Runit pro systemd haters

Kdo z jakéhokoli důvodu nesnáší systemd jako init systém a nechce čekat na maturitu gnu/dmd, může přejít na runit. Preferuje jej nyní nová rolling-release distribuce Void, je k dispozici i v Archlinuxu a jiných distribucích.

11.9.2014 11:24 | Petr Ježek | Zajímavý projekt

Komentáře

[Petr Ježek]

Ještě doplním, že aktuální vývoj přinesl některá alternativní vylepšení původního Gerritova runitu, např. Nealův runit-init pro Arch nebo Christianovy init scripty v jeho ignite. Pouštět se do náhrady udev pomocí mdev nedoporučuji, prozatím si X s mdev dostatečně nerozumí. Nicméně z hlediska rychlého vývoje Waylandu to začíná se skutečným odlehčením a "oddémonizováním" nejen initu (a s reálně výhodně použitelnou alternativou systemd) vypadat velmi nadějně.

[trekker.dk]

Runit jako náhrada systemd (nebo sysvinit) obstojí jenom těžko - pro začátek nemá kromě "udělej si sám" žádné nástroje na řešení závislostí mezi službami a stejně jako systemd nezná koncept služby, která neběží nepřetržitě (tradičním příkladem je konfigurace netfilteru.)

[Spike]

systemd nezná koncept služby, která neběží nepřetržitě (tradičním příkladem je konfigurace netfilteru.)

Type=oneshot nefunguje?

[pavlix]

+1

[Petr Ježek]

Jaké nástroje postrádáte? Neal má perfektně okomentovaný svůj busybox v runit-init pro Arch, Christian dodal startovací skripty v ignitu (pro jakoukoli distribuci) spolu s reinkarnací klasického rc.d pro Arch. Jednorázové a nikoli nepřetržitě bežící služby jsou v runitu řešeny, stačí se podívat na aktuální dokumentaci. Mimochodem, runit je používán, a to nikoli zcela okrajově...

[trekker.dk]

Jaké nástroje postrádáte?

Příkladem budiž init skript pro PostgreSQL z Debianu:

### BEGIN INIT INFO
# Provides:             postgresql
# Required-Start:       $local_fs $remote_fs $network $time
# Required-Stop:        $local_fs $remote_fs $network $time
# Should-Start:         $syslog
# Should-Stop:          $syslog
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    PostgreSQL RDBMS server
### END INIT INFO

V distribuci je potom program, který tato data vezme a vygeneruje symlinky v /etc/rcX.d tak, aby se tento init skript spustil až poté, co doběhnou init skripty zajišťující local_fs, remote_fs, atd. Jako autor init skriptu tudíž nemusím řešit závislosti sám, stačí mi je někam zapsat. OpenRC AFAIK umí něco podobného a systemd taky. Runit ne.

Mimochodem, runit je používán, a to nikoli zcela okrajově...

Neříkám že ne, já ho na serverech používám taky - spouští mi ho init skript pro služby, kde se hodí supervizor. Rozhodně si ale nemyslím, že by se ve své současné podobě hodil a dal dobře použít jako hlavní init systém pro celý stroj.

Mimo jiné zkoušel jste tu věc někdy přemluvit k tomu, aby se čistě restartovala? Pokud dobře vidím v manuálu, mám dvě možnosti: buď můžu poslat procesu runsvdir TERM, tím se ukončí. Když ho znovu spustím, bude se pokoušet nastartovat běžící služby. Nebo mu můžu poslat HUP, zabije všechny runsv a tím i všechny služby. Ani jedno není OK.

[Petr Ježek]

Díky za věcnou reakci. Samotný runit od Gerrita ponechává veškerou skriptovací iniciativu na uživateli/správci. To znamená čekat, kolika lidem přijde "produktivní" si něco takového bastlit v bashi. IMHO se i za této "holé" podoby dá použít pro jakýkoli stroj. Některé bystřější jako je Christian to vede ke "konfekční" (univerzální) sadě skriptů v podobě ignitu, což znamená, že kromě strojů to může uchlácholit i mnohé uživatele. Konečně tu je zcela otevřený source code pro znalé schopné posunout runit k ještě lepší použitelnosti. Co se týče rebootu, nevidím problém, neb to řeší standardně init level. Co se do těchto úrovní nacpe specificky dle specifikace v kernel line, to se bude specificky (re)startovat. Sám s tím nemám dost zkušeností, abych tu byl za znalce, ale jsem před experimenty, o nichž podám časem zprávu. Nicméně třeba údajný problém v hierarchii staru služeb je problémem pouze potud, pokud autoři těchto služeb v rámci vývoje jádra nespecifikují zvláštní požadavky na pořadí, jež implicitně nevyplývá z povahy daných služeb.

[trekker.dk]

Co se týče rebootu, nevidím problém, neb to řeší standardně init level.

Psal jsem restart (runitu), ne reboot (stroje). Reboot by IMO byl ještě v pohodě, ale představte si, že uděláte nějaký update a potřebujete restartovat runsvdir jako takový. To moc dobře nejde.

Nicméně třeba údajný problém v hierarchii staru služeb je problémem pouze potud, pokud autoři těchto služeb v rámci vývoje jádra nespecifikují zvláštní požadavky na pořadí, jež implicitně nevyplývá z povahy daných služeb.

Jakou souvislost má vývoj jádra s pořadím služeb v userspace?

[PanZvedavy]

Momentalne jsem ve fazi, kdy opet a znova hledam vhodne distro pro sve potreby na desktop. Po precteni features to vypada zajimave.

Hlavne pozaduji rolling distro, idealne moznost nastaveni nejake stabilni-konzervativni vetve balicku, odvsiveni od systemd bude prijemnym bonusem. Momentalne bezim na Sabayonu a po kazdem update se desim co se zase posere, naposledy po update firefoxu jsem prestal videt pismo v nabidce programu :). Uz sem premyslel o nejakem zautomatizovanem systemu snapshotu LVM, pred kazdym updatem a ted bum, VOID linux jak blesk z cisteho nebe...to urcite nebude nahoda, pravdepodobne zasah nejakeho linuxoveho bozstva bo co.

Pouziva to nekdo? Nejake reference?

[andree]

Nebolo by jednoduchsie forknut systemd a mergovat do toho len veci ktore davaju realne (aj haterom) zmysel? Alebo je ten kod taka prasarna, ze ti nikoho nelaka?

[mankind_boost]

Osobne jsem taky uvazoval nad forknutim systemd a vyhazenim bordelu. Kod vypada celkem ciste a je komentovanej.

[martin.k]

nebylo.

a) systemd fura lidi povazuje za wrong by design, takze jina implementace z definice nemuze prinest vyrazne zlepseni

b) runit je zalezitost stara cca. 10 let, kdyz zapocitame daemontools, ktere jsou predchudcem, tak to je nejakych 15 let. je jednodussi forkovat cosi co ma >500.000 LOC, nebo vzit neco co uz davno existuje a prokazatelne funguje?

[rADOn]

Vetsina veci v systemd je nejak uzitecna, ale nema jiny duvod byt zrovna tam nez Lennartovu neschoponost videt veci jinak nez jako funkci systemd. Treba deklarativni pridavani uzivatelu se mi libi a usnadnuje balickovani, ale s initem nema spolecneho lautr nic. Kdyby si nekdo dal praci a rozstrilel to do samostatnych projektu tak by to rozhodne neskodilo.

Ale porad zbude spousta veci ktery dela systemd primo v pid 1 ktery nejde vykostit bez velkych zmen uvnitr. A to je prave ten defektivni design kterej zkusenejsi lidi stve nejvic.

[andree]

Mne popravde nevadi funkcionalita v PID==1, pokial na to je testsuita a su to rozumne veci. Trebars ta vec s DHCP serverom nakoniec neznela az tak strasne, ked je to len par sto riadkov kodu vo vysledku.

Ale pridavat to do systemd len preto, ze sa mi trebars nechce robit API, alebo novy balik - proti tomu by bolo treba "zakrocit". Takze vykostit DHCP server a spravit API a rovno by default pouzivat 'trivialdhcpserver-by-lennart', ale umoznit napr. dnsmasq ako nahradu. Bohuzial rovno dodavam ze na to cas nemam, mam dost programovania i v praci a na inych OSS projektoch (ja viem, trapny argument), a nemam ani zdaleka dostatocny prehlad o diani v systemd.

Kazdopadne mi pride efektivnejsie "bojovat" s Lennartom takto - ze mu ukaze komunita ze to ide lepsie, nez sa snazit vymysliet dalsi init system.

[chrono]

Nemyslím si, že by sa RedHat akokoľvek zaujímal o názor komunity (a z ich projektov sú už teraz odstraňované niektoré vlastnosti, pretože to predsa rieši SystemD...).

[andree]

Pochybujem ze by sa tvarili tak arogantne, keby im komunita povedala "takto nie", a po chvilke by si zakaznici uvedomili, ze nemienia udrzovat jeden software pre "RedHat" a druhy pre vacsinu="komunitny linux". RedHat stale nie je majoritna distribucia, tusim...

[j]

To se jeste dost pravdepodobne stane, protoze zakaznici to na svych strojich jeste nemaji. A je dost pravdepodobny, ze znacna cast adminu se k tomu postavi tak, ze rozhodne nehodlaji adminovat blackbox, kterej se nasere do vseho, a nikdo nevi, co kde a proc vlastne dela ...

[pavlix]

Tak Red Hat je komerční firma, ale je tu spousta komunitních distribucí, které na systemd z různých důvodů přešly.

[Rezza]

Systemd je ale komunitni projekt. Red Hat si jen plati lidi, aby tam dopsali funkcionalitu, kterou potrebuje pro sve zakazniky (protoze to neni Lennartuv use case) + bugfixing :).

[kavol]

Red Hat si jen plati lidi, aby tam dopsali funkcionalitu, kterou potrebuje pro sve zakazniky (protoze to neni Lennartuv use case) + bugfixing :).

"jen"? - teď se nepřipojím na VPNku, ale ono se od pondělka něco změnilo, on RH už Lennarta neplatí?

[pavlix]

umoznit napr. dnsmasq ako nahradu.

Jestli bude umožněný dnsmasq jako náhrada záleží jen na kódu systemd-networkd, což je primární uživatel té DHCP knihovny. Ale nepředpokládám, že by o něčem takovém někdo uvažoval, byla by to pro ně jen práce navíc. To už vidím větší šanci, že NetworkManager dnsmasq časem úplně opustí ;).

[Matlák]

Mno, aby to nedopadlo tak že NetworkManager časem bude nahrazen právě systemd-networkd.

[pavlix]

A to by byla dobrá nebo špatná zpráva?

[mankind_boost]

Jak by to asi mohla být dobrá zpráva? Co by na tom bylo dobrého?

[pavlix]

Reagoval jsem jen na obsah komentáře, nepodíval jsem se, zda nenese přezdívku některého ze známých systemd haterů ;).

Teď vážně, NetworkManager je často kritizovaný projekt a existují lidé, kteří jsou nadšení z možnosti, že by mohl být nahrazen, stejně jako je systemd často kritizovaný projekt a existují lidé, kteří se děsí možnosti, že by nový nástroj z jeho stromu měl něco nahradit. Dokonce se ty dvě skupiny prolínají. Z toho pohledu může být výměna NetworkManageru za systemd-networkd pozitivní, negativní i neutrální.

Jinak se počítá s tím, že NetworkManager bude časem spoléhat na systemd implementaci DHCP, stejně jako systemd-networkd. Navíc si NetworkManager prozatím podržel pevnou závislost na udevu. Jak moc půjde NetworkManager používat bez systemd a různých udělátek poskytujících API jednotlivých částí systemd, záleží jen na zájmu aktivních uživatelů, tedy natolik aktivních, že sledují vývoj a čas od času pošlou patch a ještě ho mají chuť dopilovávat.

Naposledy se řešilo to, aby systemd šel zkompilovat s podporou systemd-logind a ConsoleKit a vybral si z nich až za běhu. Našel se člověk, co poslal patch, ale dolaďoval jsem ho já, a to jsem ještě experimentoval jak s OpenRC, tak se systemd na Gentoo, takže se mě to i přímo týkalo.

Ale já osobně bych třeba vyhodil podporu NM pro dhcpcd a nechal jen dhclient a libsystemd-dhcp, protože s dhcpcd to stejně nefunguje správně a používají to jen gentooisti a to ještě kvůli šíleným vývojářům, kteří si o tom nic nezjistili, ale usoudili, že dhcpcd je děsně alternativní a cool.

Nicméně, nikdo neví, co bude systemd-networkd za pár let umět a v jakém stavu bude tou dobou NetworkManager a lze tedy jen těžko předpovídat, kterou cestou se budou distribuce ubírat a jestli NetworkManager zůstane výchozí volbou příštích pět let.

[mankind_boost]

Mně se jen nelíbí, že se z toho stává hnusnej moloch, co umí od každýho kousek. Proti systemd nic extra nemám (sám ho používám). V modularitě je síla a věřím v unixovou filosofii.

[pavlix]

Vnímám to podobně :).

[Matlák]

To je otázka. On Linux jako jádro je velmi úspěšný i proto, že umí všechno, od podivných okrajových architektur na malých routerech, přes telefony a dotykové hračky až do automobilových sběrnic, přes RT a multimediální aplikace až po nejnovější virtualizační podpory na procesorech v datacentrech a na superpočítačích. Jsou lidé, kteří mu vyčítají to že je monolitický. Že je to jeden veliký blok kódu, který je sice modulární, ale není na to až tak brán zřetel, binární ABI ovladačů Windows prostě nahrazuje otevřenými zdrojovými kódy.

Jestlipak něco podobného nechce pan Lennart udělat se systemd? Možná má (a možná i právem) pocit že úspěch Linuxového jádra je v ostrém kontrastu z úspěchem různých konstelací stovek a tisíců malých, evolucí řízených produktů tržiště, které jako celek mají úspěch obrovský, ovšem není za tím jedno slovo (jako "Linux"). Není za tím jeden člověk (jako Linus Torvalds, vyhrazující si právo některé commity prostě odmítnout, skoro jako v té katedrále). Možná chce Lennart zaujmout přesně tento pomyslný "trůn", tuto stolici velitele userspace moderních distribucí Linuxu.

IMHO Tím že integruje všechny věci pod sebe, vytváří systemd prostředí, kde bude Lennart schvalovat každý commit stále se rozrůstajícího ekosystému systemd, kde bude velká komunita vytvářet moduly a diskutovat subsystémy přesně tak, jak bylo odkoukáno od jádra.

Asi to bude pro funkčnost lepší. Otázka zní, jestli bude větší svoboda. On i ten Linux vlastně celkem omezuje...

[Drom]

stolice velitele Lennarta, hezký dvojsmysl :)

[rADOn]

Srovnávat jádro a systemd není fér. Jádro má praktické důvody proc je postavené tak jak je postavené – ring0 je jen jeden. A jaderní vývojáří jsou si – narozdíl od Lennarta – viditelně vědomi úskalí která to přináší. Třeba všechny ty více či méně exotické kusy hw které jsi jmenoval potřebují sdílet společnou kódovou bázi, narozdíl od spousty "součástí" systemd které by klidně mohly žít samostatně. A přesto se, zase narozdíl od systemd, věnuje nemalá péče tomu aby sis do kernelu mohl zakompilovat jen to co je nezbytně nutné, vybírat z alternativ a kde to jde se funkce přesouvají do userspace. Nemluvě o legendárně rozdílných přístupech Linuse a Lennarta ke kompatibilitě a regresím, že.

To že se Lennart považuje za spasitele a vrchního stratéga linuxu je dost zřejmé. Ale metody neodkoukal od Linuse jako spíš od Steva Jobse. Stejně jako asi milion jiných magorů.

[Petr Ježek]

Runit je "starý" přesně třináct let, s deamontools 17 let, linux je starší, o unixových příkazech a utilitách nemluvě. Stáří není argument. Argumentem by bylo, že se za tu dobu runit nijak nevyvíjí, což je v rozporu s realitou. Pochopitelně že hlomoz lidí z jakéhokoli důvodu odmítajících systemd vede k aktivizaci vývojářů schopných oživit starší, ale dobře koncipované projekty výhodně použitelné právě dnes.

[martin.k]

stary != zastaraly - jen jsem chtel naznacit, ze runit neni nic, co by vzniklo jako projekt nejakeho "systemd-hatera", takze argument "nebylo by lepsi forknout systemd" je tak trochu mimo misu. to, ze unixove principy vydrzely 40 let je pro me spis dukaz kvality (nadcasovy design, dalo by se rict). runit unix principles striktne dodrzuje, systemd je vedome odhazuje coby zastaraly balast... ostatne, i kdyby se runit nevyvijel vubec, neznamenalo by to nutne nic spatneho. inovace pro inovaci neni zadne plus. nakonec: treba kolo zname tisice let a nic lepsiho pro dany ucel zatim nikdo nevymyslel :)

[andree]

Nepoznam detailne vnutornosti ani jedneho, ale forkuje sa aj cely android ci OpenSSL, takze nemyslim ze pocet SLOC je nejaky dovod. Ani to ze ma runit 10 rokov neni dovod (jedine ze by ho niekto realne vo velkom pouzival, ale popravde to vypada na dost akademicky projekt, na prvy pohlad).

Netrepi ma nejaky argument "je to proti filozofii unixu", pokial to je kvalitny kod, pripadne ten design "all in pid 1" nie je samoucelny. Z toho co som doteraz cital vypada ze oboje je pravda.

[martin.k]

nejak porad nevidim usacase pro fork. imo vetsina lidi, co nemaji radi systemd ho odmitaji prave pro jeho antiunix povahu a pro jeho design. kritici toho, jak je systemd implementovany se snazi ho menit zevnitr. navic, pokud by se fork chtel udrzet funkcne zamenitelny se systemd, znamenalo by to, ze by vyvojari museli jen neustale dohanet zmeny, ktere by se dely v hlavnim systemd - a to neni (zvlast pri vedomi lennartovy hyperproduktivity) moc lakava predstava.

co vas trepi ci netrepi je mi uprimne jedno, ale presto si dovolim doporucit knizku "art of unix programming" od erica s. raymonda (vyslo i cesky, i kdyz preklad ma par much zvici vetsi masarky), ktera je cela o unixove filozofii. mozna pak uvidite, ze na tech nekolika jednoduchych pravidlech neco je :) ostatne, tahle "unizova filozofie" prispela velkym dilem k tomu, ze unix dneska neni zapomenuty koncept z dejin IT, ale nejuspesnejsi operacni system (ok, rodina systemu), ktery kdy existoval.

[JS1]

imo vetsina lidi, co nemaji radi systemd ho odmitaji prave pro jeho antiunix povahu a pro jeho design

Proc je systemd navrzen v rozporu s "Unixovou filozofii" a proc je Linux (makrojadro) navrzen s ni v souladu?

[rADOn]

To neni soulad ale nezbytnost. A tam kde to jde existuje znatelna snaha tlacit veci z jadra do userspace (udev, fuse…).

[pavlix]

IPv6 router discovery... ;)

[mankind_boost]

"Delej jen jednu vec a delej ji dobre."

[Spike]

Floskule.

[mankind_boost]

Prosim, diskutuj na urovni.

[chrono]

Aký zmysel by to malo? (hlavne keď aplikácie budú vyžadovať aj tie veci, ktoré zmysel niekomu nedávajú)

[andree]

Aky vyznam ma mat KDE, GNOME a XFCE, ked vsetci robia to iste? .-) Alebo nerobia?

Navyse to vypada, ze pan systemd si aktualne do vyvoja komunitou prilis kecat nenecha - ale ak by par vacsich distribucii pouzivalo "sane fork" systemd, mozno by musel svoj force-it styl vyvoja zacat prehodnocovat, a pripadne zhovadilosti by mu nepresli tak lahko ako doteraz (pri kazdom vydani sice vznikne vlna "odporu", ale "uz je von, takze smolicek, musite s tym zit deti"...). Mozno by nedajboze musel aj dopredu konzultovat zmeny v interface, navrhnut standardy...

[martin.k]

KDE nebo XFCE jsou forky GNOME? nebo GNOME je naopak fork KDE? hmmm, tak to je pro me novinka... diky za vyvedeni z omylu, ja vul jsem zil 15 let v predstave, ze GNOME je na KDE naprosto nezavisle (dokonce, ze ani toolkity pod nimi - GTK+ a QT - spolu nemaji nic, ale vunec nic spolecneho).

[andree]

Samozrejme je mozne si tie 2 komentare takto absurdne zlozit... Chcel som tym ale povedat, ze paralelny vyvoj jedej veci nie je vzdy na skodu - KDE a GNOME boli na zaciatku uplne ine a v mnohych veciach nekompatibilne prostredia. Dnes mame freedesktop - a tak velka cast konfiguracie je rovnaka nezavisle na pouzitom GUI...

Takze ak by existovali systemD, libreD a whateverD, ale vsetci mali navonok ekvivalentne API, je to lepsie ako ked bude s kazdym releasom systemd vymyslat blbosti o ktore linux svet nestoji, ale v zasade nema ako ich "zmenit" (a jedine co moze je vylievat smutok na forach).

[Rezza]

Tak GNOME vzniklo jako truc projekt kvuli spatne licenci Qt v te dobe.

[martin.k]

tak jo, ale kodu spolecnyho moc nemaji, a od doby GNOME 2.0 se zacaly vyrazne rozchazet i koncepcne. jeste by se dal (pro pametniky) pripomenout projekt harmony. myslim, ze zrovna kontextu tehle diskuse o forku by to vlastne nebyla ani tak nesmyslna paralela :)

[j]

Ale ty to nechapes, tady vubec nejde o systemd, at si ho pouziva kdo chce, tady jde o to, ze system se sere do naprosto vseho, takze bez nej nemuzes provozovat hromadu zcela nesouvisejicich veci. Uz tu ostatne byl i pokus to nacpat do kernelu ...

A prave to je jeden ze zasadnich duvodu, proc to v zadnym pripade nepouzivat, protoze zachvilu budes mit na serveru, kde potrebujes provozovat postfix, nainstalovany i cely widle, protoze se je ten magor rozhodne integrovat ...

[pavlix]

Uz tu ostatne byl i pokus to nacpat do kernelu...

Pokud se zde mluví o věcech jako kdbus nebo single cgroups tree, nebyl ten pokus náhodou úspěšný?

[Spike]

Že by? [Phoronix] Uselessd: A Stripped Down Version Of Systemd

[pavlix]

To mi něco značně připomíná.

[xxl]

Runit je fajn. Systém se nastaví a pak prostě funguje. Problém je ten, že nastavení pro jednotlivé služby musí udělat člověk sám, protože to distribuce přímo nepodporuje. Také je dobré logování pomocí socklog.

[Petr Ježek]

Právě, to nastavení je přesně v duchu Archu - setup once for ever. Jedinou nejistotu je budoucí vývoj udev v rámci systemd, resp. zásadní pokrok v použitelnosti mdev.

[R]

Once forever, ale pri najblizsom upgrade sa to rozbije.

[pavlix]

+1

[AsciiWolf]

+1

[Petr Ježek]

Někomu ano, někomu po celou dobu víceletého používání nikoli. Ono to chce kromě jiného číst zprávy a instalační komentáře... Ostatně rolling release koncepce není pro každého...

[d.c.]

A co kdyz nekomu vyhovuje v Unixu standardni init? To uz dnes ve svete Linuxu neni ani 'hater', ale rovnou 'looser'?

[Petr Ježek]

Dane, zkuste si projít způsob argumentace proti systemd u lidí, kteří k němu mají výhrady. Pak pochopíte, že to v drtivé většině jsou prostě systemd haters. O loosers se nevyjadřuji ani u civilních témat běžného života, je to silně pejorativní.

[Spike]

Koutek jazykového nácíčka:

• looser = volnější (2. stupeň adjektiva loose, volný)
• loser = nula, ztroskotanec, poražený (od slovesa to lose, prohrát)

Ne že by loose nemělo taky pejorativní význam (loose woman), ale to nebude tenhle případ. ;)

[Petr Ježek]

Omluva za ztrátu namísto zoufalosti navzdory nadbytečnému "o" :/ Občas mi anglická gramatika uteče navzdory fonetické předznačnosti...

[d.c.]

Omlouvam se, to byl fakt jenom preklep, jinak bych musel vratit statnicky z AJ. :o)

[d.c.]

…sakrys "statnice". Neradi on mi tu nejaky automaticky korektor?

[pavlix]

Pak pochopíte, že to v drtivé většině jsou prostě systemd haters.

Argument statistikou je v tomto případě trochu mimo, ne? Drtivá většina je například 90%, což u tisícovky lidí znamená sto lidí s dobrými argumenty ;).

[Petr Ježek]

Ony nebyly ty "dobré argumenty" důvodně zpochybněny, ne-li přímo vyvráceny? Jinak ctím onu vzdělanou desetinu populace, která sobě a jiným dokáže klást zvědavé otázky a přicházet se zajímavými řešeními.

[pavlix]

Ony nebyly ty "dobré argumenty" důvodně zpochybněny, ne-li přímo vyvráceny?

A byla všechna relevantní kritika projektu a jeho vývojářů důvodně zpochybněna, natož vyvrácena? Moc rád bych viděl člověka, který vyvrací výhradně hodnotnou kritiku a nepodlehne pokušení si ulehčit práci tím, že se opírá do nesmyslných útoků.

[Heron]

Hehe. Mě se "líbí" ten přístup. SystemD můžete buď používat, nebo nenávidět.

Kde jsou ty časy, kdy se věci dělaly protože existuje důvod pro a nikoliv proto, že neexistuje důvod proti.

[martin.k]

jeste ho lze pouzivat a (prave proto) nenavidet :)

[pavlix]

Dokonce spíše než zcela ignorovat díky nepoužívání.

[Petr Ježek]

Je ovšem možné, že používat znamená racionálně vědomě s výhodou, zatímco emoce reprezentuje pouze pocit nevýhodnosti či přímo špatnosti... Zamilovat se znamená potlačit racionální kritičnost :)

[Frack]

Lennarta uráží, když to někdo píše jako SystemD a ne systemd, ale počítám, že pro tebe je to o důvod víc v tom pokračovat

[Petr Ježek]

Nad tím by se pozastavil každý, kdo má rád sématicky čistou terminologii.

[pavel]

Kde jsou ty časy, kdy se věci dělaly protože existuje důvod pro a nikoliv proto, že neexistuje důvod proti

Přesné +1

[Bystroushaak]

Pořád jenom hate

[coder]

+1

[Petr Tomášek]

čekat na maturitu gnu/dmd

chudáci středoškoláci

[Ondra]

dmd, guix i hurd ziji, takze jednoho dne se dockaji i stredoskolaci

https://www.openhub.net/p/gnudmd

https://www.openhub.net/p/gnuguix

https://www.openhub.net/p/hurd

[Tom]

http://boycottsystemd.org/

[coder]

Plan 9 jsem neznal, tak alespoň k něčemu mi ten odkaz byl užitečný

[mankind_boost]

Joo, skoda ze linux neni vic jak p9. Podle me nejlepsi zatim vymyslena architektura OS.

[Petr Ježek]

Je smutné, že mnohé "nejlepší zatím architektury" nejen OS jsou pro nepřekonatelné obtíže vývoje zcela nepoužitelné v praxi. Plan9 je z dob UNIXového mládí a u Bellů nemohli tušit, že geniální produkt si nenajde ani své geniální uživatele... Tím narážím na to, že pochopit geniální design a současně jej přijmout jako denně používaný nástroj jsou dvě zpravidla nekompatibilní věci...

[mankind_boost]

Pochopit p9 je ale paradoxne lehci nez pochopit unix. Zadny symlinky, PATH, block/char device nodes, superuzivatel... Vsechno je mnohem cistci a jednodussi.

Neuspel, protoze nema drivery ani moc softwaru (neni kompat s unixem). Jinak je lepsi v kazdym smeru.

[Bystroushaak]

Jinak je lepsi v kazdym smeru.

Kromě provázanosti s GUI, které je mimochodem naprosto zfetované.

[mankind_boost]

To ano, ale gui se dá vždy nahradit jiným.

[jkb]

Neuspel, protoze nema drivery

to jsem si take myslel, ale ono to vlastne neni tak strasne. U nas se nasazuje napr. centos a kdyz davame dohromady server, tak se osvedcilo pouzivat mainbord minimalne 2 roky stary, aby vsechny drivery fungovaly. S takovou zakladni deskou mohu provozovat plan9 zrovna tak.

[mankind_boost]

P9 na tom neni spatne, ono je na tom primo katastrofalne s driverama. Tam funguje dobre vpodstate jen klavesnice, mys a nejaky genericky sitovy karty.

[JS1]

Tak teoreticky by se takova vec dala prakticky pouzivat pod nejakym virtualnim strojem, ne?

Ale je otazka, zda Plan 9 pouzivat kvuli necemu jinemu nez prave uzivatelskemu rozhrani. Vsechny ostatni systemy toho umi daleko vic.

[mankind_boost]

"Ale je otazka, zda Plan 9 pouzivat kvuli necemu jinemunez prave uzivatelskemu rozhrani."

? Tohle jsem moc nepochopil. Hlavni zmeny jsou prece pod kapotou (factotum, venti, fossil, plna sitova transparentnost - sdileni vypocetni sily, procesu, oken, souboru, zarizeni, ...). Koho zajima rozhrani?

 

PS:

Jde nejak na linuxu udelat neco jako na plan 9 prikaz "cpu"? Spusti shell na vzdalenym CPU  serveru, ale je to jako kdybych ho pustil lokalne (vidi lokalni soubory, zarizeni atd.)

[mankind_boost]

Beru zpet prvni odstavec, neumim cist. Sry.

[Bystroushaak]

Tak teoreticky by se takova vec dala prakticky pouzivat pod nejakym virtualnim strojem, ne?

Když jsem to zkoušel naposled, tak mi to pod quemu neběželo. Pozitivní ale je, že někdo přidal podporu raspberry pi, takže je zde jeden krásně unifikovaný a rozšířený hardware, kde se si s tím člověk může hrát :)

[Václav "Darm" Novák]

A co inferno? Přinejmenším to vypadá docela zajímavě Začalo v Bell labs a je založeno na ideích z Plan9

[Bystroushaak]

Není náhodou inferno úplně mrtvé? Když jsem o něm naposledy hledal informace, tak všechny články vypadaly 10+ let staře.

[Václav "Darm" Novák]

Poslední release je 5 let starý, dá se to rozchodit na Nintendu DS a mailing list taky ještě zcela nezemřel

[Václav "Darm" Novák]

Každopádně je to mnohem živější než Plan9.

[Tom]

Plan 9 jsem neznal,

to je sila, co sem posledni dobou chodi za lidi

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

... no a já už na něj zapomněl.

[Petr Ježek]

Spammer?

[kavol]

zkus vyhledat odbornou pomoc, nejsi-li si jist svojí identitou ...