0 kör, ha már fent láthatólag kezdtél befeszülni, akkor most szólok, hogy itt az ilyeneket simán el fogom engedni, azokkal együtt, amikor azzal jössz, hogy de hát ezt más is tudja. Igen, tudom, hogy van, amit más is csinál. Teljesen hibás prekoncepció, hogy a systemd csak akkor lehet indokolt, ha olyat csinál, amit más nem.
> Tehát baromi jó, de ha mégsem, akkor legalább forwardolni lehet, hogy ugyanazt kapjam, mint nélküle, tehát semmi értelme az egésznek.
Mi az, hogy semmi értelme az egésznek. Annyit mondtam, hogy ha nem kell, el lehet tekinteni tőle, attól még lehet értelme.
> A bináris loggolás egy agyrém, ami még Torvaldsnál is kiverte a biztosítékot, pedig ő direkt nem szállt bele a systemd vitákba.
Torvalds bácsi véleménye érdekes, de üzemeltetési kérdésekben finoman szólva sem gondolnám perdöntőnek. Ha a bináris logolás agyrém lenne, akkor nem lenne tele a világ olyan projektekkel, amik nem text fileokba, hanem mindenféle adatbázisokba (azok biza binárisok ám) pakolják be a logokat. Éppen azért, mert a text fileok egy csomó mindenre kevésbe optimálisak, elég fos mondjuk bennük keresni, korelálni, ilyesmi. Hogy mást ne mondjak, mondjuk a syslog-ng, meg a rá épülő scb egészen jól megél abból, hogy van neki egy bináris logstore formátuma, hozzá jó indexelés, meg jó patterndb support. Szóval nem, önmagában a bináris logolás nem agyrém.
> A logoknak pont az a lényege, hogy az ember is el tudja óőket olvasni.
Ez max vélemény, hogy ez lenne a legfontosabb, vagy főleg az egyetlen szempont. Az extrém hordozhatóság természetesen előny, a bazi méret pl (ami miatt naponta berotáljuk őket egy bináris gzipbe :P) meg hátrány, még jó pár dologgal együtt.
Ezzel együtt nem véletlen írtam, hogy nem biztos, hogy default viselkedésnek ez annyira jó, bizonyos szempontból a jó hordozhatóság, az, hogy elráncigálva egy félhalott gépről máshova a logot miatt valóban nem rossz ötlet egy sima text file. Én összességében még mindig arra szavazok, hogy az se rossz, hogy rendesen fel vannak pimpelve a system managgerrel a system logok, rém könnyen, és viszonylag gyorsan tudok szűrni a no brainer esetekben. A fontos logokon meg úgyis gondolkodtam. (És jó eséllyel nem egy text fileban laknak)
És egyébként ez egy jó példa arra, hogy nem sok értelmét látom ezeknek az eszmecseréknek. Van egy határozott, sarkos világkép a fejekben arról, hogy márpedig this is the way, tehát ami máshogy súlyoz, az már csak rossz lehet. Én meg ezekkel a fekete fehér világképekkel nem nagyon tudok, meg akarok mit kezdeni.
> Arról nem is beszélve, hogy a systemd logfájljai szeretnek korruptálódni, ami után teljesen olvashatatlan lesz az egész, a legkisebb sérüléstől is, míg a szöveges logoknál azért elég durva sérülés kell, hogy az egész olvashatatlan legyen.
Köszi a linket, igen jól mutatja, hogy milyen jól csúsztatsz, vagy legalábbis mennyire furcsán értelmezed, amit látsz. Most tekintsünk el attól, hogy az egy darab bugreport szeretnek korrumpálódni labellel jön (ne strapáld magad, biztos lehet találni még egy másik rakás esetet is, elhiszem, hogy szar), de a teljesen olvashatatlan az egész az ebből a bugból kevésbé látszik. Alatta a szerinted borderline agyament pötyi egy műszakilag teljesen korrekt összefoglalást ad arról, hogy hogyan, és miért úgy vannak kezelve a korrupciók, ahogy. Amiből például kiderül, hogy arra, hogy az egész olvashatatlan legyen, elég kicsi esély van, hiszen append only, és ahogy észreveszik, rotálnak, szóval a damage kontrol van a helyén, kéne valami igazi érv erre a legkisebb sérüléstől is teljesen olvashatatlan lesz. Lehet, hogy így van, de ha már érvelőset játszunk, akkor bizonyíts, mert ebből az ellenkezője jön le. Én most rápróbáltam, belevimeltem néhány pageup után egybe. Ha jól látom, onnan ahol szar, nem olvas. Ami nem túl vidám, de beleírva egy gzben kb pont ugyanez történik a zcattal. Az ugyan olvas, de csak garbage out van utána. Egyébként ez elég szomorú a systemdtől, az ember naiívan azt gondolná, hogy block boundarkyat azért meg lehetne ismerni.
Illetve ez biztos nagyon rendszeres, de spec korrumpálódott journal filet én még nem láttam, syslog meg logrotate által okozott katasztrófát meg egy párat már igen. (Mondjuk ezeket olyan helyeken, ahol jobban is nézi az ember, hogy mi van). De ugye a fontos logok egyébként sem csak egy helyen vannak meg, szóval én azért nem érzem itt a rettenetes showstoppert.
> Hát nem. Ezek szerint te nagyon felületesen nézted meg s6-ot.
Már most azon lovagulunk, hogy az execline nem shell script? Kérlek, a deklaratív vs script vonalon maradjuk. A systemdben effektív iniket kell írni.
> 1. Először is, nem kötelező shellscripteket használni. Azt használsz, amit akarsz.
Ami szabad fordításban azt jelenti, hogy nem kaptál megoldást. Amiket ajánlanak, azok jellemzően scriptek.
> 2. Az, hogy a SysVInit scriptekkel minden nyűg van, az nem jelenti, hogy mag a shellscripting szükségszerűen szar. Ez egy téveszme a részedről. Nézd meg a BSD.rc-t.
Nem, ez egy vélemény a részemről. Egyrészt, ha mindig nyűg van velük, akkor gyanús, hogy nem jó választás. (Néztem egyébként, szerintem az se jó). Amikor egy ilyen helyen shell scripttekkel kell játszani, az annak a beismerése, hogy rossz az absztrakciós réteg. Én nem akarok szerviz indításoknál programozási izékkel bajlódni, meg boilerplatet kopipasztálni. Ez tervezési baj, nem lenne érdemben jobb ebben a usecaseben, ha perl, python, java, vagy c kódot kellene odatenni, mert akármilyen kód mint must have baj. Az, hogy egyébként szerintem a shell programnyelvnek is kifejezetten rossz, az egy másik kérdés.
> 3. Tekintve, hogy a systemd-ben gombamód szaporodnak a javítatlan bugok, a shellscriptek okozta bugok száma ahhoz képest elhanyagolható.
Ezt elengedem, mint rant.
> Why?
Csak. Nem szeretem, ki kell csavarni az agyamat, ronda az a syntax, nem tudom. Igen, tudom, hogy egy szoc prob, nem véletlen van, ahol mégis használom.
> Ez így kevés: fejtsd ki, hogy mitől vicc az s6 függőségkezelése.
Van az s6-svwait meg az s6-svlisten, ami megmondja, hogy valami elindult, vagy megállt, a többit pedig találd ki magad. Ehhez képest a systemdben egészen sok féle előre kigondolt és letesztelt függőség megoldás van.
> Bevallom, ezt nem értettem és hiába is kerestem rá, hogy systemd Verb VerbedBy, nem találtam semmit.
Hát, ezek szerint te nagyon felületesen nézted meg a systemdt. Wants - WantedBy, Requires - RequiredBy, stb. Van, amit nem így neveznek teljesen, de azt, hogy a függőségeket oda vissza lehet definiálni.
> s6-nak is. Mitől nem normális az szerinted? Ez már a sokadik, hogy a normalitásra hivatkozol. Nekem nagyon úgy tűnik, hogy te a szubjektív "normális" jelentését a saját szemszögeddel akarod megerőszakolni, te ex-katedra kijelented, hogy X a normális way és olyan nincs másban. Hát ez nem így működik.
Nahát, mennyire genya vagyok, hogy a saját véleményem mondom. Csak én nem gondolom, hogy szentírás. FYI, a te szubjektív megítélésed sem az. Ha te nem látod a funkcinalitásban meg a kényelemben a különbséget a csomó akármictl meg az sv között, azzal nem tudok mit kezdeni. Az előbbiek sokkal alaposabban megírt, több funkcionalitással rendelkező toolok, az s6 cuccai meg egy vékony minimum, nekem az előbbi sokkal jobban kézreáll.
>> Van neki resource managementje.
>Clarify pls.
>> Van neki cgroup / namespace supportja.
> Isoraz, mit támogat a cgroupson?
A kettő összefügg. Ettől lesznek rendes resource limitek. Tudod, cpu, memória, ilyesmi.
> Te keversz valamit. Nem az baszta ki a biztosítékot, hogy van daemon-notify benne, hanem az, hogy azt akarták, hogy a világ összes daemonja a systemd daemonizerét használja. Ld. a tmux esetét, na ott megkapták a magukét.
Egyrészt gyakorlatilag pont ezt mondtam, hogy patásördög lett, mert le akarták tolni a mindenkinek is a torkán, vagy legalábbis ez volt az interpretáció. Másrészt tmux sztorira ilyenre nem emlékszem, olyanra igen, hogy egy másik feature (a nem hagyhat a user random szarokat futni csak úgy maga után, másik nagy utált cucc, mert mit képzelnek) miatt kérték, hogy tök jó lenne, ha a tmux szólna automatán, hogy ne a usernek kelljen, megtartva a megszokást, de aztán volt valami fujjdbus.
> Agyrém gányolás? Jó reggelt, az UNIX így működik. Szerinted a systemd daemonizere mit csinál belül? BTW: http://jdebp.eu/FGA/systemd-house-of-horror/daemonize.html
No shit sherlok, nem mondod, hogy a fosul tervezett init és processzing miatt ezt faszott tangót kellett leimplementálni minden egyes daemonban, hogy aztán lehessen pid fileokkal raceconditionözni. Nyilván a systemd is ad ehhez támogatást (mert különben ugye nem lenne rajta sapka), de el is mondják, hogy szerintük ez nem jó, oldja ezt meg az okosabb supervisor, semmint az összes deamon. Azok fussanak csak forground, és ne foglalkozzanak ilyenekkel, az apukájuk meg majd vigyáz rájuk. És ezzel a véleménnyel egyáltalán nincs egyedül, az s6 is pont ezt mondja, és csinálja tök elegánsan (emlékszel, mondtam, hogy cuki, nem vicceltem, az az exec chain egy elegáns megoldás)
> http://skarnet.org/software/s6-dns/
Ez egy rakás dns kliens. Vagy rendkívül fos a doksija, vagy nem értetted, mire gondoltam.
> Hogy mi?
Nem tudom, szalajtott az agyam. Szerintem a firewalld dbus interfaceére gondoltam.
> Ezt aláírom. A systemd timerek tényleg jók. Csak épp cron alternatívából dunát lehet rekeszteni. Még jobbakkal is. (Mesos + Chronos) Ettől persze a systemd timerek még nem lesznek szarok.
Ja, csak azok nem illeszkednek ilyen szépen seamless a supervising és dependency management többi részével. Simán csak cronnak csak közepesen jó. (mint a cron :P)
> Nem. Egyrészt ezt más SCS-ek is tudják, nem csak a systemd.
Hát, ezt másképp látjuk.
>Másrészt meg nem konkrétan az integráció a baj, hanem az, hogy ez mind a PID1-be van beleöntve. Ez szokta kiverni a "biztit".
Szóval tulajdonképp, ha alátolnék mondjuk egy tinit, és ettől a systemd a pid2 lenne, akkor már nem lenne baj? Vagy miért olyan rettenetes tragédia, hogy amit a rendszer felügyeletére akarok használni, az a pid1?
> Ez igaz. De Poettering nem okos ember. Amit ő művel néha, az már-már az elmeháborodottságot súrolja.
Egyrészt a systemd messze nem pötyi egyszemélyes projectje. Másrészt pötyi hozza szokásos markáns véleményű doert, ami sok sok sikeres opensource project sikerességének egyik oka. Linus, DeKok, Theo, meg még egy csomóan nem egyszerű emberek. De szeretnél te csak fele olyan okos lenni, mint az a srác.
> Miért is lenne? Az s6 úgy van összerakva, hogy egymással kommunikáló, de független részegységekből áll. Ez UNIX-os szemléletű és mégsincs tele bugokkal.
És egy csomó mindent nem tud, amit a systemd igen. (VIgyázz, ha mégis, akkor hirtelen nem lesz érv, hogy miért ilyen bloat a systemd). A systemd is sok részből áll, rengeteg helyen hozzá lehetne nyúlni, ott a dbus, lehetne vele beszélni. Ja, nem a szokásos unixos IPCt használja, shell felől nagyobb szívás jönni. De a gyakorlatban az s6ból sem nagyon szokás larpurlart más használni mondjuk az s6-rc helyett, mert minek?
> Hogy mi? :D Ha mindent egybeöntünk, ahelyett, hogy részekre lenne szedve, akkor az szerinted flexibilisebb? Bakker, az pont, hogy merevebb, hiszen szükségszerűen egybe van öntve az egész, aminek nem cserélheted le egyetlen részelemét sem...
Egyrészt mind mondtam, ez a nem cserélheted le egyetlen részét sem ez erős csúsztatás, másrészt nem erre gondoltam, hanem arra, hogy ezek az összecsiszolt részek sokkal részletesebb szabályok mentén tudnak együttműködni alapból. Ergo konfigolni flexibilisebben lehet, hogy mit szeretnél. Lehet, hogy nem ez a legjobb szó
> Ez igaz, de hogy jön ide? DBus-szal? :]
Egyrészt nyilvánvalóan poénból, másrészt azért, mert szokott menni a nyekergés, hogy pl a geci gnomeosok logindt (? asszem ezen szokott menni) használnak, és jajj szegény bsdk.