systemd 209

Lennart Poettering oznámil vydání nové verze systemd. Verze 209 vychází o tři měsíce později, než bylo plánováno. Nejnovější verze přináší spoustu nových vlastností. Lennart Poettering ale upozorňuje, že nový kód se musí stabilizovat a nepředpokládá se tedy nasazení této verze v distribucích s dlouhodobou podporou. Novinkou je například systemd-networkd (zprávička), systemd-socket-proxyd nebo podpora kdbusu.

20.2.2014 18:59 | Ladislav Hagara | Nová verze

Komentáře

[SPM]

Takže daemon na spouštění služeb už nám nastavuje i síť. Doufám, že je tam už i nějaký systemd-coffeed, který mi sám uvaří kafe - to bych narozdíl od ostatního alespoň uvítal.

[Bhua]

Co takhle integrovat xserver?

[Spike]

wayland

[frdrx]

Je to jiný daemon.

[potato]

Bojím se, že coffeed by vyžadoval Javu...

[anonym]

Takže daemon na spouštění služeb

pozor, tohle je pouze velice rozsireny omyl!!

jak vlastni nazev napovida, systemd je daemon na beh celeho systemu

[/sarcasm]

[TM]

A to je právě od základu špatná, stupidní, myšlenka.

[rastos]

Stupidní? Ne. Démonická!

[pavlix]

pozor, tohle je pouze velice rozsireny omyl!!

Sice jsi upozorňoval na sarkasmus, ale představa, že je systemd jen správce služeb skutečně je vcelku rozšířený omyl. Spíš je to integrovaný správce systému.

[pc2005]

Pokud je to služba, co je závislá na nějaké jiné při bootu, tak je to klidně možný .

[Václav "Darm" Novák]

Takže lidi co si ani nepřečtou o co jde komentujou… Ale že se divím. Má to v názvu systemd, netřeba číst, prostě je to blbě.

[snajpa]

A ted tak trochu otazka, tebe (a vas odpurce systemd) ten *BORDEL* v linuxovym svete bavi? Pridej k tomu fakt, ze nevyuzivame featury, ktery maji bejt k usnadneni zivota adminum, v kernelu jsou roky a userspace to nebyl schopny vyuzit? (mluvim o cgroups zejmena)...
Kdyz nikdo nebyl schopnej zvednout linou prdel a neco s tim udelat do ted, nedivte se, ze je to ted hyperaktivni Lennart. Nedivte se. A dekujte mu, ze vytahnul tu nasi stoku "GNU/Linux" z hnicich stojatejch vod statutu quo. Kazdej komercni Unix se pomalu z toho tisiciletyho legacy hnusu vymotal a nabidnul spravcum nastroje, co jim setri nervy. Jenom na Linuxu musime v roce 2014 resit podelany init skripty v Bashi! Seriozne! No preci pokrokova technologie 9000. Nebo vyuzivame kexec na 110%! Nebo cgroups, nebo... atd. atd. atd.
Prestante uz brecet and grow the fuck up.

[Václav "Darm" Novák]

Předpokládám že ta reakce měla jít trochu jinam

[snajpa]

Sry to melo bejt top-level, ne na tebe :)

[jc]

Ja teda v tomhle pripade preferuju stary bordel pred tim novym. Nic proti nastrojum, ale kdyz potrebuju klic na kolo, nechci s nim kupovat celej autoservis.

[benghi]

Nějak jsem nepochopil, co je na initu špatně. Mladým a talentovaným stačí, že je to starší než oni, ale mně nikoliv. Co je špatně na systemd je mi jasný z dálky - je to knedlí knedlí, který dělá moc věcí a když jednu z nich potřebuju upravit, přehrabuju se v klíčové části systému jak v senkrubni i v případě, kdy by to mohlo být přehrabování v oddělené části a případná chyba by nebyla fatální. Jenomže nebude, protože to někdo zahrnul do systemd.

[kavol]

Nějak jsem nepochopil, co je na initu špatně. Mladým a talentovaným stačí, že je to starší než oni, ale mně nikoliv.

krásně řečeno, +1

... mně by jen zajímalo, kde se ta hovadina staré = špatné učí, že je tím naočkováno tolik lidí, kteří se jinak chovají docela racionálně :-/

[rbt]

Kazda druha reklama o tom je - revolucni novinka kterou musite mit, jinak budete out a zustenete se svymi starymi kramy nekde v zadu. Pri te masivnosti a intenzite se to proste musi projevit nejen v nakupnim chovani, ale i pri jinych cinnostech. Osobnost a podvedomi jsou neoddelitelne. Stado frikulinu, kteri si nevidi dal nez na spicku nosu…

[kavol]

dík za pokus to objasnit, ale nějak to nedávám - přece tyhle věci jsou o tom, že si musíš koupit novej mobil, novej holicí strojek, nový auto, novou jinou šílenost, a nikoli o tom, že si místo mobilu máš koupit poštovního holuba, místo holicího strojku opalovací lampu, místo auta lokomotivu, zkrátka místo vylepšenýho výrobku daný kategorie nějakej úplně jinej výrobek, kterej danou potřebu taky nějak pokrývá, ale funguje úplně jinak ...

[sid]

Napr cele skriptovanie. Ved cisto prakticky scripty riesia inicializaciu, spravu, pripadne zavislost. Akurat kedze nemaju ziadny kontext tak pridavaju dalsi debilny stupen sledovania stavu cez pid a podobne genialnosti. To ze system sa rozhodol riesit vsetko je otazka ci je ok cesta ale to ze linux potrebuje nejaky inteligentnejsi init ako ma je snad zrejme?. Ci nie? Absolutna volnost a nekonecne riesenie tych istych veci tiez nie je ziadna vyhra.

[zofrey]

seriozne?

[j]

99% adminu po systemu chce, aby byl snadno administovatelnej - a to predevsim v situaci, kdy se neco podela. Kdyz vsechno funguje, tak nikoho nezajima proc a jak. Zarucis svym zivotem ze se tohle nikdy nepodela? Tezko co? A kdyz se to podela, tak to NIKDO nespravi - narozdil od "blbyho" scriptu.

Sem vazne moc zvedav, co budes delat, az se uzasnej systemd rozhodne, ze tvoje sluzba pada, a proto ji bude co par vterin restartovat ... a to presto, ze tvoje sluzba zcela spolehlive bezi, jen jeblo tomu kramu ...

[potato]

To jsou zase kydy.

Když se posere unita, je to evkvialentní posrání SysV init skriptu -- až na to, že ty skripty mají kvůli své komlikovanost mnohem ,zajímavější` možnosti posrání.

A když se posere sám init, tak se v obou případech posere sám init.

[martin.k]

rozbity init skript dava mnohem vetsi moznosti ho spravit nebo ohackovat nez deklarativni unita a init co ma veskerou logiku zadratovanou v binarce. myslim, ze pro admina kteryho ve dve rano vzbudi kvuli nejakymu prusvihu to je docela dulezity rozdil. navic i ty skripty se daji psat hezky a elegantne - viz openbsd.

sance ze se podela init co ma RSS par desitek kb a krome bugfixu se v nem prd deje je radove nizsi nez sance ze se podela systemd (ted myslim pid eins!) ktery ma RSS kolem nekolik mega a vari se tak rychle, ze se o tom vyplaci psat zpravicky na abclinuxu.

[Xerces]

+1

[R]

Urcite lepsie riesit init skripty v bashi ako debugovat init.

[Petr Tomášek]

Možnost nastavit pohodlně systém editací několika málo dobře zdokumentovaných textových konfiguráku rozhodně není „bordel“

[dustin]

Určitě, za předpokladu, že se mohu 100% spolehnout na systém, který s těmi konfigurákami pracuje. Stejně jako se mohu spolehnout na správnou funkci bashího interpreteru.

A to bude systemd ještě pár let trvat.

[sid]

Uzasny argument. Takym zrusite hocico. Dolezite ci sa chyby riesia a ako.

[dustin]

Pro mé klienty je především důležité, aby tam ty chyby nebyly. Je fajn, že bude po nahlášení vyřešena, ale to klientovi dobrý pocit z nefunkční služby nepřidá.

Ale souhlasím, že je také důležité, zda se řeší. Protože až se většina vyřeší, a do systemd budou přibývat jen kosmetické změny a drobné opravy, mohu takové řešení začít používat a užívat si jednoduché konfiguráky. A jo, těším se na to, proč ne.

[sid]

Vasi klienti uz maju teraz systemd? Co vam brani pockat rok dva?

[dustin]

Vždyť přesně to říkám Počkám si, až to bude spolehlivé a pak to klidně budu používat.

[Ivan]

Bashi? Initscripty na komercnich Unixech se pisi v ksh. Konkretne je to ksh89. ksh93 je volitelna moznost. Komercni Unixy - narozdil od Linuxu - nezabihaji do slepych ulicek a nevymysleji kola. Proto se bootovaci proceses 15 let nezmenil, a admini se muzou venovat dulezitejsim vecem.

PS: jako moc jsou cgroups realne pouzitelne? Kdo vsechno to pouziva v produkcnim prostredi?

[Michal Kubeček]

Bashi? Initscripty na komercnich Unixech se pisi v ksh. Konkretne je to ksh89. ksh93 je volitelna moznost.

Viděl jsem zdrojáky ksh, takže tohle mi rozhodně jako žádná velká výhra nepřijde.

jako moc jsou cgroups realne pouzitelne? Kdo vsechno to pouziva v produkcnim prostredi?

Celkem dost našich zákazníků. Jmenný seznam pochopitelně nečekejte.

[Ivan]

ksh opravdu neni zadnej zazrak. ksh preziva prave pouze konzervativismu komercnich Unixu.

[Michal Kubeček]

…a zákazníkům, kteří sice přešli na Linux, ale mají napsané hromady skriptů v ksh, kterým už dávno nikdo nerozumí a i kdyby snad ano, stejně by bylo moc práce přepsat je do bashe.

[Ivan]

Tohle bohuzel nefunguje. ksh89 pro Linux neexistuje - jedine snad jeho nahrada pdksh. Na Linuxu se da potkat tak max. ksh93 popr. ksh200, ktere uz jsou kompatibilni s Posix standartem. Bohuzel uz ale nejsou zpetne kompatibilni s ksh89.

Porad jsou to ale resitelne problemy. Narozdil od situace kdy se najaka obludna binarka zacne chovat divne.

[Michal Kubeček]

U našich zákazníků jde vesměs o ksh93 - ale nejde o init scripty, spíš o jejich vlastní, které občas narážejí na takové corner cases, že nad tím zůstává rozum stát.

Porad jsou to ale resitelne problemy. Narozdil od situace kdy se najaka obludna binarka zacne chovat divne.

To tvrdím od chvíle, kdy propaganda "init skripty jsou zlo" začala. Přeci jen připsat do skriptu "set -x", "ulimit -c unlimited" nebo si prostě jen nechat vypsat hodnotu určité proměnné, to je něco trochu jiného než debugovat chaotický "event based" model systemd. Za to mi o pár sekud (pokud vůbec) rychlejší boot opravdu nestojí.

[trekker.dk]

jako moc jsou cgroups realne pouzitelne? Kdo vsechno to pouziva v produkcnim prostredi?

Jedna z věcí, co mě na systemd sere: sebere mi cgroups a nedá se to vypnout.

[pc2005]

sebere mi cgroups

Počkej to jako fakt? FFFFUUUUU!

[marbu]

Zatim ne.

Ted ma systemd vlastni cgroups hierarchii (mountovanou napr. v /sys/fs/cgroup/systemd), ktera nema pripojeny zadny controller. Takze po sem ok.

Ale planuje se prepracovani cgroups v jadre, v ramci ktereho by se vytvoril userspace daemon nahrazujici dosavadni fs interface (ono ten fs asi zustane, ale bude "privatni" pro toho cgroups daemona) a zrusila moznost konfigurace nekolika nezavislych hierarchii. Napad pochazi od jadernych vyvojaru, kteri nejsou se soucasnym stavem spokojeni: jsou tu problemy s udrzbou kodu, vetsi odhalovani vnitrni implementace nez by bylo vhodne a pak zdani vzajemne nezavislosti hierarchii, kterou ale jadro nemuze realne zajistit.

Bohuzel to ale zatim smeruje k tomu, ze ten userpace daemon bude asimilovan do systemd a po teto zmene bude nutne pro pouziti cgroups komunikovat se systemd. Na druhou stranu to bude nejakou dobu jeste trvat, nez tahle zmena (v nejake budouci forme) nahradi dosavadni rozhrani.

[trekker.dk]

Ted ma systemd vlastni cgroups hierarchii (mountovanou napr. v /sys/fs/cgroup/systemd), ktera nema pripojeny zadny controller.

No vida, to jsem ani nevěděl, že jde. Jak se to mountuje?

ono ten fs asi zustane, ale bude "privatni" pro toho cgroups daemona

... takže se kvůli systemd bude rozbíjet zpětná kompatibilita rozhraní mezi jádrem a uživatelským prostorem? To chci vidět, jak tohle projde přes Linuse.

zrusila moznost konfigurace nekolika nezavislych hierarchii

Proti tomu bych nic neměl (i když se asi najdou jiní, kteří už nezávislost hierarchií využívají.) Proti tomu, že k tomu nebudu pořádně mít přístup a že mi to nějaký udělátor s klidem bude měnit pod rukama, už jo.

[marbu]

No vida, to jsem ani nevěděl, že jde. Jak se to mountuje?

Proste vypustis seznam controlleru, viz: Creating a Hierarchy and Attaching Subsystems

... takže se kvůli systemd bude rozbíjet zpětná kompatibilita rozhraní mezi jádrem a uživatelským prostorem? To chci vidět, jak tohle projde přes Linuse.

Ne. Tohle se nedela kvuli systemd, ale kvuli vyse zminenemu problemu s udrzovanim tohoto rozhrani. I kdyby ten cgroups daemon byl samostatny bez vazby na systemd, stejne by to dopadlo stejne. Nazor Linuse neznam, ale v tomto pripade jde o ponekud specialni pripad, tak tezko rict.

[trekker.dk]

Proste vypustis seznam controlleru

To mě napadlo, ale stroj s jádrem 3.2 mi to nesežral

# mount -t cgroup none /mnt/test/
mount: none already mounted or /mnt/test/ busy

Na jádře 3.11 to naopak použilo všechny controllery, taky nic moc:

pokus on /mnt/test type cgroup (rw,relatime,perf_event,blkio,net_cls,freezer,devices,cpuacct,cpu,cpuset)

Tohle se nedela kvuli systemd, ale kvuli vyse zminenemu problemu s udrzovanim tohoto rozhrani. I kdyby ten cgroups daemon byl samostatny bez vazby na systemd, stejne by to dopadlo stejne. Nazor Linuse neznam, ale v tomto pripade jde o ponekud specialni pripad, tak tezko rict.

I kdyby, řešení s použitím speciálního démona nedává smysl, protože by se ten démon musel stejně dodávat a aktualizovat s jádrem. Takové pokusy obejít neměnnost rozhraní do uživatelského prostoru už tu byly a Linus s tím lidi zatím vždycky poslal do háje.

[marbu]

To mě napadlo, ale stroj s jádrem 3.2 mi to nesežral ... Na jádře 3.11 to naopak použilo všechny controllery, taky nic moc:

No jo, máš pravdu, takhle jednoduše to nefunguje.

Pokud se hierarchie mountuje uplne bez parametru, má se za to, že se mají použít všechny controllery. Ten rozdíl mezi verzemi jader bude dán spíš tím, že v prvním případě už byl každý controller nějaké hierarchii přiřazen, a tak pokus o znovupřipojení selhal (If any of the requested subsystems are in use in an existing hierarchy, the mount will fail with -EBUSY.)

Nicméně připojit hierarchii bez controlleru vážně jde, musí se ale ješte extra předat jméno:

mount -t cgroup -o none,name=foobar foobar /sys/fs/cgroup/foobar

Viz.: When passing a name=<x> option for a new hierarchy, you need to specify subsystems manually; the legacy behaviour of mounting all subsystems when none are explicitly specified is not supported when you give a subsystem a name.

Reference: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

[marbu]

I kdyby, řešení s použitím speciálního démona nedává smysl, protože by se ten démon musel stejně dodávat a aktualizovat s jádrem. Takové pokusy obejít neměnnost rozhraní do uživatelského prostoru už tu byly a Linus s tím lidi zatím vždycky poslal do háje.

Tohle vymysleli právě jaderní vývojáři, což já ale nejsem, takže hádat se o tom se mnou nemá moc smysl :)

[trekker.dk]

Oni jaderní vývojáři jsou právě ta skupina, kterou Linus poměrně často posílá do háje

[David Jaša]

Viz starší jaderné noviny, probíralo se to docela dost posílání do háje tam moc nebylo. Věřím tomu, že kdyby měl Linus nějaké nepřekonatelné námitky, objeví se už dřív.

[little.owl]

Spise bych cekal nekolik iteraci hledani reseni, nez konec a zachovani stavajiciho stavu, ktery bude vytvaret postupem casu vetsi a vetsi problemy.

[trekker.dk]

probíralo se to docela dost posílání do háje tam moc nebylo

Taky ještě nikdo neposlal pull request na patche.

[David Jaša]

Viz starší jaderné noviny, probíralo se to docela dost posílání do háje tam moc nebylo. Věřím tomu, že kdyby měl Linus nějaké nepřekonatelné námitky, tak se objeví už dřív.

[little.owl]

Napad pochazi od jadernych vyvojaru, kteri nejsou se soucasnym stavem spokojeni: jsou tu problemy s udrzbou kodu, vetsi odhalovani vnitrni implementace nez by bylo vhodne a pak zdani vzajemne nezavislosti hierarchii, kterou ale jadro nemuze realne zajistit.

Ano, to je hlavni hybatel soucasnych a planovanych zmen, jinak by museli pomalu zacit modelovat nejakou virtualni architekturu uvnitr kernelu pro vnejsi svet.

[pavlix]

jako moc jsou cgroups realne pouzitelne?

Já bych řekl, že jsou velmi použitelné.

[Heron]

Proto se bootovaci proceses 15 let nezmenil, a admini se muzou venovat dulezitejsim vecem.

+1

[zippy]

CGroups su super; ale nie su pre kazdeho. Cgroupy davaju zmysel, ak si ich nebude moct nastavovat kazdy sam, ale bude jediny bod, cez ktroy sa budu nastavovat. A tym zatial systemd nie je, takze argument "systemd lebo cgrupy" je invalidny. Potom, naco mi je u serveru paralelny boot? Na desktope mozno, ale u serveru nejako postradam zmysel tejto feature. Najma, ked paralelny boot dokazu aj ine init systemy, ze jo. Jedine co systemd prinasa skutocne nove, je socket inicializacia: spustenie sluzby az ked sa niekto pripoji na socket. Ale ked som to naposledy sledoval, tak to systemd este nevedel, neviem ako teraz. Potom, kdbus - preco pouziva iny format sprav nez userspace dbus?

btw: vie mi niekto vysvetlit, preco systemctl show blah.scope nieco vypise namiesto zahlasenia chyby? to je jak keby cat /dev/blah vypisal nejake retazce a skoncil s navratovou hodnotou 0.

[trekker.dk]

Jedine co systemd prinasa skutocne nove, je socket inicializacia: spustenie sluzby az ked sa niekto pripoji na socket.

To je ta věc, která znemožňuje vypnutí služby, protože při připojení na ten socket se zase nastartuje?

[pavlix]

Obecně neznemožňuje, jen komplikuje z hlediska user interface. Znemožňuje pouze vypnutí dbusových služeb, a to se má údajně řešit až ve chvíli, kdy se bude systemd používat i jako náhrada dbusu, což jestli správně chápu začíná platit právě pro verzi 209.

[Michal Vyskočil]

Obecně neznemožňuje, jen komplikuje z hlediska user interface. Znemožňuje pouze vypnutí dbusových služeb, a to se má údajně řešit až ve chvíli, kdy se bude systemd používat i jako náhrada dbusu, což jestli správně chápu začíná platit právě pro verzi 209.

A pro jádra s podporou kdbus

[trekker.dk]

A dekujte mu, ze vytahnul tu nasi stoku "GNU/Linux" z hnicich stojatejch vod statutu quo.

... a hodil ji do žumpy. Děkujeme pěkně.

[pavlix]

A dekujte mu, ze vytahnul tu nasi stoku "GNU/Linux" z hnicich stojatejch vod statutu quo.

Já bych když už tak spíš děkoval klukům, co vytáhli ze sraček systemd a zařídili, že nezůstal kvalitativně na úrovni třeba Avahi.

[u2]

Tak tem uz vubec ne, ti se na to meli vykaslat a delat neco uzitecnejsiho (pistoli u hlavy jim snad nikdo nedrzel, nebo ano?). Pak by se systemd i jeho autor v te zumpe sam utopil a dnes by to tom bastlu nikdo ani nestek.

[trekker.dk]

Odhadl bych, že jim někdo u hlavy držel výplatní pásku.

[pavlix]

+1

[trekker.dk]

Slovníček pojmů:

BORDEL - někdo dělá něco jinak, než bych si představoval, že by to měl dělat.

Pridej k tomu fakt, ze nevyuzivame featury, ktery maji bejt k usnadneni zivota adminum, v kernelu jsou roky a userspace to nebyl schopny vyuzit? (mluvim o cgroups zejmena)

Námět na zamyšlení: možná to bylo kvůli tomu, že ty featury nejsou takový zázrak a lze se bez nich obejít.

Nebo vyuzivame kexec na 110%

Ještě nějaký příklad naprosto nezbytné technologie, u které si člověk nedovede představit, jak bez ní mohl ještě předevčírem žít? Pomíjím fakt, že na systémech se Secure Bootem se tahle věc vypíná.

Prestante uz brecet and grow the fuck up.

Vezmou si prášek na uklidnění, Mlamoj.

[Michal Kubeček]

Nebo vyuzivame kexec na 110%

Ještě nějaký příklad naprosto nezbytné technologie, u které si člověk nedovede představit, jak bez ní mohl ještě předevčírem žít?

No, pro mne je třeba představa života bez kdumpu nepříjemná docela dost.

[trekker.dk]

Já netvrdím, že kexec nikdo nevyužije. Tvrdím, že těch uživatelů a případů využití není tolik, aby to ospravedlnilo výkřiky o stojatých vodách a podobné. A už vůbec ne aby to vyžadovalo přístup "teď všechno předělám a komu se to nelíbí, s tím zatočí revoluce ten to má blbě"

Jen tak mimochodem: hádám, že kexec zřejmě využíváte. Není zajímavé, že vás k tomu nemusel nikdo nutit nastolením nového pořádku?

[Michal Kubeček]

Spíš naopak. Právě kdump je názornou ukázkou toho, jak se dnes nové koncepty zavádějí "přes mrtvoly", aniž by se řešila funkčnost zásadních věcí v systému. Když se implementoval UEFI "secure boot", kexec se prostě zakázal s tím, že kdump se dořeší dodatečně. Nedořešil se AFAIK dodnes. Když se do OpenSuSE narychlo cpal dracut, protože je hezky blýskavý a líp si rozumí se systemd, plymouthem a kdoví čím, ti, kdo se snažili střízlivně navrhovat, že bychom si nejdřív měli ověřit, jestli dracut poskytuje všechno, na co jsme z mkinitrd zvyklí, a nepřecházet na něj plně, dokud tomu tak nebude, byli ukřičeni jako zpátečníci; a teď se najednou strašně divíme, že kdump s dracutem nefunguje a že dá zatraceně hodně práce, aby zase fungoval.

[little.owl]

Neresi ten problem s dracut a kexec() Fedora zde? Muzete se poucit .

[Michal Kubeček]

Řeší, ale neposkytuje to kompletní funkcionalitu, kterou jsme měli s mkinitrd, takže na tom ještě bude hodně práce. Hlavně jde ale o názorný příklad toho, jak se dnes ukvapeně přechází na nová řešení, aniž by se ověřovalo, že už jsou opravdu schopna nahradit ta stará.

[little.owl]

Tak to s tim kexec() to je problem. S prechodem na dracut - co vam chybi? Obecne - je treba nahradit komplektni funkcionalitu starsiho reseni?

[Michal Kubeček]

S prechodem na dracut - co vam chybi?

V tuhle chvíli mi chybí kdump jako takový, protože současný stav je takový, že se sice spustí kdump jádro, ale místo minimálního initial ramdisku, který by vydumpoval systém, naběhne normální systém (tedy až na paměť blokovanou obrazem původního).

Obecne - je treba nahradit komplektni funkcionalitu starsiho reseni?

To je asi potřeba zvážit případ od případu. Třeba možnost dumpu přes CIFS by se asi dala po zralé úvaze oželet (pokud by to mělo být příliš komplikované přidat), ale zcela nefunkční kdump by podle mne měl být jednoznačný blocker.

[little.owl]

V tuhle chvíli mi chybí kdump jako takový, protože současný stav je takový, že se sice spustí kdump jádro, ...

Budu muset zkusit, co se deje ted ve F20 ...

To je asi potřeba zvážit případ od případu.

Presne tak. V rade pripadu se udrzba uz proste nevyplati.

[little.owl]

Budu muset zkusit, co se deje ted ve F20 ...

U F20 to v pripade Secure Bootu, kdy je disablovan kexec(), take asi nechodi a reseni bylo presunuto do F21. Bohuzel, /sbin/kexec musi byt take podepsan Microsoftem.

[little.owl]

Ohledne Secure Bootu, Linux jako minoritni platforma, bez schopnosti protlacit sve klice smerem k vyrobcum HW, nemel moc na vyber.

[trekker.dk]

Drtivá většina na superpočítačích, IIRC nadpoloviční většina na serverech, velká většina na mobilních zařízeních je "minoritní platforma"...?

[little.owl]

A na techto platformach je nejaky problem se Secure Bootem?

[Heron]

Nadávat na bordel v linuxovém světě je totéž, jako nadávat, že si z kostiček lega každý staví co chce.

[trekker.dk]

nadávat, že si z kostiček lega každý staví co chce.

... což ale není nic nového

[Ivan]

Hmm a to tak funguje detekce HW to ti nevadi? Vzdyt jsou to samy podelany scripty v bashi. TOHLE uz ma poreseny kazdej komerni Unix. Dokonce i Wokna maji vlastni jazyk s gramatikou, ktery popisuje jak hledat HW.

Napriklad, kdyz multipath detekuje SAN disky tak porovna kazdy disk s kazdym - O(n^2). Kdyz propojite k serveru cca 200 SAN LUNu, tak RHEL bootuje skoro hodinu. Kdyz povolite paralelni bootovani, tak OOM killer zabije nektery z tech Bash scriptu a uz nenabootuje nikdy.

Pokud jsou ty Bash scripty tak spatny, tak proc se pouzivaji pro udev?

[SPM]

A když si to přečtu celé, změní to něco na faktu, že software, který ve valné většině nahradí init, řeší hromadu dalších věcí, které podle mého názoru vůbec řešit nemá?

[Václav "Darm" Novák]

Už od tvého prvního příspěvku je zjevné že moc nevíš o čem mluvíš. „Takže daemon na spouštění služeb už nám nastavuje i síť.“

Ano, to init řešit nemá a ani to neřeší. systemd-networkd je samostatný síťový démon jako třeba networkmanager. Jen je prostě vyvíjen v jedné sadě nástrojů se systemd.

To je to samé jako tvrdit že KDE je špatně, protože DE nemá řešit výukový software.

[kavol]

To je to samé jako tvrdit že KDE je špatně, protože DE nemá řešit výukový software.

když už obviňuješ ostatní z toho, že si něco nepřečetli apod., tak tady tak ostentativně nedemonstruj vlastní nepochopení :-p

ten příměr je absolutně mimo, pokud chceš mluvit o kdeedu, tak je to asi tak, jako kdyby se kdeedu vyvíjelo společně s kwin a nikoli v rámci vyššího organizačního celku KDE, kwin by bez toho kdeedu odmítnul fungovat, a do celého KDE a nenápadně i do ostatních projektů se rozesíval kód, který vytváří tvrdé závislosti na kwin, aby se to nedalo používat třeba s openboxem nebo awesome nebo čímkoli jiným

[Václav "Darm" Novák]

Já myslel že se stále bavíme na téma první reakce SPM o networkd, kde přesně to samé co píšeš o kdeedu platí. Je to součást projektu, ale naprosto volitelná a ani nemá ambice stát se povinnou.

[SPM]

Je to součást projektu, ale naprosto volitelná a ani nemá ambice stát se povinnou.

Tohle si vytisknu a za rok se tomu zasměju, až to zase bude zaseté všude a nepůjde se toho zbavit :)) Ale ani tak mi nepřijde proč by to mělo být v rámci projektu. Desktop environment mi přece jen přijde jako jiná kombinace. Tohle je jako kdyby ve zdrojáku apache se najednou objevil mailserver.

[martin]

ja jsem si docela jistej, ze si spis za rok jednu liskes za to, jaky jsi psal blbosti. resp. ty to neudelas, protoze kdyby si mistni doomsdayari meli jednu lisknout pokazdy, kdyz nejaka jejich priblbla konspiracni teorie nevysla, tak by jim ted radsky horeli ksichty ;)

[SPM]

Hele anonymní sadisto, když ti přispěju na bičík přestaneš tady prudit? :)

[martin]

nemusis, staci sem prestat psat nesmysly ;)

[trekker.dk]

Jasně. Třeba takový udev. Původně samostatný projekt. Pak součást systemd, ale "půjde to i bez něj". A dneska? Pokud vím, tak jenom se systemd.

[martin]

tak to vis spatne, udev se da pouzivat, i kdyz systemd neni PID1

[j]

Mozna jeste par mesicu, je jen otazka velmi rkatkeho casu, kdy to nepujde. Ale to bys musel aspon tusit, ze ...

Uz ted jsou z udevu odstranovany funkcionality, ktery nikdy nikomu nevadily, ale vadej vyvojarum systemd. Viz v.200, od ktery nefunguje prejmenovani na ethx ... to je uzasny, muset kvuli nekolika kretenu prepisovat desitky milionu radku ruznych konfiguraci, co?

[pc2005]

No on je hlavně problém, že za rok si na to nikdo nevzpomene . To by chtělo tady mít nějakou rubriku jako tenhle web.

[kavol]

... ale naprosto volitelná a ani nemá ambice stát se povinnou.

to journald taky ... oh, wait ...

[martin]

a ty si vazne pripadas chytre, kdyz tohle pises?

[kavol]

měl bych, když se takhle ptáš? kdo ti to nakukal?

- a co ty?

[kavol]

Je to součást projektu

jo ještě by stálo zato upřesnit tohle ^ ... tak tedy mluvíš o tom, co píše SPM, tedy "daemon na spouštění služeb" = v rámci KDE něco na úrovni kwin, anebo o systemd* = celé DE?

[frdrx]

Nebuď takovej datenwolf.

[Michal Kubeček]

Kdepak. Mně prostě myšlenka, že vnutíme extra démona na konfiguraci každému včetně toho, kdo má konfiguraci pevnou a mění ji nanejvýš jednou za rok (nebo rovnou za dobu života systému), připadá zásadně chybná. A je mi úplně jedno, jestli se ten démon jmenuje systemd-networkd nebo třeba wicked. Ve jménu ten problém není.

[Václav "Darm" Novák]

Mohu se zeptat kde je ten démon vnucován?

[Michal Kubeček]

Vy opravdu - po předchozích zkušenostech se systemd a spol. - věříte tomu, že systemd-networkd bude volitelnou komponentou, která se bude spouštět jen tomu, kdo o ni stojí? A s wicked se už reálně počítá jako s náhradou inicializačních skriptů sítě, ne alternativou k nim (což bylo pro mne hořké zklamání, protože původně mi byl ten projekt docela sympatický).

[Václav "Darm" Novák]

Ano, věřím. Je to systemd service, nevidím jediný důvod proč by nešel disablovat a napsat si vlastní service která nastaví síť přes net-tools.

[Michal Kubeček]

Stejně tak jako není jediný důvod, proč nevypnout systemd-journald a nelogovat přímo prostřednictvím syslog/syslog-ng/rsyslog?

[Michal Kubeček]

Oprava: … proč by nemělo jít vypnout … a logovat …

[Václav "Darm" Novák]

A uměl by vůbec syslog-ng nebo rsyslog pracovat se systemd samotným? Pokud ano, nevidím jediný problém, journald se vypnout dá.

[Michal Kubeček]

Aneb filosofie systemd v kostce: máme tu desítky let existující rozhraní pro logování, ale my, Lennart první, si právě proto vymyslíme své vlastní. A všechny aplikace jsou povinny se tomu rozhraní přizpůsobit.

Opravdu vás ani na vteřinku nenapadlo, že by ta otázka měla být položena obráceně?

[Petr Ježek]

Michale, myslím, že přeháníte. Předně, služby systemd jsou opravdu pouze a jen službami systemd, jinde je nepoužijete a jsou enabled/disabled. Už to tu zaznělo, že od dob mnoha různých initů a démonů je Lennart první (s malým p!), kdo se zamyslel nad možnostmi jisté standardizace, která se stane pojítkem doposud roztříštěného vývoje initu napříč distry. Osobně pozoruji v Archu, který měl vymakaný a skvěle funkční vlastní init systém a přešel taky na systemd, že se pro mne nic nezměnilo kromě jediného - používám častěji systectl pro většinu věcí souvisejících s initem - je to rychlé a účinné. Rychlost initu je skvělá, především díky skvělému řazení spouštěných služeb, které do té doby nebylo možné řadit jinak než metodou pokus-omyl. Testování vypínáním služeb ukazuje, že i systemd může být velmi puritánský init systém a že lze mnohé služby volat ad-hoc, což má co do činění třeba s bezpečností systému. Ale mám pocit, že tohle vše víte i vy...

[David Jaša]

Řekl bych, že většina dnešních výhrad proti systemd se netýká jeho funce coby initu (i když ten opravdovej stop mi furt chybí).

[Michal Kubeček]

Předně, služby systemd jsou opravdu pouze a jen službami systemd, jinde je nepoužijete a jsou enabled/disabled.

Příklad s journald, kterému se v posledních verzích už vyhnete jen za cenu toho, že systemd logovat nebude vůbec, není dostatečně výmluvný?

skvělému řazení spouštěných služeb, které do té doby nebylo možné řadit jinak než metodou pokus-omyl

Nesmysl. Bylo možné je řadit na základě závislostí, stejně jako teď. Kromě absurdit typu socket-based activation (advokátům doporučuji např. bnc#857372, je to velmi poučné čtení) je nová v podstatě jen možnost jemnějšího členění služeb pro potřeby závislostí (tj. např. "eth0 je nakonfigurované" místo "síť je nakonfigurovaná"), ale šlo udělat i s init scripty, kvůli tomu nebylo potřeba přejímat celou tu obludnost.

Testování vypínáním služeb ukazuje, že i systemd může být velmi puritánský init systém a že lze mnohé služby volat ad-hoc

Teď asi nerozumím, co máte na mysli. Jestli socket-based activation, tak viz výše, tohle považuji za jednu z největších zrůdností, které systemd přinesl. Jinak co se vypínání služeb týká, hláška "OK, vypínám službu X, ale počítej s tím, že ti ji za chvíli stejně zapnu přes X.socket" (volně převyprávěno) hovoří sama za sebe.

[Michal Vyskočil]

Teď asi nerozumím, co máte na mysli. Jestli socket-based activation, tak viz výše, tohle považuji za jednu z největších zrůdností, které systemd přinesl. Jinak co se vypínání služeb týká, hláška "OK, vypínám službu X, ale počítej s tím, že ti ji za chvíli stejně zapnu přes X.socket" (volně převyprávěno) hovoří sama za sebe.

To je pravda, tohle by se za sysvinit a xinetd rozhodně nenapsalo!

[kavol]

Příklad s journald, kterému se v posledních verzích už vyhnete jen za cenu toho, že systemd logovat nebude vůbec, není dostatečně výmluvný?

anebo také nevyhnete

[Sešívaný]

Na to, že po zamaskování journald člověk už ani nenabootuje, jsem narazil už ve Fedoře 18, respektive Pidoře na ní postavené. Potřeboval jsem snížit počet zápisů na disk a paměťový footprint systému na Raspberry na minimum. Zamaskoval jsem to, z prvu vypadalo vše ok, po x hodinách přestal systém odpovídat a už ani nenabootoval. Nakonec jsem to musel vyřešit tak, že mi journald loguje jen do paměti s nastaveným hodně malým limitem. Když jsem se tenkrát ptal kluků ze systemd, řekli mi, že úplné vypnutí journald nemají moc ošetřené.

[Václav "Darm" Novák]

Aha, tak to je, uznavam, dost blby. Ja to zkusil jen jednou na Chakre a v pohode.

[Sešívaný]

Mně to zase tak moc nevadilo. Journald mám raději než rsyslog. Spíš na tom Raspberry jsem nepotřeboval žádné logování a raději dal veškerou paměť té jediné službě, která tam běží, a hlavně omezil zápisy na SD kartu. To druhé se podařilo vyřešit úplně a to druhé není tak hrozné. Journald té paměti zase tak moc nesežere.

[Václav "Darm" Novák]

Jo, taky mi journald naprosto vyhovuje, ale tohle by se stat nemelo...

[kavol]

Na to, že po zamaskování journald člověk už ani nenabootuje, jsem narazil už ve Fedoře 18

no, však taky ten původní bug 917503 byl na F18 ...

[kavol]

Potřeboval jsem snížit ... paměťový footprint systému na Raspberry na minimum. ... Nakonec jsem to musel vyřešit tak, že ...

"musel"? - a co takhle nějaký bugreport s tím konkrétním usecasem, aby to doprdele spravili?

# pmap -x `pidof systemd-journald`
445:   /usr/lib/systemd/systemd-journald
Address           Kbytes     RSS   Dirty Mode  Mapping
00007f8219932000    8192    1476       0 rw-s- system.journal
...
ffffffffff600000       4       0       0 r-x--   [ anon ]
---------------- ------- ------- ------- 
total kB          480372   40072     516

půl giga alokováno na pitomý logování? to jako vážně?

[trekker.dk]

co takhle nějaký bugreport s tím konkrétním usecasem, aby to doprdele spravili

Otázka je, jestli by se prostě neprohlásilo, že takový use case je chybný a že to tak dělat nemáš...

[kavol]

tož, to by ovšem mělo ten pozitivní efekt, že by se dozvěděl, jak to dělat má neb jak já to chápu, tak to prostě ke své spokojenosti nevyřešil

a pokud by to "správné" řešení bylo pičou ke zdi, tak bychom zase měli další čárku pro management ... sice nevím, jestli nám kdy k něčemu budou, nicméně pokud se to nebude řešit vůbec, tak je jasný, že ze nic nezlepší - pak ale můžeme rovnou zrušit celou bugzillu, že ...

[little.owl]

Tak tohle koukejte nahlasit, na mem mini netbooku s 2GB pameti:

total kB          395448   24472     356

a hodte sem prosim link.

[kavol]

s radostí to hlášení přenechám jiným, já mám dneska statistiku dobrou

[little.owl]

OK, musi se nastavit limity v journald.conf a pak to neni tolik rozezrane.

[chrono]

Journald sa vypnúť nedá aj keď jediná vec, ktorú bude robiť bude len to, že log pošle klasickému syslog démonu.

[Petr Ježek]

To že to nejde vám ještě neznamená, že to nejde vůbec (u mne dobré). Zamyslete se nad systémovou integrací vaší distribuce a případně vašeho setupu...

[kavol]

To že to nejde vám ještě neznamená, že to nejde vůbec (u mne dobré). Zamyslete se nad systémovou integrací vaší distribuce a případně vašeho setupu...

mno ... The Biggest Myths

Myth: systemd doesn't allow your to replace its components.

Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.

tak si nejsem jist, jestli výše zmíněný rhbz#1068542 je tedy vůbec chybou ve Fedoře (v "systémové integraci vaší distribuce") ...

[Václav "Darm" Novák]

systemctl disable journald

Pokud nepomuze

systemctl mask journald

Jen zatim neexistuje alternativa co by dovedla logovat bez nej.

[kavol]

goto #80

[SPM]

A umí vůbec network-manager nebo současné network scripty pracovat se systemd samotným? To je úplně stejná argumentace, až systemd-networkd bude zase nedílnou povinnou součástí...

[Petr Ježek]

Ach jo, mám to (NM, connman) jako standardní službu systemd. V čem je problém?

[SPM]

Že argumentaci pro journald je natolik demagogická, že až za rok z nějaké pohnůtky už NM/Connman nebudete moc použít, ale bude možné pouze networkd, tak si zase někdo vymyslí nějaký takový stupidní argument, proč to musí být networkd.

[Václav "Darm" Novák]

Zajimalo by me, jakym zpusobem by mi mohl init zakazat pouziti net-utils nebo cehokoliv jineho.

[SPM]

Tak třeba ty závislosti na síti pro služby nebudou fungovat, když nepoběží networkd... těch možností jak ho tam zadrátovat se určitě najde dost :)

[David Jaša]

Dřív se distribuce lišily balíčkovacím systémem, teď si každá píše i svého síťovacího démona.

[pavlix]

Takže lidi co si ani nepřečtou o co jde komentujou…

Je na tom komentáři, na který reaguješ něco fakticky špatně?

[martin]

jop, systemd != systemd-networkd

takze to tvrzeni, ze init demon bude nastavovat sit, je zcestne. stejne jako nebude delat session managera, protoze systemd != systemd-logind

btw. ty sis teto "drobne" fakticke chyby vazne nevsimnul, ze se musis ptat?

[j]

Jop, ony to vubec nejsou (velmi brzo nedilne) soucasti ... bez kterych to (velmi brzo) proste vubec nepojede ...

[Václav "Darm" Novák]

[citation needed]

[kavol]

dávám bolševikovi rok, maximálně dva ... potom sem budeme moct ten zdroj doplnit :-p

a vůbec, nepřijde ti hloupé dávat [Citation needed] k příspěvku, který mluví v budoucím čase?

[Václav "Darm" Novák]

Ne, protože příspěvek byl psán stylem „Je to naprosto jistá informace“, proto jsem chtěl znát zdroj této informace. A ne, nemyslím si, že by se síťová konfigurace dala takovým způsobem monopolizovat.

[Michal Kubeček]

Mladý pane, viděl jste někdy důl? To je díra v zemi, chodby tak a tak. Prosím, důl se může zatopit, zasypat, ale nikdo vám ho nemůže vzít!

[kavol]

+1

[pavlix]

nemyslím si, že by se síťová konfigurace dala takovým způsobem monopolizovat.

Já si myslím, že to půjde až moc snadno.

[pavlix]

takze to tvrzeni, ze init demon bude nastavovat sit

Vtipné na tom je, že takovéto tvrzení ani nepadlo.

systemd != systemd-logind

systemd-logind (démon) je součástí systemd (projektu, stromu zdrojáků), který byl nejvíce prezentován jako projekt, který vyřeší správu služeb. Takže nejde říct, že by původní hláška byla vyloženě nesmyslná.

btw. ty sis teto "drobne" fakticke chyby vazne nevsimnul, ze se musis ptat?

I vzhledem k tomu, že hned ve vysvětlení zaměňuješ init se správcem služeb, což nebylo mimo systemd zdaleka samozřejmé, mi reakce nepřijde adekvátní k tomu, že dotyčný použil slovo démon, i když se o technicky jedná o sadu démonů. Vzhledem k tomu, že zavádějící je už název té sady démonů, ani se tomu moc nedivím.

[Stanislav Brabec]

Takže daemon na spouštění služeb už nám nastavuje i síť.

Konečně!

Zatímco init skripty jsou jen ošklivé a plné hacků, ten pravý horror nastává při čtení skriptů na start sítě.

[...]

Problem systemd je ze chce robit vsetko a nechce to poskytovat ako alternativu, ale ako jedine riesenie ktore nahradi vsetko. Argument ktory ma vzdy pobavi je "napis si alternativu, systemd poskytuje API...". Ja nechcem pouzivat obskurne API a vytvarat dalsie zavislosti na systemd. Ja chcem init system, ktoreho casti mozem vymenit bez toho aby som k tomu musel zlinkovat polovicu userspace-u. Dalsi problem je ze bug reporty ohladom boot-u sa zmenili z popisu problemu na proces v ktorom clovek musi dokazat ze chyba je skutocne v systemd inak sa s nim nikto nebude bavit.

[Honza Jaroš]

Jo, tak tohle je přesně to, co mi na systemd vadí. Snažím se nevyjadřovat se k jeho kvalitě/nekvalitě, protože naživo jsem ho zatím potkal jen letmo, ale na Linuxu jsem si vždy cenil i toho, že to byla skládačka jejíž jednotlivé části (v podstatě až na pár výjimek) byly zaměnitelné podle aktuálních potřeb a preferencí a byly schopné relativně bez problémů koexistovat vedle sebe. Systemd na mě prostě působí dojmem, že chce sežrat co nejvíc funkčnosti a ostatní odstřihnout. Místo dosavadní konkurence monopol a diktát. Podle mě je to chyba, ale holt jako admin a nevývojář tahám za kratší konec lana...

[Pavel Čejka]

+1 souhlas, jsem na tom stejně

[rbc]

Vendor lock-in podle RedHatu. A to tu lidi na podobnej pristup nadavali M$ a ted se plizive dostava do Linuxu a ted tomu tleskaj. Jak to rikal Einstein o te nekonecnosti vesmiru a hlouposti ?

[Honza Jaroš]

Jo, tohle srovnání mě už taky párkrát při čtení diskusí napadlo, taky pamatuju devadesátá léta, volání po přenositelnosti programů a jak na to windowsoví programátoři z vysoka káleli. Když čtu tady v diskusích hlášky typu "koho zajímá BSD/Hurd", je to jak déjà vu.

[Ivan]

Anebo si pamatuju, ze se Linuxari smali, kdyz MS predelaval desktopovy OS na serverovy. Dneska se na Linuxu cpou desktopovy veci na server a lidi tomu jeste tleskaji.

[Honza Jaroš]

Fakt? To ani nevím, že si z toho někdo dělal srandu. Moje první serverová Windows byla NT 3.51 v roce 1995; tehdy byl Linux ještě v jedničkové řadě a netuším, jestli už byl dostatečně použitelný v ostrém provozu. Já s ním začal koketovat až o pár let později. Přijde mi, že pokud si z toho někdo dělal srandu, netušil o čem hovoří.

Ale to je každopádně fuk. Dokud ty desktopové věci můžu na serveru vyházet, je mi to vcelku jedno. Dokud...

[pavlix]

Nikdy jsi neslyšel pojem zavaděč her? ;)

[Honza Jaroš]

No to sice jo, ale NT byla přece jen jiná řada než Win9x (a ty hry na ní, pokud si pamatuju, až do WinXP ani moc neběžely). Pamatuju si naopak na kritiku toho, že (tuším) ve Win2000 byly nacpány ovladače grafiky do jádra. Pokud někdo tvrdil něco o předělávání desktopového OS na server, tak to mohla být nanejvýš neznalost, protože NTčka byla serverová už od první verze v roce 1993. Pokud Microsofti v případě NT něco předělali, tak spíš OS pro servery a pracovní stanice na systém pro běžné desktopy...

[Václav "Darm" Novák]

Neběžely, pokud si dobře vzpomínám, Windows NT nepodporoval DirectX.

[Honza Jaroš]

Co jsem teď koukal, tak NT4.0 už nějakou podporu DirectX měly, ale byla omezená. Ono je ale otázka, co člověk rozumí pod pojmem NT, protože ta řada pokračuje dodnes a byť už se v oficiálních názvech NT nepoužívá, třeba v HTTP hlavičkách UserAgent ho najdete i teď.

[Heron]

Běžely, měly (NT 4.0, možná dx přišel až s nějakým service packem). Já jsem na NT 4.0 hrál (třeba Half Life).

[Václav "Darm" Novák]

Nejel Half Life pod OpenGL? No, i kdyby, dost toho taky asi rozbijel fakt, ze byli vyvojari zvykli prasit pro jednouzivatelsky OS. Docasny soubory a konfigurace v Program Files? Zadnej stress :)

[Heron]

Asi jo, já jsem ho tehdy hrál na software rendering. Jinak ano, NT měly DX, v max. verzi 3.0a. Ano, prasilo se fest. Dodneška si Windy nesou s sebou nutnost pracovat s právy admina právě proto, že se progs. nikdy nenaučili programovat multiuser aplikace.

[Pavel Čejka]

Fakt? To ani nevím, že si z toho někdo dělal srandu. Moje první serverová Windows byla NT 3.51 v roce 1995; tehdy byl Linux ještě v jedničkové řadě a netuším, jestli už byl dostatečně použitelný v ostrém provozu. Já s ním začal koketovat až o pár let později. Přijde mi, že pokud si z toho někdo dělal srandu, netušil o čem hovoří.

Ale to je každopádně fuk. Dokud ty desktopové věci můžu na serveru vyházet, je mi to vcelku jedno. Dokud...

Nevím jestli Linux v jedničkové verzi, ale kdysi (v době 2.6.x jader) jsem servisoval PC řídící provoz jedné docela důležité spalovny bioodpadu, kde běžel Linux na jádře 1.2.13 (nebo něco podobně nízkého), starší funkční Linux jsem nikde jinde neviděl.

Dle https://www.kernel.org/pub/linux/kernel/v1.2/ tomu odpovídá rok 1995.

Určitě tam nebylo nic desktopového

[pavlix]

Pravda je, že na doby, kdy zaprdění linuxáci nadávali na Microsoft a hromady dalších firem kvůli každé nekompatibilitě, si taky pamatuju ;). Dneska jsou pupek světa a můžou stejným způsobem kálet na BSD.

[pc2005]

+1 !

[Heron]

+1

Jinak tohle se týká i dalších Lennartovin.

[Petr Tomášek]

+1

[tetris]

este som nemal problem so systemd. Funguje ako ma a je velmi jednoduchy na ovladanie. Dakujem.

[chrono]

Správa bola odoslaná cez webový prehliadač v niektorej Windows hre?

[AsciiWolf]

-1

[flow]

* (-1)

[frdrx]

Souhlasím. Používám systemd všude bez jediného problému a jsem s ním spokojený stejně jako s Pulseaudio. Nemůžu se dočkat až se zbavím i X serveru a budu spokojeně používat Wayland. Je dobře, že se konečně maká na vyhození obstarožní zátěže.

[...]

Dnes som kvoli jednomu bugu potreboval bootnut kernel bez podpory TMPFS. Myslis ze systemd bootol? Pravdaze nie. Akakolvek chyba v systemd je fatalna chyba a mal by si urychlene konktaktovat svojho vendor-a (Lennarta).

[Michal Kubeček]

Kdyby jen tmpfs, nedávno jsem se dozvěděl, že systemd bezpodmínečně potřebuje i autofs…

[marbu]

K tomu networkd tu nedavno probehla zajimava diskuse:

• systemd-networkd#2
• systemd-networkd#13

[pavlix]

Z těch sedmi démonů už znám u čtyř vývojáře osobně. Z těch významných mi momentálně chybí promluvit si s tvůrci netifd, o kterém se hodlám zmínit na InstallFestu v OpenWRT tracku.

[kolcon]

Nabootoval jsem Arch. Po zavreni vika notebooku se mi tento uspal, ackoliv jsem v xfce4-power-manageru mel nastavene neco jineho.

Co myslite, ze se o to postaralo?

Ano, Lennartova s*acka... konkretne HandleLidSwitch v logind.conf. Co ma jako vec na spousteni demonu spolecneho s uspavanim pocitace a zaviranim vika?

[little.owl]

Problem je v xfce4-power-manager, patch je k dispozici zde, pripadne reseni zde.

[kolcon]

diky za tip, ale stejne nechapu, proc systemd jako ma resit uspavani pocitace pri zavreni vika?

[little.owl]

Tak obecne, jakykoliv systemovy manager zodpovedny za bez sluzeb a systemu nemuze povolit userspace aplikaci zapinat/vypinat/hibernovat/etc. cely system, aniz by k tomu mel uzivatel prislusna prava (pak logind). Spatna integrace XFCE na Archu je jiny problem, ale oni na to wiki upozornuji.

[marbu]

Predne tohle neresi primo systemd, ale jiny daemon: logind. Druha vec je, ze je pevne svazan se systemd. Jinak mi prijde logicke ze tuhle funkcionalitu resi globalne logind, misto toho aby si to resilo kazde DE samo (viz. delat jednu vec, ale dobre). Fakt ale je, ze integrace logind se systemd neni idealni, ale nastesti Debian i Ubuntu maji zajem i lidi ochotne to podilet se na reseni.

[David Jaša]

(viz. delat jednu vec, ale dobre)

Nedělá ji dobře. Nebo snad už umí mít různé akce na stejném čudlíku na základě toho, jestli se jede z baterky nebo ze sítě?

[petr]

http://monolight.cc/2011/05/the-systemd-fallacy/

[Michal Vyskočil]

Má to cenu číst? Hned ten první bod

restarting processes after they crash. sysvinit doesn’t do that and we don’t have restartd or a thousand other programs for it. Oh, wait…

ukazuje, že ten člověk vůbec neví o čem mluví. Samotný /sbin/init umí respawn a namísto restartd si může dosadit třeba monit, supervisord, daemontools, runit a dost možná, že i věci jako pacemaker a čert ví, co všechno ještě umí monitorovat procesy a v případě potřeby je restartovat.

[Michal Kubeček]

Nebo že by to "Oh, wait..." byl náznak, že jde o ironický povzdech nad takto znějícím argumentem používaným některými zastánci systemd?

[kavol]

hehe, člověku by se chtělo říct "má to cenu číst? hned ten první bod ukazuje, že Michal neumí anglicky ..."

[Michal Vyskočil]

Nebo že by to "Oh, wait..." byl náznak, že jde o ironický povzdech nad takto znějícím argumentem používaným některými zastánci systemd?

To mě pochopitelně napadlo, ale jednak žádný jiný bod není tímto způsobem napsaný a druhak jsem z toho nerozklíčoval co vlastně lennart-fans tvrdí. Že se do sysvinit nedá přidat externí monitorovací démon?

[Michal Kubeček]

Ne, prostě to uvádějí jako jednu z featur "proč systemd".

[petr]

spíše je podstatné jak se Lennart vyjádřil o POSIXu a jak vystihuje svůj přístup viz

(…) So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It’s quite relieving!

Bohužel je udivující, že tento Amazing sw RedHat akceptuje a podporuje....další se pak chtě-nechtě vezou.

Rád bych parafrázoval další Lennartovu perlu ... BSD is not relevant anymore.... Spíš bych řekl, BSD is relevant more than EVER now :)

Tedy alespoň pro mne. Včera jsem včera jsem po dlouhém přemítání nad aktualizací na Fedoru 20, linux z noteboku vyhnal a nasadil FreeBSD, takže asi tak...

[pavlix]

další se pak chtě-nechtě vezou.

Spíše chtě než nechtě. Další distributoři se vezou z vlastní vůle. Nepoužití systemd by pro ně znamenalo zajistit integraci software s alternativami k jednotlivým funkcím systemd. Výhoda systemd je jen v tom, že práci buď už někdo odvedl, nebo je velká šance, že ji někdo odvede.

Včera jsem včera jsem po dlouhém přemítání nad aktualizací na Fedoru 20, linux z noteboku vyhnal a nasadil FreeBSD, takže asi tak...

Přitáhni na nějakou konferenci. Docela rád bych viděl, jak to zvládá běžné úlohy typu připojení notebooku do wifi sítě apod. Nainstalovat něco z trucu je jedna věc, dlouhodobé spokojené používání je věc druhá.

[petr]

Ta integrace je právě ten problém. Závislost na initu reps. všeobjímajícím systemd vidím jako problém a neskutečně mě "sere" Lennart a jeho amazing hacking přístup.

To není truc, ale vygradování dlohoudobější nespokojenosti - celkově. Čím dál víc se raději věnuji práci s např. s AIXem, než ladění RHELu a jiných linuxů.

Co se týče BSD, zatím vše OK outofbox včetně wifi - intel. Jediný problém je nevyladěný suspend, to je fakt.

Na nějakou konferenci bych klidně dorazil :)

[pavlix]

Ta integrace je právě ten problém.

Integrace je problém, ale nikoliv nepřekonatelný. Pokud by skutečně byla vůle, integrace by se zadařila i bez systemd.

To není truc, ale vygradování dlohoudobější nespokojenosti - celkově. Čím dál víc se raději věnuji práci s např. s AIXem, než ladění RHELu a jiných linuxů.

Netvrdil jsem, že je to truc. Jen to, že mě to zajímá za předpokladu, že je to více než jen truc.

Co se týče BSD, zatím vše OK outofbox včetně wifi - intel.

Mně osobně nejde ani tak o hardwarovou stránku. Vždy jde vybírat hardware tak, aby byl podporovaný, pokud alespoň nějaký existuje. Spíše mi šlo o uživatelskou stránku, jestli je to práce na úrovni wpa_supplicant, NetworkManager, popřípadě ještě lepší/horší.

Jediný problém je nevyladěný suspend, to je fakt.

Pravda je, že to by mi hodně vadilo.

Na nějakou konferenci bych klidně dorazil :)

Za pár dní je v Praze InstallFest, tak můžem pokecat o FreeBSD, vždycky mě zajímaly alternativy a FreeBSD je jediná, která se mi i líbila, když jsem to zkoušel, i když mi přijde, že za asi nejpodobnějším Gentoo je to pořád poněkud pozadu.

[little.owl]

FreeBSD 4.x jsem uspesne pouzival na desktopu. Zkousel jsem FreeBSD 10 a je to IMHO snad nejhorsi FreeBSD ever, pomale, nestabilni (treba new GPU drivers), se snad alpha featurami (BHyVe), bez rozumneho FS (ZFS na 4G pameti? muhehe). Ale jinak si to uzijte a at vam to vydrzi; ja jsem na pouzivani neceho jako FreeBSD jiz prilis liny.

[petr]

Zatím 10tku provozuji na Latitude D620 se 4GB RAM + SSD a i s vypnutým ZFS Prefetch a je to OK. O víkendu to nahodím na pracovní Precision M4700 tam mám 16GB RAM 2xSSD a NVQuadro K1000, tak jsem zvědav na srovanání s aktualně instalovaným RH 6 WS.

Mimichodem, nic ve zlém :) , parafráze o lenosti byla celkem častý argument Windows uživatelů ve směru přechodu k Linuxu.

Každopádně, je dobře, že je stále z čeho vybírat.

[pavlix]

Jestli se Lennartovi podaří trochu oživit a rozšířit BSD komunitu, tak to bude docela dobrý počin.

[petr]

Uvidíme. Prozatím v mém okolí pozoruji náznaky, kdy "nespokojení" migrují spíše směrem k "placenému BSD" resp. MacOSX :) A ti co už opravdu potřebují jen zobrazovadlo přechází na iOS a Android.

Celkem zajímavé bude sledovat pohyb v komerční sféře, kde hlavně co se týče 24/7 má Linux své stabilní místo, o které ovšem může velice rychle přijít. Dávno jsou pryč doby kdy korporace v rámci úspor přecházeli z Unixů na Linux. Dnes je vše o virtualizaci. Ti co šetří sahnou po kombinaci vmware-windows a pro vysoce náročná prostředí a benevolentnejší budgety je tu např. AIX-PowerVM.

Vytváření dalších záměrně POSIX nekompatibilních "windows" pod taktovkou RH+LP nic nového nepřinese...

Nevím jestli se tedy rozšíří BSD komunita, nicméně alepsoň v mém případě pravděpodobně ano :) a cca oněch 200 dolarů za rok za RHWS velmi rád pošlu FreeBSD na bugfix a vývoj.

[pavlix]

Já bych to neviděl až tak horké.

[little.owl]

A unik smerem k OS X, launchd a podobnym vychytavkam ma byt cesta jak uteci "lenartovinam", zejmena ted kdyz tam pomalu strkaji prvky z iOS? Duvod migrace je ve vetsine pripadu jiny, casto prave ta "lenost" a FreeBSD neni pak alternativa.

[David Jaša]

Ti co šetří sahnou po kombinaci vmware-windows

Tak buď budou šetřit, nebo budou platit za vmware...

[little.owl]

.. a windows [server].

[little.owl]

Zrejme mame velmi rozdilne predstavy, co je vlastne OK.

Mimichodem, nic ve zlém :) , parafráze o lenosti byla celkem častý argument Windows uživatelů ve směru přechodu k Linuxu.

V rade ohledu naprosto smysluplny, prechazet na nejaky system, pokud jeho vyhody pro vas neprevazi jeho nevyhody, je nesmysl.