- Apple iPhone 16 Pro - rutinvizsga
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
- Google Pixel topik
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Íme az új Android Auto!
- Samsung Galaxy A55 - új év, régi stratégia
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- iPhone topik
- Realme GT Master Edition - mestermunka
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
F34R
nagyúr
válasz
bambano
#29932
üzenetére
Az nem FreeBSD-re van, tegnap meg homalyban voltam... ma eszembe jutott, OpenBSD-re csinaltak ilyet. de elvileg ez nem teljesen atvett systemd, csak ahhoz hasonlo inint rendszer.. [link]
FreeBSD-re egyebkent OpenRC aplikalhato.
En ilyen gepre nem tennek BSD-t.... Alpine -al probalkozhatsz, de inkabb Devuan..
-
inf3rno
nagyúr
válasz
bambano
#29932
üzenetére
Ja ezt néztem régebben, de nem kell komolyan venni szerintem, többek között azért sem, mert egy systemd fejlesztő mondja. Azok alapján, amit FreeBSD fórumon olvasok systemd-vel kapcsolatban kizártnak tartom, hogy bármi ilyesmit elfogadna a közösség. Nagyjából az az álláspont, hogy megnézik, és ha találnak bármi használható ötletet benne, azt esetleg belekódolják FreeBSD-be, de eddig nem tűnik úgy, hogy kifejezetten rajonganának bármiért is, ami benne van. A gummiboot-ot sajnálom, hogy benyelte az a fekete lyuk, úgy tűnik jó boot loader volt, de így, hogy már a systemd-sek határozzák meg a fejlesztés irányát, supportot, stb., jobb kukázni.
-
Frawly
veterán
válasz
bambano
#29926
üzenetére
Nem kizárt, hogy neked van igazad, de én erről nem tudok, mérmint hogy systemd-nek megfelelő szutykot tolnának a FreeBSD-sek a rendszerükbe. Valami linket tudsz erről adni?
(#29929) F34R: igen, ez meg a másik, hogy fájlrendszerek támogatása terén is le vannak maradva a BSD-k. Persze megértem őket, mert egy nagyságrenddel kisebb legalább a fejlesztők száma, de lehet van két nagyságrend is. Így meg a szűkös erőforrások nem elengedők ahhoz, hogy mindenben hozzák a linuxos támogatottsági szintet. Ezért van kevesebb tároló és mirror is hozzá. Viszont másik oldalról pont ez a jó is benne, hogy még nem támogatott minden sz@r rajta, meg nincs elbloatosítva.
-
Frawly
veterán
válasz
bambano
#29922
üzenetére
Sajnálattal olvasom én is. A FreeBSD nekem tartalék terv. Ami most még visszatart tőle, hogy a drivertámogatottsága erősen le van maradva a Linuxhoz képest (NetBSD még szimpatikusabb a még kisebb hardverigénye miatt, de az meg még rosszabbul át driverek terén), főleg GPU-knál meg Wi-Fi-nél problémásak a driverek, de amúgy mindenben le van maradva, ami driver, meg van pár szoftver, ami nem érhető el rá, pl. Wine, Steam. Na, meg mindenki kedvence, a systemd, pulseaudio sem érhető el rá., de ez pozitívum
![;]](//cdn.rios.hu/dl/s/v1.gif)
Meg amiatt sem BSD-zek még, mert még a Linuxban sem fejlődtem ki magam, nem használtam még ki minden benne rejlő potenciált. Úgy meg nem akarom elhamarkodottan dobni. De ha nagyon elbloatosodik a Linux, akkor elkerülhetetlen lesz a BSD-re váltás, a Win, MacOS nálam nem játszik.
A Debian éltetésével nem értek egyet. Bármelyik nagyobb, mainstream disztró felhúzható 10 perc alatt grafikus felülettel. Én az Archot 15 perc alatt felhúzom neked, ha nincsenek nagy extra igények, és valami sztenderdebb DE-vel telepítem, ami függőségnek beránt, megold minden szükséges dolgot.
-
Vladi
nagyúr
válasz
bambano
#29922
üzenetére
Tudtam én, hogy bepróbálod.
"beledugtam a debian telepítő pendrájvomat és 10 perc alatt lett."
Ugyan így voltam én a debiannal anno. Na most van egy olyan projekt, hogy itt kipróbálom, akkor honnan töltsem, meg mit, és hogy telepítek csomagot és hol a tároló és hol a centos 7 install lemezem...
"maradunk az "öreg vagyok én már bohócnak" szindrómánál"
"de szerintem a világ nem erre halad."
Jah hát nem erre. Viszont amerre, az neked ugyan úgy nem teccik mint ez. -
-
Vladi
nagyúr
válasz
bambano
#29836
üzenetére
"driver le. ez az én hibám."
Igen. A zártaknál ez alap, a nyílt drivereket le tudja kezelni.
"hallador kolléga pár napja publikált tűzfalas cikket"
Erről lemaradtam, illetve most se találom.
"ha nem romlott el, ne akard megjavítani"
1. mégiscsak elromlott, mert nekiálltál javítani.
2. ha mindenhez így állnánk, akkor még a fán ülnénk. Szerencsére elég sűrűn romlanak a dolgok."persze lehet ez a hozzáállás kifogásolható"
Igen.Ami a freebsd-t illeti, engem az lepett meg, hogy mennyire naprakész és bőséges a programkínálata.
Rád meg előbb utóbb vár a systemd-homed, esetleg ios rosszabb esetben windows. -
Vladi
nagyúr
válasz
bambano
#29830
üzenetére
Okés, vesézzünk. Én értem a problémádat technikailag és emberileg is, de:
2010 környékén 7600gt kártyámat az nvidia cseréltem 4670-re, az meg amd. ez az akkori fedorán úgy nézett ki, hogy driver le, fedora leáll, kártyát átszerel, fedora indul, driver betölt, kész.Ehhez képest a windows 7 ugyan ezen művelet alatt olyan összecsuklást produkált, kb amit imént leírtál.
A freebsd-s felvetéseidre nem tudok séróból válaszolni, de ha komolyan érdekel, biztos, hogy 10-15 perc alatt ki lehet gúglizni.
-
Frawly
veterán
válasz
bambano
#29824
üzenetére
Az RX570-nel nem tudsz mellényúlni. Melyik modellt vetted, 4 gigásat, 8 gigásat, Armor verziót? Ahogy nézem, 3 DP port is van rajtuk, úgyhogy paradicsomban fogod érezni magad. Ráadásul nem túl új kártya, a kernelben lévő amdgpu driver, és a linux-firmware csomagban lévő AMD firmware simán viszi, csak legyen fent a legújabb mesa is, akkor se X.org-os, se waylandes felületek alatt nem lesz gondod se a megjelenítéssel, se a hardveres gyorsítással, se a hardveres dekódolással.
Az RX570-ben még van annyi erő, hogy bármelyik játékot is simán elviszi 1080p 60 fps-sel, high beállításokon (néha médium, némelyik játékban az ultra is sima neki), Vulkan, DXVK, Proton is mind támogatott. Freesync is.
Ha nem játszol rajta, akár alul is feszelheted, underclockolhatod egy kicsit, azt mondjuk nem tudom Linux alatt hogy kell, de csendesebben jár majd tőle.
-
Vladi
nagyúr
válasz
bambano
#29825
üzenetére
"amikor kiderül, hogy minimum kernelt kellene upgradelni, hogy felismerje a kártyát"
Milyen kernel ez? Ez egy viszonylag régi gpu, nem elég modul?De rendes tőled, hogy nem a mianyánkat ki vagy a mennyekben.
singel userbe se bootolt? Vagyg ilyen csodák már nincsenek szisztemdés időkben?
mod: lesz egy kis időm megy fel a freebsd. Neked is javasom, vedd elő újra a projektet...
mod2:
amdgpu-pro dirver 18.40 már támogatja a kártyád, ez még centos 6-ra is elkészült. azt ne mond, hogy ennél régebbi a kerneled.
Meg 16-os ubuntura, az kb a debianod korabeli lehet, vagy régebbi.Értem, hogy kizártad magad, de hiányolok itt egy kis rtfm-et.
Vagy keresel csomit, de az már debian specifikus megoldás. -
-
Frawly
veterán
válasz
bambano
#29816
üzenetére
GT 1030 például. Esetleg GTX 1050. Ettől jobb felesleges is, mert mint írtad úgyse játszol. De fontold meg az AMD-t, annak jobb a drivertámogatottsága. Az NV kártyákhoz zárt NV driver kell, az AMD-ket meg viszi a kernelbe beépített nyílt driver.
Ami a jelentősebb megkötés, az a két DP port. Ilyen nem biztos, hogy minden kártyán lesz, ez szerintem gyártófüggő is, azaz NV-n belül is gyártója válogatja. DP szokott lenni majd minden kártyán, meg HDMI is, de hogy pont DP-ből legyen mindjárt kettő, annak nagyon utána kell nézni.
Az a kártya, amit most vettél, az konkrétan milyen? Milyen driverrel hajtod?
-
-
Frawly
veterán
válasz
bambano
#29787
üzenetére
Wow, ez nekem teljesen új. Nem tudom hogyan másol /dev/null-ba, mikor azon nincs fájlrendszer. Persze ettől még lehet megoldották. Azt sem értem, hogy ha egy fájllal tudja, akkor a több fájlnál mi okoz neki gondot. Valami directory-ra hivatkozik, de nem világos miért.
-
#23196416
törölt tag
válasz
bambano
#29688
üzenetére
Programozó, hogyne lenne nagy arca... Szerintem egy elavultan kezelt problémára adott egy új, jó, hatékony választ. Bughalmaz? És ha mindaz amit a szoftver tud, összeszeded egyes különálló komponensekből és kiegészíted saját scriptekkel mire nagyjából ugyanazt tudod hozni, mekkora lesz a kód és mekkora lesz a bughalmaz? Ha ebből élsz, és rengeteg munkaórát öltél enterprise környezetben sysv systemd migrálásra, bizonyára busásan megfizettek érte, egy egy erős win szituáció. De rajtam ne múljon, remélem a közösség hamarosan összefog a sötét nagyúr ellen, forkolja ördögi gyermekét, és a nap örökké ragyogni fog az új fork felett ami minden csorbát kiköszörül, hiszen mi is gátolna meg bárkit ebben?
-
kovaax
őstag
válasz
bambano
#29703
üzenetére
Sajnos a munkahelyi munkaállomásokon windows van, és úgy, hogy minden nap leállítom, másnap elindítom, az XP sp2 volt az első, amivel nem volt különösebb stabilitási problémám (az más kérdés, hogy egy csomó mindenben rám akarják erőltetni a f@szságaikat azóta is). Megkacsáztam, 2004 augusztus 25-én jött ki, kb. fél év után kaphattuk meg. Szóval addig stabilabb volt az otthoni linuxom...
-
Dißnäëß
nagyúr
válasz
bambano
#29703
üzenetére
Na jó, nem 24. 16-18 ? 96-ban Netscape navigátoroztam faternál a cégben és néztem a DOS után az űrtechnikát, utána jött egy ősrégi SUSE, amivel elkezdtem kapizsgálni egyáltalán, mi az a Linux, utána jöttek az első szopások VMWare-el, hát az ja, úgy kb. 2000-es évek első fele, pont gimi után. Akkoriban még jobban érdekelt az IT, mint a punci, érdekes módon.
-
samujózsi
senior tag
válasz
bambano
#29684
üzenetére
Nem csak szerinted, de pl a debian(?) fejlesztők szerint a noexec az hülyeség, úri huncutság, ördögi praktika...
De az is lehet, hogy ez már ubuntus marhaság: sok telepítő nem működik, ha noexec van a /tmp-n. És nem értem, hogy miért. (Úgy értem: miért oda csomagolja ki a futtatandó szemetet?) -
samujózsi
senior tag
válasz
bambano
#29626
üzenetére
Az bjztosan nem. A nested X gyakorlatilag ablakban futtat egy másik X szervert.
Nekemnmeg az kellene, hogy húzzon egy függőleges vonalat a monitor közepén és a két oldal önálló virtuális dekstopként viselkedjen.
Sokadjára megnézve lehet, hogy mégis nagyjából arról lenne szó, amit májmiki linkelt.Eredendően arra kellett volna, hogy az egyik oldalra kihajítom maximalizálva a böngészőt a szükséges doksikkal, a másik oldalon meg dolgozom, de úgy, hogy a munkafelület ablakai nem takarják el, nem mozdítják meg a browser ablakát.
Workarondként akár ez is szóba jöhet, bár macerás bizonyos esetekben: [link]
-
Dißnäëß
nagyúr
válasz
bambano
#29581
üzenetére
Nanana. Telco szektorban, de akár banknál is, vagy tkp bárhol, olyan irdatlan megagiga BSS stack-ek vannak Windows alapon, hogy nélkülük azonnal földbe állna az egész cirkusz. A vállalatirányítás csak 1 a listából, amit kiragadtál. Valid, de csak 1, az arányokat még így is eltolja bőven 20-30-50% körülre akár az, amikor jön egy csapat vendor egy kiírásra és röpködnek a négyjegyű CPU mag igények a proprietary cuccuk alá, amik miiiind-mind MS alapú megoldások. A vállalatirányítás Góliátja ezekhez képest szúnyogfing.
-
haddent
addikt
válasz
bambano
#29574
üzenetére
Szerintem arra gondolt a kolléga meg Linus is fregmentáció alatt, hogy csilliárd felé ágazott/ik a linux és "központi hatalomként" csak a kernel van, de ugye abból is forkolnak ide-oda mindent és semmi nem biztos, soha. Értem én, hogy sokszor szükséges a kalapálás-hegesztés egyedi módon, de 90% -ban ez a csakazértismáséssajátésegyedileszek
-
AcCEsS
senior tag
válasz
bambano
#29533
üzenetére
Tulajdonképpen a tv előtt ülve telefonról szeretnék átváltani Kodi-ról SteamLink-re. A kodi service leállítása simán működik, de sajnos Buster alatt a SteamLink kizárólag X környezetből futtatható, ezért előbb az X környezetet kell indítanom, azzal együtt autostartol SteamLink is. De időközben meglett a megoldás:
sudo usermod -a -G tty pi
sudo apt-get install xserver-xorg-legacy
Ez utóbbi a lényeg, és akkor már lesz /etc/X11/Xwrapper.config, amibe be lehet jegyezni az "allowed_users = anybody" sort.Így már simán működik!
-
Frawly
veterán
válasz
bambano
#29512
üzenetére
Ebben nem lennék biztos. Persze abban egyetértek, hogy lehet nem fizetődik ki a vele töltött munka, főleg nem egy cégnél. Bár ez attól függ, hogy ki mire használja.
Én hobbi szinten is gondoltam saját rendszerre, forráskódból forgatva. Ezt nem is disztrónak nevezném, mert akkor disztró valami, ha terjeszted. Én saját rendszernek tervezem, csak a saját használatra, csak saját gépre, csak azokat a progikat fordítani, amiket használok is, minden kifejezetten csak arra a gépre fordítva. Amúgy LFS-szerűen, de nem LFS-sel. Ez annyira egyedi rendszer lesz, ha tető alá is hozom valamikor, hogy senki másnak a gépére nem lesz alkalmas, de pont itt jön a poén, hogy nem is kell alkalmasnak lennie. Pont ez az, a legtöbb disztró keze meg van kötve, mert általános céllal mennie kell sok hardveren, illeszkednie kell sokféle felhasználáshoz. De saját célú rendszeren nincsenek ilyen kötöttségek, hogy Garázs Bt. gépén, meg Gipsz Jakab gépén is mennie kell. Emiatt kihagyhatok a rendszerből minden általam nem használt sallangot, a kernelbe már bele se kell forgatni egy csomó drivert meg szokásos lehetőséget.
-
haddent
addikt
válasz
bambano
#29512
üzenetére
Nem mindenki, csak nem tudunk róla, mert tényleg belsős. Ha jól tudom a Google -nél saját Debian forkot használnak saját hardeninggel. Ilyen méretű dolgokra gondoltam, ez alatt vicc kategória.
De ellenpéldának melóban van, hogy hozzák a teljes vm imaget aztán na tartsd karban a saját kis kiépített sles - saltstack világodban azt a szutyokszemét oracle linuxot oracle db -vel. Oracle nevet eleve meglátom már rosszul vagyok, annyi fertőt hoztak a világra
Borzalom minden amihez nyúlnak -
válasz
bambano
#29496
üzenetére
Az ilyen webes kódoktól a hideg is kiráz... Meg úgy a webfejlesztéstől alapvetően
(#29499) Frawly
tényleg csak arra lesz jó, hogy valaki megpróbálja jogászkodással a felelősséget áthárítani valaki másra Gyakran ez egy igen fontos szempont.
Szerintem a licenccel sincs probléma, főleg nem szerveren, mert a legtöbb szerveres dolog pont GPL-es opensource. Egy random rolling distrónál ki garantálja, hogy minden ami benne van jogilag jó? Egy normál distró esetén minden verzió adott, bármikor pontosan meg lehet mondani, hogy mit használunk, abban benne van-e egy adott rés stb.
-
haddent
addikt
válasz
bambano
#29496
üzenetére
Hát ezért vannak a webpack meg társai. Felszippantja az összes includeot, összegyúrja, minimize aztán ott van egyetlen (vagy több) saját kis js csomag. A fejlesztés további része, ha megszűnne egy csomag támogatottsága jó kérdés lenne, de ebbe ne menjünk bele, mert egyetértenénk, hogy a js mekkora egy undormány hányinger és itt nincsenek hozzászokva, hogy egyetértünk
-
samujózsi
senior tag
válasz
bambano
#29487
üzenetére
A 20.04-re kicsi az esély. A 16.04 kb így került a vasra, úgy egy héttel a megjelenése után, de csak kényszerből, mert a régebbi kernelekkel voltak gondok az akkor vadonatúj procin, ebben találtam olyan kernelt ami többé-kevésbé jól kezelte a hardvert.
Az új rendszerekben sok a bug, ezért is tartok kicsit a rolling release-ként megjelenőktől (arch, suse). -
Frawly
veterán
válasz
bambano
#29487
üzenetére
A várással nem értek egyet. Nincs értelme várni, ennyi erővel mindig várhatnánk valamire. Ha most kell OS a szerverre, akkor most kell, azt kell feltenni, ami már most megjelent. Egyébként pont ez is a rolling előnye, nem kell semmilyen kiadásra várni, meg külön disztrófrissítésekre időt dedikálni.
Egyébként meg attól is függ, hogy mekkora támogatottsági időt akar. Ha nagyon hosszú támogatottsági idő kell, akkor a CentOS 8.1 a legjobb jelenleg ebből a szrmponból, az 11 és fél évig támogatott lesz még, ennyi év után meg nem az lesz a szempont, hogy a telepített rendszer elavul (mert az el fog már 2-5 év után avulni nagyon csúnyán, a régi verziók nem fogják tudni semmi újabb szoftvernél kielégíteni a verziófüggőséget), hanem a gép hardverügyileg is teljesen elavultnak fog számítani addigra. Vagyis vannak ennél hosszabb támogatású disztrók is, de azok már fizetősek tudtommal.
-
-
haddent
addikt
válasz
bambano
#29443
üzenetére
Nem, ezen valóban nem lehet vitatkozni, mert pontosan gépi feldolgozás szempontból tulajdonképpen zseniális, de visszamehetünk teljesen elemi, matematikai feldolgozásra, azazl formális nyelvek és automatákra, nagyon szép, egyszerű, lineáris determinisztikus automatával felismerhető nyelv. A CSV már ott egy rakás szar, hogy nincs konkrét szabvány, de ha ezt félretesszük és jóhiszeműen feltételezzük, hogy mindenki a nevében szereplő comma -t használja, akkor is egy káosz egy json/yaml -hez képest. Ez nem szubjektivitás kérdése egész egyszerűen.
Ha esetleg netán elírtad volna és pont fordítva értetted, tehát, hogy "humán" szemszögből ronda, akkor elnézést a "kirohanásért", ehhez a véleményedhez nyilván tökre jogod van
Vagy megint elmehetünk olyan irányba, hogy nagyon végtelenül primitív egyszerű adat (struktúrának nem nevezhető) kis szösszeneteket ki lehet fosni csv -ben is, csak akkor meg elő fog jönni az a tipikus eset, amikor pl. syslog esetén nem az RFC szabvány szerint logol valaki/mi, "me' megspórolunk 3 bitet!" aztán amikor valaki parsolni, értelmezni, aggregálni, rendszerezni szeretné (pl ELK, Graylog) akkor majd írjon magának hozzá egyedi lószart, vagy töltsön le plugint, nem ám 1 kattintás a szabvány szerinti
-
inf3rno
nagyúr
válasz
bambano
#29420
üzenetére
"mondtam én, hogy * nem szabványos formátum? hint: nem mondtam." (*: a JSON)
"Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki,: vagyis csv-ben, és még véletlenül sem json-ben."
Egy kicsit önellentmondóak a hozzászólásaid.
-
haddent
addikt
válasz
bambano
#29405
üzenetére
Igen, előfordul, nem egyszer. Ahogy az is, hogy fej-fej megy a C -vel. Java meg hasonló viccek közelébe nincs soha. Nyilván amint olyan részhez érünk, ahol nem a C libeket használja, hanem pure python, akkor nagyságrendekkel lassabb, nem hittérítés részemről továbbra sem
bambano persze, ha bios -t vagy hasonlót fejlesztünk. De akár már csak kernelnél is inkább kell gondolni arra, hogy ez nem 1x megírom és 30 évig nem nyúlok hozzá majd újraírom lesz, hanem délután jön 2 másik mikrokód amiket integrálok, commit, CI tesztek stb aztán deploy meg testing aztán production. Fenntarthatóság, követhetőség. Persze mindezt ésszel, vannak helyek ahova aki nem sima C -t használ fejbe kéne lőni
-
samujózsi
senior tag
válasz
bambano
#29407
üzenetére
Épp ezért nem fogok grep/sed helyett pythont használni, ellenben perl-t azt bármikor, ha az előbbiekkel nem lehet két mozdulattal elintézni vagy épp lehet, csak kib.lassú... (pár hónapja futottam ilyenbe, hogy sorokban stringet cserélni bizonyos esetekben nagyságrendekkel lassúbb a grep ... | sed -e ... formában, mint perl szkriptben. (Konkrétumokra nem emlékszem, talán a notebookomon megvan valahol, ha kell)
-
samujózsi
senior tag
válasz
bambano
#29405
üzenetére
Az nem bash, már bocs... egyébként van amikor gyorsabb a futása, mert a sed és a python más regex feldolgozót használnak.
Te itt foggal-körömmel véded az álláspontod, hogy bash, most meg kiderül, hogy valójában nem is a bash a lényeg, hanem a unix/linux toolok használata? (Amit viszont természetes, hogy meg kell ismerni annak, aki dolgozni akar a linuxszal) -
-
samujózsi
senior tag
válasz
bambano
#29399
üzenetére
????
Na ezt részletezd plíz, mert a "nemszabvány" csv ugye úgy néz ki, hogy egy sor = egy rekord, a mezők általában ;-vel (vagy más megadott karakterrel) szeparálva, plusz lehetőség van a mező tartalmának idézőjelezésére, hogy el legyen különítve a numerikus és a string adat (illetve ha a mező tartalmaz a szeparátorral azonos karaktert, akkor ott ne akarjon új mezőt a parser)
Ha valami egyedit csinálsz, annak már csak az általad adott neve csv. Szerintem. -
samujózsi
senior tag
válasz
bambano
#29394
üzenetére
Itt szokott előjönni (mármint a csv vs egyéb formátum témában), hogy
- azért mostanában elég ritka, ha egy fejlesztő csapat egy konkrét cég házi csapata, soha, senki másnak nem dolgoznak. Az jellemzőbb, hogy külsősök, saját kódbázissal x darab jelenlegi és y potenciális, jövőbeni ügyféllel. Emiatt akkor is muszáj univerzális megoldással jönniük, ha konkrétan nektek dolgoznak.
- írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?) -
haddent
addikt
válasz
bambano
#29388
üzenetére
Ebből a kommentedből is látszik, hogy nagyon más nézetet vallasz. Nem rossz vagy jó kérdése ez és nincs igazad meg nekem sem, továbbra is mindkettő kell. Egy modern, nagy, bővülő, naponta 10x commit-test-deploy ci óriás enterprise szörnyet a te módszereiddel borzalom lenne életbentartani, vagy inkább lehetetlen.
Pont a példád a tökéletes példa. Monitoring adatokat pont, hogy igenis valamilyen sztenderdizált formátumban és azon belül is szépen formázva adunk ki, hogy univerzális és kompatibilis legyen ne csak a te shell scripteddel, hanem grayloggal, prometheussal, kibanával meg nagyjából bármivel is, ne kelljen külön parser meg interpreter hozzá. A json beolvasása objektummá ami aztán iszonyú jól kezelhető pontosan 2 sor (melyből az egyik 1 import) Pythonban. Nincs elírás, nincs jajj idézőjel, space, nincs fájl ellenőrzés mert ez mind a beolvasó object exception modelljeinek része. Egyszerű, elegáns és nem utolsó sorban gyorsabb/hatékonyabb is mint a bash valószínűleg, mert egy agyonoptimalizált C kód-wrapper
A hálózati példád nem fejtetted ki ennyire, de vakon erről is kb. ez mondható el. Lehet iptables írogatni vimmel, csak aztán azt tartsa karban meg egyben aki nem normális.. Akár csak egy Vyos vagy pfSense sem tesz rá túl óriási absztrakciót, de épp akkorát, hogy át tudsz látni 1000 szabályt is.
Viszont van az a hely, pl. pont a kígyó saját farkába harap, Pythont nem lehet Pythonban fejleszteni, mert egy fos lesz. C -ben kell
Nem az absztrakció az ellenség.. nem hülyegyerekek találták ki ezeket és nem hülyegyerekek számára. Akkor van óriási probléma, amikor a hülyegyerek él az absztrakció nyújtotta lehetőségekkel és kényelmi funkciókkal úgy, hogy fingja nincs róla mi zajlik a háttérben. Na az k*#& gáz, és sajnos ebben viszont igazad van, hogy ez a többség. De nem a puska a hibás, ha lelőnek vele valakit..
-
samujózsi
senior tag
válasz
bambano
#29388
üzenetére
Én flame helyett maradnék a tények mezején.
Te gyűlölöd. Én tudomásul veszem, hogy ilyen és használom.
Ha valaki tanulni akar, annak szvsz nem azt kellene néznie, hogy egy szarrá hardeningelt/hackelt szerveren milyen lehetőségei vannak, hanem azt, hogy a tanulmányait befejezve, a témában kezdőként, milyen tudással tud elhelyezkedni, ha ez a célja.
Itt azért a bash elég sokadlagos szempontnak tűnik.
Linuxon ugyan default többnyire a bash, de rengeteg helyen futhat ksh-ba (*BSD), ash/dash/busybox shellbe stb.
Ezekből talán több van, mint kiherélt szerverekből. Unixból még nem láttam olyat, ahol ne lett volna perl felrakva, bár azt meg nem mondom, hogy mely unixon, melyik rendszerkomponensek íródtak perlben, valahogy a *bin könyvtárakban sohasem kerestem szkripteket, linuxon is tudom, hogy sok rendszeralkatrész (igaz, főleg GUI-s) íródott pythonban, de ezekre is igaz: tudom, hogy vannak, emiatt nagyon ritka, ha a python alap nincs fenn.Ui: vicces, a git ragaszkodik a perlhez?
ubuntu18.04 serveren ezt mondja -
haddent
addikt
válasz
bambano
#29381
üzenetére
Miért, Pythonban megfordult a menetirány meg az ifirány, vagy miről maradtam le? Vagy a generátorokra gondolsz, amikkel 1 sorban rendezel le egy 50 soros C headert?
Az indentálást syntax részévé tenni szerintem fura, de jó ötlet, szerinted szar. A végeredmény szerencsére az, hogy még a kókánygenyó indiánus "programozók" kódja is valamelyest olvasható, néha -
samujózsi
senior tag
-
samujózsi
senior tag
válasz
bambano
#29376
üzenetére
Hurrá... írtam féloldalnyi választ, majd a mobil "back" gombjával sikeresen eltüntettem.
Nem írom újra: az általános shell ismeret kötelező, a bash-t... nem vinném túlzásba. Napi munka során nem nagyon fut össze olyan rendszerrel az ember, ahol nincs perl és/vagy python, esetleg awk.
Olyannal inkább, ahol bash nincs. Pl. beágyazott rendszerek, routerek (busybox)
Persze ez csak azbén véleményem. -
Dißnäëß
nagyúr
-
haddent
addikt
válasz
bambano
#29234
üzenetére
Rendbe bizony
De már megy, hardware offloadot ki kellett kapcsolni.
Következő csoda: minden tökjól natolódik, kivéve szerencsétlen deluget. Bármit csinálok, nem tölt se föl se le lényegében. Deluge ui -ban zöld minden, de amúgy kb. 0 forgalom. Sense logban már zöld minden, NATolva van egy konkrét porton, reflekt (oda-vissza), egyszerűen nincs reject, mégis
Bár épp az előbb bugolt be, fogta magát és olyan rule alapján engedett valamit amit már töröltem. Aztán meg létrehoztam újat és arra meg nem futott rá .. Még 1-2 ilyen aztán köszönöm szépen megyek vissza iptables cli -hez -
Frawly
veterán
válasz
bambano
#29219
üzenetére
Az elvileg bele van fordítva. Legalábbis vonatkozót csak a menuconfig - Device Drivers ---> Character devices ---> Serial Drivers részben találok, de itt minden be van kapcsolva:
* 8250/16550 and compatible serial support
* Console on 8250/16550 and compatible serial port
* 8250/16550 PCI device support
* Extended 8250/16550 serial driver options
és még egy csomó ilyen 8250/16550-es dolog: sharing interrupts, autodetect IRQ, RSA serial ports support, Intel LPSS/MID support.Egyedül csak speciális, konkrét UART eszközöknél nincs csak *, mint pl. Altera UART support, ARC UART driver, stb..
Elhiszem pedig, hogy működnie kéne, pl. Ubuntu kernellel. A QEMU verziója sem baj, a legújabb 4.2.0-ás stabil QEMU-t használom, tehát nem elavult, meg nem dev/béta verzió.
-
samujózsi
senior tag
válasz
bambano
#29219
üzenetére
De az nem default manapság?
Azért megjegyzem, a posztod alapján van bennünk némi közös: mazochista módon állunk az ilyen szarokhoz
Én most egy EFI-vel súlyosbított KVM virtuális gépre próbálok arch linuxot varázsolni a célból, hogy kipróbáljam ezt a kernelt a default configjával.
Épp csak... korábban szinte kizárólag virtualboxot használtam, az archlinuxból a nevén kívül semmit sem ismerek. -
samujózsi
senior tag
válasz
bambano
#29208
üzenetére
Megtiltani senki sem akarja, hogy hozzányúljatok. Viszont azt senki se várja el a kernel fejlesztőitől, hogy olyasmire pazarolják az idejüket, mint pl a kernel hibáinak pontos meghatározása egy-egy ilyn crash esetén!
Mert ugye itt elsősorban azon megy a szófosás napok óta, hogy érthetetlen a kiírt hiba a felhasználónak. -
samujózsi
senior tag
válasz
bambano
#29204
üzenetére
Azért az érzed, hogy itt átlaguserről van szó, nem hobbista kernelfejlesztőről?
Úgy a 0.99-1.0 környékén még volt rá példa, hogy a kernel dumpból kintudtam hámozni, minvolt a baj, mi több, a cdu31a driver részébe még bele is írtam pár sort a magam szórakoztatására (ha tudod még, mi volt az)
Ma már csak user vagyok, eszembe nem jutna ezekben turkálni -> nem várom el, hogy olyan helyről jöjjön úgymond értelmes hibaüzenet, amivel esélyem sincs érdemben kezdeni valamit.Vagy, ha mindenáron értelmes infóként akarok a kernel efféle hibaüzeneteire tekinteni, akkor nem morgok azon, hogy értelmetlen (nem az), hanem megtanulom értelmezni. Ami saccra pár hónap tanulás alsó hangon.
-
válasz
bambano
#29190
üzenetére
Alapvetően bőven vannak debuggolási lehetőségek, csak szinte mindegyik performance impacttal jár. Szóval nem igazán érdemes bekapcsolni normál esetben. Ezek képesek akár soronként haladni, pl. ftrace, kgdb. Ha crash van akkor lementődik az egész memória kép (ha be van állítva rendesen a rendszer). Az, hogy az alapján dobjunk hibát, hogy milyen sorban vagyunk szvsz egy agyrém, normál esetben semmi értelme sincs. Ha esetleg kell ilyesmi akkor ott az ftrace.
Azért opensource, hogy bárki küldhessen be patchet. Bele hackelni szerintem otthonra sem szerencsés ötlet, kisebb elcseszések is okozhatnak nagyon furcsa problémákat. Egy kernel backtracenek sosem volt és sosem lesz célja az egyszeri felhasználó számára való olvashatóság.
-
samujózsi
senior tag
-
kraftxld
félisten
válasz
bambano
#28809
üzenetére
Örököltem a rendszert, egy partner cég már elvileg megcsinálta és kiszámlázta a DR-t és az ügyfél hümmögve megkérdezte, hogy akkor holisvan a DR
Ezt kell gyorsan megkalapálni (a VMware részt) és valszeg segíteni abban, hogy az adatok minnél rövidebb RPO-val automatikusan átkerüljenek a DR-ba. -
haddent
addikt
válasz
bambano
#28789
üzenetére
Én egy szóval nem állítottam, vagy akkor félreértettél, hogy csak annyit tenne. Nem ismerem olyan mélységeiben, hogy működési elveiről vitázzak és különösebben jelenleg nem is foglalkoztat, hiszen az iparban systemd van, akárkinek akár tetszik, akár nem. Majd ha más lesz akkor megtanulom azt 1 nap sz**ással aztán ennyi
Két dolgot állítok, egyik az személyes véleményem és tapasztalatom, hogy szerintem/nekem/én tapasztalataim alapján tök jó a systemd. Ezzel vitába lehet szállni, csak felesleges, mert mostmár egészen világosan kiemeltem, hogy szubjektív, illetve felőlem hívhatod izolált esetnek, bár nem hiszem, hogy egyedül vagyok.
A másik, objektíven, hogy ha talán pl. neked / te felhasználásodban nem is a legjobb, azért bőven használható és workarounddal simán megoldható minden, ahelyett, hogy kézzel kelljen bizbaszkodni, még ha mondjuk sysvinitben szebb is lenne, vagy neked jobban kézreállna/tetszene.Sőt, lehet, hogy többet tud a sysvinit, nem tudom. De nekem se itthon, se a szervereken melóban sehol nem volt eddig másra/többre szükségem. Azt akarom csak ezzel mondani, hogy továbbra sem vagyok semminek a hívője, pl. ott lenne a networkd is, de nem használom, mert ku***ra kevés az én igényeimnek egyelőre. De a netctl, ami nem is tudom pontosan talán Arch saját projekt de systemd mintára, az egyik legjobb, megint, nekem
-
haddent
addikt
válasz
bambano
#28783
üzenetére
Mert a többi 90% -ban egyszerűbb és hatékonyabb. De ezt már túltárgyaltuk, hogy neked nem begyerés akkor sem, itt csupán szükségmegoldásról volt szó, hogy azért működésre lehet bírni, nem kell kézzel
ivana eh, jah, lényegében ugyanaz csak kicsit tisztább, hosszú volt a nap
-
haddent
addikt
válasz
bambano
#28779
üzenetére
Tisztán elméleti okoskodás részemről. Szóval lehet, hogy "oem" nem megy, de amit meg tudsz kézzel csinálni, azt scripttel is. Mi lenne, ha scriptelnéd amit kézzel csinálsz, és beraknád multi-user.target.wants -ba, majd szintén ide a postfix-et, csak a postfix.service -be tennél egy
After=manual-hax-startup- ot? Ennek pontosan azt kéne elérnie amit szeretnél, elméletben.Az más kérdés, hogy out-of-the-box miért nem működik, de szerintem azért eléggé egyedi igény ahhoz, hogy egy manual scriptet elviseljen. A sors fintora, hogy más inittel úgyis kéne írtni scriptet
-
-
inf3rno
nagyúr
válasz
bambano
#28769
üzenetére
"volt service manager, úgy hívták: init." - Ha a sysvinit-re gondolsz, akkor erősen az a benyomásom, hogy túl keveset tud, és nem igazán támogatja a fejlesztést. Mármint az jött le, hogy annyit csinál összesen, hogy elindít egy bash scriptet bootoláskor, amit megadsz neki, aztán kalap. A systemd-ről az jött le, hogy van egy event bus, arra küld mindenki eseményeket, és onnan veszik le a szolgáltatások azokat, amikre nekik reagálni kell. Sokkal kiforrottabb ez így nekem, bár a megvalósításról továbbra is az a benyomásom, hogy fos. De ezeket tényleg csak érzésre mondom az alapján, amiket olvastam. Ma van egy kis időm, rászánok néhány órát, meg belenézek a kódokba is, hogy tisztázódjon ez az egész. Én személy szerint valószínűleg OpenRC vagy ilyesmi mellett kötök ki, de érdekel a téma.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Milyen belső merevlemezt vegyek?
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Path of Exile (ARPG)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen routert?
- Teljes verziós, ingyenes mobil játékok és alkalmazások
- Sega, Nintendo - retro konzolok
- eMAG vélemények - tapasztalatok
- Luck Dragon: Asszociációs játék. :)
- Gaming notebook topik
- További aktív témák...
- Apple iPhone 15 Pro Max 512GB, Kártyafüggetlen, 1 Év Garanciával
- VÉGKIÁRUSÍTÁS - REFURBISHED - HP Elite / ZBook Thunderbolt 3 docking station
- BLUESUMMERS NVMe SSD adapter
- AKCIÓ! Intel Core i9 14900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- Geforce GTX 1050, 1050 Ti, 1060, 1650, 1660 - GT 1030 - Low profile is (LP)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest