Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: Martin 21. 03. 2017, 14:47:58
-
Tak jsem zmigroval nasich 6 debianu na systemD. Kupodivu to slo celkem hladce a vsechny pozadovane sluzby bezi jak pred tim. Nejdriv sem se s tim hral ve virtualu a tak jsem byl pripraven na par zmen v scriptech a cronu, ale jinak pohoda. Samozrejme images starych stroju mam pro jistotu odzalohovane.
Tak me trochu znepokojuje, ze to slo podezrele hladce. Otazka tedy: Mali jste nekdy problemy po uspesne migraci co sli na vrub systemD?
-
Neradujte se. To, ze to funguje, znamena pouze to, ze systemd potichu pripravuje zakernou strategii, ktera vam v nejnevhodnejsi chvili slozi server AND/OR znici data, nejpozdeji az vyjdou nejnoveji zaplaty na systemd.
-
Tak jsem zmigroval nasich 6 debianu na systemD. Kupodivu to slo celkem hladce a vsechny pozadovane sluzby bezi jak pred tim. Nejdriv sem se s tim hral ve virtualu a tak jsem byl pripraven na par zmen v scriptech a cronu, ale jinak pohoda. Samozrejme images starych stroju mam pro jistotu odzalohovane.
Tak me trochu znepokojuje, ze to slo podezrele hladce. Otazka tedy: Mali jste nekdy problemy po uspesne migraci co sli na vrub systemD?
Upřímnou soustrast. Slovy klasika: "Když vše funguje, jak má, je to prvním příznakem toho, že je něco špatně" :D
-
Neradujte se. To, ze to funguje, znamena pouze to, ze systemd potichu pripravuje zakernou strategii, ktera vam v nejnevhodnejsi chvili slozi server AND/OR znici data, nejpozdeji az vyjdou nejnoveji zaplaty na systemd.
Ne kazdej ma obe nohy leve and/or necte dokumentaci
-
No jasne, hateri sa ozvali a vedia o systemd velke H. A pritom sami raz zmigruju, ajurat budu mat blbe reci ze v 2017 to bolo nepouzitelne ale v 2019 je to uz fasa...
Dobre si spravil, ze si zmigroval. Dobuducna budes mat ovela jednoduchsi upgrade. SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma. A kodia ju spickovi a PLATENI programatori. Nie banda zhulenych githubistov. Staci pozriet zdrojaky. Kazdy sw moze mat chybu, ale u systemd by som sa bal najmenej. Vsetko krasne zdokumentovane, ochotna komunita, radost pouzivat ich api. Init style scriptarina je obsoletny balast porovnatelny s autoexec.bat a config.sys :D Ale to haterovi nevysvetlis, lebo ich to asi vzrusuje trolit nad pokrokom.
U nas sme za dva roky postupne nabehli na systemd na stovke masin, zeleznych aj virtualnych a ziaden problem co by stal za rec. Problemy boli zvycajne len pri upgrade. Po nastaveni vsetko slape, ziaden problem s logovanim, watchdogmi a podobne nezmysly co siria hateri. Blobu zdar ;)
-
@DareBack: A fotku Poetteringa s vlastnorucnim venovanim uz mas?
-
SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma.
No tak to teda potěš koště: 216 otevřených bugů v bugzille, 556 issues na githubu ;)
-
No jasne, hateri sa ozvali a vedia o systemd velke H. A pritom sami raz zmigruju, ajurat budu mat blbe reci ze v 2017 to bolo nepouzitelne ale v 2019 je to uz fasa...
Dobre si spravil, ze si zmigroval. Dobuducna budes mat ovela jednoduchsi upgrade. SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma. A kodia ju spickovi a PLATENI programatori. Nie banda zhulenych githubistov. Staci pozriet zdrojaky. Kazdy sw moze mat chybu, ale u systemd by som sa bal najmenej. Vsetko krasne zdokumentovane, ochotna komunita, radost pouzivat ich api. Init style scriptarina je obsoletny balast porovnatelny s autoexec.bat a config.sys :D Ale to haterovi nevysvetlis, lebo ich to asi vzrusuje trolit nad pokrokom.
U nas sme za dva roky postupne nabehli na systemd na stovke masin, zeleznych aj virtualnych a ziaden problem co by stal za rec. Problemy boli zvycajne len pri upgrade. Po nastaveni vsetko slape, ziaden problem s logovanim, watchdogmi a podobne nezmysly co siria hateri. Blobu zdar ;)
Tak teď jsi mě opravdu pobavil :)
-
SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma.
No tak to teda potěš koště: 216 otevřených bugů v bugzille, 556 issues na githubu ;)
https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=Importance&query_format=advanced
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&order=Importance&query_format=advanced
-
556 issues na githubu
Klasicka lziva propaganda linuxaku co zustali na stromech (systemd antagoniste). Z 557 issues jsou 300 bugy, 244 vyreseno, 66 se resi a i z tech je 16 cant reproduce nebo needs feedback. Takze nakonec mame 50ku bugu, co pri sw s 300tisic radkama kodu je velmi slusne cislo.
Tak co tam mate dal na tech stromech mili trolicci ?
-
Init style scriptarina je obsoletny balast porovnatelny s autoexec.bat a config.sys :D
V zasade souhlas.. Takovej firewalld me treba neoslovil, takze zustanu u iptables, ale jinak se mi dost veci zamlouva.
Nemyslim si ze by byl systemd tak unstable, kdyz na nej migruji i pomerne konzervativni distra jako je rhel.
Ono to boli, naucit se novou technologii, ale situace okolo systemd mi pripomina nekdy hate na ipv6.
-
556 issues na githubu
Klasicka lziva propaganda linuxaku co zustali na stromech (systemd antagoniste). Z 557 issues jsou 300 bugy, 244 vyreseno, 66 se resi a i z tech je 16 cant reproduce nebo needs feedback. Takze nakonec mame 50ku bugu, co pri sw s 300tisic radkama kodu je velmi slusne cislo.
Tak co tam mate dal na tech stromech mili trolicci ?
300K řádků?
Není to na init system trošku moc?
Jo pardon, systemD se chysta udělat modul kerneld a todle je jen příprava žejo.
Že vy chlapci tady trollite :D
Tim blobu zdar ste se prokecli.
-
Bylo: GNU/Linux
Bude: SystemD/KernelD
-
[...] 244 vyreseno [...]
no a kolik z nich bylo vyreseno stylem "don't fix - it's not a bug, it's a feature" ? ;)
a z tech par ostanich, kolik bylo vyreseno ze se predalo vyfuckovane reseni na 3rd autory?
tedy neco jako "Autore Byobu, zacali jsme pres sYsTeMd killovat Byobu, oprav to(=prispusob se te nasi picovine))" ;)
-
No tak to teda potěš koště: 216 otevřených bugů v bugzille, 556 issues na githubu ;)
Kolik byste tak myslel, že by mělo být nejvýše hlášených chyb, aby nemuselo koště těšit?
Kernel a GCC bugzilla odkazovaná výše končí s "This list is too long for Bugzilla's little mind" a řádově větším počtem chyb.
-
Bylo: GNU/Linux
Bude: SystemD/KernelD
Stallman rekl, ze systemd je ok, protoze je free se vsim vsudy. Ze se nekomu nelibi jak funguje je debata typu "vi je lepsi nez emacs".
Linus rekl, ze systemd je ok, protoze prinasi rad do init bordelu.
No ale mistni konzervativni uderka vi vsechno lepe ze? V zivote systemd neprovozovala ale prudi. Tak hybaj na stromy a nezaclanejte v konstruktivni debate tech co systemd znaji a pouzivaji.
-
300K řádků?
Není to na init system trošku moc?
Init systém je jenom jedna komponenta systemd.
Jo pardon, systemD se chysta udělat modul kerneld a todle je jen příprava žejo.
To je pozoruhodné, jak si odpůrci systemd neustále musejí něco vymýšlet. To systemd nemá žádné skutečné chyby?
Že vy chlapci tady trollite :D
Vy trollíte moc průhledně.
-
Bylo: GNU/Linux
Bude: SystemD/KernelD
GNU/Linux nikdy poradne nebylo, to byl jenom takovy dokola opakovany vykrik RS.
-
Bylo: GNU/Linux
Bude: SystemD/KernelD
Stallman rekl, ze systemd je ok, protoze je free se vsim vsudy. Ze se nekomu nelibi jak funguje je debata typu "vi je lepsi nez emacs".
Linus rekl, ze systemd je ok, protoze prinasi rad do init bordelu.
No ale mistni konzervativni uderka vi vsechno lepe ze? V zivote systemd neprovozovala ale prudi. Tak hybaj na stromy a nezaclanejte v konstruktivni debate tech co systemd znaji a pouzivaji.
Jeste nez skocim zpatky na strom: debata neni o tom, jestli je systemd free. A ze prinasi rad do init bordelu? Rad jako treba NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""? No potes to drive zminovane koste.
Kdyby byl systemd jenom init system tak mozna. Jenze komplexni moloch, ktery z nej delaji, musi a bude prinaset jenom problemy...
-
https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=Importance&query_format=advanced
Čistě z hlediska zdrojů: těch 216 je https://bugs.freedesktop.org/buglist.cgi?bug_status=__open__&product=systemd Definici "nejlépe otestovaného" sw nechám na libovůli každého soudruha.
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&order=Importance&query_format=advanced
To by byl relevantní argument, kdyby někdo prohlašoval gcc za "nejlépe otestovaný" sw. Nikoho takového jsem nepostřehl, takže to je trochu irelevantní :) O tom, že je gcc buggy asi není sporu, nebo jo?
556 issues na githubu
Klasicka lziva propaganda linuxaku co zustali na stromech (systemd antagoniste). [...]
Tak co tam mate dal na tech stromech mili trolicci ?
Tak nějak nevím. Počet issues na githubu s může každý ověřit. Nic víc jsem netvrdil. Krom toho (to už jenom na okraj, bez větší relevance): nepočítám se za "linuxáka". Proč bych to měl dělat?
-
slozi server AND/OR znici data
Tvrzení: Nechť s reprezentuje server, d reprezentuje data, a nechť AND (*) a OR (+) jsou běžně definované logické operace. Pak AND/OR je logický nesmysl a stačí OR.
Důkaz:
s | d | * | +
0 | 0 | 0 | 0
0 | 1 | 0 | 1
1 | 0 | 0 | 1
1 | 1 | 1 | 1cbd.
Závěr: Stačilo by místo fušérského "AND/OR" napsat pouze "nebo".
-
My mame SD na radove nekolika stech serveru a VM, prevazne RHEL 7 + workstations (Fedora,Ubuntu, Arch), osobne zadne zasadni problemy se SD nemame. Je pravda, ze SD nejake veci meni, ale to uz je dusledek toho, jaky neskutecny bordel to byl predtim, takze to vnimam spise jako velke plus. Stary sysvinit byl v dnesni dobe spis parodii na service manager nez neco, co se da pouzivat :) Nemluve o tom, ze je super, ze diky faktu, ze SD pouzivaji vsechny majoritni distribuce, tak se mnohem zjednodusuje napr. napsani vlastni service (staci udelat jednou).
Jinak firewalld me taky neoslovil, neprijde mi spatny, ale spise na serverech pouzivame tak komplexni custom pravidla, ze musime stejne pouzit iptables. Nicmene firewalld je zcela separatnim projektem, neni soucasti systemd.
-
Čistě z hlediska zdrojů: těch 216 je https://bugs.freedesktop.org/buglist.cgi?bug_status=__open__&product=systemd Definici "nejlépe otestovaného" sw nechám na libovůli každého soudruha.
Je to novy SW, ma obcas nejake bugy, to neni nic prekvapiveho. A pokud budeme srovnavat, jen samotny upstart ma v soucasne dobe 162 otevrenych bugu a to je to opravdu pouze a jenom init (navic jednodussi). A v te SD bugzille se resi cely SD, tzn. jsou tam bugy service managera, logind, udevu, networkd (nova komponenta) a vsech dalsich komponent SD. Navic to nejsou bugy v striktnim slova smyslu, jsou tam v tom ruzne pozadavky na doplneni dokumentace, rozsireni funkcionality, zmeny defaultu atd atd atd.
Takze fakt, ze to ma bugy, stejne jako kazdy jiny software me opravdu nejak nechava chladnym - dulezite je, ze hlavni veci funguji normalne a spolehlive, na nejake zasadni problemy jsme pri pouzivani nenarazili (pokud nepocitam svoji early adopci na Archu v roce 2011 - kdy byl SD skutecne work in progress)
-
Je to novy SW, ma obcas nejake bugy, to neni nic prekvapiveho.
Přesně tak - je to nový software a není nic překvapivého, že má bugy. Není to ani náhodou nejodladěnější sw na Linuxu (na tohle tvrzení jsem reagoval, nic víc).
dulezite je, ze hlavni veci funguji normalne a spolehlive, na nejake zasadni problemy jsme pri pouzivani nenarazili
Že jste na ně nenarazili neznamená, že na ně nenarazí někdo jiný za jiných podmínek. Např. by někdo mohl být překvapený, že se mu z ničehožnic nespustí cronjoby, protože posun času: https://github.com/systemd/systemd/issues/5595 nebo nefunguje logování, protože má /var bindmountnutý (https://bugs.freedesktop.org/show_bug.cgi?id=90268)
Systemd už celkem dobře dělá co dělat má, ale na překvapení by měl být člověk připravený, skvěle odladěné to zatím prostě není, bugy a regrese tam jsou (a není to nic divného).
-
Od kdy je bugzilla měřítkem kvality projektu?
1) Netestuju vůbec -> 0 bug reportů -> HQ software.
2) Přepísknu to s testováním a dám code review akademickýmu pedantovi, najednou tam mám 5k bugů typu "uzavírací závorka funkce v modulu XYZ na řádku 123 nemá být odsazená". Z toho reálných je třeba jenom 50.
3) Pokud bugzillu používám i na návrhy vylepšení od zákazníků a zákazníci navrhují blbosti, tak ty blbosti zdůvodním a zavřu. Přece není bug, když třeba u pluginu - dekodéru formátu X bude někdo požadovat funkcionalitu na dekódování formátu Y a vysvětlím mu, že to už řeší jiný plugin a stačí, aby si ho instaloval... Pokud to nedělám, stane se z toho blob, který umí všechno a nic dobře.
Ohledně LOC, taky metrika trochu mimo. Příklad, projekt v C, psaný dle doporučení uncle Boba (průměr 5 řádků v těle funkce, počítejme jeden blok (cyklus nebo if) uvnitř funkce, 1000 funkcí v 50 modulech, každá funkce má prototyp.
1) Jak je to formátováno? Pokud dám styl K&R (s otvírací složenou závorkou na konci řádku), mám 8 kLOC, pokud otvírací závorku odřádkuju, mám 10 kLOC (jeden řádek je hlavička, jeden řádek mezera mezi funkcema).
2) Počítají se do toho komentáře? Pokud jo, tak ejenom hlavička souboru, kde je datum, copyright a stručný popis modulu na 20 řádků, udělá z 10 kLOC 11 kLOC (+ 50*20LOC)
3) Jak jsou odděleny funkce? Někdo mezi ně dává grafický předěl za dvou řádků komentářových hvězdiček a mezi tím název funkce, prázdný řádek pod. Z 11 kLOC je najednou 15 kLOC
4) Jestli je tam dokumentace v Doxygenu, tak na funkci vychází třeba 8 LOC dokumentace funkce + 50 LOC na modul, tak je z 15 kLOC najednou 25,5 kLOC.
5) A to se furt bavíme o tom samým kódu 1:1, jenom s různým formátováním a dokumentací. 8 nebo 25,5, to je trojnásobek! Co když třeba to samý místo bloku if-else s odřádkováním závorek (8 LOC) udělám přiřazením v ternárním operátoru na 1 LOC?
Prostě zase debata o hnědým mazlavým. Nemáte tam jinou metriku? Třeba usability skóre?
-
"uzavírací závorka funkce v modulu XYZ na řádku 123 nemá být odsazená"
Ano, to je přesně typ bugů, které tam jsou.
OMG ::)
-
Že jste na ně nenarazili neznamená, že na ně nenarazí někdo jiný za jiných podmínek. Např. by někdo mohl být překvapený, že se mu z ničehožnic nespustí cronjoby, protože posun času: https://github.com/systemd/systemd/issues/5595 nebo nefunguje logování, protože má /var bindmountnutý (https://bugs.freedesktop.org/show_bug.cgi?id=90268)
Systemd už celkem dobře dělá co dělat má, ale na překvapení by měl být člověk připravený, skvěle odladěné to zatím prostě není, bugy a regrese tam jsou (a není to nic divného).
Mno, ja ti rozumim jak to myslis, da se rici, ze s tim souhlasim, ale asi se trochu lisime interpretaci toho, co je mature software :) Protoze pokud to vezmu takhle, co ze systemovych komponent je v linuxu "perfektne odladeno":
* Kernel - no tak to je skoda mluvit, naposledy jsem bisectoval pred 2 mesici, protoze to zaclo tuhnout pri resume, jako uzivatel se Skylake notebookem jsem si uzil svoje - https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&limit=0&order=priority%2Cbug_severity&query_format=advanced&rep_platform=x86-64 - 1115 otevrenych bugu jen na platforme AMD64
* Glibc - https://sourceware.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&product=glibc&query_format=specific - bugzilla ukonci zobrazovani po 500 bugs (celkem jich je 1009)
* Apache httpd - https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&product=Apache%20httpd-2&query_format=specific - taky 500+ bugs
* dokonce i hloupy legacy crond v Ubuntu ma 49 otevrenych bugu - https://bugs.launchpad.net/ubuntu/+source/cron/+bugs?field.status:list=NEW
* GNOME, KDE - no tak to je uplne skoda mluvit, to neni nutne ani hledat :-D
Takze kolem a kolem mi z toho ten systemd vychazi porad docela dobre, rozhodne ne jako neco, co vycniva :-)
Ale tezky spani z toho fakt nemam ani u jednoho - proste u komplexniho SW bugy jsou, byly a budou - SD je komplexni software a neni v tomhle vyjimka....
-
Od kdy je bugzilla měřítkem kvality projektu?
1) Netestuju vůbec -> 0 bug reportů -> HQ software.
2) Přepísknu to s testováním a dám code review akademickýmu pedantovi, najednou tam mám 5k bugů typu "uzavírací závorka funkce v modulu XYZ na řádku 123 nemá být odsazená". Z toho reálných je třeba jenom 50.
3) Pokud bugzillu používám i na návrhy vylepšení od zákazníků a zákazníci navrhují blbosti, tak ty blbosti zdůvodním a zavřu. Přece není bug, když třeba u pluginu - dekodéru formátu X bude někdo požadovat funkcionalitu na dekódování formátu Y a vysvětlím mu, že to už řeší jiný plugin a stačí, aby si ho instaloval... Pokud to nedělám, stane se z toho blob, který umí všechno a nic dobře.
Ohledně LOC, taky metrika trochu mimo. Příklad, projekt v C, psaný dle doporučení uncle Boba (průměr 5 řádků v těle funkce, počítejme jeden blok (cyklus nebo if) uvnitř funkce, 1000 funkcí v 50 modulech, každá funkce má prototyp.
1) Jak je to formátováno? Pokud dám styl K&R (s otvírací složenou závorkou na konci řádku), mám 8 kLOC, pokud otvírací závorku odřádkuju, mám 10 kLOC (jeden řádek je hlavička, jeden řádek mezera mezi funkcema).
2) Počítají se do toho komentáře? Pokud jo, tak ejenom hlavička souboru, kde je datum, copyright a stručný popis modulu na 20 řádků, udělá z 10 kLOC 11 kLOC (+ 50*20LOC)
3) Jak jsou odděleny funkce? Někdo mezi ně dává grafický předěl za dvou řádků komentářových hvězdiček a mezi tím název funkce, prázdný řádek pod. Z 11 kLOC je najednou 15 kLOC
4) Jestli je tam dokumentace v Doxygenu, tak na funkci vychází třeba 8 LOC dokumentace funkce + 50 LOC na modul, tak je z 15 kLOC najednou 25,5 kLOC.
5) A to se furt bavíme o tom samým kódu 1:1, jenom s různým formátováním a dokumentací. 8 nebo 25,5, to je trojnásobek! Co když třeba to samý místo bloku if-else s odřádkováním závorek (8 LOC) udělám přiřazením v ternárním operátoru na 1 LOC?
Prostě zase debata o hnědým mazlavým. Nemáte tam jinou metriku? Třeba usability skóre?
Samozrejme, mit bugzillu jako meritko pouzitelnosti SW je neskutecna hovadina.
-
Že jste na ně nenarazili neznamená, že na ně nenarazí někdo jiný za jiných podmínek. Např. by někdo mohl být překvapený, že se mu z ničehožnic nespustí cronjoby, protože posun času: https://github.com/systemd/systemd/issues/5595 nebo nefunguje logování, protože má /var bindmountnutý (https://bugs.freedesktop.org/show_bug.cgi?id=90268)
Hmm, posun času je snadné opravit a u druhé chyby si nejsem jistý, proč to pánové z Archu bez dalšího označili za upstream bug. Bindmountnutý /var normálně používám a na tenhle problém jsem nenarazil, takže by od lidí z Archu bylo užitečné, kdyby to odzkoušeli na své distribuci a nějak rozumně nahlásili. Jestliže systemd-journald nevytvoří /run/log/journal, pak bych čekal, že do /run/log zkrátka nelze zapsat a reportující by mohl (a měl) zjistit proč.
Comment 4 ("I have the same exact problem (with /var/log mounted as tmpfs to avoid unnecessary writes to the SSD disk). Apparently this issue has never been fixed.") pak nedává smysl, protože /var/log slouží k persistentnímu uložení, které lze vypnout v konfiguraci. Zvolené řešení vede k tomu, že je journal uložený jak v /run/log, tak ve /var/log a obé leží v RAM.
-
proste u komplexniho SW bugy jsou, byly a budou - SD je komplexni software a neni v tomhle vyjimka....
To je pravda, ale když zacoredumpuje apache, tak ho supervisor restartne a jede se dál močálem černým kolem bílých skal. Když zacoredumpuje systemd nebo systém nenaběhne po updatu, je to trochu větší legrace :)
Ale je fakt, že v dnešní době už je hodně serverů totálně zkomoditizovaných - když tam něco zahapruje, tak se smaže a spustí znovu někde jinde, takže chyby tohodle typu (pokud se neobjevují deterministicky všude) už taky tolik nevadí.
-
Hmm, posun času je snadné opravit
Nejde o to, jestli to je nebo není snadné opravit, ale o to, že je fajn, když se kritické části systému chovají předvídatelně a člověk se na ně může spolehnout. Když se mi dvakrát ročně nespustí nějaký důležitý cronjob a nevím proč, jenom vím, že před systemd to nedělalo, tak mi moc nepomůže že to "je snadné opravit" :)
-
Závěr: Stačilo by místo fušérského "AND/OR" napsat pouze "nebo".
Nestacilo. Lomitko tam znaci, ze plati jedno nebo druhe, Tedy ne "nebo", ale "bud, anebo". Tedy slozi server nebo znici data nebo udela oboji.
-
proste u komplexniho SW bugy jsou, byly a budou - SD je komplexni software a neni v tomhle vyjimka....
Aha. A je zadouci, aby init byl komplexni? Aby navic nebyl init, ale nabalil na sebe kdeco, vcetne Tetris a firewallu?
-
Bindmountnutý /var normálně používám a na tenhle problém jsem nenarazil
Což je jenom horší, protože pak tahle -bug- featura někde je a někde není. Neznámo proč. A to je horší než kdyby byla všude.
a reportující by mohl (a měl) zjistit proč.
A rovnou by mohl i poslat patch, ne?
Zvolené řešení vede k tomu, že je journal uložený jak v /run/log, tak ve /var/log a obé leží v RAM.
To je irelevantní.
-
To je pravda, ale když zacoredumpuje apache, tak ho supervisor restartne a jede se dál močálem černým kolem bílých skal. Když zacoredumpuje systemd nebo systém nenaběhne po updatu, je to trochu větší legrace :)
Ale je fakt, že v dnešní době už je hodně serverů totálně zkomoditizovaných - když tam něco zahapruje, tak se smaže a spustí znovu někde jinde, takže chyby tohodle typu (pokud se neobjevují deterministicky všude) už taky tolik nevadí.
No a kdyz je chyba v kernelu ci glibc (viz ty stovky bugu co jsem linkoval), tak je to jeste horsi, protoze ty narozdil od SD pouziva opravdu uplne vsechno... ale pointa je, jak moc problematicke je takovy SW pouzivat a jak casto se takove veci stavaji - coz nastesti neni pripad ani jedne z techto komponent (ve vetsine pripadu)...
A s tou kontejnerizaci mas samozrejme pravdu - kdo dneska nepouziva neco typu docker, nebo aspon puppet a podobne...
-
Systemd by si vazne zaslouzil nejake kompetentni kritiky.
-
Aha. A je zadouci, aby init byl komplexni? Aby navic nebyl init, ale nabalil na sebe kdeco, vcetne Tetris a firewallu?
SD neni (jen) init, ale komplexni zaklad userspace systemu, takze tento argument je irelevantni.
-
SD neni (jen) init, ale komplexni zaklad userspace systemu, takze tento argument je irelevantni.
To se pak bude SW portovat uplne levou zadni.
-
...
Což je jenom horší, protože pak tahle -bug- featura někde je a někde není. Neznámo proč. A to je horší než kdyby byla všude.
...
A rovnou by mohl i poslat patch, ne?
...
Odzadu: Tu irelevantní věc berte jako vysvětlení, proč to tak nedělat. Původní komentář nemá beztak s hlášenou chybou nic společného.
Patch by poslat mohl, ale v tomhle případě asi není co opravovat.
Souhlasím, je to strašné, ale kdyby se povedl tolik obávaný master plan, tedy sjednocení dister, nebylo by to nutné řešit. Ale teď vážně - všimněte si, že i diskuse tady je zmatená. Původní začíná větou "in some cases (i can't seem to narrow down which yet), systemd fails to create /run/log/journal...". Persistentní úložiště není k funkci třeba, jenže jemu to nefunguje vůbec a v kódu ten problém nebude:
https://github.com/systemd/systemd/blob/master/src/journal/journald-server.c#L360
Takže jestli Vás napadá něco jiného, než že do /run/log nejde zapsat, pak sem s tím.
-
Tak jsem ze zvedavosti kouknul jak ten SystemD vyvijeji a je na tom kus pravdy, ze se to dela profesionalne. Frci continuous inegration jak na githubu
https://semaphoreci.com/systemd/systemd
tak treba u fedory
https://koji.fedoraproject.org/koji/packageinfo?packageID=10477
Kod obsahuje unit testy, lokalne jsem to nespoustel ale tady sem nalezl 2 roky stary unit testing a uz tehdy meli temer 50% function coverage, co u takovyho macka je dost dobry. Dnes to bude mnohem lepsi.
https://www.freedesktop.org/software/systemd/coverage/index.html
-
...
jj treba nekolu, ten co placne to perla ... sice zcela vohovne a zcela vzdy 100% OT, ale coz.
To se pak bude SW portovat uplne levou zadni.
Hlavne je zabavny sledovat, jak dodavatele, kteri si daj na web podporu centosu/fedory/... vcetne verzi se sytemd, pak cumej jak z visne spadly na to, co to vlastne vsechno dela nebo nedela ... Sranda je, ze skoro vsichni skoncej u "tak tam dejte starsi verzi co tuhle hovadinu nema".
Alternativne to vypada tak, ze si nekam naladujou vlastni verze vsech knihoven ktery jejich appka pouziva vcetne ty appky, a spoustej to pekne kilometrovym bashovym scriptem, zcela mimo jakejkoli init. A logujou si samo taky sami ... pekne do vlastniho textaku. Presne stejne jako to ostatne delaj widloaplikace.
Jo a samo ti neopomenou do dokumentace na prvni stranku dat 20tkou a tucne, ze v zadnym pripade nemas ten system aktualizovat, ze pak nerucej za to, ze to jeste taky bude fungovat.
-
...
jj treba nekolu, ten co placne to perla ... sice zcela vohovne a zcela vzdy 100% OT, ale coz.
Ještě něco nám chceš povědět?
-
Mam systemd nasazeny na vsech debianech D8+. Zatim jsem narazil na dva problemy, ktere s puvodnim initem nebyly.
1] postgresql se nestartovalo po instalaci, pokud byl stroj restartovany. Duvod - mainteneri zapomeli systemd unitu nastavit jako aktivovanou. Casem to opravili.
2] pri pouziti openvswitch + drbd se rozbijely disky na masterovi, pokud byl dan restart. Duvod - openvswitch byl spousten jako soucast network unity, cili drbd nevedelo o zavislosti na nem. Openvswitch se z nejakeho duvodu vypinal drive nez drbd. Reseni - nastesti jiz kernel 4.x umi vice vlan na jednom sitovem interface, takze doslo k opusteni openvswitche.
Naopak jsem narazil na jednu ze zajimavych vyhod pri mountovani nfs. Pokud systemd mountuje na klientovi automaticky, tak pri pokusu o pristup do daneho adresare je pristup odmitnut, pokud selze spojeni s nfs serverem. Bezny non-systemd mount naopak zobrazil obsah prazdneho adresare, logicky tam jde pak zapisovat.
-
To se pak bude SW portovat uplne levou zadni.
To ale neni problem uplne autoru systemd, ze ne ?:-) Navic ze by s portovanim SW byly nejake extra problemy se rici neda - SW ktery skutecne striktne vyzaduje systemd zas tolik neni - vetsinou je to resene na nejake abstraktni vrstve, pripadne podminenym prekladem. A pripadne spousta SW vyuziva SD jen jako service manager a poskytuje max unitu, coz tez nicemu nevadi :) Hledas problem tam, kde absolutne neni.
A ano, samozrejme ze existuje SW jako GNOME, ktere vyzaduje logind ci neco podobneho,ale to uz je uplne jina story - prave proto,ze GNOME potrebuje neco jako logind, logind to presne resi - tudiz to pouzivaji... A neni to nijak jine nez jakekoliv jine platform specific veci v ruznem SW (a ze jich je)...
-
a reportující by mohl (a měl) zjistit proč.
A rovnou by mohl i poslat patch, ne?
Ano, idealne by mel. Je to open source, jsou zdrojaky, navic pouzivaji neci praci zcela zdarma - takze prispet obcas neco zpet (i treba kvalitni bugreport) je celkem fajn pristup. I kdyz samozrejme je to vec, ktera se deje v minimu pripadu.
A to prosim myslim zcela obecne - ne ve vztahu k systemd, ale k jakemukoliv open source software. A tohle konkretne je pripad spatneho bugreportu - /var mountemto urcite nebude, to je docela standardni vec co funguje. A obecne nevidim moc rozdil v tomhle a napr. bugreporty v kernelu (reportoval jsem jich mnoho, vetsina je dodnes neresena, takze jsem si par veci radsi spravil sam a poslal patche).
-
Závěr: Stačilo by místo fušérského "AND/OR" napsat pouze "nebo".
Nestacilo. Lomitko tam znaci, ze plati jedno nebo druhe, Tedy ne "nebo", ale "bud, anebo". Tedy slozi server nebo znici data nebo udela oboji.
Matematika (obzvláště logika) asi není tvoje silná stránka, co?
-
Mam systemd nasazeny na vsech debianech D8+. Zatim jsem narazil na dva problemy, ktere s puvodnim initem nebyly.
1] postgresql se nestartovalo po instalaci, pokud byl stroj restartovany. Duvod - mainteneri zapomeli systemd unitu nastavit jako aktivovanou. Casem to opravili.
2] pri pouziti openvswitch + drbd se rozbijely disky na masterovi, pokud byl dan restart. Duvod - openvswitch byl spousten jako soucast network unity, cili drbd nevedelo o zavislosti na nem. Openvswitch se z nejakeho duvodu vypinal drive nez drbd. Reseni - nastesti jiz kernel 4.x umi vice vlan na jednom sitovem interface, takze doslo k opusteni openvswitche.
Naopak jsem narazil na jednu ze zajimavych vyhod pri mountovani nfs. Pokud systemd mountuje na klientovi automaticky, tak pri pokusu o pristup do daneho adresare je pristup odmitnut, pokud selze spojeni s nfs serverem. Bezny non-systemd mount naopak zobrazil obsah prazdneho adresare, logicky tam jde pak zapisovat.
No, to nejsou uplne problemy systemd jako takoveho, ale spis toho, jak je systemd vyuzivan v konkretni distribuci unitama vytvorenymi autory distribuce, ne ?
Kdybych mel mluvit o problemech, co jsem mel ja se systemd, tak journald obcas spadnul pri urcite specificke konfiguraci (naposledy v roce 2011 tusim, od te doby jede spravne) a nektere DoS/bezpecnostni diry. Vetsinu problemu, co jsem zazil, byla spise dana distribuci (arch), na RHEL 7 jsme problemy nejak nezaznamenali.
-
Vetsinu problemu, co jsem zazil, byla spise dana distribuci (arch), na RHEL 7 jsme problemy nejak nezaznamenali.
IIRC má RHEL 7 nějakou relativně starou (čili jednodušší) a dost opatchovanou verzi systemd, ne? Arch pojede na o hodně jiném kódu. Takže opticky to s distribucí souvisí, ale jinak je to pořád systemd od těch stejných autorů. Ne?
-
Vetsinu problemu, co jsem zazil, byla spise dana distribuci (arch), na RHEL 7 jsme problemy nejak nezaznamenali.
IIRC má RHEL 7 nějakou relativně starou (čili jednodušší) a dost opatchovanou verzi systemd, ne? Arch pojede na o hodně jiném kódu. Takže opticky to s distribucí souvisí, ale jinak je to pořád systemd od těch stejných autorů. Ne?
Mluvil jsem o necem uplne jinem:
1. Problemy na Archu jako very early adopteru (rok 2011) - tzn. uz nerelevantni
2. Faktu, ze nektere problemy se SD nejsou zpusobeny samotnym SD, ale tim, jak je integrovany do distribuce (napr. jak jsou vytvoreny jednotlive unity atd.)
-
Mluvil jsem o necem uplne jinem:
1. Problemy na Archu jako very early adopteru (rok 2011) - tzn. uz nerelevantni
2. Faktu, ze nektere problemy se SD nejsou zpusobeny samotnym SD, ale tim, jak je integrovany do distribuce (napr. jak jsou vytvoreny jednotlive unity atd.)
Řeknu to jinak: na RHEL jsi problémy nezaznamenal, protože je před vypuštěním vychytal (AFAIK) a protože ranné fáze systemd byly míň komplexní.
-
Řeknu to jinak: na RHEL jsi problémy nezaznamenal, protože je před vypuštěním vychytal (AFAIK) a protože ranné fáze systemd byly míň komplexní.
Presne naopak, RedHat je hlavnim contributorem systemD. Hraji se stale s poslednimi verzema na svych fedorach a z casu na cas updatnou RHEL. Ostatne ten link tu uz byl https://koji.fedoraproject.org/koji/packageinfo?packageID=10477 vidite, ze builduji z poslednich release tagu na githubu.
-
Reseni - nastesti jiz kernel 4.x umi vice vlan na jednom sitovem interface
Měl jsem za to, že je podpora vlan poněkud starší.
-
Navic ze by s portovanim SW byly nejake extra problemy se rici neda - SW ktery skutecne striktne vyzaduje systemd zas tolik neni
Zdá se tedy, že zatím ještě není systemd tak úspěšný, jak by si někteří přáli. ;)
-
Je to open source, jsou zdrojaky, navic pouzivaji neci praci zcela zdarma
A o tom přesně je open source, že můžu používat a šířit kód mnoha různých autorů a mám záruku, že mi ti lidé můžou vlézt na záda, když dojde na nejhorší. Osobně bych do systemd moc nepřispíval, nemyslím si, že je to projekt, kde by se mohl člověk nějak zvlášť realizovat bez podkuřování.
-
Řeknu to jinak: na RHEL jsi problémy nezaznamenal, protože je před vypuštěním vychytal (AFAIK) a protože ranné fáze systemd byly míň komplexní.
Hezky pokus. Proc je tedy nezaznamenavam na ArchLinuxu, Fedore a dalsich ?:) Je opravdu tak tezke pochopit, ze jsem mluvil o stavu v roce 2011, kdy SD byl sotva rok stary a Arch byl jednim z very early adopteru?:-)
-
Zdá se tedy, že zatím ještě není systemd tak úspěšný, jak by si někteří přáli. ;)
Jak souvisi uspesnost SD s tim, zda na nem zavisi SW? Naopak, ze se SDonly API nepouziva zbytecne je plus :)
A o tom přesně je open source, že můžu používat a šířit kód mnoha různých autorů a mám záruku, že mi ti lidé můžou vlézt na záda, když dojde na nejhorší. Osobně bych do systemd moc nepřispíval, nemyslím si, že je to projekt, kde by se mohl člověk nějak zvlášť realizovat bez podkuřování.
Prispivani do open source projektu je forma seberealizace ?:-D No co se clovek nedozvi. Ano, urcite jsou lide, kteri to tak maji, ale to neni nic ,co by prispivani do OS projektu melo definovat - jednoduse prispeji do projektu, ktery pouzivam, aby byl lepsi/vyhovoval vice memu use case a nemusim si psat vse sam, jednoduche. A u firem, ktere maji na OS postaveny byznys, je to zase o trochu neco jineho...
-
Osobně bych do systemd moc nepřispíval, nemyslím si, že je to projekt, kde by se mohl člověk nějak zvlášť realizovat bez podkuřování.
Jen blbni, dotaz na lubrikant už mi tady smazali... ;D
-
DRY - nac bych pouzival alternativu neceho na co uz je funkncni modul v systemd ? Je to stejne jako s kernelem, kdyz to api tam je a funguje, tak nac neco jinyho ? Kdyz muj kod zavisi jen od toho modulu tak vim, ze to pojede na vsech systemd distrech bez komplikaci. Takze se nedivim Gnome, ze sli touhle cestou. Proste rozbujnely svet dister se razem zmenil na standartni distra se systemd a obsolete distra s buhvi cim.
-
Reseni - nastesti jiz kernel 4.x umi vice vlan na jednom sitovem interface
Měl jsem za to, že je podpora vlan poněkud starší.
To sice ano, ale vlan-aware bridge podpora ne.
-
Presne naopak, RedHat je hlavnim contributorem systemD. Hraji se stale s poslednimi verzema na svych fedorach a z casu na cas updatnou RHEL. Ostatne ten link tu uz byl https://koji.fedoraproject.org/koji/packageinfo?packageID=10477 vidite, ze builduji z poslednich release tagu na githubu.
Na CentOSu vidím verzi 219: http://mirror.centos.org/centos/7/updates/x86_64/Packages/
-
Na CentOSu vidím verzi 219: http://mirror.centos.org/centos/7/updates/x86_64/Packages/
Centos = RHEL = LTS. Verze jsou zmrazeny od data vydani po dobu podpory a backportuji se jenom bugfixy (momentalne aktualni tusim 30ta komiplace). Kdyz chces novoty tak mas Fedoru nebo kompiluj src.rpm sam.
-
Centos = RHEL = LTS. Verze jsou zmrazeny od data vydani po dobu podpory a backportuji se jenom bugfixy (momentalne aktualni tusim 30ta komiplace). Kdyz chces novoty tak mas Fedoru nebo kompiluj src.rpm sam.
No dyť. Řeč byla o RHELu, ne o Fedoře.
-
Závěr: Stačilo by místo fušérského "AND/OR" napsat pouze "nebo".
Nestacilo. Lomitko tam znaci, ze plati jedno nebo druhe, Tedy ne "nebo", ale "bud, anebo". Tedy slozi server nebo znici data nebo udela oboji.
Matematika (obzvláště logika) asi není tvoje silná stránka, co?
Sice jste s kolegou asi silni v logickych operacich, nicmene and/or se konkretne v anglictine pouziva bezne a to ne proto, ze je mluvci ignorant, ale prave proto, ze nebo se casto v prirozenem jazyce uziva ve smyslu "exclusive or" a on chce zduraznit, ze ma na mysli i splneni obou moznosti najednou.
-
Neni treba jit daleko, taky doma mame "a", "nebo" anebo "anebo" :D
Viz jazykovy koutek http://www.rozhlas.cz/plzen/jazykovykoutek/_zprava/322944
-
Centos = RHEL = LTS. Verze jsou zmrazeny od data vydani po dobu podpory a backportuji se jenom bugfixy (momentalne aktualni tusim 30ta komiplace). Kdyz chces novoty tak mas Fedoru nebo kompiluj src.rpm sam.
No dyť. Řeč byla o RHELu, ne o Fedoře.
No ale to neznamena, ze "vydejte sedmicku az bude systemd stabilni" ale proste "dnes mame deadline posledni bety RHEL7, tak posledni otestovanou kompilaci systemd zmrazte a pujde ven". V dobe vydani RHEL7 byla z relativne poslednich release tagu githubu. To, ze ma dnes dva roky je vec LTS, ne toho ze novejsi jsou spatne :-) Stejny je to v RHEL treba u kernelu, apache atd.
-
Matematika (obzvláště logika) asi není tvoje silná stránka, co?
Zkus neaplikovat matematickou logiku na hovorovou rec. Mohlo by se ti stat, ze se nedomluvis v pekarne, az budes chtit koupit pet housek.
-
To se pak bude SW portovat uplne levou zadni.
To ale neni problem uplne autoru systemd, ze ne ?:-)
Navic ze by s portovanim SW byly nejake extra problemy se rici neda - SW ktery skutecne striktne vyzaduje systemd zas tolik neni....
To jejich problem mozna neni, ale je to problem tech, co to portuji. System si hraje na vic, nez jen init a dela to tak blbe, ze cpe do systemu vselijake logind namisto existujicich zalezitosti a podnecuje vznik zavilosti na sobe samem. Zatim je to Gnome, otazka je, co to bude zitra. Abychom se nahodou nedockali toho, ze na systemd zacnou zaviset i aplikace, coz by bylo uplne v prdeli. Autori systemd jaksi hledi vpred ku svetlym zitrku, kdy systemd bude delat temer vse a zaviset na nem bude zbytek, ale jaksi by si meli uvedomit, ze nejsou v systemu sami, ale ze v nem bezi i programy nekoho jineho.
Abychom se jednou nedockali toho, ze na systemd bude zaviset i ls, pokud nebudeme muset rovnou psat systemd-ls.
-
Neni treba jit daleko, taky doma mame "a", "nebo" anebo "anebo" :D
Viz jazykovy koutek http://www.rozhlas.cz/plzen/jazykovykoutek/_zprava/322944
coz ale je irelevantni vzhledem k formulaci "nejnevhodnejsi chvili slozi server AND/OR znici data"
protoze to znamena ze muze nastat samostatne jedna situaci, druha situace, nebo obe situace dohromady, naproti tomu to tve "anebo" obe situace dohromady vylucuju, viz i na odkazu kterej si postoval:
V případech, kde uvádíme různé alternativy řešení, které nemohou nastat zároveň, tedy dojde vždy jen na jednu z nich, můžeme použít spojky nebo a anebo
takze jsi to bud necetl a/nebo ses blbej ;)
-
Panove, opuste tu jazykovedu, drzte na mysli cil teto diskuse. A to je nadavani na systemd. ;-)
-
Tak jsem zmigroval nasich 6 debianu na systemD ...
... tos nemel delat ...
-
Abychom se nahodou nedockali toho, ze na systemd zacnou zaviset i aplikace, coz by bylo uplne v prdeli. Autori systemd jaksi hledi vpred ku svetlym zitrku, kdy systemd bude delat temer vse a zaviset na nem bude zbytek, ale jaksi by si meli uvedomit, ze nejsou v systemu sami, ale ze v nem bezi i programy nekoho jineho.
Aleluja ze jsi na to prisel. Vzdyt o to nam uz snad desetileti jde. Vnest do bordelu a chaosu desitek dister nejaky rad. Jako programator dlim slava Potteringu na vysosti, ze rozdelil svet linux na dva tabory. Normalni se systemd kde se muzu spolehnout na jeho API stejne jako na API kernelu a obstarozni svet bez systemd kde se nemuzete spolehnout na nic. Doby kdy zdrojak z githubu je nutno prehnat 10ti debian patches aby to vubec slo nahodit do systemu budou jiz brzo za nama. Protoze o tuto "radost" nas nastesti odbremeni maintaneri systemd v distru.
Jestli ste nazoru, ze svet linuxu je v poradku tak to teda neni. Proto vznikaji blbosti typu flatpack protoze autor SW chce aby to bezelo na kazdem linuxu ne na vuli/zvuli maintaineru balicku kde-ktereho distra a jeho nazoru ktere liby v jake verzi jsou ty svate. I takove prkotiny systemd vyresi.
Zakladni kamen dister je porad kernel. Pak uz dneska kamen druhy - systemd. Neni co resit, budoucnost je jasna. Muzete kritizovat nejake detske bolistky nasazeni v minulosti ale to je asi vse. I ty jednou zmigrujes 8)
Abychom se jednou nedockali toho, ze na systemd bude zaviset i ls, pokud nebudeme muset rovnou psat systemd-ls.
Porad si tam muzes nainstalovat nejake starozitne gnu utils a prefixnout je g-ckem. A budes mit gls no. Appliste to maju uz leta, ze brew alternativy jsou prefixovany g-ckem a nevzrusuje je to :)
-
Aha. A je zadouci, aby init byl komplexni? Aby navic nebyl init, ale nabalil na sebe kdeco, vcetne Tetris a firewallu?
SD neni (jen) init, ale komplexni zaklad userspace systemu, takze tento argument je irelevantni.
To není odpověď na otázku.
Otázka zněla, zda je to žádoucí. Co je SD zač všichni ví (ať už v dobrém, či zlém).
-
Aha. A je zadouci, aby init byl komplexni? Aby navic nebyl init, ale nabalil na sebe kdeco, vcetne Tetris a firewallu?
SD neni (jen) init, ale komplexni zaklad userspace systemu, takze tento argument je irelevantni.
To není odpověď na otázku.
Otázka zněla, zda je to žádoucí. Co je SD zač všichni ví (ať už v dobrém, či zlém).
Je to vysvětlení, proč je ta otázka špatně. Systemd init není komplexní. Ve skutečnosti je jednodušší, než SysVinit. Na rozdíl od něj totiž dělá právě jenom to, co musí dělat proces s PID 1.
-
Jestli ste nazoru, ze svet linuxu je v poradku tak to teda neni. Proto vznikaji blbosti typu flatpack protoze autor SW chce aby to bezelo na kazdem linuxu ne na vuli/zvuli maintaineru balicku kde-ktereho distra a jeho nazoru ktere liby v jake verzi jsou ty svate. I takove prkotiny systemd vyresi.
Jak by mohl systemd vyřešit, že v distru A je knihovna verze X a v distru B verze Y?
-
No ale to neznamena, ze "vydejte sedmicku az bude systemd stabilni" ale proste "dnes mame deadline posledni bety RHEL7, tak posledni otestovanou kompilaci systemd zmrazte a pujde ven". V dobe vydani RHEL7 byla z relativne poslednich release tagu githubu. To, ze ma dnes dva roky je vec LTS, ne toho ze novejsi jsou spatne :-) Stejny je to v RHEL treba u kernelu, apache atd.
Jasný. Tak bys mohl přestat vyvracet něco, co jsem netvrdil, a koukněme se na to prakticky:
$ mkdir /tmp/nejotestovanejsi-sw-na-linuxu
$ cd /tmp/nejotestovanejsi-sw-na-linuxu
$ wget http://vault.centos.org/7.0.1406/os/Source/SPackages/systemd-208-11.el7.src.rpm
$ rpm2cpio systemd-208-11.el7.src.rpm | cpio -idmv
$ ls -l *.patch | wc -l
232
$ mkdir /tmp/uplne-stejny-pripad
$ cd /tmp/uplne-stejny-pripad
$ wget http://vault.centos.org/7.0.1406/os/Source/SPackages/kernel-3.10.0-123.el7.src.rpm
$ rpm2cpio kernel-3.10.0-123.el7.src.rpm | cpio -idmv
$ ls -l *.patch | wc -l
3
...a teď si prosím znovu přečti, co jsem říkal.
EDIT: sorry, nekorektní srovnání - kernel je už opatchovaný uvnitř. No nic, každopádně 232 patchů systemd je i tak výmluvných.
-
Matematika (obzvláště logika) asi není tvoje silná stránka, co?
Zkus neaplikovat matematickou logiku na hovorovou rec. Mohlo by se ti stat, ze se nedomluvis v pekarne, az budes chtit koupit pet housek.
Jestli ti AND/OR přijde jako hovorová řeč, tak... Jako upper case, anglická slova... První, na co si člověk vzpomene, jsou právě ty logické operace. ;) Pokud je teda aspoň lehce IT-pozitivní.
Jinak psal to správně, stačilo by napsat prosté "nebo" (bez čárky), které dovoluje i "obojí naráz". :)
-
Jasný. Tak bys mohl přestat vyvracet něco, co jsem netvrdil, a koukněme se na to prakticky:
$ mkdir /tmp/nejotestovanejsi-sw-na-linuxu
$ cd /tmp/nejotestovanejsi-sw-na-linuxu
$ wget http://vault.centos.org/7.0.1406/os/Source/SPackages/systemd-208-11.el7.src.rpm
$ rpm2cpio systemd-208-11.el7.src.rpm | cpio -idmv
$ ls -l *.patch | wc -l
232
O cem presne tohle vypovida krom toho, ze RH v svych LTS verzich zajistuje backportovani ruznych zmen a pripadne si nektere veci pro konkretni distribuci customizuje ? SD 208 pochazi z roku 2013, toto je build z roku 2014, svete div se, ze jsou tam nejake patche. On by tvuj argument mel nejakou vahu, kdyby SD i RHEL nevyvijela jedna firma - RH. Takhle je to maximalne diskuse o internich vyvojovych procesech v ramci RH, coz je dost irelevantni :) To je jeste uchylnejsi srovnani nez se bavit o poctu issues v bugzille...
A heavy patching se deje u kazde systemove komponenty v RH - staci se podivat na miliardu patchu v kernelu, glibc a dalsich systemovych komponentach :)
A pokud uz se chceme bavit o pouzitelnosti SD bez patchu - https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/systemd - ArchLinux, ktery pouzivam denne, SD funguje spolehlive (coz neznamena, ze nema zadne bugy ale samozrejme) a patche nema zadne :)
-
O cem presne tohle vypovida
https://forum.root.cz/index.php?topic=15084.msg204848#msg204848
-
Jak by mohl systemd vyřešit, že v distru A je knihovna verze X a v distru B verze Y?
Hehe, asi mal na mysli, ze na so kniznice sa mozes vybodnut tiez. Vsetky API a sluzby budu uz v systemd moduloch :-) To inac je celkom sexi napad a ako programator by som to teda bral. Ale celkom relane to nebude, predsa len ten GNU virus v podobe glibc je zadratovany uplne vsade, taktiez xwindows/wayland bude mat kopu kniznic, ktore si ako systemd modul viem predstavit dost tazko. No ved uvidime.
-
$ ls -l *.patch | wc -l
232
Backporty Mirku, backporty. Neupgradujeme na novejsi verzi z patchem ale preneseme patch do nasi verze. U kernelu jich bude radove vice, mozna jenom nejsou v patch souborech.
-
Backporty Mirku, backporty. Neupgradujeme na novejsi verzi z patchem ale preneseme patch do nasi verze.
No a ty patche jsou bugfixy, nebo snad ne? Ještě jednou připomínám: byla srovnávána stabilita vanilla systemd v Archu s heavily-patched verzí v RHELu. S tvrzením "Vetsinu problemu, co jsem zazil, byla spise dana distribuci (arch), na RHEL 7 jsme problemy nejak nezaznamenali." https://forum.root.cz/index.php?topic=15084.msg204834#msg204834
Já jsem měl hypotézu, že ty problémy nejsou dané distribucí (že by něco dělala špatně), ale tím, že RHEL bugy odstraňuje, narozdíl od Archu, který prostě přejde na novější verzi (která má zas nové bugy ;) ).
U kernelu jich bude radove vice, mozna jenom nejsou v patch souborech.
Jasně, však tuhle chybu v úvaze jsem opravil hnedka jak jsem ten příspěvek odeslal :)
-
Backporty Mirku, backporty. Neupgradujeme na novejsi verzi z patchem ale preneseme patch do nasi verze.
No a ty patche jsou bugfixy, nebo snad ne? Ještě jednou připomínám: byla srovnávána stabilita vanilla systemd v Archu s heavily-patched verzí v RHELu. S tvrzením "Vetsinu problemu, co jsem zazil, byla spise dana distribuci (arch), na RHEL 7 jsme problemy nejak nezaznamenali." https://forum.root.cz/index.php?topic=15084.msg204834#msg204834
Já jsem měl hypotézu, že ty problémy nejsou dané distribucí (že by něco dělala špatně), ale tím, že RHEL bugy odstraňuje, narozdíl od Archu, který prostě přejde na novější verzi (která má zas nové bugy ;) ).
U kernelu jich bude radove vice, mozna jenom nejsou v patch souborech.
Jasně, však tuhle chybu v úvaze jsem opravil hnedka jak jsem ten příspěvek odeslal :)
Ne. Kdyby sis poradne precetl,co jsem psal, tak jsem mluvil o problemech v roce 2011 se sd a early adoption v archi. A konstatoval jsem ze,ze vetsina problemu byla dana pouzitim systemd v distribucich (tzn. jejich unity,konfigurace a dalsi), nikoliv samotnym systemd. Uz ti to tu pisu po nekolikate.
Takze resis problem,ktery neni a citujes ho na zaklade neceho,co jsi nepochopil...
-
Takze resis problem,ktery neni a citujes ho na zaklade neceho,co jsi nepochopil...
Ale pochopil, neboj. Jenom tady nejses sam a diskuse ma vic vlaken a vic souvislosti.
Hlavni pointa je ta, ze ja si "nejstabilnejsi software" predstavuju tak, ze si stahnu vanilla release, rozbalim, prelozim a slape to jako hodinky. Ne ze budu muset slozite zjistovat, u ktere verze se objevila jaka regrese nebo bug a jaky patch ho opravuje.
Dám ti konkrétní příklad: teď momentálně pracuju na embedded linuxu s jedním konkrétním účelem - tj. od initu potřebuju jenom to, aby nebyl příliš velký a byl absolutní spoleh, že skutečně spustí služby, které jsou na tom systému to, o co jde. Je mi fakt ukradený, jestli služby spustí izolovaně tím nebo oním namespacem nebo killuje procesy spuštěné interaktivně uživatelem, hlavně potřebuju, aby se choval předvídatelně, za všech možných corner cases (SD karta na hviličku zahapruje, síť se zakucká, ...). Můžu se na systemd opravdu spolehnout? Ve vanilla verzi? Jaký release? Je riziko s ním spojené predikovatelné? Jakmile se do světa vypustí tisíce zařízení s tímhle systémem, tak už se jakýkoliv krávoviny initu budou fakt zatraceně blbě řešit. Stojí mi to za to? Lidem z OpenWRT ne: https://wiki.openwrt.org/doc/techref/procd
-
Hlavni pointa je ta, ze ja si "nejstabilnejsi software" predstavuju tak, ze si stahnu vanilla release, rozbalim, prelozim a slape to jako hodinky. Ne ze budu muset slozite zjistovat, u ktere verze se objevila jaka regrese nebo bug a jaky patch ho opravuje.
Zrejme nebezis vanilla na kolene kompilovane Mirekux distro ne? Ale pouzivas nejake existujici jako zaklad. Jestli to distro systemd obsahuje tak neni co resit, bude stabilni, maintaner to udela lepe nez ty.
-
Zrejme nebezis vanilla na kolene kompilovane Mirekux distro ne?
To prave jeste neni rozhodnuto. Postavit na-kost-orezany a super-otestovany vlastni system muze byt mensi blbost nez si mozna myslis.
Ale pouzivas nejake existujici jako zaklad. Jestli to distro systemd obsahuje tak neni co resit, bude stabilni, maintaner to udela lepe nez ty.
To prave neni tak jisty. Distributor muze do distra dat temer co chce - pro desktopove a serverove nasazeni se stane co? Kdyz to nekomu zahapruje, podiva se do logu, posle bugreport, panove v RedHatu pridaji dvestetricatytreti patch, vydaji update, nove instalace to budou mit hned od zacatku a bug uz nebude, vsichni jsou happy. U embedded zarizeni mas o dost slozitejsi situaci - kdyz to nekomu zahapruje, tak ti zadny bugreport neposle, jenom ti to omlati o hlavu, ze to umrelo, nedozvis se typicky nic. A pokud se to dozvedet chces, stoji to straslivy usili. Tohle riziko si proste musis zvazit o dost pecliveji, nez kdyz mas desitky a stovky serveru nekde na AWSku, kde je ti vicemene putna, jestli semtam nektery z nich umre neznamo proc...
-
https://wiki.openwrt.org/doc/techref/procd
Zrovna, když jsem si říkal, že to nemá cenu dál číst, protože se řeší ty samé kraviny furt dokola se objeví tohle. Děkuji, to stojí za vyzkoušení :-) Akorát by pánové mohli zlepšit marketing, protože sekce "Why do we want procd?" je prázdná a je potřeba se podívat do kódu - a není to vůbec nepříjemný pohled.
(Na embedded používám též systemd (v232, ~5k zařízení ve světě) a kdyby bylo se vším tak málo problémů jako s tímhle initem, tak si budu gratulovat)
-
No ja jen z vlastni skusenosti, nekdy pred 10ti lety jsem se nudil a vlastni distro zbastlil. Bez Xwin samozrejme ale napriklad sem se snazil drzet LSB. Vzhledem na to, ze na pokus jsem pouzil nejake stare PentiumII s Intel sitovkou, bez wifi a zvukovky tak to ani moc nebolelo. Clovek se pri tom hodne o unixu nauci ale vysledek byl, ze podruhe bych to toho uz nesel a radeji pouzil gentoo.
No a k tvemu zadani, systemd neni jen o inicializaci. Kdyz jinou functionalitu kterou systemd ma nepotrebujes tak ti je tam asi zbytecne. Ale do budoucna kdovi jestli by ti nejaky jeho modul neprisel vhod?
-
Zrovna, když jsem si říkal, že to nemá cenu dál číst, protože se řeší ty samé kraviny furt dokola se objeví tohle. Děkuji, to stojí za vyzkoušení :-)
Jo, urcite stoji. OpenWRT se mi vubec libi z vic duvodu. Treba i ten ubus neni k zahozeni.
Akorát by pánové mohli zlepšit marketing, protože sekce "Why do we want procd?" je prázdná a je potřeba se podívat do kódu - a není to vůbec nepříjemný pohled.
Jo, ta stranka stoji za prd. Zajimave info se da sem tam zjistit z ruznych diskusi...
(Na embedded používám též systemd (v232, ~5k zařízení ve světě) a kdyby bylo se vším tak málo problémů jako s tímhle initem, tak si budu gratulovat)
To je cenna informace, dik. Fakt z toho mam trochu tezkou hlavu, jestli se na systemd spolehnout nebo ne. Pouzivas rucne zbuildenou vanillu v tehle verzi nebo je to nejaka opatchovana verze z nejakeho distra? (A kdyz uz jsme u toho, dovolim si velky OT: jaky build system? Buildroot, Yocto, ditribution-specific nebo uplne homemade?)
-
To je cenna informace, dik. Fakt z toho mam trochu tezkou hlavu, jestli se na systemd spolehnout nebo ne. Pouzivas rucne zbuildenou vanillu v tehle verzi nebo je to nejaka opatchovana verze z nejakeho distra? (A kdyz uz jsme u toho, dovolim si velky OT: jaky build system? Buildroot, Yocto, ditribution-specific nebo uplne homemade?)
Vanilla a tohle: https://git.pengutronix.de/cgit/ptxdist/tree/patches/systemd-233 to jsou převážně cross-compile fixes.
Z toho je poznat i odpověď na druhou část otázky: http://www.pengutronix.de/software/ptxdist/index_en.html
K OT: Běží tam dokonce i ModemManager a NetworkManager, custom aplikace používají věci z libsystemd, komunikují přes DBUS (pomocí API libsystemd), ale pokud bych dostal z procd podobnou fukcionalitu (zatím to vypadá na dost snahy, která by se dala vyvážit použitím levnějšího hw, takže by zbylo na vývoj), pak se mi to zdá jako dobrá alternativa.
(A ještě větší OT: z embedded pohledu je největší problém jádro a teď nemyslím, že stejná konfigurace, pro ten stejný hardware nakyne 4x, takže co je platné, že použiju lehčí userspace... http://elinux.org/Linux_Tiny je mrtvý projekt)
-
Aha. A je zadouci, aby init byl komplexni? Aby navic nebyl init, ale nabalil na sebe kdeco, vcetne Tetris a firewallu?
SD neni (jen) init, ale komplexni zaklad userspace systemu, takze tento argument je irelevantni.
To není odpověď na otázku.
Otázka zněla, zda je to žádoucí. Co je SD zač všichni ví (ať už v dobrém, či zlém).
Je to vysvětlení, proč je ta otázka špatně. Systemd init není komplexní. Ve skutečnosti je jednodušší, než SysVinit. Na rozdíl od něj totiž dělá právě jenom to, co musí dělat proces s PID 1.
Takže když se nám otázka nehodí, tak ji označíme za špatnou? OK, tomu rozumím.
Jinak to vysvětlení nevysvětluje co tvrdíš. A nikdo se nebaví o SystemD initu, ale o SystemD, jehož je SystemD init nedílnou součástí, což je jaksi jádro problému, viz původní dotaz.
Takže znova, je žádoucí, aby byl SystemD tak komplexní, a aby SystemD init na sebe povinně nabalil i ten tetris?
-
Takže znova, je žádoucí, aby byl SystemD tak komplexní, a aby SystemD init na sebe povinně nabalil i ten tetris?
Pred 2ma roky jste narikali, ze tam tetris neni. A ted placete, ze tam je?
https://www.root.cz/zpravicky/do-systemd-je-integrovana-nahrada-za-su/vlakno/1/
-
Takže znova, je žádoucí, aby byl SystemD tak komplexní, a aby SystemD init na sebe povinně nabalil i ten tetris?
Ne, není žádoucí, aby měl v sobě tetris. Osobně jsem pro miny nebo hada.
-
Takže když se nám otázka nehodí, tak ji označíme za špatnou? OK, tomu rozumím.
Ne, nerozumíte. Kde jsem psal, že se mi otázka nehodí? Nikde. Psal jsem, že ta otázka je špatně. Protože součástí té otázky je tvrzení, které není pravda. Takže se na ní nedá odpovědět.
Když se vás někdo bude ptát, proč je tráva modrá, taky mu těžko budete moci odpovědět na jeho otázku, a místo toho mu budete muset vysvětlit, že tráva je zelená.
Jinak to vysvětlení nevysvětluje co tvrdíš. A nikdo se nebaví o SystemD initu, ale o SystemD, jehož je SystemD init nedílnou součástí, což je jaksi jádro problému, viz původní dotaz.
Viz původní komentář, na který jsem reagoval. A tentokrát si ho doopravdy přečtěte:
300K řádků?
Není to na init system trošku moc?
O čem se tam píše, o samotném initu, nebo o celém systemd?
Takže znova, je žádoucí, aby byl SystemD tak komplexní
Pro mnohé je to žádoucí. A ničemu to nevadí. Takže je to OK.
aby SystemD init na sebe povinně nabalil i ten tetris?
Opět další lež, systemd init na sebe nic nenabaluje.
-
Takže když se nám otázka nehodí, tak ji označíme za špatnou? OK, tomu rozumím.
Ne, nerozumíte. Kde jsem psal, že se mi otázka nehodí? Nikde. Psal jsem, že ta otázka je špatně. Protože součástí té otázky je tvrzení, které není pravda. Takže se na ní nedá odpovědět.
Jenže ta otázka není špatně.
Když se vás někdo bude ptát, proč je tráva modrá, taky mu těžko budete moci odpovědět na jeho otázku, a místo toho mu budete muset vysvětlit, že tráva je zelená.
Samozřejmě, to máš pravdu. Jenže ona ta tráva skutečně je zelená, přestože tvrdíš, že je modrá.
aby SystemD init na sebe povinně nabalil i ten tetris?
Opět další lež, systemd init na sebe nic nenabaluje.
Hééj, pokud je možné používat pouze SystemD init, tak to je ale dobrá zpráva.
-
Jenže ta otázka není špatně.
Systemd init není komplexní. Takže otázka, která se ptá na komplexní systemd init, je špatně. Nebo mi sna dokážete odpovědět na otázku, proč je tráva modrá?
Jenže ona ta tráva skutečně je zelená, přestože tvrdíš, že je modrá.
Popletl jste si osoby a obsazení. Nebo snad dokážete napsat, co je na systemd initu komplexního?
Hééj, pokud je možné používat pouze SystemD init, tak to je ale dobrá zpráva.
Teď už zbývá jen vysvětlit tu záhadu, proč systemd pořád kritizuje někdo, kdo o něm nic neví.
-
Hééj, pokud je možné používat pouze SystemD init, tak to je ale dobrá zpráva.
Teď už zbývá jen vysvětlit tu záhadu, proč systemd pořád kritizuje někdo, kdo o něm nic neví.
To je super mít tu odborníka na sD. Toho využiju a zeptám se na přímo. Jak použít pouze sD init, bez jakýchkoliv dalších částí sD?
-
Jak použít pouze sD init, bez jakýchkoliv dalších částí sD?
Zkompilujete si ho a nainstalujete. Jako kterýkoli jiný OSS.
-
Jak použít pouze sD init, bez jakýchkoliv dalších částí sD?
Zkompilujete si ho a nainstalujete. Jako kterýkoli jiný OSS.
No ale tam chybí první krok. Vykostit kraviny, zalepit po nich díry a pak az kompilovat. Jinak aby bylo jasno, nic proti sD jako initu nemam, i když po něm nijak netoužím. V initech je dlouhodobe bordel a jeden navíc nikomu neublíží a třeba se i hodí, ale problem je prave v tech dalších kusech, který bori některé dlouho fungující principy a bez kterých se to neobejde. Byt to hromada samostatných a samostatne fungujicich nástrojů, tak je to cajk.
-
Najprv to vyskusaj a potom bud mudry. Je to modularne ako kernel.
-
Najprv to vyskusaj a potom bud mudry. Je to modularne ako kernel.
Jakým způsobem se to přeloží pro kernel bez cgroups?
-
Najprv to vyskusaj a potom bud mudry. Je to modularne ako kernel.
No tak si to nejdřív vyzkoušej a potom buď moudrej, protože modulární to sice je, ale modularita je založená na vlastním API, který se ještě rok zpátky měnilo pod rukama, takže nahradit jakoukoliv součást znamenalo, že na to musel člověk něco ohýbat a měl téměř stoprocentní jistotu, že se mu to s příští aktualizací sD rozbije. Jak moc se mění teď nevím a je mi to tak nějak jedno, sD trpím tam kde musím a tam kde nemusím sice nakonec taky asi přejdu, ale doufám, že se do té doby vyřeší některý nechutnosti. Jinak, dřív si člověk mohl vybrat z několika kvalitních syslogů, cronů, time daemonů a nevím, čeho dalšího, ale dnes už smolíček. To by to totiž někdo musel upravit tak, aby se z toho sD nepokakal.
Jinak poslední skvělá zkušenost se sD na SLES12: instalace jednoho moc fajn komerčního softu rozhodila /etc/group a vyhodila z toho jednu skupinu, která tam byla pro sD. Tohle chyba sD nebyla a nevyčítám mu, že to nerozdejchal, ale to jak to nerozdejchal - bez jakékoliv viditelné chyby se do nekonečna snažil načíst jakousi kravinu. Žádná chyba, žádná recovery konzole, prostě asi 2 hodiny čekal na službu, která měla nastavenej timeout na 90 vteřin!!! No sorry jako...
-
Najprv to vyskusaj a potom bud mudry. Je to modularne ako kernel.
Jakým způsobem se to přeloží pro kernel bez cgroups?
A jak se to zkompiluje bez pocitace? A jak pro Windows?
-
A jinak, abych jen nehejtoval, udělat pořádek v initu je zajisté záslužná činnost, ale sD má dva zásadní problémy:
1. banda tupých hlav ho procpala do mnoha dister v době, kdy by to příčetný vývojář označil jako alpha verzi (momentálně bych to nazval betou, maximálně RC)
2. vývojáři v čele s LP jsou arogantní hajzlíci, kteří nejsou schopní normální diskuze a v rámci svého supr čupr agilního vývoje jsou schopní ze dne na den rozbít léta fungující věci, je jim to u míst, kde záda ztrácejí svoje pěkné jméno a pak kopou kolem sebe, že se mají ostatní přizpůsobit
No a pak je tu další problém a to jsou další retardovaní vývojáři, kteří aby nemuseli náhodou napsat pár řádek kódu navíc, tak raději vytvoří mnohdy zcela zbytečné závislosti na sD. Občas mám pocit, že se z Linuxu stává windows ENT (eště novější technolodžy). A takhle to dopadá, když se do komunitního projektu začne cpát nepřiměřené množství komerčních subjektů prosazujících svoje zájmy (zisk).
-
A jinak, abych jen nehejtoval, udělat pořádek v initu je zajisté záslužná činnost, ale sD má dva zásadní problémy:
1. banda tupých hlav ho procpala do mnoha dister v době, kdy by to příčetný vývojář označil jako alpha verzi (momentálně bych to nazval betou, maximálně RC)
2. vývojáři v čele s LP jsou arogantní hajzlíci, kteří nejsou schopní normální diskuze a v rámci svého supr čupr agilního vývoje jsou schopní ze dne na den rozbít léta fungující věci, je jim to u míst, kde záda ztrácejí svoje pěkné jméno a pak kopou kolem sebe, že se mají ostatní přizpůsobit
No a pak je tu další problém a to jsou další retardovaní vývojáři, kteří aby nemuseli náhodou napsat pár řádek kódu navíc, tak raději vytvoří mnohdy zcela zbytečné závislosti na sD. Občas mám pocit, že se z Linuxu stává windows ENT (eště novější technolodžy). A takhle to dopadá, když se do komunitního projektu začne cpát nepřiměřené množství komerčních subjektů prosazujících svoje zájmy (zisk).
+1
-
Jak by mohl systemd vyřešit, že v distru A je knihovna verze X a v distru B verze Y?
Jednoduse. Pote, co zdola Tetris, Solitaire, jadro a dalsi veci, zautici na knihovny. Ty budou prichazet pouze v Poetteringove verzi, coz bude dusledne kontrolovane pri bootu podle digitalniho podpisu. System s nedovolenymi knihovnami odmitne bootovat a bude nutna reinstalace.
-
A jak se to zkompiluje bez pocitace? A jak pro Windows?
Chtít provozovat init na kernelu bez cgroups je stejná pitomost jako chtít kompilovat bez počítače? Tak jo no... modulární systém, chápu.
-
A jak se to zkompiluje bez pocitace? A jak pro Windows?
Chtít provozovat init na kernelu bez cgroups je stejná pitomost jako chtít kompilovat bez počítače? Tak jo no... modulární systém, chápu.
Jak souvisi modularita systemu s tim, ze ma nejake behove pozadavky?
-
Postupně jsem zmigroval našich pár serverů na FreeBSD a OpenBSD a desktopy na OpenBSD..... a vůbec nelituju. Můžete tu diskutovat o přínosu SytemD jak chcete, ale bude požírat víc a víc funkcí, bude vytvářet víc a víc závislostí na jiných komponentách systému... a Linux tím jde jen směrem provázaných, zabugovaných a uzavřených systémů typu Windows a OSX.
-
Jak souvisi modularita systemu s tim, ze ma nejake behove pozadavky?
Rozhodně víc než absence cgroups s překladem bez počítače.
-
a Linux tím jde jen směrem provázaných, zabugovaných a uzavřených systémů typu Windows a OSX.
OS X má náhodou docela rozumný init ;)
-
a Linux tím jde jen směrem provázaných, zabugovaných a uzavřených systémů typu Windows a OSX.
OS X má náhodou docela rozumný init ;)
Souhlas, v mnoha ohledech je launchd mnohem rozumnější než systemdLP...
-
Uz se s tim smirte. SystemD zvitezil uz vcera. Par natruc dister jiste bude pro nostalgiky ale ve firmach si uz bez SD neskrtnete. Prosadili to protestanti (arch), presli na nej katolici (redhat) a take pravoslavni (debian). Distra bez systemd jsou dnes povazovana za pohanstvi. Linux se meni, komercionalizuje a komerce vyzaduje pravidla a spoleh. Linux jak jste jej znali pred 10 lety uz neni. Muzete najit Slackware skanzen nebo Gentoo gheto, ale na produkci to nema nikdo. Mozna je trochu problem, ze to vsechno jeste volame linux. Ale je to jen z duvodu ze lepsi kernel neni, jakmile bude tak mainstream na nej prejde bez mrknuti oka jak presel na sytemd.
No a pak tu mame jeste jine unixy - bsd (oblibeny u sitaru), macos (oblibeny u vyvojaru a grafiku) a treba takove Haiku (ex beos). Ty fragmentaci na desitky dister netrpi a tam podobne schizma jako prinesl systemd nehrozi.
-
Rozhodně víc než absence cgroups s překladem bez počítače.
Nejak mi unika proc bych mel chtit pouzivat kernel bez cgroups... Nebo co tim vubec chces rict... Ze existuje volba v kernelu, kterou kdyz vypnes, tak rozbijes SD? Ano, to je zcela jiste pravda... A kdyz vypnu podporu tty, nepujde se mi prihlasit :-) Ano, existuji volby kernelu, ktere dokazi rozbit userspace na nich zavisly... Modularita systemu opravdu neimplikuje podporu ruznych nestandardnich a obskurnich konfiguraci, zvlaste ne neceho jako je kernel... A proc SD cgroups pouziva ma velmi dobre a racionalni duvody, protoze diky nim ma skutecne beh sluzeb pod kontrolou, coz je jenom dobre.
Souhlas, v mnoha ohledech je launchd mnohem rozumnější než systemdLP...
launchd je SD podobny jak vejce vejce... Tez implementuje miliardu veci, ktere sysvinit neresi (socket activation, monitorovani filesystemu pro zmeny, cron-like funkcionalita).
A jinak, abych jen nehejtoval, udělat pořádek v initu je zajisté záslužná činnost, ale sD má dva zásadní problémy:
1. banda tupých hlav ho procpala do mnoha dister v době, kdy by to příčetný vývojář označil jako alpha verzi (momentálně bych to nazval betou, maximálně RC)
2. vývojáři v čele s LP jsou arogantní hajzlíci, kteří nejsou schopní normální diskuze a v rámci svého supr čupr agilního vývoje jsou schopní ze dne na den rozbít léta fungující věci, je jim to u míst, kde záda ztrácejí svoje pěkné jméno a pak kopou kolem sebe, že se mají ostatní přizpůsobit
No a pak je tu další problém a to jsou další retardovaní vývojáři, kteří aby nemuseli náhodou napsat pár řádek kódu navíc, tak raději vytvoří mnohdy zcela zbytečné závislosti na sD. Občas mám pocit, že se z Linuxu stává windows ENT (eště novější technolodžy). A takhle to dopadá, když se do komunitního projektu začne cpát nepřiměřené množství komerčních subjektů prosazujících svoje zájmy (zisk).
No a diky bohu za to, ze se tam ty komercni subjekty cpou. Jinak bysme skoncili se systemem, na kterem by se mohla vyucovat historie operacnich systemu. Mozna by si stalo za to si uvedomit, kolik toho do Linuxu prinaseji prave ty komercni firmy (jako je RH, Suse, Canonical, Intel a mnohe dalsi) a kolik komunita lidi, kteri to delaji povetsinou ve volnem case a pak se na to vykaslou, kdyz prijde rodina/jina prace/proste je to prestane bavit.
Takze za me diky za ty komercni firmy, ktere nad Linuxem svuj byznys postavili - protoze prave diky nim je dneska zcela normalni odpoved (ktere se nikdo nedivi) na to, jaky OS chci na server, prave Linux :-) Pouzivam Linux od roku 1998 jako svuj primarni desktopovy a serverovy OS, takze muzu trochu srovnavat - a rozhodne bych nevymenil stav tehdy a stav ted - nemluve o o tom, ze tehdy srovnani Windows NT a Linuxu bylo k smichu, dneska je k smichu taky, ale celkem obracene (hello podpora dockeru ve windows :-D) :-D
-
Nejak mi unika proc bych mel chtit pouzivat kernel bez cgroups...
Treba proto, ze vyrabis ten embedded system, kde proste nechces mit nic, co neni nezbytne nutny.
-
Nejak mi unika proc bych mel chtit pouzivat kernel bez cgroups...
Treba proto, ze vyrabis ten embedded system, kde proste nechces mit nic, co neni nezbytne nutny.
Pokud resim na embedded systemu kilobajty ,tak v tom pripade nebudu pouzivat asi ani glibc,ani sd,celkem asi nic z normalniho userspace..
Jinak jeden z nasich zakazniku ma systemd na embedded zarizeni pro vytahy - takze sd hateri,neriskujte a chodte vsude pesky,nikdy nevite,kdy tam bude systemd ;D :D
-
Pokud resim na embedded systemu kilobajty
To nejsou ani nahodou kilobajty. Systemd ti tam zatahne dbus, udev...
tak v tom pripade nebudu pouzivat asi ani glibc,ani sd,celkem asi nic z normalniho userspace..
Jo. A je skoda nepouzivat init system jenom z tohodle duvodu. SD je v principu fajn, akorat je proste skoda, ze spoustu veci uzivateli vnucuje. Kdyby byl _opravdu_ modularni, konfigurovatelny a ty zasadni veci opravdu rock solid, nerekl by proti nemu nikdo ani popel a vsichni by byli happy.
Jinak jeden z nasich zakazniku ma systemd na embedded zarizeni pro vytahy - takze sd hateri,neriskujte a chodte vsude pesky,nikdy nevite,kdy tam bude systemd ;D :D
Vsadim tri prsty na prave ruce, ze tam ten Linux nic kritickyho neridi. Hlasky "prvni patro", "druhe patro" at tam klidne pousti systemd ;)
-
Pokud resim na embedded systemu kilobajty
To nejsou ani nahodou kilobajty. Systemd ti tam zatahne dbus, udev...
tak v tom pripade nebudu pouzivat asi ani glibc,ani sd,celkem asi nic z normalniho userspace..
Jo. A je skoda nepouzivat init system jenom z tohodle duvodu. SD je v principu fajn, akorat je proste skoda, ze spoustu veci uzivateli vnucuje. Kdyby byl _opravdu_ modularni, konfigurovatelny a ty zasadni veci opravdu rock solid, nerekl by proti nemu nikdo ani popel a vsichni by byli happy.
Jinak jeden z nasich zakazniku ma systemd na embedded zarizeni pro vytahy - takze sd hateri,neriskujte a chodte vsude pesky,nikdy nevite,kdy tam bude systemd ;D :D
Vsadim tri prsty na prave ruce, ze tam ten Linux nic kritickyho neridi. Hlasky "prvni patro", "druhe patro" at tam klidne pousti systemd ;)
Jj,jen nouzovou signalizaci,diagnostiku a rizeni motoru ))
-
Vsadim tri prsty na prave ruce, ze tam ten Linux nic kritickyho neridi. Hlasky "prvni patro", "druhe patro" at tam klidne pousti systemd ;)
Zajímalo by mě, zda existuje nějaká metodika, který by vytvořila něco jako "zaručený" software. Tak nějak bych stále věřil spíše hw řešení (systém zpětných brzd etc).
Spousta příležitostí, aby se něco pokazilo: šváb, kabeláž, sw...
-
Vsadim tri prsty na prave ruce, ze tam ten Linux nic kritickyho neridi. Hlasky "prvni patro", "druhe patro" at tam klidne pousti systemd ;)
Zajímalo by mě, zda existuje nějaká metodika, který by vytvořila něco jako "zaručený" software. Tak nějak bych stále věřil spíše hw řešení (systém zpětných brzd etc).
Spousta příležitostí, aby se něco pokazilo: šváb, kabeláž, sw...
třeba IEC61508 hromada dalších, v tomhle případě bych si tipl, že bezpečnost je zajištěna nějakým hw (a že řízení motoru znamená komunikaci s invertorem)
-
Zajímalo by mě, zda existuje nějaká metodika, který by vytvořila něco jako "zaručený" software. Tak nějak bych stále věřil spíše hw řešení (systém zpětných brzd etc).
Spousta příležitostí, aby se něco pokazilo: šváb, kabeláž, sw...
Bezpečnost tam samozřejmě musí být zaručena fyzicky/fyzikálně. Nemůže to být tak, že se ti v Linuxu objeví nějakej memory leak a výtah spadne :) Tím "řízením motoru" imho tnr trochu mlží. Čekal bych tak maximálně, že Linux uděluje instrukce "popojeď o 3 patra výš". A kdyby se něco podělalo, tak výtah přinejhorším zůstane stát, nebo pomalu, nouzově sjede.
-
No a pak je tu další problém a to jsou další retardovaní vývojáři, kteří aby nemuseli náhodou napsat pár řádek kódu navíc, tak raději vytvoří mnohdy zcela zbytečné závislosti na sD.
Par radek kodu. Ano, pro kazdou distribuci jine radky, kazdy program vlastni radky, proc si vlastne ti vyvojari nepisou rovnou vlastni obsluhu fs, vlastni obsluhu netstacku, vlastni obsluhu shellu...
-
No a pak je tu další problém a to jsou další retardovaní vývojáři, kteří aby nemuseli náhodou napsat pár řádek kódu navíc, tak raději vytvoří mnohdy zcela zbytečné závislosti na sD.
Par radek kodu. Ano, pro kazdou distribuci jine radky, kazdy program vlastni radky, proc si vlastne ti vyvojari nepisou rovnou vlastni obsluhu fs, vlastni obsluhu netstacku, vlastni obsluhu shellu...
He? Pro každou distribuci jiné řádky? Tím asi narážíš na init, což je zcela irelevantní, protože nejde o závislosti na initu, kterej je v podstatě každýmu softu, potažmo jeho vývojářům, úplně u zadku, ale jde o závislosti na tom bordelu kolem.
A proč si nepíšou vlastní obsluhu všeho možnýho? To jako toho, co dělá jádro, což je jaksi z principu povinná závislost (a nemusí to být jen Linux) a co zvládnou s pomocí standardních knihoven? Závislosti na sD se dá vyhnout, což má dost zásadní vliv na možnost zkompilování a používání aplikace na jiném OS a většinou je to tak moc práce, že pokud ten SW používá víc lidí, vždy se najde někdo, kdo z něj tu závislost vytluče. Takže je otázka, jestli není lepší naspat SW rovnou bez závislosti na sD, případně sD mít jen jako nepovinnou možnost, pokud to přinese nějakou výhodu.
-
komerce vyzaduje pravidla a spoleh
Ano, a to presne zaruci systemd: :-D
No a pak tu mame jeste jine unixy - bsd (oblibeny u sitaru), macos (oblibeny u vyvojaru a grafiku) a treba takove Haiku (ex beos). Ty fragmentaci na desitky dister netrpi a tam podobne schizma jako prinesl systemd nehrozi.
Bohuzel u Haiku a dalsich nehrozi ani dobra HW podpora a dostatek aplikaci.
-
No a diky bohu za to, ze se tam ty komercni subjekty cpou. Jinak bysme skoncili se systemem, na kterem by se mohla vyucovat historie operacnich systemu.
Aby se podle Linuxu se systemd jednou nevyucovala historie slepych cest, ktere vedou do totalni prdele, ze ktere neni navratu.
-
Ptaji se vnoucata JardyP.
- Dedo a kdy jsi presel na systemd ?
- Ale jdu si tak vlakem v kupe, na kolenou notas. Proti mne sedi Kim Kardashian a rekla, ze kdyz nainstaluji systemd a vylizu ji pekac tak mi da tenle zlaty prsten!
-
Aby se podle Linuxu se systemd jednou nevyucovala historie slepych cest, ktere vedou do totalni prdele, ze ktere neni navratu.
To vis ze jo, Jardo :-D Pokracuj ve svem vlhkem snu :-D
-
Zajímalo by mě, zda existuje nějaká metodika, který by vytvořila něco jako "zaručený" software. Tak nějak bych stále věřil spíše hw řešení (systém zpětných brzd etc).
Spousta příležitostí, aby se něco pokazilo: šváb, kabeláž, sw...
To normy věří HW taky, například motor není vypnutý, pokud (na 400V) nejsou kontakty 3mm od sebe. Takže frekvenční měnič není problém, jeho řízení po CANu nebo MODBUSu není problém, ale před ním stykač s ovládáním z PLC a u toho ještě bezpešnostní modul...
Jinak kde o něco jde, tam jsou dva systémy s inverzní logikou. Když situaci vyhodnotí stejně (jeden musíš, druhý smíš), tak se to teprve zapne. A když jeden vyhodnotí musíš a druhý nesmíš, vypne stykač...
Nebo se třeba porovnávají tři identický systémy. Stejný výsledku OK, jeden dá jiný výsledek a vypadne obsluze warning, všechny tři se liší a systém se odstaví. Atd. Na VUT jsme na tyhle finty, výpočty spolehlivosti, zálohy, záskoky atd. měli extra předmět a bylo to docela zajímavý.
-
Cca před rokema půl se mi na notebooku Debian Jessie po jednou updatu system tak rozsypal, že šlo nabootovat jen do singleuser režimu pře sysv skripty. Tehdy jsem se tak naštval, že šel z notebooku do háje.
Cca před rokem jsem měl problém s OpenSuse (nevím přesně verzi, ale byla to nějaká tehdejší stable) na vmware esxi, kde po restartu někdy naběhla a někdy nenaběhla sít. Díky bohu jsem to musel jen nainstalovat, tak nevím jak to vyřešili.
-
Cca před rokema půl se mi na notebooku Debian Jessie po jednou updatu system tak rozsypal, že šlo nabootovat jen do singleuser režimu pře sysv skripty. Tehdy jsem se tak naštval, že šel z notebooku do háje.
Cca před rokem jsem měl problém s OpenSuse (nevím přesně verzi, ale byla to nějaká tehdejší stable) na vmware esxi, kde po restartu někdy naběhla a někdy nenaběhla sít. Díky bohu jsem to musel jen nainstalovat, tak nevím jak to vyřešili.
... smarja co to je za smutnej pribeh synku...
-
Muzete najit Slackware skanzen nebo Gentoo gheto, ale na produkci to nema nikdo.
Ja mám Gentoo skoro na všetkých produkčných serveroch (okolo 20 kusov). Málokedy sa stane, že by s tým bol nejaký problém. Ide mi to stabilnejšie a dlhodobo udržateľnejšie, než všetky ostatné distribúcie, ktoré som kedy skúšal. A samozrejme, SystemD tam nemám. Skúšal som ho vo virtuáli a neprišlo mi, že by to malo jedinú výhodu pre moje účely.
-
No po dvou mesicich zmigrovano dalsich 20 servru, vsechno funguje jak ma. U tech zmigrovanych drive zadny problem a celkove tak nejak se mi zda, ze mam mene prace s administraci. Je to proste dobre, neni se treba toho prechodu obavat.
-
Neni treba jit daleko, taky doma mame "a", "nebo" anebo "anebo" :D
Viz jazykovy koutek http://www.rozhlas.cz/plzen/jazykovykoutek/_zprava/322944
Obávám se, že to soudruh Prošek nevysvětlil dobře či přesně. Spojka "nebo" se dá použít ve významu slučovacím, kdy platí alespoň jeden ze spojovaných členů, ale klidně i všechny (to je to, o co se tu někteří marně snaží s odkazem na nějakou zzadekenou angličtinu), nebo ve významu vylučovacím, kdy platí jen jeden z členů, pak ale musí před "nebo" být čárka.
-
Obávám se, že to soudruh Prošek nevysvětlil dobře či přesně. Spojka "nebo" se dá použít ve významu slučovacím, kdy platí alespoň jeden ze spojovaných členů, ale klidně i všechny (to je to, o co se tu někteří marně snaží s odkazem na nějakou zzadekenou angličtinu), nebo ve významu vylučovacím, kdy platí jen jeden z členů, pak ale musí před "nebo" být čárka.
Krásná ukázka použití ve významu vylučovacím ;D
-
Chtěl jsem jít příkladem. ;)
-
Takže ukončete jazykové nebo pindíkoměrné okénko, nebo se systémdé nesouvisí.
-
SystemDick je kanka na historii linuxu a unixu obecne. Potter se totiz snazi udelat si svuj vlastni os paraziticky nad linuxem a vsem to nacpat.
Coz se mu podarilo a je to prvni krok k padu linuxu.
Jsme v dobe post wokni.
Jednou nastane doba post linuxova.
SystemDick tomu otevrel vratka.
Jedine co BSD brzdi je malo devs. To se ale pomalu zmeni obavam se.
-
No jasne, hateri sa ozvali a vedia o systemd velke H. A pritom sami raz zmigruju, ajurat budu mat blbe reci ze v 2017 to bolo nepouzitelne ale v 2019 je to uz fasa...
Dobre si spravil, ze si zmigroval. Dobuducna budes mat ovela jednoduchsi upgrade. SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma. A kodia ju spickovi a PLATENI programatori. Nie banda zhulenych githubistov. Staci pozriet zdrojaky. Kazdy sw moze mat chybu, ale u systemd by som sa bal najmenej. Vsetko krasne zdokumentovane, ochotna komunita, radost pouzivat ich api. Init style scriptarina je obsoletny balast porovnatelny s autoexec.bat a config.sys :D Ale to haterovi nevysvetlis, lebo ich to asi vzrusuje trolit nad pokrokom.
U nas sme za dva roky postupne nabehli na systemd na stovke masin, zeleznych aj virtualnych a ziaden problem co by stal za rec. Problemy boli zvycajne len pri upgrade. Po nastaveni vsetko slape, ziaden problem s logovanim, watchdogmi a podobne nezmysly co siria hateri. Blobu zdar ;)
Nejsem si jisty jestli si vtipalek, idiot a nebo troll.
-
No jasne, hateri sa ozvali a vedia o systemd velke H. A pritom sami raz zmigruju, ajurat budu mat blbe reci ze v 2017 to bolo nepouzitelne ale v 2019 je to uz fasa...
Dobre si spravil, ze si zmigroval. Dobuducna budes mat ovela jednoduchsi upgrade. SystemD je jedna z najotestovanejsich a najstabilnejsich veci aku linux ma. A kodia ju spickovi a PLATENI programatori. Nie banda zhulenych githubistov. Staci pozriet zdrojaky. Kazdy sw moze mat chybu, ale u systemd by som sa bal najmenej. Vsetko krasne zdokumentovane, ochotna komunita, radost pouzivat ich api. Init style scriptarina je obsoletny balast porovnatelny s autoexec.bat a config.sys :D Ale to haterovi nevysvetlis, lebo ich to asi vzrusuje trolit nad pokrokom.
U nas sme za dva roky postupne nabehli na systemd na stovke masin, zeleznych aj virtualnych a ziaden problem co by stal za rec. Problemy boli zvycajne len pri upgrade. Po nastaveni vsetko slape, ziaden problem s logovanim, watchdogmi a podobne nezmysly co siria hateri. Blobu zdar ;)
Nejsem si jisty jestli si vtipalek, idiot a nebo troll.
Idiot...
-
Takže ukončete jazykové nebo pindíkoměrné okénko, nebo se systémdé nesouvisí.
Systemd ještě neobsahuje grammarcheckerd? Jakto?
-
SystemDick je kanka na historii linuxu a unixu obecne. Potter se totiz snazi udelat si svuj vlastni os paraziticky nad linuxem a vsem to nacpat.
Coz se mu podarilo a je to prvni krok k padu linuxu.
Trololo, linux nema so systemd nic. Systemd akurat obsahuju moderne distra ktore linux pouzivaju ako kernel. "Pad linuxu" bude len a len dobra zalezitost pretoze tu vladne vseobecna euforia ze je z toho mozne vyskladat desktopovy OS. Konci to komplexnym bordelom, kde mozu akurat tak dakovat za systemd. Cim skor sa ludstvo z toho mokreho sna, ze z linuxoveho distra bude poriadny desktop zobudi, tym lepsie.
-
Ja zmigroval desktop na wayland, tak nejakou nadeji snad ten linux jeste snad ma. Alespon se oddeli zrno od plev a vzkvetat budou moderni wayland apky podobne jako systemd.
-
Nejak mi unika proc bych mel chtit pouzivat kernel bez cgroups...
Treba proto, ze vyrabis ten embedded system, kde proste nechces mit nic, co neni nezbytne nutny.
Tam ti staci zacekovat len jedno nastavenie CGroups = enable, vsetko ostatne co sa tyka cgroups mozes zakazat.
SD potrebuje cgroups na monitoring procesov ....
-
Také fandím system, je to lepší než ty prasárny s bashovými skripty s procedurálnímy case esac
-
Já už jsem rezignoval, stejně na tu sračku přešly všechny distra, holt si ten desktop přeinstaluju když se systemd dosere a odmítne bootovat nadobro. Aspoň mám každej druhej měsíc o zábavu postaráno a je to rychlejší než v té kokotině hledat chybu.
-
Já už jsem rezignoval, stejně na tu sračku přešly všechny distra, holt si ten desktop přeinstaluju když se systemd dosere a odmítne bootovat nadobro. Aspoň mám každej druhej měsíc o zábavu postaráno a je to rychlejší než v té kokotině hledat chybu.
Vsechny ne. http://without-systemd.org