Devuan 2.0.0 ASCII Stable

Měsíc po vydání RC verze byla vydána stabilní verze Devuanu 2.0.0. Její kódové jméno je ASCII, podle planetky s katalogovým číslem 3 568. Přehled novinek v poznámkách k vydání. Devuan (Wikipedie) je fork Debianu bez systemd.

9.6.2018 11:22 | Ladislav Hagara | Nová verze

Komentáře

[Odin]

Proc udrzovat paralelni distribuci, kdyz navod na instalaci debianu bez systemd behem minuty jde vygooglit?

[_]

Vygooglit jde, ale spousta věcí pak nefunguje (nesmyslné závislosti na systemd).

[BFU]

Nestacilo by to opravit a upstreamovat ?

[_]

To by o Debianu nesměli rozhodovat -píp-, kteří kompilují jako závislé na systemd i věci, kde ta závislost není nutná. Méně energie stojí Devuan, než se dohadovat s fanoušky systemd v Debianu.

[rpajik]

No popravdě ... když by debian neměl spoustu unit v systemd udělanou blbě, tak by možná žádný Devuan nebyl potřeba.

[Grunt]

Já nevím, ale přijde mi to na hlavu padlé. V Gentoo si člověk může vybrat init systém už při instalaci (stačí kliknout na příslušný záznam v Gentoo Wiki a řídit se jím) a Debian který se ptá na každou debilovinu i v rámci postinstallačních skriptů musí mít extra distribuci? Není to směšné?

[_]

Ano Debian se chová směšně.

[ewew]

Tak používaj svoj oneclick systém.

[Bedňa]

ení to směšné?

Není, keby sme sa chceli ťahať za pipíky, tak si môžeme porovnať verzie programov a ver tomu, že Gentoo už dávno zaspalo dobu.

[Grunt]

Verze jakých programů? Oč tu běží?

[Bedňa]

Všetkého.

[AsciiWolf]

Gentoo i OpenRC jsou fajn. Dobu zaspal především SysVinit (ten byl zastaralý již před 15 lety) a autoři projektů jako je Devuan (nicméně i tak jim a Devuanu fandím).

[mirec]

Debian je na tom s podporou init skriptov / systemd unitov dlhodobo zle. Pred systemd to bola len zmes hrozne nespoľahlivých skriptov. Niečo tak neprehľadné a nefunkčné sa len tak ľahko nevidí. Po nasadení systemd síce stále niektoré služby nefungujú (za všetky spomeniem napr. taký gitlab ktorý má 50% pravdepodobnosť naštarotovania, alebo uwsgi, ktorý naštartuje takmer vždy, ale pravdepodobnosť, že sa neskôr dá reštartovať je tak 10%), ale stačilo napísať vlastné pár riadkové unity a všetko krásne funguje.

[Bedňa]

Teda už dosť dlho nepoužívam priamo Debian, ale antiX, mno s niečim podobným som sa nikdy nestretol ani v Debiane.

Máš konkrétny príklad pre systemd free distro? Napr. aj starší Debian aby som ti to vyvrátil, pretože to sú pre mňa len nijak nepodložené kecy.

[trekker.dk]

Init skripty v Debianu fungovaly dobře - do přechodu na systemd. Teď už to tak dobré není - například mají init skript, které spouští službu s parametrem "ukonči se po 60 sekundách", což u on-demand aktivace v systemd asi nevadí, ale se sysv to moc nefunguje. Nebo init skript, který umí službu spustit, ale už ne ukončit či restartovat.

Krásná ukázka toho, jak něco "nefungovalo" a teď je to "lepší"

[Bedňa]

Ja mám Mireca rád, ale toto sa mi zdá že prestrelil.

Fakt tie skripty mi fungovali v starých Debianoch dobre a rád by som sa nechal presvädčiť, že to pravda nie je.

[mirec]

Niektoré fungovali, niektoré nie. Tie najbežnejšie asi fungovali, ale akonáhle som potreboval rozbehať redmine tak štart fungoval, vypnutie tak v 20% prípadov vytuhlo. Gitlab robil to isté, akurát potreboval viacej krokov a vytuhlo to tak v 50% prípadov. Vtedy som musel zistiť v akom stave zostal visieť, pokillovať čiastočne naštartovaný gitlab ručne a skúsiť ho ručne naštartovať. Úplne najhoršie bolo asi uwsgi. Úspešnosť vypnutia služby bola tak 20% a moc jednoducho som to nevedel pokillovať, takže pri reštarte uwsgi som radšej rovno reštartoval server. Áno, nasieralo to zákazníkov, ale vždy to trvalo kratšie než keby som mal všetky procesy killovať, kontrolovať zámky atď.

[trekker.dk]

To je právě to, ty nejběžnější fungovaly a nefungovalo hlavně to, co si lidé většinou stejně nějak spouštěli sami. Dneska jsou rozbité věci jako Spamassassin a LVM, přičemž přinejmenším to druhé by měla být kategorie "nainstaluju a funguje".

[mirec]

Nechcem tu byť za obhajcu systemd, ale treba si uvedomiť, že doba sa trochu zmenila. Časy keď sme na serveri hostovali pár PHP stránok, všetko to bežalo pod apachom, ktorý si sám mangoval PHP, sám si managoval vlastné procesy, sám sa staral o logovanie, sám sa staralo o zapisovanie PID ... sú preč.

Dnes mám na serveri mnoho malých služieb, ktoré bežia samostatne. Niektoré sú štartované na požiadanie, iné štartujú hneď pri boote. Niektoré sa automaticky vypnú pri nečinnosti. Niektoré potrebujú závislosti. Niektoré sú uzavreté v chroote. Keby som to chcel managovať starým spôsobom musel by som každú jednu aplikácu naučiť fork, ku každej jednej ktorá beží pod chrootom by som musel napísať vlastný supervizor, v kadej by som musel riešiť logovanie, ku každej aplikácii by som musel napísať init skripty so špecifickým sleepom podľa toho koľko aplikácii trvá zapísanie PID ... tieto veci sa našťastie presunuli do systemd a pri vývoji aplikácie sa o ne už nemusím starať.

Z mojej strany je odchod od initu vykúpením z nekonečného písania skriptov, ladenia, dopisovania toho istého deravého kódu do každej aplikácie, ladenia, opravovania každej jednej aplikácie, ladenia ... Určite by som u systemd uvítal menej arogantné správanie vedenia, väčší dôraz na opravovanie chýb, minimalizáciu závislosti, možnosť nahradiť binárne logy a mnoho mnoho ďalších vecí, ale ako celok to vnímam pozitívne.

[trekker.dk]

Nechcem tu byť za obhajcu systemd, ale treba si uvedomiť, že doba sa trochu zmenila. Časy keď sme na serveri hostovali pár PHP stránok, všetko to bežalo pod apachom, ktorý si sám mangoval PHP, sám si managoval vlastné procesy, sám sa staral o logovanie, sám sa staralo o zapisovanie PID ... sú preč.

Ani náhodou. Provozuju na serveru víc než pár stránek, Apache si pořád managuje svoje vlastní procesy, sám si managuje PHP (se suexec, aby to všechno neběželo pod apachem), sám si zapisuje PID, celé to běží pod supervizorem, systemd-free. (A s radostí pozvu na pivo každého, kdo mě přesvědčí, že existuje lepší způsob, jak to udělat.)

Dnes mám na serveri mnoho malých služieb, ktoré bežia samostatne. Niektoré sú štartované na požiadanie, iné štartujú hneď pri boote. Niektoré sa automaticky vypnú pri nečinnosti. Niektoré potrebujú závislosti.

Jo, dobrý, uznávám, že supervizor, který umí řešit závislosti a spouštět služby on-demand, není v principu špatný nápad. Ale systemd+universe (mínus bulánci) je špatná realizace.

[mirec]

Ten apache je typický príklad starej služby. Má určitý master proces, ktorý má pid a init systém komunikuje s master procesom cez signály a ten ďalej managuje forky. Ja som potreboval inicializovať služby bez master procesu a bez práv na zápis mimo svojich chrootov.

Ja netvrdím, že systemd je správne realizovaný, ale rieši problém, ktoré som predtým nedokázal vyriešiť bez vytrhania vlasov. Teda ok, aby som nebol zlý upstart sa celkom približoval k tomu, čo som potreboval. Keby bola rozumná alternatíva k systemd tak by som ju rád používal, lebo je až príliš veľa vecí koré mi na ňom vadia.

Ozaj len pre zaujímavosť aký supervizor je dobrý? Pred prechodom na systemd som používal supervisord, ale ten fungoval celkovo nejak divne.

[trekker.dk]

Ozaj len pre zaujímavosť aký supervizor je dobrý?

Já používám runit - stačí na to, co potřebuju - tj. spustit službu a držet ji spuštěnou - ale víc toho neumí.

[mirec]

Ja na desktope používam gentoo. Init skripty neriešim, je to desktop, takže stačí, že to naštartuje do X.

Na serveroch niekde ubuntu, niekde debian. S prechodom na systemd som veľmi spokojný. Na rozdiel od init skriptov systemd funguje spoľahlivo a mohol som 200-riadkové monštrá nahradiť 10-riadkovými konfigurákmi. Všetko pekne používa cgroups, niektoré služby majú socketovú aktiváciu, služba sa naštartuje na požiadanie, pri nečinnosti sa pekne ukončí ...

Ako príklad uvediem toto. Sú to len pomocné funkcie k uwsgi, okrem nich init skript includuje ešte 3 ďalšie súbory s pomocnými funkciami, ktoré includujú ešte ktovie koľko ďalších. Celý tento bordel som nahradil dokopy 11 riadkami pre socketovú aktiváciu (to sysvinit nedokáže) a 17 riadkami pre štart a konfiguráciu služby.

[Bedňa]

Sorry Mirec ani som si nevšimol, že si to písal ty, inak by som bol zdržanlivejší, sorry brácho.

Áno bashovské skripty sú fakt menej čitateľné, mno s čím nesúhlasím, že by sa chovali nejak nespoľahlivo, práveže naopak. Mno môže sa stať, že v Debiane niečo posrali, hneď ako budem mať čas odskúšam si ako to ne/funguje.

Ja som zas dostal do daru na nejaký čas server s Ubuntu a systemd, kde bolo aj grafické prostredie. Tak prvé som odstránil všetko grafické prostredie a dal reboot a tam som skončil vďaka systemd v neonečnej slučke, to je čo? Toto som nikde okrem distier so systemd nikde nevidel. Je to jediný Init čo sa dokáže zdrbať.

[mirec]

Na zdržanlivosť si nepotrpím :P

Ale teraz vážne. Init funguje dobre na služby kde služba naštartuje, zapíše PID a pod týmto PID zostane bežať až kým ju init nekillne. Ak sa aplikácia potrebuje počas behu prepnúť užívateľa, zatvoriť sa do chrootu, využije k tomu exec, vymení PID a nemôže ho zapísať lebo je v chroote tak sa celý init jednoducho zosype pretože stratí PID. V systemd je stále súčasťou cgroup a dá sa bezpečne ukončiť. Ak potrebujem služby zapínať a vypínať dynamicky (teda služba naštartuje pri pripojení na socket a sama sa vypne pri nečinnosti) tak to je v inite tiež neriešiteľné. Takto by som mohol pokračovať pre mnoho ďalších prípadov.

Či som niekedy skončil s nebootovateľným serverom? So systemd zatiaľ nie, s initom niekoľko krát. Na druhej strane na desktope s archom som pár krát skončil s nebootovateľným systemd a úspešnosť bootu so systemd (ak vôbec fungoval) bola tak 75%. Vo zvyšných 25% prípadov sa systém sekol, čo naštvalo hlavne keď som ho nadiaľku reštartoval. To bolo v začiatkoch systemd, takže odhadujem, že teraz to už bude odladené.

[Bedňa]

Nenabootovať do sysVinit mi príde po rokoch používania Debianu a derivátoch neuveriteľné. Fakt Mirec si to zrejme znásilňoval viac ako sa má. Ja som o tom ani nepočul, nie že by som to riešil.

Debiania komunita ktorá bola neskutočne veľká a neverím, že by nikto neriešil tvoje problémy.

Nič nedokázalo tak veľkú komunitu rozbiť a predsa sa našiel zmrd, čo to dokázal. On všetko robí dobre. Všetko čo bolo v Linux enviroment, bolo vždy zle. Konfigi treba ukladať, kde ťa napadne, napr. do /usr/lib, to je to pravé miesto.

Kde sa kurwa pripájajú disky a prečo? Asi cez texťák vytiahnem neskurvený log? Proste Mirec serem na to, zhodneme sa na tom že sa nezhoneme a ďalej sa nemám o tých skurweninách o čom baviť.

[mirec]

Nenabootovať do sysVinit mi príde po rokoch používania Debianu a derivátoch neuveriteľné. Fakt Mirec si to zrejme znásilňoval viac ako sa má. Ja som o tom ani nepočul, nie že by som to riešil.

Neviem kde bol u mňa problém so sysvinitom. Viem, že mi to urobilo na pár VPS-kach keď som tam spustil skript na aktualizáciu vydania. Vtedy som vrátil späť klon, spustil ten istý skript znovu a druhý krát to prešlo a nabootovalo.

Debiania komunita ktorá bola neskutočne veľká a neverím, že by nikto neriešil tvoje problémy.

Moje problémy neboli riešiteľné sysvinitom. V debiane uhackovali niečo, čo fungovalo niekedy keď sa daemon nechrootoval. Väčšina užívateľov to riešila cez supervizora (ale aj s tým som mal problémy).

Nič nedokázalo tak veľkú komunitu rozbiť a predsa sa našiel zmrd, čo to dokázal.

LP mi svojim prístupom vadí, požieranie ostatných projektov mi tiež vadí, ale som pragmatický človek. Potrebujem aby server fungoval spoľahlivo a potrebujem aby som si pri tom nevytrhal vlasy a prekvapujúco systemd toto splňuje z init systémov, ktoré som skúšal najlepšie.

Konfigi treba ukladať, kde ťa napadne, napr. do /usr/lib, to je to pravé miesto.

Umiestnenie unitov v /usr/lib mi žily netrhá. Radšej by som tak dôležitý komponent ako systemd videl v /lib aby sa dal nabootovať systém, ktorý náhodou nepripojí /usr, ale to je drobnosť. Umiestnenie unitov do podadresára lib je mimochodom správne. Len pre zaujímavosť pozri si kde máš umiestnené také veci ako ssl certifikáty, mimetypy, udev pravidlá ...

Vlastné, alebo upravené systemd unity sa ukladajú do /etc, systémové sú v /usr/lib, čo je asi najlepšie riešenie pretože pri aktualizácii ti nerozbije /etc ako sa to dialo doteraz. V gentoo som používal kedysi jeden upravený skript v /etc/init.d a pri každej aktualizácii som musel spustiť diff a aplikovať znovu svoje zmeny.

Kde sa kurwa pripájajú disky a prečo? Asi cez texťák vytiahnem neskurvený log?

Disky neviem, nestarám sa kým to funguje, ale naposledy to používalo normálne fstab. Logy mi fungujú ako doteraz (síce k tomu pribudol binárny log, ale stále sa posielajú aj do syslogu, takže neriešim, ale na nové služby som si už zvykol prezerať cez journalctl).

[Bedňa]

Pol hodinu som písal odpoveď ktorú som zmazal.

Pretože mi to príde ako opakovanie toho čo som tu už písal viac krát a zas dostanem rovnakú odpoveď. Je to ako z Red Dwarf keď sa tam objavila Pree.

Proste každý nech si používa čo chce, len by si mal uvedomiť kde svojou podporou nasmeruje ďalší vývoj Linux enviroment.

[Tuttle]

Máte někdo už s Devuanem delší zkušenosti v produkčním serveru s víceméně klasickými službami? Podělíte se?

[R]

Na produkcny server by to daval len samovrah. Hlavne ked tam bez problemov funguje Debian so sysvinitom.

[rpajik]

To neni úplně pravda.

Debian Stretch sice může používat sysvinit, ale to neznamená že se systemd vyhnete. Například udev zmizel a nahrazuje ho systemd.

[R]

Mam pocit, akoby som sa tu bavil s absolventami pomocnej skoly...

# dpkg -l | grep udev
ii  libudev1:i386                      232-25+deb9u3                     i386         libudev shared library
ii  udev                               232-25+deb9u3                     i386         /dev/ and hotplug management daemon
# dpkg -l | grep systemd
ii  libsystemd0:i386                   232-25+deb9u3                     i386         systemd utility library

[k3dAR]

neprijde ti divne ze udev ma totoznou verzi jako libsystemd? non-systemd fork udev je eudev(od gentoo vyvojaru), v devuanu je, v debianu nevidim...
jestli ono to nebude tak, ze vyvojari devuanu vedi co a proc delaji, narozdil od uzivatelu co devuan povazujou za zbytecne protoze si mysli ze to udelaji v debianu na tuknuti take

[mankind_boost]

sakra, o minutku rychlejší

[mankind_boost]

Mam pocit, akoby som sa tu bavil s absolventami pomocnej skoly...

Mám úplně stejnej pocit. Koukni na verze těch balíku a možná si něčeho všimneš...

Pro-tip: zkus příkaz apt-cache showsrc udev

Ano, je to tak! udev v debianu je ten ze systemd.

Ten normální samostatný udev se dneska jmenuje eudev a udržuje to gentoo project pokud se nepletu. To ale v debianu jen těžko rozjedeš.

[Jendа]

Ano, je to tak! udev v debianu je ten ze systemd.

A proč by mi to mělo vadit, když funguje i bez běžícího systemd?

[mankind_boost]

To nevím, já se systemd nemám problém, též ho používám. To si musíš odpovědět sám.

[R]

Samozrejme, ze viem, ze udev je v upstreame sucastou systemd. Ale funguje aj bez neho, tak nevidim dovod, preco ho nepouzivat. Ziadny problem som s nim nemal (na rozdiel od systemd).

[Bedňa]

V systémoch bez systemd teraz beží eudev, čo je vykostení udev z systemd a spravili ho Gentoisti ako proof of concept, z ktorého sa napokon stal skutočný projekt. Inak sa to dá dohľadať aj tu v správičkách keď to začínalo.

[Petr73]

Ve firmě nám běží Devuan Jessie od doby RC2 jako webserver pro podnikový systém. Od doby instalace a nastavení se kromě aktualizací v podstatě nemuselo nic víc řešit. Je to stabilní systém. Nedokážu si představit dát na produkřní server cokoliv se systemd.

[Pavel 'TIGER' Růžička]

U několika serverů jsem přešel v rámci debian jessie na devuan jessie a defacto o těch strojích nevím. Dnes je sice možné jedním příkazem odebrat systemd z debianu, ale v provopočátcích to tak rozhodně nebylo. Navíc se systemd byly problémy. Devuan vznikl hlavně proto, že se s lidmi kolem debianu nedalo domluvit. Já osobně jsem za něj velmi vděčný.