Názory k článku
Devuan 1.0 LTS, aneb Debian Jessie bez systemd
-
lopata (neregistrovaný)
Tak já začnu. Nehodlám shazovat vývojáře, odvedli kus práce a investovali do Devuanu spoustu času (a tím i peněz). Nicméně je potřeba ptát se, kolik uživatelů si to najde a zda má takový fork nějaký praktický smysl: http://popcon.debian.org/
1.61 (jessie/stable) : 120181 1.61-4+devuan : 718 1.64 (testing/unstable) : 27294
Devuan má uživatelskou základnu asi 0.6% stabilní jessie. I testing/unstable má násobně víc uživatelů. Zřejmě to ještě půjde nahoru, ale na úspěšný projekt to zatím moc nevypadá.
-
lopata (neregistrovaný)
Linux není fork Windows. Use case pro Linux a Windows se značně liší. Devuan je fork Debianu. Use case pro Devuan a Debian je prakticky stejný. Potencionální uživatelé Devuanu nepřijdou z Windows, ale jedině z Debianu. Zatím to nevypadá, že by Devuan nějaké významné množství uživatelů Debianu získal.
-
Systemd a jeho nasazení je součástí snahy (velmi, velmi potřebné), aby Linux byl konkurenceschopný i v use cases, které jsou dosud výsadou Windows. Jinak souhlas, akorát nevím, kolik současných uživatelů Debianu přejde na Devuan. Drtivá většina jich už dávno povýšila na jessii. Kdyby byl Devuan přišel někdy před rokem až rokem a půl, tak možná... Z Windows na Devuan samozřejmě nikdo nepřejde (ani na Debian). Pokud vůbec, tak jedině snad na Ubuntu nebo na Fedoru.
-
Duff (neregistrovaný)
To bohužel není pravda.
journald se nedá jednoduše odstranit. DNS cache taky ne. Jejich implementací crona si taky nejsem jistý jestli jde vykuchat s kdo ví co tam ještě pohltili nebo najradili svojí impmementací.
Komunikace mezi jednotlivými částmi systemd není nijak stabilizovaná a nemá žádnou doložku o stabilitě rozhraní, takže je výměna dosti složitá a v každé verzi je potenciál, že se rozpadne.
-
Duff (neregistrovaný)
https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/
The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:
Undocumented switches to systemd, systemctl and otherwise
The internal protocols used on the various sockets such as the sockets /run/systemd/shutdown, /run/systemd/private. -
Filip JirsákStříbrný podporovateljournald se nedá jednoduše odstranit.
Samozřejmě, že se nedá odstranit – musíte jí nahradit. A to možné je, API je veřejné.Komunikace mezi jednotlivými částmi systemd není nijak stabilizovaná a nemá žádnou doložku o stabilitě rozhraní, takže je výměna dosti složitá a v každé verzi je potenciál, že se rozpadne.
Stokrát opakovaná lež se stává pravdou? Veřejná API jsou stabilizovaná a mají doložku o stabilitě rozhraní (což rozhodně není samozřejmá věc). Interní rozhraní stabilizovaná nejsou, ale neměl by být důvod je používat. Pokud byste něco z toho potřeboval, chtělo by to připravit příslušné veřejné rozhraní a ne se snažit vlámat do interního rozhraní. -
muf (neregistrovaný)
Uživatelé přijdou i od jiných distribucí Linuxu - nejen od Debianu. Vidím to u sebe. Jeví se jako zajímavá alternativa a jiná možnost, pokud se na některých strojích budu chtít vyhnout vztekání se systemd, téměř není. CentOS6 už je v závěrečné fázi podpory a bez budoucnosti.
Hvězda desktopu to pochopitelně nebude.Vaše péče o uživatelskou základnu distra, kterému teď sotva vyšla první stabilní verze, je dojemná.
-
lopata (neregistrovaný)
Existuje jednoduchá rovnice: málo uživatelů -> neúspěšný projekt, hodně uživatelů -> úspěšný projekt. Projekt, který dlouhodobě nemá uživatele, nemůže ve světě open source přežít. Bez uživatelů nebudou bugreporty, nebudou vývojáři a nebudou ani případní sponzoři.
Mně je Devuan celkem volný, ať si ho používá, kdo chce. Nicméně je dobré si uvědomit, že je to distro vydávané dnes, ale založené na jessie, která vyšla před dvěma roky a Debian jako takový je vzhledem ke svému konzervativnímu vývojovému cyklu celkem zastaralý už v době vydání.
-
Ani ne tak péče, jako spíš úvaha, která se nijak nesnaží být dojemná. Devuan je primárně konkurent pro jessii, ta už tu ale dávno je a má své uživatele, takže že by ji někdo odinstaloval a místo toho instaloval Devuan opravdu není moc pravděpodobné, na tom není nic dojemného. Devuan tedy bude muset lovit uživatele jinde. S tím CentOS 6 máte pravdu, toho se zatím skutečně drží mnozí z těch, kteří odmítají systemd (na rozdíl od RHEL 6, tam jde především o podporu ze strany vendorů a přítomnost nebo nepřítomnost systemd nehraje žádnou roli), a Devuan pro ně může být perspektivní alternativou. Další zájemci se asi najdou mezi BSĎáky, kteří buď přímo přecházejí na Linux nebo ho chtějí používat souběžně s BSD. Ti tradičně volili Debian ale většinou jsou taky proti systemd, takže Devuan je zaujme.
-
muf (neregistrovaný)
V *BSD, HP-UX, Digital Unixu, Solarisu atd.... tyto věci opravdu nechyběly/nechybí. Proč bych se vracel k prehistorickým verzím Bell labs. atd. z přelomu 70. a 80. let? Když vznikaly, prostě např. TCP/IP nebyly na světě. Oproti nim systemd nic převratného nepřináší.
Argumenty na úrovni základní školy diskusi nikam neposunete.
-
HPUX ani Digital Unix moc neznám, ale v tom Solarisu nebo třeba v AIXu mimochodem nechybí ani obdoba systemd, když už je o nich řeč. Ale je to trochu jinak. Ty příklady jsem totiž necitoval náhodou. Pokud jste tu dobu nezažil (ani já), tak si to můžete snadno dohledat: u každého jednotlivého z nich totiž nastaly podobné reakce, jako u systemd: že to prý "není Unix" (jakoby na tom záleželo), že to bude mít zlé důsledky pro komunitu (no jistě), atd, atd, atd. Ano, i v případě TCP/IP, i v případě multithreadingu a ostatních tomu tak bylo. S tím, že v podtextu byla a je stále tatáž pozoruhodná představa: kdo takové věci potřebuje "nic nechápe" a měl by změnit své požadavky a potřeby podle toho, co umožňuje Unix (a především podle toho, co NEumožňuje), namísto aby se OS přizpůsobil uživateli. Při trošce nadsázky (ale opravdu jenom trošce) je to v podstatě že lidé mají zapomenout na grafiku, na web, video, virtualizaci, hry atd. a místo toho se mají učit používat vi a konfigurovat sendmail.
-
muf (neregistrovaný)
Nevím jestli je za tím brilantní jirsákovská demagogie nebo jen nedostatek informací.
Vyjmenované věci nikdy významně neútočily na podstatu filosofie daného OS. Šlo o vylepšení a přirozené doplnění o nové technologie. Jistěže se to někomu nelíbilo, ale takové diskuse utichaly poměrně rychle, protože nebylo.moc o čem diskutovat.
Systemd je poněkud jiný "level". Přináší dosud nepoznané problémy a zlozvyky ze světa mimo Unix - většinou přesně to co nás tam otravuje.
Init v Solarisu(pokud vím) není filosofie systemd. Ono to není v tom, že se nepíší shell scripty, nahazující služby atd. Pokud by systemd zůstalo init systémem, tipuju, že by vadilo málokomu(v tomto směru je snadné se přizpůsobit). Problém je v zavádění podivných závislostí, snaze dokonce i o přiohýbání kernelu pro pochybné účely a vzdalování se od kompatibility s ostatními podobnými OS.Je to složité, neustále nedodělané a nechová se to zcela deterministicky.
Z Linuxu se tak může stát podivné cosi - ani VMS nebo Windows ani Unix, slepenec těch nejhorších přístupů ze všech světů.Proto díky za Devuan. Linux pořád může být snadno použitelný Unix.
-
Filip JirsákStříbrný podporovatel
Přináší dosud nepoznané problémy a zlozvyky ze světa mimo Unix - většinou přesně to co nás tam otravuje.
Například?Já na systemd oceňuji například to, že i do světa služeb přináší tradiční unixovou filozofii – dělej jen jednu věc, ale dělej ji pořádně.
Třeba webový server musel dříve odpovídat na požadavky na webové stránky, a vedle toho se ještě musel starat o logování a rotaci logů, naslouchání na privilegovaném portu a následné vzdání se rootovských oprávnění, o daemonizaci o nějaké servisní rozhraní, přes které bylo možné vyvolat přenačtení konfigurace (v nejprimitivnější podobě např. zápis PID serverového procesu do souboru). Nic z těch věcí navíc se systemd dělat nemusí – stačí, když vyřizuje požadavky na webové stránky, o to ostatní se postarají komponenty správce služeb. Logy server posílá na standardní výstup, o naslouchání v síti se může postarat systemd, a pokud to chce dělat server sám, povolím mu jenom capability cap_net_bind_service, daemonizaci server nedělá a komunikovat s ním může systemd přes signály rovnou, protože serverový proces je přímo potomkem procesu systemd, takže jeho PID systemd zná.
Pokud by systemd zůstalo init systémem, tipuju, že by vadilo málokomu
Jenže init systémů je dost, nevím, jestli je potřeba psát nějaký další. V linuxu ale chyběl správce služeb – což se ukázalo například na těch jiných init systémech, které sice pár problémů vyřešily, ale vždy narazily na limity init systému, který jen spouští procesy a dál se o ně nijak nestará. Přitom unix má tu perfektní vlastnost rodičovského a dceřiného procesu, kdy rodičovský proces má dceřiný proces na starost a dostává zprávy o jeho průběhu. To je pro správce služeb perfektní podpora, ale klasický init systém toho prakticky nevyužívá.
ČLÁNKY DO MAILU