Dotaz: Děkuji firmě RedHat, že mi umožnuje zažít stejnou zkušenost, jako mají uživatelé Windows

[frufru]

Dělat Vám bezmocného testovacího debila, tak to byl můj sen. Než jste spáchali tu hovadinu SYSTEMD, tak linux dělal co má a nebyl s tím problém. System windows má plno placených testerů, kteří při každé aktualizaci trnou co se všechno pokazilo. Firma RedHat to povýšila na ještě lepší level. Uživatelé linuxu to dělají zadarmo. Proč pro obyčejného uživatele byl linux bezproblémový, než jste vymysleli systemd. Chápu, že pokrok se nezastaví, ale jak mohu linuxu věřit, když se pořád něco sere v systemd.Jel jsem mnoho let bez win, ale teď už tam mám zpět win 10 a silně uvažuji o pořízení MacBook. Nechci zažívat problemy s HDD a systemD.

1/ Tchán má nainstalovaný LinuxMint 19.2. V linuxu se nevyzná, ale aktualizaci přes správu aktualizací zvládne. Nic neinstaluje, jen prohlíží internet a sem tam si zahraje karetní hry. Po aktualizaci mu nešel spustit počítač. Aktualizovalo se jádro 4.15.0.70-generic a system skončil. Po výpisu logu jsem zjistil, že system trvá na připojení disku s btrfs ????? System je na jednom 500GB disku, který je rozdělen na 30GB / a zbytek /home. Souborový system ext4. Tak proč trval na připojení btrfs ?????

2/ Proč mi systemd zasere místo na disku, když jsem ho o to nežádal. Rady typu, že si mám všechna nastavení projít, neberu!! Opravdu všicni uživatelé win, MAc OS lezou do nastavení a kontrolují nastavení???? Sežrat přes Giga místa na mém disku jen pro log systemd??? Asi je to třeba, vždyť se tesruje a je třeba mít zpětnou vazbu. Nastavit, opravit to jde, ale musí o tom člověk vědět. Hrát si na tichého brouka nepomáhá a spíš nasere uživatele linuxu.

3/ Po této zkušenosti, kdy jeden system zhavaroval a druhý, kvůli nedostatku místa málem zhavaroval jsem se rozhodl pořádně zazálohovat 2TB disk s daty. Pořídil jsem externí 4TB HDD a začal zálohovat. Prostě přetáhl adresáře a nechal zálohovat. Asi ve 3/4 system spadl. Restart znova skončil na systemctl. Nabídnul přihlášení do root, výpis systemctl (-xb nebo tak nějak). Pak už nic. System win 10 natartoval. System Manjaro kde 18.1.3 nenastartoval. System LinuxMint 19.2 nenastartoval. Vše končilo na systemctl???? VTF Po restartu z flash disku a kontrole disku přes gparted system Manjaro i LinuxMint nastaroval. VTF????

== přestal jsem věřit linuxu. Už to pro mne není spolehlivý system. Děkuji firmě RedHat za tu sračku kterou protlačila do linuxu. S linuxem asi skončím. Sory, napsat jsem to musel. Během měsíce mít 3x špatnou zkušenost se systemd ???? A ostatní na tom nejsou líp.

http://www.abclinuxu.cz/poradna/linux?tags=systemd&logicalOp=on

---

---

Odpovědi

[unix-like]

Tak svet sa meni. A preslapi sa deju. Ak chces mat nieco poriadne, tak si za to plat. Citaj licencie, autory garantuju na vlastne riziko alebo max. cena media.

Mozno sa ludom nepaci (ak funguje ok, tak ano - aspon mne), ale zas na druhu systemd moze priniest isty druh standardacie do buducna, ak budu vznikat forky. Ak sa budu vytvarat dalsie forky. Chapem tych, co vytvarali.

Preco neprejde k Debianu stable s net/minimal install? Preco neprejdes k none-systemd systemom. Proste dnes su systemy zlozite - jednoduchost nestaci alebo hraju rolu peniaze.

Zvol si dobre. Su distro, ktore mas maximalne pod kontrolou (vlastne distro zo zdrojakov) po za uzivatela rozmyslajuceho.

Nik ta nenuti pouzivat. Existuje komercne distra.

systemctl - je take univerzalne rozhranie na chyb pri starte a radsej hod, co za chybu.

Unix je unix. Bud ide, alebo nejde, nic medzi. Ak ma poskodit, tak nebude radsej robit nic. Tak je robeny.

Preco sa kriticke veci duplikuju. Mame produkcne a testovacie zostavy.

Chod za typkom, co ti nainstaluje poriadne. Skor skara skola. Pozdra zdrojaky. Zacil aj stare casy bez pulseaudio, btrfs, kommpilacia zo zdrojakov. Vsetko sa lahko spravuje ak neni problem. Lez co potom, ked je problem.

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

Upřímně, zas tak dobře to nevidím. Komunita nemá tolik vývojářů, aby se mohlo neustále forkovat. A projekty typu one man show též nejsou dobrou cestou. Už jsem to psal nesčetněkrát. Myšlenka systemd nebyla špatná, ale provedení ano. Když se podíváme, po jakou dobu už tu systemd je a že pořád generuje nové a nové chyby, které se ne zrovna pohodlně odhalují a napravují, pak můžeme klidně napsat, že nasazení napříč distribucemi bylo opravdu velkou chybou. A spíše to vypadá na úmysl. Pak to přirovnání k Windows není nikterak zcestné. Jak dlouho tu jsou W10? A nemají ani pořádně odladěnou přihlašovací obrazovku. Já jedu Devuan, takže jsem relativně v klidu jak na desktopu, tak na serverech. Ale upřímně, nevím , co bych dělal, kdyby projekt z jakéhokoliv důvodu najednou skončil. Na desktop možná PCLOS Ale i na tomto projektu je vidět velký nedostatek vývojářů. Distribucí bez systemd je celkem dost, ale málo jich má širokou škálu balíčků. Zkrátka máme období rozbitých systémů. Já sice nakouslé jablko nepoužívám, ale už i z těchto končin jsem zaslechl nějaké stížnosti.

[vencour]

Co nějaké xBSD? Sám mám v záloze FreeBSD drobet ošahané pro případ nouze.

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

To by byl asi případ pro ty servery. Já zase sleduji DragonFly BSD.

[unix-like]

Tie forky som tak, ze viac menej da systemd obecne user API, kde uz backend bude rozdielne implementacie. Nie nadarmo sa aj pri systemd proces vola /sbin/inittab. Ale inittab spustanie to nie.

Skor to ber tak, ze ak sa toho niekto chyty a spravi poriadne. Aj v Debiane je otazke ci nieco ine ako systemd sa bude pouzivat. Vid ako Firefox alebo Chrome sa dostal. Ale ist cestou bez podpory (konfiguracnej) systemd, to bude pokus o hazard.

Ano. Unix-like spustenie - 1 prikaz a ide to, verzus .service skript pre spustenie. Co je milsie pre admina?

Ak sa nechyti nejaka osoba poriadne, tak sa stav nezmeni.

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

Tie forky som tak, ze viac menej da systemd obecne user API, kde uz backend bude rozdielne implementacie. Nie nadarmo sa aj pri systemd proces vola /sbin/inittab. Ale inittab spustanie to nie.

Skor to ber tak, ze ak sa toho niekto chyty a spravi poriadne. Aj v Debiane je otazke ci nieco ine ako systemd sa bude pouzivat. Vid ako Firefox alebo Chrome sa dostal. Ale ist cestou bez podpory (konfiguracnej) systemd, to bude pokus o hazard.

Řekl bych, že takhle nějak už to funguje. Třeba openSUSE se snaží to mít dobře odladěné. Ale řekl bych, že jim to dá poměrně dost práce. Otázkou je, jestli se ta práce vyplácí za tu (ne)efektivitu, kterou to má přinášet.

Ano. Unix-like spustenie - 1 prikaz a ide to, verzus .service skript pre spustenie. Co je milsie pre admina?

Ak sa nechyti nejaka osoba poriadne, tak sa stav nezmeni.

A jaký je v tom rozdíl oproti jiným initům?

[unix-like]

Oprava. Systemd sa uzivatelovi zda, ze sa tak vola, ale na disku je to link na /lib/systemd/systemd.

A jaký je v tom rozdíl oproti jiným initům?

Asi taky rozdiel medzi funkcionalnym a objektovym programovanim. Inittab to je hned jasne pridas. Neriesis nejake zavislosti pred/po ako mozes systemd. Ak sa to ma spustis za pripajanim diskov, tak to spustis. Alebo ak nechces bojovat s inymi, tak to das rovno do /etc/inittab. Do inittab pridas bez nejakych vedomosti. Do systemd nie (resp. okopirovat/editovat). Keby malo nejake oficialne GUI klikatko.

[Peter Golis]

Do inittab pridas bez nejakych vedomosti. Do systemd nie (resp. okopirovat/editovat). Keby malo nejake oficialne GUI klikatko.

Nevidím dôvod prečo by čovek nemohol spustiť systemd-fstab-generator — Unit generator for /etc/fstab, hoci aj zo single (s pripojenou bižutériou) aby sa mu preklopilo /etc/fstab do mount unitov. Alebo si tie Unity človek vytvorí/aktivuje/deaktivuje aj sám.

I keď je pravda že oldschool môže namietať že pri výpadku nejakého disku na to v strese zabudne keďže sa jedná o relatívne novú technológiu. Ja som s systemd spokojný už vyše 10 rokov.

[unix-like]

To je fakt pravda, ze systemd supluje fstab. Podla mojich skusenosti - minimal install nie. Mazal som swap a nasledne pridal.

[Peter Golis]

This makes sense, none.

Vedel by si to tvoje vyjadrenie preložiť do nejakej zrozumiteľnej reči?

[debian+]

To je fakt pravda, ze systemd nahradia (implementacne) fstab_ Podla mojich skusenosti (Debian minimal install), nie. Mazal som swap odiel a nasledne ho pridal, a pri bootovani sa riadil podla fstab (swap nebolo, aj tak ho hladal).

[Peter Golis]

Systemd nenahrádza fstab, systemd používa fstab ako vedľajší zdroj konfigurácie. Inak by neexistoval ten nástroj na ktorého manuál som odkazoval. A ak si s tým mal nejaký problém, tak ti znova dávam do pozornosti ten manuál.

Čítaj, a študuj. Až potom píš.

[lajka27]

+1

[Mirek]

Ano je to názor. Ale má zkušenost je poněkud jiná. Potřeboval jsem na NB s dual bootem ( W10 a L ) vyměnit disk za větší pomocí CloneZilla, příčemž W patrišnu jsem nepotřeboval měnit. Šel jsem o radu za MS certifikovaným inženýrem, no a jeho rady byly jen známá modrá smrt. No a tak jsem se ponořil a doplnil si znalosti z Linuxu. Stačilo změnit pár drobností a je to vyřešené. To ovšem ti, co umějí "jen klikat" i když jsou MS certifikování asi nechápou. Proto asi nepochopí ani i nezbytnosti, které nese jakákoliv změna. Nejenom systemd, ale před časem i změna samby ...

[vencour]

Nic ve zlym, když něco někomu doporučím, laikovi, tak bych mu měl nějaké kritické stavy ošetřit. Nenechat ho, aby sám zjistil nějakou kritickou chybu jako první.
Sám jedu na gentoo bez systemd.

[eagle.metawerzum]

Sory? VTF? Možná bude problém mezi židlí a klávesnicí.

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

Nevím, nevím ... minulý týden jsem testoval nějakou distribuci (bohužel už ji nemám na testovacím stroji, tak nevím co to bylo, možná něco od Mintu) a pořád mi vnucovala zapnutí bodu obnovení. Na to v Linuxu fakt nejsem zvyklý. Přijde mi, že nás dlouhodobé uživatele se snaží odsunout někam pryč a ten systém se snaží postavit pro někoho, kdo jim ho stejně používat nebude.

[frufru]

To je Vaše standartní odpověď? Chyba mezi klávesnicí a židlí. Špatně nastavený system. Špatně spravovaný system. Choď za někým zkušenějším. SORY, jseš chudák a měl by jsi se zamyslet TY, jestli nemáš problém mezi klávesnicí a židlí. Já mluvím o připravených systemech, které se defaultně nainstalují. Přidám maximálně tiskárny apod. Uživatelé to používají JEN na psaní dopisu, mailů, prohlížení internetu a občas hraní jednoduchých her. Do nedávné doby stačilo pouze nainstalovat a upgradovat. System běží 1-2 roky a pak ho přeinstaluji za novější. Než přišel systemd, mtak bylo vše OK. Teď trnu, kdy se zase sekne. TOHLE nebylo!!!! Opakuji. Jen používám LinuxMint - ten pochází z Ubuntu - a ten zas z Debianu. Problém se vyskytl!! Pro sebe si zkouším Manjaro KDE - problem se vyskytl. Jsem idiot já, jak Ty tvrdíš, když používám system v základním nastavení, které zadal tvůrce distribuce???? 3x za měsíc problem se systemd je fak moc. Kdyby to byla jen jedna distribuce, ale sere se to i v jiných distribucí. Můžu prohlásit, když si nainstaluji nějakou distribuci, třeba ubuntu, že se to s určitostí neposere?? Jak mám takovému systému věřit a svěřit tam svá data. Přestal jsem věřit a ty si žij ve svém zamindrákovaném světě, kde je vždy chyba mezi židlí a klávesnicí. Uvažovat o tom, že systemd je neodladěný zmetek, tak to bych po tobě ani nechtěl. Možná že by jsi se seknul, jako se seká systemd.

[eagle.metawerzum]

psal si ze ti schazi ta volnost a svoboda co byla driv, proto sem ti nahore doporucil i LinuxFromScratch, pokud ale naopak hledas predpripravene distro, bez systemd, tak ta prvni varianta co sem psal => Devuan, hotovo, vyreseno. Pokud ale mas problem verit GNU/Linux otevrenemu/svobodnemu systemu, ale nemas problem verit uzavrenemu/nesvobodnemu/smirovacimu W10 systemu, mel bys ty nadavky obratit proti sobe...

[SpFred]

Devuan ASCII mam nainstalovany na troch PC a jednom serveri. Funguje bez problemov. Stabilny, rychly. Plna spokojnost. Na dalsom PC pouzivam AntiX (tiez bez systemd). Bezi tiez bezproblemovo.

[j]

Vubec nejlejpsi ovsem je, kdyz tenhle zvast za reseni oznaci veleblb Jirsak, kterej nema ani paru o tom, jak fungujou i ty nejprimitivnejsi zaklady cehokoli ....

Krasnej priklad:

"Asi je to klasický problém, kdy na NATu dělají jen DNAT, ale ne SNAT – tím pádem paket od klienta dorazí na NAT, přepíše se cílová adresa, paket přijde k vám ..."

https://forum.root.cz/index.php?topic=22177.msg321615#msg321615

Jinak receno, naprosto netusi jak fungujou preklady adres, ale to mu nebrani o tom zvanit.

[Vantomas]

A co je na tom tvrzení špatně?

[j]

Uplne vsechno soudruhu, podej si ruku s Jirsakem ...

NAT (jedno jestli Snat nebo Dnat) kupodivu (velky prekvapeni) asi tak 30 let funguje tak, ze si prekladajici stroj zapise kombinaci IPcek a portu, a samozrejme preklada tam i zpatky, protoze jinak by to nefungovalo vubec. Jinak receno, pokud mu prijde ta odpoved, od stroje uvnitr, tak pozna, ze to je odpoved, prave proto, ze najde v prekladovy tabulce kombinaci portu a IP.

A presne proto to taky rozbiji internet, protoze protokoly, ktery v sobe prenaseji (nebo v prubehu komunikace meni) IP nebo porty proste fungovat nemuzou. Jsou na to ruzny helpery, ktery se to snazej vyresit, ale to prozmenu funguje pouze v pripade, ze protokol neni sifrovanej.

Ve finale, kdybys nemel nastavenej Snat, jak tam Jirsak blaboli, tak se nedostanes vubec na net. A opet, i ten Snat dela ten preklad ve skutecnosti obousmerne, protoze odpoved by ti jinak nemohla dorazit. To je zazracna technologie co?

Jinak receno, pro ty blbejsi: Snat umozni navazat !OBOUSMERNOU! komunikaci smerem zevnitr ven, Dnat umozni navazet !OBOUSMERNOU! komunikaci zvenku dovnitr.

[Vantomas]

Jak může NAT použít conntrack na pakety, který se přes ten NAT nevrací? Ale jako u každýho jinýho soudruha, teorii o DNAT máš nastudovanou pěkně, ale do souvislostí už to dát neumíš a najednou se zjišťuje, že ten tvůj bolševickej grál nefunguje.

[vencour]

Když se odpověď na ten překladovej stroj nevrátí, jelikož kolizní rozsahy nebo jinak blbej či neznámej routing, tak to asi chodit nebude.
Stejně tak když to přijde zpět na překladovej stroj jinym interfejsem tak se zpravidla funkční komunikace neděje.
A samozřejmě nutno dodat že to ani nemusí být cílem, pokud chci jen spoofovat nebo vytěžovat něčí ntp.

[debian+]

Este dopln, ze na zaciatku sa inicializuje na vopred dohodnotuty port (pri HTTP na 80) a nasledne sa prehodi komunikacia u servera a klienta porty v rozsahu 5000+.

Nie je NAT preklad 1:1 a PAT 1:N?

[GeorgeWH]

Co za bludy tu zase pises?! Ake prehadzovanie portov?!

Jsi dost drsnej...

[k3dAR]

[...]Než jste spáchali tu hovadinu SYSTEMD[...]Jel jsem mnoho let bez win, ale teď už tam mám zpět win 10 [...]Nechci zažívat problemy s HDD a systemD.[...]
[linux]Sežrat přes Giga místa na mém disku jen pro log systemd???

nevim jestli se mnozite, nebo si to byl ty co psal (z casti)podobnou hloupost na rootu, ale:
- prejit na W10 kvuli systemd neni logicke, protoze jsou GNU/Linux distra bez systemd, napr. Devuan nebo primo od korene LinuxFromScratch(ten ti dava absolutni svobodu v tom jak si TY poskladas SVOJI instalaci PRESNE podle SVEJCH potreb, od jadra, initu po dostupne sluzby, desktop, programy, tak jak (resp. snadneji) se to delalo v minulem stoleti...
- prejit na W10 kvuli tomu ze init sluzba logujici veskere sluzby/provoz/atd zabere 1GB na disku je uz postavene na hlavu, kdyz ve W10 jsou to jednotky az desitky GB pro logy, predchozi verze programy, instalovane aktualizace + 7GB vyzadujici free na preinstalaci systemu pri (kazdo)pulrocni velke w10 aktualizaci

- prejit na W10 obecne kvuli mistu na disku, kdy GNU/Linux vcetne vsech ovladacu, pres desktop prostredi, aplikace jako kancelarsky balik, www prohlizece, prehravace filmu, programy na upravu fotek si vystaci s 10GB oddilem a v pripade W10 ses na 20GB na holej OS, pridas office, photoshop, ovladace od vyrobce a ses na 35GB, udelas parkat windows update a ses na 50GB...

- W10 stejne jako systemd/journald ma binarni logy, takze ve W10 na tom nebudes lepe, s systemd (pokud tedy nepouzijes rovnou (viz vyse) reseni bez systemd) ale mas stale moznost forwardu logy do sylogu a mit ve /var/log klasicke textove logy...

- GNU/Linux s nebo bez systemd je stale otevreny os, bez spehovacich nastroju, bez vnucovani MSLive uctu, bez odsouhlaseni EULA kterou se v podstate vzdavas vlastnitvi vsech svejch i soukromejch dokumentu, dat, kontaktu, zprav, poznamek, atd...

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

Udivuje mne, že si použil minulé století a ne tisíciletí. Mimochodem, už i v tom minulém tisíciletí byly předpřipravené distribuce s balíčky, aby se nemuselo kompilovat, protože málo kdo měl doma výkon na kompilaci. Takže pokud byl kompatibilní hardware, tak instalace byla opravdu snadnější.

W10 mají integrován poměrně jednoduchý nástroj na vyčištění od toho co vyprodukují. Poslední výroční aktualizace byla zahrnuta mezi běžné aktualizace. Mimochodem linuxová distribuce také nechává nainstalované balíčky na disku. Velikost W10 na disku je dána tím, že sebou tahá spousty věcí. Více, či méně není problém pustit aplikaci pro W98. Zkus něco takového na linuxu a uvidíš, jak to začne žrát prostor.

U W10 alespoň hned víš, že jsi v prdeli. Linux se mnohdy tváří, že to tak černé nemusí být a přitom ve výsledku je na tom stejně, jen déle trvá, než se na to přijde.

S tou otevřeností bych byl opatrnější, ano lze nainstalovat čistý linux, ale lze přidat i různé softwareové zdroje a pak mezi Linuxem a Windows už nemusí být tak velký rozdíl.

Toto není obhajoba Windows !!!

[k3dAR]

samozrejme ze v minulem stoleti byli predpripravene distribuce s balicky, ale ta predpripravenost byla jina nez dnes, vyzadovala aby uzivatel pred a/nebo pri a/nebo po instalaci projevil nejake znalosti, pri vyberu balicku, priprave/uprave konfigurace, atd... primarne mi ale slo o to poukazat na i dnes moznost jit cestou pripravy a vyberu absolutne vsech komponent dle pozadavku uzivatele...

W10 maji sice nastroj "Vycisteni disku" ale nemaze rozhodne vse, treba winsx musis mazat rucne v prikazovem radku pomoci nastroje dism, v kontextu stiznosti "frufru" je ale zasadni to ze u W10 system "provozem" sezere na disku 10x vice mista...

S tou otevřeností bych byl opatrnější, ano lze nainstalovat čistý linux, ale lze přidat i různé softwareové zdroje a pak mezi Linuxem a Windows už nemusí být tak velký rozdíl.

pokud myslis ze do Windows pridas opensource SW, jako Firefox, VLC, LibreOffice, tedy stejne opensource SW jako mas v GNU/Linuxu, tak tim samozrejme nezacne byt zaklad/os otevrenejsi...
pokud myslis ze do GNU/Linux pridas nejaky closedsource SW, tak tim se take nestane GNU/Linux zaklad/os uzavrenejsi...

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

samozrejme ze v minulem stoleti byli predpripravene distribuce s balicky, ale ta predpripravenost byla jina nez dnes, vyzadovala aby uzivatel pred a/nebo pri a/nebo po instalaci projevil nejake znalosti, pri vyberu balicku, priprave/uprave konfigurace, atd...

Corel Linux nic takového nevyžadoval.

primarne mi ale slo o to poukazat na i dnes moznost jit cestou pripravy a vyberu absolutne vsech komponent dle pozadavku uzivatele...

W10 maji sice nastroj "Vycisteni disku" ale nemaze rozhodne vse, treba winsx musis mazat rucne v prikazovem radku pomoci nastroje dism, v kontextu stiznosti "frufru" je ale zasadni to ze u W10 system "provozem" sezere na disku 10x vice mista...

Primárním důvodem stížnosti nebyla velikost, ale nepovedný upgrade systému.

S tou otevřeností bych byl opatrnější, ano lze nainstalovat čistý linux, ale lze přidat i různé softwareové zdroje a pak mezi Linuxem a Windows už nemusí být tak velký rozdíl.

pokud myslis ze do Windows pridas opensource SW, jako Firefox, VLC, LibreOffice, tedy stejne opensource SW jako mas v GNU/Linuxu, tak tim samozrejme nezacne byt zaklad/os otevrenejsi...

Ano, uzavřenost sytému to zcela znemožňuje.

pokud myslis ze do GNU/Linux pridas nejaky closedsource SW, tak tim se take nestane GNU/Linux zaklad/os uzavrenejsi...

Právě díky jeho otevřenosti není problém jej uzavřít a klidně to může spáchat jeden uzavřený program a pár závislostí z daného zdroje navíc, nevidím to jako neproveditelnou záležitost.

[k3dAR]

- CorelLinux sem nezkousel, ale nepredpokladam ze by v te dobe nebylo potreba NIC donastavit pro bezne pouzivani, kazdopadne to porad neni o pointe, coz bylo, i dnes lze sestavit distro od prvniho po posledni balicek rucne, pokud nekomu nesedi to co mu nejaka distribuce pripravi...

- vidim v "dotazu" 3 body a 2 z nich obsahuji stiznost na misto/velikost_na_disku

- kdyz do GNU/Linuxu pridas closed-source program, tak se nestane jadro, gnu, desktop uzavrenej... nevim co resis

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

Tady fakt už není o čem diskutovat. Protože argumenty typu nezkoušel jsem, nevěřím, 2x vidím, řešíš. Jsou naprosto o ničem.

[k3dAR]

ano, v minulem stoleni sem CorelLinux nezkousel, to se zacit cestovat v case nebo co ? "neverim" sem nepsal...
2x vidim si asi nepochopil, tak se znovu podivej do #0 ze pise o problemu s mistem/velikosti...
souhlasim ze je to o nicem, protoze kazdej asi cteme i mluvime o necem jinem

[Heron]

nepredpokladam ze by v te dobe nebylo potreba NIC donastavit pro bezne pouzivani

V té době (1998) jsem zkoušel Live distra Suse a RHEL z časopisu Chip a skutečně nebylo nic potřeba nastavovat. Jako tehdy totální začátečník (v Linuxu) s nadšením zkoušet nové věci jsem to bez problémů nainstaloval a provozoval. Ono ale záleží, co si člověk představí pod pojmem NIC. Ono tehdy i na instalaci DOSu musel člověk něco umět a nainstalovat Win NT včetně všech ovladačů také chtělo znalosti. Ale ve srovnání s jinými produkty té doby nebyla instalace linuxu o nic náročnější než nainstalovat cokoliv jiného. A toto srovnání se prakticky nemění. Letos v létě jsem zkusil nejnovější Ubuntu a vypadá to jako instalátor Win 10. Je to zcela automatické a pokud člověk nechá výchozí instalaci, tak jediné na co se to ptá je uživatelské jméno a heslo a výsledkem je uživatelsky použitelný produkt. Další programy si i začátečník snadno nainstaluje z "app store" vlastně stejně, jako je to zvyklý dělat na mobilu.

[frufru]

Přílohy:

• rh51.jpg (81197 bytů)
• rh71.jpg (94290 bytů)

Já měl prvni distribuci Slackware a pak RedHat 5.1. Další byla RedHat 7.1. U všeho se muselo kompilovat jádro pro konkrétní(můj) HW. Měnit disstribuci jsem přestal až po uvedení Ubuntu. Bohužel Gnome3 a přechod Ubuntu na Unity mě přinutil zase měnit distra. Skončil jsem LinuxMintu a ten je tam do dneška. Výpisy log souborů nemám a nedělám. Stejně si to musím zpravit sám anikdo mě nepomůže. Výpis samozřejmě zkontroluji a pak se to snažím opravit. A vždy jsem to rozchodil. Ale dvakrát zhroucený linux za jeden měsíc na dvou různých PC je fak dost. Hw problem to nebyl. Koukal jsem na ten devuan, ale nelíbí se mi, že je založená na debianu 9. Tak jsem zatím stáhnul na zkoušku MX Linux. Ten je taky bez systemd.

[rastos]

To máš trest Boží za to, že si odišiel od Slackware-u

[frufru]

Jinak tuto distribuční turistiku po pravdě nechápu Vlasně nejsem zas velký turista. Měl jsem dlouho Ubuntu. Asi od 6.06. Po zavedení Unity LinuxMint do teď. Turistiku provozuji proto, že jsem instaloval pár linuxů lidem, které jsou v důchodovém věku. Hledám Náhradu za Linuxmint. Občas prostě nezvládne korektně přejít na nové vydání a jdnou za dvě vydání kompletně preventivně přeinstaluji na čistý system. Většinou to používají na internet, mail, psaní a tištění dopisů a sem tam jednodušší hry. Teď zrovna bude končit podpora win7 a zase se zvedne zájem o nahrazení za updatovaný OS. Mám vyhlídnuté manjaro, ale teď se to během měsíce 2x pos..o startování se systemd. Pokaždý jiný system. Proto jsem docela rozladěný, že se to stane na dvou nezávislých distrech. Požadavek je, aby se to podobalo winxp/7 apod. Šlo tisknout a co nejméně se to sekalo.

[PL]

Hledám Náhradu za Linuxmint. Občas prostě nezvládne korektně přejít na nové vydání a jdnou za dvě vydání kompletně preventivně přeinstaluji na čistý system. Většinou to používají na internet, mail, psaní a tištění dopisů a sem tam jednodušší hry. Požadavek je, aby se to podobalo winxp/7 apod. Šlo tisknout a co nejméně se to sekalo.

Jak jsem psal níže. Debian Stable s XFCE.

Před 14 dny jsem instaloval další Lenovo T420 pro 75 letého důchodce, který je totální antitalent na počítače. Antitalent ani není správný výraz, je to k posrání s ním cokoliv řešit/vysvětlovat.

Na Internet, mail, psaní a jednodušší hry je to ideální. Nepodobá se to Windows XP, starší lidé to neřeší, tak za den si toho přechodu ani nevšimnou, stačí jim ta rutina "klik na ikonu prohlížeče, klik na seznam email přihlásit, klik na ikonu hry".

A protože je to čistě soukromý počítač, kde se nic neplatí přes bankovnictví, e-mail je ve stylu "napíšu Marušce, jak se má" tak ve finále není potřeba instalovat ani ty bezpečnostní aktualizace a nic se nestane a i kdyby se stalo a někdo se do PC naboural, tak se opět nic nestane, protože tam nic není. Je to úroveň veřejného terminálu.

A když se jednou nainstaluje a nic se neaktualizuje, tak se nemá (kromě HW) co podělat.

[Heron]

Já jsem nikdy jádro nekompiloval. V minulé práci (2007) jsem instaloval desítky strojů na různém HW a nikdy nebylo potřeba nic kompilovat, všechno běželo. Tehdy nový CentOS 5. Některé servery, bohužel, běží dodnes, protože někdo roky ignoroval moje varování, že EOL je v 2017. Jediné, co jsem na produkčním stroji na linuxu ručně kompiloval, byl ovladač k síťovce, nakonec naštěstí vyřešeno výměnou hw.

Jinak tuto distribuční turistiku po pravdě nechápu. Všude je stejný software, stejné systémové utility a jediné, co se mění, jsou distribuční skripty od autorů distribuce. Já jsem (krom pokusů v roce 1998), začal na Fedoře, potom přesel na CentOS (což není ani přechod) a potom na Debian. CentOS a Debian je paralelně vedle sebe na produkčních serverech. Soukromě ještě používám od roku 2015 FreeBSD.

Bohužel Gnome3 a přechod Ubuntu na Unity mě přinutil zase měnit distra.

Ehm? Grafické prostředí se dá snadno změnit. Na desktopu mám Debian, ani nevím, co tam je jako default a je mi to úplně jedno, používám i3wm. Takže jestli je tam vedle toho gnome3 a unity je mi fakt jedno, nemám to nainstalované. Zkrátka mi to přijde jako velmi zvláštní důvod ke změně celé distribuce.

[Matlák]

Jo, to jsem tady kdysi v nějaké diskusi přirovnával k tomu že člověk vymění auto protože má špatně nastavená zrcátka.

[eagle.metawerzum]

to je dobrý, to s dovolením, přebírám do repertoáru

[Karel Benák]

Hele, LinuxFromScratch vážně nedoporučuju, pokud nemáš moře času. Jo, máš kontrolu nad systémem a jako bonus budeš vědět snad o každé binárce na disku. Ale pro obyč. uživatele nebo na servery fakt ne!

[k3dAR]

vsimni si ze sem doporucil Devuan jako par-click-install distro bez systemd... zminka o LFS byla ciste proto ze "tazatel" si stezuje co mu RedHat predpripravi a ze nad systemem jiz nema kontrolu "jako driv", logicky tedy je LFS moznost mit "absolutni" kontrolu nad "vsim"...

[ewew]

Namiesto toho aby si dodal požadované logy tu hlásiš, že ako je systém na nič.

• Plný log signalizuje problém. Linux Mint nepoznám ale určite to hlási nejaký hw problém. To že systém po aktualizácii nenabehol môže signalizoať nejaký problém s hw pri zmene jadra. Neviem čo tam je za hw ale pravdepodbne to budú niečo čo nie je zrovna kompatibilné. Skôr to vyžaduje nejaký špecialný firmvér.

• Jednoducho je tam nejaký problém, ktorí stále pretrváva a je nutné to riešiť.

• Nerozmýšlal si, že prečo to asi padlo ? U linuxu to máš aspoň šancu zistiť u iných nelogujúcich systémoch to nemáš ako. čo sa týka miesta a znova je tu potvrdené, že kritizované rozdelenie disku je vhodnejšie na zabezpečenie chodu systému. Zaplnenie miesta kde sú uchované logy /var/log nespôsobi zlyhanie systému.

BTRFS a podobné súborové systémy majú nevýhodu v tom, že sú dynamicky alokované a ak dôjde k narušeniu štruktúry, tak obnova je skoro nemožné. Pritom pri staticky alokovaných súborových systémoch je šanca na obnovu pomocou programov obnovujúcich súbory na základe hlavičky.

[frufru]

Nečetl jsi dobře. Já tam BTRFS souborový system nemám. Celou dobu jedu jen ext4. Ale system po updatu na jádro 4.15.0.70-generic si usmyslelo, že ho tam mám. Je zajímavé , že jádro 4.15.0.69-generic nastartovalo. Opakuji, jednalo se o LinuxMint 19.2 na ext4. Proč tam systemd cpal BTRFS. Co se týká zasílání logů. Do te jsem se nesetkal se zamrzáním, restartem sezení - třeba i několikrát a hlavně nemožnosti nastartování systému. Vždy běželo vše ok. Ani mi nenapadlo udělat ty logy. Sory. prostě jsem je nikdy nepotřeboval. Vše jsem rozchodil k mé spokojenosti a jak linuxmint, tak manjaro jedou. Jde o to, že už tomu nějak nevěřím. Jen jsem si postěžoval, že toho je za jeden měsíc nějak moc.

[k3dAR]

zadne aktualizovane jadro natoz systemd ti nikam btrfs necpalo, POUZE se ti zobrazila hlaska ze probehla ("nejaka") funkce zjisteni/detekce btrfs, ktera nemela vliv na nenastartovani, pouze to byla posledni hlaska ktera se (s vychozi urovni logovani/zobrazovani) zobrazila na obrazovce... sice sis postezoval ale v 90% nevhodne, s temi W10 si te nesmyslnosti uz dal jen "tresnicku", viz jak sem psal okolo, prispevky kterejm reakci se vyhejbas

[frufru]

Tak jsem se kouknul do logu. Třeba dnes systemd šahal/posíla něco na net? ::: session uid=xxxx pid=xxxx] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.64' (uid=xxxx pid=xxxx comm="nemo /media/xxxx/Nov?? svazek " label="unconfined") a to 30 listopadu 4x 15:48,1x 15.56,2x 17:04, 2x 17:13,1x 23:09 a konečně teď 0.29 Co všechno o mně zasílá!!!! Asi půjde LinuxMint pryč. Proč zasílá SYSTEMD něco do netu? O tom mám rozhodovat já a ne systemd. Taky Vám zasílá bez vašeho vědomí něco do internetu? Není to přes čáru? Já to neovládám, ale systemd si dělá co chce.

[frufru]

https://fossies.org/diffs/systemd/238_vs_239/src/hostname/org.freedesktop.hostname1.service-diff.html

[tomvec]

Myslíš že org.freedesktop.portal.Desktop je adresa někam do internetu?

[Heron]

To není URL, to je identifikátor služby v dbus. Je poměrně běžné, že se hierarchie odděluje tečkou a je poměrně běžné, že se používá reverzní url like zápis. Třeba moduly v javě cz.heronovo.utils. atd. Totéž odkoukal i golang, kde už je to přímo ve formě url na git, kde lze daný balíček stáhnout a go tools s tím umí pracovat (třeba github.com/google/goexpect). To, že je někde vypsaná nějaká url (což v tomto případě ani není), vůbec neznamená, že se něco někam odesílá.

[debian+]

Nazov organizacie alebo obratena URL spolu s nazvom projektu sa niekde pouziva ako jednodznacny identifikator, ktory isto nebude kolidovat s inymi.

[debian+]

Model server/klient sa pouziva aj na jednom pocitaci (ako predavanie dat). V linuxe je ich dost, vid. ktore pocuvaju ako server na Tvojom pocitaci:

netstat -l

[k3dAR]

Tak jsem se kouknul do logu. Třeba dnes systemd šahal/posíla něco na net? [...] org.freedesktop.portal.Desktop [...] Co všechno o mně zasílá!!!! Asi půjde LinuxMint pryč. Proč zasílá SYSTEMD něco do netu? O tom mám rozhodovat já a ne systemd.

uz ti bylo napsano ze to neni nic o posilani do netu, neni to internetova adresa, jde o dbus... ptestanes tedy uz hystercit?

[tomvec]

Nepíšeš nic o tom, co je to za HW, jak je starý, jak opotřebovaný. Třeba to má málo RAM, při instalaci jsi nepovolil swap, nebo to má swap do malého souboru. Možná je chycený disk, kabel, řadič... Nepíšeš jestli jsi tam něco nestandardního doinstalovat (třeba ve flatpaku)...

[Heron]

Sorry, ale nic z toho nevypadá na chybu systemd. 1 a 3 vypadají spíše na chybu HW, nebo nějakou nespecifikovanou chybu v konfiguraci.

Dvojka není chyba. Logy mohly být velké i před systemd a 1GB není zase tak moc, k vůli tomu bych nepoužíval vulgarismy. Navíc je to otázka distribuce, některé mají persistent log vypnutý úplně, některé tam mají nastavenou max. velikost. Pokud máte problém s tím, že 1GB vám vyčerpá veškeré dostupné místo na systémovém disku, tak to máte špatně rozdělené. Mít 1GB volného není příliš mnoho a ve skutečnosti můžete narazit na problém s instalací balíčků nebo update, kdy nebude na disku místo pro stažené balíčky a jejich rozbalení.

[debian+]

Co sa tyka logov. Niekedy sa nemazali. Dnes (Debian) sa logy mazu stare ako 1 mesiac (to viem isto u prikazu last). Na velku velkost si trebalo davat pozor na serveroch (ked sa velky klienti dotazuju).

Asi si este neskusal pridavat sluzbu po starte vo Windows.

[frufru]

AMD Phenom II X4 955,GA-870A-UD3, 8GB pamet,NVIDIA GP107 [GeForce GTX 1050 Ti], 2x 120GB ssd (system) 2x 2TB data. To zas tak španý počítač není.Jinak sytemová hlášení má záznam o pádu systemu a chce nainstalovat systemd-coredump no nic. Jdu se v tom vrtat, než tam dám debian.

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

Pokud nadáváš na systemd, pak změna z mintu na debian asi nebude to pravé ořechové.

[frufru]

Ono je to stejně jedno. Řešení 2× (Gréta, Filip Jirsák) , udělal za mne. Možná bude problém mezi židlí a klávesnicí. Vtip je v tom, že systemd je zmetek a lidé s ním mají problemy. Chápu, že do budoucna je třeba něco sjednotit. Ale přidávat do stabilních distribucí neodladěný šmejd se nemá. Chování RedHatu mi připomíná firmu Microsoft. Tam proběhne aktualizace a pak se řeší prusery. Zákazník testerr to odladí. Linuxová komunita vždycky vzdychala, proč se více nepouužívá linux doma. Asi je někde chyba, když po obyčejné aktualizaci nejde nastartovat linux. A poslední záznam je, že hledá souborový system BTRFS, kterýtam ani není nainstalovaný. S tou velikostí log záznamu máte pravdu. Místa je dost, ale co kdybych to zkoušel na některém embendet systemu s málou úložnou pamětí. Máte pravdu. Co kdyby je spekulace a tak je normálnání že se to rozlejzá po disku. A poslední spadnutí jsem taky zařídil z prostoru mezi klávesnicí a židlí. Zavaděč systemu na mě řval systemctl a žádal root heslo jen proto, že jsem se nepomodlil a usednul do profláknutého linuxového místečka "Možná bude problém mezi židlí a klávesnicí", které místní linuxové guru doporučují jako řešení pro ostatní uživatele linuxu -> plebs. Už jednou jsme jako uživatelé protestovali proti zavedení Unity do Ubuntu. Úplně stejně jsme dopadli. Ty dnešní odpovědi se vůbec neliší od toho, co jsme slyšeli tenkrát.Když se dneska kouknu na Ubuntu, tak se mi chce brečet, kam to dotáhli. Teď se to opakuje s firmou RedHat. Pánové svobodní vývojáři, jste tak zaslepení, že jste si ani nevšimli, že vám korporace linux ukradli a Vy už s tím nic nenaděláte. Ta menšina je umlčena výpady typu "Možná bude problém mezi židlí a klávesnicí" Co se stane s programy, které se plně přispůsobí systemd. Půjdou spouštět bez systemd? Proč tady něco plkat, když už si většina korporátních firem vybrala. Jdu odpojit ten problém mezi židlí a klávesnicí, Abych Vás tady nedáždil. Už tady psát nebudu.

[k3dAR]

uz sem ti to psal vejs, nainstaluj Devuan, coz je "fork" Debianu bez systemd....

Náš administrátor shledal tento komentář závadným.

Takhle ne

Zobrazit komentář

[k3dAR]

do ted sem si myslel ze ses jen neschopnej, ted chapu ze jsi jen tro(t)l

[frufru]

Drž hubu Tak to nejsem já! Nějakej chudák se vydává za mě. Tady když se něco nelíbí, tak se zaněj začnou vydávat. Ubohé

[k3dAR]

je-li to tak, ma to jedine (za to snadne) reseni, zaregistruj se a pis pouze prihlasenej

[Radovan]

To mas fuk, K4d4k si chce jen zanadavat

[debian+]

Ak si da stable, tak bude mat najmenej problemov, kedze otestovane. Predsa len, je najrozsirenejsie resp. na nom postavene distra.

[rastos]

Nitpick:

System windows má plno placených testerů, kteří při každé aktualizaci trnou co se všechno pokazilo.

Nemá.

[frr]

Když o krok poodstoupím:

Systemd na Debianu. Zezačátku nabuzen veřejným míněním jsem měl chodidla v pěst, ale když jsem to poprvé viděl nabootovat (během pár vteřin), pochvalně jsem zamručel. Pak jsem asi dvakrát narazil na "zádrhel v systemd", obvykle na strojích s nějakou historií dist-upgradů... a v obou případech jsem zjistil, že se jedná o zádrhel okolo mé specifické konfigurace, kterou jsem kdysi cosi natvrdo zadrátoval, a problém byl mezitím vyřešen elegantněji a univerzálněji, akorát ten můj hrobeček kdesi hluboko uvnitř jaksi přežil a teď dělá neplechu... Člověk se furt učí. Osobně na systemd už nevrčím apriori. Možná je to díky "uleželosti" Debianu stable = nepřejímá bleeding edge upstream, ale točí starou ozáplatovanou verzi.

Ač původně kdysi redhatista, už mnoho let se poloamatérsky starám o pár porůznu Debianů, někde cca od verze 4-5. Některé z nich postupně updatuji, jiné jsem instaloval z čisté vody, různě je stěhuju na novější hardware, páchám různé dočasné instalace ke svobodnému prasení, teď si třeba hraju s netbootem (včetně lehkých úprav initrd skriptů), předtím s read-only rootem... Protože jsem lenoch, často na produkční stroje instaluju "o krok starší" verzi (old stable) abych se vyhnul dětským nemocem poslední verze. Což někdy znamená, že schytám staré známé bugy, které už nikdo neopravil No právě - aspoň jsou zdokumentované.

Člověk se furt učí. Třeba pro blbnutí s diskless bootem je výborné, že už nepotřebuju /etc/network/interfaces. Naučil jsem se, napsat primitivní systemd konfiguráčky pro moje vlastní servisky nebo různé ohavné hacky při bootu. Třeba když jsem potřeboval víc instancí OpenVPN démonka, každou instanci s jinou konfigurací, bylo to jednodušší a čistší než postaru se sysV init, protože pro tenhle "scénář" má systemd v konfiguraci explicitní "syntactic candy". Nebo když jsem si vzpomněl, že chci dle okamžitého rozmaru volit boot do X nebo do textového režimu, po prvním smutku "no jak tohle zařídím pod systemd" jsem díky Googlu obratem s úžasem zjistil, že na to je zcela základní systemd-oidní finta na kernel command line... Stejně tak blbutí se síťovinami a mountováním kořenového svazku v rámci initrd skriptů vypadá zatím v pododě, podle mých prvních poznatků systemd prostě převezme to, co najde při svém startu... = u mě dobrý, zatím jsem nenarazil na nic, co by mě vytočilo doběla.

[dustin]

A upgrade serveru z non-systemd oldold...stable na systemd stable verzi je OK? Díky.

[frr]

Mám za sebou tuším 1-2 takové přechody a popravdě mi lezly oči z ďůlků z jiných věcí, než je zrovna init/systemd. Matně si vybavuju změny v podporovaných databázích snad v Cyrusu (Berkeley DB vs. něco nového) apod. Ale tohle se děje průběžně v různých oblastech. Třeba Samba taky pravidelně trochu inovuje konfiguraci a chování. Kdysi dávno jsem řešil konverzi znakových sad češtiny v názvech souborů ve filesystému. Nebo mě jednou napálil Cups... Obecně u dist-upgrade je lepší šance, že přechod proběhne v pořádku, pokud je cílová verze distra už taky na vysokém "patchlevelu" - nebo že aspoň najdu popis řešení někde v internetech.

Obecně při těchto přechodech je fajn, zazálohovat si původní stav, aby bylo kam se vrátit, když to neklapne. Což je trochu hraběcí rada, protože snadno se zazálohuje OS (bootovací disk), ale když jako součást upgradu nelze vyloučit změnu formátu uživatelských dat, třeba pár set GB mailů... tak vlastně řešíte napřed průběžnou zálohu těch uživatelských dat, případně jejich migraci na novou verzi softwaru, a ten dist-upgrade už je pak jenom taková chutná třešnička na dortu Asi dvakrát jsem místo dist-upgrade provedl čistou novou instalaci a explicitní migraci dat ze starého systému na nový - jednou když jsem měl pocit, že toho nabaleného starého dědictví je už moc, podruhé jsem stěhoval něco archaického ze stroje s IDE a paralelní PCI na hodně nový hardware, co měl už jenom SATA a PCI-e. A než bych to nějak redukoval, nebo stavěl dočasný "košatější" hardware, abych dokázal připojit disky, prostě jsem nainstaloval nový čistý systém a data jsem ze starého odmigroval po síti.

[Heron]

a v obou případech jsem zjistil, že se jedná o zádrhel okolo mé specifické konfigurace, kterou jsem kdysi cosi natvrdo zadrátoval, a problém byl mezitím vyřešen elegantněji a univerzálněji

Ano a toto se až tak moc netýká systemd, toto je tak nějak obecné. Jsou admini (nebo i programátoři), kteří prostě nechtějí zahodit svůj kdysi dávno napsaný a roky už zastaralý program / skript / konfiguraci a přejít na něco nového.

Já, ve své praxi, mám nejraději situace, kdy můžu okamžitě zahodit svůj bastl a nahradit to něčím z repa. Když si něco píšu (python), tak kdykoliv najdu modul řešící můj problém lépe než moje řešení, přejdu na něj. Čím dřív, tím lépe.

Jsou lidé, kteří se mi za to smějí a tvrdí, že mám všechno v defaultu a že jejich (jeden) naprosto dokonale vymazlený systém je lepší. Tak ať si totéž zkusí provozovat na stovkách serverů.

[j]

Takze misto tisiciradkovyho scriptu mas desitky nebo stovky tisic radku knihoven. Jo to je vyhra ...

Asi neco jako kdyz si nainstalujes M$ visual ... napises hello world, prekompilujes to, a ono to ma 15MB (teda ta binarka, ktera ovsem jeste potrebuje dalsich 150MB knihoven).

[Heron]

Jo to je vyhra ...

Výhra to je, protože jednak se o ten program / modul stará někdo jinej a podstatnější důvod je, že to má mnohem více uživatelů, než jen jednoho, takže je to mnohem lépe otestované. Takže místo bastlu jednoho geniálního admina máš místo toho poměrně standardní řešení, které používá kromě tebe ještě další milion+ lidí na světě.

[Ovoce]

v obou případech jsem zjistil, že se jedná o zádrhel okolo mé specifické konfigurace, kterou jsem kdysi cosi natvrdo zadrátoval, a problém byl mezitím vyřešen elegantněji a univerzálněji, akorát ten můj hrobeček kdesi hluboko uvnitř jaksi přežil a teď dělá neplechu... Člověk se furt učí.

Jo, to věřím. To je obecně přítomný problém, Némlich stejné je to myslím i s Windows, tam se to taky sere tím víc, čím víc se to člověk snaží ohejbat, kdežto v posledních letech jak není chuť a čas šťourat, tak mi systém tak stabilně drží až se to bojím nahlas říct...

Ono tohle je nevyhnutelné. Čím víc custom nastavení nebo změn proti výchozí konfirugaraci, tím dál jste od toho, co se nejvíc testuje. Kombinatoricky může v OS v interakci s aplikacema a vším ostatním nastat tolik situací, že to prostě nemůže být odladěný na 100 %. Čím blíž máte systém vanilla instalaci, tím častěji se pohybujete po vyšlapanejch cestách, který byly odladěný.

Samozřejmě když někdo zrovna vrtat a customizovat chce, tak je to pro něj dost nemilé, ale jak říkám, příčiny jsou z části objektivní, takže je to chcaní proti větru a je třeba snížit očekávání a být tolerantní, protože v řadě případů nejspíš dělali co mohli, snažili se, ale holt bugy jsou a některý věci se nedají vyřešit ke spokojenosti všech a musí přijít kompromis. Kolikrát nějaký pro vás problemeatický řešení má produktivní účel a opravuje zase problémy pro spoustu jinejch lidí, akorát holt nebylo možný se vyhnout rozbití pro pár jinejch.

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

W10 můžeš ohýbat jak chceš, s výroční aktualizací ti to vrátí a můžeš začít znova. Ba ne od 2019.3 se naučili některé věci nevracet. Takže snad se to začne konečně zlepšovat.

[KOLEGA]

Ja mam systemd rad, jsem sice mladik, ale sprava systemu se SystemD je logicka a prehledna (urcite pro adminy).

1) Pravdepodobne nekde vadna konfigurace

2) Protoze logy jsou potreba. Bezne je potreba logovat, abys mohl resit, co se pokazilo, co nefunguje a pripadne mohl zadat o pomoc vyvojare distribuce.

3) Tohle urcite vypada na problemy s hardwarem.

Chapu, ze je to frustrujici, ale za tvoje problemy opravdu nemuze SystemD (ani Kalousek).

[zelva]

s/SystemD/systemd/ - https://www.freedesktop.org/wiki/Software/systemd/

[KOLEGA]

Diky :)

[Jendа]

Ja mam systemd rad, jsem sice mladik, ale sprava systemu se SystemD je logicka a prehledna (urcite pro adminy).

Mně to přijde tak napůl (podle profilu jsem stejný mladík jako ty). Některé věci dávají smysl, ale vyznat se v tom a nastavit to tak, aby to spolehlivě fungovalo, je kvůli složitosti dost obtížné.

Příklad z praxe: počítač za devatero NATy, na něm OpenVPN klient, aby se tam dalo dostat. Historické Jendovo řešení z roku 2012: v rc.local se spustil screen, ve kterém se spustilo while sleep 10; do openvpn /root/config.ovpn; done. Pro extra spolehlivost (proces openvpn teoreticky nemusí spadnout, ale může i zatuhnout) byl přidán do cronu watchdog, který spojení zkusil, a když se nepovedlo, udělal killall -9 openvpn. Běželo to 7 let, nikdo na to nemusel ani jednou sáhnout, a subjektivně si troufnu říct, že se na tom nemá co pokazit. Ale bylo to strašně neelegantní.

Proto to bylo migrováno na systemd-way. Byla aktivována openvpn-client@config.service a bylo vyzkoušeno, že to po rebootu opravdu naběhne. A opravdu to fungovalo, napříč rebooty. Jenže pak vypadla elektřina a po tom se to nepřipojilo.

???

Vysvětlení: openvpn-client@.service vyžadoval potvrzení že to opravdu naběhlo (pomocí notify mechanismu). Jenže po obnovení dodávky elektřiny nabootoval počítač rychleji než router, během 90 sekund se nepodařilo připojit (internet začal fungovat až chvíli po tom), systemd to vzdal a unita byla natrvalo failed.

No a takovýchto problémů mám víc. Z nějakého nevysvětlitelného důvodu neelegantní řešení kolem mě fungují, a když se rozbijí, tak se dají snadno opravit, zatímco elegantní systémy s promyšlenou architekturou (systemd, libvirt[*]…) mají nevysvětlitelné problémy.

Možná, že ostatní skutečně dokážou enterprise systémy používat (když se kouknu kolem sebe, tak bych o tom spíš pochyboval). Ale já jsem zjistil, že na to nejspíš nemám mentální kapacitu.

[*] libvirtu se mi nepodařilo zaboha vnutit custom parametry qemu a smazat ty defaultní, aby to mohlo spouštět OS X. U konkurenčního serveru, který místo libvirtu používá sadu shell skriptů, to znamenalo tam ten jeden řádek dopsat.

1) Pravdepodobne nekde vadna konfigurace

Ano, to nepochybně. Ale správně navržený systém má vypsat ladící hlášky (alespoň nějaké - i kdyby vypsal nějaké neužitečné, budiž - nemáme umělou inteligenci), ne se zaseknout a nic neříct. To je doménou jiných systémů, kde se po startu počítače zobrazí okýnko a všichni 20 sekund trnou že to fakt nabíhá.

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

Díky podobným chybám systemd jsem z Debiana Jessie migroval na Devuana Jessie. Důvod byl prostě ten, že různě testovaný systemd nebyl schopen zajistit bezproblémovou funkcionalitu systémů. I když se dnes sem tam rozhodnu nějakou tu distribuci se systemd vyzkoušet, tak do měsíce se ukáže nějaký náhodný režim a zase mne to na nějakou dobu pustí. A je naprosto jedno, jestli je to LTS, Rolling, či úplně něco jiného. Z mého pohledu není systemd stabilní. Bohužel na produkčních strojích stabilitu vyžaduji. Nejdéle to kupodivu vydrželo OpenSUSE Tumbleweed, to padlo až po dvou měsících.

[vencour]

A měl jste nějaký testovací stroj pro ověření nových aktualizací? Abyste rovnou nepadl na ústa?
Sám takhle nejdřív zpracuju aktualizace a nové věci u sebe a pak u ostatních.

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

Ano, mám tu mašinu, která mi simuluje prostředí produkčních strojů, přeci jen už je mi čtyřicet a nejsem takový střelec, jako před dvaceti lety. Ony i ty systémy před dvaceti lety na tom byly se stabilitou trošku jinak. Teď se na všech frontách vymýšlí nová kolečka, která zajišťují stejnou funkcionalitu, ale na úkor stability. Dnes se tolik nehledí na to, co se vypouští. Je to dáno mnohem rychlejším tempem, ničím jiným.

[Jendа]

K tomuto bych jenom chtěl podotknout, že část problémů byla způsobená tím, že přechod na systemd v Debianu 8 proběhl tak, že někdo poloautomaticky vygeneroval unity pro jednotlivé init.d skripty, čímž se spousta věcí grandiózně pokazila (věci co měly být forking/simple byly oneshot, věci nebyly simple ale byl tam wrapper simple na forking + se zjišťoval běh přes pidfile, chyběly různé fallbacky jako v příkladu s openvpn výše, …). Debian 8 a 9 tak byl skutečně z tohoto pohledu peklo -- a nevím, co bych dělal, kdyby v těchto dvou verzích současně nebyl podporovaný snadný přechod zpátky na původní init. Ale postupně se to opravovalo a Debian 10 už je z tohoto pohledu docela použitelný. A už teda nejde tak jednoduše použít původní init (na systemd začala záviset spousta věcí), ale naštěstí to ještě nebylo potřeba.

[bigBRAMBOR]

takze to nebyla az tak chyba systemd ale prasáků z debianu? Ja jsem za centosu nezaznamenal jedinou chybu se systemd. Debian moc neznam, ale v souvislosti s ubuntu, se kterým se potkávám, musím říct, ačkoliv to většina lidí nerada slyší, že je to hrozná srágora, jedno zda server, LTS nebo STS.

[Jendа]

takze to nebyla az tak chyba systemd ale prasáků z debianu?

Ano, ale jakmile použiješ tento argument („nekvalitně udělané unity nejsou problém systemd“), tak už nikdy v životě nesmíš použít argument „sysv init je na prd, protože měl blbě udělané skripty“.

v souvislosti s ubuntu, se kterým se potkávám, musím říct, ačkoliv to většina lidí nerada slyší, že je to hrozná srágora, jedno zda server, LTS nebo STS

Do verze 14.04 bylo Ubuntu srovnatelné s Debianem, od 16.04 je horší, protože začli nasazovat střeštěné novinky (několikrát vyměněná správa sítě (něco, nedotažený netplan, systemd-networkd), snapd, plymouth, …).

[k3dAR]

16.04 sem se vyhnul a s 18.04 nemam problem, na desktopu nechavam nm, na serveru zrusim netplan tim ze nainstaluji ifupdown balicek a pouzivam klasicke /etc/network/interfaces jak na normal lan, tak na bridge i bond...

[Heron]

takze to nebyla az tak chyba systemd ale prasáků z debianu?

Ano, i tak se to dá říct. Debian se na všechno snaží mít vlastní "helpery" a po jejich odinstalování všechno začalo fungovat. Například se debian snažil tvářit, že lze používat systemctl a service současně. Nešlo. update-rc.d nefungovalo snad nikdy (překlad na systemctl enable apod.). Takže řešením bylo co nejdříve se zbavit těchto "helperů" a dělat všechno na systemd (nebo přejít na devuan bez systemd, ale to jsem nikdy nezkoušel). Totéž platí o síti, odinstalovat ifupdown a networking apod. a používat networkd. Jako kdybych věděl, co všechno má debian blbě, tak bych o to rychleji přešel na čistě systemd distro (asi arch linux). Ale zpětně se to hodnotí snadno.

[j]

"No a takovýchto problémů mám víc. Z nějakého nevysvětlitelného důvodu neelegantní řešení kolem mě fungují, a když se rozbijí, tak se dají snadno opravit, zatímco elegantní systémy s promyšlenou architekturou (systemd, libvirt[*]…) mají nevysvětlitelné problémy. "

Tohle pisu uz par let, ze vsechny ty uzasny a genitalni ficury systemd jsou uplne khovnu. Nejen ze nic neresi a nefunguji, ale navic rozbiji to, co roky bez jakyhokoli problemu fungovalo (trebas zrovna ten screen).

BTW: Na vsech serverech mam neco mezi 5-15 minutama delay pred bootem, presne proto, ze to sice je mozna zcela neelegantni, ale zcela funkcni reseni toho, ze ten switch startuje dyl, nez ten server. A protoze i UPSky se spolu chteji bavit, tak sou jeste navic vsechny switche zapojeny jednim zdrojem naprimo, protoze UPSky ze zapnou az se nabijou, ale pokud na sebe po siti mezi tim nevidej, tak to opet nefunguje.

BTW2: Neboj, tux ti taky brzo zacne zobrazovat jen "neco pro vas delame" nasledovane "neco se nepovedlo"

[012]

Bez to tak, že systemd 90-95% spĺňa potreby používateľom, to im stačí. Ak si tá minoritná časť, tak to musíš prijať. Android na PC nepoužíva systemd a ani Tiny Linux.

[j]

systemd nesplnuje pozadavky vubec nikoho. Systemd mel (pry) zjednodusit udrzbu startovacich scriptu, coz se nestalo, a to co bylo predtim mozna slozity, je s tim jeste slozitejsi, protoze jako bonus prestaly fungovat veci, ktery predtim desitky let bez problemu fungovaly.

Neznam zadnyho admina, kterej by byl se systemd spokojenej, zato znam desitky adminu, kterym na jejich stroj nesmi. Cimpak to asi bude ... Dokonce sem osobne videl situaci, kdy si dodavatel trval na distru se systemd, tak mu bylo smluvne ulozeno, ze nese (v desitkach mega) odpovednost ze to, ze system bude funkcni. Kdyz to videl, honem souhlasil s tim, ze to muze byt neco jinyho. Tahle radostna udalost vznikla tak, ze asi mesic pred tim dotceny firme chcipnul provozni stroj ... po aktualizaci systemd (jasne, systemd nemuze za to, ze se zmeni vychozi chovani a jako bonus to neni ani nikde zdokumentovany, za to muze admin ...).

[MP]

Dej si klavesnici pres ruku ty spamovaci lhari.

[dustin]

j je svůj, ale občas s ním souhlasím. Toto je jeden z těch mála případů

[debian+]

Uzivatelom to splna ;)

V pro sfere nekomentujem (nepoznam).

[KOLEGA]

Mas pravdu v tom, ze nektera receni jsou pruzracnejsi, ovsem managovat pak takove systemy jako nove nastoupivsi admin je peklo. Protoze ti bezi tuny screenu, tmuxu, podle toho, co kdo ma rad a ty netusis, jak se to ma chovat, jak pracovat s upgrady a tak.

Vyhodou unit je taky to, ze jsou trochu self-documentating.

Journal mi prijde jako naprosto skvelej, pomerne snadno dohledam vzdy co potrebuji a diky hledani po unitach a case to jde celkem rychle. Kazdopadne diky za postrehy

[Heron]

+1

Naprosto správný postřeh. Navíc je tady ještě další komplikace, že admini, kteří jsou hrdí na své komplikované skripty, tisíci řádkový rc.local, všude naspawnované screeny na služby apod. mají ještě zásadní odpor k psaní dokumentace. Takže nejen, že je ten jejich výtvor často napsaný prasácky a šlo by to udělat lépe (i bez nenáviděného systemd), ale ještě navíc o tom nikde není ani čárka dokumentace. Ani o tom, že tam nějaká taková služba vůbec běží.

[j]

"Journal mi prijde jako naprosto skvelej"

jj, nejskvelejsi na logovani je, kdy zadny logy nejsou. A kdyz uz cirou nahodou jsou, tak je na jejich precteni treba pouzivat nejakou silenou binarku, protoze grep je pro nektery "takyadminy" sprosty slovo.

[KOLEGA]

Problem s grepem je ten, ze na velkejch datech zacne byt pomaly, btw. pokud tu touhu clovek ma, muze samozrejme nakonfigurovat logovani do souboru. Ubuntu 18.04 to tak dela, ze spoustu dat sype i do syslogu. Prace se journalem je rychlejsi a samozrejme na to grep jde taky nasadit. Ale nemuset grepovat unitu a datum je velke zrychleni.

Samozrejme chapu tvoji vytku, ze data jsou binarni.

[Heron]

Příklad z praxe: počítač za devatero NATy, na něm OpenVPN klient, aby se tam dalo dostat.

Nevím, proč to dělat takto. OpenVPN klient má parametr resolv-retry infinite. Používám to roky. Takže klient naběhne a potom se donekonečna snaží o připojení. Internet si může v průběhu služby padat jak chce, ono se to po chvíli opět připojí. No a potom stačí mít watchdog na běh samotné služby (která mi teda nikdy nespadla, ale náhoda je blbec) a to lze udělat i v systemd. A klidně i tam nastavit nekonečný počet opakování.

Vysvětlení: openvpn-client@.service vyžadoval potvrzení že to opravdu naběhlo (pomocí notify mechanismu).

To vypadá na špatně napsanou unitu (což není nijak vzácné). Nebo zná někdo důvod, proč tam to notify bylo?

[Jendа]

Nevím, proč to dělat takto. OpenVPN klient má parametr resolv-retry infinite.

Ten tam mám samozřejmě taky. Osobně si myslím, že to openvpn snad nikdy nespadlo ani nezatuhlo.

Ale parametr resolv-retry infinite toto neřeší, protože openvpn klient pošle i s tímto parametrem notifikaci až po prvním úspěšném připojení: které se nestane pokud do 90 sekund od bootu nefunguje internet.

To vypadá na špatně napsanou unitu (což není nijak vzácné). Nebo zná někdo důvod, proč tam to notify bylo?

Ano, samozřejmě, že to byla špatně napsaná unita - alespoň pro tento účel. Příklad měl ilustrovat, že dle mého názoru větší složitost systému vede k tomu, že můžeš přehlédnout nějaké důsledky a pak tě překvapí.

[Heron]

Příklad měl ilustrovat, že dle mého názoru větší složitost systému vede k tomu, že můžeš přehlédnout nějaké důsledky a pak tě překvapí.

Tak otázkou je, jestli je složitější. Já mám obecně rád, když se věci dělají standardním způsobem a celkem dlouho jsem naivně věřil, že když lidé budou znát, jak věci fungují, tak snadněji pochopí, proč se věci mají dělat právě takto. Jenže v realitě to nefunguje skoro nikde a bez norem bychom se prostě neobešli. (Tohle myslím obecně, viděl jsem mnoho elektrikářů, kterým bych nesvěřil ani zapojení stolní lampy a jediný bič je na ně norma.)

Proto i v IT mám rád systémy, které nedovolují příliš velkou kreativitu a spíš vedou uživatele tou nejlepší a nejjednodušší cestou. Neříkám, že systemd je tato cesta, podle mě toho dovoluje až příliš moc. Kdyby se víc tlačilo na to, že všechny služby budou typu simple (což by v zásadě měly být i v sys v, kde se to jen obalí nějakou formou odpojení od terminálu), tak by to bylo lepší, než vymyslet 150 typů služeb, které bude systemd nějak managovat.

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

Včera se mi dostal do ruky počítač s windows a chrome. Ani jedno nemusím, ale všiml jsem si, že 64bitový chrome se nacpal do program files (x86). Řekl jsem si fajn, odinstaluji ho a nainstaluji do správného umístění. Chvilku jsem to zkoušel, ale pak jsem ho nechal tam, kde je. A člověk by si řekl, že je to taková maličkost, avšak těmi maličkostmi to začíná.

[Heron]

Moc nevím, jak to souvisí s tématem, ale ano, všiml jsem si, že některé programy ve win jsou mixem 64b a 32b (více binárek ve stejném instalačním adresáři s různou bitovostí) a jak funguje umístění do Program Files / (x86) je asi věcí instalátoru, ale neřeším to. MS se rozhodl jít cestou mixu 64+32, je to jeho problém. Spíše mě děsí, kolik nových programů je stále distribuováno jen jako 32b. A kolik věcí má 32b launcher a 64b program (což je pořád lepší než naopak, ale divím, se, proč to kompilujou různě).

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

Ano, to je také zarážející. Dokonce jsem potkal program, který v 32bitu byl zdarma a za 64bit chtěli zaplatit ... někdy ty pochody jsou fakt nepochopitelné.

[lertimir]

No já si pořád za ta léta, co sem chodím myslím, že toto se jmenuje poradna. Jenže ty nic poradit nechceš. Jenom jsi sem přišel prskat. Ani v tom předchozím vlákně ani tady jsi nikdy neposlal přesný výpis z logu ze systému, který má u tebe problém, aby mohl kdokoliv ti jakkoliv poradit. Nic víc než nadávání na to, že je to jinak než bylo. Ano je.

A podobně jak jsem ti psal v minulém vláknu, je to trochu jako z auty. Žádné už nemá karburátor a sytič, ve všech je spousta elektroniky a pokud do auta neodborně hrábneš tak nemusí vůbec jet.

Pokud chceš žít na Win10 je to naprosto v pořádku. Ve firmě nedávno zvětšovali prostor na systémovém disku C: (kde mají uživatelé jen systém) z 150GB na 190GB, protože některé aktualizace havarovaly. Je to také možná a použitelná varianta a přeji ti ať tě baví více než linux a pak tady nemusíš trolit.

[PL]

1/ Tchán má nainstalovaný LinuxMint 19.2. V linuxu se nevyzná, ale aktualizaci přes správu aktualizací zvládne. Nic neinstaluje, jen prohlíží internet a sem tam si zahraje karetní hry.

Něco podobného jsem řešil u rodičů (72 let) počítači nepolíbená generace. Na notebooku windows 10 co byly u něj, po roce používání stylem Firefox + aktualizace Windows z toho byl šnek co startuje 5 minut, minutu se načítá Firefox...hrůza. Pořád jim to čistit CCleanerem apod. mě lezlo na mozek.

Koupil jsem repasované Lenovo T420, dal tam SSD, nainstaloval Debian stable + XFCE a jediné co dělám, že s nimi můžu zase normálně mluvit po telefonu, aniž bychom řešili počítač a problémy. Když jsem to instaloval, čistý systém po instalaci startoval 11 sekund, po 14 měsících používání startuje 11 sekund. Žádný bordel v PC, v prohlížeči, nikde. Stabilní bezproblémový systém a systemd na to nemá vliv.

Přesně pro seniory a jejich unavené děti, co jim dělají adminy a pro lidi, co chtějí mít klid je Debian stable ideální. Kdo se jen dívá na internet, ten nepotřebuje aktualizovat na nové verze, jen bezpečnostní aktualizace.

Zvaž tedy, zda tchán na internet potřebuje Linux Mint, já myslím, že ne. Potřebuje stabilní distribuci bez aktualizací na internet a ty klid.

Kdybych měl odepsat všechno, s čím mám 3x špatnou zkušenost, tak z heteráka přejdu na buzíka (zklamaly mě 3x ženský), z buzíka na zoofila (zklamali mě 3x chlapi) a ze zoofila na nekrofila (kousnul mě 2x pes a jednou kočka).

[dustin]

Rodiče (též > 70) mají už roky Mint Mate, aktuálně myslím 18 něco, a žádné problémy s aktualizacemi nenastávají. Mám Mint na všech desktopech (doma i ve firmě), zrovna píši na 19.1.

Tím ale nechci obhajovat systemd, jeho geniální defaultní hodnoty mě už párkrát na serveru vypekly.

[Petr Fiedler]

Taky už nějaký ten pátek ke své velké spokojenosti používám Linux Mint.

[lertimir]

Zajímavé. (tedy ty 3 zklamání)

Ale pokud bych zůstal u linuxu, tak bych ještě bych přidal, že z podobného důvodu manželce provozu openSUSE. Průběžně probéhají pouze bezpečnostní aktualizace distribuční aktualizace jednou ročně, špičkový management snapshotů na btrfs, pokud někde něco pokazí (což se už sice moc neděje), tak díky snapshotům je jasná jednoznačná přímočará cesta, jak vybrat v grubu jiný zpětný snapshot a nabootovat z něj, pro klikacího uživatele celkem dost komfortní a dost úplný management systému přes Yast. Navíc Yast má i svou terminálovou formu takže je možné se přihlásit přes SSH a opravit chybu ve stejném prostředí.

Je pravda, že jsem nikdy nepřilnul k debianí větvi a pohyboval se mezi Mandrake, RH, CentOS a openSUSE a v poslední době na Archu, ale věřím, i díky oblibě, že debian a deriváty jsou na tom podobně. Nicméně, pokud 1,5GB dat v logu je důvodem pro tuto bohatou diskusi a navíc ani nepoužití těchto logů při diagnostice a opravě, tak to distribuce se snapshoty není pro tazatele řešení, protože prostoru zaberou snapshoty mnohem více.

[k3dAR]

pokud se nepletu, Debian ani *buntu tuhle (pro uzivatele btrfs jiste neocenitelnou) vlastnost (snadno) nemaji, v Mintu vim ze je nejaky snaphotovaci/zalohovaci? nastroj by default, ale nevim zda s btrfs dela snapshoty a i do grubu, nicmene sem ted za par vterin nasel tohle: https://github.com/Antynea/grub-btrfs, v Archu to je v (neAUR) repositari, do Debian/*buntu pripadne Mint(pokud to nema) to asi neni problem pridat, jde v podstate o 1 pridanej grub script ktere se pousti automaticky pri regenerovani grubu a 1 systemd sluzbu pro rucni spusteni, akorat tedy v zavislosti na distru by bylo potreba pridat skript co se pusti automaticky pro zavolani spravce balicku, pri upgrade/remove/add/atd... pripadne do cron at se to dela samo i treba 1x za den... (nezkoumal sem zda neco uz pplne automatickeho pro deb/apt neni)

[k3dAR]

automatizovat + sprava z terminali i gui, by udajne mohl http://snapper.io/

[lertimir]

snapper je command line utilita na práci se btrfs snapshoty. Ve snapshotech je suse o parník před jinými distry. (což neznamená že jinde nemusí ztrácet, např. ta správa přes YAST je sice super pro začátečníka, ale dost nemá ráda, dkyž se ji hrábne do konfigurací napřímo)

[k3dAR]

snapper sem prave zahlidl nekde u ubuntu+grub-btrfs, ale nebylo jasne bez dalsiho hledani zda je to ono, jen v readme ze umoznuje automaticke snapshoty pri aktalizaci, ale zminene nastroje neobsahovali apt...
openSUSE sem zkousel chvili jen na AC100, projizdel si Yast a na prvni pohled moc pekne, ale tim ze seb deb'ar me to stejne nepresvedcilo na prechod, protoze rpm opravdu nemusim (asi blok z minuleho stoleti :) ale i za tu chvilku sem narazil ze Yast mel problem kdyz sem neco menil sam v /etc...

[lertimir]

Zatím jsem to na Archu nezkoušel, ale popíšu jak to má openSUSE. Jednak provádí automaticky dva druhy snapshotů: Jeden časový (v defaultu každou hodinu) a jednak párový pre/post snapshoty před aktualizací a po aktualizaci. Samozřejmě můžeš nastavit, jak snapshoty odmazávat. V závislosti na tom, jak podstatné jsou aktualizace, tak některé párové snapshoty mají flag důležité a ty mají jiné odmazání.

Z hlediska penetrace do grubu se ti to jednak umožní vrátit se dočasně tím, že bootneš nějaký starší snapshot, nebo přímo v grubu provedeš skutečný "rollback" což způsobí, že se starého snapshotu se stane aktuální systém, všechny pozdější snapshoty a současný se zlikvidují a můžeš od toho staršího snapshotu pokračovat. A dali si práci a mají poměrně rozumně btrfs rozdělené na subvolumes, které v režimu snapshotů nejsou. Když to budeš dělat ručně musíš ty subvolumes rozumně vymyslet také. A potvrzuji, že to opravdu kvalitně funguje, před časem se mi podařilo rozbít manželce systém tím, že jsem si před distribučním upgadem nezkontroloval volné místo, a upgrade totálně krachl na nulový volný prostor. Bootnout kousek starší snapshot, uklidit prostor a provést nový upgrade bylo otázka asi 15 minut, z čehož hlavní čas bylo trochu uklízení a hlavně nový běh aktualizace.

[k3dAR]

chapu ze to ma openSUSE poresene, prave proto sem psal ze Debian/*buntu ne, ale zaroven ze zajimavosti zkusil dohledat zda to aspon nejak jde, to co pises by prave resilo grub-btrfs + skript do apt + pravidlo do cronu, akorat nevim jak delal rollback v grub, coz si poredstavuju jako jen dalsi polozku snapshotu s paremtrem "~rollback" coz taky samodomo by slo resit, pripadne po okouknuti jak to dela openSUSE, kdybych pouzival btrfs, tak to overim na Xubuntu v praxi, takhle jen teoretizuju...

[Petr Fiedler]

A co budeš dělat, až tě 3x zklame mrtvola?

[PL]

A co budeš dělat, až tě 3x zklame mrtvola?

Až mě zklame mrtvola, potom budu za vola.

[Jendа]

Related: Narazili jste už někdy při bootu na 90s, 300s, 900s nebo dokonce no-limit timeout? Co v takové situaci děláte? Proč to nejde klávesou ustřelit? (seriózní dotaz)

[k3dAR]

rikam si proc to neudela takto

[k3dAR]

a uplne nejradeji mam, kdyz cekam az konecne dobehne 90s a ono se to pak po uplynuti prepne na 180s

[🇹🇬]

It is not possible. Systemd is noninteractive.

hele

asi jako jedině zkusit zkrátit ten timeout jak tam pišou a koukat co to udělá. já to u sebe neštelovala a vždycky čekám až to odjede a koukám třeba kolem ;D

[Heron]

Nenarazil. Možná jednou, když nenajela síť, ale to stejně vyžadovalo fyzický přístup k tomu stroji, ssh bylo logicky nedostupné.

Narazil jsem ale na jiné chování, chvíli jsem podezříval systemd, ale nakonec byla příčina jinde a chování systemd považuju za správné. Někdy se mi stávalo, že systém při vypínání čekal na ukončení session-0. A stávalo se to především v situacích, kdy jsem zapnul komp, potřeboval něco rychle udělat (pár minut) a zase ho vypnout (a jít pryč). Tj doba běhu před shutdownem pár minut, nikdy se to nestalo u delšího uptime. Podezříval jsem systemd, ale ne, on to byl BackupPC, který si pingá stroje a když zjistí, že je up, tak ho začne zálohovat. A to přesně byla ta session-0. Tam je timeout delší než 90s. Ale záloha se dokončila dřív a systém se normálně vypnul. Což považuju za lepší stav, než tu zálohu killnout, jak by se to stalo u sysv initu.

[Jendа]

Nenarazil.

Zajímavé, tak to mám na používání systemd asi opravdu nedostatečný intelekt. Třeba se mi stalo, že jsem dal do počítače nové PCIe zařízení, čímž se přečíslovaly unpredictable interface names, a čekalo se na síťovku wmxwiofn65, i když ta, do které vedl kabel, se teď začala jmenovat wmxwiofn67. Nebo jsem nevěděl, že se teď do fstab musí kromě nofail nově napsat i x-systemd.device-timeout=5, a čekal jsem po odpojení disku.

Což považuju za lepší stav, než tu zálohu killnout, jak by se to stalo u sysv initu.

Já bych osobně preferoval možnost si na konzoli vybrat, jestli killnout, nebo čekat dál.

[k3dAR]

take sem mel tu "cest", stroj s 1x LAN a nesmyslnej "predvidatelnej" prirazenej nazev, nastavim interfaces, restart, ok stroj dostupnej...
druhej den si necham pridat SATA radic a po zapnuti v siti nedostupnej, tak vypojit SATA radic, stroj v siti dostupnej...
zrusim definici v interfaces, vratit SATA radic a vidim ze ta 1x LAN diky pridanemu SATA radici dostava jinej "(wtf)predvidatelnej" nazev...

[🇹🇬]

fstab tě jako brzy vubec nebute trápit. se přejde na mountování disků pomocí systemd :D :D :D :D

hele

[Petr Fiedler]

Ty 3 obrázky RedHat pod článkem jsou vzhledem k názvu dotazu fakt dobrý

[Heron]

O predictable iface names tady už diskuse byla. Bohužel finální řešení neexistuje. Ale kdo by chtěl pojmenovávat iface stejně jako dřív, tedy podle mac, tak může. networkd to umožňuje. Tím to pro mě skončilo a jen jsem naštvaný, že jsem o tom nevěděl dřív a že já, jako systemd hater o tom ještě navíc musím napsat článek.

Nebo jsem nevěděl, že se teď do fstab musí kromě nofail nově napsat i x-systemd.device-timeout=5, a čekal jsem po odpojení disku.

Používám .mount unity. Od té doby, co je fstab jen potrava pro generator, jsem si zvykl psát unity a některé fs mountuju jen jako závislou službu jiné služby.

[GeorgeWH]

Prave teraz:

[***  ] A stop job is running for Zabbix Server (3min 17s / nolimit)

Zatial cakam...

[GeorgeWH]

(8min 18s / no limit)

Ktory chuj toto vymyslel...? :/

[GeorgeWH]

Mame progres - po poslani signalu ctrl+alt+del (vmware), to resetlo pocitadlo...

(1min 36s / no limit)

Co s tym? :(

[debian+]

Najdi a uprav unit, ze nech necaka za nim. Resp. stanov cas.

[Love_Dali]

Vyhodit to do hajzlu. Upřímně, nic jiného nezbývá. Setkal jsem se s podobným scénářem napříč distribucemi a tohle je fakt na hovno. Za celou moji historii linuxu jsem tohle neviděl. Jenom systemd.

[frufru]

Podle místních guru je to mezi klávesnicí a židlí. Systemd za to nemůže. Já s tím tedy nesouhlasím.

[Love_Dali]

Mno, koukám, koukám, jdu na Artix :)

[Love_Dali]

určitě bude problém mezi klávesnicí a židlí. Nikdo ovšem neřekl čí :D ;)

[Jendа]

Zajímavé, jak žijeme v nějaké jiné realitě, protože třeba Heronovi se tohle prý nikdy nestalo.

[Heron]

Jaký smysl má tento osobní výpad?

[Petr Fiedler]

To není výpad. Myslel to dobře.

[Jendа]

To neměl být výpad, spíš podivení se nad tím, že je nás asi víc, co děláme něco blbě.

[Heron]

Já, jako systemd hater, vůbec neříkám, že systemd je bez chyb. Ale současně o něm (stejně jako o čemkoliv jiném) nebudu šířit věci, které jsem nezažil. Já jsem skutečně nezažil popisovanou situaci a jak se ukázalo, nebyla to chyba systemd, ale autora balíčku. A se špatně napsanými unitami se setkávám opakovaně, což jsem několikrát psal. (Stejně jako se špatně napsanými rcv skripty.) Ano, možná by systemd mohl vyřešit interaktivní ukončení neposlušné unity. To bezpochyby.

že je nás asi víc, co děláme něco blbě

No jenže ono se to ukazuje i v diskusích. Buď se dotyčný admin tváří, že systemd neexistuje a dělá věci (schválně) proti srsti (což na jednu stranu chápu, ale není to moc pragmatický přístup a pokud systemd nechce, tak si má podle toho vybrat distro) a to v mnoha oblastech, nejen proti srsti systemd; nebo je problém na straně autora unity a za to fakt nemůže systemd (a několikrát jsem komentoval, že systemd věci fakt nepomůže, autoři, kteří špatně psali rcv skripty budou stejně tak prasit i .service).

[Jendа]

nebo je problém na straně autora unity a za to fakt nemůže systemd

Na druhou stranu mně se zdá, že:

• Na špatně napsané unity narážím častěji než jsem narážel na špatně napsané init skripty.
• Unity se mi ladí hůř než init skripty.

Oboje může být způsobeno buď tím, že init skripty tu jsou 30 let a lidi si na ně zvykli a chyby nějak vychytali, a za nějakou dobu budou unity stejně bezproblémové (pokud bude současný trend pokračovat, tak snad ano -- přijde mi, že už zažívám podstatně méně dobrodružství než na začátku (i když teda zrovna nedávno se mi stal ten kernel panic o kterém píšu níže) -- pokud se teda najednou nepřijde zase s nějakou další věcí, která se začne dělat jinak), a nebo taky tím, že je systemd příliš komplikovaně navržený a má nedostačující dokumentaci. Osobně si aktuálně myslím, že je to tak půl na půl.

[Heron]

Na špatně napsané unity narážím častěji než jsem narážel na špatně napsané init skripty.

Za mě je to stejné. Typicky programy, které měly špatně napsané init skripty, mají stejně špatně napsané unity a někdy unita jen volá skript vzniklý z původního initu.

Unity se mi ladí hůř než init skripty.

Na tom by nemělo být co k ladění. Co chceš ladit na jednom řádku ExecStart?

To, že některé unity takto nevypadají, není chyba systemd. Systemd nabízí mnoho typů service (podle mě až příliš mnoho), ze kterých si autor unity může vybrat. Má to být jednoduché a sebe dokumentující.

A na toto jsem upozorňoval již před x lety. Že systemd v zásadě nic nevyřeší, protože slušné programy měly init skript v zásadně o jednom řádku v sekci start a ty špatné měly tisíci řádkový start (který bych teda jako admin fakt ladit nechtěl), takže do systemd se to v zásadě jen prokopírovalo. A systemd umožnil svým způsobem mnohem větší prasení tím, že přináší až příliš mnoho typů unit.

Takže nakonec je to jen o autorech těch initů / unit.

[michich]

Výchozí nastavení timeoutu pro zastavení služby (DefaultTimeoutStopSec) je 90 s. "no limit" u této služby naznačuje, že někdo (správce nebo autor unit souboru služby) pro ni nastavil nekonečný TimeoutStopSec. systemd poslušně vykonává.

[GeorgeWH]

Ano, bolo to nastavene na nulu.

Ale aky ma realny zmysel nastavit timeout na "nekonecno"? Podla mna je to blbost, a v tomto pripade by ten reboot bezal este doteraz.

[Heron]

Ano, bolo to nastavene na nulu.

Přímo z distribuce? Které? Díval jsem se na default v debu a je tam 90s. Totéž v CentOSu.

[GeorgeWH]

Nie je to distribucny balik, ale zabbix repozitar http://repo.zabbix.com/zabbix/4.4/rhel/7/x86_64/.

[Heron]

RestartSec=10s
TimeoutSec=0

Chytráci... Takže to není chyba systemd, ale autora toho balíčku. Stejně tak ten 10s sleep při restartu je zvláštní.

[k3dAR]

nedostatek systemd ale je ze bezici odpocet neumoznuje interaktivne uzivatelem preskocit (na JEHO zodpovednost)

[x]

Tak ze Linux uz roky drzi v otezich Oracle, RedHat, IBM a delaji si s nim co chteji a pouzivaji to jako zbran proti konkurenci si jeste spoustu lidi v komunite stale nevsimlo a maji naivni pocit, ze maji nejakou moznost vyberu a volby.

Nastesti jsou jeste mista, kde je svet normalni:

$ rcctl
usage:  rcctl get|getdef|set service | daemon [variable [arguments]]
        rcctl [-df] check|reload|restart|stop|start daemon ...
        rcctl disable|enable|order [daemon ...]
        rcctl ls all|failed|off|on|started|stopped
$

$ rcctl ls on
apmd
check_quotas
cron
library_aslr
ntpd
pf
pflogd
slaacd
smtpd
sndiod
sshd
syslogd
$

$ rcctl get sshd
sshd_class=daemon
sshd_flags=
sshd_rtable=0
sshd_timeout=30
sshd_user=root
$

$ uname -rs
OpenBSD 6.6
$

a i dokumentace vypada jako od profesionalu rcctl(8) a nemusi to pripominat tuhle bichli systemctl(1)

Chapu, ze mit treba stejne prehlednou virtualizaci vmctl(8) je proste pro ty co se hrabou v kodu 24/7/365 strasna nuda a not cool, protoze to pak vsechno trapne proste funguje a jede a neni se v cem hrabat

Stejne jako proc mit ifconfig na to podle ceho se i jmenuje, tedy interface config, jako je zde i na nastavovani Wifi a dalsich veci, kdyz se muzete hrabat v projektiku a delat wpa_supplicant, pak ip a zaroven ale v systemu roky drzet neudrzovany linuxovy ifconfig

Muze byt, ze clovek potrebuje Bluetooth, ZFS, Dtrace, LVM a dalsi veci, tak ma i jine moznosti, jeste vice tradicni:

$ ls /etc/rc
/etc/rc           /etc/rc.conf      /etc/rc.conf.d/   /etc/rc.d/        /etc/rc.local     /etc/rc.shutdown  /etc/rc.subr
$

$ /etc/rc.d/sshd status
sshd is running as pid XXX.
$

$ grep ssh /etc/rc.conf
sshd=YES
$

$ uname -rs
NetBSD 8.1_STABLE
$

baliky tam vlastne taky zadne nejsou.............
$ pkgin avail | wc -l
   19242
$

Oboje to startuje stejne rychle nebo rychleji na modernim HW jak Linux s systemd. Nebyl to nahodou jeden z puvodnich hlavnich cilu Poltergeista? Rychlejsi boot?

Legracky stranou, i kdyz pravdive. Ti v komunite Linuxu by se meli vice zajimat o to kde se realne deje drtiva vetsina vyvoje Linuxu poslednich nekolik let a jake vztahy tam panuji. GPL se mezi temi firmami pouziva jako munice proti konkurenci pro donuceni zpristupnovat zdrojaky. Zadny div, ze posledni roky roste priliv penez od firem do BSD sveta, kde je tema ptakovinama z GPL nikdo neotravuje a pokud chteji byt "don't evil", tak muzou a stejne tak muzou byt i ten "evil" a vsichni jsou spokjojeni.

Je hezke slyset, ze po 20 letech i Andy Tanenbaum uznal, ze BSD melo pravdu a zacal spolupracovat A reimplementation of NetBSD based on a microkernel by Andy Tanenbaum

[frufru]

Tak další zkušenosti s linuxem za posleedních pár dní. Doporučený Devuan jsem nestahoval, protože se mi nelíbí, že je postavený na debianu 9. Přeci jenom bych chtěl novější verzi jádra. Stáhnul jsem si MX-Linux. Instalace proběhla dobře. Instalace ovladače Nvidia a multifunkční tiskárny Brother OK. Jediný zápor je, že má starší jádro a starší ovladač GK Nvidia. Myslím 340, což už je opravdu starý a proto známka 2+. Dále jsem stáhnul Ferdoru Gnome. Nainstalovat Nvidia jsem nezkoušel. Takhle dlouhý návod na instalaci ovladače GK jsem ještě neviděl. Je mi jasný, že příští grafická karta bude Radeon, ale zatím mám Nvidia 1050Ti. I ovladač tiskárny je porod. Fedora tedy pro snadnost instalace ovladačů GK a tiskárny dostala 4-. Nedoporučuji pro nové zájemce o linux. Stáhnul jsem si OpenSuse Tumbleweed KDE live. Live ok. Když jde tak pěkně grafika, tak jsem to nainstaloval. První zádrhel byl v tom, že pořád trval na instalaci zavaděče na /sdb, přitom ostatním linuxům stačil /sda. Prostě to přehodit nešlo. Takže po startu černá obrazovka. Po přehození v Biosu na sdb začal startovat. Ale nenastartoval. Jak to, když live distribuce OK a pak se zasekne? známka 5, protože jsem během 1/2 roku zkoušel 2x, a ani jednou se to nepodařilo po instalaci nastartovat. Ta první byla Leap Už nechci vidět. Následoval skoro vítěz a to Majaro Kde 18.1.3. Instalace OK. Nvidia pohoda a ovladače Brother přes AUR OK takže 1-. Má vyjít Linux mint 19.3 a tak jsem se rozhodl, že ten starý 19.2 smažu a zkusím jak se bude chovat Manjaro s jinou distribucí vedle sebe. Stejně bych dělal čistou instalaci. Vzal jsem nejnovější Ubuntu Gnome 19.10 a ninstaloval. Vše OK. Nainstaloval se Ovladač Nvidia 435.21 a dokonce bez zásahu multifunkce od Brother. Skenování a tisk OK. CHce se mi napsat , že za 1, ale je tu menší zádrhel. Manjaro linux nestartuje! VTF? píše Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0) Startuje jenom se zadáním talback initramfs Takže to shrnu. I když instaluji jen základní system + ovladač GK + ovladač tiskárny, tak to některá linuxová distribuce nezvládne a zůstane černá obrazovka. Zdá se, že všichni to zkouší jen ve virtuálním prostředí akdyž se má linux potkat se skutečným HW, tak je problém. Než mi místní guru zase začnou vysvětlovat, že je to mezi klávesnicí a židlí, tak bych je chtel upozornit, že jsou to pouze takové instalace, které si nastavil v instalačním programu sám tvůrce distribuce. Takovou úmrtnost linuxu při instalaci na železo jsem dlouho nezažil. CHce to občas testovat i na HW a ne jenom na virtuálu. S pozdravem FRUFRU

[🇹🇬]

VTF????

[frufru]

Proč VTF? Jenom se ptám jakou distribuci klasického vzhledu, snadnou instalací GK, ovladačů tiskárny a aby aspoň nastartovala po instalaci na HW. CHci toho tak málo?ZAtím mile překvapilo Ubuntu a Manjharo. Zatím mi nikdo ještě neodpověděl, proč tolik linux padá.

[JMP]

linux jen tak nepadá

pokud se opravdu chcete dozvědět co se děje, tak koukněte do logů a pořádně otestujte HW...

[k3dAR]

Xubuntu 18.04 pouzivam bez problemu na spouste realnem/nevirtualizovanem HW, instalace a provoz bez problemu, nemam Nvidia.

[Moderní Doba]

Mám i xubuntu a nikdy zatím žádný problém obecně NTB i7,32GB,1,5 TB ssd,Grafárna nivide používám statndatrní ovladače.. na druhém delu taky i7,16 giga ramek, a 1,5 TB ssd (ten jede nonstop skoro 2 roky..) Tam je "lubuntu" nikdy žádné problémy co pamatuji 3-4 - 6 let.. U Prvního vitrualizuji widle na warcraft 3,debian,kali a blackarch na testy webů,žádný problém...stále si myslím,že je problém mezi "klávesnicí a prdelí"..

[Moderní Doba]

Každý linux má "klasický vzhled" a snadnou instalaci GK - stačí číst v dokumentaci,určitě nechcete tak málo ne?Linux padá protože Windows,takové otázky nemají fakt logiku... jste tu nový? Pokud ano,přiložte logy,výpisy všechno co je dostupné..není to bakalářka..

Stačilo napsat na úvodu : " Pánové prosím mám tu problém s A-B-C" přikládám všechny logy,děkuji. Hotovo.

[Moderní Doba]

:_D

Daj si PCLinuxOS.

[Moderní Doba]

Tento systém jede segra přešla ze "sedmiček" a už je to taky řada let... nikdy si nestěžovala Souhlasím,mohu doporučit - má sice taky deláka s i5 tkou 4gigoše ramy klasický hadr pětikilo - nestěžovala si NIKDY.

Takže to asi nebude tím systemd, že?

[x]

Tu tucnou hlasku jsem za posledni rok videl v produkci uz tolikrat, ze to ani hezke neni. A duvod? No protoze mily Linuxek (RedHat kralove..... ) neni schopny pri aktualizaci pres yum vytvorit novy soubor jadra. Ma jich byt 5, udela jen 4 a klidne ten prikaz tak visi i 2 hodiny aniz by se neco delo. Co pomaha? Ano, Windows styl, udelat reboot predtim nez se spusti aktualizace (ale u nekterych stroju je to treba delat 2x - 3x ).

Delaji to fyzicke server jak s AMD, tak s Intel, tak i virtualni stroje na VMware, OVM a dalsich. Verze RH 7.x mene casto, 6.x skoro vsechny stroje, 5.x taky.

Proste odbornici no

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

Když jsem tvou stížnost četl poprvé, měl jsem pro ni pochopení, protože systemd stále nepovažuji dostatečně vyzrálý na to, abych jej mohl s čistým svědomím nasadit do ostrého provozu. Ale koukám, že tobě vůbec nejde o nějaký init, jako o instalátor, který ti vše nastaví na tvou vlastní hardwérovou konfiguraci a pokud možno tak, abys nemusel na nic sáhnout. Pak tedy potřebuješ apple, protože ten si vyrábí i hardwér. Ale i tam se můžeš dostat do úzkých. V linuxu však není problém nainstalovat takovou distribuci, která umožňuje tvorbu vlastních iso obrazů a tak si můžeš vytvořit vše přímo na míru a nedoufat, že to někdo udělá za tebe. A ano, teď už trollíš, takže odpověď na problém mezi klávesnicí a židlí je úměrná tvému trollení.

[frufru]

Tak to bylo tou Fedorou. Bylo divný, že jsem dal aktualizaci a Fedora 31 se restartovala. Objevilo se okno, že se aktualizuje system. Pak se to znova restartovalo a znova okenko , že se aktualizuje system. Takovou aktualizaci jsem zažil naposled u windows 95/98, kde po každé aktualizaci se prováděl restart. Zajímavé, kam došel linux za ta léta. Škoda.

[dustin]

Fedoru nepoužívám, ale je obecně známé, že Fedora je testovací platforma RH. Stejně jako beta (non-LTS) verze ubuntu. Není nic divného, když ve fedoře něco nefunguje, ladění chyb jej jejím účelem.

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

Možná se budeš divit, ale není problém se do takového cyklu dostat i s W10. Pak nastupuje diagnostika, aby se zjistilo proč se tak děje. 100% software neexistuje, stejně jako 100% hardware. Obojí je pořád z velké míry závislé na lidském faktoru. A to nezmiňuji uživatele ...

[Moderní Doba]

Hodně dobrá odpověď,luxusní a všezahrnující.

[lertimir]

Přesně tak. Pokud mi něco neběží tzv v defaultu. Tak si první otázku kladu, Co mám jinak? Co mám nějak divočeji, co tvůrci při vytváření automatických skriptů nečekali. Ve Win to mnohdy bývá velmi podobné až někdy horší, protože divočejší HW konfigurace musí mít CD s drivery, které se zařadí během instalace aby systém vůbec běžel.

[k3dAR]

asi posledni windows ktere si pouzival byli W98, protoze restart po kazde aktualizaci meli dale XP, Vista, Windows 7, Windows 8 a nejen ze chteli restart po aktualizaci, ale po restartu to naslo aktualizace predchozich aktualizaci ktere to nedokazalo najit rovnou, takze dalsi restart...Windows 10 maji restart "jen" v ~75% ... a i v W10 se obcas stane to ze aktualizace se nepovede krome toho ze pri vypnuti nejdriv koukaji na "dokoncujeme aktualizaci, nevypinejte", pak pri zapinani "jeste neco dokoncujeme, nevypinejte" nasledovane "ops, neco se pokazilo, odstranujeme aktualizaci, nevypinejte" nasledovane "nalezena aktualizace" a kolecko se opakuje...

[Moderní Doba]

A pak běží k nám do servisu a cálují..

[frufru]

A proto mě celkem sere, že se linux tlačí stejným směrem jako windows. Pokud jsi neměl nějaký obskurní PC s SIS grafikou, tak šlo po instalaci ihned pracovat. A i když dneska použijete Live distribuci, tak po jejím nainstalování nemáte 100% jistotu, že se to rozjede. U grafik je to ještě vetší sranda. Máme na výběr 3 (slovy tři grafiky), ale instalace proprietálních driverů je hrůza a děs. O to větší bylo zklamání, že ve fedoře se to dělá jak za krále klacka před 20 lety. A to je ten lídr trhu, od kterého všichni přebírají soft.

[...]

No, já používám Windows 7 spokojeně asi 11 let. Počítač nevypínám, nanejvýš ho uspávám. AutoCAD, SCIA, GEO5, kancelářské programy, VirtualBox, fotky, videa, internet,... na 3 obrazovkách, kolikrát tohle všechno dohdomady... Windows nepadají. Obávanou modrou obrazovku smrti jsem neviděl, ani nepamatuji. Naposled to totiž bylo na předchozí verzi Windows. Aktualizace probíhá automaticky někdy v noci. Někdy se stane, že ráno zjistím, že v noci proběhl restart, ale je to tak 1x v měsíci. Jinak to ručně restartuji výjimečně. Takže JÁ bych Windows 7 vůbec nenasazoval psí hlavu.

Ale například XEN mi loni na serveru po nějaké super aktualizaci asi půl roku pořád padal. Kousala se síť a ačkoliv jsem na internetu zjistil, že nejsem sám, závada prostě nebyla odstraněna, protože se zřejmě vyskytovala jenom na určitém hardwaru (serverovém). Musel jsem přejít na KVM, které zaplaťpánbuh spolehlivě jede...

[debian+]

Lenze podpora mu kanci v marci 2020 ;)

[...]

Dokonce snad už v lednu. Už se těším na Store, kostičky a blikající zprávy

[debian+]

To som vedel tak v hrubom.

[Jendа]

Hejt: 2019-12-09 (Debian 10)

Za mých mladých let bylo možné za běhu přeplácnout rootfs, udělat sync a otočit to přes sysrq_trigger. To už teď nejde, protože systemd na rozdíl od původního jednoduchého initu, který se spustil a běžel, hrabe na disk a přečte si změněné knihovny (se kterými samozřejmě není kompatibilní) a spadne, což způsobí panic (protože spadne PID 1) - ještě než jsem stihl nový rootfs rozbalit.

[  498.581817] systemd-journal[230]: segfault at 1 ip 00007f622f593004 sp 00007ffe1d668410 error 4 in libsystemd-shared-241.so[7f622f55f000+147000]
[  498.595361] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f
[  498.616493] systemd[1]: segfault at 1 ip 00007f737f681004 sp 00007fff50859190 error 4 in libsystemd-shared-241.so[7f737f64d000+147000]
[  498.628918] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f

Message from syslogd@debian at Dec  9 00:02:09 ...
 kernel:[  498.616493] systemd[1]: segfault at 1 ip 00007f737f681004 sp 00007fff50859190 error 4 in libsystemd-shared-241.so[7f737f64d000+147000]

Message from syslogd@debian at Dec  9 00:02:09 ...
 kernel:[  498.628918] Code: 00 00 48 83 c0 17 31 c9 48 c1 e8 04 48 c1 e0 04 48 29 c4 4c 8d 4c 24 0f 49 83 e1 f0 48 83 bb 30 01 00 00 00 4d 89 cf 0f 84 e9 <02> 00 00 8b 7b 04 89 f2 4c 89 fe e8 fc 1c fd ff 41 89 c4 85 c0 0f
[  498.871929] systemd: 41 output lines suppressed due to ratelimiting
[  498.878622] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Jendа]

Ještě k tomu:

Za mých mladých let bylo možné za běhu přeplácnout rootfs, udělat sync a otočit to přes sysrq_trigger.

Ano, tohle opravdu funguje, a to nejen napříč verzemi a distribucemi, ale i napříč architekturami. Už jsem takhle upgradoval z armel na armhf. Jak je to možné? Když spouštíte ten tar/rsync, tak se načte stávající (kopírování vám nesmí spadnout -- ale i když se to stane, tak to pořád můžete zachránit, pokud si předem deploynete a spustíte staticky linkovaný busybox. Na Debianu je to balíček busybox-static.). SSH vám při přihlášení vyrobilo extra proces a ten je také mimořádně odolný. No a na konci děláte echo b > /proc/sysrq-trigger, přičemž echo je builtin. (proto nejde použít systémový shutdown/reboot)

[xicht]

Ahoj, po dlouhe dobe procitam ABC a chtelo se mi reagovat...

Cca 20 let spolupracuji na OpenSource projektech a realne pouzivam/administruji Win/Linux/BSD a nastesti je to porad o svobodne volbe.

Osobne se mi pristup/infiltrace systemd do GNU/Linux velice nezamlouva a jsem proti. Nemel jsem zatim potrebu to realne resit u zdroje a asi by to nemelo zadny efekt...

• 1. Systemd neni uplne spatny napad, ale z meho pohledu by mohla byt signalizace stavu demonu resena primo pres nejake API v kernelu a obsluha jednoducha v ramci KISS pristupu.
• 2. Systemd dnes pohltil mnoho funkci nad ramec obsluhy sluzeb a osobne v tom mam stale bordel.
• 3. Mnoho projektu zacina byt primo zavislych na systemd.

Hlavni benefity v OpenSource svete jsou moznost menit veci (idealne k lepsimu) diky nasi spolupraci. Nemusime spolehat na to ze nam nejmenovane firmy reknou ze jejich reseni jsou nejlepsi a nejbezpecnejsi...

Musime samozrejme pocitat i s tlakem na SAAS reseni do budoucna! Tohle fakt nechci!

I pres to co jsem psal mame dnes porad svobodnou volbu nepouzivat systemd a nebyt moc ochuzeni o OpenSource reseni na svem stroji/serverech.