Názory k článku
Vyšel Devuan 2.0.0 ASCII, Debian bez systemd
-
Fuki (neregistrovaný)
Ja som myslel ze Devuan je len serverove distro. A pozeram, ze oni tam balia aj desktopy? Naco je to dobre, ved prave desktopy tazia z vsetkych vyhod co systemd prinasa. Bezat ich na inite je asi tak super ako mat Babettu a pouzivat iba pedale, lebo sa mi ten motor nepozdava :-)
-
jouda (neregistrovaný)
Vezměme naprosto normální debian na naprosto normálním domácím desktopu, kde se dělají takové desktopové věci jako fejsbůček a jůtůbko v chromu, občas tam někdo napíše něco v libreoffice.
Teď se tajně lognu a prohodím to za sysv init, a jsem fakt zvědavej jak poznáte, že se to stalo bez přímého kouknutí.P.S. Odvolávám souhlas se zpracováním os. údajů nad rámec nutný pro odeslání postu.
-
Fuki (neregistrovaný)
Z pohladu BFU minimalne tieto veci:
- ovela rychlejsi boot
- viac pamati pre uzivatela
- viac disku pre uzivatela (binarne logy)
- fungujuci sleep !!!
- fungujuci plug & play
- ziadne obskurne bugy a polovicna funkcionalita - bude ide alebo nejde :-DKeby som mal vypisovat vyhody z pohladu powerusera ci linux developera tak mi nestaci strana. Akoze sysvinit nebol az taka katastrofa ale v porovnani s komfortom co prinasa systemd je te posun vpred jednoznacny.
-
Dekuji za snahu mi odpovedet, verim, ze se v necem vzdelam. Muzu tedy prejit k detailum?
- rychlejsi boot - dobre. V 99% probouzim ze spanku, ale beru to a nebudu sarkastický.
- vice pameti - slo by to kvantifikovat? Mam vetsinou fyz. 4-8GB, kolik ziskam?
- vice disku - ve /var/log mam nekolik MB (gz s rotaci), v /run/log/journal taky. Je to pod moji rozlisovaci schopnosti, nebo mi unika nejaka obecnejsi vlastnost?
- fungujici sleep == suspend? Pred rokem 2014 ale ntb taky usinaly? Alespon me.
- p&p moc nevim o co konkretne jde, ale psaval jsem udev skripty, kterym jsem rozumel. Ta doba je asi pryc, zato se mi automaticky mountuje usb do /media. Je to ono?
- obskurne bugy - to je typicka nahravka na flame. To nechme stranou.
- bud to jde nebo ne - totez. Nechme stranou, i kdyz mam jednu uplne cerstvou prihodu.
Takze opravdu diky za snahu. Zatim ale potrebuji presnejsi argumenty. A developera a roota nechme zatim stranou, rozmelnili bychom puvodni tema.
-
Delam si porad nadeje, ze me Fuki vic pouci, ponevadz nejaky zisk se systemd pro desktop bude. Takze znova nahazuji...
- vice pameti - slo by to kvantifikovat? Mam vetsinou fyz. 4-8GB, kolik ziskam?
- vice disku - ve /var/log mam nekolik MB (gz s rotaci), v /run/log/journal taky. Je to pod moji rozlisovaci schopnosti, nebo mi unika nejaka obecnejsi vlastnost?
- p&p moc nevim o co konkretne jde, automaticky mountuje usb do /media. Je to ono?
Zadne diskuze kde je vic a kde horsich bugu vest nechci, jen vyhody, ktere pozna end-user.
-
Jenda (neregistrovaný)
> - ovela rychlejsi boot
Průměrně se mi boot nezrychlil, protože bootuju jednou za měsíc, a ten o něco rychlejší boot když všechno funguje je bohatě vyvážen nezrušitelným 90sekundovým čekáním když se něco rozbije.
> - viac pamati pre uzivatela
To není pravda, oproti sysv initu mi přibyly procesy systemd --system/user a logind a navíc journald defaultně loguje do ramdisku, kde to zabírá pár desítek mega.
> - viac disku pre uzivatela (binarne logy)
OK (logy mi teda aktuálně zabírají 0.019 % místa na disku, ale budiž)
> - fungujuci sleep !!!
Mně naopak systemd sleep rozbil, protože ACPI eventy převzal loginctl, který ale neumí (resp. před 2 lety neuměl, třeba už se to opravilo) spustit arbitrary skript, takže jsem ho musel nahradit za původní acpid.
> - fungujuci plug & play
Nevšiml jsem si žádné změny.
> - ziadne obskurne bugy
Mně naopak přijde, že po nástupu systemd řeším obskurní bugy - zrušení rc.local, mount už není mount(2), ale něco, co spouští vygenerované mountovací unity a po změně fstabu se to musí reloadnout (což člověka překvapí pokud o tom nevěděl), programy vidí jako /tmp privátní adresář a ne skutečné /tmp (direktiva PrivateTmp), takže pokud jste si tam třeba vytvářeli kanárka/soket, ke kterému jste se pak zvenku připojovali, tak vám to přestane fungovat...
-
kraxna (neregistrovaný)
> Mně naopak přijde, že po nástupu systemd řeším obskurní bugy - zrušení rc.local, mount už není mount(2), ale něco, co spouští vygenerované mountovací unity a po změně fstabu se to musí reloadnout (což člověka překvapí pokud o tom nevěděl), programy vidí jako /tmp privátní adresář a ne skutečné /tmp (direktiva PrivateTmp), takže pokud jste si tam třeba vytvářeli kanárka/soket, ke kterému jste se pak zvenku připojovali, tak vám to přestane fungovat...
V prekladu - neco se zmenilo a je to spatne z principu.
-
kraxna (neregistrovaný)
> Něco je opravdu jen „nezvyk“ (což možná poukazuje na problém, že je málo dokumentace a howto jak zvládat tyto novinky),
Tak zrovna vytykat SD se da ledaco - ale zrovna absenci dokumentace? Kdyz si vzpomenu jak vypadala dokumentace k initu a dalsim vecem predtim.
> něco je problematické ne proto, že se to změnilo, ale proto, že se to změnilo ke složitějšímu/hůře debugovatelnému/hůře upravitelnému.
A co konkretne?
Naopak me napada spousta veci, co se zjednodusilo (unity, prenositelnost, jednoduchost zmeny, oddeleni systemovych / uzivatelskych sluzeb, monitorovani sluzeb, ...)
-
SB (neregistrovaný)
Jenda:
Složitější mi to nepřijde. I já jako laik, když chci např. spustit službu, udělám deklarativní unit, kde je 7 parametrů, když chci něco extra, tak kouknu do seznamu parametrů a vyberu si, co by dosáhlo požadovaného chování (i spouštění skriptů dle událostí tam je!), pak to má 11 parametrů. Všechny služby se spouštění, zastavují, restartují, zapínají, vypínají, ověřují stejně. Přijde mi to minimalistické a přímočaré.
Jak sysvinit řešil např. restartování padlých služeb?
-
Jenda (neregistrovaný)
> Jak sysvinit řešil např. restartování padlých služeb?
Nijak. Nejspíš se očekává, že máš plnohodnotný monitoring, protože ani systemd nemůže rozlišit stav "proces běží, ale zasekl se".
Ale já nekritizuji tu funkcionalitu init systému - ta mi naopak přijde docela dobrá (a určitě lepší než init co byl na Debianu předtím - protože ten byl fakt dost strašný. Jiné distribuce na tom možná jsou jinak.). Ale vadí mi některé ostatní featury, které to kromě initu pohltilo.
-
SB (neregistrovaný)
„a ten o něco rychlejší boot když všechno funguje je bohatě vyvážen nezrušitelným 90sekundovým čekáním když se něco rozbije.“
Čekáním na spuštění které služby? A co je na ní závislé? Nemáte někde nadbytečné závislosti (aťto od výroby, či vlastním přičiněním)?
A co by to udělalo se sysvinit? Vysralo by se na službu a zkusilo spustit další, závislé služby? -
Tohle neni muj thread, ale tohle cekani me zabiji, takze za sebe odpovim.
- prvne me to prekvapilo, kdyz jsem mel nadefinovanou USB ve fstab a system si neporadil a ani nenabehl
- casto se mi stava, ze nekde necham nejakej sitovej mount, kterej se pak pri vypinani snazi shodit a tak se ntb radeji nevypne
- naposledy jsem bojoval se spatnym fw pro wifi, nedokazal to po uspani rozbehnout a nasledkem zamrzal terminal u sudo nebo ifconfigNazory se mohou ruznit.
Nazor, ze ja smim spustit nebo vypnout podle nejakych receptu uz neni nazor, ale byrokraticke omezeni. At daji option nekonecno => 5s, option 'start @ all costs` a budu s tim ok.Nejaky flame nema cenu, pokud existuji moznosti modifikace chovani, dejte vedet.
-
Jenda (neregistrovaný)
> - prvne me to prekvapilo, kdyz jsem mel nadefinovanou USB ve fstab a system si neporadil a ani nenabehl
Hint: parametr "nofail". Dřív to byl default, teď ne. Osobně si myslím že systém by měl naběhnout za každou cenu byť třeba bez připojeného /home nebo /mnt/porno.
> At daji option nekonecno => 5s
Tohle bys měl vyřešit nějak lépe, protože tohle jsem jednou naivně nastavil (z 90 sekund na 9) a za chvíli se mi corruptnul filesystém, protože odpojení 6TB btrfs pole trvalo déle než 9 sekund a systemd to killnul uprostřed umountu a nechal to nekonzistentní.
-
Jenda (neregistrovaný)
> Čekáním na spuštění které služby? A co je na ní závislé?
Například na síť, blbě nastavené LVM nebo chybějící disk v poli. Ano, můžu si za to sám, ale teoretický systém, který při náhodném překlepu exploduje, by se ti asi taky nelíbil.
> Nemáte někde nadbytečné závislosti (aťto od výroby, či vlastním přičiněním)?
Mám, nepopírám, že to je chyba konfigurace (často defaultní distribuční - ano, blbé defaultní nastavení v distribucích je podle mě zodpovědné za část negativního vnímání systemd). Ale neskutečně mě vytáčí, že abych tu chybu mohl ladit/opravit, musím čekat na disk, co neexistuje. Předchozí init v Debianu typicky „nějak“ pokračoval dál nebo poměrně brzy selhal a vyhodil výzvu na login do emergency shellu. Nechápu, proč tam pořád ještě nepřidali, že když se zmáčkne ^C, tak to prohlásí, že aktuálně startující/čekající služba fakt nenastartuje.
-
ja. (neregistrovaný)
ja to vidim so systemd takto:
- napisat unit file pre systemd je ovela jednoduchsie, ako napisat init skript pre sysv. A to nehovorim este o init skripte, ktory by mal fungovat na viacerych distibuciach. Pre vyvojara/maintainera jednoznacne plus, admin ma aj sancu pochopit, co unit robi, bez toho, aby dva dni dekodoval bashove skripty,
- unit subory su by default v /usr/lib/systemd ako read-only, ako sucast balicka daneho software. Pokial je rovnaky v /etc, ktory vytvoril admin, ma prioritu (zapnute/vypnute su konceptualne rovnake ako v sysv, pomocou symlinku)
- unity maju koncept drop-inov. Teda ked chcem zmenit cast daneho unitu, napr. nejaku env premennu, nemusim ho editovat cely, ale iba zmenim tuto jednu vec v drop-ine. Napriklad;
[Service]
Environment=PGDATA=/srv/pgsql/9.6/data
/etc/systemd/system/postgresql-9.6.service.d/pgdata.conf (END)Medzitym software moze kludne updatovat svoj povodny unit file, nehrozi ziadne .rpmnew ani sa dpkg nevyzaduje, ze sa musim hned teraz rozhodnut, ktory konfig je ten spravny a pritom moje zmeny ostanu a budu fungovat.
- init system vie spolahlivo najst vsetky procesy, ktore patria do daneho unitu, aj double-forky. Ked admin zada "systemctl stop nejakyservis", tak vsetky procesy idu dole, bez vynimky a bez nahanania.
- vie si omanazovat servisy bez ohladu na to, akym sposobom su aktivovane. Z pohladu systemd je jedno, ci sa servis pusta pri boote, z timera, aktivaciou na sokete, dbusom, plug-and-play hardware, alebo nejakym este dalsim mechanizmom. Ma nadefinovane ako sa spusta, ako sa ukoncuje, ake ma zavislosti, apod, vsetko jednotne bez ohladu na spustaci mechanizmus. Tym padom napr. nemusi bezat bluetoothd ked pocitac ziadny bluetooth nema - ale spusti sa, ked pouzivatel napr. pripoji dongel.
- volitelnou sucastou je systemd-logind, co vyuzivaju hlavne desktopove prostredia (a to bol dovod, preco Gnome vyzaduje systemd alebo nieco kompatibilne): stava na predoslom bode a vie rozdelit vsetky userove procesy podla toho, z ktorej session boli spustene . Podla toho vie riadit jednotlive sessions, napr. vie ktoru moze uzamknut, lebo bola idle, ktoru uzamknut nemoze, lebo tam pouzivatel pusta video, ked ukoncuje session, vie ktore procesy moze ukoncit a ktore nie, vie ktora session patri na ktore sedatko apod. Procesy, ktore boli pustene z lokalnej konzoly/lokalneho GUI mozu moct mat ine moznosti, ako procesy pustene cez ssh (napr. ten lokalny dokaze namontovat usb disk, ten cez ssh nie).
- je mozne mat instancie sluzieb a systemd medzi nimi vie rozlisit. Napriklad mi bezi syncthing@ja, bezi pod mojim accountom, ale nie v mojej session, takze synchronizuje subory, aj ked nie som prihlaseny. Iny pouzivatel na tom istom pocitaci si moze spustit to iste a nepobiju sa.
- a este kopec dalsich veci, ktore ma momentalne nenapadaju, ale keby som bol naspat za pocitacom so sysv, tak by ma iritovali.
Pokial vam nieco nekonecne dlho nabieha alebo shutdownuje, tak systemd sa o tu informaciu rad podeli (default timeout je 90s). Pri starte pomocou systemd-analyze (blame, critical-chain), pri shutdowne po odmontovani diskov kludne aj vypisom na konzolu. Mne sa podarilo az prechodom na systemd v ubuntu 16.04 zistit na jednom nettope, preco shutdown trva tak dlho ako trva (lebo cakal na wifi kartu, ktora nebola ani zapnuta a nikdy nemala nakonfigurovany interface. Toto mi upstart nikdy nevedel povedat, na logy bolo uz neskoro a seriovu konzolu to nema). To usb-cko vam montuje nejaky iny servis, najskor nejaky desktop. Pozrite si aj timery; niektore distribucie pustaju fstrim z timera, ktory moze missnut ak je pocitac vypnuty. Pri starte to potom dohana.
-
null null (neregistrovaný)
@ja.
Jasně, ok, ale problém přece byl v tom, že to protlačili tu a tam o pár hlasů a pod dojmem vyřazení z hlavního proudu apod. ve stavu Alfa do stable releasů, dostalo se to na servery a začalo to požírat závislosti - proti lepšímu hlídání procesů přece nikdo nic neměl a nemá ... možná až na vyjímky ...
-
ja. (neregistrovaný)
Ja na druhu stranu Poetteringa dost chapem: do roboty mu chcu kecat ludia, co nikdy nic podobne nerobili, netusia co to obnasa, ale o to silnejsie maju nazory.
Dnes uz klasicke video: https://www.youtube.com/watch?v=ZTdUmlGxVo0
-
null null (neregistrovaný)
@SB
Nevídiš mezi servery a desktopy rozdíl? Tak kolikrát za den můžeš na třeba 10 min. vypnout server se službami a desktop, než někdo doletí a ty poletíš na kobereček? Takže rozdíl bychom měli ...
V celé takové debatě by byl základní problém ten, že existuje víc přístupů, resp. více skupin lidí podle přístupu, možná taky občas nějaké skupiny implementací vyžadujících jin přístup - no a systemd nenabízí variabilitu - buď máš, nebo táhni jinam - a to samozřejmě irituje určité skupiny, kterí by radši jednou co nejrobustněji všechno nastavili. Abys mě pochopil, mě je to jedno, naštěstí servery řešit nemusím, ale .... -
SB (neregistrovaný)
Takže jediný (kvantitativní) rozdíl je v době, kterou daný počítač může nejet, ale funkční potřebuju přece desktop i server.
Mimoto odstraněním Requires, Wants a BindsTo z units a nastavením Before a After lze dosáhnout chování sysvinitu. Akorát mi pořád není jasné, co tím získám. -
:> Takže jediný (kvantitativní) rozdíl je
To ale není pravda.
Jsou nová pravidla. Nevím, které zasedání vývojářú a uživtelů se to dohodlo, ale okamžitě si vybavím 2 typy případú, kdy jsem měl prostě konec práce, jediná možnost násilný reboot a následná oprava. Postaru to bylo hlášení o nefunčnkosti něčeho a zbytek jel dál. -
Začínám stahovat. Přitom očekávám, že bude mít naprosto stejný problém jako Debian 9 (Stretch) !
Očekávám, že nebude schopen startu na starých serverech Sun Fire X2100 (M2) a Sun Fire X2200 (M2) kvůli absenci ovladačů integrované grafiky.Starší, ale plně podporovaný Debian 8 (Jessie) funguje na starých Sun Fire X naprosto perfektně...
-
Devuan neznám, zatím jsem ho nikde neviděl. ISO Devianu 2.0 mám, ale instalovat ho budu nejdříve během víkendu... Na nic nedávám, pouze oznamuji !
Na svoje servery Sun Fire X2200 M2 nikdy Debian 9 (Stretch) instalovat nebudu, protože:
1. Debian 8 Jessie (LTS do roku 2020) šlape jako švýcarské hodinky.
2. Servery Sun Fire X2200 M2 jsou staré 10 let. Dnes perfektně šlapou, ale za týden mohou být mrtvé.
3. Hlavně: do června 2019 servery Sun Fire X2200 M2 buď prodám nebo vyhodím do popelnice.Čas je mrcha. Řešit problém, který dnes nemám (Jessie) a zítra nebude existovat (prodáno / popelnice) je poněkud zbytečné... :-)
-
ANO, problém je násobně větší...než jsem očekával !
Servery Sun Fire X2100 M2 a Sun Fire X2200 M2 mají stejnou integrovanou grafiku -- ASPEED AST2000.
Zásadní problém však je, že firma SUN použila stejnou int. grafiku AST2000 v obrovském počtu svých serverů !
Zatím mám tyto:-- Sun Blade X6250 , Sun Blade X6450
-- Sun Fire X4150 , Sun Fire X4250 a Sun Fire X4450
-- Sun Fire X4140 a Sun Fire X4240
-- Sun Fire X2270 a Sun Fire X4270
