Udev a Systemd se spojují

Projekty Udev a Systemd se spojují do jednoho stromu. Podpora funkce připojení za běhu je klíčová pro dnešní init systémy. Funkcionalita Udev je tak integrální součástí Systemd a spolu se snahou minimalizovat duplicitu kódu, administrativní zátěž a odbourat cyklické závislosti při sestavování jádra OS je tak důvodem tohoto spojení, jež bude distribuováno jako Systemd verze 184 a vyšší. Oficiální podpora sestavení Udev bez Systemd bude zachována.

3.4.2012 20:00 | Nicky726 | Nová verze

Komentáře

[belisarivs]

Kill it. Kill it with fire.

Jeste chvilku me bude Lennart srat a ja na nej vypisu odmenu a hadam, ze nebudu sam.

[Migi]

asi založim odbojovou skupinu proti saboterum opensource softwaru, čmuchám tu prvního adepta na člena .

[Dom]

+1

[Migi]

Mohlo by se to jmenovat třeba LARA - Linux Anti Revolutionary Army a naším maskotem by byl Tux v převleku za Laru Croft .

[BFU]

Jenze Lara mela nejvetsi prumer nahore ... tux ho ma dole ... nevim jak by to vypadalo

[Michal Kubeček]

Otočit vzhůru nohama? :-)

[Mti.]

Jeste horsi. Zobak by blbe trcel. :-/

[qpal]

A co otocit Laru kozama dolu, to by mohlo nalakat prispevatele..?

[mrv]

no, oss totiz nejvic pomahaj kokoti, co hovno delaj a na vsechno nadavaj. omfg...a to abicko nebyvala uplna sracka, ale v posledni dobe se to tu fakt tezce neda :smutnik:

[ukos]

zato sprosťáci jako ty a fanatici, co rozvrtávají funkční věci, ti tomu oss pomáhají asi nejvíc! Leda tak do hrobu.

[pavlix]

Tak si kucí pokecejte :).

[michich]

Uklidni se. Takovéhle řeči jsou přinejmenším nevkusné.

[kavol]

a to že Lennart rozesere co může vkusné je?

[ukos]

+1

[michich]

To je irelevantní. Vyhrožování fyzickým násilím nelze ospravedlnit.

[Lol Phirae]

Pár pádnejch facek je rozhodně produktivnější, než sáhodlouhé nikam nevedoucí vysvětlování... :P

[Nicky726]

Hmmm, bylo by to produktivnější i na některé místní diskutující/kritizující?

[kavol]

ok, jaké řešení navrhuješ?

p.s. tak naokraj, mám zato, že naše kultura fyzické násilí akceptuje, pokud je to přiměřené, např. policie může použít různých "donucovacích prostředků", až po usmrcení, takže v západní společnosti vyhrožování fyzickým násilím rozhodně ospravedlnitelné je - můžeme se tak nanejvýše bavit o tom, zda je v mezích zákona a morálně přijatelné

... a to nemluvím o tom, že jde jen o nadsázku (zřejmé mj. z užití oblíbeného memu) spíše než o skutečnou výzvu k likvidaci

[michich]

ok, jaké řešení navrhuješ?

Jmenovaný problém ("Lennart rozesere co může") nepovažuju za skutečný, takže ho řešit nepotřebuju. Pokud bych problém zjemnil na "systemd má chyby", tak řešením je je opravit.

p.s. tak naokraj, mám zato, že naše kultura fyzické násilí akceptuje, [...]

O násilí jsem psal v kontextu threadu o Lennartovi. Nechci se zde pouštět do obecné diskuse, kdy může být násilí přijatelné. Ale jestli moc chceš vědět, jak to vidím, tak tě odkážu na díla klasického liberalismu.

[kavol]

ok, jaké řešení navrhuješ?

Jmenovaný problém ("Lennart rozesere co může") nepovažuju za skutečný, takže ho řešit nepotřebuju.

což ovšem nedává odpověď na otázku, co podle tebe mají dělat ti, co s tímto tvým názorem nesouhlasí, jestliže násilí považuješ za nepřípustné

takže ... "kdybys ten problém považoval za skutečný, co bys navrhoval?"

p.s. tak naokraj, mám zato, že naše kultura fyzické násilí akceptuje, [...]

O násilí jsem psal v kontextu threadu o Lennartovi.

já též

[pavlix]

což ovšem nedává odpověď na otázku, co podle tebe mají dělat ti, co s tímto tvým názorem nesouhlasí, jestliže násilí považuješ za nepřípustné

Ok. Když tedy nesouhlasím s tvým názorem, navrhoval bys mi, abych proti tobě použil fyzického násilí? Do jaké míry? Jen k modřinám nebo až do usmrcení? Rád si vyslechnu tvé doporučení.

[kavol]

pavlixi, prosímtě, než na mě budeš příště reagovat, přečti si nejprv dvakrát relevantní část threadu, a až to napíšeš, počkej nejmíň deset minut než se ti to rozleží, pak si to přečti potřetí, zkonfrontuj se svojí odpovědí, a teprve potom, přijde-li ti to pořád správné, odešli, anebo začni znova, anebo se na to úplně vykašli

prozradím ti jedno sladké tajemství, které ti v zápalu boje zřejmě uniklo, a to že je jistý rozdíl mezi názorem a činy, takže tvé návodné otázky jsou úplně mimo - nikdo tady použití násilí pro rozdílnost názorů nenavrhoval

[pavlix]

Hehe :). Tušil jsem, že si to vezmeš osobně, ale tolik?

nikdo tady použití násilí pro rozdílnost názorů nenavrhoval

Tedy bití sa (údajně) špatně napsaný software? Víš kolik lidí, by muselo být bito? Nebylo by pak jednodušší bít preventivně všechny programátory, on už si to bůh přebere.

Prozradím ti jedno sladké tajemství. Navrhovat fyzické ubližování někomu na základě toho, že se ti nelíbí jeho program je zhovadilost. Pokud je to pro tebe takové neštěstí, a pokud jen trochu můžeš a nezávisí na tom tvé současné i budoucí živobytí, prostě ten nenáviděný software nepoužívej.

Já chápu, že jsi emotivní člověk, neberu ti to, ale tohle by stálo za přehodnocení.

[kavol]

Tedy bití sa (údajně) špatně napsaný software?

omlouvám se Jendovi za vrhání na zeď, ale ... mohl bys přestat s těmi neustálými záměnami předmětu?

Navrhovat fyzické ubližování někomu na základě toho, že se ti nelíbí jeho program je zhovadilost.

Navrhovat fyzické ubližování někomu na základě toho, například že se ti nelíbí, že něco ukradl, je zhovadilost.

nebo ne? ... má policajt nechat zloděje odkráčet, neb zadržením proti jeho vůli by mu fyzicky ublížil?

existuje vesměs všeobecná shoda na tom, že krádeže jsou pro společnost škodlivé, pročež násilí k jejich zamezení povolujeme

co když dojdeme ke shodě, že Lennartův "program" (sic!) je pro společnost obdobně škodlivý?

[pavlix]

co když dojdeme ke shodě, že Lennartův "program" (sic!) je pro společnost obdobně škodlivý?

Tak doufám, že se z toho dotyčný programátor vykřeše a že vy soudcové lynčové skončíte ve vězení. Nic víc, nic míň, toto je můj pohled na věc.

A my ostatní se rozhodneme, zda daný software budeme používat nebo ne a budeme si o vás číst v novinách. Reiser asi taky usoudil, že jeho žena je společensky škodlivá.

[Vskutečnosti Saýc]

Promin, ale ten clovek se snazi znicit linux. Co jineho s nim chces delat? Ostatne co jineho s tebou? Chces sebrat lidem neco co maji radi, rozbit neco co funguje, a jeste se u toho budes vysmivat lidem? Je logicke ze te jednho dne nekdo sunda.

(I'm kidding.)

[pavlix]

Promin, ale ten clovek se snazi znicit linux.

Paranoia se dá léčit. A argumentace přejetí autem, kterou jsi použil níže mi připadá jako že už ses předvedl dost.

Ostatne co jineho s tebou? Chces sebrat lidem neco co maji radi

Nevím, jak jsi přišel na to, že chci někomu něco sebrat. Je z tvé strany křivé obvinění. Nehledě na to, že je to dost slabý argument od člověka, který by druhým chtěl brát život či zdraví.

Je logicke ze te jednho dne nekdo sunda.

Teď přemýšlím, jestli bych na tebe neměl podat trestní oznámení za vyhrožování fyzickým násilím či dokonce smrtí.

[Vskutečnosti Saýc]

To bys mohl, ale potom bych vedel kde bydlis!

Loukam ze Poeuv zakon, "Without the use of a winking smiley or other blatant display of humor, it is impossible to make a parody of fundamentalism that someone won't mistake for the real thing." fakt funguje. Zavrazdit kvuli initu? Vazne?

U Reisera slo (pokud vim) o to, ze se rozvadeli a jeho zena vzala deti a odvezla je do Ruska aby je uz nikdy nevidel. Coz je malicko jiny pripad, kvuli detem delaji lide silenejsi veci nez kvuli pocitacovym programum.

[pavlix]

To bys mohl, ale potom bych vedel kde bydlis!

To najdeš v živnostenském rejstříku.

[kolcon]

jeste placeny agent MS Miguel de Icaza

[Michal Kubeček]

Ten už je ze hry. Teď je na řadě Red Hat. :-)

[vezen]

+1

Lennart je imperialistickej rozvracec a proto jsem odesel od Fedory, ktera se v kazde verzi odvraci od nasich revolucnich idealu. Sezazeni ALSA a nasilne jmenovani PA jsem jeste prezil, ale on soudruh Lennart na ty proverky jde primo od initu a s tim se uz jen tezko muj kadrovy profil vyrovna.

[stativ]

No doprdele…

[Michal Kubeček]

Tohle přišlo pozdě. O dva dny…

[snajpa]

Je tu nekdo, kdo tyhle zmeny vita v tom podani a provedeni, jak jsou? ...

[kozzi]

JJ, ja to vitam, me se to nahodou moc paci

[Bedňa]

+1

[little.owl]

+1

[mess]

Píšou, že udev půjde dál sestavit i bez systemd a bude po dlouhou dobu kompatibilní se stávajícími ne-systemd init systémy (i když nevím, co znamená "po dlouhou dobu"). Takže je mi to v podstatě šumák. A až to rozbijou, tak buď vznikne nějaký fork nebo moje distribuce přejde na systemd, aby vůbec šlo nabootovat, a život půjde dál.

[David Watzke]

To jsem si mohl myslet, mnoho povyku pro nic

[pavlix]

+1

[mirec]

Ja napríklad ;)

V podstate v systemd nevidím nejaké veľké nebezpečenstvo. Na prvý pohľad sa zdá zložitejší než súčasný systém, lenže ak si človek uvedomí, že nepotrebuje množstvo ľahko rozbitných shell scriptov, takže to nakoniec môže byť odladenejšie než sysv. Okrem iného so sysv sa veľmi ľahko môže stať, že z nejakého dôvodu (oom, segmentation fault ...) služba padne a nemá ju kto naštartovať, čo systemd elegantne rieši.

V každom prípade zatiaľ na serveroch nikto neplánuje nasadzovať systemd a ako experiment na desktope rozhodne nezaškodí.

[petr_p]

A o restartu se uloží záznam, tudíž s každým restartem zmizí kousek paměti. Lennart místo kruhového logu doporučuje vypnout logování nebo prostě nechat dojít paměť.

[michich]

Můžeš to nějak rozvést? O jakém kousku paměti to mluvíš? A kde Lennart doporučuje to, co říkáš?

[petr_p]

systemd retains socket-activated service failure records forever leading to memory exhaustion

[Lol Phirae]

I will post a blog story about this very soon

Geniální řešení. Blognu si vo tom.

[kralyk z abclinuxu]

Geniální řešení. Blognu si vo tom.

A ten text nad touhle větou sis přečetl?

Píšeš o little owl, že je fanatik, ale sám naprosto vytrhneš větu z kontextu.

[kralyk z abclinuxu]

Aha tak pardon, tos asi nebyl ty... no ale stejně, přečti si ten text okolo

[Lol Phirae]

Četl jsem. Nicméně blognout si vo tom, že tam je potenciální remote DoS, to ten problém s nesmyslným defaultním chováním asi těžko vyřeší, že?

[pavlix]

Takže jestli to dobře chápu, tak by se o tom blogovat nemělo?

[Lol Phirae]

Blogovat by se mělo maximálně o tom, že ta chyba byla opravena a defaultně chování už je "sane". Ne o tom, že pokud někomu vadí remote DoS, tak ať použije workaround, protože stávající nesmyslné výchozí chování by se mohlo někdy někomu hodit.

[pavlix]

Blogovat by se mělo maximálně o tom, že ta chyba byla opravena a defaultně chování už je "sane".

To mi zavání cenzurou.

Ne o tom, že pokud někomu vadí remote DoS, tak ať použije workaround, protože stávající nesmyslné výchozí chování by se mohlo někdy někomu hodit.

Podle mě otevřená diskuze pomáhá. Minimálně si můžeš po jejím přečtení lépe srovnat v hlavě argumenty protistrany.

O tomto konkrétním problému nemám dostatek informací, je to v něčem jiné než ostatní problémy s přetékáním třeba logů na disku a reakcí automatických systémů, které na obsah logů reagují?

Ono totiž ohánět se slovem DDOS je jedna věc, mít v ruce jasnou a srozumitelnou analýzu toho, že dotyčná „vlastnost“ zhoršuje nebo potenciálně může zhoršovat současnou situaci, je věc druhá.

Vývoj klíčových OSS systémů se nadáváním ovlivňuje dost blbě. Ono někdy je práce uspět i když máš pádné argumenty a snahu problém vyřešit, natož, když nemáš.

[Lol Phirae]

O tomto konkrétním problému nemám dostatek informací, je to v něčem jiné než ostatní problémy s přetékáním třeba logů na disku a reakcí automatických systémů, které na obsah logů reagují?

Eeeeh. Asi v tom, že standardně je v distribuci nainstalováno cosi jako logrotate. Hádej proč. :P Krom toho by měla "sane" implementace mít cosi jako rate limiting, aby nezasírala log zcela zbytečnými a nepotřebnými hovadinami. Když už pominu takovou věc, jako že disk má standardně tak o dva řády větší kapacitu a je sakra rozdíl, jestli dojde paměť anebo jestli dojde místo ve /var/log.

A to už vůbec pomíjím systemd-journal a onu "geniální" myšlenku vyrobit ze systémového logu binární blob (což už nezkousla ani Fedora).

[pavlix]

Eeeeh. Asi v tom, že standardně je v distribuci nainstalováno cosi jako logrotate. Hádej proč. :P Krom toho by měla "sane" implementace mít cosi jako rate limiting, aby nezasírala log zcela zbytečnými a nepotřebnými hovadinami.

Cosi jako... měla by... hele já jsem pro.

A to už vůbec pomíjím systemd-journal a onu "geniální" myšlenku vyrobit ze systémového logu binární blob (což už nezkousla ani Fedora).

Závidím ti tvoji jistotu, že Fedora nebude v budoucnu obsahovat binární logy se sadou příkazových nástrojů na jejich prohledávání a správu. Že fedora nezkousla binární logy je tvrzení na úrovni nadpisu z Blesku.

Já osobně to spíš vidím tak, že FESCO správně rozhodlo, že v tuto chvíli nemá smysl měnit rsyslog za journald.

Myslím, že nedodělaných démonů je ve F17 až dost, firewalld ještě nemá ani permanentí konfiguraci a to má F17 za chvilku vyjít.

[little.owl]

Tak tohle se zda byti jedna z veci, kde by Lennart mel byti uzemnen

[Martin Mareš]

Jako by jeden Jörg Schilling nestačil ;)

[kavol]

nejsem si úplně jist nač narážíš, ovšem dovolil bych si poznamenat, že cdrecord alespoň funguje (resp. jinak, v první verzi, která se ke mně dostala, jsem s ním neměl problémy, což se rozhodně nedá říci o zde diskutovaném systemd a dalších produktech z téže dílny ...)

[Martin Mareš]

Že cdrecord v časech, kdy se o něj staral Jörg, fungoval??? Asi žijeme každý v jiném světě. Například mu na mnoha systémech nešlo rozumně nastavit, jakou vypalovačku má používat, protože Jörg byl přesvědčen, že jediný způsob, jak se odkazovat, na zařízení, je prostřednictvím jeho SCSI ID a vše ostatní je hříšné a prokleté. Že může mít jeden stroj více SCSI řadičů, z nichž polovička jsou virtuální SCSI na ATAPI nebo třeba iSCSI, a proto žádná dlouhodobě stabilní IDčka nemají, mu bylo marno vysvětlovat.

S Lennartem je to podobné: je skálopevně přesvědčen o své pravdě, která je konsistentní jenom proto, že Lennart má klapky na očích a nevidí zbytek světa.

[Milan Jurik]

Je zvláštní, že jsem nikdy neměl s cdrecordem problémy a dosud nemám. Oproti cdrkitu/wodimu a dalším forkům a rewritům. Dodnes nejsem schopen bezpečně pálit v Debianu na slušné mechanice a kvalitních mediích, i když i to zvládnou bez problémů jak čistě W7, tak Solaris s cdrw (což už je hodně stará a neudržovaná věc) i cdrecordem. Takže, prosím, prskejte si, nadávejte (já se občas také s Jörgem zhadám), ale přirovnávat ho k LP je sprosté.

[kavol]

ráčil sis všimnout oné závorky, kterou připouštím, že to vlastně v různých jiných případech fungovat nemuselo, že explicitně mluvím o svém světě, kde se SCSI IDčka nastavovaly jumperama na zařízení, a kde se nevyskytovali šotci, co by je po nocích přehazovali, a tedy se tam ani nevyskytoval problém s měnícíma se IDčkama?

jinak ale vidím tu dva rozdílky ...

1) existence pouze jednoho způsobu výběru zařízení používání sice komplikuje, ale nebrání mu, což je dost podstatný rozdíl oproti tomu, kdy daná věc nefunguje vůbec

2) jestliže cdrecord nefungoval v okrajových případech, kdy ti po pokoji řádí šotci a přehazují jumpery, tak Lennartovy výmysly fungují právě jen v těch okrajových případech, když za úplňku 29. února odříkáváš kouzelnou mantru sedě na tučňáčím vejci

[Lol Phirae]

Lennartovy výmysly fungují právě jen v těch okrajových případech, když za úplňku 29. února odříkáváš kouzelnou mantru sedě na tučňáčím vejci

Sakra, tak tady dělám chybu! A tos nemohl říct o dva měsíce dřív? Teď abych zase skoro 4 roky čekal.

[kavol]

Lennartovy výmysly fungují právě jen v těch okrajových případech, když za úplňku 29. února odříkáváš kouzelnou mantru sedě na tučňáčím vejci

A tos nemohl říct o dva měsíce dřív?

na co, vždyť tou dobou byla první čtvrt, nikoli úplněk ...

[Martin Mareš]

Jenže ono vůbec nejde o šotky :) Jörg prostě žije ve světě, kde má každý stroj jen jednu SCSI sběrnici a na ní zařízení s IDčky nastavenými jumpery. Nepředpokládá, že by jeden stroj mohl mít dva řadiče, jejichž pořadí závisí na tom, který se při bootu zrovna stihne zinicializovat dřív, nebo že by se mohla vypalovačka kdykoliv připojit po USB (na noteboocích docela běžné). A to už pěkných pár let nejsou okrajové případy.

[kavol]

ono taky pěkných pár let není originální cdrecord v distrech default ...

každopádně, i když se shodneme, že takováto vlastnost může být poměrně nepříjemná, a že by s tím mohl něco dělat (hm, měl jsem pocit, že dělá, vím, že jsem nějakou dobu používal místo SCSI id linky jako /dev/cdrw - nebo to bylo patchováno balíčkovači?), nějak v tom stále nevidím, jak to brání primární funkci programu, tedy vypalovat?

[trekker.dk]

Nemožnost nastavit to, kterou vypalovačku použít, nebrání primární funkci programu, tedy vypalovat... hmmm

[Vskutečnosti Saýc]

Skutecne je to nemoznost? Ja uz jsem cdcka teda nevypaloval roky, ale nejde udelat nejake "lsscsi" a podivat se, ktere id ta vypalovacka ma? dmesg | grep writer? Je to otravne, ano, ale porad si myslim ze to neni tak smutne jako init system ktery se nasilim tlaci vsude, a pritom nezvlada takovou situaci jako nahozeni alsy nebo ipsecu pri startu, a podle autoru ji ani zvladat nebude, protoze proste proto.

[pavlix]

a pritom nezvlada takovou situaci jako nahozeni alsy nebo ipsecu pri startu

A prosímtě, který že je to init systém, který to nezvládá a tak moc se protlačuje? Já o žádném nevím, zřejmě mi něco uniklo.

[stativ]

Podstatnej rozdíl mezi tema dvěma je v tom, že ačkoliv je Jörg vůl, programovat umí. Z Lennarta lezou jen nepoužitelné bastly, které pak musí někdo jiný opravit (ano, narážím na pulse audio, které začalo „trochu“ fungovat až po změně maintainera).

[Vskutečnosti Saýc]

Jorg je na osobni pokec docela v pohode, jenom je takovej tvrdohlavej. Neco jako djb.

I kdyz djb je zas jinej priklad, ten clovek umi delat uzasnej software, ale to jak ho navrhne vzdycky vyvolava dojem ze j na nejakejch tvrdejch drogach.

[stativ]

Jorg je na osobni pokec docela v pohode, jenom je takovej tvrdohlavej.

Já se zatím bavil Jorgem jen emailem a měl jsem z toho trošku jiný pocit…

[ukos]

...služba padne a nemá ju kto naštartovať, čo systemd elegantne rieši.

Zatím se mi nezdá, že by to řešila. Už třikrát se mi na téhle vymoženosti stalo, že nějaká služba (pokaždé jiná) vychcípla a systemcmd status pěkně zeleně tvrdil, že je služba aktivní a běží. Při tom neběžela, nastartovat ani restartovat nešla. Musela se stopnout a znova nahodit. Tohle mi za minulých dvacet let systemV neudělal ani jednou. Mám pocit, že na svobodném software teď dělají looseři vyhození z Mikrosoftu pro neschopnost!

[belisarivs]

Ja mel zase problem s alsou. Systemd ji nezvladal nahodit. takze jsem mel ticho. Ladit se to dalo na prd a nefungovalo to. Skvele.

[R]

Alsa je predsa v jadre.

[belisarivs]

Akorat ze pro ni potrebujes jeste nahodit nejakeho daemona. A to se prave Systemd moc nedarilo.

[kralyk z abclinuxu]

Akorat ze pro ni potrebujes jeste nahodit nejakeho daemona.

Afaik nepotřebuješ, akorát restore levels, což je nějaké jedno zavolání alsactl... Afaik.

[belisarivs]

Koukam na /etc/init.d/alsasound.

Ten, mimo jine, natahuje jaderne moduly a vola alsactl.

Kazdopadne je to celkem trivialita, kterou systemd nezvladal.

Zatimco ted muzu mrknout primo na ten skript a vidim, tak odladovat systemd znamenalo dalsi srani okolo, kdy jsem muzsel zjistovat, jak se chova a co dela a stejne mi alsa sverepe hlasila "dead" a zvuk nesel.

Po zahozeni systemd bylo vsechno v pohode.

To byl taky duvod, proc jsem na systemd zmenil z neutralniho az mirne pozitivniho nazoru na negativni a hodlam se mu vyhybat co to jde.

Ostatne, muzu utect zatim na Debian, a pokud se zblazni i tam, tak zkusim Gentoo, kde se vyrazeni OpenRC nebojim.

[pavlix]

Kazdopadne je to celkem trivialita, kterou systemd nezvladal.

Definuj nezvládal. Pravda je, že jsem systemd nesledoval od jeho počátků, ale od té doby, co o něm vím, tak spouštět falešné služby, které spočívají jen ve spuštění nějakého skriptu, umí.

[pavlix]

K tomu gentoo, ti udržují celý základní systém v dlouhodobě na tak dobré úrovni, že zařazení systemd klidně počká nebo se dokonce nemusí konat vůbec. Gentoo tahá ze skriptů maximum, narozdíl od mnoha jiných distribucí, kde se to řeší buď po staru nebo přes systemd.

[xHire]

zařazení systemd klidně počká nebo se dokonce nemusí konat vůbec

Gentoo si vyvíjí OpenRC a poměrně nedávno se na něj začalo migrovat jako na stabilní řešení (a to se vyvíjí nějaké 4 roky, systemd teprve 2 a začalo se na něj migrovat o dost dřív jak na OpenRC, pokud se nepletu). Troufnu si proto říct, že Gentoo na systemd nikdy migrovat nebude.

[little.owl]

Tak Fedora/Redhat prokazali jiz mnohokrat v minulosti, ze maji vice zdroju/vyvojaru nez Gentoo a jsou tak schopni protlacit klicove technologie/zmeny v podstatne kratsim case.

[Tomáš Bžatek]

No uz i ve stable maji nektere balicky USE flag systemd, takze integrace probiha uz ted Ale ja taky radeji openrc, povazuju to za dobry system.

[little.owl]

Gentoo diverzant a primo v zazemi!

[mimi.vx]

tak navrhy na vyrazeni OpenRC se objevily uz v pred dvema lety a existuje oficialni gentoo howto jak pejit na systemd ...

[pavlix]

Už třikrát se mi na téhle vymoženosti stalo, že nějaká služba (pokaždé jiná) vychcípla a systemcmd status pěkně zeleně tvrdil, že je služba aktivní a běží.

To se může při špatně napsané unitě stát.

Mám pocit, že na svobodném software teď dělají looseři vyhození z Mikrosoftu pro neschopnost!

Tihle tvoji „looseři“ vydali doporučení, jak se mají systemd unity psát a jak mají systémové aplikace fungovat. Neměli by ti spíš vadit ti, kteří se ještě nenaučili buď těmi doporučeními řídit, nebo si promyslet svá vlastní funkční doporučení.

[Michal Kubeček]

vydali doporučení, jak se mají systemd unity psát a jak mají systémové aplikace fungovat. Neměli by ti spíš vadit ti, kteří se ještě nenaučili buď těmi doporučeními řídit

Tohle je ale přesně ten "buldozerový" přístup, který mi vadí. Spousta démonů není vyvíjená primárně pro Linux, spousta dokonce není vůbec vyvíjená s ohledem na Linux. Chtít po jejich vývojářích, aby se přizpůsobili tomu, co systemd nalinkoval, dost dobře nejde.

[pavlix]

Tohle je ale přesně ten "buldozerový" přístup, který mi vadí. Spousta démonů není vyvíjená primárně pro Linux, spousta dokonce není vůbec vyvíjená s ohledem na Linux. Chtít po jejich vývojářích, aby se přizpůsobili tomu, co systemd nalinkoval, dost dobře nejde.

A jak bys chtěl psát systemd unitu jinak než podle specifikace pocházející od vývojářů systemd?

Stačí správně napsat cca tři řádky konfigurace, což je mnohem jednodušší než správně napsat sysv initskript.

Systemd se stávající situaci přizpůsobuje až zbytečně moc. Kdyby se prostě řeklo, že každý démon musí umět běžet „normálně“ na popředí alespoň s nějakou volbou na příkazovém řádku, ani bych se nedivil.

[flame]IMO je velké plus v diskuzi vědět, o čem mluvíš :).[/flame]

[Lol Phirae]

Kdyby se prostě řeklo, že každý démon musí umět běžet „normálně“ na popředí alespoň s nějakou volbou na příkazovém řádku, ani bych se nedivil.

No jistě, protože tak to je soudruzi správné, tak to musí být!

[pavlix]

No jistě, protože tak to je soudruzi správné, tak to musí být!

Vést technickou debatu na politické úrovni nebudu :).

[David Jaša]

--foreground by mělo být povinné nejen kvůli systemd.

[little.owl]

+1

[pavlix]

+1

[ukos]

To se může při špatně napsané unitě stát.

To by se stávat právě nemělo. A hlavně to dává další otázku - proč jsou v jedné z majoritních distribucí minimálně tři špatně napsané unity? Proč se cpe mezi lid něco, co pořádně nefunguje - a co si (narozdíl od původního konceptu) jen málokdo může opravit?

Proč redhat tlačí linux pryč z místa, kam vždy patřil - to jest, že si každý trochu schopnější uživatel mohl upravit systém podle svých potřeb? Ještě pár podobně debilních změn a budeme s každou prkotinou čekat, až distributor vydá servispack. Pokud ho vůbec náš problém bude zajímat...

[tomasgn]

Proč redhat tlačí linux pryč z místa, kam vždy patřil - to jest, že si každý trochu schopnější uživatel mohl upravit systém podle svých potřeb?

aby vydelal na placene podpore?

[mimi.vx]

+1

[pavlix]

To by se stávat právě nemělo.

To říkej těm, kterým se to stává :).

A hlavně to dává další otázku - proč jsou v jedné z majoritních distribucí minimálně tři špatně napsané unity?

Neberu nic menšího než odkazy na detailní bugreporty.

Proč se cpe mezi lid něco, co pořádně nefunguje - a co si (narozdíl od původního konceptu) jen málokdo může opravit?

Na tuto otázku ti nemůžu odpovědět, protože má nepravdivé předpoklady.

Proč redhat tlačí linux pryč z místa, kam vždy patřil - to jest, že si každý trochu schopnější uživatel mohl upravit systém podle svých potřeb?

Dtto.

Ještě pár podobně debilních změn a budeme s každou prkotinou čekat, až distributor vydá servispack. Pokud ho vůbec náš problém bude zajímat...

Tak používej systém, se kterým jsi alespoň v rámci možností spokojený. Já to tak taky dělám.

[kavol]

V každom prípade zatiaľ na serveroch nikto neplánuje nasadzovať systemd

JPP?

[xHire]

Příloha:

• bad-lego-toy.jpg (41625 bytů)

V podstate v systemd nevidím nejaké veľké nebezpečenstvo. Na prvý pohľad sa zdá zložitejší než súčasný systém, lenže ak si človek uvedomí, že nepotrebuje množstvo ľahko rozbitných shell scriptov, takže to nakoniec môže byť odladenejšie než sysv.

„Write programs that do one thing and do it well.” [zdroj]

Okrem iného so sysv sa veľmi ľahko môže stať, že z nejakého dôvodu (oom, segmentation fault ...) služba padne a nemá ju kto naštartovať

Už když jsem s GNU/Linuxem začínal, tak jsem na tohle začal používat specializovanou utilitu. daemontools. A dalších jiných existuje celá řada. Nutno říct, že nikdy daemontools nikdy neselhaly. A když už je nemůžu nebo nechci používat, napsání jednoduchého watchdog skriptu je triviální.

Mnohem radši si systém vyskládám z jednotlivých – malých a funkčních – lego kostiček, než abych si pořídil jednu velkou hrůzu (alá příloha), a pak se snažil hledat, kde co způsobilo, že mi něco nefunguje… (Natož, abych to pak musel ještě opravovat!)

[lm]

a predstav si, ze ked si s linuxom zacinal, a objavil si tu specializovanu utilitu tak existovali ludia co s linuxom/unixom nezacinali a nadavali na daemontools, ze su zbytocne a ved predsa na vsetko si napisu skript atd :)

[pavlix]

Tak já když občas u někoho musím pracovat s daemontools, tak to by se člověk začal k systemd kolikrát i modlit :).

[trekker.dk]

...protože pracovat s daemon tools je tak jednoduché, že si nemůžeš naúčtovat dost hodin...?

[pavlix]

Ne, protože je to dělá v systému takový bordel, že jsem nad tím strávil mnohem víc času. Nebylo všechno kvůli daemontools, něco bylo kvůli qmailu, djbdns a dalším podobným věcem.

Z většiny z těchhle výtvorů v logu nevypadlo ani lidské datum, kdy se nějaká akce stala. Dokumentace pomálu, ovládání děsivé. Daemontools je jen špička ledovce.

Naúčtoval jsem si na to nějaké ty desítky hodin navíc, které jsem samozřejmě dostal zaplacené. Takže z tohohle pohledu bych měl daemontools milovat stejně jako komerční banku.

[trekker.dk]

Ne, protože je to dělá v systému takový bordel, že jsem nad tím strávil mnohem víc času.

Daemon Tools? Bordel? Vždyť je to pár binárek, jedna se spustí (většinou pomocí inittab) a řídí všechno ostatní. Jednoduché, přehledné, funkční. Jediné, co se tomu dá vytknout, je umisťování souborů DJB way (platí zejména pro to ostatní, ne pro Daemon Tools), ale v některých distrech je ošetřené i tohle.

Z většiny z těchhle výtvorů v logu nevypadlo ani lidské datum, kdy se nějaká akce stala.

RTM. Use the tai64nlocal, Luke.

Naúčtoval jsem si na to nějaké ty desítky hodin navíc, které jsem samozřejmě dostal zaplacené.

No tak pokud ti zákazník připlatí za to, že něco neumíš, tak je samozřejmě všechno v pořádku.

[xHire]

Asi myslel právě rozmístění souborů. Nějaké /command je docela obskurní na běžné poměry.

[trekker.dk]

/command ? Pokud máš na mysli /service, tak třeba v Debianu je to /etc/service. A od té doby, co si někdo vymyslel /run, už je /service ten nejmenší problém.

[xHire]

$ ls /command
envdir@     multilog@       setlock@    supervise@  svscan@      tai64n@
envuidgid@  pgrphack@       setuidgid@  svc@        svscanboot@  tai64nlocal@
fghack@     readproctitle@  softlimit@  svok@       svstat@

$ tail -n 1 /etc/inittab 
SV:123456:respawn:/command/svscanboot

Tož asi tak. Ty symlinky navíc vedou do /package, což je další exot v řadě.

[trekker.dk]

No, řekněme, že některá distra tohle mají ošetřené o malinko líp

[xHire]

To rozhodně, protože tohle byla manuální instalace, nikoli z distribučního balíčku.

[xHire]

a predstav si, ze ked si s linuxom zacinal, a objavil si tu specializovanu utilitu tak existovali ludia co s linuxom/unixom nezacinali a nadavali na daemontools, ze su zbytocne a ved predsa na vsetko si napisu skript atd :)

Už když jsem daemontools (a další z djb rodiny) instaloval, tak jsem byl obeznámen s tím, že se lidé dělí na dva tábory: skalní příznivce a skalní nepřátele djb softwaru. Ovšem ti nenadávali na to, že jsou zbytečné a že jde napsat si skript (djb software jsou jednoúčelové záležitosti, žádné „všechno umím” obludy, žádné vnucování se, takže tohle přirovnání imho kulhá na obě nohy), ale že djb razí dost svérázné názory.

A mně se na jeho programech líbila právě ta jednoduchost, perfektní spolehlivost a bezpečnost. Pro to jsem byl ochoten skousnout i pár manýrů jako třeba ignorování konvencí, co se adresářové struktury týče.

[Martin Mareš]

ale že djb razí dost svérázné názory.

Jo, například takové, že nikdo nikdy nebude v DNS potřebovat CNAME

Já jsem si z toho učinil logický důsledek, že nikdo nikdy nebude potřebovat djbdns :)

[xHire]

ale že djb razí dost svérázné názory.

Jo, například takové, že nikdo nikdy nebude v DNS potřebovat CNAME

To bude asi nějaký informační šum, protože djbdns CNAME záznamy nativně podporuje. Používal jsem ho dost dlouho na to, abych věděl, co umí. A říct o něm, že nepodporuje nějaký typ záznamů v zásadě nejde (díky podpoře generického záznamu).

Já ho opustil jen proto, že neuměl naslouchat na IPv6 socketu. Kdybych tehhdá věděl o existenci forku dbndns, tak jsem možná vůbec nikam nemigroval. Ale už se stalo.

[Martin Mareš]

Minimálně ho několik let neuměl a DJB tvrdil, že ho nepřidá, protože se mu nelíbí.

A říct o něm, že nepodporuje nějaký typ záznamů v zásadě nejde (díky podpoře generického záznamu).

To bych tak jistě netvrdil. Některé záznamy vyžadují dodatečné zpracování, například přidání dalších záznamů do additional section. Typicky CNAME.

[Petr Ježek]

Pokud bude Udev fugovat bez Systemd, pak sjednocení průnikového kódu je prospěšná věc. Já mám spíš problém se Systemd...

[Lol Phirae]

Leck mich im Arsch, Herr Poettering! Jdu zkoumat, jak rozchodit mdev z busyboxu.

[Lol Phirae]

How to replace udev in Linux with mdev. No výborně, hned o víkendu na to jdu.

[Tomáš Bžatek]

No, to mel byt opravdu spis aprilovy zert. Se systemd jsem mel zatim tolik problemu, jako s zadnym jinym init systemem.

[kozzi]

No, nevim ja to na archu zkousel a na to ze to jeste neni zcela odladene se to chovalo dobre.  V podstate jsem nenarazil na nic zvlastniho. Ale je pravda ze jsem od toho nic nechtel. Stacilo mi to ze mi najel system a pri trose stesti i nejake sluzby :D

[kralyk z abclinuxu]

+1

[little.owl]

A nejake podrobnosti?

Chapu, ze to ma stale mouchy, ale ty vy prece casem vychytate!

[Tomáš Bžatek]

No ja nevim, pouzivam to od pocatku (od te doby, co jsou cgroup patche, potrebne k nabootovani ve vanille a ne jen v patchovanem Fedorim kernelu) a stale to nefunguje tak dobre, jako upstart drive. Syntaxe nastroju i kernel options je slozita, neintuitivni, ale co me nejvic vytaci, je nemoznost ovlivnit bootovaci proces a nejake moznosti recovery. Casto vidavam rescue mode misto bezneho bootu, nacez staci reboot beze zmen v systemu a ejhle, uz to nabehne v poradku. Naposledy jsem neco takoveho videl ve Windows 95. Ale taky pravda, ze vetsinou pouzivam (pouzival jsem) rawhide, sance na nabootovani do gdm byla takovych mizernych 20%.

[Tomáš Bžatek]

Zkratka na systemd je potreba jeste kopa prace a potrva nekolik let, nez se odvazim (predpokladam nedobrovolne) jej nasadit na sve produkcni masiny.

Systemd ma spoustu dobrych napadu a je urcite perspektivni, ale kvalita implementace pokulhava.

[little.owl]

Tak ja s tim souhlasim. Mne se plno napadu v nem libi, ale jeste to neni production ready a jeste nejakou dobu nebude, ale k tomu mame RHEL/CentOS/Debian Stable/Ubuntu LTS.

[Sten]

Tak teď už jenom chybí forknout udev a spojit ho s Upstartem a tenhle pekelný aprílový žertík bude dokonán. MUHAHA

[Franc]

Dobrý večer,

jsem pouhý uživatel a ještě k tomu Ubuntu, dokazal by mi někdo srozumitelně vysvětlit co je na tomto sloučení tak hrozného? Měl jsem za to, že udev (userspace devices) je démon který pomocí rozhraní jádra tuším netlink vytvaří zařízení v /dev (přípojim usb flash udev udev vytvoří /dev/sdx apod), což mi přijde více než dobrý nápad navzdory faktu, že dříve jsem musel mít /dev spousty souborů zařízení s jejich major a minor čísly, protože nikdo dopředu netušíl jak rozdělím disk, co si tam přípojím apod.

Podle mě je v tomto udev v podstatě špička ...

O systemd nevím skoro nic, k čemu je to dobré, co to řeší či nahrazuje?

Franc

[Migi]

proti udev tu nikdo nic nema, problem je to systemd, ktere nahrazuje Sys V init scripty -> tudíž mění zaběhnuté, funkční a lety ověřené řešení za něco nového (potenciálně) nestabilního.

My zakřiknutí uctívači všeho lety ověřeneho nemáme rádi systemd a proto se nam propojeni udev a systemd nelibi. Proto je taky dulezita ta poznamka o tom, že udev stale pujde sestavit i bez systemd (protože kdyby to nešlo tak jsme v loji).

Pokud o tom chceš vědět víc, tak zaskoč na Vyskočila do jeho seriálu O Systemd.

[Mordae]

Tohle nechápu. Init skripty jsou naprostá hrůza a systemd konečně přichází s decentním řešením. Místo toho, aby se lidé zaradovali, že konečně máme možnost kvalitního dohledu běžících procesů, aby byli rádi, že napsat službu se drasticky zjednodušilo, tak nadávají, že "se mění zaběhnuté".

[TM]

Mění se funkční, jednoduché a zaběhnuté za polofunkční nepřehledný bastl. Bohužel trend z desktopových prostředí začíná požírat i to co je pod nimi. Kdysi funkční a spolehlivý OSS pomalu ovládá smečka idiotů

[Martin Mareš]

Funkční to je jen tak napůl. Téměř všechny initscripty fungují jen na dobré slovo, protože v nich je spousta race conditions. Není zase tak řídký jev, že služba neběží, ale initscript si myslí, že běží, a nebo naopak nejde stopnout, protože si skript myslí, že už dávno neběží. Nedej Tučňák když chce někdo provozovat dvě instance jednoho daemona s různými konfiguracemi.

Neříkám, že se mi systemd líbí (mimo jiné proto, že ho ještě neznám natolik dobře, abych na něj měl pevný názor), ale SysV initscripty jsou ošklivá houština plná trní, kterou by jednou někdo měl rázně proklestit.

[little.owl]

A ted s vami souhlasim - v nazoru na SysV.

[Michal Kubeček]

Není zase tak řídký jev, že služba neběží, ale initscript si myslí, že běží, a nebo naopak nejde stopnout, protože si skript myslí, že už dávno neběží.

Obávám se, že v tom systemd moc nepomůže. Z diskuse na opensuse-factory listu např. vyplynulo, že systemd nabízí jen dva modely detekce toho, zda služba běží: (a) spustili jsme démona, takže dokud běží, služba běží, (b) systemd spustil službu, takže dokud ji neukončí, tak z definice běží. Na námitku, že jsou služby (namátkou třeba AppArmor, firewall nebo konfigurace sítě), pro které tohle nefunguje, a návrh, že by bylo vhodné přidat možnost specifikovat v konfiguraci příkaz, který otestuje, zda služba běží, se od věrozvěstů dostalo odpovědi, že to nepřichází v úvahu, protože to je prostě špatně navržená služba a tomu se systemd přizpůsobovat nebude. Pro srovnání: když je špatně detekce stavu služby v init scriptu, tak se prostě v tom init scriptu opraví status větev.

Právě tahle arogance vývojářů a evangelistů a představa, že celý svět je potřeba zplanýrovat podle jejich pravítka, je podle mne největším nebezpečím projektu.

[Lol Phirae]

možnost specifikovat v konfiguraci příkaz, který otestuje, zda služba běží, se od věrozvěstů dostalo odpovědi, že to nepřichází v úvahu, protože to je prostě špatně navržená služba a tomu se systemd přizpůsobovat nebude

No jistě, protože např. takoví vývojáři monitu jsou oproti Poetteringovi naprostí břídilové a pitomci, kteří nevědí, co dělají.

[l4m4]

protože to je prostě špatně navržená služba

S tím bych skoro souhlasil. Tedy ne špatně, ale bez reálné možnosti zjišťovat status.

Spustím firewall jako službu. Pak ručně (iptables ...) změním nějaká pravidla. Možná mírně upravím jedno, možná překopu všechna, možná cokoli mezi tím. Běží služba, nebo neběží?

U pseudoslužeb, které pouze něco nastaví, je detekce běhu většinou logicky nedefinovaná. Často by sice za cenu komplikovaných a křehkých skriptů šlo zkontrolovat, zda je jakási konfigurace stále přesně taková, jakou ji nastavilo spuštění té pseudoslužby, ale má to cenu dělat? Tedy je to skutečně to, co statutu očekáváme?

[Michal Kubeček]

Spustím firewall jako službu. Pak ručně (iptables ...) změním nějaká pravidla. Možná mírně upravím jedno, možná překopu všechna, možná cokoli mezi tím. Běží služba, nebo neběží?

Pokud si rozumně (myšleno naprogramovatelně) zadefinuji, co to pro mne znamená, pak si můžu napsat skript, který to zjistí. Tuto možnost mi ale systemd nedává (mohl by, ale autoři nechtějí). Klasický skript ano.

Často by sice za cenu komplikovaných a křehkých skriptů šlo zkontrolovat, zda je jakási konfigurace stále přesně taková, jakou ji nastavilo spuštění té pseudoslužby, ale má to cenu dělat?

Podle mne ano. Navíc ani u služeb, kde nějaký démon je, se nemusí otázka, zda je služba aktivní, nutně redukovat na pouhé zjištění, zda démon běží. Vezměte si třeba síťové rozhraní nastavené pomocí DHCP, kde se může stát, že démon sice běží, ale nedostal odpověď od serveru.

[tomasgn]

initscripty funguji tak dobre, jak jsou napsane. kdyz je nekdo zprasi, nemuze ocekavat dobrou funkcnost.

pri vychvalovani systemd jsem si vzpomnel na zavedeni SMF do Solarisu a vychvalovani, jak je to skvele, rychle a kdovicojeste; tento hnus spravovat je mnohem horsi opruz, nez poladit klasicky init skript. tam jsme taky nekolikrat videl, jak kvuli zavislostem a selhani nejake zanedbatelne sluzby system nenajel do funkcniho stavu, nacez nasledoval boj se SMF. s klasickymi initskripty by toto nenastalo, system by normalne nastartoval, nacez by stacilo umravnit jednu neposlusnou sluzbu ci jeji skript.

btw, nejak me ty systemd konfiguraky pripominaji win.ini.

[Milan Jurik]

SMF trpí tím samým co systemd. Minimálně ze dvou důvodů:

1) jeho architekt (Stephen Hahn) je podobného ražení co Lennart Poettering - velké myšlenky, sebestředný design, bídná implementace, ignorace oponentů, nezájem o další rozvoj a rychle vymýšlet něco v úplně jiné části systému.

2) oba systémy válčí s tím, jak dostatečně nasimulovat zprasený design init. Pro vás je možná init snadný a průzračný, jenže ve skutečnosti tam jsou hnusné okrajové případy, které se musí nasimulovat.

Vždy jsem měl neklidné spaní, když jsem musel do SMF kódu hrábnout.

[Martin Mareš]

initscripty funguji tak dobre, jak jsou napsane. kdyz je nekdo zprasi, nemuze ocekavat dobrou funkcnost.

Problém je, že shellovými prostředky se ty race conditions vyřešit nedají a běžnými nástroji typu start-stop-daemon také ne. V podstatě to znamená napsat ne zrovna triviální Céčkový wrapper. A pokud chcete automatický restart služby (ne každý o to stojí, ale někdy se velmi hodí), nezbývá, než aby ten wrapper pořád běžel.

[Martin Mareš]

Jen dodávám, že init-scripty, který by byly správně (nebo spíš ve kterých bych nanašel zjevnou chybu), jsem v životě viděl asi tak tři, a to jsem dva z nich napsal sám

Tohle ve skutečnosti není zrovna jednoduchý úkol a většina lidí si prostě spoustu možných problémů neuvědomuje a spokojí se s tím, že zbastlí něco, co v triviálních případech funguje.

[little.owl]

Restart sluzby je u systemd defaultne vypnuty a ja opravdu nevim proc je tu kolem toho takovy krik. Pouziva behove udalostim jako je exit(), abort() etc. a tim jsou jeho moznosti omezeny.

Napsat genericky softwarovy watchdog (wrapper) bez podpory aplikace je zatracene tezke, spise nemozne, takze je nezbyva nez cekat az applikace (daemons) zacnou systemd lepe podporovat a jako obvykle je zde urcite zpozdeni v userspace.

[tomasgn]

proc se vubec nejaky automaticky restart v systemd resi? init skripty maji zajistit spusteni nebo ukonceni sluzby podle daneho nastaveni. kontrola, zda sluzba spravne bezi, je ukol pro monitoring.

[pavlix]

proc se vubec nejaky automaticky restart v systemd resi?

IMO je to takový malý bonus, že si můžeš službu nechat restartovat při pádu.

Je mnohem jednodušší narychlo zapnout takovou direktivu v systemd, jehož úkolem je starat se o lokální služby, než stavět samostatný monitoring, který se bude pravidelně ptát systemd na to, jestli služba běží (případně pouštět jiné testy) a následně bude pomocí systemd službu restartovat.

Je to jednodušší jak pro administrátora systému, který prostě zkopíruje jeden soubor a připíše jednu direktivu, ale i z hlediska běhu.

[Petr Ježek]

Čím to je, že já v Archu žiju s initscripty v symbioze? :)

[Michal Vyskočil]

google: aristoteles jeskyně

[Nicky726]

Spíš Platon ne?

[Michal Vyskočil]

Je to možné, příště zkusím "starý řecký filozof jeskyně"

[kralyk z abclinuxu]

+1, Imho to, jak si tady někteří lidi myslí, že SysV je krásný, spolehlivý a čistý systém, je jen klamný dojem vyvolaný tvrdou prací maintainerů v distribucích, díky kterým ten bastl vůbec nějak funguje.

[kavol]

+1, Imho to, jak si tady někteří lidi myslí, že SysV je krásný, spolehlivý a čistý systém, je jen klamný dojem vyvolaný tvrdou prací maintainerů v distribucích, díky kterým ten bastl vůbec nějak funguje.

mně by jen zajímalo, čím je vyvolaný dojem některých jiných, že systemd je krásný, spolehlivý a čistý systém, když ten bastl mnohdy ani nefunguje ...?

btw, nějak nemám pocit, že by tu ten SysV někdo chválil tak, jak se snažíš tvrdit - ba právě naopak, mnozí jiní si myslí, že to není žádná sláva, a tak spáchali systémy jiné, zde též porůznu zmiňované ... kteréžto se ovšem nesetkaly s tak negativními reakcemi jak systemd, pokud je mi známo ... hm, čímpak to bude ...?

[pavlix]

btw, nějak nemám pocit, že by tu ten SysV někdo chválil tak, jak se snažíš tvrdit

To není o pocitech, stačí číst výše.

[kralyk z abclinuxu]

mně by jen zajímalo, čím je vyvolaný dojem některých jiných, že systemd je krásný, spolehlivý a čistý systém, když ten bastl mnohdy ani nefunguje ...?

Podobný argument jsem čekal, nicméně podívej se na to takhle: Problémy SysV doposud nikdo neřešil, krom Ubunťáků, kteří si udělali vlastní řešení, o kterým nevim, jak moc je použitelný mimo Ubuntu. Jinak ale nikdo nic moc, nebo jo? (Případné alternativy jsou ještě problémovější). A pak přijde Lennart se systemd a všichni to zkritizujou... Tady je něco špatně.

To je jako s alsou, alsa má řadu svých problémů. Osobně nemám PulseAudio rád, mam k němu mnohem horší vztah než k systemd, nadruhou stranu, kdyby už někdo problémy alsy řešil, nebyl by důvod pro vznik PulseAudia.

Jestliže někdo kritizuje systemd s tím, že přístup XY by byl lepší, tak to je trochu lichý argument, jestliže dotyčný nemá XY implementované. Na to už bylo času imho dost...

[little.owl]

Ubunti upstart je pouzitelny i mimo Ubuntu a Debian, jede na nem RHEL 6 ci jela pre-systemd Fedora.

[pavlix]

+1

[dustin]

Jaké konkrétní problémy alsy řeší pulseaudio? Snad možná názvy ovládacích prvků, ale i ty odhaduje. Přijde mi, že řeší oblasti, které alsa zatím neřešila (primárně dynamické nastavování latence pomocí časovačů). Jakmile to jeden ve vlastním procesu, je vše daleko snazší, než například mixování jenom knihovnou ala dmix.

[kralyk z abclinuxu]

System-wide equalizer a per-app volume setting, to jsou věci, co mi u alsy chybí. Ale jak říkám, pulseaudio nemusim. Nejrdaši bych OSSv4, jenže to zas nepodporuje suspend/resume :-/

[dustin]

System wide equalizer se řeší např. VST pluginy, volume setting per app tam nebyla, ale nebyl problém přidělat. Pro předem známou omezenou skupinu aplikací lze již dnes zařídit např. přes definici zařízení pro každou aplikaci se softvol pluginem, které vyúsťují do dmixu (pulseaudio taky musí mixovat). Samozřejmě to není tak pohodlné. To nebyly důvody, proč vyvíjeli pulseaudio, primárním cílem byl tzv. glitchfree playback http://0pointer.de/blog/projects/pulse-glitch-free.html

[kralyk z abclinuxu]

System wide equalizer se řeší např. VST pluginy, volume setting per app tam nebyla, ale nebyl problém přidělat. Pro předem známou omezenou skupinu aplikací lze již dnes zařídit např. přes definici zařízení pro každou aplikaci se softvol pluginem, které vyúsťují do dmixu (pulseaudio taky musí mixovat). Samozřejmě to není tak pohodlné.

No to není no, je to asi tak stejně pohodlné a příjemné, jako nainstalovat PA :-/

To nebyly důvody, proč vyvíjeli pulseaudio, primárním cílem byl tzv. glitchfree playback http://0pointer.de/blog/projects/pulse-glitch-free.html

Mně je to srdečně jedno, nemám PA rád tak jako tak...

[stativ]

Nejrdaši bych OSSv4, jenže to zas nepodporuje suspend/resume :-/

Takna to mám stejný názor. A věřím, že kdyby se ta práce, která byla potřeba na to dostat PA do jakš-takš použitelného stavu dala do práce na OSS, byl by tu funkční suspend mnohem dříve než funkční PA.

[Milan Jurik]

FYI, fork/rewrite OSS4 pro Solaris S&R zvládá, ale je fakt, že bylo potřeba udělat kus práce. Ale rozhodně méně a za kratší dobu než nekonečný film v podobě PA.

[kralyk z abclinuxu]

+1

[kavol]

Podobný argument jsem čekal, nicméně podívej se na to takhle:

sorry, ale asi na to nedívám dostatečně politicky:

Problémy SysV doposud nikdo neřešil, ...

vs

(Případné alternativy jsou ještě problémovější).

o jakých alternativách mluvíš, když to podle tebe nikdo neřešil?

A pak přijde Lennart se systemd a všichni to zkritizujou... Tady je něco špatně.

teď je jen otázka, zda je Lennart spíše jako Galileo, Newton nebo Bozo ...

že se Země přece točí ještě neznamená, že dav nemá nikdy pravdu

[pavlix]

že se Země přece točí ještě neznamená, že dav nemá nikdy pravdu

Dav pravdu obvykle nemívá. Už jenom to, že se dav vůbec shodne je podezřelé :). Samozřejmě, výjimky jsou.

[belisarivs]

Problémy SysV doposud nikdo neřešil, krom Ubunťáků

OpenRC

[mimi.vx]

mimo jine, nahrad SysV existuje celkem velka mnozina a podivny Upstart je jen jednim z mnoha ...

[Vskutečnosti Saýc]

Jake problemy ma sysvinit? "Neni to binarni blob podobny registrum z windows" bych nepovazoval za problem, restartovani spadlych sluzeb je vec kterou vyuzije opravdu malokdo, a jine problemy systemd moc neresi.

[Michal Kubeček]

Nemluvě o tom, že zrovna to restartování vlastně init umí. :-)

[pavlix]

Neni to binarni blob

Vykopej ze svého počítače všechny binárky a jsem zvědavý, co s ním pak budeš dělat :).

restartovani spadlych sluzeb je vec kterou vyuzije opravdu malokdo, a jine problemy systemd moc neresi.

Pokud se na to díváš tímhle způsobem, tak je odpověď velmi jednoduchá. Buď se musíš se systemd smířit, nebo používat distribuci, která na něm není závislá (a případně zajistit, aby závislá nebyla).

[kralyk z abclinuxu]

systemd přece není binární blob, není to o nic víc binární blob než jakýkoli jiný kompilovaný opensource. Jestli tím máš na mysli to, že SysV z vetší části skripty, tak to je naopak nevýhoda. SysV poskytuje naprosté minimum funkcí/featur, v podstatě jenom spouští procesy dle nějakého nastavení. Zkrátka SysV init je init, který když chce někdo používat, musí si ho nejdřív napsat v bashi. Takže bude vždycky jen tak schopný, jak schopné jsou tyto skripty.

No a jinak je například problém spouštět služby on-demand. Takže např. když chci tisknout, musím buď ručně zapínat/vypínat cups, nebo ho nechat puštěnej stále, ačkoli tisknu málokdy.

[pavlix]

Mimochodem, někdo mě teď upozorňoval na race spojený s asynchronním chováním příkazu IP, který se chová v podstatě libovolného init systému. Víš o tom něco, případně máš nějaký nápad jak to řešit jinak než nepoužíváním příkazu ip během initu?

[Martin Mareš]

Co konkrétně myslíš?

[Lol Phirae]

Že je hrozně nutné spojit iproute2 se systemd, protože networkd nám tady hrozně chybí. A když už jsme u toho, tak do toho zadrátujeme ještě networkmanager a půlku Gnome3, což je ostatně Jediné Správné Řešen황

[pavlix]

Že je hrozně nutné spojit iproute2 se systemd, protože networkd nám tady hrozně chybí.

S tímto tvým názorem nesouhlasím :).

A když už jsme u toho, tak do toho zadrátujeme ještě networkmanager a půlku Gnome3, což je ostatně Jediné Správné Řešen황

Spíš mi to přijde jako pěkná blbost :).

[little.owl]

SysV jiz davno narazil na sve limity a ja jsem spokojen, ze veci se posouvaji dopredu.

Polofunkcni neprehledny bastl?

Co vam konkretne vadi?

Dokumentace mi prijde zatim jako dobra a kod celkem prehledny.

Az se odladi problemy a lide se to nauci [s obvyklym kvicenim] dobre pouzivat, po SysV ani pes nestekne.

[ukos]

Až bude systemd fungovat aspoň z poloviny tak dobře, jako tvrdí píáristické dřísty fanatiků typu little.owla, tak uživatelé nebudou nadávat. Zatím všechny geniální funkce systemd zůstávají v poloze zbožných přání a vlhkých snů. Systemd nepozná, jestli mu služby běží, mrtvé považuje za živé a živé za mrtvé, spouští nesmyslný balast - podle rozhodnutí nějakého páprdy v redhatu, místo podle potřeby administrátora. Upravit to aspoň do trochu funkční podoby znamená reverzní inženýrství a hodně času (více než ladění sysV) a hlavně instalaci externího programu, který hlídá, zda služby skutečně běží - to je výhra!

[little.owl]

Tohle neni zadne PR, ale reakce na lidi, kteri systemd kritizuji aniz se obtezovali si projit manualove stranky. Tech dobrych napadu, ktere systemd prinasi je hodne a jako u kazde nove nasazene technologie jsou tam problemy.

[Petr Ježek]

Problémy typu nestabilní init nepovažuji za průvodní znak novinky, ale za nedomyšlený projekt. Dobrá myšlenka k přínosné praktické aplikaci jaksi nestačí.

[Lol Phirae]

+∞

Jenže tohle Lennarta a spol. nezajímá, jeho dalším cílem je znova nenávratně rozmrdat další věc v Linuxu, co na tom, že to nefunguje, to nikoho nezajímá.

[ukos]

+8

[little.owl]

Problémy typu nestabilní init

Je systemd nestabilni?

[Michal Kubeček]

Zjednodušilo se to jen v případě, že služba přesně zapadá do představy autorů systemd o světě a o tom, jak má služba vypadat. Jakmile z té představy z jakéhokoli důvodu vybočíte, jste na tom naopak daleko hůř. K tomu si přičtěte striktní odmítání tuto představu jakkoli rozšířit, odmítání kompatibility s jinými unixovými systémy (autoři například odmítají přijímat jakékoli patche, jejichž účelem je implementace na jiném systému než na Linuxu), podstatně větší složitost (a tedy i náchylnost k chybám), výrazně nižší flexibilitu, celkovou neprůhlednost a komplikovanější diagnostiku. A co za to dostanete? Možná o něco rychlejší boot (reálné výsledky nijak přesvědčivé nejsou) a stránku uměle vymyšlených "výhod" a featur pro featury. Děkuji, nemám zájem.

[little.owl]

podstatně větší složitost (a tedy i náchylnost k chybám)

C-kovy projekt s 3.5M zdrojaku vcetne prekladu a dokumentace bych za prilis slozity nepovazoval.

autoři například odmítají přijímat jakékoli patche, jejichž účelem je implementace na jiném systému než na Linuxu

Odmitaji, pokud by to znamenalo zavadet bolestive kompromisy. Ano, systemd je orientovan na Linux, autori to rikaji od sameho zacatku a maji pravdu v tom, ze start systemu je vec, ktera je proste silne zavisla na softwarove implementaci jadra. Forknout to mohou kdykoliv, je to GPL.

výrazně nižší flexibilitu

V nektere vech je mozna mensi flexibilita, u jinych vyrazne vetsi a architektura resi problemy, ktere SysV poradne resit neumel.

celkovou neprůhlednost

Dokumentace je pomerne velmi dobra a kod je diky nove code base jeste celkem prehledny.

uměle vymyšlených "výhod" a featur pro featury

Precetl jste si nekdy seznam veci, ktere to prinasi a resi? Pochybuji. Vazne si myslite, ze ostatni distribuce, ktere po tom po Fedore sahli ridi jen pitomci? Nakonec zustane mimo jen Debian kvuli FreeBSD kernelu a mozna i Ubuntu, ale tam uz to ted take vypada nejiste.

[Honza Jaroš]

Nakonec zustane mimo jen Debian kvuli FreeBSD kernelu a mozna i Ubuntu, ale tam uz to ted take vypada nejiste.

Uff, za připomenutí BSD kernelu v Debianu díky, klasický init mi tedy alespoň na serverech zůstane...

[little.owl]

Ale s FreeBSD kernelem!

Enjoy, verim init system bude posledni, co budete muset resit

[petr_p]

Ale no tak. System V init a systemd nejsou jediné inity. Třeba OpenRC oficiálně podporuje jak Linux, tak i FreeBSD. Umí závislosti, umí paralelní spouštění, umí restartování a přesto jednotlivé služby jsou definovány skriptem, nikoliv deklarativní šablonou, která není schopna pojmout všechny případy.

[Honza Jaroš]

To jako že si budou paralelně udržovat dva init systémy? Nestrašte!

[pavlix]

Tak dalo by se to vyřešit tím, že by se systemd a freebsd skamarádili, ale to sbližování bude asi dost práce.

[Mrkva]

C-kovy projekt s 3.5M zdrojaku vcetne prekladu a dokumentace bych za prilis slozity nepovazoval.

Můj !funkční! init systém v bashi měl pár řádků a fungoval spolehlivě, proti tomu je těch 3.5MB zdrojáků fakt šílený moloch. Proč to sakra závisí na D-busu!?

maji pravdu v tom, ze start systemu je vec, ktera je proste silne zavisla na softwarove implementaci jadra

Ale no tak, fsck, remount read-write, spuštění daemonů a getty že je nějak extrémně systémově závislé?

Když koukám na ty featurky systemd, nechápu proč je kolem toho takový povyk. Na většinu implementovaných věcí tu už dávno existují funkční řešení, ať už v podobě věcí jako inetd nebo samostatných init skriptů. Opravdu by v init démonovi měla být řešená podora pro specifické úlohy jako LUKS? Pro nahození loopbacku? Pro obsluhu fsck? Natahování jaderných modulů?

Automatické restartování služeb je naprostá hovadina. Když má něco problémy, je potřeba to opravit a ne dokolečka restartovat a dělat že se nic neděje. Naopak, pokud se jedná například o útok na nějakou zranitelnost, je žádoucí službu nerestartovat a nejdřív opravit.

Závislosti mezi jednotlivými službami? Není náhodou /etc/rcn.d/Sxxjmeno přehlednější?

Na řešení problémů s autofs se vyloženě těším.

To, že je polovina systemd je nacpaná v /usr je už jen třešnička na dortu.

Fuj, to jsem se zas nasral.

[little.owl]

Můj !funkční! init systém v bashi měl pár řádků a fungoval spolehlivě, proti tomu je těch 3.5MB zdrojáků fakt šílený moloch. Proč to sakra závisí na D-busu!?

Tak k tem par radkum pridejte velikost zdrojaku bashe a initd a dalsich desitek externich programu, ktere budete potrebovat k ziskani obdobne funkcionality a pak muzem srovnavat a najednou zjistite, ze 3.5M vcetne prekladu neni tolik a hlavne je to konzistentni a zdokumentovane.

Proc D-Bus? Pokud chcete implementovat neco jako "transactional dependency based service control logic" (uz nevim jak to rici cesky), pak potrebujete v ramci systemu komunikovat pres sbernici a proc nevyuzit D-Bus, kdyz uz tu je a etablovan?

Automatické restartování služeb je naprostá hovadina. Když má něco problémy, je potřeba to opravit a ne dokolečka restartovat a dělat že se nic neděje.

Automaticky restart je jen tresnicka na dortu, kterou muzete a nemusite pouzit a muzete nastavit podminky za jakych se to stane. Tam jsou i jine hezke veci - konecne poradne parallelizace ktera bere v potaz HW, snapshoty a jejich restore, on-demand start daemonu, socket a D-Bus aktivace startu sub-systemu, sprava (auto)mountovacich bodu, pouziti cgroups atd.

Závislosti mezi jednotlivými službami? Není náhodou /etc/rcn.d/Sxxjmeno přehlednější?

Neni, casto je to pekny bordel skriptu a nastroju nekompatibilnich napric linuxovymi distribucemi a hlavne to ale neresi behove zavislosti mezi sluzbami za behu, za startu ci vypinani.

To, že je polovina systemd je nacpaná v /usr je už jen třešnička na dortu.

Za chvili tam bude skoro vsechno a zbytek jen symbolicke linky.

Fuj, to jsem se zas nasral.

Tak to me tesi . Nachapu tu paniku zde, OSX ma launchd roky a lide vcetne profesionalnich adminu jsou s tim spokojeni, cpou to i na FreeBSD a tady to vypada po prichodu systemd nastane konec sveta.

Modleme se pratele, prichazi Satan.

[Mrkva]

Pokud chcete implementovat neco jako "transactional dependency based service control logic" (uz nevim jak to rici cesky), pak potrebujete v ramci systemu komunikovat pres sbernici a proc nevyuzit D-Bus, kdyz uz tu je a etablovan?

Hmm, problém je v tom, že nechci... Rozhodně ne za cenu kdy to bude viset na desktopovém molochovi. Sakra, tohle je init systém, to má být co nejjednodušší aby bylo co nejmíň prostoru pro to, že se systém vys... a nenaběhne.

Tam jsou i jine hezke veci - konecne poradne parallelizace ktera bere v potaz HW, snapshoty a jejich restore, on-demand start daemonu, socket a D-Bus aktivace startu sub-systemu, sprava (auto)mountovacich bodu, pouziti cgroups atd.

Paralelizace je fajn, ale tak nějak pochybuju že bude mít rozumný praktický přínos. o tom, že s autofs bude sranda jsem se už zmiňoval. Ondemand start služeb je taková polovičatá věc. Jo, když někdo dělá v PHP ocení že se mu Apache a MySQL na desktopu nastartuje až když si na to poprvé sáhne, na serverech to je ale zbytečnost.

Neni, casto je to pekny bordel skriptu a nastroju nekompatibilnich napric linuxovymi distribucemi

A tak přidáme další s ostatními nekompatibilní nástroj! To je fakt výhra :)

Za chvili tam bude skoro vsechno a zbytek jen symbolicke linky.

Takže bez připojeného /usr nenabootuju. Super.

[pavlix]

Takže bez připojeného /usr nenabootuju. Super.

Nevidím v tom žádnou velkou změnu. Stále jde nainstalovat systém tak, aby nabootovat šel bez initrd, stále jde nainstalovat systém tak, aby šel nabootovat se samostatným /usr, a obojí dohromady, což stejně už moc nefungovalo, je alespoň oficiálně nepodporované :).

Kdyby usrmove neproběhl, nic zvláštního by se nestalo. Když proběhl, tak taky nic. Neškodné zpřehlednění filesystému :).

[Miška]

Můj !funkční! init systém v bashi měl pár řádků a fungoval spolehlivě, proti tomu je těch 3.5MB zdrojáků fakt šílený moloch. Proč to sakra závisí na D-busu!?

Tak k tem par radkum pridejte velikost zdrojaku bashe a initd a dalsich desitek externich programu, ktere budete potrebovat k ziskani obdobne funkcionality a pak muzem srovnavat a najednou zjistite, ze 3.5M vcetne prekladu neni tolik a hlavne je to konzistentni a zdokumentovane.

busybox tarball ma 2,1M a nemam jen to co potrebuju k initu, ale i mdev (ok, systemd ted bude mit v sobe udev) a zaklad systemu. A ty utility co potrebuju v klasickejch init scriptech potrebuju v systemu tak jako tak, protoze se pak pouzivaj, hmm, vsude?

[little.owl]

Psal jsem:

ktere budete potrebovat k ziskani obdobne funkcionality

A to busy box nezajistuje.

[Vskutečnosti Saýc]

Ale kdyz tu funkcionalitu clovek nepotrebuje, je to trochu podivne srovnani.

[little.owl]

Pokud ji nepotrebuje, tak at ji nepouziva, stale tu jsou tu minoritni alternativy.

[Vskutečnosti Saýc]

Vzhledem k tomu, ze se mluvi o mnozstvi zabraneho mista a slozitosti zpusobene velkymi zdrojaky mi neni jasne, jak nepouzivani pomuze.

[Lol Phirae]

stale tu jsou tu minoritni alternativy.

Rozumím, takže ultimátních cílem vás magorů kolem Poetteringa je dohnat co nejvíc lidí k návratu na stromy, busyboxu a spol. No bravo!

[little.owl]

Naopak, dostat vas z tech stromu dolu!

Vazne, pouzivejte si co chcete.

[ukos]

Bože můj, co vy jste to za člověka! Já tedy, když mi padesát lidí dobrými argumenty vyvrací můj názor, tak použiju mozek a pokusím se přehodnotit svá stanoviska. Protože jinak jsem buď a)geniální nebo za b) trpím bludem. A věřte mi, ani já, ani vy geniální nejsme...

Mohu vám dát půl tuctu zdokumentovaných příkladů z poslední doby, kdy hujerský fanatismus lidí kolem redhatu/fedory zničil pod heslem "lepší a modernější" fungující věci - bez náhrady. RadHat nabral naprosto nezkušené programátory z ulice (mne se snažili zlanařit taky a ti mají kromě vizí hovno...

[little.owl]

Bože můj, co vy jste to za člověka!

Diky, ze jste se udrzel na uzde.

Já tedy, když mi padesát lidí dobrými argumenty vyvrací můj názor, tak použiju mozek a pokusím se přehodnotit svá stanoviska. Protože jinak jsem buď a)geniální nebo za b) trpím bludem. A věřte mi, ani já, ani vy geniální nejsme...

Nemam problem se nechat poucit ze zkusenosti a chyb jinych. Nicmene nechat se ovlivnovat lidmi, kteri se nedostali ani tak daleko aby spustili man systemd, predtim nez zacnou siril bludy, se nehodlam, to je trochu davova psychoza.

Systemd jsem zacal pouzivat az v dobe kdy pocet bugu v bugzille zacal ukazovat, ze je to jiz pouzitelne a nastudoval jsem si nejakou dokumentaci, mam tedy praktickou zkusenost. Zatim zadny zasadni problem, veci vicemene funguji a dlouhodobe benefity spise prevazuji.

Takovou situaci jsem jiz zazil v minulosti u jinych casti systemu, neco prezilo, neco nikoliv, takze je treba povyk brat s rezervou, cas ukaze.

Mohu vám dát půl tuctu zdokumentovaných příkladů z poslední doby, kdy hujerský fanatismus lidí kolem redhatu/fedory zničil pod heslem "lepší a modernější" fungující věci - bez náhrady. RadHat nabral naprosto nezkušené programátory z ulice (mne se snažili zlanařit taky a ti mají kromě vizí hovno...

Zkusenost je dulezita a z nezkusenych lidi budou jednou stari borci. Navic si nemyslim, ze Red Hat neposloucha sve zakazniky, zamestnava hloupe lidi a dela z tupcu system architekty, Lennart jim rozhodne neni.

[Bubak]

Nemyslim si, ze treba Mrkva se neobtezoval podivat, o cem ze se to mluvi. A mluvi i za me.

[kavol]

Zkusenost je dulezita a z nezkusenych lidi budou jednou stari borci.

je tu jen takový malý problémek, že lidi ten software potřebujou používat teď, a ne léta čekat, až z mladých borců budou ti staří zkušení, kteří to už konečně naprogramují pořádně - navíc ti staří borci obvykle odchází na jiné pozice a kód zase táhnou do prdele ti mladí hujeři ...

[pavlix]

Člověče, to se máš na co těšit :).

[little.owl]

Od toho je deleni na Junior a Senior programatory, mentoring a code review.

[kavol]

Od toho je deleni na Junior a Senior programatory,

jistě, pozná se to na výplatní pásce

mentoring a code review.

MUHEHE

[little.owl]

jistě, pozná se to na výplatní pásce

To se pozna hlavne v praxi na vyslednem kodu a architekture.

Platova politika firem a system odmenovani je vec uplne jina.

[Miška]

Funkcionalita, kterou ma smysl od initu pozadovat, je ze nabootuju a sluzby co chci mi bezi, ne? Na to busybox staci. Piskvorky si pustim az potom

[tomo_tn]

Dobry, osobne som postavil linux based system, ktory bezi iba z kernelu o velkosti cca 8mb. Funguje v nom mdev, spusta sa cez init scripty a bootuje tak do 5 sekund (intel atom) s tym ze poziada dhcp o IP, bez siete to boli rovne 4.

Niektore busybox nastroje su koli jednoduchosti programovania zamenene za plnohodnotne GNU verzie (nechcelo sa mi hladat nekompatibility). Mimochodom to znamena ze to zo sebou nesie i glibC.

Tymto chcem poukazat na to ze bootovat sa da sakra rychlo i cez sysV aj ked poupraveny, ale hlavne je to ze to ide jednoducho a pravdepodobne na mensom place ako 3.5MB src + dbus.

Momentalne to facha na bash-i ale cele to "prekopem" pre dash cim sa cely system este zmensi a zrychli - pokial sa nemylim bash mam vybuildeny staticky a ma okolo 700kb.

Pre pripadnych testerov : http://www.pacman.linuxd.org/files/pacman_installer_kernel

alebo boot cd :

http://www.pacman.linuxd.org/files/installer.iso

[Petr Ježek]

Mám pocit, že se chlapci prostě rozhodli udělat to lépe a po svém, aniž by se informovali na jiná osvědčená řešení. V Archu mám ověřené, že Systemd nic nepřináší a působé problémy. Není divu, když má Arch BSD-like init scripty a udev v rc.conf detekuje a startuje vše potřebné, a to RYCHLE! Opravdu mi Systemd nepřijde jako obecně výhodné řešení initscriptů v linuxu.

[mirec]

Ja mám v práci arch, nespúšťa sa ktovie ako pomaly, ale nejaký zázrak to nie je. Vypínanie sa z nejakého dôvodu zasekne, ale tvrdý reset raz mesačne keď aktualizujem kernel zase až tak nevadí. Doma gentoo na niekoľkonásobne slabšom stroji nabieha asi 1/4 času a dokonca bez problémov.

[Michal Kubeček]

celkovou neprůhlednost

Dokumentace je pomerne velmi dobra a kod je diky nove code base jeste celkem prehledny.

Nemluvím o neprůhlednosti kódu, mluvím o neprůhlednosti procesu bootování. Když je něco špatně s init scriptem a nevím, co se tam přesně děje, tak do specifikace interpreteru přidám -x a mám jasno. U systemd můžu nanejvýš spoléhat na strace a to jsem někde úplně jinde. Když chci démona jakkoli ovlivnit (ve stylu nastavení proměnných prostředí, resource limitů, chrootu, CPU afinity atd.), přidám to do init scriptu; u systemd jsem omezen tím, s čím autoři počítali a co do systemd implementovali. Je to vlastně dost podobné rozdílu mezi textovými konfiguračními soubory a nástrojem typu YaST.

uměle vymyšlených "výhod" a featur pro featury

Precetl jste si nekdy seznam veci, ktere to prinasi a resi?

Samozřejmě že četl. Tohle je komentář právě k tomu seznamu. Pravda, neúplný: ještě jsou tam featury, které ve skutečnosti nabízí i normální init (nebo je lze do init scriptů snadno doplnit), a featury, které ve skutečnosti nenabízí ani systemd.

Vazne si myslite, ze ostatni distribuce, ktere po tom po Fedore sahli ridi jen pitomci?

Nevím jak to bylo u ostatních, ale v případě OpenSuSE to bylo v podstatě proto, že ji de facto neřídí nikdo, takže dostatečně aktivní a agresivní jedinec je schopen prosadit i takovouhle šílenost, protože ho nikdo včas nezastaví. Navíc Frederic Crozat i jinak konzistentně ukazuje, že jakmile cokoli přijmou ve Fedoře, je to podle něj automaticky důvod udělat totéž bez přemýšlení i v OpenSuSE.

Nakonec zustane mimo jen Debian kvuli FreeBSD kernelu a mozna i Ubuntu, ale tam uz to ted take vypada nejiste.

Nepředbíhal bych událostem. Zatím se přinejmenším podařilo prosadit zachování System V initu v OpenSuSE 12.2 (což původně v plánu nebylo) a uvidíme, jak to bude dál.

[little.owl]

ovlivnit (ve stylu nastavení proměnných prostředí, resource limitů, chrootu, CPU afinity atd.), přidám to do init scriptu;

Temer vse, co jste zminil lze u systemd nastavit, viz man systemd.exec: RootDirectory, CPUAffinity, Environment, ControlGroup ... a vsechno to je jen jedna line v konfiguraku. Pokud to budete chtit udelat ve skryptu intstalujete dalsi nastroje a vysledkem je system komplexnejsi nez systemd.

u systemd jsem omezen tím, s čím autoři počítali a co do systemd implementovali.

Vzdy existuji nejaka omezeni.

[Michal Kubeček]

ovlivnit (ve stylu nastavení proměnných prostředí, resource limitů, chrootu, CPU afinity atd.), přidám to do init scriptu;

Temer vse, co jste zminil lze u systemd nastavit, viz man systemd

Ach jo. Vždyť výslovně píšu, že problém je právě v tom, že jsem odkázán jen na to, co autoři systemd (kteří mimochodem nejsou zrovna moc nakloněni nápadům, se kterými nepřišli sami) uznají za vhodné implementovat. U klasického skriptu takhle omezen nejsem.

[little.owl]

To je komicka situace.

Autori daemonu se leta vymlouvali, ze nektere veci nemohou proste resit, protoze na Linuxu neexistuji unifikovany framework a ted kdyz maji neco, co se tomu blizi, tak pro zmenu uzivatele rvou, ze je to omezuje.

V praxi to bude omezovat jen velmi malou skupinu uzivatelu vyzadujicich velmi specificke reseni, ti si budou muset najit jinou cestu a ja se nebojim, ze si ji nenajdou i v ramci systemd.

[Bubak]

Me se spis systemd zda jako velmi specificke reseni pro uzkou skupinu... No co, mozna se ty desktopy taky rozsiri

[pavlix]

+1

A na servery a embedded zařízení, že. Pěkná byla přednáška na Embedded Linux Conference Europe v Praze od Koena Kooi od distribuce Ångström, jejíž název byl „Integrating systemd: Booting Userspace in Less Than 1 Second“.

[little.owl]

Ano, v Ångström to bude asi pouzivat jako moznost, coz jako jeho uzivatel vitam.

[Lol Phirae]

Jásat nad tím, že někdo bude rvát tenhle shit na embedded zařízení, to už fakt hraničí s Chocholouškem.

[little.owl]

Prekvapive embedded systemy jsou to cim se zivym a problem v tom nevidim; rychle loadovani image z flash pro ruzna jadra a jejich synchronizace po startu je slusny problem.

[kralyk z abclinuxu]

Jásat nad tím, že někdo bude rvát tenhle shit na embedded zařízení, to už fakt hraničí s Chocholouškem.

Nechat embeded zařízení zpracovávat tuny bashe ti přijde o hodně lepší?

[Lol Phirae]

Busybox na embedded zařízeních mi opravdu přijde o hodně lepší, než takhle lennartovina.

[little.owl]

Busybox je fajn, ale celou rady veci neresi a zejmena cross synchronizaci heterogennich SoC jader si dela kazdy sam a je v tom slusny binec a zadna unifikace. Lennartuv kod bych primo bez refactoringu nepouzil, ale zakladni princip je dobry. Vy muzete treba unitu pres jednoduchou binarku spojit s HW spinlockem, nastavit dependency a mate vystarano a zbytek muze zustat jak je.

[kralyk z abclinuxu]

A to proč? Teda kromě toho, že je systemd od Lennarta, což je zde asi nejvíc kritizovaná vlastnost

U busyboxu zase platí to, co u tradičního SysV initu: bude jenom tak efektivní a tak dobrý, jak dobré a efektivní jsou init skripty a jejich zpracování. Takže imho bez nějaké konkretizace se to těžko porovnává...

[pavlix]

A to proč? Teda kromě toho, že je systemd od Lennarta, což je zde asi nejvíc kritizovaná vlastnost

Asi tak :).

[Michal Vyskočil]

Vždyť výslovně píšu, že problém je právě v tom, že jsem odkázán jen na to, co autoři systemd (kteří mimochodem nejsou zrovna moc nakloněni nápadům, se kterými nepřišli sami) uznají za vhodné implementovat.

Možná sleduji špatnou systemd-devel konferenci, ale rozhodně tento dojem nemám.

U klasického skriptu takhle omezen nejsem.

U systemd taky ne. ExecStart= pustí libovolnou binárku, tedy i skript-dělající-potřebnou-magii-před-spuštěním-démona.sh. Jediná práce navíc oproti sysvinit je potom nastavit jednotku tak, aby byl systemd schopen sledovat stav spuštěného procesu. Těžko argumentovat, že u sysvinit se to dělat nemusí, když sledování stavu u sysvinit (ne)funguje na dobré slovo.

Popravdě mě není jasné, jak jinak by se měla řešit situace, kdy je v jednotce nastavení, pro které není v systemd patřičný protikus (třeba v případě, kdy máme novější jádro a starší systemd).

[little.owl]

Možná sleduji špatnou systemd-devel konferenci, ale rozhodně tento dojem nemám.

Souhlas, zatim jsem na zasadni omezeni nenarazil, i kdyz muze byt, pokud se pouzivaji nejake okrajove techniky.

U systemd taky ne. ExecStart= pustí libovolnou binárku, ...

Proboha, jak muzete po lidech chtit spustit man systemd.exec ... ?!

máme novější jádro a starší systemd

Tohle je jeden z duvodu, proc systemd je Linux centric, ta vazba tam je a bude silna. Na stranu druhou budou asi muset jako kernel dbat na kompatibilitu.

[Michal Vyskočil]

Proboha, jak muzete po lidech chtit spustit man systemd.exec ... ?!

Tak já bych se u Michala neodvážil tvrdit, že neumí číst manuálové stránky. Zvláště v případě, že sedí jenom o kancelář vedle

Já spíš myslím, že ta nechuť pramení spíše z pocitu je to všechno blbě/složité. A druhak také ze sledování ne příliš relevantních zdrojů, jako je $distribuce-devel, nebo třeba abclinuxu.cz, kde se člověk o systemd občas dozvídá věci, které v dokumentaci rozhodně nevyčte

[little.owl]

To nebylo ani cileno na nej, nebot on argumentuje pomerne racionalne a jak vim i z jinych diskuzi i vecne.

Ja jsem zaujimal podobny postoj predtim, nez jsem si nasel cas si o systemd neco precist - to trvalo docela dlouho - a pak jsem ho vzal na milost a ted si mi spise libi.

[pavlix]

Ja jsem zaujimal podobny postoj predtim, nez jsem si nasel cas si o systemd neco precist - to trvalo docela dlouho - a pak jsem ho vzal na milost a ted si mi spise libi.

+1

I když faktem je, že na nějaký slušný paralelní boot už jsem čekal dost dlouho.

[kavol]

Vždyť výslovně píšu, že problém je právě v tom, že jsem odkázán jen na to, co autoři systemd (kteří mimochodem nejsou zrovna moc nakloněni nápadům, se kterými nepřišli sami) uznají za vhodné implementovat.

Možná sleduji špatnou systemd-devel konferenci, ale rozhodně tento dojem nemám.

žádnou systemd konferu nesleduju, dojem shodný s kolegou jsem získal z bugzilly, když jsme narazili na problémy s naší databázovou testsuitou, dík kterým jsem se dozvěděl, že dovolit nějaké uživatelské akce, hm, to prostě neexistuje, tady je seznam podporovaných blbostí a přes to nejede vlak, i kdyby to požadovali všichni autoři/správci/uživatelé všech démonů

možná by tedy neškodilo vytáhnout občas hlavu z Lennartovy prdele a rozhlídnout se po realitě ...

[Lol Phirae]

dovolit nějaké uživatelské akce, hm, to prostě neexistuje, tady je seznam podporovaných blbostí a přes to nejede vlak, i kdyby to požadovali všichni autoři/správci/uživatelé všech démonů

Blázníš? Moc funkcí by mohlo zmást vývojáře.

[Michal Vyskočil]

Už tomu rozumím - na systemd-devel je totiž standardní dotaz typu "mám skript dělající tuto magii, a nevím jak to napsat pro systemd. Poradíte mi?". Pokud bugzilla vypadá stylem Lennarte, ty idiote, jaktože ten tvůj z***ný systemd neumí spouštět skripty s vlastními argumenty, ani se nedivím, že se naše pohledy na něj tolik liší.

Jinak pro skripty s vlastními argumenty v openSUSE existuje workaround SYSTEMD_WRAP_NO=true /sbin/service init-skript vlastní argumenty. Ten spustí init skript přímo z shellu, se všemi důsledky.

Správné řešení z pohledu systemd by asi bylo rozsekat to na několik service jednotek - třeba testsuita-deploy.service, testsuita-run.service a ty pospojovat závislostmi, aby se -run spustilo až po -deploy. Ovšem přesné řešení silně závisí na konkrétních požadavcích.

možná by tedy neškodilo vytáhnout občas hlavu z Lennartovy prdele a rozhlídnout se po realitě ...

Lennart je mi buřt, ale systemd se mi líbí.

[kavol]

Správné řešení z pohledu systemd by asi bylo ...

přečti si to po sobě znovu

a ještě jednou

do třetice ... už to vidíš?

rozsekat to na několik service jednotek - třeba testsuita-deploy.service, testsuita-run.service a ty pospojovat závislostmi, aby se -run spustilo až po -deploy. Ovšem přesné řešení silně závisí na konkrétních požadavcích.

ok, mám požadavek, aby mi service služba usage řeklo, co daná služba podporuje - jak mi jej splní tvoje "správné řešení"?

Lennart je mi buřt, ale systemd se mi líbí.

potíž je, že to nejsou dvě věci na sobě nezávislé

samotný systemd, jako základní myšlenka, nemusí být špatný, raděj nehodnotím, tolik do toho nevidím - bohužel, základní myšlenka je jedna věc, a implementace je věc druhá: špatný je především přístup autorů, jak zde již bylo několikrát řečeno, vpodstatě bych mohl zopakovat akorát to, co říká Michal Kubeček o "buldozeru"

[little.owl]

Naopak, jasna specifikace pozadavku na iterface je krok kupredu.

[kavol]

Naopak, jasna specifikace pozadavku na iterface je krok kupredu.

nepatřilo to pod jiný příspěvek?

[anonym]

init skripty jsou krasne a funkcni, kdyz se udelaji dobre (viz gentoo s openrc)

systemd je mozna hezka hracka na desktop, ale opravdu si nechci na server cpat kraviny jako dbus, jen protoze nekdo vymyslel ze systemd je to nejlepsi reseni

[Ivan]

Tohle taky nechapu. Opravdu je nutny mit na serveru stejny boorovaci proces jako ne desktopu? A co mobilni zarizeni? Co kdyby jsme pouzili na serverech bootovaci process z androidu? To ze systemd umi paralelni boot me nezajima, servery bootuji parkrat do roka, a popravde nikoho nezajima jestli ma server downtime 2 anebo 3 minuty.

Ze vsech mych Linuxu nejdele bootuje muj notebook s Ubuntu. Pri kazdym rebootu musim 2 minuty cekat na nekej "*****" dbus timeout. Zkousel jsem vsechy triky popsany v tyhle chybe, ale nic nepomohlo: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/811441 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/886414

[tomasgn]

servery bootuji parkrat do roka, a popravde nikoho nezajima jestli ma server downtime 2 anebo 3 minuty.

navic u vetsich systemu je udajne zdrzeni shellovymi skripty naprosto zanedbatelne, protoze nejvic casu zabere inicializace zarizeni (desitky disku, volume group, filesystemu, ...) a startovani samotnych aplikaci.

pocitace jsou stale rychlejsi, ale nekdo ma potrebu start jeste vice urychlit. mozna proto, ze se do startovaciho procesu vloudily nove soucasti, jako dbus, avahi, console-kit, pulse-audio a podobne. pak je tedy nutno vynalezt novy zpusob startovani, aby se zdrzeni nekde vyrovnalo a zase si zoufalci mohli pomerovat pindika ("muj notebook startuje rychleji, hec").

[j]

tak tak, nemluve o tom, ze pokud se mi stalo, ze neco nefungovalo, tak oprava toho scriptu byla tak na 1/2 hodky (z cehoz 90% casu trvalo zkoumani, kde to je blbe). Nesnasim neopravitelny binarni bloby ...

[pavlix]

Oprava systemd unity mi obvykle nezabere přes půl minuty, což je oproti půl hodině docela úspěch :).

[chrono]

Netuším, čo je na init skriptoch tak strašné, každopádne z vlastnej skúsenosti viem, že opraviť init skripty je neporovnateľne jednoduchšie, ako opravovať nefunkčný systemd. :)

[ukos]

+1

[pavlix]

opraviť init skripty je neporovnateľne jednoduchšie, ako opravovať nefunkčný systemd. :)

Tak ono by bylo slušné porovnávat opravování systemd když už tak alespoň se sysvinitem samotným. A opravu mnohořádkových initscriptů pak porovnávat s opravou pětiřádkových unit souborů, že?

[little.owl]

+1

[trekker.dk]

Místo toho, aby se lidé zaradovali, že konečně máme možnost kvalitního dohledu běžících procesů

To už máme dávno - runit. Stabilní, funkční, ověřené.

[rastos]

Init skripty jsou naprostá hrůza a systemd konečně přichází s decentním řešením.

Kedysi som uvažoval o tom, že pre neznalých napíšem článok o tom, ako bootuje systém. Ale potom si hovorím - veď je to primitívne: Bios spustí boot loader (LILO), ten natiahne jadro, jadro spustí proces s číslom 1 - init, ten sa pozrie do /etc/inittab, tam nájde, do ktorého runlevelu má nabootovať a ktorý skript má spustiť. A ten skript postupne pospúšťa nejaké systémové démony, nastaví sieť, pospúšťa sieťové služby a na koniec pustí nejaký X login manager. Načo taký článok, čo sa dá napísať na 3 riadky?

Lenže nedávno som zistil, že Ubuntu nemá /etc/inittab, že Gentoo boot skripty nie sú interpretované sh shellom a ktovie čo ešte iné (ne)funguje na iných "moderných" distribúciách. Našťastie môj obľúbený Slackware má ešte toľko rozumu, aby sa nevydal touto cestou (alebo je len príliš pomaly updatovaný na to, aby to bolo na ňom poznať). Btw, ten horeuvedený popis bol celkom dobre aplikovateľný aj na BSD, HP-UX, OSF-Unix, SCO-unix, Solaris a čojaviemčoešte.

Chcel som vlastne povedať, že situácia bola taká, že postup bootovania sa od stavu jednoduchého, zrozumiteľného, ľahko modifikovateľného a debugovateľného (a pripúšťam, že možno nie najefektívnejšieho) presúva do stavu, v ktorom sa ani čert nevyzná.

[Martin Mareš]

To je smutná pravda ... ale přijde mi, že lví podíl na tom zmatku (a obtížné debugovatelnosti všeho, co se při bootu děje) má initrd.

[pavlix]

Gentoo bylo jedno z úplně prvních a jeho init systém je mírně řečeno geniální.

[little.owl]

Nepouziva Solaris nahodou uz SMF, tedy neco jako systemd?

[to som ja]

http://fedora.cz/fedora-16-release-party-dalsi-prednaska-systemd/ http://lvb.sti.fce.vutbr.cz/public/LinuxAlt_2011/2011_11_05_LA_02_Systemd/2011_11_05_LA_02_Systemd.pdf

[Jiří J.]

Rád používám takovou analogii klasických init skriptů versus systemd - je to jako textové konfiguráky versus registr systému Windows.

Textový konfigurák není zdaleka tak jednodušše čitatelný programem, který v něm navíc nemůže dělat (snadno) za běhu změny, transakce, redundantní záznamy na různých koncích disku -- to vše binární registrový soubor (databáze) umí. Podobně třeba logování do databáze - možnost filtrace podle různých kritérií, daleko flexibilnější, než grep na .log soubor.

Proč se tedy pořád používají textové konfiguráky? Protože jsou snadno čitelné / upravitelné člověkem, a to pomocí prakticky jakéhokoli textového editoru, ne specializované (jednoúčelové) binární utility. Stejně tak by se pro-systemd lidé měli zamyslet, zda opravdu chceme nový "inteligentní" init systém s vlastní syntaxí konfiguračních souborů, anebo doladíme ne-úplně-dokonalý systém shellových init skriptů (které na Debianu používají dash místo bashe, jsou tedy už tak docela rychlé a nenáročné), které teoreticky mohou poskytnout větší flexibilitu.

A některé featury systemd mi přijdou spíše na škodu - automatický restart sestřeleného daemona, aniž by systemd věděl důvod sestřelení. Představte si situaci 4 nenažraných daemonů, které OOM pořád dokola killuje a systemd restartuje.

[little.owl]

automatický restart sestřeleného daemona, aniž by systemd věděl důvod sestřelení. Představte si situaci 4 nenažraných daemonů, které OOM pořád dokola killuje a systemd restartuje

Muzete to snadno kontrolovat. Sekce Service, parametr Restart. Napisete do konfiguraku sluzby neco jako:

[Service]
Restart=_an_option_

kde _an_option_ je on-success, on-failure, on-abort nebo always a defaultne no.

Bylo to jen ~20s hledani, "man systemd.service" a "/restart" a "n" "n" "n".

Neberte to osobne, ale vy jste nevidel dokumentaci ani z rychliku, stejne jako plno lidi zde a pritom vam to nebrani se "zasvecene" vyjadrovat.

Systemd ma mouchy, ale v tehle rovine nelezi a kompatibilita se SysV pro usnadneni migrace je slusna.

Pokud ale budete lini nahlednout do dobre dokumentace, nepomuze vam ani svecena voda.

[TM]

Fanatici a hračičkové jako vy rozbili před nedávnem velmi dobře funkční Linuxový desktop natolik, že se člověk bojí jej dát na PC někomu, kdo chce s PC _pracovat_.
A já se děsím, co svojí agresivitou způsobí i tam, kde jsem si donedávna myslel, že máme pevný základ na který se dá spoléhat.

[belisarivs]

+1

[ukos]

+1

[xicht]

Nastesti je tu moznost volby a GNU/Linux je STAVEBNICE.

[little.owl]

Nejsem zadny fanatik, ale jsem rad, ze veci hybou kupredu. Pokud by mel Torvalds a jini stejne zamrzle mysleni jako vy, tak se snad ani nepousti do psani Linuxu.

Pokud chcete s PC "pracovat" a tohle vam vadi, tak zustante u stable distribuci jake je RHEL/CentOS/Debian Stable/Ubuntu LTS.

[frEon]

nevim, jestli ten moloch systemd je krok kupredu nebo stranou

[little.owl]

Systemd vzhledem k funkcionalite neni moloch, obdobne reseni na bazi init a shell skryptu vyzaduje plno dalsich specifickych toolu. Vysledek je polofunkcni binec a z toho pramenici nekompatibilita mezi Linuxovymi distribucemi.

[Michal Kubeček]

Mohl byste, prosím, přestat psát "skrypt"? Je to hrozné…

[Milan Jurik]

A některé featury systemd mi přijdou spíše na škodu - automatický restart sestřeleného daemona, aniž by systemd věděl důvod sestřelení. Představte si situaci 4 nenažraných daemonů, které OOM pořád dokola killuje a systemd restartuje.

Tohle není až tak špatná fíčura. Aspoň v SMF na Solarisu je to tak, že k automatickému restartu služby dojde jen několikrát a pokud služba stále padá, přejde do maintenance modu a je vygenerován report pro admina, který musí zasáhnout. Mnohem lepší řešení, než aby si každý daemon to řešil (či spíše neřešil) po svém. Tohle Poettering ještě nedokopíroval?

[Michal Kubeček]

Mnohem lepší řešení, než aby si každý daemon to řešil (či spíše neřešil) po svém.

To se dá řešit univerzálním wrapperem.

[Milan Jurik]

Mnohem lepší řešení, než aby si každý daemon to řešil (či spíše neřešil) po svém.

To se dá řešit univerzálním wrapperem.

Jistě. A proč? A kdo to dělá? Využijete tento wrapper někde jinde mimo init?

[little.owl]

A jak ten univerzalni wrapper bude vypadat?

Nehraje nahodou systemd roli onoho univerzalniho, ale unifikovaneho, systemoveho wrapperu?

[Michal Kubeček]

Problém není v tom, že by tohle nedělal. Problém je, že dělá ještě spoustu dalších věcí, o které nestojím, a není způsob, jak mu to rozmluvit (kromě toho, že ho vyřadím ze hry úplně). Já dám přednost modulárnímu řešení, i kdyby to mělo znamenat, že se mi přihlašovací obrazovka kdm zobrazí o pár sekund déle (jako že ne).

[little.owl]

Problem je v tom, ze to tak nefunguje, ten roky trvajici dnesni binec a vzajemna nekompatibilita je vysledek teto anarchie a vyvojari daemonu potrebuji nejaky zakladni framework.

dělá ještě spoustu dalších věcí, o které nestojím, a není způsob, jak mu to rozmluvit (kromě toho, že ho vyřadím ze hry úplně)

Muzete to upresnit? Muzete mit pravdu, jen se jen ptam, co to je. Neni to nejake vylozene okrajove reseni?

Me ted spise vadi bugy na strane systemd a hlavne na strane applikaci, ktere najednou vylezaji na povrch, ne features.

[trekker.dk]

Vývojáři démonů nic takového nepotřebují. Spuštění démona v nějaké distribuci je věcí vývojářů té distribuce.

[kovariadam]

Potrebuju.

[little.owl]

Tak v meznim pripade ano, systemd totiz nevyzaduje zadnou zmenu na strane daemonu pokud vam staci omezene moznosti SysV.

Pokud chcete vice, nejake zmeny jsou uz vhodne.

Pokud treba nejaky daemon zacne mit problem s parallelnim startem je mizerne napsany.

[pavlix]

Pokud chcete vice, nejake zmeny jsou uz vhodne.

Tak ale zase konfigurovat socket activation není vhodné na každém systému u každé služby, že. Kolikrát je lepší, když systém nabootuje do použitelné podoby a služby, u kterých se dá očekávat, že budou použity, se spustí už během bootu.

V podstatě je to podobné rozhodnutí jako jestli pouštět démona z initu nebo z inetd, akorát je obojí spojené do jedné konfigurace.

[pavlix]

Vývojáři démonů nic takového nepotřebují. Spuštění démona v nějaké distribuci je věcí vývojářů té distribuce.

Momentálně naštěstí většina těch vývojářů nějaký ten example initskript či service file přibaluje. Ti, kteří chtějí, aby jejich aplikace rovnou fungovala na různých systémech bez zásahu packagerů, přibalují initscriptů několik, systemd unit stačí jedna.

[trekker.dk]

Ti, kteří chtějí, aby jejich aplikace rovnou fungovala na různých systémech bez zásahu packagerů

Oni ti "packagerové" zpravidla zasahují z nějakého důvodu...

[pavlix]

Oni ti "packagerové" zpravidla zasahují z nějakého důvodu...

Přesně tak. To znamená, že pokud bude upstream připravený, balíčkování bude jednodušší.

[little.owl]

Obvykle z toho duvodu, ze napsat startovaci skript, ktery by chodil na temer vsech distribucich je pro autory SW temer nadlidsky ukol a pak to musi patchovat/suplovat packager.

Systemd se svym zavazkem stability konfigurace je spravnym smerem a unity jsou stejne v kazde distribuci pouzivajici systemd.

[trekker.dk]

pak to musi patchovat/suplovat packager.

To je ale jeho práce. Autor softwaru má psát software, ne řešit instalaci na všech možných a značně se lišících distrech. A distra se liší nejenom v init skriptech, ale i v dalších věcech, takže package maintainer stejně pro ten software bude muset něco udělat

[little.owl]

Pro vetsinu balicku v podstate nemusi, krom zabaleni do deb/rpm/etc a nastaveni zavislosti. Pokud se mezi uzivatele a operacni system musi vlozit packager, silne to omezuje samotneho uzivate, ale i autory SW, a to naprosto zbytecne.

[trekker.dk]

Pokud se mezi uzivatele a operacni system musi vlozit packager, silne to omezuje samotneho uzivate, ale i autory SW, a to naprosto zbytecne.

Hm, budu mít záludnou otázku: jak? Správce balíku udělá, co je potřeba, autora SW to nemusí zajímat, protože to není jeho práce a neomezuje ho to. A uživateli ten balík prostě funguje, takže tady se žádné omezení taky nekoná.

[little.owl]

Omezuje vas to pokud jste uzivatel SW a chcete si nainstalovat aktualnejsi verzi a omezuje vas to pokud jste autor a chcete podporovat vice distribuci.

Ja vitam unifikaci, byt stale jeste limitovanou, a omezeni rozstristenosti v teto oblasti.

Nicmene at si kazdy pouziva co chce, systemd neni nikomu vnucovan, byt ma plno vyhod a je to volba tvurcu distribuce co budou pouzivat a pokud

uživateli ten balík prostě funguje, takže tady se žádné omezení taky nekoná.

[trekker.dk]

Nicmene at si kazdy pouziva co chce, systemd neni nikomu vnucovan

Tohle známe. Není nikomu vnucován, ale je možné na něj přejít, následně je doporučeno na něj přejít, následně je to výchozí volba a následně mám v systému další nepotřebnou sračku, která závisí na jiných nepotřebných sračkách a kterých se prakticky nelze zbavit.

Souhlas s příspěvkem č.1. Kill it with fire.

[little.owl]

Tahle myslenkova logika je od podstaty zvracena. Nekdo udela dobry skutek, napise nejaky SW, da ho zdarma k dispozici ostatnim pod GPL a vy to chcete zlikvidovat. To je absurdni, nemyslite? Pokud to ostatni pouziji a navazi na to svuj SW, je to jejich svobodna volba a vzdy je za tim jejich dobry duvod.

Vy muzete udelat jen dve veci: 1) nepouzivat to; 2) navrhnout jine reseni a presvedcit ostatni.

Pokusy diktovat jinym co smi a nesmi psat a integrovat do svych produktu do sveta svobodneho SW nepatri.

[Lol Phirae]

Pokusy diktovat jinym co smi a nesmi psat a integrovat do svych produktu do sveta svobodneho SW nepatri.

Tak už to prosímtě konečně vysvětli Lennartovi!

[pavlix]

Tak už to prosímtě konečně vysvětli Lennartovi!

IMO je lennartovi úplně putna zda jeho software používáš nebo ne.

[pavlix]

Pokusy diktovat jinym co smi a nesmi psat a integrovat do svych produktu do sveta svobodneho SW nepatri.

+1

[pavlix]

Já mám pocit, jako kdybys vůbec nevěděl jak to funguje. Tohle není closed source, o čem se bavíme. Přispěvatelem projektu může být často kdokoli, kdo přijde se změnou, kterou upstream přijme. Nehledě na to, že množina upstream vývojářů nemusí být disjunktní s množinou správců balíků a už vůbec ne množinou pokročilých uživatelů.

Pokud správce balíku vytvoří service file pro systemd, vznikne mu patch či samostatný soubor, který není důvod udržovat samostatně, pokud ho lze dostat do upstreamu. V opensource se občas používají i pojmy jako třeba „spolupráce“, které ty ve své úvaze zcela ignoruješ.

[Mrkva]

Tak krom současných budou přibalovat i systemd, to si pomůžou, co?

[pavlix]

Tak krom současných budou přibalovat i systemd, to si pomůžou, co?

Těch šest řádků nikoho nezabije a naopak některé v současné době balí jenom systemd. S tím, že distributoři stejně chtějí initskripty každý jinak, a to programátory aplikaci jaksi moc nezajímá.

Ono to totiž ve skutečnosti často proběhne úplně naopak. Distribuce vyrobí systemd unitu, upstream ji přijme a ostatní distribuce ji už jen používají. I z první distribuce může zmizet jeden zbytečný patch/soubor.

[Michal Kubeček]

Z hlavy mne napadá např.

• už zmíněný problém se službami, které mají komplikovanější detekci, zda jsou aktivní
• Mel Gorman se ptal, jak vypnout spouštění služeb v samostatných cgroups, protože pro ladění scheduleru potřebuje začít s čistou hierarchií. Odpověď zněla, že nic takového nepřichází v úvahu, protože je to integrální součást systemd a basta. Nakonec se sice ukázalo, že to možná nějak ošidit jde (a Mel se spokojil s návodem, jak systemd vypnout), ale tahle reakce je pro vývojáře a evangelisty systemd typická: nezapadáš-li do naší vize, přizpůsob se nebo zemři.
• Snaha integrovat do systemd věci, které tam nepatří, a ignorovat existující nástroje k tomu určené. Namátkou třeba vlastní plánování nebo z poslední doby mountování /tmp jako tmpfs. Proč nemůžou prostě dát položku do /etc/fstab, jak je ve slušné společnosti zvykem? (Lennartovo vysvětlení "We believe …" jsem četl, ale ani v nejmenším mne nepřesvědčilo o správnosti takového přístupu.)

[michich]

už zmíněný problém se službami, které mají komplikovanější detekci, zda jsou aktivní

Já osobně jsem pro přidání ExecStatus=, kvůli lepší kompatibilitě. Lennart ani Kay na tom pracovat nebudou, ale pokud to půjde udělat tak, aby to nepoškodilo služby, které to nepotřebují, tak by to mohlo projít. Fedorácký bug, kde jsem ExecStatus navrhoval, mi zavřel horlivý triager jako WONTFIX, ale protože ho už trochu znám, nepřikládám tomu žádnou váhu. Chci si ExecStatus víc promyslet.

Mel Gorman se ptal, jak vypnout spouštění služeb v samostatných cgroups, protože pro ladění scheduleru potřebuje začít s čistou hierarchií. Odpověď zněla, že nic takového nepřichází v úvahu, protože je to integrální součást systemd a basta. Nakonec se sice ukázalo, že to možná nějak ošidit jde (a Mel se spokojil s návodem, jak systemd vypnout), ale tahle reakce je pro vývojáře a evangelisty systemd typická: nezapadáš-li do naší vize, přizpůsob se nebo zemři.

Koho se Mel ptal? Co nejde vypnout, je pouze cgroups hierarchie "systemd", která však nemá na scheduler vliv. Ten má hierarchie "cpu". Aby na ni systemd nesahal, lze nastavit volbou DefaultControllers= v konfiguráku. Nejedná se o žádné ošizení, je to zdokumentovaná volba. S tím, že špatně informovaní lidé radí blbě, asi nic nenaděláme. Nebo šlo o nějaké nedorozumění. Nevím. To, že někteří evangelisté projekt poškozují, je asi pravda. Nelze zobecňovat vlastnosti evangelistů na vývojáře.

[pavlix]

Já osobně jsem pro přidání ExecStatus=, kvůli lepší kompatibilitě. Lennart ani Kay na tom pracovat nebudou, ale pokud to půjde udělat tak, aby to nepoškodilo služby, které to nepotřebují, tak by to mohlo projít. Fedorácký bug, kde jsem ExecStatus navrhoval, mi zavřel horlivý triager jako WONTFIX, ale protože ho už trochu znám, nepřikládám tomu žádnou váhu. Chci si ExecStatus víc promyslet.

+1

Přidat rozumně udělaný ExecStatus je řešení typu „vlk se nažral a koza zůstala celá“.

[little.owl]

ad 1) to je ona podpora systemd aplikacemi, toto podle mne systemd nemuze resit samostatne a aplikacim poskytuje vhodne nastroje;

ad 2) to mi uslo, mate nejaky link?

ad 3) s tim take nesouhlasim, ale dokazi si predstavit, ze se neco bude delat jinak - jen by to melo mit smysl - a "We believe ..." is not simply enough. Nevim, ale myslim, ze ten problem s tmp byl vyresen, vy jen nemuzete mit zaznam systemd tmp.mount a fstab zaroven, podle me to nehraje roli.

[Michal Kubeček]

Ad 1: Tady typicky nejde o aplikace, ale právě o služby, kde žádný démon není. Příkladem je třeba AppArmor (implementace v jádře, userspace jen naloaduje profily), firewall (v podstatě totéž) nebo konfigurace sítě (vlastně také, přinejmenším pro statickou konfiguraci).

Ad 2: Omlouvám se za mystifikaci, nebyl to Mel Gorman ale Mike Galbraith; nevím, proč si ty dva pořád pletu… Tady je první mail a tady ta odpověď, kterou jsem měl na mysli především. Na vysvětlení: Frederic Crozat není nějaký náhodný kolemjdoucí, ale ten, kdo má na svědomí systemd v OpenSuSE, takže když napíše, že to a to systemd neumožňuje, předpokládám, že je to pravda.

Ad 3: Možná jsem dostatečně nevysvětlil, co přesně mi vadí. Za starých dobrých časů (TM) když se mi něco divného dělo jednou denně, věděl jsem, že mám projít cron tabulky. Pak přišly adresáře /etc/cron.{hourly,daily,weekly,monthly}, ale budiž, s tím se dalo vyrovnat. Teď si systemd zavádí své vlastní plánování úloh a já jen trnu, kdo další se toho chytne a bude ho následovat. Zrovna tak jsem zvyklý, že když zjistím, že se mi na /tmp (nebo jakýkoli jiný adresář) mountuje tmpfs a nebudu to chtít, jdu do /etc/fstab a tam to opravím. Ale ne, kdosi se rozhodl, že tak je to špatně a že se to bude konfigurovat někde úplně jinde. Přitom nedokáže ani vysvětlit proč, tedy kromě jakéhosi zmateného povídání, že má pocit, že /tmp není normální součást filesystému. Přitom takové proc nebo sysfs, které by si mimořádné zacházení zasloužily daleko spíš, nic takového nedělají a v /etc/fstab jsou, jen se z technických důvodů mountují dříve (a jinde) než "normální" filesystémy.

[pavlix]

firewall (v podstatě totéž)

To už taky není/nebude pravda.

konfigurace sítě (vlastně také, přinejmenším pro statickou konfiguraci).

To už jen v teorii.

a v /etc/fstab jsou, jen se z technických důvodů mountují dříve (a jinde) než "normální" filesystémy.

Tak si to tam dopiš a bude to mít stejné „technické“ důvody, jako proc a sys.

[Michal Kubeček]

firewall (v podstatě totéž)

To už taky není/nebude pravda.

konfigurace sítě (vlastně také, přinejmenším pro statickou konfiguraci).

To už jen v teorii.

Šly by tyhle dvě poznámky trochu rozepsat?

[pavlix]

Samozřejmě.

Firewall ve stylu skriptu z iptables má ten problém, že je statický. Na serveru to obvykle dává smysl, ale třeba v redhatí bugzille už několik let visí bugreport, že nefunguje gnomácké sdílení souborů (kvůli firewallu).

Je to jenom příklad, ale to sdílení souborů konkrétně používá dynamicky alokované porty, které je potřeba dynamicky povolovat na firewallu.

Když si stáhneš Fedoru 17 a nainstaluješ firewalld, tak od té chvíle máš démona, který udržuje firewall podle požadavků, které jdou doplňovat za běhu. Některé z těch požadavků jsou ryze dočasného charakteru.

Ještě to není úplně v provozu, neumí to spoustu základních věcí (momentálně to třeba neumí ani trvalou konfiguraci), ale vypadá to docela pěkně. Předpokládám využití dynamických vlastností zprvu spíš na desktopu, ale pokud se to osvědčí, může se to rozšířit i na server.

S tou sítí je to jednoduché. Fedora vytěsňuje původní nástroj pro konfiguraci sítě. Dokonce nově je NetworkManager součástí minimální instalace. To znamená, že i když si napíšeš statickou konfiguraci, přesto ti běží démon, který se o síť stará a je připravený ji kdykoli na základě tvých požadavků překonfigurovat. Jak to udělají jiné distribuce je samozřejmě druhá věc.

Služby, které konfiguraci naloadují, ukončí se, a dále už s ní nepracují, jsou čím dál tím vzácnější. Ale systemd s tímto typem služem stále samozřejmě počítá.

[Lol Phirae]

Samozřejmě. Na serveru to obvykle dává smysl, ale třeba v redhatí bugzille už několik let visí bugreport, že nefunguje gnomácké sdílení souborů (kvůli firewallu).Je to jenom příklad, ale to sdílení souborů konkrétně používá dynamicky alokované porty, které je potřeba dynamicky povolovat na firewallu.

Aha. Takže úplně blbě navrženou službu (proč by sakra mělo sdílení souborů používat dynamicky alokované porty) neopravíme, zato vyrobíme dynamickou díru do firewallu, aby si ho každý helhula, který se v Gnome hraje se sdílením adresářů, mohl dostatečně proděravět. Uaaaaaaaa.

[Smazáno]

Je zvláštní, že connection tracking pro ftp funguje. Ale jak je to DE, tak musí systém uhnout...

[Lol Phirae]

V pasivním režimu funguje, dokud se nezačne šifrovat (FTPS). Nicméně FTP nebo NFS (v defaultním nastavení) jsou přesně ty věci, které demonstrují, že s provozem přes firewall se vůbec nepočítalo a čemu by se měli vývojáři do budoucna vyhnout. Namísto toho tuhle pitomost udělají opět znova a navíc mají touhu kvůli tomu vyrábět dynamicky díry do FW. (A propos, i tohle už je "řešeno" i na krabičkách za pár stovek přes UPnP - jedna z prvních věcí, kterou vypínám. Takže jsme opět vynalezli kolo. Hmmmmpf.

[pavlix]

Až navrhneš lepší řešení stejného problému a uděláš něco proto, aby se to řešení do gnome dostalo, můžeme si o tom popovídat.

[Lol Phirae]

Jakého problému? Aby si Franta Vocas mohl nasdílet adresář Porno? To je vyřešeno např. ve Windows skoro 20 let bez jakýchkoliv dynamických portů apod. kosočtvercovin. Není nad to, vymyslet "problém" a pak ho řešit rozesíráním fungujících věcí.

[pavlix]

Je vidět, že tě baví nadávat a nebaví tě něco opravdu dělat.

[Lol Phirae]

Člověče, něco k věci by nebylo? Proč bych měl znovu vynalézat kolo? Ano, to mě opravdu nebaví, zato vy z Lennartova fanklubu si v tom evidentně libujete.

[pavlix]

zato vy z Lennartova fanklubu

LOL, já sem přišel diskutovat o systemd a udev, ne o tom, kdo si chce koho kam zaškatulkovat, aby ho následně mohl shazovat. Je mi líto.

[Lol Phirae]

OMG. Připomněl bych původní otázku - proč má kurva nějaké sdílení kokotin uživatelem pod Gnome používat dynamické porty serveru. Na to jsem se odpovědi nedočkal, zato jsem se dočkal spousty irelevantních žvástů a la Poettering fanclub. Tak si zase zafňukej nad zaškatulkováním a hlavně neřeš, nepřepínej a buď rád, že vůbec jseš.

[pavlix]

zato jsem se dočkal spousty irelevantních žvástů a la Poettering fanclub

To jakože kritizuješ svůj vlastní žvást?

Tak si zase zafňukej nad zaškatulkováním a hlavně neřeš, nepřepínej a buď rád, že vůbec jseš.

No je vidět, že jsem tě asi vytočil, to jsem neměl v úmyslu.

[Lol Phirae]

Rozumím, k věci nic. Běž zase navrhnout nějaký další sdílecí protokol s dynamickými porty, abys pak mohl navrhnout řešení pomocí dynamického vyrábění děr ve firewallu pomocí firewalld apod. sraček.

[pavlix]

Asi sis mě s někým spletl.

[Lol Phirae]

Asi si stojíš na kabelu.

[pavlix]

Od tebe trefné :).

[Michal Kubeček]

Napsat firewall v userspace je samozřejmě možné od chvíle, kdy byl zaveden target QUEUE (dnes NFQUEUE) a byla jen otázka času, kdy to někdo udělá. To ale automaticky neznamená, že firewalld bude jediná možnost, a už vůbec to neznamená, že to tak bude ve všech distribucích. Totéž platí o té konfiguraci sítě. Z formulace předchozího příspěvku už jsem se lekl, že snad někdo zešílel a plánuje zrušit standardní postupy úplně.

[Lol Phirae]

Z formulace předchozího příspěvku už jsem se lekl, že snad někdo zešílel a plánuje zrušit standardní postupy úplně.

Na to dojde, jen se to musí prezentovat správně politicky, teď jsou lidi tak nasraní, že pro to není ta správná chvíle. Zatím...

[pavlix]

Napsat firewall v userspace je samozřejmě možné od chvíle, kdy byl zaveden target QUEUE (dnes NFQUEUE) a byla jen otázka času, kdy to někdo udělá.

Domýšlíš si věci, které tam nejsou.

[root@dragon ~]# iptables -L | grep QUEUE
[root@dragon ~]# 

Pokud můj popis v předchozím komentáři vedl na představu, že firewalld je firewall v userspace navázaný na QUEUE, tak se omlovám, ale já to v tom svém komentáři fakt nevidím.

To ale automaticky neznamená, že firewalld bude jediná

To už jsem psal.

a už vůbec to neznamená, že to tak bude ve všech distribucích.

Něco podobného jsem psal v souvislosti s NetworkManagerem. Ta situace je naprosto stejná.

Totéž platí o té konfiguraci sítě.

Ano, to jsem taky ve svém předchozím komentáři psal.

Z formulace předchozího příspěvku už jsem se lekl, že snad někdo zešílel a plánuje zrušit standardní postupy úplně.

Můžeš mi prosím citovat co nejkratší úsek toho komentáře, který v tobě vyvolává dojem, že předchozí postupy budou všeobecně zrušené?

Jediné, co já ze svého příspěvku dokážu vyčíst je, Fedora postupně směřuje k tomu, aby funkcionalita síťové konfigurace i firewallu byla řešena démony. Zprvu na desktopech, kde je to spíše potřeba a méně to bolí, později pravděpodobně na serverech, když se to osvědčí.

Jak firewalld, tak NetworkManager jsou volitelné služby, jejichž jediný účel je poskytnout dynamickou konfiguraci, tedy konfiguraci bez restartu služby.

Když obě služby vypneš, není problém naplnit kernelové struktury skriptem. Nebo myslíš, že by kerneláři testovali síťový stack přidáváním testovacího kódu do NetworkManageru? Asi těžko, zeptej se tady Martina Mareše :).

[Michal Kubeček]

Pokud můj popis v předchozím komentáři vedl na představu, že firewalld je firewall v userspace navázaný na QUEUE, tak se omlovám, ale já to v tom svém komentáři fakt nevidím.

A já ve své odpovědi nevidím, že bych něco takového tvrdil. Ale ať je implementován tak či onak, pořád to nic nemění na tom, že to bude jen jedna z možností. A pořád bude potřeba počítat s tím, že "nastavit firewall" nebude nutně znamenat "spustit démona" a že otázka "je firewall aktivní?" nemusí být ekvivalentní otázce "běží démon X?". Totéž platí i pro nastavení sítě: pořád je potřeba počítat s tím, že akce "nastavit síť" nebude spočívat ve spuštění nějakého démona.

To byla podstata mého příspěvku: že je potřeba počítat s tím, že určité služby (díky Martinovi za připomenutí kernelového NFS serveru) zcela legitimně nejsou implementovány nějakým trvale běžícím démonem. A že je pomýlené takové služby hromadně odmítnout jako špatně navržené.

[pavlix]

A já ve své odpovědi nevidím, že bych něco takového tvrdil.

Tak zkus příště, až budeš psát o implementaci pomocí QUEUE napsat, že to tak nemyslíš :).

Ale ať je implementován tak či onak, pořád to nic nemění na tom, že to bude jen jedna z možností.

Tedy informace opakovaná po kolikáte v jednom vlákně?

A pořád bude potřeba počítat s tím, že "nastavit firewall" nebude nutně znamenat "spustit démona" a že otázka "je firewall aktivní?" nemusí být ekvivalentní otázce "běží démon X?".

To mi zní v kontextu výše uvedeného jako samozřejmost.

Nicméně, na systému postaveném na systemd, firewalld a NetworkManageru bude konfigurace taková, že systemd na dotaz, jestli běží firewalld odpoví podle toho, jestli dotyčný démon běží. Co jiného by takový dotaz měl odpovědět?

Totéž platí i pro nastavení sítě: pořád je potřeba počítat s tím, že akce "nastavit síť" nebude spočívat ve spuštění nějakého démona.

Viz výše. Pokud budeš mít chuť si vše nakonfigurovat jinak, já osobně proti tomu nic nemám.

To byla podstata mého příspěvku: že je potřeba počítat s tím, že určité služby (díky Martinovi za připomenutí kernelového NFS serveru) zcela legitimně nejsou implementovány nějakým trvale běžícím démonem. A že je pomýlené takové služby hromadně odmítnout jako špatně navržené.

Mně je to osobně jedno. Toho sporu o dobrý či špatný návrh falešných služeb se vůbec neúčastním.

Já jsem tě pouze upozornil na něco, co by pro tebe mohlo být novinkou, a to, že se Fedora zbavuje staré konfigurace sítě, a že Fedora zavádí novou možnost konfigurace firewallu.

Takže do budoucna budou ve Fedoře tyto dvě konkrétní věci už realizovány démony a ne skriptem na zkonfigurování jádra. Stává se, že z Fedory tyhle „novoty“ proplouvají i do jiných distribucí. Což se u NetworkManageru už stalo a u firewalld je to vysoce pravděpodobné.

[michich]

Tady je první mail a tady ta odpověď, kterou jsem měl na mysli především. Na vysvětlení: Frederic Crozat není nějaký náhodný kolemjdoucí, ale ten, kdo má na svědomí systemd v OpenSuSE, takže když napíše, že to a to systemd neumožňuje, předpokládám, že je to pravda.

Crozat tam odpověděl správně na špatně položenou otázku. Galbraith se zeptal, jak se zbavit úplně všech těch cgroups. To skutečně nejde. Ta "name=systemd" tam být musí. Teprve o několik mailů později Galbraith popsal, co konkrétně potřebuje, že mu vadí ovlivňování scheduleru. Později dostal i správnou odpověď (od Crozata), ale to už měl systemd odinstalovaný a nechtěl to znovu zkoušet. Rodríguez tam rozdmýchával plameny.

Přitom takové proc nebo sysfs, které by si mimořádné zacházení zasloužily daleko spíš, nic takového nedělají a v /etc/fstab jsou

Nemusejí tam být. Já je tam nemám.

[little.owl]

ad1) aplikace, sluzba, demon ... stejne jde jen o to v jakem kontextu se to spousti;

ad2) to spise vypada na prvni srazky s novou architekturou a souvisejici omyly na obou stranach, spise by me prekvapovalo, kdyby se neco takove nestalo;

ad3) nikdo, vcetne autora, nechce aby systemd se integroval vsechnu funkcionalitu a ani to nedela.

jen se z technických důvodů mountují dříve (a jinde) než "normální" filesystémy.

Tak k nim pribude i /tmp. To jsou prkotiny.

[Michal Kubeček]

1. Je dost velký rozdíl mezi službou odpovídající nějakému běžícímu démonovi (nebo sadě démonů) a službou, jejíž spuštění (ukončení) spočívá v tom, že se někde něco aktivuje (deaktivuje), ale otázka "je ta služba aktivní?" se nedá redukovat na prosté zjištění, zda démon běží. S tím prvním se systemd umí - aspoň v jednodušších případech - vypořádat dobře (resp. bude umět, až se opraví bugy). To druhé jeho vývojáři zatím akceptovat odmítají.

3. Mezi /tmp na jedné straně a proc nebo sysfs na druhé je naprosto zásadní rozdíl. To první je normální součást filesystému, soubory, do kterých zapisuji, ze kterých čtu a které někde zabírají místo, a je žádoucí mít kontrolu nad tím, kde ho zabírají (např. proto, aby ho bylo dost), případně mít možnost zvolit si typ filesystému (co když zatoužím po btrfs a jeho snapshotech?). To druhé jsou zcela virtuální filesystémy, které simuluje nějaký driver jádra.

[Jiří J.]

Jen doplním - na desktopech s hodně RAM (dříve 4GB, dnes 8+GB) používám tmpfs na /tmp a ve většině případů s tím není problém. Nutno však poznamenat, že používám fluxbox, Gnome/KDE/xyz tam může cpát daleko více dat.

Já osobně narazil (v poslední době) jen na pár výjimečných případů - cache některých flashových přehrávačů videa a -snapshot vlastnost qemu-kvm. Oboje ale bylo korektně implementováno přes mktemp(3), takže pomohlo exportovat proměnnou TMPDIR na alternativní lokaci.

To ale není něco, co by běžný "noob" uživatel desktopového linuxu chtěl dělat. Pokud k tomu připočteme, že se pořád najdou modernější stroje s 2GB RAM, začíná být tmpfs na /tmp docela problém.

PS: Jsem si vědom, že defaultní max. velikost tmpfs je polovina celkové paměti systému.

[pavlix]

Jen doplním - na desktopech s hodně RAM (dříve 4GB, dnes 8+GB) používám tmpfs na /tmp a ve většině případů s tím není problém. Nutno však poznamenat, že používám fluxbox, Gnome/KDE/xyz tam může cpát daleko více dat.

To stejné jsem používal na Fedoře 16 na notebooku s 1 GB RAM, výchozí instalace, výchozí Gnome 3.

Já osobně narazil (v poslední době) jen na pár výjimečných případů - cache některých flashových přehrávačů videa a -snapshot vlastnost qemu-kvm. Oboje ale bylo korektně implementováno přes mktemp(3), takže pomohlo exportovat proměnnou TMPDIR na alternativní lokaci.

Nad tím jsem vždycky přemýšlel, proč se tmp používá pro dvě naprosto odlišné věci.

[little.owl]

ad 1) Myslim si, ze na otazku "je ta služba aktivní" - rozumim funkcni - nemuze systemd rozumne odpovedet a ani bych tam tu funkcionalitu nechtel. Systemd je pro me v tomto kontextu neco jako SW watchdog, nic vice, nic mene, a aplikace sama (a je jedno jak ji nazyvame), by mela pro to maximalne poskytnout jednoduchou diagnostiku v ramci prostredku nabizenych systemd.

ad 2) Tak ja chapu v cem je rozdil; myslel jsem to tak, ze pribude dalsi filesystem, pro ktery budou platit specialni pravidla, ale nevidel jsem zduvodneni, tak nevim. Skutecne mi prijde jako detail, zejmena pokud to budete moci nepouzit, kdyz nechcete.

[Michal Kubeček]

Ad 1: V podstatě navrhujete stejné řešení jako mnozí před vámi - zavést direktivu ExecStatus, která by umožnila definovat příkaz, který detekuje, zda je služba aktivní, a systemd to řekne. Takové řešení bych považoval za ideální - bylo ovšem smeteno ze stolu s tím, že služba, která by ho potřebovala, je špatně navržená.

Skutecne mi prijde jako detail, zejmena pokud to budete moci nepouzit, kdyz nechcete.

Problém je, že to nebudu moci nastavit v /etc/fstab, kam to odjakživa patří, přestože k tomu nejsou žádné technické důvody, jen jakýsi pocit, že "/tmp není normální součást filesystému".

Připomínám, že celá tahle větev vzešla z dotazu na příklady toho, kde se systemd snaží integrovat do sebe věci, které by dělat nemusel a pro které existují standardní nástroje. A tohle považuji za naprosto typický příklad zvráceného uvažování autora: existuje cron, ale my si uděláme vlastní; existuje fstab, ale my si uděláme vlastní; služby nějak fungují, ale my nařídíme, že mají fungovat jinak. Prostě buldozer. Srovnejte si to s takovými syslog-ng nebo rsyslog, kvůli kterým nebylo potřeba přepisovat jedinou logující aplikaci, jediné, co se změnilo, je konfigurace (v případě rsyslog nemusíte přepisovat ani tu, pokud nechcete využívat rozšířené funkce). Přitom změnou rozhraní by se daly získat další výhody - ale autoři moudře usoudili, že by nestály za nutnost přepsat všechny aplikace a zavést tak nekompatibilitu se zbytkem unixového světa.

[pavlix]

Ad 1: V podstatě navrhujete stejné řešení jako mnozí před vámi - zavést direktivu ExecStatus, která by umožnila definovat příkaz, který detekuje, zda je služba aktivní, a systemd to řekne. Takové řešení bych považoval za ideální - bylo ovšem smeteno ze stolu s tím, že služba, která by ho potřebovala, je špatně navržená.

Tak je potřeba ho navrhovat znovu a z novu s konkrétními use case. Jsou jen dvě možnosti. Buď dotyční mají pravdu a obhájí ji tím, že vždy vymyslí lepší způsob, jak unitu napsat. A nebo pravdu nemají, nevymyslí to, a nakonec se ExecStatus prosadí :).

Nebo jsem stále ještě příliš velký idealista? Ale i kdyby jo, tak je potřeba to nejdřív zkusit, pak teprve nadávat, že to nevyšlo.

[little.owl]

ad1) Ano, v podstate se schodnem, ale je to stale jen workaround, jedine rozumne reseni je, ze aplikace se zacnou chovat korektne a Lennart je zde [typicky] mene kompromisni.

ad2) Mne hlavne stale neni jasne jak podle vas souvisi prechod /tmp na tmpfs se systemd. Tenhle prechod jiz udelal Arch i Debian a systemd defaultne nemaji, na strane druhe Fedora ho ma a stale jeste pouziva klasicky /tmp.

[Michal Kubeček]

jedine rozumne reseni je, ze aplikace se zacnou chovat korektne

Kolikrát ještě budu muset zopakovat, že mluvím především o službách, u kterých žádná aplikace není, než to konečně zaregistrujete a přestanete opakovat mantru "aplikace se mají chovat korektně"?

Mne hlavne stale neni jasne jak podle vas souvisi prechod /tmp na tmpfs se systemd.

Souvisí to tak, že mezi tím, co se chystá v rámci upstreamu systemd, je mimo jiné automatické mountování tmpfs na /tmp, jehož účelem má být "stateless setup" a které nemá být řešeno přes fstab, ale interně v režii systemd. Sice by to mělo jít vypnout, ovšem v konfiguraci systemd, ne tam, kde by to admin naivně čekal.

[little.owl]

Mluvime o service v kontextu systemd, tak jak ho specifikuje systemd (systemd.service)?

[Michal Kubeček]

Těžko říct, o čem mluvíte vy. Já mluvím o službách, které v systému potřebuji a potřebuji, aby je kořenový proces při startu spouštěl a při shutdownu ukončoval a abych je mohl v případě potřeby snadno ukončit/spustit/restartovat ručně, případně se dotázat na status. Mezi takové služby patří i ty, které jsem jmenoval (síť, firewall, AppArmor, občas i ten jaderný NFS server). Pokud je systemd z ideových důvodů za služby nepovažuje a tudíž to dělat odmítá, pak nemá na mém systému co dělat.

[little.owl]

Vyborne, pokud k tomu lze dohledat PID, pak je to urcite service i pro systemd - a pro mne trochu nepresne applikace [bezici na pozadi v jinem kontextu]. Takze me vyjadreni vyse o aplikacich nahradte slovem service/sluzba a budete vedet, co jsem chtel rici.

Ohledne kernel NFS, sluzby jako rpcbind, ani nfsd nejsou problem.

[Michal Kubeček]

Ne, nejde k tomu dohledat PID. U řady takových služeb neexistuje žádný konkrétní trvale běžící proces (ani kernel thread), který by byl s takovou službou svázán. Příkladem je už mnohokrát zmíněný firewall (klasický netfilter), konfigurace sítě (statická) nebo AppArmor. U všech tří je společné to, že při inicializaci cosi spustíte, při ukončení spustíte něco jiného, ale nemáte žádný proces (ani obecný task), který by běžel celou dobu mezi těmito dvěma okamžiky a který by odpovídal této službě.

[little.owl]

To ale lze v systemd resit snadno take:

[Service]
Type=oneshot
RemainAfterExit=yes
...
ExecStart=/sbin/ip link set dev %I up
ExecStart=/sbin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev %I
ExecStart=/sbin/ip route add default via ${gateway}
ExecStop=/sbin/ip addr flush dev %I
ExecStop=/sbin/ip link set dev %I down
...

Tady opravdu zadne velke limity nejsou ...

[Michal Kubeček]

Četl jste vůbec, co tu celou dobu píšu? Problém není ve spuštění a ukončení, ale ve zjištění stavu. To je to, co by řešil ExecStatus - kdyby ho vývojáři neodmítli.

[pavlix]

Četl jste vůbec, co tu celou dobu píšu?

Podle mě by sis to první měl přečíst znovu sám.

To je to, co by řešil ExecStatus - kdyby ho vývojáři neodmítli.

Pak ale nemá smysl se o tom hádat s lidma, kteří nepsali nic o tom, že by byly proti ExecStatus. IMO by klidně mohlo být v directivách ExecStatus napsáno pár testovacích příkazů a kdyby některý vrátil nulu, byla by služba FAILED.

Neříkám, že je to k něčemu dobré. IMO to žádný problém kromě tvých osobních zvyklostí neřeší. Ale osobně bych ti takovéhle řešení, kdyby byl kód v pořádku, začlenil.

Abych pravdu řekl, tak jsem nikdy v životě reálně nepoužil /etc/init.d/iptables status nebo něco podobného.

[Michal Kubeček]

Podle mě by sis to první měl přečíst znovu sám.

Udělal jsem to (znovu) a ověřil jsem si, že v této větvi mluvím konzistentně pořád o tom samém.

IMO to žádný problém kromě tvých osobních zvyklostí neřeší.

IMHO to řeší problém s detekcí toho, zda je služba aktivní. Uživatele spíš zajímá to, zda je síť nastavená, než to, jestli se od (posledního spuštění "rcnetwork stop" | startu systému) spouštělo aspoň jednou "rcnetwork start". Samozřejmě netvrdím, že příslušný skript ve všech distribucích to opravdu kontroluje; ale pokud ne, je to jen (opravitelná) chyba toho skriptu.

Abych pravdu řekl, tak jsem nikdy v životě reálně nepoužil /etc/init.d/iptables status nebo něco podobného.

Já také ne, ale to v podstatě jen proto, že jsem si ten skript psal sám a byl jsem líný tam tu větev napsat, takže místo toho používám "iptables -nvL". Ale třeba "rcapparmor status" používám celkem často.

[pavlix]

Já také ne, ale to v podstatě jen proto, že jsem si ten skript psal sám a byl jsem líný tam tu větev napsat, takže místo toho používám "iptables -nvL". Ale třeba "rcapparmor status" používám celkem často.

ROFL, mám to chápat tak, že se se mnou i s jinými dohaduješ o problému, který tě vůbec netrápí a přesvědčuješ alespoň mě o řešení, se kterým jsem souhlasil ještě před započetím diskuze?

[Ivan]

Abych pravdu řekl, tak jsem nikdy v životě reálně nepoužil /etc/init.d/iptables status nebo něco podobného.

No vidis a ja to resim pravidelne. Veritas cluster ma kazdeho resource(neco jako sluzba), scripty "start", "stop", "clean" a "status". Ten "clean" je takovy drsnejsi "stop". U resource je mozne nastavit atributy jako "failcount" - ovlivnuje pocet automatickych restartu. Popr. je tu i atribut "critical". Pokud je resource ve stavu "failed" je "failed" i cela skupina zdroju do ktere patri.

Navic je to cele provazene s monitoringem a s helpdeskem.

Jako tresnicka na dotru je ve Veritasu nastroj, kterej ti umi vizualne zobrazit strom zavislosti, ukazuje stavy sluzeb behem bootovani a pri editaci konfigurace ti neumozni vytvorit cyklickou zavislost.

[pavlix]

No vidis a ja to resim pravidelne.

Nikde jsem nepsal, že by mi vadilo, když to někdo používá. Naše informace tedy nejsou v rozporu.

[little.owl]

Resenim je omezit pouzivani techto pochybnych pseudo-sluzeb u klicovych veci (network, firewall etc.) s problemy, ktere dobre popsal nahore l4m4, a pouzit nejaky jednoduchy daemon bezici na pozadi. Fedora jde evidentne dobrym smerem se svym firewalld.

Ohledne ExecStatus mezi nami nebyl spor, cas ukaze jestli je to opravdu treba, a pokud ano, budete to tam mit.

[Martin Mareš]

Resenim je omezit pouzivani techto pochybnych pseudo-sluzeb u klicovych veci

Čím že jsou ty pseudo-služby pochybné? Jenom tím, že nezapadají do představy "každá služba má svého daemona", nebo i něčím dalším?

Mně přijde naopak představa o ekvivalenci mezi službami a daemony naprosto naivní a evidentně v rozporu s realitou.

[Lol Phirae]

Čím že jsou ty pseudo-služby pochybné? Jenom tím, že nezapadají do představy "každá služba má svého daemona", nebo i něčím dalším?

Ale tento "problém" je přece snadno řešitelný! Firewall nemá démona? Vytvoříme firewalld! Síť nemá démona! Zadrátujem tam co nejvíc NetworkManager! Foobarbaz nemá démona? Není nic snazšího, než vytvořit foobarbazd bloatware! Protože tak to je soudruzi správné a tak to musí být, a kdo s tím nesouhlasí toho vyobcujeme a nepohřbíme ani na hřbitově.

[little.owl]

Ale takhle to nestalo.

Pokud staci jednorazove nastaveni, neni zadny problem a pouziti nejakeho daemona je skutecne zbytecne a reseni v systemd je zde ekvivaletni SysV.

Nicmene pokud chceme vice, treba monitorovat stav, daemon muze byt vhodnejsi reseni, mnohem vhodnejsi nez to presouvat do systemd - tady prece SysV take nic nenabizi. Tak o cem se hadame?

[little.owl]

Ten problem neni v tom, ze vy neco jednoduse jednorazove nastavite (pseudo-sluzba), ale v tom ze vy potom vyzadujete moznost, casto krkolomnym zpusobem, to sledovat a zjistovat stav, zda-li vam to jeste bezi v nastaveni jak jste spustil a zdali vam to treba nejaky uzivatel ci aplikace neprepsali.

Potom se pouziti jednoducheho daemona, ktery muze i trasovat historii, zda byti malym zlem, zejmena v systemu s on-demand spoustenim.

evidentně v rozporu s realitou.

To ukaze cas.

[Martin Mareš]

A nemyslíte, že hodnocení toho, zda je způsob krkolomný (a tedy řešení pomocí daemona je jednodušší), přísluší především autorovi příslušné služby?

Kategorické názory autora systemd mi v tomto směru přijdou jako klasická instance postoje "nic není obtížné pro toho, kdo to nemusí dělat".

[little.owl]

A nemyslíte, že hodnocení toho, zda je způsob krkolomný (a tedy řešení pomocí daemona je jednodušší), přísluší především autorovi příslušné služby?

Ano, myslim a prave proto by se to nemelo presouvat do systemd.

[pavlix]

A nemyslíte, že hodnocení toho, zda je způsob krkolomný (a tedy řešení pomocí daemona je jednodušší), přísluší především autorovi příslušné služby?

A kdo mu v tomto rozhodnutí momentálně překáží? Jako chápu rozhořčení nad ExecStatus, ale to nebrání takové služby v systemd používat. Názor na ExecStatus se může lišit, není to zdaleka tak jednoduchá věc, jak se zdá na první pohled.

[little.owl]

ExecStatus ve sve podstate vyrazne komplikuje celou koncepci, nebot to znamena, ze systemd bude muset periodicky testovat stav aplikace/sluzby v urcitem casovem intervalu (dalsi parametr). Fakticky, krom toho ze budete muset periodicky neco spustet, na urovni systemd akceptujete stav ze mezi volanim ExecStatus muze byt aplikace/sluzba po urcitou dobu nefunkcni.

Lepsim resenim je napsat aplikaci/sluzbu tak, aby pres vnitrni diagnostiku ukoncila sama sebe a vratila nejaky rozumny kod, pripadne byla monitorovana dalsi applikaci/sluzbou, ktera se automaticky spousti a ukoncuje pres zavislosti.

[pavlix]

ExecStatus ve sve podstate vyrazne komplikuje celou koncepci, nebot to znamena, ze systemd bude muset periodicky testovat stav aplikace/sluzby v urcitem casovem intervalu (dalsi parametr).

Taky jsem toho názoru, že by bylo lepší mít tuhle povinnost delegovanou na démona, i kdyby byl ten démon 99.9% svého života ve stavu čekání na návrat z funkce poll.

[pavlix]

Ten problem neni v tom, ze vy neco jednoduse jednorazove nastavite (pseudo-sluzba), ale v tom ze vy potom vyzadujete moznost, casto krkolomnym zpusobem, to sledovat a zjistovat stav, zda-li vam to jeste bezi v nastaveni jak jste spustil a zdali vam to treba nejaky uzivatel ci aplikace neprepsali.

+1

A na skutečné sledování a zjišťování stavu je potřeba, aby se démon přihlásil ke sledování této konfigurace přes různá jaderná rozhraní a byl schopen zodpovědně vydat informaci o stavu.

[j]

Ehm ...o par postu vejs vychvalovani, jak to umi samo restarnout sluzbu a ted ze to neumi zjistit, zda vlastne bezi?

[pavlix]

O pár postů výše to byla služba typu démon. Teď je to služba typu jednorázová akce, což vlastně ani není služba, ale z nějakých obvykle praktických důvodů se za službu vydává :).

[Martin Mareš]

Představa, že každé systémové službě odpovídá daemon, je dost naivní. Existuje spousta věcí, které se logicky chovají jako systémová služba, dává smysl je konfigurovat jako systémovou službu, a přesto jim žádný daemon neodpovídá. Typický příklad je třeba konfigurace sítě nebo export množiny adresářů po NFS.

[pavlix]

Já to chápu, je mi v podstatě jedno, jestli se to řeší démonem nebo jednorázovým spuštěním něčeho. V systemd to funguje, takže v čem je problém.

Pár lidem vadí, že systemctl status iptables.service (system iptables status) nevypíše výstup iptables-save. Když jim to vadí, tak ať ten ExecStatus navrhnou tak, aby nerozbil nic jiného. Pak se můžeme bavit o jeho prosazení. michich psal, že se na to chystá.

[little.owl]

Namatkou citace z mojich predchozich prispevku:

Automaticky restart je jen tresnicka na dortu, kterou muzete a nemusite pouzit a muzete nastavit podminky za jakych se to stane.

Restart sluzby je u systemd defaultne vypnuty a ja opravdu nevim proc je tu kolem toho takovy krik. Pouziva behove udalostim jako je exit(), abort() etc. a tim jsou jeho moznosti omezeny.

A dalsi by sli najit.

[Ivan]

Solaris neznam, ale pokud pouziju jako analogii AIX/HACMP/Veritas tak dojdu ke stejnumu zaveru. Ta nova libiva cool reseni porad jeste nezkopirovala vlastnosti komercnich Unixu, ktere byly implementovany pred vice ned deseti lety. Me nevadi, ze systemd je novy. Me vadi, ze budu muset cekat vyvojari implemetuji vlastnosti, ktery ostatni chapali jako nutnost uz v roce 1995. (Tedy v roce 1995 jsem byl jeste ucho, dneska ale spravuju systemy, ktere byly v te dobe nainstalovany)

[Lol Phirae]

Rád používám takovou analogii klasických init skriptů versus systemd - je to jako textové konfiguráky versus registr systému Windows.

Tak např. v případě genitálního Lennartova binárního systémového logu to sedí jako prdel na hrnec.

[little.owl]

To se mi take nelibi.

Ono to funguje dobre pokud to funguje a format logu by mel zarucit moznost cteni s prilozenymi tooly i pri porusene integrite dat, ale text je text a silna redundance dat se zde da prezit.

[pavlix]

Já si umím představit nad binárními logy mnohem pohodlnější dotazování. Ale osobně bych dal přednost tomu, kdyby budoucí systém logování obsahoval i modul pro textovou reprezentaci.

Vtip je v tom, že binárních logů se člověk nemusí bát zapsat trochu víc, bude to méně zdržovat, rychleji se to bude počítat. IMO by bylo ideální mít za všech okolností možnost volby, s tím, že některá z možností se ustálí jako default.

Ono čistě mezi náma, klasický způsob, jak se to dělá dnes má taky spoustu neduhů. Některé věci prostě člověk jen tak lehce nevygrepuje. Rozdělení do souborů (facility) často nefunguje tak jako je psáno v dokumentaci. Formát data bývá vskutku debilní.

[little.owl]

Pokud bude format binarky rozumne zabezpecen proti poruseni itegrity dat i pri poskozeni/ztrate sektoru filesystemu a vhodne tooly exportujici [fitrovana] data do textu, proc ne; *.log.gz je take binarka.

[dustin]

To size je binárka, ale zgrep má stejné parametry jako grep, nebo mohu v rouře projet gzipem. Absolutně nesrovnatelné s binárními logy pro které bych potřeboval zase další binárku, zkompilovanou pro danou architekturu.

[pavlix]

To size je binárka, ale zgrep má stejné parametry jako grep, nebo mohu v rouře projet gzipem.

Ale vždyť to je to, co oba říkáme. Že nám záleží pouze na tom, jestli budou k dispozici srovnatelné nástroje, ne na samotném uložení.

Absolutně nesrovnatelné s binárními logy pro které bych potřeboval zase další binárku, zkompilovanou pro danou architekturu.

A pro jakouže to společnou architekturu kompiluješ ten zgrep?

[dustin]

Myslím, že víš moc dobře, mam mířím. Je rozdíl mezi speciálním nástrojem, a nástroji, které jsou již standardní součástí každé linuxové distribuce včetně embedded - grep a gzip. Je to na mraky knihoven, není potřeba nic extra. Bude trvat spoustu let, než nějaký nový formát dosáhne takové podpory. Navíc nejsem přesvědčen, že se tím získá nějak moc.

[pavlix]

Bude trvat spoustu let, než nějaký nový formát dosáhne takové podpory. Navíc nejsem přesvědčen, že se tím získá nějak moc.

Já procházím různé logy prakticky denně. Mám v hlavě spoustu věcí, které se mi dělají špatně a s dobrým nástrojem by se mi dělaly lépe.

V podstatě, až na rychlost a ten obecný grep, je mi jedno, jestli je formát textový nebo binární. Jenom vím, že současný formát je blbě definovaný a málo strukturovaný. Od kohokoli, kdo přijde s novým logováním, které bude schopný prezentovat tak, aby ho ostatní přijali, očekávám zlepšení právě v selectování z těch logů.

Vybudovat nad slušným základem nástroje je max otázka měsíců. Než si to celé sedne, tak to jsou roky, ale s tím nikdo nic nenadělá. Každopádně současný stav není úplně to, co by se mi líbilo. Budoucnost vidím ve strukturovaném logování.

[dustin]

Pořád mi vrtá hlavou, jako to Lennart dělá, že přijde s něčím úplně novým a za pár měsíců jeho zaměstnavatel RedHat plnou silou tlačí napůl nedodělanou sotvabetu jeho dalšího projektu. Jako kdyby se tam s ním nechtěli hádat, tak mu na to raději kývnou, nebo jinak nevím. Přijde mi, že má dobré úmysly, ale vždycky si vezme obrovské sousto s maximalistickými nekompromisními plány, které se ale příliš brzo dostane do světa mezi běžné uživatele. Fakt by mě zajímal názor nějakého brněnského insidera, jak to v RH v tomto ohledu chodí.

[Karel Zak]

Muzete na nejakem prikladu ukazat kde Red Hat neco tlaci? Fedora != Red Hat, kdokoliv dostatecne vytrvalej a schopnej si muze ve Fedore prosadit nejaky *svuj* projekt, nemusi byt placen Red Hatem.

BTW mnoho z hlasitych kritiku toho co dela Lennart a Kay je prave z Red Hatu (viz. fedora-devel list). Ta firma je v tomto znacne svobodna -- coz je dobre.

[dustin]

Díky za upřesnění.

[haha]

To si vystihl presne. A taky by me zajimalo jak to dela

[little.owl]

Lennart je typ cloveka, ktery ma dobre napady, ale neni je schopen uplne dotahnout do konce. Ale od toho jsou tu jini a on ma svou [nezastupitelnou] roli.

[Milan Jurik]

bod 1.

Problém tohoto přístupu je, že ti, co to mají dotáhnout do konce, často z úcty k Tvůrci nebo nechuti nebo nemožnosti to do konce nikdy nedotáhnou.

[little.owl]

To neni problem neucty k tvurci, ale proste skutecnosti, ze je to nuda a chyby tomu adrenalin, takze to nakonec budou muset oddrit ti chudaci v Brne, ktere k tomu Red Hat dokope.

[dustin]

Ale to je přesně moje otázka - jak Lennart dokáže přesvědčit vedení RH, že jeho nápad je tak skvělý, že RH zaplatí nejenom jeho čas, ale ještě plat spousty dalších, kteří jej pak musí měsíce a roky dotahovat do konce? Chápal bych, kdyby byl šéfem vývoje a určoval priority. I když to by asi nedopadlo dobře, překomplikované projekty nebývají komerčně úspěšné.

[little.owl]

jak Lennart dokáže přesvědčit vedení RH

Asi proto, ze jeho napady jsou vetsinou velmi dobre, zduvodnene a i celkem promyslene.

Systemd neni tak extremne slozity jak se zda, jen bori zazite a anihiluje nektere roky ziskane zkusenosti a bude potrebovat cas - asi do pristiho RHEL - - na stabilizaci.

[dustin]

Souhlasím, že to obvykle velice dobře vyargumentuje. Jenom mi přijde, že jeho projekty bývají špatně řízené. Přestože se obvykle jedná o infrastrukturu, která má dopad na ostatní aplikace, příliš brzo se protlačí do mainstreamu a pak se teprve vyvaluje mraky chyb, často právě v těch aplikacích. A jsou to chyby či nedostatky podstatné, co by se nedalo odhalit pořádným testováním a včasnou domluvou s autory aplikací. Kdyby býval ještě rok makal na integraci pulseaudia a alsy, mohlo se spoustu změn v alse udělat ještě před naštváním mraků uživatelů nefunkčního pulseaudia a naprosté ztrátě image tohoto v základu užitečného projektu. Jenomže to není jeho styl.

[dustin]

Ale měl by to být styl jeho šéfů, kteří mají SW projekty na starosti.

[little.owl]

Tak ona je to tak trochu teorie.

Tam nejde jen o bugy v infrastrukture, ale i bugy v applikacich a ty jejich autori neopravi pokud se infrastruktura nenaintegruje.

Lennart proste nemuze fixovat bugy aplikaci, kteri tvurci/distributori/uzivatele resili tak, ze upraseny daemon zabalili do jeste uprasenejsiho skriptu.

To je Fedora, bleeding edge a pokud chcete stabilitu a klid hrbitova jdete do CentOS ci Debian Stable.

[dustin]

Souhlasím, leč delší testovací období by dalo více času ty aplikace včas opravit. Alsa taky měla spoustu much a např. do ubuntu se pulseaudio dostalo v době, kdy se ty chyby či nedokonalosti teprve řešily a postupně odstraňovaly. A nebylo to jenom na základě uživatelských bugreportů, oba týmy věděly, kde je tlačí bota. Alsa jasně řekla pulseaudiu, že požadavky, které na ni kladou, nikdy moc vážně neřešila a bude chvíli trvat, než ty funkce opraví a dodělají (věci kolem časování a přesnosti časovacích informací). Kdyby býval tým pulseaudia veřejně řekl "Počkejte, až to spolu pořádně sladíme" a PA šlo do distribucí o rok vývoje později, vypadalo by to první roky určitě jinak. Obávám se, že úplně stejné to bude se systemd.

[little.owl]

To jsou komunitni distra, ty vyviji a fixuje komunita, RedHat, Suse ani Canonical nema dost lidi na to vse plne odladit.

Problem neni systemova infrastruktura, ale aplikace ktere jsou vzdy o krok pozadu.

[Lol Phirae]

ktere jsou vzdy o krok pozadu.

Zato Lennart je vždy o krom dopředu - do hloubi řiti.

[Lol Phirae]

*krok

[dustin]

Zrovna v případě pulseaudia byl hlavní problém komunikace pulseaudio - alsa, tedy infrastruktura. A od začátku autoři pulsaudia věděli, že to ještě dlouho nebude fungovat pořádně. Přitom to byla komunikace s jedním konkrétním projektem na druhé straně.

Aplikace se vesměs přizpůsobily velice rychle, mimo jiné i proto, že API pulseaudia je mnohem jednodušší, než alsy.

[Michal Kubeček]

To je teď bohužel čím dál častější. Ještě teď se mi otvírá kudla v kapse, když si vzpomenu, v jakém stavu bylo KDE4, když ho dali do OpenSuSE jako default, a v jakém, když vyřadili KDE3… Sice chápu, že vývojáři potřebují, aby někdo nové verze a funkce testoval, ale oni by zase měli chápat, že čím dál víc lidí používá linuxové distribuce k práci a potřebují, aby fungovaly a aby jim jejich udržování v provozuschopném stavu zabralo co nejméně času.

[little.owl]

Tak Linux je ted trochu rozhrabany, to nelze nevidet, jde jen o to aby to nebyl trvaly stav a trochu se to stabilizovalo.

Co je jeste krom treba BTRFS zasadniho na obzoru?

[petr_p]

firewalld.

[pavlix]

+1

[melkors]

Nech toho. Uz ted mam husi kuzi

[Vskutečnosti Saýc]

firewalld je opravdu retardovane reseni, hodne fedory.

Ne, vazne. sveho casu prinasela fedora nektere zajimave veci, ale ted uz je to fakt semeniste uplnych sracek.

[pavlix]

Ne, vazne. sveho casu prinasela fedora nektere zajimave veci, ale ted uz je to fakt semeniste uplnych sracek.

Nepoužívej.

[Vskutečnosti Saýc]

Nebudu. Je ale neprijemne, kdyz pak lide z fedory zneuzivaji svou politickou moc, a nuti svoje spatna reseni vsem ostatnim. Je to hezky videt v tehle diskusi.

[pavlix]

Nebudu. Je ale neprijemne, kdyz pak lide z fedory zneuzivaji svou politickou moc, a nuti svoje spatna reseni vsem ostatnim. Je to hezky videt v tehle diskusi.

V téhle diskuzi jsou vidět lidi kteří diskutují o zajímavých věcech ze světa OSS a lidi kteří přejí druhým fyzickou újmu. Jsem rád, že se řadím společně s dalšími do té první skupiny.

[Martin Mareš]

Asi proto, ze jeho napady jsou vetsinou velmi dobre, zduvodnene a i celkem promyslene.

Po pravdě řečeno, vůbec mi tak nepřijdou. Spíš je to poměrně náhodný mix skvělých nápadů s naprosto mizernými, přičemž Lennart je bohužel příliš namyšlený na to, aby mezi nimi uměl rozlišovat.

[dustin]

S tím zcela souhlasím. Bohužel se dle mého názoru jeho nedotažené projekty příliš rychle dostávají koncovým uživatelům do běžných distribucí. Uznávám, že to není jeho chyba, jenom nechápu, proč mu to velké distribuce tak "žerou" :)

[kralyk z abclinuxu]

Mimochodem, jaký je váš názor na Launchd?

[little.owl]

Libi se mi to, kolegove maji Apple zde a chodi to velmi dobre; v nekterych vecech to ma blizko k systemd. Muzete si to zkusit, ve FreeBSD maji port.

[little.owl]

Stejne hezke, jak je systemd popularni.

Cas Thu Apr 5 13:24:55 BST 2012 a 274 prispevku!

A good job, Lennart.

[dustin]

Tak váhám, dosud jsem tě bral docela vážně, že o tom něco opravdu víš.

[little.owl]

A to byla chyba!

[lmb]

Asi žiju v paralelní realitě, ale opravdu jsem nenarazil na problémy se SysV nebo BSD initscripty, které by nešly rychle vyřešit díky jejich velké flexibilitě a jednoduchosti. U systémů, které je zavádí sekvenčně si ani nevzpomínám, že by se muselo posledních pár let zpátky vůbec něco napravovat. Takže "potřeba" nahrazovat tenhle lety ověřený způsob mi připadá jako umělá a problém jako virtuální. Čím dál tím víc si cením konzervativního přístupu vývojářů *BSD.

To jsem utíkal od adminování Win$ k jednoduchosti a průhlednosti *nixů, aby se mi to jak bumerang vracelo od desktop-nerdů ?! Nejsem proti inovacím, ale občas mám z některých jedinců pocit, že mají místo mozku <|>

[pavlix]

Vždyť stačí přejít na nějaké BSD :).

[lmb]

Pokud se podaří najít sponzora, kterej bude za mě platit složenky, tak klidně

[pavlix]

Hledej šmudlo :).

[kralyk z abclinuxu]

Ok, tak když jsou init skripty tak supr, tak mi řekni, jak mám pořešit démony cups, httpd a mysqld. Používám je dost zřídka, takže buď musí být neustále zapnuté (žere RAM), nebo je musím vždycky ručně zapína/vypínat (komfort nahouby).

[lmb]

/etc/rc.d/<název skriptu> {start|stop|restart|status|…}

nebo

/etc/init.d/<název skriptu> {start|stop|restart|status|…}
resp.
service <název skriptu> {start|stop|restart|status|…}

Tak jestli by měl být důvodem pro tak drastické změny nedostatek "komfortu", který je navíc hodně subjektivní, tak to teda potěš koště :(

[little.owl]

C'mon.

Dynamicke on-demand zapinani sluzeb jen jedna z nejlepsich veci systemd a manualni zapinani neni alternativa.

Drasticke? Zdrava evolution.

[kralyk z abclinuxu]

Nepochopil jsi otázku? Svůj init systém samozřejmě znám, vím jaké příkazy zadat, ale nechci - nerad dělám zbytečnou práci, kterou může udělat systém sám.

Tak jestli by měl být důvodem pro tak drastické změny nedostatek "komfortu", který je navíc hodně subjektivní, tak to teda potěš koště :(

Ty změny nejsou zdaleka tak drastické. Resp. zkus si někdy projít a přečíst všechny ty initskripty - nejsou o nic méně drastické než systemd/upstart/launchd/apod...

Ad komfort: Když připojuješ flashku k počítači, taky zadáváš v shellu příkaz mount? Skoro bych se vsadil, že ne, že radši prefeuješ komfort. No nic, jdu potěšit to koště...

[Gilhad]

Když připojuju flashku k počítači, tak zadávám v shellu příkaz mount pouze v případě, že chci připojit i nějaký filesystém na té flashce. Což není zdaleka vždy.

[little.owl]

Nevim jak vy, ale kdyz ja pripojuji flashku tak v 99.9% namountovat ten filesystem chci, a pokud ne, je jednoduzsi v tech 0.1% to jednim klikem umount-out.

A v pripade kdy to nikdy nechci - treba kdyz ta flaska je pouzivana pouze pro image embedded systemu - mam pro to special udev rule.

Ale kdyz vam to vyhovuje rucne mount-ovat .... proc ne ...

[Gilhad]

Me hlavne vyhovuje, kdyz system dela co mu reknu, misto abych musel sytemu rikat, co vsechno kdy nema delat (a netusil, kde vsude jeste musim neco zakazat, aby to fakt nedelalo co nema). Proto jsem taky, mimo jine, odesel od Windows.

[pavlix]

Me hlavne vyhovuje, kdyz system dela co mu reknu, misto abych musel sytemu rikat, co vsechno kdy nema delat (a netusil, kde vsude jeste musim neco zakazat, aby to fakt nedelalo co nema).

Nelze očekávat, že všichni uživatelé a všichni vývojáři takového systému budou mít stejné osobní preference.

Proto jsem taky, mimo jine, odesel od Windows.

Tohle je podle mě typický anti-windows komplex. Pokud se něco na Linuxu nedělalo, protože se to ještě moc neumělo, tak je to vždycky výhoda Linuxu a ne toho systému, který už to uměl :).

Souhlasím s tím, že je dobré, když je možné systém nakonfigurovat tak, aby byly tyhle automatiky vypnuté. Souhlasím s tím, že by bylo fajn, kdyby to šlo udělat jednodušeji než dnes. A taky souhlasím s tím, že je dobré, když existují distribuce pro lidi jako jsi ty, které ve výchozím nastavení mají tyhle věci vypnuté rovnou.

Jediné, v čem s tebou nesouhlasím je, že je jejich vypnutí jediná správná cesta pro všechny a že by tohle měla být ta rebelská cesta linuxových systémů.

Vždy máš možnost se podílet na distribuci, která je postavena dle tvých představ a pokud ty představy s někým sdílíš, nemusíš na to ani být sám. Samozřejmě to nemusí být distribuce postavená na Linuxu, ale klidně může.

[Gilhad]

Nelze očekávat, že všichni uživatelé a všichni vývojáři takového systému budou mít stejné osobní preference. Samozrejme ne. A ani jim to nenutim. Ale na druhou stranu to, ze existuje uzivatel, ci vyvojar, ktery chce aby Linux mel vsechny necnosti Windows a nebyl od nich k rozeznani (snad krome loga) jeste neznamena, ze vsichni musi byt nadseni z tohoto vyvoje a drzet hubu a krok. Na druhou stranu mam dost dobrou sanci, ze na moji distribuci (Gentoo) budou tyto veci jeste hodne dlouho pouze volitelnou casti, ktera se instalovat nemusi.

Stejne jako jsou volitelne KDE, nebo Gnome a komu nesednou, tak si vesele pouziva treba Fluxbox jako ja.

Tohle je podle mě typický anti-windows komplex. S Windows jsem delal dlouha leta a prakticky kazdy den me necim malym nastvaly. Vetsinou nejakou drobnou pitomosti, kde byly presvedcene, ze vi lip nez ja, co je pro me dobreho a tak se mi to pokusily vnutit misto toho, co jsem jim ja rikal. (Nebo nebyla jednoducha cesta jak jim rict, ze chci neco jednoducheho, bez jejich vmesovani a pruvodcu a opatreni, abych si nahodou nemohl prislapnout nohu, ktera sla tak daleko, ze se vlastne moc nedalo chodit). S Linuxem delam dlouha leta a prakticky kazdy den me necim malym potesi. Takze ted uz dlouha leta Windows nepouzivam vubec. Kdo je chce pouzivat, tak at si je pouziva, to mi nevadi, dokud me nenuti k temuz.

Ze system neco neumi povazuju za naprosto normalni jev, ale radeji budu mit system, ktery umi veci jen par (ale tech ktere potrebuju) a nehaze mi klacky pod nohy kdyz chci neco s cim nepocital nebo neumi (protoze autori pocitaji s tim, ze uzivatel je zodpovedny za sve ciny a dokaze zhodnotit co zrovna dela), nez system, ktery sice umi veci hodne (a spoustu takovych, ktere po nem nechci) ale ne dobre a zuby nechty se brani, kdyz chci neco udelat po svem (protoze autori predpokladali, ze uzivatel muze byt naprosty pitomec a je nutno mu zabranit, aby si i pri veskere snaze ublizil)

A kdyz jsme u tech komplexu - krome anti-windows komplexu mam urcite i anti-bahno komplex (vyhnu se bahnu, pokud je rozumna cesta okolo), anti-hovno komplex (neslapnu do hovna, pokud se da slapnout jinam), anti-balet komplex (balet me nebavi, tak nebaletim) a milion dalsich anti-neco komplexu, kdyz nedelam ci nepouzivam neco, co je mi neprijemne a nepoterbuju to k zivotu.

[pavlix]

Já bych to shrnul do jediné věty: Máš možnost výběru.

[Gilhad]

Zatim mam a jsem tomu rad. Jen mam obavy, aby to neskoncilo jako s akonadi/nepomukem, ktery byl puvodne volitelny a pak bez nej KDE nejely (nebo aspon ta dulezitejsi pulka). Takze zatim si vybiram nepouzivat systemd, cimz zrejme demonstruju svuj anti-systemd komplex (stejne jako jsem si kdysi vybral nepouzivat Windows).

Stejne tak si zatim, dokud to jde vybiram nepouzivat grub2, protoze mi neprinasi nic uzitecneho, jen mnohem slozitejsi konfiguraci, kterou je navic po oprave treba pregenerovat (misto jednoduche opravy jednoho textaku).

Stejne tak jsem delsi dobu odolaval udev, nez to zaclo byt prilis pracne. Pak jsem vetsinu problemu s nim poresil automatickym skriptem, co mu maze konfiguraky, takze zivot s nim je celkem snesitelny.

Stejne tak jsem odolaval HALu, ktery nastesti casem zahynul na ubyte, ale jednu dobu jsem ho stejne potreboval, aby mi bezelo to, co predtim a potom bezelo v pohode bez nej.

Ale nejak me nebavi, jak se porad nekdo snazi ostatnim vnutit svuj uzasny komplikator a orezava moznosti jak se bez nej obejit - a systemd se zda byt ze stejneho hnizda.

Kdo chce, at si to pouziva, treba mu to neco prinese, ale byl bych rad, aby byla pro me a ty ostatni zachovana moznost vyberu. (A tim myslim moznost vybrat si, ze to vubec nebudu instalovat, nikoli, ze to povine nainstaluju a jen tomu slozite zabranovat obtezovat prilis, jako je tomu napr. prave u akonadi v KDE)

[kralyk z abclinuxu]

Afaik pro grub2 nemusíš generovat konfiguráky, pokud nepotřebuješ pokročilý featury, dá se to nakonfigurovat v podstatě stejně jako grub legacy (osobně taky preferuju legacy-style, ale kdoví, možná bude někdy potřeba pokročilejší správa LVM, RAID, apod...). Případně taky existuje syslinux, že.

Jinak naštvání na Akonadi plně chápu, mám na něj stejný názor, ale přirovnávat ho k udevu mi přijde mimo, to je úplně jiná situace (minimálně to nepasal ani Lennart ani KDE Team, nýbrž GKH!). Imho pokud jsi natolik konzervativní, že ti vadí udev, Linux pro tebe pravděpodobně není vhodná volba.

[Gilhad]

nevadi mi udev jako takovy, vadi mi, ze jedina sitova karta v systemu je eth5 nebo eth6 nebo jine obskurni cislo a pulka veci prestane fungovat, protoze nekdo jednoduse spolehal na existenci eth0 u systemu s jedinou sitovkou. A podobne uzasne automatizmy (tusim, ze cdromky/dvd to same). Ale nakonec jsem prisel na to, co vsechno mazat pri vypnuti pocitace a od te doby uz dela problemy jen zridka.

Je mi celkem ukradene, kdo co psal, me zajima, kolik prace mi to pridela.

Linux se mi zda vhodna volba, aspon zatim jsem nic lepsiho nenasel. To, ze mi na nem par veci vadi jeste neni duvod zavrhnout celou platformu. Dovedu si predstavit, ze by byl system, co by mi vyhovoval jeste lip, ale zatim jsem ho nepotkal.

[pavlix]

Linux se mi zda vhodna volba, aspon zatim jsem nic lepsiho nenasel. To, ze mi na nem par veci vadi jeste neni duvod zavrhnout celou platformu. Dovedu si predstavit, ze by byl system, co by mi vyhovoval jeste lip, ale zatim jsem ho nepotkal.

Takhle to mám se spoustou věcí.

[pavlix]

Takze zatim si vybiram nepouzivat systemd, cimz zrejme demonstruju svuj anti-systemd komplex (stejne jako jsem si kdysi vybral nepouzivat Windows).

Proti tomu nemůžu říci půl slova. Takže +1.

Stejne tak si zatim, dokud to jde vybiram nepouzivat grub2, protoze mi neprinasi nic uzitecneho, jen mnohem slozitejsi konfiguraci, kterou je navic po oprave treba pregenerovat (misto jednoduche opravy jednoho textaku).

Mně vyhovuje. Protože jsem vždycky chtěl používat LVM pro celý systém. Někdy v kombinaci s RAIDem. Grub2 používám od Debianu 6 a dalších distribucí z podobné doby.

Ale nejak me nebavi, jak se porad nekdo snazi ostatnim vnutit svuj uzasny komplikator a orezava moznosti jak se bez nej obejit - a systemd se zda byt ze stejneho hnizda.

Na vnucování mám stejný názor jako ty. Takže pokud bude existovat nějaký slušný obecný návod, jak třeba udržovat Fedoří balíčky obojetné vzhledem k systemd i sysvinit, tak mi nedělá problém udržovat obojí (stejně to dělám kvůli RHEL/CentOS 6). Momentálně by se hodil někdo, kdo zreviduje relevantní části Fedora wiki. Já to dělat nebudu, protože vystačím se systemd, ale pokud budu mít pocit, že je zájem, tak všechny své balíčky budu udržovat sysvinit-compatible (momentálně to jsou dva, Strongswan a Racoon2).

Kdo chce, at si to pouziva, treba mu to neco prinese, ale byl bych rad, aby byla pro me a ty ostatni zachovana moznost vyberu.

Naprosto souhlasím. Věnuj aspoň trochu snahy zachování možnosti ve své oblíbené distribuci. Pokud se stane, že při své snaze narazíš na mě, vyhovím co jen to půjde.

[tomasgn]

Tohle je podle mě typický anti-windows komplex.

proc lidi, kteri chteji aby to vypadalo jako windows, fungovalo jako windows, pouzivaji linux, a snazi se do jej za kazdou cenu tem windows pripodnobnit jak vzhledem, tak chovanim? windowsovateni linuxu je za poslednich 12 let dost videt. k tomu se jeste pridava protlacovani zbytecnych, nesmyslnych ci nedotazenych projektu typu systemd, pulseaudio, nepomuk.

pripada me, ze pavlix a little.owl jsou na systemd nejak zahackovani, mozna na nem primo pracuji, a proto maji zajem to protlacit. jinak kdo to zkusil, je spis znechucen.

[pavlix]

proc lidi, kteri chteji aby to vypadalo jako windows, fungovalo jako windows, pouzivaji linux, a snazi se do jej za kazdou cenu tem windows pripodnobnit jak vzhledem, tak chovanim?

Na tuto manipulativní otázku nemůžu odpovědět :). Já bych windows pro svoji práci používat nemohl nebo bych musel práci změnit.

pripada me, ze pavlix a little.owl jsou na systemd nejak zahackovani, mozna na nem primo pracuji, a proto maji zajem to protlacit. jinak kdo to zkusil, je spis znechucen.

Ne. Pouze jsem měl tu čest napsat pár initskriptů a pár systemd unit.

To první mě zbytečně nutí zabývat se mnohořádkovým skriptem, který v systému funguje v mnoha instancích stejně. To druhé znamená napsat pětiřádkový config z něhož tři řádky jsou metadata.

jinak kdo to zkusil, je spis znechucen.

Tento názor ti neberu, pouze ho nesdílím.

Ale jesti všichni ti znechucení mají ve zvyku na technické argumenty reagovat ad hominem, tak mi vůbec není líto, že se lišíme i v názoru na systémový init.

[pavlix]

Ad komfort: Když připojuješ flashku k počítači, taky zadáváš v shellu příkaz mount? Skoro bych se vsadil, že ne, že radši prefeuješ komfort. No nic, jdu potěšit to koště...

No, lidi jsou různí. V dřevních dobách linuxu si někteří zvykli, že co si nenamountuješ, to nemáš. A cokoliv, co v linuxu funguje a dříve by to nešlo, tak je automaticky špatně :).

[little.owl]

+1

[tomasgn]

kdyz potrebuju pro sebe nebo nekoho jineho spustit apache, cups, nebo cokoliv jineho, tak to radeji spustim sam, nez aby to za mne spoustel nejaky prechytraly subsystem kdykoliv se nekdo odkudkoliv pokusi na tyto sluzby sahnout. taky to totiz muze byt bot, hledajici diry v systemu.

[little.owl]

A systemd vam brani to tak nastavit ?

[tomasgn]

ja to nechci nastavovat v systemd, protoze systemd vubec nechci. chci pouzivat klasicke init skripty. na linuxovych distribucich je pekna moznost volby. pokud bude v distribuci moznost volby, tak me to staci. jestlize se vsak ze systemd stane jedina moznost, bude cas na zmenu. treba gentoo, pokus se nenanazi, nebo smerem k BSD systemum.

[pavlix]

ja to nechci nastavovat v systemd, protoze systemd vubec nechci.

To ovšem není náš problém, že.

chci pouzivat klasicke init skripty. na linuxovych distribucich je pekna moznost volby. pokud bude v distribuci moznost volby, tak me to staci.

Tak se můžeš postarat o to, aby ta možnost byla. Nejmenší, co můžeš udělat, je používat nějakou distribuci, kde ta možnost je a v případně problémů se sysvinitem si dopsat/opravit initskript a dát ho jako přílohu bugreportu se žádostí o začlenění opravy.

jestlize se vsak ze systemd stane jedina moznost, bude cas na zmenu. treba gentoo, pokus se nenanazi

Pozdě.

nebo smerem k BSD systemum.

Může být. Pokud je pro tebe systemd takovou překážou a zároveň bude linuxovým distributorům natolik vyhovovat, že se vaše preference nepotkají, tak bych na tvém místě BSD volil.

[pavlix]

kdyz potrebuju pro sebe nebo nekoho jineho spustit apache, cups, nebo cokoliv jineho, tak to radeji spustim sam, nez aby to za mne spoustel nejaky prechytraly subsystem kdykoliv se nekdo odkudkoliv pokusi na tyto sluzby sahnout. taky to totiz muze byt bot, hledajici diry v systemu.

A kdo ti v tom brání? :)

[tomasgn]

a proc bych tedy mel mit v systemu bullshit zvany systemd?

[Vskutečnosti Saýc]

Protoze se pavlix rozhodl a chce to vsem vnutit.

Muzeme jen doufat, ze ho prejede auto nebo tak neco.

[pavlix]

Protoze se pavlix rozhodl a chce to vsem vnutit.

Tvé obvinění je nepodložené a v příkrém rozporu z tím, co tady píšu. Doporučuju pořídit si slabikář.

Muzeme jen doufat, ze ho prejede auto nebo tak neco.

Jojo. Můžeš doufat, že mě přejede auto a já přestanu na Abclinuxu obtěžovat lidi svými názory. Já naštěstí takový primitiv nejsem, takže ti přeju, aby se ti dařilo dobře.

[Vskutečnosti Saýc]

Pokud tvemu "systemd se musi nacpat do vsech distribuci a pokud ti to nevyhovuje tak mas smulu" nechces rikat "vnutit" tak jak tomu tedy chces rikat?

[pavlix]

"systemd se musi nacpat do vsech distribuci a pokud ti to nevyhovuje tak mas smulu"

To není moje, nejspíš cituješ někoho jiného.

[Vskutečnosti Saýc]

Mozna ne doslova, ale neco velmi podobneho. Nebo to napsal tvuj fake little.owl, no.(*)

Za chvili se vratim s citacemi.

(*): humor spocivajici v naznacovani ze nepopularni nazor o systemd mas jenom ty, tak predstiras ze jsi vic lidi aby to bylo zvucnejsi.

[pavlix]

Mozna ne doslova, ale neco velmi podobneho. Nebo to napsal tvuj fake little.owl, no.(*)

Veřejná omluva a uznání, že jsi vůl, by bohatě stačily :).

[little.owl]

Co by clovek mohl cekat od junkies ...

[pavlix]

Nebuď tak přísný, klone můj :D.

[little.owl]

My se skutecne shodnem ve vetsine veci, s vyjimkou Wayland vs. X, ale i tam doslo posledne k posuvu.

[pavlix]

Jen si nepamatuju na čí straně k tomu posunu došlo :).

[little.owl]

Tedy .... !! Ale to by bylo OT.

[pavlix]

Tak ono je to jednoduché. Člověk s chutí přijímat novinky se snaží posoudit racionálně jejich kvalitu a použitelnost. Člověk s chutí konzervovat současný stav se bude zabývat pouze nevýhodami a to ještě nepohrdne ani těmi smyšlenými nebo už historickými.

Viz tato diskuze, kde se několik diskutujících opírá o lživé tvrzení, že systemd nepodporuje fake systémové služby bez běžícího démona. A je jim jedno, že to tu už někdo vyvrátil i konkrétní ukázkou konfigurace takové služby.

[little.owl]

tu už někdo vyvrátil i konkrétní ukázkou konfigurace takové služby.

To jsem byl tusim ja. Nicmene je stale totez - nenahlednuti do elementarni dokumentace - man pages - a nekolika ukazkovych prikladu. S tim nic nenadelame.

[Martin Mareš]

Viz tato diskuze, kde se několik diskutujících opírá o lživé tvrzení, že systemd nepodporuje fake systémové služby bez běžícího démona. A je jim jedno, že to tu už někdo vyvrátil i konkrétní ukázkou konfigurace takové služby.

Ne tak úplně – zatím nikdo neukázal, jak systemd přimět, aby uměl vypisovat i stav takové služby.

[pavlix]

Ne tak úplně – zatím nikdo neukázal, jak systemd přimět, aby uměl vypisovat i stav takové služby.

To je podle mého názoru samostatné téma. Protože stav služby není jednoznačně definován. Z jednoho pohledu spočívá v informaci, jestli je služba aktivována (uživatelem nebo jako závislost). Z druhého pohledu spočívá v informaci zda služba stále funguje podle očekávání (tedy že do ní nebylo zasáhnuto). Ze třetího pohledu je to textová informace, která říká říká hromadu informací o akutálním stavu démona.

Shoda nad definicí IMO nepanovala ani dosud, každá služba to měla jinak, takže třeba service --status-all bylo vždy nesmyslné a nepřehledné, takže se rád dozvím tvůj soud.

Zatímco zjištění stavu služby s démonem považuju za klíčové a systemd ho zvládá mnohem lépe běžný initskript, zjištění stavu služby bez démona osobně nevyužívám právě proto, že vůbec netuším, co by mi to přineslo.

Fake služba bez démona nemůže v pravém smyslu spadnout, když neběží. Takže jediné, co od ní očekávám je, že ji lze aktivovat či deaktivovat, tedy provést konfiguraci nebo uvést subsystém do výchozího stavu.

Jsi jeden z mála, kdo zde dokáže nějak argumentovat „z druhé strany“, takže mě odpověď na tuhle otázku hodně zajímá.

[little.owl]

Jen bych doplnil, ze toto ve sve podstate neresi ani SysV, a radsi nez zavadeni ExecStatus jsem pro reseni s jednoduchym monitovacim daemonem spoustenym pres dependency - jak jsem popsal vyse; coz muze ulehcit zivot i lidem, kteri systemd vubec pouzivat nechteji - stejne jako vetsina ostatnich "brutalnich" pozadavku kladenych systemd na sluzby.

[Martin Mareš]

Já myslím, že nemožnost definovat jednotným způsobem, co znamená zjištění stavu služby, není dobrý argument pro to, aby systemd nic takového neuměl. Naopak: správné řešení je myslím umožnit službám, aby definovaly libovolné akce a klidně několik různých způsobů zjišťování stavu nechat koexistovat. Kód systemd to IMHO nijak výrazně nezkomplikuje a umožní to autorům služeb, aby experimentovali a třeba časem zkonvergovali k několika běžným typům akcí, které se pak standardizují.

Trochu obecněji: Myslím, že jedním z hlavních důvodů úspěšnosti UNIXu je, že především dává nástroje k tomu, aby lidé udělali, co potřebují, místo aby motivován nějakou hlubokou (a pravděpodobně značně egocentrickou) filosofií nakazoval, že nějaký problém má jedno jediné správné řešení. S programovacími jazyky je to podobné: střezme se jazyků, jejichž autoři v záchvatu svatého nadšení pro záchranu světa usoudili, že goto je zlo, jež je třeba vykořenit, takže ho neimplementují.

[pavlix]

Já myslím, že nemožnost definovat jednotným způsobem, co znamená zjištění stavu služby, není dobrý argument pro to, aby systemd nic takového neuměl. Naopak: správné řešení je myslím umožnit službám, aby definovaly libovolné akce a klidně několik různých způsobů zjišťování stavu nechat koexistovat. Kód systemd to IMHO nijak výrazně nezkomplikuje a umožní to autorům služeb, aby experimentovali a třeba časem zkonvergovali k několika běžným typům akcí, které se pak standardizují.

Jak už jsem psal dříve. Nijak zvlášt mi na tom nezáleží, ale nic proti tomu nemám.

Kód systemd to IMHO nijak výrazně nezkomplikuje a umožní to autorům služeb, aby experimentovali a třeba časem zkonvergovali k několika běžným typům akcí, které se pak standardizují.

Komplikace je v tom, že pokud se systemd bude jakkoli zabývat stavem, tak člověk očekává, že dotaz na stav nebude mít vedlejší efekt. Tudíž buď musí systemd ponechat službu ve stavu failed nebo ji musí kontrolovat pravidelně a umožnit tak různé restarty apod.

Prostě nepovažuju to za triviální.

[little.owl]

... a umožní to autorům služeb, aby experimentovali a třeba časem zkonvergovali k několika běžným typům akcí, které se pak standardizují.

Jenze tohle presne nejde. U systemd je zavazek dluhodobe stability interface, viz. zde a pokud bude neco oficialne podporovano v release, bude to podporovano i v budoucnosti a proto je treba byt, IMHO, velmi velmi opatrny.

[Lol Phirae]

Zavazovat se, že nějaké rozhraní zůstane stabilní, má možná smysl tehdy, když je stabilní ta věc sama. Pokud Lennart považuje ten svůj těžce experimental alfa výtvor v této fázi za stabilní, tak je to s ním ještě horší, než jsme si mysleli.

[little.owl]

Lennart nebyl jediny, kdo se podilel na specifikaci interface a zazil zde horke chvile, plno veci bylo odmitnuto a braly se v uvahu i jine podobne projekty se kterymi jsou jiz letite zkusenosti - Apple launchd, Solaris SMF etc.

Prominte, ale evidentne o tom vite kulovi a pouze se negativne vymezujete, aniz byste prinesl jediny fakticky argument. Netyka se to pouze teto zalezitosti a pomalu a jiste se zacinate dostavat na trolli cestu.

[Martin Mareš]

Není problém nějakou část rozhraní prohlásit za experimentální a explicitně říci, že se může kdykoliv změnit.

[Martin Mareš]

... a letmé přečtení onoho Interface Stability Promise prozrazuje, že to o některých interfacech už takto deklarováno je.

[pavlix]

Ale tak uznej, že tohle je hodně klíčová věc. Sice ne tak jako tabulátory v makefajlech, ale precedenty máme :).

[Martin Mareš]

Ale tak uznej, že tohle je hodně klíčová věc.

Klíčové především je zbavit se naivní představy, že se všechny služby na světě dají nacpat do jedné typizované krabičky. Svět prostě je složitý a ten počítačový zvlášť, takže neobvykle se chovající služby se určitě objevovat budou. Takže systemd coby nástroj pro ovládání systémových služeb by se měl této realitě přizpůsobit a nabídnout obecný mechanismus pro definování nových akcí, nikoliv nutit ostatní k tomu, aby se všechny služby chovaly jedním způsobem.

Stabilita rozhraní je až sekundární záležitost, o té se dá bavit až v okamžiku, kdy program rozumně funguje. A k tomu ještě některé aspekty systemd mají daleko.

[little.owl]

To ukaze cas a praxe, interface neni frozen, a bude se rozsirovat, postupne jak budeme ziskavat zkusenosti.

[pavlix]

Znám tě a zvlášť u tebe se za všech okolností snažím brát v potaz to, co řekneš nebo napíšeš. Ale v tomhle příspěvku už nevidím žádný nový argument ani nic konkrétního, co by vedlo na posunutí mého názoru.

Že systemd není dokonalý, na tom se shodneme. Že není dokonalý sysvinit s initskripty, na tom jsme se taky shodli. Otázka tedy je, zda je systemd pro svůj účel použitelný (podle mě ano) a zda jeho návrh přináší zlepšení oproti sysvinit (podle mě ano) a zda je to celé dobře implementováno (zde nemohu úplně sloužit, ale zdá se mi funkční).

Takže systemd coby nástroj pro ovládání systémových služeb by se měl této realitě přizpůsobit a nabídnout obecný mechanismus pro definování nových akcí, nikoliv nutit ostatní k tomu, aby se všechny služby chovaly jedním způsobem.

Mně osobně variabilita možností v systemd přijde vcelku dostatečná. Mám tam taky své corner casy ohledně spouštění služeb rozdělených na více démonů bez supervisingu, takže tam by bylo ještě celkem o čem mluvit. Konstruktivně se dá diskutovat i o ExecStatus.

Možná se později dozvím o něčem dalším, ale proč mi připadá, že v této diskuzi se už jenom recykluje?

[little.owl]

Mate pravdu, nicmene jakmile zacnete neco - i nestabilne - podporovat a uzivatele to zacnou pouzivat, je toho tezke se zbavit, bez ohledu na to jak se ona vec ukazala byti spatnou.

Systemd adoptoval, v malem, kernel development model - experimental development branches a jakmile se to osvedci a dostane do mainstream a uzivatele to zacnou pouzivat, bude se to zpetne kompatibilne podporovat i do budoucna. Uvidime, zda to bude v praxi fungovat.

[kralyk z abclinuxu]

Protoze se pavlix rozhodl a chce to vsem vnutit.

Ale vždyť je jasně řečeno, že udev půjde i bez systemd.

Tažke si v podstatě můžeš nainstalovat na jakékoli distro víceméně jakýkoli init systém.

Ty řeči o "vnucování sytemd" mi přijdou už dost histerické.

[pavlix]

Ty řeči o "vnucování sytemd" mi přijdou už dost histerické.

Mně přijde celý ten člověk, co tu píše o přejíždění autem, hysterický.

[pavlix]

a proc bych tedy mel mit v systemu bullshit zvany systemd?

A proč bych se já měl zabývat tím, co si ty instaluješ do systému?

[Bubak]

Jsou sluzby, ktere si taky zapinam rucne, treba sambu, kdyz jsem v praci a potrebuju neco kopirovat, tu jmenovanou mysql, kdyz jednou za par mesicu neco potrebuju, cups, kdyz potrebuju neco vytisknout. A nepripada mi to nijak nekomfortni, delam to jednou za cas, obvykle v ten den, kdy tu sluzbu potrebuju, jednou. A rozhodne mi to pripada podstatne lepsi, nez aby se neco podivneho v systemu snazilo hadat, co za sluzbu mi asi ma pustit, kdyz si mi na klavesnici lehne kocka (ctyrnoha, aby nebyly omyly).

[pavlix]

Jsou sluzby, ktere si taky zapinam rucne, treba sambu, kdyz jsem v praci a potrebuju neco kopirovat, tu jmenovanou mysql, kdyz jednou za par mesicu neco potrebuju, cups, kdyz potrebuju neco vytisknout.

A máš nějaký důvod se bát, že by tohle v budoucnu už nešlo? Tedy kromě nedostatku informací.

A rozhodne mi to pripada podstatne lepsi, nez aby se neco podivneho v systemu snazilo hadat

To skoro vypadá, jako bys chtěl tvrdit, že nějaký běžně používaný init systém toto hádá. Obávám se, že zde opět nedostatek informací nebude na mé straně.

[Bubak]

A máš nějaký důvod se bát, že by tohle v budoucnu už nešlo? Tedy kromě nedostatku informací.

Ne, ale to jsem take nikde nepsal.

To skoro vypadá, jako bys chtěl tvrdit, že nějaký běžně používaný init systém toto hádá.

Opet ne, ale tady nedostatek informaci priznavam, reaguji na predrecnika. Sam jsem to nezkoumal, koukal jsem jen na veci pro me relevantni. Sypu si popel na hlavu.

[pavlix]

Ne, ale to jsem take nikde nepsal.

Tedy díky.

Opet ne, ale tady nedostatek informaci priznavam, reaguji na predrecnika. Sam jsem to nezkoumal, koukal jsem jen na veci pro me relevantni. Sypu si popel na hlavu.

Chápu, že ne každý chce pečlivě sledovat vývoj init systémů. Já jen že se místní flame zbytečně vyhrotil :).

[little.owl]

Ja si jen nejsem jist, jestli ten konzervatismus vyvojaru BSD neni spise vynucen nedostatkem zdroju a lidi, a vyssi koncetraci zaslouzilych vyvojaru

[tomasgn]

doufam, ze jim ten konzervativismus vydrzi, aby bylo kam utect, az se z linuxovych distribuci stanou vlastnim zivotem zijici "Windows s jadrem Linux".

[pavlix]

Vždycky se můžeš podílet na tom, co ti vyhovuje a hlásit se k tomu, co ti vyhovuje :).

[100% Lenin]

To vypadá na revoluci. Nebo na kontrarevoluci užitečných idiotů uprostřed linuxu. :D

[Vskutečnosti Saýc]

Je to jenom Mono 2.0

[mimi.vx]

http://en.wikipedia.org/wiki/Init