Hlavní navigace

Vlákno názorů ke zprávičce Devuan Jessie: Debian bez systemd v první betaverzi od Jan Mimránek - No určitě nechci vyvolat nějaký flame, spíš mě...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 30. 4. 2016 9:19

    Jan Mimránek (neregistrovaný)

    No určitě nechci vyvolat nějaký flame, spíš mě zajímá mě jen fundovaná odpověď. To je ten systemd taková hrůza? A když jo, tak proč na něj přešlo tolik dister a podporují to i vydavatelé balíčků? Mě se na tom moc nelíbilo, že se to nedrží zásady "dělám jednu věc a dělám ji dobře" ale zase účel světí prostředky .... Mám Debian 8 už rok na posledním stroji a neměl jsem se systemd jediný problém a je fakt, že ty hlášky ze splashscreenu konečně zmizely.
    Tak jak to tedy je?

  • 30. 4. 2016 10:04

    Palo (neregistrovaný)

    Tak ak ta trápia hlášky na splashscreene tak zostaň pri systemd, to bolo vytvorené presne pre teba.

  • 30. 4. 2016 10:15

    Jan Mimránek (neregistrovaný)

    No, já si s nima vždycky poradím celkem lehce, akorát je trošku trapné, v 21. stol., když dokončíš novou instalaci systému a hned po restartu už tam máš nekonzistentnosti, nehledě na to, že pak musíš průběžně vychytávat errůrky po instalacích balíčků. Uvedl jsem to ale i proto, protože vyčištění startu systému od hovadin byla jedna z často zmiňovaných dobrých vlastností systemd.
    Takže chlapci, vyndat hlavy z ...

  • 30. 4. 2016 10:22

    Lol Phirae (neregistrovaný)

    Aha, takže podstatné je, že problém není vidět, protože je tam henten systemd a splashscreen. Bezva. Tak zas tu hlavu zandej do Lennartovy (_|_) a běž to oslavit

  • 30. 4. 2016 10:34

    Jan Mimránek (neregistrovaný)

    Víš " já si s nima vždycky poradím celkem lehce" znamená, že si zjistím co se děje, a problém odstraním. V těchto případech to bývá často v nastaveních GRUBU a nebo chybějící konfigurace daemonů dotčených programů.

    Nevím jestli jsi si akorát nevzal ráno prášek, nebo jseš jen takové pako, ale nesmíš brát ostatní podle sebe, že když se řekne vyřešit tak někdo něco kamufluje a skrývá.
    Zkus to na živě.cz, tam si z tebe možná ti přidrzlí školáčci sednou na zadek ...

  • 30. 4. 2016 11:14

    Lol Phirae (neregistrovaný)

    Aha, tak systemd řeší problémy grubu a chybějící konfiguraci služeb si domyslí. ROFL. Myslím, že tuhle debatu ukončíme.

  • 30. 4. 2016 11:51

    Jan Mimránek (neregistrovaný)

    Ne, systemd řeší načítání služeb a řeší jejich závislosti a chytá errory. To se v Init nedělo a proto errory vyskakovaly až na splash screen. Třeba chybějící konfigurace k síťovkám. To bylo po instalaci syst. velmi častá chyba

    Ale debatu ukončíme. Evidentně o tom víš prd a akorát se snažíš vymaxovat nějakou blbost kterou jsem v textu nevyvrátil. Opravdu mě nebaví, pokaždé vymezovat všechny termíny a skutečnosti, aby mě nějaké zakomplexované děcko nechytalo za slovo. Nejsi zakomplexované děcko? Tak proč vypisuješ takové hovadiny?

  • 30. 4. 2016 12:34

    Lol Phirae (neregistrovaný)

    a chytá errory. To se v Init nedělo a proto errory vyskakovaly až na splash screen

    Aha, Takže jsem měl stoprocentní pravdu. Tebe ty chyby vůbec nezajímaj, tebe zajímá, jak je schovat. Ty errory "vyskovaly až na splash screen", protože - ty tupče - ty errory jsou ta nejdůležitější informace!!! Ne tvůj splashscreen s Lennartovou fotkou. Ty errory potřebuješ vidět, abys mohl zjistit problém a opravit ho. Ne schovat, ty lemple!!!

  • 30. 4. 2016 12:53

    Jan Mimránek (neregistrovaný)

    No, jasně. Zakomplexované děcko a co horší. tak ví prd. Errory patří do logu ty Lennartova fotko a ne uživateli na obrazovku.
    Když o tom noc nevíš, tak aspoň nepiš blbiny.

  • 30. 4. 2016 12:59

    Lol Phirae (neregistrovaný)

    Aneb frikulín mlamoj programuje init. Abys moh něco vůbec logovat, tam musíš mít kam. Když nemáš připojenej disk, tak můžeš logovat tak leda do Lennartovy řiti. A vůbec nejlepší je ty informace před uživatelem schovat úplně, aby nedejbože neviděl, co za blba mu ten systém instalovalo, že mu nanastavil síť, a aby se případný problém po telefonu vůbec nedal řešit. Vždyť uživatel přece může půl dne čumět na Lennartovu fotku, aby nebyl znepokojen errory.

  • 30. 4. 2016 13:10

    Jan Mimránek (neregistrovaný)

    Jo, takže hláška o chybějící konfiguraci síťovky na obrazovce přišla asi z věštící koule, protože init tahá služby z /etc/ z nepřipojených disků, takže proto ani nemá pojem o /var/log/ ani RAMce, ale zato zobrazit uživateli hlášku přes půl obrazovky na 10 vteřin je ten skvělý recept. No ty jsi teda čaroděj

    PS: Nevím co to máš pořád s Lennartovou fotkou, ale tvůj obvoďák ti rád poskytne odbornou pomoc.

  • 30. 4. 2016 13:20

    Lol Phirae (neregistrovaný)

    Śirší technické vysvětlování je úplně zbytečné, myslím, že všichni s mozkem a ti, co aspoň jednou řešili fatálně rozesraný systém pochopili, jakou situaci jsem popisoval. A ano, hláška na sekund, že janek při instalaci nenastavil síť, je nepochybně skvělý recept na vyřešení problému. Asi milionkrát lepší, než uživatel volající "pomooooc, mě půl hodiny nabíhají Xka a když kliknu na ploše na Seznam, tak mi nejde ten internet."

    Koneckonců, i každý svéprávný programátor GUI aplikace se snaží o to, aby při vážném problému aplikace zobrazila chybu tak, aby ji uživatel mohl zachytit. Ne, aby to prostě spadlo. Ale to zoufalec pochvalující si to skvělé zlepšení, že uživatele na splashscreenu nevyrušují žádné chyby, stejně nikdy nepochopí.

    Tak čau, mlamoji.

    2. 5. 2016 8:50 redakčně upraveno, důvod: Odstraněny zbytečné vulgarity.
  • 30. 4. 2016 13:40

    Jan Mimránek (neregistrovaný)

    Co to meleš?

    Pokaždé jsem prošel normálním instalátorem a pokaždé mi instalátor nějak nedokončil nastavení sítě a pokaždé mi to při startu vypisovalo hlášky při pokusu nastavit síť. Laskavě UTFG, tohle se stává spoustě lidem.

    Kdyby jsi se nesoustředil jen na to, jak někomu něco trapně podsouvat mezi řádky (to bych do příspěvku musel opsat celou dokumentaci, aby na mě tobě podobný blbeček neměl co vykonstruovat) a přečetl jsi co jsem psal, tak by ti došlo, že jsem se ptal, jestli je lepší systemd nebo init?

    Zbytek už jsou jenom tvoje debilní výplody o splashcreenu, maskování errorů, čtení konfigurace služeb z nepřipojených disků, nadávek a podobných <|> jako ty choré bláboly o Lennartových fotkách a ani už nevím co všechno jsi tam splácal dohromady a nyní, ještě vytáhneš nějaké lidi z nějakých diskuzí a oháníš se tím jako bych něco takového napsal.

    K tématu systemd vs init jsi nenapsal absolutně nic, akorát pořád nadáváš, meleš něco o Lennartově fotce a nějaké podobné bludy, oháníš se nějakýma konfiguracema které máš jako za sebou, ale nedokázal jsi dát dohromady jedinou normální odpověď jako spousta ostatních, jenom pořád něco smýšlíš a pak dál podsouváš.

    Připadáš si v pořádku?

  • 30. 4. 2016 13:47

    Lol Phirae (neregistrovaný)

    Pokaždé jsem prošel normálním instalátorem a pokaždé mi instalátor nějak nedokončil nastavení sítě a pokaždé mi to při startu vypisovalo hlášky při pokusu nastavit síť.

    A řešením je nevypisovat hlášky při pokusu nastavit síť. Vivat Lennart! Juchůůůůůůůů! To nevadí, že to nefunguje, chyba není vidět!!! Vyřešeno, hurááááááááááá! Chyby zásadně nezobrazoval a nikam nevypisovat, schovat je před uživatelem do logu je jediné správné a moderní řešení!!!

    Připadáš si v pořádku?

    Já ano, zato jedinec jásající nad tím, že teď je vše konečně správně, protože už mu konečně chyby neprobublávají na obrazovku a jsou výtečně skryty, zjevně příliš inteligence nepobral.

  • 30. 4. 2016 14:14

    Jan Mimránek (neregistrovaný)

    No, krom toho, že mi pořád podsouváš Lennarta, kterého, mít už mnohokrát po ruce, tak ho kvůli Alse zadupu do země a mám ho rád asi jako osinu v zadku, ze systemd nejsem nijak odvázaný, tak ok. Konečně už umíme zbytečně nenadávat a nevymýšlet hovadiny.

    Hlášky na bootu jsou k ničemu (krom těch, kvůli kterým opravdu systém ani nenaběhne). Proběhnou rychle, i když si to stopneš, nejdou zkopírovat, stejně nevíš co bylo předtím a potom, stejně lezeš do logu. Dobře, uznávám že něco se objevit může, ale stejně nakonec končíš v logu a pokud nejsou fatální, tak se stejně hov. děje, systém naběhne a lezeš do logu. Ať tak nebo tak, v initu, pokud vím ještě, to byly printy do kozole, pokud se nepletu a ne nějaký promyšlený systém upozornění uživatele. Klidně se pak dal použít a zkontrolovat syslog. Aby sis nemyslel, já naopak všechny hlášky miluji a řeším je, proto jsem i řešil každou tu blbost na bootu s initem. Strašně nerad před errory strkám hlavu do písku.

    "Já ano, zato jedinec jásající nad tím, že teď je vše konečně správně, protože už mu konečně chyby neprobublávají na obrazovku "

    Probublávání není o tom, vypsat něco na obrazovku, ale odchytit a zaznamenat vyjímku tam, kde se má na její význam reagovat a rozhodnout o dalším toku programu. Promiň, prostě si myslím, že v moderním OS jako je i Debian, je volovina vypisovat uživateli něco čemu stejně nerozumí přes půl obrazovky, akorát ho to plaší, ale má se po naběhnutí systému zobrazit případný výčet a možnost logy normálně použít pro řešení. Ale tak jako beru i ostatní názory. Třeba se pletu. Jen nemám rád nadávky a když mi někdo tvrdí, že jsem řekl něco, o čem vím že e hovadina a nevypustil bych to z úst.

  • 2. 5. 2016 22:07

    Jarda_P

    Hlášky na bootu jsou k ničemu (krom těch, kvůli kterým opravdu systém ani nenaběhne).

    Ale hovno, prave barevne odlisene chybove hlasky pri bootu si clovek vsimne spis, nez neceho v logu. Zejmena pokud se cloveku ze systemu podari vykopat vselijake dementni Plymouthy, skryvani hlasek a kde co, co se snazi textovy boot nahradit nejakym nesmyslem. Krome toho ne vsechny hlasky z pbrazovky maji odpovidajici polozku v nejakem logu. I kdyz s Poetteringovym blobem by udajne mely byt odchyceny i hlasky, ktere vznikly pred namontovanim disku RW, tak je otazka, jestli se k nim clovek dostane. Je tu nekdo, kdo se uz poklousel cist Poetteringovy binarni logy? BTW, bootovaci obrazovku vidim pri kazdem bootu, existuje sance, ze si hlsky vsimnu. Ale do logu po kazdem bootu nelezu.

    Promiň, prostě si myslím, že v moderním OS jako je i Debian, je volovina vypisovat uživateli něco čemu stejně nerozumí přes půl obrazovky, akorát ho to plaší, ale má se po naběhnutí systému zobrazit případný výčet a možnost logy normálně použít pro řešení.

    Tak blby uzivatel si muze nainstalovat Plymouth, nastavit tak, ze se mu tam budou ukazovat akorat nejake nic nerikajici ikonky nebo progress bar nebo co to ted frci a ma hlasky skryte a i bez Poetteringa. Uzivatel, ktery si nezaklada na podobnych picovinach, si necha po obrazovce rolovat hlasky, aby se o systemu dozvedel vic, nez pri bootu Widli, ktere leda tak vytuhnou s hlaskou, ze se *neco* posralo.

  • 3. 5. 2016 0:56

    Jan Mimránek (neregistrovaný)

    Pozdě. Trident mi odborně vysvětlil proč jsou hlášky printem do konzole dobré. Ty to moc nevysvětluješ ...

  • 1. 5. 2016 7:41

    j (neregistrovaný)

    Zalez demente do lennartovo rite ... kadej normani servis vypise error pri startu rovnou na konzolu ty mamlase, protoze log demon nemusi v tu chvili, treba prave kvuli ty chybe, bezet. Ale to retard jako ty nemuze vedet.

  • 1. 5. 2016 19:04

    Jan Mimránek (neregistrovaný)

    Lennart je mi někde ... psal jsem to v příspěvku někde nahoře, taky hlavně jsem se ptal, že nevím jestli je systemd lepší než init, ale na co číst vlákno když se chci jenom navážet a trapně pindat, že?

    Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba. To už je ale zřejmě moc na pochopení. Přečti si někdy něco na téma jaké hlášky uživatele vůbec zajímají a zamysli se nad tím, že pokud mu systém nepadne a na obrazovce problikne za pár sekund při startu systému několikrát 10 řádků výpisu, je mu to bliknutí celkem k <|> a stejně poleze do logu.

    Klidně si vřískej, ale to na situaci nic nemění . . .

  • 1. 5. 2016 19:09

    M. Prýmek

    > Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba. To už je ale zřejmě moc na pochopení.

    Nevím, kdo o tom rozhodl, že "nepatří". Nějaká komise? :)

    Mně se třeba jednou stala taková prima věc: nabíhá Linux se systemd, splashscreen vypnutý, objevují se hlášky o startování jednotlivých služeb a v tom jedna z těch služeb nestartuje - motá se u ní takový to motadlo. Hláška samozřejmě žádná - je někde v tom slavném binárním logu. Nevím, co se děje. Mám počkat ještě pět minut? Půl hodiny? Hodinu? Není to nějaká chyba v systemd, takže to takhle sůstane viset na věky a na spuštění loginu vůbec nedojde? Zobrazí se mi po půl hodině hláška "Jejda! Něco se pokazilo"? Nebo "Došlo k chybě. Kód chyby: NO ERROR"? Objeví se okýnko "Zavolejte administrátora"?

  • 1. 5. 2016 19:31

    Jan Mimránek (neregistrovaný)

    No víte, už se v tom celkem motám. Ono to totiž co jsem psal začalo tak, a tak to i myslím, ne že by se vůbec neměly objevovat hlášky při problémech, ale přesně to jak jsem psal, to co se mi reálně stalo:
    Vyskočí mi 10 řádků výpisu nějaké části co měla směřovat do logu - čas - nějaké hodnoty, věty .... a za 10 vteřin je to fuč. A co teď jako s tím?
    Nebo klasika "Waiting for network confi ..... 60 sec ...." a čeká ..... A co jako s tím? Jak mi to pomohlo?

    Po startu systému stačí vyhodit v liště warning s odkazy na errory a je to. Hotové.
    Samozřejmě dokud nejede logovací daemon, tak chyby na obrazovku, ale to ani systém nenaběhne, stejně lezete do logu a stejně čtete logy od začátku.
    Každopádně když Vám zůstane viset sys při startu tak co uděláte? Zase musíte manuálně do systému i kdyby Vám to na obrazovku vyhodilo chybu i s řešením, jenže to nezkopírujete a musíte systém vypnout, takže zase lezete do logu.


    Jen musím znova dodat - neobhajuji systemd, nevím jestli je lepší než init nebo něco jiného a proto jsem se tu ptal na názory ( toto celé vzniklo z toho že se tu do mě začal trapně navážet LoL Phirae a stočilo se to až sem na nějaké logování. jen píšu názor - jinak je mi celkem u prdele jestli se to píše na obrazovku, stejně si většinou u startu sys vyzouvám boty ) a nelíbí se mi na systemd už ani to jak je nokompatibilní s ostatními


    Prosím nedělejte z Nás obou blby, Kód chyby: NO ERROR je volovina, takové nicneříkající nic je k ničemu ale dají se dávat i normální error kódy

  • 1. 5. 2016 19:43

    M. Prýmek

    > Vyskočí mi 10 řádků výpisu nějaké části co měla směřovat do logu - čas - nějaké hodnoty, věty .... a za 10 vteřin je to fuč. A co teď jako s tím?

    Ale ty hlášky přece směřují do logu - ale zároveň se vypisují do konsole. Pokud je to za 10s pryč, tak je to dobře, protože to znamená, že systém naběhl a můžu si to v logu přečíst. Horší je opačný scénář - systém nenaběhne, čili z logu si to přečíst nemůžu a na obrazovce si to nepřečtu, protože to tam "nemá být".

    > Nebo klasika "Waiting for network confi ..... 60 sec ...." a čeká ..... A co jako s tím? Jak mi to pomohlo?

    No velice zásadně - vím, že to nenabíhá kvůli konektivitě. Čili buď tu konektivitu umím hned napravit (např. zastrčit vytažený kabel), anebo u nejklasičtějších initů umím využít i toho, že ten skript běží na popředí - čili stačí zmáčknout klasické CTRL+C a jede se dál bez čekání. Systemd (a ostatní systémy pro paralelní spouštění) už tohle neumožňují - procesy běží kdesi na pozadí a dostat se k nim dá jenom přes nějaké spešl API - úplně přesně jako na Windows, se všemi souvisejícími nepříjemnostmi.

    > Prosím nedělejte z Nás obou blby, Kód chyby: NO ERROR je volovina, takové nicneříkající nic je k ničemu ale dají se dávat i normální error kódy

    To byl samozřejmě nejapný vtip: je to typická hláška z Windows. Tak daleko snad zwindowsovatění Linuxu ještě nedošlo ;)

  • 1. 5. 2016 20:01

    Jan Mimránek (neregistrovaný)

    No když jsem viděl " Kód chyby: NO ERROR " tak mě taky hned napadly Win :-D.
    Šlo mi o to, že mi to většinou probliklo a stejně jsem musel lézt do logu, ale dole Trident už mi to vysvětlil proč je dobré to tak nechat, ok, beru. mě to nevadilo ani před tím, to vzniklo z toho, že mi tu TroLL Phirae začal podsouvat že maskuju errory a pak si myslím že je vše ok a takové koniny no a pak už jsem se asi nechal vtáhnout do těch konstrukcí .....

  • 2. 5. 2016 22:14

    Jarda_P

    No, bud ad, ze to aspon probliklo. Aspon vis, ze mas lezt do logu. Na Widlich nic neproblikne a v logu se stejne obvykle nedoctes nic relevantniho a pokud doctes, tak k tomu v polovine pripadu nenajdes zadny rozumny vyklad.

  • 2. 5. 2016 22:11

    Jarda_P

    ...neobhajuji systemd, nevím jestli je lepší než init nebo něco jiného...

    Systemd nemuze byt lepsi, nez jiny init a to uz proto, ze ho napal dement s tak arogantni drzkou a pristupem k uzivatelum.

  • 1. 5. 2016 19:11

    Lol Phirae (neregistrovaný)

    Jinak na obrazovku patří hlášky jenom pokud neběží logovací služba.

    Pochopitelně. Takže např. když kopíruju nebo ukládám soubory a operace selže, tak to potichu zaloguju, aby si toho uživatel nedejbože náhodou nevšiml a nevyrušila ho taková prkotina. Software design by idiot.

  • 1. 5. 2016 19:17

    Jan Mimránek (neregistrovaný)

    Pokud sis nevšiml, stále se tu řešil start systému a hlášky na obrazovce, ne zatajování errorů při spuštění nějaké operace. Tak prosím vymysli něco jiného proč je to špatně.

  • 1. 5. 2016 19:20

    Lol Phirae (neregistrovaný)

    Už jsme ti to tu opakovaně vysvětlovali, ale s mlamoji, které znepokojují informace, protože jim kazí bezcenné animované obrázky, je tato diskuse zcela zbytečná.

  • 1. 5. 2016 19:35

    Jan Mimránek (neregistrovaný)

    Jseš prostě osel. Nikdy jsem nenapsal že mne znepokojují errory na startu nebo že mám radši obrázky. To jenom bereš druhé podle sebe.
    Já akorát napsal, že errory patří do logu. Pokud ale myslíš že errory patří jinam, mě je to u (_!_)

  • 1. 5. 2016 19:42

    Trident (neregistrovaný)

    Rekni mi kolik mas pod palcem masin, kolik jsi delal embedded systemu a jak jsi delal diagnostiku. At uz velkyho nebo malyho zeleza. Pokud bootujes server potrebujes vedet co se pri bootu deje pripadne ho odladit. Ten vystup na konzoli muze byt klidne nekam na seriovy port na systemovou konzoli( non-x86 velke platformy na to maji treba specialni device(ale ptaci stejne nonx86 architektury stejne temer nepodporujou), nebo to potrebujes hned videt na KVM rozhrani v managementu serveru. Ty treba nemas sanci se dostat k logu nebo neni kam logovat protoze system je tak nakopnuty. A kolikrat ani nemuzes protoze to z bezpecnostniho hlediska neni uplne mozne(logy se neukladaji)
    Co budes delat pane kakademiku? Je ti jasne ze nahodit system ze site/z CD nemusi byt v mozne? J ti jasne ze cekani na pristup k logu je jak cekani na ......

    Vubec co vedej vasnosti vo juniksech? Sto takoje possssiksss? Tyhle radoby linuxaci radi obracej to co bezmala 50 let funguje a funguje to dobre. Pak pride nagelovany startupovy blbitko a misto pokory a studia co je udelano jak to funguje vymysli nakou naprostou ptakovinu a misto toho aby zdokonalilo stavajici system, tak vymysli system novy ktery sice fixuje nevyhody predchoziho systemu, ale funkcni veci z predchoziho systemu neimplementuje stejne funkcne, spolehlive a jednoduse. Namisto toho si okolo toho vseho vytvori prakticky vedni obor a sektu uctivacu. Well played, Lennart o great one!

    Systemd neni odpad protoze zakladni myslenka je spatna, systemd je odpad protoze implementace(im­pdementace - implementace dementem).

  • 1. 5. 2016 19:53

    Jan Mimránek (neregistrovaný)

    No vidiš. Tak nějaké emmbed má za sebou mám své vlastní virtuální servery a dělal jsem i se serverovým "železem" přímo ve firmě. Je fakt že jsem nikdy ale nepřišel do styku s takovými případy, z mého pohledu vyjímečnými, jak píšeš.
    Hele, faln, tomu co píšeš rozumím a kdyby jsi mi to napsal bez těch zbytečných urážek a machrovinek, fakt bych si tvého názoru vážil ještě mnnoho mnoho více. Každopádně jsi 1. za dva dny, kdo mi dokázal napsat, proč se pletu s těmi hláškami na startu a ne jen sady konstrukcí "kdyby byly v řiti ryby .....". Díky. Beru, nemám s tím problém.
    Celé moje provinění akorát začalo tím, že jsem chtěl vědět, jestli je lepší systemd nebo init z pohledu někoho, kdo do toho fakt vidí. I já,jako ne-super-odborník jsem si všiml, že by chtěl init vylepšit, ale z toho co jsem četl o systemd jsem nabyl dojmu, že to je tak trošku čuňárna. Tak jsem si dovolil se zeptat a už to jelo ....

  • 1. 5. 2016 21:59

    Trident (neregistrovaný)

    Jaky machrovinky? Clovek co s unixy dela a pouziva je vsestranne a coby soucast rozsahle infrastruktury vcetne specialnich embedded systemu(nemusi byt vzdy unixy) tak v zivote ani nepomysli na kraviny co najde v systemd. Clovek ktery se zabyva castecne i kritickymi systemy a human factors by v zivote nenapsal kravinu typu "NO ERROR" a nepouzival by slozita reseni na jednoduche problemy - dbus a nepouzival by nabobtnaly monolit a staticky linkovanou glibc.
    Jde o to ze linux se pouziva velice vsestranne a systemy jsou take velice vsestranne nasazovany. Vem si ze mas zakose kde je treba vycuc konzole logovan primo po siti nekam jinam na logmasinu protoze neni zadouci aby se ten log na masine ukladal. Jak odladis boot kdyz ti jeste nenaskocil log daemon? Co kdyz ti vyhnije?
    Slozity problemy ktere jsem popsal byly typicky zakysy na SAN infrastrukture kdy se k logum na rozhasenem fs(na lun snapshotu) neslo dostat. Navic kdyz nemas centralni logovani na dane casti infrastruktury tak si loguj kdyz ti odchazi disk a log fakt nejde zapsat.

    Pisi tady o rozsahu infrastruktury tisice fyzickych stroju - ruzna linuxova distra(predevsim RHEL),AIX,Sola­ris,VMS,HP-UX a par upgradovanych zvejkadel dernych stitku se zOS. Nepocitam embedded veci a letectvi - to resi tym prumyslovych ptakovin, ale obcas jim svou dusi taky projektove zaprodam abych nezdegeneroval v podnikoveho ajtaka nebo manazera.

  • 1. 5. 2016 22:33

    Jan Mimránek (neregistrovaný)

    "Co budes delat pane kakademiku?"
    "Vubec co vedej vasnosti vo juniksech? Sto takoje possssiksss? "

    Ale možná už jsem byl jen trochu podrážděný, protože se mi tu dostávalo nadávek, všeobecných všemouder a kdejakých konstrukcí pořád. Tak se omlouvám. Každopádně děkuji, opět jsem se něco dozvěděl.

  • 30. 4. 2016 11:33

    mimi (neregistrovaný)

    splashscreen dela jen plymounth a neni problem se ho zbavit .....

    systemd sam o sobe je 1000x lepsi nez silene initscripty .. jediny problem je politika kolem nej

  • 30. 4. 2016 11:54

    Jan Mimránek (neregistrovaný)

    Jj, mě ale ani tak neštvalo, že se tam ty errory vypisují, ale že tam vůbec jsou. To že se error vypíše u mě není špatně, jen mohl končit v logu a ne i na obrazovce ...

  • 30. 4. 2016 12:38

    Lol Phirae (neregistrovaný)

    jen mohl končit v logu a ne i na obrazovce ...

    Ano. Nejlépe v binárním logu, který nedokážu přečíst, a který je uložen na disku, který kvůli těm fuj fuj vyskakovacím errorům na nádherném splashscreenu s Lennartem leštícím si péro nedokážu připojit. #facepalm #wtf

  • 30. 4. 2016 12:50

    Lol Phirae (neregistrovaný)

    splashscreen dela jen plymounth a neni problem se ho zbavit .....

    O tom, jak není problém se plymouthu zbavit, běž vyprávět třeba soudruhům z Ubuntu.

    Bug 531331 - Remove plymouth destroying system
    Plymouth is not a bootsplash

  • 30. 4. 2016 18:31

    mimi (neregistrovaný)

    To ze buntu je ptakovina ... vime ..

    v opensuse staci "zypper in blog-plymouth" a od toho okamziku te nejaky blby splashscreen nezajima

  • 30. 4. 2016 22:06

    ByCzech

    To už jsme řešili nedávno pod jiným článkem/zprávičkou. V Debianu taky stačí "sudo apt-get purge plymouth plymouth-theme" a je vystraráno. U Ubuntu to sebou vezme tuším celý/většinu desktop(u) :). Vzhledem k té změně závislostí Debian vs Ubuntu to určitě není chyba, ale záměr :-). Výběr distribuce je každého jeho vlastní rozhodnutí a problém...

  • 1. 5. 2016 7:44

    j (neregistrovaný)

    jo jasne, uzasny zlepseni, kde kdyz nechci aby mi servisa bezela, tak nestaci ji stopnou ... musim ji odinstalovat ... bombaaa. A o i kdyz ji potrebuju vyradit na 1/2 hodky ...

  • 1. 5. 2016 23:45

    mimi (neregistrovaný)

    plymouth neni service ...

    a chces li ho vyradit .. jednorazove ... staci ti pridat na comandline jadra 1 parametr ' plymouth.enable=0'

  • 30. 4. 2016 10:10

    mhepp (neregistrovaný)

    Distribuce byly donuceny. Aplikace ztratily funkcionalitu, kterou mely drive, protoze vyvojari systemd tuto funkci implementovali (zde je problem, ze obvykle chybove a nespolehlive) a puvodni aplikace prestaly fungovat (naposledy mam problem skutecne vypnout vestavene NTP a pouzit klasicke NTP, protoze s vestavenym do systemd mi ujizdi cas).

    Druha pulka pohledu na tuto situaci je ta, ze mnohe aplikace zacaly zaviset na funkcionalite systemd bez moznosti volby (napriklad GNOME). Takze pokud chces nove GNOME, tak musis mit systemd. To zpusobuje docela problem pro ne-linuxove systemy, ktere jsou bez systemd. Napriklad *BSD. Takze FreeBSD resi, jestli neimplementovat falseny systemd kvuli vecem jako GNOME.

    To, ze je aplikace moloch, ktera Ti i utre zadek je jen mala drobnost ve svetle ostatnich problemu. Restart po upgrade systemd je radost vzdy, pravidelne se mi zasekne vypinani/restart na nejake sluzbe, kterou ani nepotrebuji a podobne.

  • 30. 4. 2016 10:28

    Jan Mimránek (neregistrovaný)

    Aha, no já si to tak trošku myslel, akorát nejsem aktivní vývojář okolo nějaké distribuce, takže nemám info z první ruky a ty články o tom jsou buď hate nebo love, každý sype to svoje a prase aby se v tom vyznalo ... Mě se na tom hlavně nelíbilo, že je to takový všepohlcující blob na věčné časy a nikdy jinak ... a na to jsem velice skeptický

  • 1. 5. 2016 12:07

    Filip Jirsák

    Není to žádný blob, je to spousta malých nástrojů, které se akorát vyvíjejí pod jednou střechou a umí spolupracovat. Není ale problém do toho zaintegrovat své vlastní nástroje, nebo ty z rodiny systemd nahradit něčím jiným. Naopak si myslím, že koncepce, na které staví systemd, v budoucnosti umožní větší variabilitu služeb, protože definuje standardní rozhraní, jakým mezi sebou mohou komunikovat závislé služby.

  • 1. 5. 2016 12:13

    M. Prýmek

    > Naopak si myslím, že koncepce, na které staví systemd, v budoucnosti umožní větší variabilitu služeb

    No... https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ - sloupeček Reimplementable Independently...

  • 1. 5. 2016 13:01

    Filip Jirsák

    Ono je potřeba si k tomu přečíst i ten první sloupeček. To, že systemd pracuje se soubory ve formátu Unit File, a když mu předhodíte nějaký jiný formát, nebude s ním sám od sebe umět pracovat, je logické. To je jako byste vytýkali Perlu, že si neporadí se skriptem napsaným v Pythonu.

  • 1. 5. 2016 13:42

    M. Prýmek

    Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval. Kromě sloupečku 1 je taky spolupeček 7, kde je vidět, že komponenty, které by snad měly být reimplementova­telné, nikdo neimplementoval. Asi z nějakého důvodu.

    Existence API totiž sama o sobě nic neslibuje. Důležité je hlavně, jak je to API stabilní (to se snad poslední dobou zlepšilo a existuje i nějaký slib stability aspoň něčeho) a hlavně jestli je to API obecné nebo reflektuje designované volby implementátora (takže ho sice reimplementovat můžu, ale musel bych defacto napsat ten stejný kód, což by mi nijak nepomohlo). A tady u toho druhého bodu si nejsem moc jistý. Kdyby to totiž bylo tak růžové, neměli by vývojáři *BSD a Gentoo takové vrásky na čele...

    -systemd code too co-dependent on other systemd libraries/com­ponents
    -can't port/recreate any low-level functionality
    -horrible idea anyway
    http://darknedgy.net/files/systembsd.pdf

  • 1. 5. 2016 15:40

    Filip Jirsák

    Chtěl jsem jenom upozornit na to, že kdyby to s tím API bylo tak růžové, tak by systemd nikoho nevzrušoval.
    Tohle vůbec není pravda. To, co na tom nejvíce vadí, je to, že je to nové, poukazuje to na chyby v tom starém, je moderní na to nadávat, a stojí za tím kontroverzní autor. Až na ten poslední bod je to úplně stejné, jako nadávky třeba na IPv6 nebo btrfs. No a někde v koutku vedle těchhle hlasitých odmítačů jsou pak ti, kteří tiše věcně kritizují věci, které jsou na systemd (IPv6, btrfs) opravdu nešťastně řešené, nedotažené apod.

    Stabilita a obecnost API je sice hezká věc, ale hrozí, že bude nějaká komise nejprve několik let navrhovat obecné stabilní API, aby se pak ukázalo, že to v praxi nevyhovuje. API podle potřeb konkrétního projektu má tu výhodu, že jsou hned vidět výsledky a to API se dá prakticky používat.

    Ona je to s tím API totiž taková výmluva. Až tu bude nějaký projekt, který to API využívá, a kvůli změně v API systemd přestane ten projekt fungovat, pak bude možné tvrdit, že je chyba v nestabilitě API systemd.

    Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá, že udělat to dnes pořádně znamená implementovat spoustu nové funkcionality. Takže kdyby chtěl někdo reálně konkurovat systemd, musel by toho také sám spoustu implementovat – a do toho se nikomu nechce.

    Po té nové funkcionalitě byla evidentně velká poptávka, proto najednou na systemd závisí tolik věcí. Což není důkaz rozpínavosti systemd, jak to někteří interpretují – protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset.

    Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd. Nikomu nic nebrání vytvořit stabilní a obecné API, do kterého systemd zabalí. Celý problém systemd je v tom, že nikdo nevytvořil nic lepšího. Kdyby vytvořil, vývojáři i distribuce na to s radostí přejdou, a autorům systemd nezbyde, než implementovat to stabilní a obecné API toho lepšího systému.

  • 1. 5. 2016 15:59

    M. Prýmek

    > To, co na tom nejvíce vadí, je to, že je to nové, [...]

    Asi jak kde. V *BSD světě na tom lidem vadí, že je to by-design Linux-only a že aplikace na tom začínají záviset. Čili *BSD se dostává do situace, kdy si může vybrat buď GNOME úplně zaříznout (nikdy už na BSD nebude) nebo reimplementovat systemd. Obojí je opruz. A nejhorší na tom je, že úplně zbytečný.

    > ale hrozí, že bude nějaká komise nejprve několik let navrhovat [...]

    Pokud je funcionalita jednoduchá, jasná a obecná, tak nevím, co by na tom komise řešila. Co je ta bájná funkcionalita? V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod. Není na tom nic světoborného, co by potřebovalo API o stovkách položek.

    > Primární problém je totiž v tom, že původní správa služeb přes SysVinit a skripty byla tak zastaralá a zatuhlá

    Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd. To je strawman.

    > Po té nové funkcionalitě byla evidentně velká poptávka

    Konkrétně prosím! Po jaké funkcionalitě? Nemám systemd kdovíjak nastudované, ale ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak.

    > protože systemd nemá žádné prostředky, jak donutit programátory nebo správce distribucí, aby na něm začali záviset. [...] Nikomu nic nebrání vytvořit svůj software, který bude nabízet lepší služby, než systemd

    Jistě. To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...

  • 1. 5. 2016 16:23

    Lol Phirae (neregistrovaný)

    Konkrétně prosím! Po jaké funkcionalitě? Nemám systemd kdovíjak nastudované, ale ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak.

    No, já jsem třeba hrozně poptával nový resolver, protože tu máme akutní nedostatek DNS serverů. Výtečným nápadem byla taky implementace dostatečně debilizovaného (S)NTP klienta. Kritický nedostatek syslog démonů byl geniálně vyřešen implementací binárního blobu, která bobtná do velikostí mnoha gigabajtů a opravit ho jde pouze smazáním. Prostě tomu vůbec nerozumíš, bez Lennarta a podobných průkopníků bysme ještě lezle po stromech. :-P

  • 1. 5. 2016 16:34

    M. Prýmek

    > bez Lennarta a podobných průkopníků bysme ještě lezle po stromech. :-P

    Mně osobně je Lennart ukradenej, jeho chování a spory s některými developery jsou pro mě jenom takové vtipné historky z natáčení - Linux používám minimálně, kde můžu, mám FreeBSD. Rozlaďuje mě spíš to, že dokud byl linuxový svět malinký pidižvýček oproti drtivě majoritním Windows, mluvilo se o spolupráci, standardizaci, otevřenosti, přenositelnosti - a teď najednou, když se Linux rozšířil všudemožně (kromě desktopu), tak najednou vlastně standardy nejsou důležité, jde o vytvoření "moderní post-unixové platformy" a ostatní unixoidní systémy ať si trhnou nohou (nebo reimplementují řešení, která si vymyslíme my).

    Prostě Linux jako celek (jo, vám, že to je nekorektní) se bohužel posunuje k chování, které bylo dřív typické pro Windows - systém kompatibilní jenom sám se sebou, totálně ignorující okolí. Navíc těch podobností je čímdál víc i v technické rovině (binární formáty, automagická řešení, do kterých nikdo nevidí, neproniknutelné závislosti,... už zbývá jenom řešení problémů reinstalací :( ).

  • 1. 5. 2016 17:00

    Lol Phirae (neregistrovaný)

    No, když mluvíš o té reinstalaci - systemd už se nasral i do aktualizací systému...

  • 1. 5. 2016 18:12

    Filip Jirsák

    Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století, protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje? Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě? Ano, nevýhoda je, že po něčem, co řeší systemd, byla evidentně velká poptávka, takže se masově nasazuje už v době, kdy ještě není stabilní a portace by byla komplikovanější. No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.

  • 1. 5. 2016 18:28

    M. Prýmek

    > Jak byste si to představoval jinak? Máme na Linuxu solidárně dál používat nevyhovující správce služeb z minulého století

    Prosím o konkrétní vyjmenování, v čem jsou alternativy systemd nevyhovující. Se zřetelem k launchd, SMF a klidně i init skriptům FreeBSD.

    > protože v *BSD nejsou schopni naimplementovat funkcionalitu, kterou moderní správce služeb potřebuje?

    Jakou funkcionalitu? Třeba cgroups? Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux? Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome? WTF?! OSS už není o možnosti volby, ale o tom, že kdo nepřijde systemd, ten je pitomec?!

    > Není lepší to implementovat alespoň pro Linux, vyzkoušet a ověřit, a až bude existovat nějaké stabilní řešení, můžou si to lidé z *BSD portovat k sobě?

    Systemd nikdy portovat nepůjde, protože je neportovatelný by design. To je ta pointa.

    > po něčem, co řeší systemd, byla evidentně velká poptávka

    Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?

    > No jo, ale to je problém toho, že tu poptávku neuspokojil nikdo před systemd. Přitom tu možnost měl každý.

    Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...

  • 1. 5. 2016 18:48

    Filip Jirsák

    Vývojáři BSD nejsou schopní BSD udělat tak, aby bylo přesně stejné jako Linux?
    Kde jsem psal, že se to má udělat „přesně stejně“? Ať si to vývojáři *BSD udělají, jak chtějí, klidně ať upraví systemd tak, aby fungoval i bez podobné služby. Kdo by to měl udělat jiný?

    Vývojáři BSD jsou pitomci, protože nechtějí mít systemd jenom kvůli tomu, aby fungovalo Gnome?
    Vývojáři BSD jsou pitomci, pokud nechápou, že když nechtějí mít systemd, musí Gnome opatchovat tak, aby fungovalo i bez systemd, nebo musí služby, které Gnome poskytuje systemd, implementovat sami. Ale já si myslím, že vývojáři BSD to chápou, že to nechápou jenom někteří diskutující.

    Systemd nikdy portovat nepůjde, protože je neportovatelný by design.
    To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?

    Pořád jsem ještě neslyšel konkrétně po čem. Je to fakt tak těžké vyjmenovat?
    Já netuším, po čem všem ta poptávka je. Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod. Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?

    Windows se asi taky rozšířily kvůli nějaké poptávce. Nikdo jiný ji neuspokojil. Přitom tu možnost měl každý. Tak jo no...
    Před nástupem Windows měl tu možnost každý.

    Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.

  • 1. 5. 2016 19:02

    M. Prýmek

    > To je zvláštní, že se běžně portují programy z Unixů do Windows a opačně, u kterých s portací původně nikdo nepočítal, a jde to. Co je na systemd tak specifického, že je neportovatelný by design?

    To je vtip? Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!

    > Já netuším, po čem všem ta poptávka je.

    Ok. Tak s tím přestaň operovat.

    > Ale jak už jsem psal, předpokládám, že když nějaký vývojář zatáhne do svého programu závislost na systemd, má k tomu dobrý důvod.

    Jasně. A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.

    > Nebo vy si myslíte, že to vývojáři dělají jen tak z rozmaru, nebo aby něčím naštvali Mirka Prýmka?

    Mě tím rozhodně nenaštvou. Gnome nepoužívám a kdyby na BSD nebylo, je mi to úplně jedno. Ale je mi líto, že se z linuxové komunity - s jasným zaviněním konkrétních jedinců - stávají fanoušci jednoho konkrétního systému a na spolupráci kašlou.

    > Pořád píšete, jakoby do Gnome tu závislost na systemd nepřidali vývojáři dobrovolně, jako by je k tomu někdo ze systemd donutil. Ale ani jednou jste nenapsal, jak je k tomu donutili, jaké mají vývojáři systemd páky na vývojáře Gnome.

    A uživatele Windows někdo "donutil" používat Windows? Stál jim za zády s bouchačkou? Ne. Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in. Něco velmi podobného se může stát s linuxovým světem - stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém. Protože OSS je přece o svobodě volby...

  • 1. 5. 2016 23:12

    Filip Jirsák

    Budeme srovnávat portovatelnost init systému, úzce provázaného s kernelem, s nějakou aplikací, která interaguje jenom s knihovnami?!
    Systemd není úzce svázán s kernelem, pouze vyžaduje určité služby od jádra operačního systému. Což je úplně stejné, jako ty „nějaké aplikace, které interagují jenom s knihovnami“ – některé ty knihovny totiž tvoří pouze rozhraní k jádru operačního systému. Pokud dnes systemd používá některé služby, které jsou specifické pro Linux, není problém okolo těch služeb udělat obecnou knihovnu, systemd přepojit na tu knihovnu, a třeba na *BSD tu knihovnu implementovat jiným způsobem, s prostředky příslušného jádra. Nebo je možné nepoužívat příslušnou část systemd, která je na té službě linuxového jádra závislá. A nebo třetí možnost, fňukat, že my to chcem taky, ale nikdo to za nás neudělá, což je hrozně nespravedlivé.

    Tak s tím přestaň operovat.
    Myslíte, že když o té poptávce nebudeme psát, tak zmizí? Pokud k tomu takhle přistupujete, že když je někde nějaká poptávka, vy se tváříte, že ji nevidíte a že tím pádem neexistuje, nesmíte se pak divit, že přijde nějaké systemd, netváří se, že tu poptávku nevidí,a zareaguje na ní.

    A ten důvod může být třeba ten, že většina dister na systemd přešlo a cokoli jiného je mu u prdele.
    Jo, takže vývojář si tak se dí u počítače, a říká si: „Já systemd vůbec nepotřebuju. Ale většina distribucí na něj přešla, tak já schválně do aplikace tu závislost na systemd přidám. Sice mi to nic nepřinese, budu s tím mít akorát práci, ale naštvu tím Prýmka, a top je to hlavní!“

    na spolupráci kašlou
    Pěkně prosím, jak byste si takovou spolupráci představoval? To jako že linuxový komunita vyčlení pár dobrovolníků, kteří budou portovat věci z Linuxu do *BSD?

    Windows se prostě rozšířily
    Pokud vím, bylo to trochu jinak, než že se „prostě rozšířily“.

    staly se monopolem, protože nebyly s ničím kompatibilní a způsobily lock in.
    Jenže ta nekompatibilita a lock in byl záměr a Microsoft se alternativám aktivně bránil. Pamatujete války o souborové formáty kancelářských balíků? Nikdo tenkrát nechtěl, aby Microsoft naprogramoval Office pro Linux – chtěli jsme jenom znát specifikace souborových formátů, abychom si kompatibilní software mohli napsat sami. A i tomu se Microsoft bránil.

    Brání snad někdo zveřejnění API systemd? Nebrání, jak také, když je systemd open source. No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD. Stejně jako jsme nikdy nechtěli, aby Microsoft portoval Office na Linux.

    stačí si představit, že podobně jako Gnome by se zachovali vývojáři různého jiného serverového sw. A juchů, Linux by byl monopolní serverový systém.
    Ale nebyla by to chyba lidí od linuxu, ale těch, kteří nenapsali alternativy, přestože jim v tom nikdo nebránil.

    Protože OSS je přece o svobodě volby...
    No právě. OSS je o svobodě volby. Takže když se jako vývojář rozhodnu, že mi systemd přináší nějaké výhody a vyplatí se mi udělat na něm můj program závislým, je to moje svobodná volba. A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním, nebo dokonce napsat něco lepšího než systemd, co povede k tomu, že opustím závislost na systemd a přejdu na to nové. A nebo tu mou aplikaci upraví tak, aby fungovala i bez systemd, jenom nebude poskytovat ty služby, ke kterým využívá systemd. To všechno je svoboda volby.

    Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD. V tom já ale žádnou svobodu volby nevidím.

  • 1. 5. 2016 23:28

    Lol Phirae (neregistrovaný)

    Systemd není úzce svázán s kernelem, pouze vyžaduje určité služby od jádra operačního systému. Což je úplně stejné, jako ty „nějaké aplikace, které interagují jenom s knihovnami“

    Vidím, že ten odkaz na Lennartovo vyjádření jsi stále nenastudoval a úspěšně pokračuješ v exhibici vlastní debility.

  • 1. 5. 2016 23:29

    M. Prýmek

    > Systemd není úzce svázán s kernelem

    Tak jo no...

    > Myslíte, že když o té poptávce nebudeme psát, tak zmizí?

    Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.

    > No, ale psát alternativy k systemd opravdu není úlohou vývojářů systemd, stejně jako není úlohou linuxové komunity portovat software na *BSD.

    To jsem ani nechtěl. Nebudu to vysvětlovat znova, můžete si to přečíst znovu a pozorněji výš. Jestli něčemu na tom výš řečeném nerozumíte, zeptejte se, třeba jsem se vyjádřil nejasně. Ale opakovat se nebudu.

    > A někdo jiný má zase svobodnou volbu napsat alternativu k systemd se stejným rozhraním

    Problém je, že vy si to představujete jako hurvínek válku. Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu? A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.

    > Vaše představa je asi taková, že by vývojáři systemd měli povinně naprogramovat minimálně dvě alternativy k systemd, a to navíc i pro všechny odnože BSD.

    Ne. Vývojáři systemd si můžou dělat co chtějí. Můžou si do systemd integrovat klidně i Xka (btw, provázání s Waylandem je určitě na spadnutí). Vy to můžete klidně obhajovat. Linus může klidně říct, že k tomu nemá žádný strong opinion. Dělejte si všichni co chcete, jste svobodní lidé.

    Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto. To je vše. A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.

  • 2. 5. 2016 7:00

    Filip Jirsák

    Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
    Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.

    Chápete to, že *BSD je prostě jiný kernel? Že má úplně jiné vlastnosti? Že nejde jenom tak snadno napsat nejakou mezivrstvu emulující chování Linuxu?
    Já to chápu. Ale nechápu, jaké vy navrhujete řešení. Linux má nějaké vlastnosti, které se hodí autorům určitého programu. Napadají mne jenom následující možnosti:

    Autoři toho programu používají Linux, tak tu vlastnost použijí. Pokud bude někdo chtít použít daný program pod *BSD, bude muset příslušnou funkcionalitu implementovat s prostředky *BSD.

    Nebo autoři Linuxu danou vlastnost vůbec neimplementují, protože ji nemá *BSD, a kdyby to někdo použil, byl by jeho program závislý na Linuxu.

    Nebo autoři danou vlastnost implementují do Linuxu, ale zároveň ji povinně implementují i do *BSD, aby použití té vlastnosti neznamenalo závislost na Linuxu. Možná by to měli implementovat i do Windows?

    Nebo autoři danou věc v Linuxu implementují, ale nikdo to nebude používat, aby nevznikla závislost na Linuxu.

    Která varianta je podle vás správná?

    Samozřejmě to platí i opačně, některé věci jsou implementované v některém z *BSD a nejsou v Linuxu, případně se jimi Linux dodatečně inspiruje. Nikdy jsem neslyšel, že by to *BSD někdo vytýkal.

    A že je to úplně zbytečná práce, protože systemd nepřináší nic tak zásadního, aby to nešlo bez toho.
    Vůbec nejlepší by bylo zůstat u děrných štítků. Terminály, klávesnice, dokonce grafická prostředí a myš nepřinášejí nic tak zásadního, aby to nešlo bez nich… Systemd evidentně něco přináší, když to lidé chtějí používat. Vaše neustálé fňukání, ať to vylepšení přestanou používat, protože když ho nemáte vy, nemá ho mít nikdo, je dětinské. Navíc, když to není tak zásadní, tak to přece půjde snadno obejít nebo implementovat jinak.

    Ale já si s dovolením vyhrazuji právo říct, že Linux windowsovatí a že je mi to líto.
    Takže přidání nové vlastnosti je windowsovatění. OK.

    A taky si dovolím vás poprosit, abyste mi nevkládal do úst svoje interpretace.
    Když ono je těžké vás pochopit, když pořád kroužíte kolem toho, že vám vadí, že Linux má nějakou vlastnost, kterou *BSD nemá, a považujete to za chybu linuxové komunity – ale přímo to napsat nechcete.

  • 2. 5. 2016 10:40

    pavel (neregistrovaný)

    Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.
    Klamná indukce a klamná analogie.

    Dokud nebudete konkretizovat tu poptávku po systemd, půjde jen o pouhou spekulaci s nulovou vypovídací hodnotou. Zdroje dokazující existenci ČR si laskavě najděte třeba na Wikipedii, pokud o tom pochybujete.

  • 2. 5. 2016 11:11

    gamer (neregistrovaný)

    Kontrétně třeba GNOME používá logind:
    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/logind.html

    Pokud vím, adekvátní ucelená náhrada k funkcím logind neexistuje. Myslí si to i vývojáři GNOME, a proto logind použili. Jasně, že by si to mohli implementovat sami a znovu, ale proč by to dělali? Prostě usoudili, že majorita jejich uživatelů systemd používá a nebude mít se závislostí na systemd problém. Ti, kteří systemd nechtějí, nebo nemůžou používat, si musí upravit GNOME, nebo napsat ekvivalent logind pro svůj systém. Jestli to bylo dobré nebo špatné rozhodnutí, ukáže čas. Pokud špatné, jejich uživatelé nebudou závislost na systemd akceptovat a přijdou o ně. Pokud dobré, ušetřili si práci při vývoji a můžou se soustředit na vývoj funkcí, které jejich uživatele chtějí.

  • 2. 5. 2016 11:16

    M. Prýmek

    > Pokud vím, adekvátní ucelená náhrada k funkcím logind neexistuje.

    Jaké konkrétně Gnome získal funkce tím, že začal systemd používat? Co přesně umí teď, co předtím neuměl? A to nešlo tu funkcionalitu udělat jako volitelnou?

    Netvrdím, že takové věci neexistují, ale nebaví mě šermování něčím, co asi teda možná existuje, nevím, co to je, ale určitě něco jo a proto je potřeba systemd a žádná jiná alternativa není.

  • 2. 5. 2016 11:24

    gamer (neregistrovaný)

    Oni na to měli dřív svůj vlastní ConsoleKit: https://wiki.gnome.org/Projects/ConsoleKit

    Takže v jednu chvíli byly dvě implementace, které poskytovaly podobné funkce (ConsoleKit a logind). Mohli zůstat nezávislí a paralelně s logind vyvíjet i ConsoleKit. Rozhodli se ušetřit si práci a použít logind, protože se jim zdál lepší. Jak říkám, jestli to bylo dobré nebo špatné rozhodnutí, ukáže čas.

  • 2. 5. 2016 11:28

    M. Prýmek

    No a jsme u jádra pudla: přenositelný ConsoleKit (Linux, BSD, Solaris) byl nahrazen Linux-only systemd.

    P.S. AFAIK to není "jejich [GNOME] vlastní" ConsoleKit. Je to prostě nezávislý projekt ConsoleKit.

  • 2. 5. 2016 11:38

    Filip Jirsák

    No a jsme u jádra pudla: přenositelný ConsoleKit (Linux, BSD, Solaris) byl nahrazen Linux-only systemd.
    No a jsme u jádra pudla. Já si myslím, že ta náhrada vyžadovala nějaké úsilí, a že ji tedy vývojáři provedli proto, že jim systemd oproti ConsoleKitu přinese nějaké výhody.

    Od vás jsem se zatím nedozvěděl, jak měli ty samé výhody se stejným množstvím práce získat jinak.

  • 2. 5. 2016 13:09

    rna (neregistrovaný)

    Ochota a trpělivost některých lidí krmit trolly, kteří jsou schopni v blouznivých horečkách vypotit souvětí ala:"windows se rozšířili a staly monopolem prostě proto, že nebyly s ničím kompatibilní..." je unikátní a raritní. Prospěšnější by bylo jim doporučit teplou stravu a nápoje, placebo s vyraženým nápisem anti-lennart a pravidelné návštěvy obvodního lékaře.

  • 2. 5. 2016 11:59

    gamer (neregistrovaný)

    Ale Lennart nestál u vývojářů s pistolí u hlavy a nedonutil je zahodit ConsoleKit a místo něj použít logind. Logind to vyhrál, protože si vývojáři GNOME myslí, že je prostě lepší. Nabízí jim více funkcí s menším úsilím. Nic víc za tím není. A že díky tomu GNOME přijde o nějaké uživatele? Možná ano, ale zase se můžou soustředit na vývoj jiných věcí, takže ve výsledku je to pro uživatele (smířené se systemd) výhra.

  • 2. 5. 2016 12:14

    M. Prýmek

    > ale zase se můžou soustředit na vývoj jiných věcí, takže ve výsledku je to pro uživatele (smířené se systemd) výhra.

    Jasně, však to je legitimní, můžou si dělat co chtějí.

    Je to stejně legitimní jako proprietární autentizace ve Windows - pro lidi, kteří mají windows a jsou s nimi smíření, je to určitě úplně bezva. A vývojáři v Microsoftu se aspoň nemusí zabývat implementací něčeho přenositelného/kom­patibilního, takže pro uživatele je to jasná výhra.

    Vůbec z Windows je ještě hodně čím se inspirovat. Vložit grafický subsystém do jádra, nebo aspoň do PID 1 by bylo určitě super, spoustu věcí by to zjednodušilo a zrychlilo, takže pro uživatele taky jednoznačně výhra.

    Jo a taky myslím Lael říkal, že COM je daleko vyspělejší než DBUS. Možná by se na něj dalo přejít. Všichni správci linuxů se už těší na hlášky

    Systém událostí modelu COM+ nemohl vytvořit instanci odběratele partition:{41E90F3E-56C1-4633-81C3-6E8BAC8BDD70}­!new:{6295DF2D-35EE-11D1-8707-00C04FD93327}. CoGetObject vrátil hodnotu HRESULT 8000401A.

    :)

  • 2. 5. 2016 12:20

    Filip Jirsák

    Je tu takový drobný rozdíl. Ve Windows si tu proprietární autentizaci nijak nezměníte. V případě Gnome a systemd vám nic nebrání napsat ještě lepší implementaci a portovat na ni Gnome. Dokonce pokud bude o tolik lepší, jako byl systemd oproti předchůdcům, portují na to Gnome jeho vývojáři sami, jak se ukázalo v případě systemd.

  • 2. 5. 2016 12:24

    gamer (neregistrovaný)

    To je hrozná demagogie, s Windows ani proprietárními produkty to vůbec nesouvisí.

    Vývoj každého produktu, včetně GNOME, má za cíl uspokojit s co nejnižšími náklady co nejvíce uživatelů. Majorita uživatelů GNOME systemd používá. Nemají problém s tím, že GNOME na systemd závisí. Naopak vítají, že se vývojáři GNOME můžou soustředit na vývoj desktopu, místo reimplementace funkcí, které dělá systemd. Dostanou totiž lepší desktop. Podpora uživatelů bez systemd by stála vývojáře GNOME čas (peníze).

    Kdo systemd nechce nebo nemůže používat, má volbu. Upravit si GNOME nebo implementovat funkce logind. Všechny informace k tomu má jednoduše dostupné.

  • 2. 5. 2016 12:46

    M. Prýmek

    Však jo, já nic z toho nezpochybňuju. Linux se klidně může úplně vykašlat třeba i na POSIX a začít fungovat úplně jinak, post-unixově. Bude to úplně nový, jiný systém, který už nebude mít s unixem nic společného. Proč ne? Pokud takový systém bude chtít někdo vyvíjet a někdo používat, je všechno naprosto v pořádku.

    Jenom nevím, proč by si lidi, kteří měli Linux rádi kvůli jeho unixovosti a kompatibilitě, nemohli postesknout po starých dobrých časech. Tak nám to dopřej, ne? :)

  • 2. 5. 2016 22:00

    martin (neregistrovaný)

    Zvláštní, že si nikdo nestýská třeba nad SMF. Přitom ve srovnání s tímhle enterprise XML paskvilem je systemd vrchol unixovosti.

  • 2. 5. 2016 11:15

    Filip Jirsák

    Poptávku už jsem dávno konkretizoval. Jsou to všechny ty kritizované přidané závislosti na systemd. Závislost na systemd přidají do své aplikace vývojáři právě proto, že systemd řeší něco, co vyřešit potřebují.

  • 2. 5. 2016 11:02

    hawran.diskuse

    Ne. Myslím, že když něco neumíte konkrétně vyjmenovat, tak byste neměl šermovat s tím, že to na obecné rovině zcela určitě existuje protože a poněvadž pakliže proto.
    Geniální. Tvrdíte, že existuje ČR? Dobře, tak vyjmenujte její obyvatele.

    WTF?
    Ty vole, ta tvoje "argumentace", to je k zblití.

  • 2. 5. 2016 12:51

    rna (neregistrovaný)

    "Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní..."

    Vem si prášek trolle a hodně ho zapij vodou, už meleš úplný hovadiny z hladu a žízně.

  • 1. 5. 2016 19:04

    Lol Phirae (neregistrovaný)

    Co je na systemd tak specifického, že je neportovatelný by design?

    Už to tady máš nalinkováno od samotného velikého guru Lennarta, proč to je neportovatelné. (S tím, že seznam je od té doby asi tak 10x delší.)

  • 2. 5. 2016 7:21

    j (neregistrovaný)

    Ta poptavka po systemd je tak uzasna, ze uz ted znam desitky pripadu, kdy provozovatel radsi zmenil distro nez aby pouzival systemd. A to sme furt jeste ve fazi, kdy jsou starsi verze dister bez systemd pod supportem.

    A duvod je prevazne naprosto primitivni - proste mu to 10 let funguje, ma spousty custom veci, a nehodla investovat tisice hodin do predelavani neceho, jen proto, aby zjistil, ze to nefunguje prave kvuli systemd.

    On totiz realne zadnej admin neni zvedavej na nejake paralelni start sluzeb (to je zlo doslova pekelny), stejne tak neni zvedavej na neco, co mu samo pod rukama bude veci startovat nebo dokonce restartovat ... Jelikoz serverovy selezo 15min+ dela jen post, tak start systemu minutu nebo dve ... nikoho nedojme. Zato kdyz zjisti, ze ma na disku TB binarni blob logu, kvuli kterymu mu doslo misto ...

  • 1. 5. 2016 23:55

    mimi (neregistrovaný)

    tak ono je jedno co se v linuxu implementuje ... BSD to stejne neda kvuli GPL:)

  • 1. 5. 2016 18:04

    Filip Jirsák

    A nejhorší na tom je, že úplně zbytečný.
    Podle vás autoři třeba Gnome jen tak z rozmaru přepisují stávající kód, aby byl závislý na systemd? Nebude to spíš tak, že jim systemd poskytuje nějaké služby, které by jinak museli pracně implementovat, nebo na ně rezignovat – zatímco takhle jednoduše využijí systemd, a sami se mohou věnovat něčemu jinému?

    Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.

    V principu jenom nastavit nějaké parametry systému (locale, hostname apod.), spustit a monitorovat služby apod.
    To, co odlišuje systemd od správců služeb založených na SysVInitu a skriptech je mimo jiné schopnost průběžně reagovat na různé události. Takže nestačí jen služby spustit a monitorovat, ale také jim poskytnout prostředí, ve kterém mezi sebou mohou nějak komunikovat.

    Opakuju: mnoho let existuje OpenRC, launchd, SMF, supervisord ... těch alternativ je spoustu. Není to "hnusné initskripty" nebo systemd.
    Jenže ty alternativy nebyly dostatečné, pořád se snažily tvářit, že je to vlastně SysVinit + skripty (a třeba takové OpenRC pořád je SysVInit + skripty). Autoři systemd se rozhodli zahodit zpětnou kompatibilitu a udělat to znovu a tak, jak odpovídá roku 2016. Nikomu nic nebránilo udělat to před systemd, mohlo se dnes úplně stejně nadávat třeba na launchd.

    ještě jsem neslyšel o ničem, co by řešil a nedalo se to udělat jinak
    Systemd není žádný zázračný software s nadpozemskými schopnostmi. Vše, co dělá systemd, se samozřejmě dá udělat i jinak. Akorát to zatím nikdo jinak takhle komplexně neudělal. Samozřejmě je spousta projektů, které řeší část věcí z toho, co řeší projekt systemd. Ale zatím z nich nikdo tu alternativu systemd neposkládal.

    To je stejně validní argument jako "nic nenutí lidi používat Windows". Pěkně silné "nic"...
    To teda není stejně validní argument. K používání Windows nutí lidi to, že je všichni znají, je vydáván software nebo ovladače jen pro Windows. Když vám partner poskytuje data v proprietárním datovém formátu nějakého programu, který je jen pro Windows, můžete s ním buď přestat komunikovat, nebo používat Windows.

    Systemd je něco úplně jiného. To, že nějaký jiný program používá systemd, vás jako programátora přece vůbec nenutí použít systemd ve svém programu. Když váš program nějak fungoval před příchodem systemd, bude úplně stejně fungovat i na systému, kde systemd běží, i když váš program bude systemd dál ignorovat. Takže autory programů opravdu vůbec nic nenutí vytvářet závislost na systemd. Když ale tu závislost dobrovolně vytvoří, musí pro ně systemd představovat nějakou výhodu. Zvlášť když každý programátor přidává nerad závislosti na cizích projektech a každý je v pokušení, že by si to napsal sám a určitě líp. A přesto programátoři tu závislost na systemd přidají.

    Tvůrci distribucí jsou na tom o něco hůř. Pokud mají nějaký program, jehož autor přidal závislost na systemd, mohou tu část funkcionality odstranit, mohou začít používat systemd, nebo mohou to, co poskytuje systemd, poskytnout danému programu jinými prostředky.

    Jenže odpůrci systemd na něj akorát nadávají, ale že by napsali něco lepšího, to ne. Přitom je to podle nich tak snadné. A autoři po tom rádi skočí, když sáhli o po tom „hrozném“ systemd. Takže jediné, co brání vytvoření lepší alternativy systemd, je to, že když se chtějí odpůrci systemd přepnout do programátorského editoru a začít kódovat, vždy jim to nějak ujede a najednou píšou nenávistný komentář do diskuse. A určitě za to může systemd.

  • 1. 5. 2016 18:22

    M. Prýmek

    > Závislost na Linuxu je problém, ale asi to není problém, který by měli řešit primárně uživatelé systemd na Linuxu. A ta závislost není by-design – když bude *BSD implementovat služby, které systemd potřebuje, jistě nikdo nebude bránit portaci systemd na *BSD.

    Hm.

    Závislost na Windows je problém, ale asi to není problém, který by měli řešit primárně uživatelé Windows. A ta závislost není by-design – když bude Linux implementovat služby, které Windows aplikace potřebují, jistě nikdo nebude bránit portaci aplikací na Linux.

    Jinak zbytek už komentovat nebudu, jenom bych opakoval tohle: http://judecnelson.blogspot.cz/2014/09/systemd-biggest-fallacies.html

  • 1. 5. 2016 18:52

    Filip Jirsák

    Ano, přesně takhle to při portaci Windows aplikací na Linux bylo. To opravdu neřešili uživatelé Windows, ale ti, kdo aplikaci chtěli používat na Linuxu. Museli nahradit to, co bylo specifické pro Windows, něčím, co poskytoval Linux, nebo danou část aplikace oželet, a nebo danou službu implementovat pro Linux.

  • 1. 5. 2016 18:54

    M. Prýmek

    A přesně proto se z Linuxu stalo to, čím byly Windows pro Linux - systém, který myslí jenom na sebe a ostatní je mu u prdele. Samozřejmě na to má kdokoli právo, ale neměl by se divit, že se to lidem, kteří pamatují když byl Linux ve stejné roli, nelíbí.

  • 1. 5. 2016 18:37

    Lol Phirae (neregistrovaný)

    Podle vás autoři třeba Gnome jen tak z rozmaru přepisují stávající kód, aby byl závislý na systemd?

    Viz. Není nad to si pořádně naběhnout na vidle, co, Jirsák?

  • 1. 5. 2016 23:20

    Filip Jirsák

    Kde se tam píše o tom, že tu závislost přidávají jen tak z rozmaru? Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat. Jenže ona se ta závislost nepřidává jen tak z rozmaru, ale proto, že poskytuje nějaké služby, které Gnome skutečně využije. Takže to nejde jen tak odpárat. ale je potřeba ty služby něčím nahradit. Jenže to by tu náhradu někdo musel naprogramovat. A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.

  • 1. 5. 2016 23:36

    M. Prýmek

    > Navíc pokud by byla přidána jen tak pro nic za nic, nebyl by žádný problém ji pro BSD zase odpárat.

    Jistě. Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome. Super nápad! :)

    > A do toho se nikomu nechce, je snazší místo toho fňukat v diskusi, že když mi tyhle služby nemáme, neměl by je mít ani Linux, protože jinak je to od něj nekolegiální.

    Jenže takhle to není. Věci jdou dělat se zřetelem na portabilitu a bez zřetelu na portabilitu. Někoho to prostě zajímá, někoho to nezajímá.

    Podívejte se třeba na nosh - init systém, který z těch podstatných věcí dělá asi všechno co systemd. A s portabilitou nemá problém. Poettering jde ale záměrně cestou "všichni kdo nejste mainstream, polibte mi prdel."

  • 2. 5. 2016 7:03

    Filip Jirsák

    No vidíte. Takže nad nosh triviálně uděláte API kompatibilní se systemd, a máte vystaráno.

    Protože lidi nemají nic jiného napráci než synchronizovat nekompatibilní codebase takového molochu jako je Gnome
    Takže podle vás mají raději plýtvat časem na tom, že budou znovu implementovat to, co už je implementováno v systemd?

  • 2. 5. 2016 14:01

    BoneFlute

    "že budou znovu implementovat to, co už je implementováno v systemd?"
    - a je?

    Teda povim ti, ta tvá demagogie je vysloveně učebnicová.

    systemd není hotové, řeší problémy, které mělo sysv, a má problémy, které sysv nemělo. Takže proč bychom jako měli kejvnout na tvůj dojem, že to, že je v systemd už něco implementováno má nějakou váhu?

  • 2. 5. 2016 14:14

    Filip Jirsák

    Nejde o můj dojem. Jde o dojem všech těch vývojářů, kteří do svých aplikací závislost na systemd přidávají. Zatím nikdo zde v diskusi nepřišel s lepším vysvětlením, než je to pro ty vývojáře výhodné.

  • 2. 5. 2016 14:17

    M. Prýmek

    Ale v tom není sporu, že je to pro ně výhodné. Pro Microsoft je taky výhodné používat telnet s NTLM autentizací místo ssh.

  • 2. 5. 2016 14:27

    Jan Mimránek (neregistrovaný)

    "Nejde o můj dojem. Jde o dojem všech těch vývojářů, kteří do svých aplikací závislost na systemd přidávají. Zatím nikdo zde v diskusi nepřišel s lepším vysvětlením, než je to pro ty vývojáře výhodné"

    Tak já to zkusím.

    Přece pokud děláte softwarové balíčky pro velké distribuce jako je třeba Debian a přejdou na systemd tak musí Vaše balíčky taky, nebo si uberete možnost šířit software pro uživatele. A je pak jedno, co se Vám jako vývojáři líbí, nebo ne. Stejně s Firefoxem třeba, změní API a pokud to neukončíte, tak máte jen jednu možnost, ale těžko se dá jen tak prohlásit, že se Vám nové API líbí a proto na něj přecházíte.

    Disclaimer: nemám statistiku co si o systemd myslí vývojáři, třeba je to půlce i jedno ...

  • 2. 5. 2016 15:43

    Filip Jirsák

    Ne, můj software se v takovém případě nemusí stát závislým na systemd. Nanejvýš můžu přidat unit file, to je ale pouze přidání jednoho textového souboru do distribuce, žádná závislost tím nevzniká. A i kdybych ten unit file nepřidal, správce distribučního balíčku si ho snadno vyrobí sám, takže kdybych chtěl systemd jako autor toho software úplně ignorovat, klidně to můžu udělat, a můj software stejně v Debianu zůstane.

    Takže tímhle způsobem závislost aplikace na systemd určitě nevzniká. Ale oceňuji, že jste se to alespoň pokusil nějak vysvětlit.

  • 2. 5. 2016 15:56

    Jan Mimránek (neregistrovaný)

    Takže když přidám unit file, tak si můžu nainstalovat Gnome?

  • 2. 5. 2016 17:23

    Filip Jirsák

    Asi ne, protože Gnome prý závisí na službách systemd. O tom se tady celou dobu bavíme, jestli existuje nějaké lepší vysvětlení, proč autoři do kódu Gnome přidali závislost na systemd, než to, že jim to přináší nějaké výhody.

    Vytvoření unit souboru závislost na systemd nevytváří. To, že systemd používá nějaký jiný projekt, také závislost nevytváří, a není to důvod, proč přidávat tu závislost do svého projektu.

  • 2. 5. 2016 17:31

    Jan Mimránek (neregistrovaný)

    "O tom se tady celou dobu bavíme, jestli existuje nějaké lepší vysvětlení, proč autoři do kódu Gnome přidali závislost na systemd, než to, že jim to přináší nějaké výhody"

    No vždyť ho říkám. Protože chtěli být na systemd distrech<,/strong> což už ale jsou všechny velké distra, takže taková main line ( A nepodporovat systemd znamená asi jako na mobilech nepodporovat android). Ale aby jsme se netočili v kruhu a rozlouskli jsme to hned:
    Bylo to rozhodnutí podporovat pouze systemd z toho důvodu, že je systemd tak dobrý a nic jiného nemá smysl a nebo po přechodu na systemd by vývoj pro další init systémy znamenalo v podstatě udržovat paralelní forky .... a tak se na to vysr.... ?

  • 2. 5. 2016 17:50

    Filip Jirsák

    Myslíte, že když nechápete, co znamená v software „závislost“, že to lépe pochopíte, když budete psát tučně?

    Protože chtěli být na systemd distrech
    Systemd distribuce je předpokládám distribuce, která jako init systém používá ve výchozím nastavení systemd. V takové distribuci budou samozřejmě fungovat i aplikace, které na systemd žádnou závislost nemají. Třeba bash, vim, Firefox a tisíce dalších programů na systemd žádnou závislost nemají, přesto v „systemd distribucích“ fungují.

    A nepodporovat systemd znamená asi jako na mobilech nepodporovat android
    Ne, neznamená. Aplikace, která nepodporuje systemd, bude na systému se systemd fungovat úplně stejně, jako na systému, kde systemd není.

    Ale aby jsme se netočili v kruhu a rozlouskli jsme to hned
    Nejdřív musíte pochopit, že „podporovat systemd“ a „záviset na systemd“ jsou dvě různé věci, a to, že kdyžje v distribuci systemd, v žádném případě to neznamená, že v té distribuci může být jen software, který je na systemd závislý. Klidně v ní může být dál software, který o systemd vůbec nic netuší.

    Ostatně ono stačí pochopit obecný význam slova „závislost“ – když budete mít v kuchyňce kafe („kafe kuchyňka“), neznamená to, že od té chvíle budou moci v kuchyňce vařit jenom ti, kteří jsou na kafi závislí. Klidně tam mohou být i lidé, kteří kafe vůbec nepijí.

    Bylo to rozhodnutí podporovat pouze systemd z toho důvodu, že je systemd tak dobrý a nic jiného nemá smysl
    Ne, z pohledu vývojáře je přidána závislost na systemd proto, že systemd poskytuje nějaké funkce, které může vývojář využít, a nemusí je sám programovat. To ale neznamená, že bude podporovat pouze systemd – když ty funkce nabídne někdo jiný, umožní použít i tu alternativu. Něco jiného samozřejmě smysl má, akorát to jaksi nikdo nenapsal, protože ti, kteří by k tomu teoreticky měli motivaci, mají plné ruce práce s hejtováním systemd.

    nebo po přechodu na systemd by vývoj pro další init systémy znamenalo v podstatě udržovat paralelní forky
    Dříve používané init systémy neposkytovaly aplikacím žádné služby. Takže aplikaci, která počítá se starými init systémy, je úplně jedno, jaký init sytém se použije, nijak ne tom nezávisí a její kód se nijak nemění. Prostě se vedle té aplikace připraví něco, co ji umí spustit – pro SysVinit shell skript, pro systemd unit file. Takže aplikace, která nechce být na systemd závislá, si může klidně dál nezměněná existovat, nepotřebuje žádné forky, prostě jenom její správce v systemd distribuci pro ni připraví unit file.

  • 2. 5. 2016 18:03

    Jan Mimránek (neregistrovaný)

    Pardon, chtel jsem zvýraznit jednu větu a nevšiml jsem si překlepu "<,/strong>". Pak pardon no. Přečíst to ale snad jde.

    Prosím Vás, nemusíte psát takové dlouhé texty, jen opakujete obecné věci, ale když jsme chytli konkrétní, tak ta kompatibilita kterou proklamujete stejně jaksi neplatí.

    Takže když vezmu staré Gnome tak ho spustím na distru se systemd?
    Alias proč tedy vývojáři nenapsali ten unit file a tím pádem nemají podporu i u ostatních dister, které systemd nepoužívají ale rozhodli se jít do systemd? Co je teda taková výhoda, že se rozhodli být nekompatibilní s ne-systemd systémy?

  • 2. 5. 2016 18:24

    Filip Jirsák

    Prosím Vás, nemusíte psát takové dlouhé texty, jen opakujete obecné věci
    Neopakuju. Význam slova „závislost“ jsem vám vysvětloval poprvé, předtím jsem si myslel, že to slovo znáte.

    ldyž jsme chytli konkrétní, tak ta kompatibilita kterou proklamujete stejně jaksi neplatí
    Ale platí.

    Takže když vezmu staré Gnome tak ho spustím na distru se systemd?
    Myslíte Gnome, které nebylo na systemd závislé? Samozřejmě, že ho v distribuci se systemd spustíte. Stejně jako tam spustíte kterýkoli jiný program, který o systemd nic neví. Jak by asi systemd mohl spuštění toho programu zabránit?

    Alias proč tedy vývojáři nenapsali ten unit file
    Protože vývojáři nechtěli jen ulehčit práci těm, kteří konfigurují správce služeb. Vývojáři chtěli použít služby, které programy z rodiny systemd nabízí. Tím vzniká ta závislost.

    Co je teda taková výhoda, že se rozhodli být nekompatibilní s ne-systemd systémy?
    Už jsem psal, že nevím, co konkrétně to bylo u Gnome. A také jsem psal, že neznám lepší vysvětlení, než že nějaké výhody existují. A zatím nikdo s lepším vysvětlením nepřišel.

  • 2. 5. 2016 18:53

    Jan Mimránek (neregistrovaný)

    "Neopakuju. Význam slova „závislost“ jsem vám vysvětloval poprvé, předtím jsem si myslel, že to slovo znáte."

    No já si samozřejmě prošel vlákno než jsem něco napsal. Ale ok, mě jste to ještě nenapsal ;-)

    Dobře no, takže závěr je takový, že přesto že máte jasno, tak nevíte co k tomu vývojáře vede ale víte, že to co jsem psal to není. Nevadí, třeba se to jednou dozvíme, co se dělo, až zase někdo naštvaný kolem nějaké distribuce začne nadávat a někdo se mu ozve.

    Díky

  • 2. 5. 2016 20:05

    Filip Jirsák

    Jak už jsem psal, to vysvětlení je nejlepší mně známé, nikdo tady zatím lepší nenapsal. To vaše vysvětlení je ve zjevném rozporu s realitou.

  • 2. 5. 2016 20:10

    Lol Phirae (neregistrovaný)

    Aha, takže tvoje vysvětlení je, že to vlastně vůbec nevíš (což ti ale - jak je u tebe zvykem - nebrání na to téma napsat desítky "zasvěcených" komentářů). No tak to se nedivím, že takovému vysvětlení se nikdo nepokouší konkurovat, to tvoje je totiž bezkonkurenčně nejlepší. :-DDD

  • 2. 5. 2016 20:13

    M. Prýmek

    > to vysvětlení je nejlepší mně známé, nikdo tady zatím lepší nenapsal.

    Tak úvodem bych chtěl říci, že nejdůležitější objevy jsem učinil já.

  • 1. 5. 2016 12:26

    Lol Phirae (neregistrovaný)

    Není ale problém do toho zaintegrovat své vlastní nástroje... koncepce, na které staví systemd, v budoucnosti umožní větší variabilitu služeb

    Jirsák opět nezklamal... :-)))))))))))))­))))))))

  • 1. 5. 2016 7:47

    j (neregistrovaný)

    Predevsim je uzasny, ze init ti pusti deravy sitovy sluzby driv, nez nastartuje firewall (a treba taky nenastartuje vubec).

  • 30. 4. 2016 10:31

    klokan

    Řekl bych, že systemd žádná hrůza není, naopak řeší spoustu dlouholetých problémů. Asi jde hlavně o to, že linux se systemd už skutečně není UNIX. Není jím, protože tak v podstatě zní zadání: odpoutat se od *nixových konvencí a tradice a vyvíjet novou, postunixovou platformu. Dle mého názoru je to cíl velice žádoucí a vítaný, ale je pochopitelné, že ten, kdo chce v Linuxu vidět implementaci *nixu a jako takový ho používat, ten bude o systemd neustále zakopávat.

    K tomu slavnému "dělat jednu věc a dělat ji dobře": ono to zní hezky, ale v praxi jsou věci často jinak. Takovéhle principy dávají smysl, když programujete shellové příkazy, ale přece jenom máme rok 2016 a většina lidí si neinstaluje linux proto, aby v něm mohla dělat ls a mkdir. V moderním systému je důležitá INTEGRACE... a proto máme systemd.

  • 30. 4. 2016 10:53

    Jan Mimránek (neregistrovaný)

    Aha, zajímavé. No jasně, akorát si právě nejsem jistý, když použiji příměr teda - jestli u "lin. auta", kvůli výměně startéru neměníme všechno až po zadní rozvodovku a ještě k tomu od automobilky, která jede hlavně na vlastní triko

  • 30. 4. 2016 11:09

    klokan

    To je váš názor. Neúčastním se vývoje systemd, ale mám dojem, že se řídí spíš heslem, že je nejvyšší čas zkonstruovat pořádnou rozvodovku a přestat věčně bastlit a fušovat tu co kdysi byla na wartburgu :)

  • 30. 4. 2016 11:58

    Jan Mimránek (neregistrovaný)

    Jasně, jako potřeba zásahu tu 100%pro byla, ovšem je otázka kolik a za jakou cenu. Proto jsem se právě ptal, protože v tom mám trošku guláš i kvůli tomu, že se objevují fakt protichůdné tvrzení a protože v tom nedělám, tak na to nemám tolik času abych si udělal opravdu fundovaný názor sám ....

  • 2. 5. 2016 13:27

    rna (neregistrovaný)

    :"tak na to nemám tolik času abych si udělal opravdu fundovaný názor sám ...."

    ....a skončil u nekonečného krmení trollů, od kterých jsme se místo fundovaného názoru dozvěděli, že "Windows se prostě rozšířili a staly monopolem, protože nebyly s ničím kompatibilní..."

    S tím časem to zdá se nebude zase až tak zlé:-)))

  • 2. 5. 2016 13:31

    M. Prýmek

    A co jsme se dozvěděli od tebe? Podal jsi nějaký argument, v čem je ta citovaná věta chybná? Ne. Vystačil sis s tím, že jsi ji 3x zopakoval. Tak jo no, doufejme, že budeš takto obohacovat diskusi i nadále :)

  • 2. 5. 2016 16:31

    rna (neregistrovaný)

    Čti pozorněji, jak sám ostatním doporučuješ, a dozvíš se!

    Bez pardonu pro extra trolly extra znovu: pokud autor výroku :"Windows se prostě rozšířily a staly se monopolem, protože nebyly s ničím kompatibilní..." není na drogách, tak nutně potřebuje do stínu, napít, najíst a dát si neodkladně od práce delší pauzu, dost možná po poskytnutí výše uvedeného vyhledat lékařskou pomoc.

    PC´s jsem prodával a upgradoval opravdu všelijak (ne)nadaným uživatelkám, které se ptaly na opravdu zarážející věci, ale takovouhle debilitu nedokázala zplodit ani ta nejméně nadaná z nich.

    Vyser se na třídenní trollení pomocí argumentů, které neprojdou ani u osmáka ze ZŠ, odlož všechny podružné úkoly okolo železa a zkontroluj základní životní funkce a pitný režim, tvým nejzákladnějším biochemickým procesům akutně hrozí panic kernel.

  • 2. 5. 2016 16:33

    M. Prýmek

    Zbytečně moc textu. Stačilo napsat "ne, nejsem schopný napsat konkrétní důvod. Raději ti budu nadávat, protože jsem anonymní king."

  • 2. 5. 2016 17:46

    rna (neregistrovaný)

    To by fakt úplně a opravdu stačilo, ani ses na to nemusel logovat a pouštět se do unikátního rozboru s ještě raritnějším závěrem, kterak redmondská firmička světem operačních systémů zamotala. Naneštěstí jsi rozhodl opačně.

    Mimochodem "moc textu..." napsal vážně člověk, co tu tři dny blije po těžkém úpalu kvalitu typu "Windows se rozšířily až do monopolu kvůli nekompatibili­tě..."???

    Vážně? To je ten tvůj stav ještě mnohem horší, než jsem si myslel.

    A kdybys dělal to, co doporučuješ ostatním, tj. pozorněji četl, pro začátek třeba po sobě to, co sám píšeš, mohl sis ty tři dny blitek a průjmu nesmyslů v kvalitě, kterou nezplodí ani dvacetiletá personalistka u spořiče, ušetřit. Natož to vydávat za postesknutí.

    A to nemluvě o doporučení ostatních, kteří ti už 3 dny naznačují, že namísto těchto perel rootu, které by měly i s autorem viset v perexu minimálně na rok, ten čas u open source nikdo nikomu (čili ani tobě) nebrání využít k napsaní něčeho lepšího, než je systemd.

    Ale chápu, po tak těžkém úpalu mezi průjmy a blitím se programuje těžko.

    Zatím jsi nám v horečkách vyzradil, kterak geniálně Bill všechny ostatní pochcal od hlavy až k patě zákeřnou nekompatibilitou.

    Jestli se tvůj stav nelepší a na tomto výblitku stále trváš (což je velmi varovné pro tvoji prognózu), pokračuj ve stejném duchu i další dny, co se dá dělat, kódování je opravdu pro ty, kdo jsou fyzicky v jakés takés biochemické normě.

  • 30. 6. 2016 2:35

    rna (neregistrovaný)

    ...není důležitý, soudruhu! Podstatný je, zda se ulevilo lidem, který blili v horečkách :"Windows se rozšířili kvůli nekompatibilitě..." atp. a trvali na tom několik dní v kuse... Protože jestli je to drží dodnes, ja to s nima zlý, tuze zlý. Nejen pro tuto sezonu...

  • 30. 4. 2016 11:53

    bastlir (neregistrovaný)

    Chci upozornit na vasi falesnou argumentaci. Davate do opozice business pozadavky "dělat jednu věc a dělat ji dobře" s "INTEGRACE" v kontextu spousteni a behu operacniho systemu.

    Pominu-li siroky pojem terminu integrace, vami pouzita opozice nema zadnou souvislost.

    Prvni je pozadavek na jednoduchost a potazmo kvalitu komponent.

    Druhy je pozadavek na potrebu takove komponenty vhodne kombinovat (pri pouzivani/spousteni OS).

    SystemD je odpoved/imple­mentace na nevuli nebo neschopnost autoru navrhu takoveho integracniho reseni naplnit pozadavek prvni. Spravne namisto aby rekli, neumime to, nevime, reknou business requirement je spatny a proto na to kasleme a slepime si to po svem.

  • 1. 5. 2016 1:40

    klokan

    Máte to obráceně. Princip "dělám jednu věc..." není žádný business requirement. To je implementační doktrína která, jako všechny doktríny, má svůj velký smysl pro úzce vymezený typ zadání (a opravdu jenom pro úzce vymezený typ zadání). Systemd je snaha řešit skutečný business requirement a tím je automatizace správy služeb, vylepšení "plug and play" a usnadnění provozu uživatelských aplikací tam, kde se konfigurace systému dynamicky mění za běhu, např. na tabletu, na serveru v případě živé migrace apod.

    Z toho vyplývá, že systemd - možná narozdíl od starého sysvinit - není komponenta systému, nýbrž framework. Samozřejmě, že každá jeho subkomponenta může dělat jednu věc atd... a také tomu tak do značné míry je, ale když s požadavek rozeberete, zjistíte, že aby to fungovalo, je k tomu potřeba podpora system-wide asynchronních událostí, včetně možnosti, aby takové události odchytávaly nebo i generovaly uživatelské aplikace. Je k tomu potřeba, aby si jednotlivé komponenty i aplikace mohly předávat zprávy formou strukturovaných dat. Je potřeba API, aby bylo možné takový systém a služby konfigurovat programově. Atd, atd. No a pochopitelně aby to celé mělo smysl, je nutné staré komponenty nahradit takovými, který tento framework podporují, a tím pádem je v obraze udev, dhcp, ntp, mount, logind. Proto říkám, systemd není zásahem do UNIXu, je to poslání UNIXu do důchodu a jeho nahrazení jinou platformou.

    Nemusíte Lennarta a vývojáře systemd zrovna milovat, ale neschopní hlupáci to opravdu nejsou. Trvat na tom, že se takový systém musí implementovat buď čistě "unixově", tj. výhradně pomocí nekooperujících a nekoherentních programů jednosměrně si předávájích čirý text skrz roury, a nebo vůbec, protože v roce 1969 to tak u Bell Laps kdosi sbastlil a od té doby se už tím pádem nic jiného používat nesmí, to není žádný business requirement, ale holá pitomost.

  • 30. 4. 2016 18:21

    pavel (neregistrovaný)

    Řekl bych, že systemd žádná hrůza není, naopak řeší spoustu dlouholetých problémů.

    Řeší spíš neexistující problémy. S Linuxem dělám už skoro dekádu a se zaváděním systému, konfigurací sítě a spouštěním démonů (po novu služeb) žádné významné problémy nebyly, ani se "službami" které závisely na jiných jako samba nebo nfs. Stovky produkčních serverů, spousta desktopů a problémy s funkcionalitou byly úplně jinde - chybějící podpora hardware, nedostatečná podpora výměnných formátů, chybějící aplikace pro určitý okruh problémů, regrese po upgradu vč. kernelu, rychlost začleňování záplat.
    Některé distribuce jako Debian nebo RH/Fedora nezvládly udržet jednoduchost a koncepčnost init skriptů, ale to není problém SysV nebo BSD initů ale konkrétních případů (ne)schopnosti a špatné organizace. V Gentoo, Slackware nebo Archu se to v žádné spaghetti skripty nezvrhlo. O OpenBSD nebo FreeBSD ani nemluvě.

  • 30. 4. 2016 21:05

    Pavel Šimerda

    Právěže řeší i některé problémy (například se správou služeb a jejich procesů), na které si mnozí linuxáci holt nějak zvykli. Viníkem jsou podle mě ti, kteří ty problémy dlouhodobě přehlíželi a zanedbávali a tím dávali prostor k takovým akcím jako je systemd. Dneska máme takový výsledek, jaký máme.

    Gentoo má docela hezky dělané initskripty, ale taky to není až takový zázrak. Třeba ty psí kusy s integrací NetworkManageru s OpenRC, to je vyloženě prasárna. Kecy o jednoduchosti a bezproblémovosti SysV initskriptů mě docela baví. Neříkám, že je systemd ideální řešení, spíš je to výsledek ignorování nedostatků stávajících systémů.

  • 30. 4. 2016 23:07

    M. Prýmek

    > spíš je to výsledek ignorování nedostatků stávajících systémů.

    Asi jde docela i o to, jakých přesně problémů jakých systémů. Existuje launchd, existuje SMF. Nejsem si úplně jistý, jestli bylo potřeba vynalézat kolo. A pokud bylo potřeba, pak nejspíš kvůli problémům, které trápí především desktop. Serverům to afaik nic moc nepřinese a spousta věcí se začne rozbíjet - z pohledu serveru úplně zbytečně. A tohle je podle mě motivace lidí za Devuanem.

  • 1. 5. 2016 5:15

    klokan

    SMF? Jestli tím myslíte ten krám ze solarisu, tak to bych zrovna jako vzor neuváděl. Podle mého je to dokonalý příklad Enterprise humusu, u kterého není až tak jasné, co doopravdy přináší kromě toho, že se jim konečně podařilo do toho nějak narvat XML.

    O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný - přesněji řečeno, systemd se silně podobá launchd, který je starší. Rozdíly jsou hlavně v implementaci. V launchd procesy komunikují přes Mach porty, v systemd přes dbus. Kromě toho má systemd některé linuxové fičury navíc, jako je využití cgroups (což je velmi užitečné). Pokud vás ale uklidní, že systemd je až na pár drobností kopie launchd pro linux, tak mu tak klidně říkejte a žijte blaze :)

  • 1. 5. 2016 11:16

    M. Prýmek

    > není až tak jasné, co doopravdy přináší

    ??? Přináší v principu totéž jako systemd. XML není šťastná volba, ale taky není nijak nutné - viz např. https://github.com/mheily/jobd - reimplementace launchd, místo XML používá JSON. Stejně tak by tam mohl být třeba YAML, no problem.

    > O launchd si něco přečtěte a zjistíte, že si je se systemd velmi podobný

    No a co jsem asi napsal? Launchd je systemd velmi podobný, čili nebylo potřeba vymýšlet další nekompatibilní kolo, mohl se vzít launchd, poupravit, vylepšit a bylo by. Mohl vzniknout portabilní init systém, který by nezpůsobil takové vlny a nevytvářel z Linuxu nekompatibilního solitéra.

    "Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4

  • 2. 5. 2016 2:32

    klokan

    > mohl se vzít launchd, poupravit, vylepšit a bylo by.

    Ne, nebylo by. Launchd má licenci Apache, ne GPL, což u tak klíčové součásti linuxového prostředí je dost zásadní problém. Možná se mýlím, ale pokud vím, ač je licence Apache dost permisivní, není to BSD a přelicencovat pro potřeby linuxu celý launchd pod GPL by nešlo - nehledě na to, že i kdyby to teoreticky šlo, neumím si představit ten řev. Některým lidem se prostě nikdy nezavděčíte.

    > nevytvářel z Linuxu nekompatibilního solitéra.

    To je dost diskutabilní. Nekompatibilní s čím? A z jakého pohledu? OSX je dodnes jediný systém s launchd, je to teda taky nekompatibilní solitér? Asi je, ale komu to vadí? Anebo dneska, kdy v podstatě všechny velká distra používají systemd, je takovým solitérem... Devuan, který je nekompatibilní s mainstreamem právě proto, že systemd nemá? Anebo FreeBSD, které nemá systemd ani launchd, ale svůj vlastní BSD init, který taky není kompatibilní se sysv, jak ho dříve používal linux?

    Chci tím říct, že to je z mého pohledu čistě subjektivní argument a že v podstatě vůči jakémukoli software na světě se dá vznést námitka, že je špatný, protože vytváří nekompatibilitu s těmi, co ho nepoužívají.

    > "Post-unixový" Linux je možná pro někoho příjemná myšlenka, nicméně https://plus.google.com/+MiroslavPrymek/posts/VYf2W8WXrj4

    Přiznám se, že nevím, co tím chtěl básník říci. Každý má své důvody, já jsem kupříkladu už před neuvěřitelnými 23 lety neutekl od Windows proto, že to není unix, ale proto, že to je monopolistický proprietární systém a že záviset na něm znamená vydat se na milost a nemilost jisté notoricky hostilní a podraznické firmě. Linux byl, je a vždycky bude open source, ať už se systemd nebo bez něj, takže to mě tolik nepálí. Jestli ale systemd usnadní vývoj aplikací, užívání a nasazování linuxu pro uživatele, kterým jde možnost číst bezpečně maily, sledovat videa, prohlížet si fotky a psát články, a ani ne tak si hrát na pravoslavné unixové sysadminy, tak to bude záslužný počin.

  • 2. 5. 2016 7:07

    Filip Jirsák

    Proč to tedy s launchd neuděláte? Vemte, poupravte, přidejte API kompatibilní se systemd, a máte vystaráno. Nebo vemte, poupravte, udělejte lepší než systemd a systemd převálcujte.

  • 30. 4. 2016 21:50

    mimi (neregistrovaný)

    a proto mi gentoo jelo lepe se systemd :)

    ano .. Arch je davno systemd only

    Slackware .. :) dane Patrickem a znacne omezenym setem balicku

  • 2. 5. 2016 11:04

    pavel (neregistrovaný)

    a proto mi gentoo jelo lepe se systemd :)
    To ti neberu, i kdyz by me zajimalo z ceho vyvozujes ze "lepe".

    ano .. Arch je davno systemd only
    Arch presel na systemd, ale to neni v rozporu s tim ze jeho BSD-like init skripty byly prehledne a jednoduche a nepredstavovaly zadnou prekazku nebo omezeni funkcionality.

    Slackware .. :) dane Patrickem a znacne omezenym setem balicku
    A pointa ? Na slackbuilds.org je dalsich cca 6.000 balicku, cast z nich instaluje svoje init skripty a zadne problemy tim nezvnikaji. Sluzby se implicitne nespousti, skripty jsou navzajem ortogonalni, ve vyjimecnych pripadech je nutne specifike nastaveni systemu, ktere je popsano v instalacnim readme.

  • 30. 4. 2016 21:00

    Pavel Šimerda

    Nějak mi není jasné v čem má být ten rok 2016 tak jiný než třeba rok 2006 a už vůbec ne co se týče používání stroje s linuxem. Osobně jak ls, tak mkdir používám dodnes.

  • 30. 4. 2016 21:32

    Jan Mimránek (neregistrovaný)

    Myslím že tím chtěl říct, že v roce 2006 nebyl linuxový desktop tak vyspělý a vybavený, aby ho opravdu využívali lidi, kteří do konzole fakt nelezou, jako třeba moje přítelkyně, nebo třeba měli jsme dobrého Java vývojáře, který prostě znal v lin. konzoli jenom příkazy pro Javu, kvůli kompatibilitě s námi jako ostatními vývojáři v jednom kanclu měl Ubuntu ale jinak doma vše Win. Prostě do konzole nelezl a jednou za měsíc když bylo fakt něco potřeba, tak mu do toho na 5 min. někdo přes konzoli hrábl, servery nedělal. A takových lidí je podle mne spousta a ti nepoužívají mkdir a ls. Ale možná jsem tu jeho poznámku špatně pochopil. Znám prostě hodně lidí, co mají lin fakt jako jenom desktop a o konzoli nic neví a nepotřebují to, nebo potřebují tak často, jako běžný uživatel na Win.

  • 30. 4. 2016 22:45

    Jan Mimránek (neregistrovaný)

    Tak pro Vás to asi takový význam nemá. Pro mě asi taky ne, jsem v konzoli každý den ale jsem i na "desktopu" a on právě reagoval na to moje "dělám jednu věc a dělám ji dobře".
    No já jen že asi vím jak to myslel, ale osobně si nemyslím, že ten princip musí být v rozporu, pokud jde o plynulou funkci celku. Slovo "integrace" nemám rád, protože často je zaměněno za výrobu jednoho velkého blobu. Spíš by byla potřeba určitá standardizace požadavků a očekávaných výstupů aby se dalo jednoduše dosáhnout plynulé funkčnosti. LSB, kolik toho řeším přiznám nevím, ale co jsem se zatím dočetl, tak se ne tak úplně dodržuje. Ale nejsem aktivní vývojář, jsem jen aktivní uživatel ....

  • 1. 5. 2016 1:54

    klokan

    Já je používám taky, ale chci tím říct, že v dnešní době většina uživatelů instaluje linux proto, že v něm náhodou funguje aplikace, kterou potřebují. Klasický *NIX nikdy nebyl "platformou" v pravém slova smyslu, původně nikdo ani nepočítal s tím, že by měl podporovat hotové aplikace třetích stran, a Linux je dnes pod tlakem se takovou plnohodnotnou platformou stát. Osobně Lennarta neznám, ani nemám akcie u Red Hat, a už vůbec netvrdím, že systemd je nejlepší možné řešení tohoto požadavku. Realita ale je, že dosud je to jediné řešení. Všechny alternativy, které jeho odpůrci prosazují (sysv, openrc atd...) jsou vedle, protože zásadně vycházejí z předpokladu zachovat stávající unixové status quo a na požadavky, kterým se systemd snaží vyjít vstříc, neodpovídají vůbec.

  • 1. 5. 2016 11:28

    M. Prýmek

    > na požadavky, kterým se systemd snaží vyjít vstříc, neodpovídají vůbec.

    Mohl byst uvést tři takové požadavky? A ideálně i kdo a proč je požaduje.

  • 2. 5. 2016 2:05

    klokan

    Požadavek 1: mít API, aby šlo systém, služby, uživatelská sezení atd. ovládat a monitorovat programově. Pokud vím, minimálně na Linuxu má API jenom systemd.

    Požadavek 2: integrace mezi různými typy událostí. Příklad: chci si nastavit (jako běžný uživatel, ne root), aby ve chvíli, kdy si připojím svůj záložní USB disk, se mi automaticky zálohoval adresář s dokumenty každou hodinu. Jak toho dosáhnu v klasickém unixu? V podstatě nijak. Jako běžný uživatel nemůžu ani instaloval službu, ani zachytit událost připojení konkrétního USB zařízení. Ale i kdybych mohl, bylo by to málo platné, protože neexistuje způsob, aby program nebo událost nastartovala nebo zastavila daný cronový úkol. Nemluvně teda o tom, že v zásadě neexistuje ani spolehlivý způsob, jak z pozice běžného uživatele zjistit, zdali je připojen jeden konkrétní USB disk. V systemd tohle jde, v sysvinit absolutně ne, v openrc se přiznám, že nevím, ale nejspíš taky ne.

    Požadavek 3: Možnost JEDNODUŠE omezit CPU a pamět pro danou službu. V systemd to jde díky podpoře cgroups.

    Stačí, nebo jich chcete patnáct dalších? ;-)

  • 2. 5. 2016 7:28

    j (neregistrovaný)

    1) /etc/init.d/apache2 start/stop/restart ... ti nestaci? Systemd zadny API nema, protoze je to asi tak stejny, jako kdyby si chtel zapisovat sektory primo na disk - na kazdym to bude jinak.

    2) aha, ty zvanis a vubec netusis ... pokud ti root nastavil, ze k USB muzes, tak samozrejme muzes ...

    3) systemd a cgroups nemaji nic spolecnyho ...

  • 2. 5. 2016 7:53

    Ondra Satai Nekola

    1) Nestaci. Navic to nefunguje.

    3) systemd cgroups pouziva a diky tehle kombinaci je dost nastavovani omezeni celkem trivialni

  • 2. 5. 2016 8:32

    M. Prýmek

    > Nestaci. Navic to nefunguje.

    To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd. Ve FreeBSD je většina funkcionality výborně vyřešená a daná do společných souborů. Takže typický init skript služby pak už připomíná spíš jenom tu deklaraci podobně jako ji má systemd - viz např. https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-daemon.html - takhle málo stačí pro implementaci init scriptu, i s podporou dependencies.

    Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh).

    > systemd cgroups pouziva

    Na tom není nic špatného. Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS.

  • 2. 5. 2016 8:42

    Ondra Satai Nekola

    "To, že spousta linuxových distribucí má prasácké init skripty, není argument pro nutnost systemd."

    Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.

    "Kromě toho samozřejmě existuje několik (!) init systémů, které fungují stejně jako systemd, ale nemají jeho nevýhody (např. ten zmíněný nosh)."

    Ja netvrdim, ze systemd je jedine reseni (prestoze mne vyhovuje). Jenom to, ze sysv uz vazne ne. Ale samozrejme mas pravdu - tech reseni je vic.

    "Špatné je, pokud je nutně potřebuje a navíc ještě třeba probublají do API a následně do aplikací, které se tím stanou nejenom závislé na jednom init systému (úlet samo o sobě), ale i na jediném OS."

    Uprimne - nevim. Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.

  • 2. 5. 2016 8:55

    M. Prýmek

    > Nevim, zda by init mel byt ve krehky ve smyslu ze nutne potrebuje bezchybne init scripty.

    Tomu nerozumím. Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?

    > Nikdy mne nenapadlo moc resit, ze Mail.app funguje jenom na Mac OS X, ale zase chapu, ze kdyz nekdo pouzival xBSD, tak asi bude rozcarovany, ze pro nej nekteri lide prestali delat soft.

    To je úplně jiný případ. Mail.app je proprietární aplikace a závisí na veliké proprietární knihovně.

    Jde spíš o ten princip, proč ta aplikace nejde spustit jinde - jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda. Můžu jenom doufat, že většina vývojářů to za chybu bude považovat a takovou zbytečnou závislost s velkým dopadem si do softu nezavlečou - i když na to, jak říká Filip, mají právo, o tom není sporu.

  • 2. 5. 2016 9:05

    Filip Jirsák

    Chyba v init skriptech způsobuje úplně stejné problémy jako chyba ve zdrojácích jakéhokoli init systému. Jaký je rozdíl?
    Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.

    jestliže je to jenom kvůli závislosti na pár funkcích init systému, které se daly udělat jinak, je to prostě škoda
    Co vám brání udělat to jinak?

  • 2. 5. 2016 9:09

    M. Prýmek

    > Rozdíl je v tom, že administrátor neupravuje zdrojáky init systému, ale pouze jeho konfiguraci.

    A proč by měl admin upravovat init skripty? Když chci třeba spustit na FreeBSD nginx, tak dám do /etc/init.rc jeden řádek
    nginx_enable="YES"
    a pokud chci upravit nějaké parametry, tak třeba něco ve stylu
    nginx_chroot="YES"
    - je to principiálně úplně stejně deklarativní popis jako unitfile.

    > Co vám brání udělat to jinak?

    Proč bych to měl dělat jinak, když už jiná řešení existují? Už jste se podíval na to nosh?

  • 2. 5. 2016 21:05

    j (neregistrovaný)

    Zasadni rozdil je v tom, ze v tom scriptu si to snadno opravis, kdezto v initu ne.

  • 2. 5. 2016 8:48

    klokan

    1. Skripty nejsou API, to se na mě neráčej zlobit. Systemd API má, viz https://www.freedesktop.org/wiki/Software/systemd/dbus/. A pokud jsem si všiml, tak API pro zápis na disk náhodou máme.

    2. Evidentně jsi to nepochopil. Že můžu na USB je irelevantní. Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)? A pokud na tohle řešení máš, jak to udělám, aby v tu chvíli začala jistá operace pravidelně probíhat každou hodinu? Doufám, že mi nechceš vážně navrhnout nějak fušovat crontab pomocí sed a awk...

    3. Tak se informuj. Systemd funguje jako správce cgroups (ekvivalent cgmanager ve starších distrech) takže s ním nejen velmi úzce souvisí, ale taky takovou operaci triviálně umožňuje.

  • 2. 5. 2016 9:00

    M. Prýmek

    > Skripty nejsou API, to se na mě neráčej zlobit.

    Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.

    > Jak to udělám, abych věděl o tom, že právě byla připojena moje záložní flashka (a ne jiná)?

    Matchováním tam, kam to patří - v hotplug subsystému. Root tam může dát skript, který může udělat cokoli, včetně spuštění uživatelského skriptu.

    > Tak se informuj. Systemd funguje jako správce cgroups

    Pointa je v tom, že cgroups se dají použít i bez systemd. Čili argument "chceme cgroups" je irelevantní pro otázku "potřebujeme systemd?"

  • 2. 5. 2016 9:20

    klokan

    > Api není problém vytvořit pro jakýkoliv init systém, pokud by to bylo potřeba. Viz např. API supervisord.

    Takže neustále "není problém vytvořit, šlo by kdyby" atakdále. Vytvořené není, tudíž to momentálně nejde. Tečka.

    > "Root tam může dát skript, který může udělat cokoli..."

    Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript, tak jste mě rozesmál. Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.

  • 2. 5. 2016 9:27

    M. Prýmek

    > Vytvořené není, tudíž to momentálně nejde. Tečka.

    Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví.

    > Jestli Vaše odpověď na sice záměrně zvolený, ale jinak banální a legitimní scénář pro BFU je, že to sice normálně nejde, ale za to root někam může dát skript,

    Jak "normálně nejde"? Jde to. Tím skriptem. Na unixech se věci řeší skripty.

    > Navíc neřešíte otázku, jak ten skript nahodí a zruší časovanou službu, když cron nemá API a init neumožňuje provozovat uživatelské služby.

    Samozřejmě že to jde. Opět: vhodně napsaným skriptem.

    Ale jinak námitku neexistence API ke cronu beru. Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše. Ne tím, že se cron včlení do initu.

  • 2. 5. 2016 10:05

    klokan

    > Ne. Vytvořené to je, např. Upstart má dbus api. tudíž to momentálně jde už hezkých pár let. Akorát někteří lidi o tom neví

    Ano, upstart má (omezené) API, lépe řečeno měl, protože už se nepoužívá. Mimochodem všechny (pseudo)argumenty proti systemd se svého času stejně zuřivě používaly i proti upstartu, jak si možná pamatujete. Navíc hlavní hateři systemd nikdy neprosazují upstart, a vždycky sysvinit nebo openrc.

    > Jak "normálně nejde"? Jde to. Tím skriptem.

    Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)

    > Na unixech se věci řeší skripty.

    Což je jeden z důvodů, proč si unix zasluhuje odpočinek (minimálně pokud jde o linux).

    > Pokud je to problém, bylo by fajn ho řešit tím, že se API do cronu dopíše.

    Tak jestli to někdy bude, tak se rád podívám. Do té doby na to máme systemd.

  • 2. 5. 2016 10:10

    Lol Phirae (neregistrovaný)

    > Na unixech se věci řeší skripty.
    Což je jeden z důvodů, proč si unix zasluhuje odpočinek (minimálně pokud jde o linux).

    Ano, nebudem to řešit skripty, to je přece fuj a zastaralé. Vyřešíme to statisíci řádku ve zkompilovaném molochovi neustále bobtnajícím o nové funkce naprosto nesouvisející s init-em, se kterým v případě problémů nikdo nenadělá vůbec nic. Hlavně že to je moderní!!!! Aneb mlamoj opět zasahuje. #facepalm

  • 2. 5. 2016 11:43

    klokan

    > Ano, nebudem to řešit skripty, to je přece fuj a zastaralé.

    Když jde o to, pořád znovu vynalézat kolo a skriptovat věci, které jsou dneska holá samozřejmost a moderní OS je má umět out of the box, tak to je zastaralé. To vám klidně podepíšu.

  • 2. 5. 2016 11:46

    M. Prýmek

    Ale tady se nebavíme o něčem, co má systém umět out of the box. Bavíme se o tom, že uživatel chce po vložení nějakého zařízení udělat nějakou custom akci. Buď tu custom akci definuju pomocí skriptu, nebo nějakého jednoho řádku v uživatelově cronu, nebo pomocí vytvoření systemd služby. Každopádně musím něco vytvořit.

  • 2. 5. 2016 10:44

    M. Prýmek

    > Jak sám říkáte, nejde to bez zásahu roota a dost netriviálního bastlení (a to nechci ani pomyslet na race conditions a jiné možnosti katastrofy při tom skriptovém vrtání se v crontabu)

    Zásah roota je nutně potřeba, to je správně. Jak jsem už řekl: bez něj by mohl uživatel komukoli nepozorovaně zkopírovat data.

    O jakém "netriviálním bastlení" je řeč? Napadá mě několik způsobů, jak to udělat:

    1. pod daným uživatelem je spuštěn skript, který provede zálohu a pak danou dobu čeká

    2. flashka se mountuje do přesně daného umístění. V uživatelově cronu je úloha, která očekuje, jestli je přimountovaná a zálohuje. Když ne, končí.

    3. konfigurace cronu je rozělena do více souborů (např. ~/.config/cron.d), při vložení flashky se konfigurační soubor přejmenuje z "bcp.conf.disabled" na "bcp.conf"

    4. totéž jako 2, ale cesta k mountpointu flashky se zapíše někam do souboru

    ... a bambiliony jiných možností...

    Nikde nevidím žádné "netriviální bastlení", všechno jsou to věci na jeden řádek.

  • 2. 5. 2016 11:29

    klokan

    Asi vám uniklo to hlavní: Frantu Uživatele zajímá, jestli se mu zálohují fotky. Jestli to je nebo není unixové je mu u onoho. Se systemd to jde triviálně a hned. Vaše "lepší" řešení bez toho "strašného" systemd spočívá v tom, že Franta nejdřív provede nebo nechá provést rootový zásah do OS, nastaví nový match pro udev a pak se pustí do vývoje vlastního démona, přičemž se předpokládá, že je dostatečně zkušený programátor, aby věděl, jak démona spolehlivě zabít nebo restartovat a jak se vyhnout race conditions. Případně milion jiných možností, které sice nefungují, protože unix potřebné funkce nemá, ale teoreticky by šlo je do něj implementovat.

    To jako myslíte vážně?

    (Na okraj: není pravda, že je na to potřeba root. USB se běžně automaticky mountuje s uid a gid namapovanými na toho, kdo je zrovna přihlášen na konzoli. Tak to bylo už před systemd a je tomu tak i teď. Vaše přístupy ostatně v tomto ohledu absolutně nic nemění)

  • 2. 5. 2016 11:34

    M. Prýmek

    Pokud Franta používá systém, který mu flashku automaticky namountuje, tak už vůbec systemd nepotřebuje. Prostě má cronjob, který zkontroluje, jestli je flashka přimountovaná a podle toho pak zálohuje nebo nezálohuje. To je jeden řádek. Jak to udělá pomocí systemd, že to je o tolik snadnější?

  • 2. 5. 2016 11:40

    Lol Phirae (neregistrovaný)

    To je jeden řádek. Jak to udělá pomocí systemd, že to je o tolik snadnější?

    To je přece úplně triviální. Třeba takhle (zřejmě zastaralé) nebo takhle s použitím timers - což je znovuvynalezený cron aneb Lennart a jeho NIH syndrom.

    Všimni si, že to je tak ohromně jednoduché a intiutivní, že to vyžaduje pouze několik stránek návodu.

    :-DDDDDDDDDDDD

  • 2. 5. 2016 12:50

    klokan

    > To je přece úplně triviální. Třeba takhle (zřejmě zastaralé) nebo takhle s použitím timers - což je znovuvynalezený cron aneb Lennart a jeho NIH syndrom.

    Znovuvynalezený cron, který na rozdíl od starého cronu jde ovládat skrz API, takže ho můžou používat aplikace, může záviset na jiných službách nebo událostech, služby nebo události můžou naopak záviset na něm atd. Taková drzost, co si to ten Lennart dovoluje!

  • 2. 5. 2016 12:57

    Lol Phirae (neregistrovaný)

    A jak to zjednodušilo to zálohování na flashku, že... jak říkám, stačí nabiflovat několikastránkový návod a je to. (A až to Lennart zase rozmrdá, tak možná někdo po pártýdenním laborování napíše návod nový.) Kdepak, s takovou hnusnou zastaralou věcí jako je crontab nebo /etc/cron.d běžte k šípku, to není vůbec moderní. :-DDD

  • 2. 5. 2016 13:13

    klokan

    Takže nakonec celé to drama kolem systemd je o tom, že když někdo chce použít novou funkci, která dřív nebyla, tak si ji musí najít v návodu?

    To už se blíží čistému surrealismu :D

  • 2. 5. 2016 13:32

    Ivan (neregistrovaný)

    Ne problem je presne opacny. Chci pouzit funkcionalitu, ktera funguje 10 a vice let a najednou to nefunguje. Pokud shutdown script sluzby nebezi pod rootem, systemd to ignoruje a vesele utrhne disky pod bezici databazi. Soubor limits.conf uz neslouzi pro sluzby(uzivatele), ale POUZE pro sessions prihlasene pres logind. Limity pro demony se musi nastavovat jeste jinde. (celkove 2x). Pokud se uzivatel odhlasi ze serveru, systemd smaze vsechny shared-memory segmenty, bez ohledu jestli je nekdo pouziva anebo ne. Klauzule "name" v udev pravidlech uz nejde pouzit pro disky ale pouze pro sitove adaptery. Kazda verze rozbije neco jinyho a neda se na to dopredu pripravit.

    PS: to ze uzivatel ma dvoji limity, jednou pro GUI session a jednou pro SERVICE jsem resil naposledy pred 15ti lety na Win 2000. Dost jsem se tehdy divil co to v tom Microsoftu kouri.

  • 2. 5. 2016 13:34

    Lol Phirae (neregistrovaný)

    Ty tomu nerozumíš, prostě používáš nemoderní věci, no... Taková zpozdilost, jako očekávat, že něco, co fungovalo 10-20 let, bude fungovat i nadále. Takhle ten Gnome OS nevybudujeme, soudruzi. Takhle ne!

  • 2. 5. 2016 13:18

    Filip Jirsák

    Ten cron jste se také musel naučit používat, v tom rozdíl není. Rozdíl je možná jenom v tom, že cron už umíte, ale nic nového se učit nechcete. A jinak zrovna cron také není vzorem intuitivnosti. Sice všechny crony používají zdánlivě stejný formát, ale ve skutečnosti se navzájem liší. A těch dotazů ve fórech „nefunguje mi cron“… Někde je potřeba odřádkování za poslední řádkou souboru, někdy dotyčný netrefí formát souboru, někdy má problémy s proměnnými prostředí, někdy neví, jak zacházet s výstupem…

  • 2. 5. 2016 13:24

    Lol Phirae (neregistrovaný)

    Ten cron jste se také musel naučit používat, v tom rozdíl není.

    Ano, správné vytvoření jedné řádky v crontabu je nepochybně co do potřebného času ke studiu, learning curve atd. zcela ekvivalentní nalinkované magii se systemd unity a službami, která k témuž vyžaduje několikastránkový návod. A jako bonus ten je to celé tak stabilní, že se to s jakoukoliv novou verzí Lennartova výplodu může kdykoliv rozbít.

  • 2. 5. 2016 19:24

    BoneFlute

    Souhlas. Racionální řešení je vytvořit lepší cron s lepším API. To přeci není problém. Jak to souvisí se SystemD a s tím, že ho musím používat?

  • 2. 5. 2016 20:19

    Filip Jirsák

    Nemusíte ho používat. Ale když se zamyslíte, jak by takový lepší cron měl vypadat, zjistíte, že není žádný důvod, proč by se služba „pokud dojde k události X, udělej Y“ měla chovat jinak, pokud událostí „X“ je uplynutí nějakého časového okamžiku, než když tou událostí je změna souboru, připojení média, spuštění služby… No a že když už máte univerzální systém, který dokáže reagovat na události, stačí do tohohle systému zapojit budík, který bude umět poslat událost v požadovaném čase. A že tak snadno získáte systém, který toho umí daleko víc, a jen tak mimochodem implementuje i celou funkcionalitu původního cronu. Navíc to „udělej Y“ je univerzální a může úplně stejně reagovat na různé události – takže může spouštět zálohu třeba každý den, a navíc pokaždé hned, jak připojíte zálohovací médium.

    Ale nic vám nebrání používat ten původní cron, když chcete. Stejně jako vám nic nebrání napsat cron, který bude mít akorát lepší API.

  • 3. 5. 2016 21:23

    BoneFlute

    Odbíháte.

    Za a) SystemD musím používat.
    Za b) Já chci lepší cron. Já nechci překopat půlku systému, který mi doteď fungoval.

  • 3. 5. 2016 21:28

    Filip Jirsák

    Ad a): Kdo a jak vás k tomu nutí?

    As b): Tak ten lepší cron napište. Nevím, proč by ho pro vás měl psát někdo jiný, kdo má o lepším cronu jinou představu, než vy.

  • 4. 5. 2016 1:56

    BoneFlute

    ad a) Fedora? Debian?

    ad b) Opět odbíháte. Problém není v tom, že bych mermomocí chtěl psát novej cron. Jen jsme vám kejvli na to, že nějakej lepší cron by se možná hodil. Jen stále nechápu, proč by náhradou tohoto cronu mělo být zboření všeho kolem.

  • 4. 5. 2016 7:03

    Filip Jirsák

    Ad a) – Ne.

    Ad b) – Neodbíhám, to jenom vy nevíte, co chcete. Chcete starý cron? Můžete ho mít. Chcete nový cron s API? Můžete ho mít, napište ho. Chcete správce služeb řízený událostmi (který tím pádem může plnit i to samé, co dělal cron)? Můžete ho mít. Výběr je jenom na vás. Když si vyberete starý cron, může vám být úplně jedno, že systemd dokáže plnit tutéž funkci.

  • 4. 5. 2016 8:55

    Jan Mimránek (neregistrovaný)

    " Neodbíhám, to jenom vy nevíte, co chcete. Chcete starý cron? Můžete ho mít. Chcete nový cron s API? Můžete ho mít, napište ho."

    Víte, tohle ale trošku boří možnost mít vlastní názor - taky by se klidně dalo říct - chcete systemd? Tak ho mějte ale necpěte ho všem, když znemožňuje kompatibilitu. A nevytáčejte se. Na Gnome je to dobře vidět, kam to vede. Plný přechod na systemd znemožnil jeho použití s ne-systemd distry.
    Beru, že jsou balíčky, kde jde podpora "bypassnout" ale jak dlouho to vydržíí? Dokud nedodají plnou podporu?
    A proto to zajímalo i mě, protože velkých distirbucí == široká podpora a tuny balíčků už bez systemd moc není ,,, Proto jsem i nahoře se ptal, co je lepší, protože "systemd na věčné časy a nikdy jinak" se mi moc nezamlouvá a jedna z věcí, která se mi na LInuxu líbila když jsem začínal byla ta možnost výběru. To padlo.
    A postupem času v té nekompatibilitě a rozlezenosti systemd spíš vidím záměr než to, že by věci, které byly nedotažené nebo chtěli zlepšení, nešly udělat tak, aby nebyly konečné a absolutní.

  • 4. 5. 2016 9:38

    Filip Jirsák

    Nikoli, nikdo vám nebrání mít vlastní názor – ale nemůžete po nikom chtít, aby se tím vaším názorem řídil. Systemd nikdo všem necpe – někdo ho napsal podle svých představ, a nabídl ho ostatním. Je teď na nich, aby se rozhodli, zda ho chtějí nebo nechtějí používat. Když vy máte jiný názor, napište svůj program a nabídněte ho ostatním – a opět bude na nich, zda ho budou používat či nebudou. To naopak vy chcete, aby se ostatní podřídili vašemu názoru, a když se vám systemd nelíbí, chtěl byste, aby vůbec nevzniklo nebo ho zakázat. To je totiž jediný způsob, jak zabránit tomu, aby ho lidé nezačali dobrovolně používat.

    Přechod na systemd neznemožnil použití Gnome na zařízeních, kde se systemd nepoužívá. Odkazoval jsem třeba na návod na zprovoznění Gnome bez systemd na Gentoo.

    To, že chcete používat Gnome bez systemd, je váš požadavek, takže se vy musíte postarat o jeho splnění. Není ničí povinností to pro vás zařizovat. Pohybujeme se ve světě opensource, takže je velmi pravděpodobné, že pokud bude o Gnome bez systemd zájem, vaše úpravy se integrují na hlavní větve Gnome.

    „Systemd na věčné časy a nikdy jinak“ je pouze váš výmysl. Možnost výběru je tu pořád, nic nepadlo. Akorát pořád nechápete, že ty alternativy k systemd vám nezařídí autoři systemd, ale musí to udělat ti, kterým systemd vadí.

    Jak může být záměr v nějaké nekompatibilitě nebo rozlezlosti ve světe opensource? Co vám brání napsat systém, který bude dotahovat a zlepšovat všechno, co dotahuje a zlepšuje systemd, a zároveň bude kompatibilní a nerozlezlý?

    Bavíme se tu pořád dokola o tom, že někdo napsal systemd a dal ho k dispozici ostatním s tím, že pokud ho chtějí používat, tady je a používat ho můžete. A pár lidem se to nelíbí, a pořád dokola si stěžují, jak si může někdo dovolit napsat software, který neodpovídá jejich požadavkům, a dát ho k dispozici ostatním. Tak už se s tím smiřte, že žijete ve svobodném světě, každý si může napsat software jaký chce a může ho zveřejnit. Vy to můžete udělat také. V tom, abyste napsal software, který bude daleko lepší než systemd a převálcuje ho, vám nebrání vůbec nic z vašeho okolí – problém je čistě v tom, že to neumíte nebo nechcete. Stěžovat si na to klidně můžete, ale nečekejte, že lidé, kterým vyhovuje systemd, bude psát váš anti-systemd.

  • 4. 5. 2016 10:09

    Jan Mimránek (neregistrovaný)

    To ale není jenom "neodpovídá jejich požadavkům" a není to tak jenom "pár lidem".
    Pokud vím, tak třeba v Debianu se o tom dost pohádali a bylo to těsně 50 na 50 a spousta lidí kvůli tomu odešlo. Ale čerpám jenom z toho, co jsem se dočetl.

    A toto bude asi taky jenom nějaký "trouba"

    Linus Torvalds said:

    "I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility . and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."

  • 4. 5. 2016 10:24

    Filip Jirsák

    Je to neodpovídá požadavkům – bugs and compatibility jsou jenom požadavky. Na počtu lidí nezáleží – když píšete opensource software, nikdo vás nemůže nutit, abyste bral v úvahu, kolik lidí to bude používat. Já si můžu klidně napsat a zveřejnit program, který bude vyhovovat jenom mně a všichni ostatní budou tvrdit, jak je to špatný program – a přesto mi nikdo nedokáže zabránit v jeho zveřejnění. Navíc pokud je těch odpůrců systemd takové množství a systemd je špatné, tak už přece dávno někdo z nich musel napsat něco lepšího, než systemd, na co všichni uživatelé systemd rádi přešli.

  • 4. 5. 2016 10:45

    Jan Mimránek (neregistrovaný)

    Ano, ale když Vy si<ústrong> napíšete svůj program, který si můžu nebo nemůžu nainstalovat, je to něco jiného, než když někdo napíše program, pak se kvůli tomu poperou maintaneři distribucí a zadrátují to do systému. Jasné, tak jak je to svobodné rozhodnutí, asi, tak úplně stejně se mě to nemusí líbit.
    To bych Vám taky mohl říct, že když se Vám nelíbí spojenci a jejich války o ropu a vliv, bez mandátu OSN, kde umírají civilisti - ženy , děti, starci, tak nežijte v Evropě. Nikdo Vás nenutí. Podporujete vražděné civilistů? Asi ne že?
    Jo , je to extrém, ale princip je stejný, jen jsem vyměnil "spojenci jejich války o ropu a vliv, bez mandátu OSN, kde umírají civilisti - ženy , děti, starci" za "systemd" a "nežijte v Evropě" za "si ho neinstalujte" ...

  • 4. 5. 2016 11:14

    Filip Jirsák

    Ano, je to něco jiného – rozdíl je v tom, zda se kvůli tomu poperou správci distribucí. Což je věc těch správců distribucí a já jako autor toho programu to řešit nemusím (ostatně oni se mohou klidně poprat z důvodu, který ani).

    Ten princip není stejný. Autoři Debianu dělají distribuci pro sebe, a rozhodli se, že ji zpřístupní i ostatním. Vy jste se dobrovolně rozhodl, že tohle, co vám někdo zadarmo nabízí, budete využívat. Teď se autoři Debianu rozhodli k něčemu, co se vám nelíbí. Tím, že je to opensource, vy dokonce můžete tu distribuci jednoduše vzít, a udělat fork, který bude vyhovovat vašim potřebám – jako to udělali autoři Devuanu. Ale vy byste místo toho chtěl, aby se autoři Debianu vykašlali na to, jak to chtějí mít oni, a místo toho to udělali podle toho, jak chcete vy. Proč by to měli dělat?

  • 4. 5. 2016 11:43

    Jan Mimránek (neregistrovaný)

    "Ale vy byste místo toho chtěl, aby se autoři Debianu vykašlali na to, jak to chtějí mít oni, a místo toho to udělali podle toho, jak chcete vy. Proč by to měli dělat?"

    Samozřejmě, že si o tom rozhodnou autoři Debianu, ale co jsem měl možnost se dozvědět, tak to moc jednomyslné nebylo. takže zas tak křišťálově čisté "chtěli to tak mít" to není.

    Podívejte, mám několik serverů se staším Debianem, umím se v něm pohybovat a nyní potřebuji vytvořit malou síť serverů a nemůžu na produkci hodit něco, co je zadrátované v systému, mění se to, občas se po aktualizaci něco rozbije (zdroj zde diskuze). Nemůžu zvolit Devuan, protože nemám jistotou, že některý balík co tam budu mít nepřejde na plnou podporu systemd jako třeba to Gnome a já budu muset na produkčních serverech buď dělat obezličky (pokud to pujde) aby program fungoval, nebo jsem v háji a nemůžu použít Devuan ani proto, protože nevím ani jak jim ta snaha vydrží a jak na tom budou s bezp. aktualizacema atd .... Jo, ještě můžu přeinstalovat produkční server, paráda. Tak si asi vyberu Gentoo, ale tam to zase neznám, nemám zkušenost s flow, s dostupnostmi atd .... No a jelikož nedělám administraci serverů jako hlavní činnost, o to je to pro mě horší a bolestnější a bude mě to stát více času a platit si kvůli tomu profi admina je jako s kladivem na komára.
    Takže to je takový můj výhled na účinek systemd v prostředí a panu Poetringovi, jehož Alsu sice taky používat nemusím ale udělal jsem tu chybu a dost jsem se s ní natrápil, můžu fakt poděkovat. Já vím, nemusím používat nic, ale tak proto to dělají? Aby to lidi mohli klidně nepoužívat?

  • 4. 5. 2016 12:14

    Filip Jirsák

    Nezáleží na tom, jak se k tomu rozhodnutí dospělo, to výsledné rozhodnutí představuje to, co dnes Debian „chce“. Kdyby se rozhodli, že chtějí podporovat varianty se systemd i s ním, také by to znamenalo, že to Debian „chce“.

    zdroj zde diskuze
    Pokud se o tom, co nasadíte na server, rozhodujete podle zdejší diskuse, je to váš problém. Pokud zdejším diskutérům důvěřujete víc, než správcům Debianu, nenasazujte na servery Debian, ale distribuci zdejších diskutérů.

    Takže to je takový můj výhled na účinek systemd v prostředí a panu Poetringovi […] můžu fakt poděkovat.
    Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže.

    Já vím, nemusím používat nic, ale tak proto to dělají? Aby to lidi mohli klidně nepoužívat?
    Ne, dělají to proto, aby to lidé mohli používat – a dospěli k rozhodnutí, že se systemd to bude pro lidi použitelnější. Pokud vy si myslíte, že by to bylo použitelnější bez systemd, je na vás, abyste to prokázal. Ostatně autoři Devuanu jdou právě touhle cestou.

    Nějak pořád nechápu, proč by autoři Debianu, kteří si myslí, že to bude lepší se systemd, měli prokazovat platnost vašeho názoru, že to bude lepší bez systemd.

  • 4. 5. 2016 12:17

    M. Prýmek

    > Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže.

    Nejde o rady, ale o popis konkretnich problemu konkretnich lidi.

  • 4. 5. 2016 12:40

    Jan Mimránek (neregistrovaný)

    "zdroj zde diskuze"

    Ale zde lidi linkovali zajímavé zdroje a ty beru v potaz. A názor je ale taky důležitý - pokud to teda není "Ty jsi vůl a nic nevíš" - jak se tu občas objevuje. Ale nebuďte smutný, stejně vážně beru i Váš názor, protože jste schopný ho normálně napsat, akorát s ním nesouhlasím. I Vy jste tam dával linky a asi ne jen tak z bůhdarma aby "jsem se jako hlavně neřídil podle diskuze" ale jako relevantní zdroj. Diskuze, ty vážné, ne jako na živě.cz, jsou zajímavým zdrojem informací. Proto jsem kdysi zde na root začal chodit, protože v diskuzi pod článkem se člověk vždycky ještě i něco dozvěděl - minimálně nějaký názor nebo pohled na věc. Dokonce jsem zde vedl 3 denní rozpor o programovacím jazyku a nakonec jsem se dozvěděl zajímavé věci a dokonce pár konkrétních případů a zase vím o něco víc a líp .... Já sem nechodím machrovat nebo se vyřádit ....

    "Za to, že se řídíte „radami“ zdejších diskutérů, opravdu pan Poetring nemůže".

    Viz výše + "může" ale za to, že se mi po restartu objeví místo zvuk. karty graf. karta a když pak vytáhnu jack od repráčků, tak bez reinstalace Alsy a restartu už zvuk ani nezapnu + Podle googlu zdaleka nejsem sám. To si pak i se všemi těmi bugreporty a nepochvalami na systemd mám myslet že je to ok? Jako nevím, proč to nemohli první pořádně vychytat a ne to honem hrnout do produkce aby to už už měli rozdělené. Pardon, ale takový dojem to na mě dělá

    "Nějak pořád nechápu, proč by autoři Debianu, kteří si myslí, že to bude lepší se systemd, měli prokazovat platnost vašeho názoru, že to bude lepší bez systemd."

    Nemusí, já to po nich přece nechci. Naopak, platnost svého názoru prokazuji já, sám za sebe. Jestli mě, ale nejen mě. dá vývoj za pravdu, to se uvidí. Samozřejmě že nemám patent na pravdu, ale mám právo na svůj názor. A dokonce, už po několikáté píši že uznávám jejich volbu, akorát se mi nelíbí. Ale přístup, když se ti něco nelíbí, tak "si naser", neboli slušně řečeno "používej si něco jiného nebo si to napiš sám" neberu jako správný, protože to nepodporuje volnou výměnu názorů. Doby pravdy jen té správné strany už tu byly a za moc to nestálo ... A celá ta situace není o jednom sporném programu, ale o tom, jak moc je komplexní a jak až moc tím zasahuje nejen do částí systémů, ale taky tak trochu nabourává kompatibilitu balíčků a na tom, co jsem Vám psal s mými servery je to vidět, před jako volby to lidi postavilo. To není jenom o tom, jestli si naistaluju nebo nenainstaluju nějaký balíček nebo ne.

  • 4. 5. 2016 13:36

    Filip Jirsák

    Z těch bugreportů a nepochval se ale nedozvíte, jestli je to jinde lepší nebo horší. Čekat s vydání softwaru „než se to pořádně vychytá“ je samozřejmě možné, ale při vývoji softwaru se obecně inklinuje spíš k častějšímu vydávání. Protože jinak hrozí, že si budete někde pod pokličkou psát svůj dokonalý kód, a až ho ukážete světu, ukáže se, že to takhle vlastně nikdo nechce. Navíc většina problémů „se systemd“ je způsobena tím, jak „netradičně“ se to v reálném světě používá – což nezjistíte, dokud se ten software nezačne reálně používat.

    Ale přístup, když se ti něco nelíbí, tak "si naser", neboli slušně řečeno "používej si něco jiného nebo si to napiš sám" neberu jako správný, protože to nepodporuje volnou výměnu názorů.
    To asi ale špatně vykládáte, co to znamená volná výměna názorů. Ta se týká skutečně jen těch názorů, ne toho, že se jimi někdo musí řídit. To, že je systemd špatný, je váš názor, a nikdo vám to nebere. Ale pokud se tím názorem chcete řídit, je to na vás – volná výměna názorů neznamená, že někoho jiného, kdo s tím názorem nesouhlasí, donutíte, aby se jím řídil.

    To, že je ten balíček komplexní, je právě ta podstata sporu. Někdo si myslel, že ta původní halda různých částí, které spolu navzájem komunikují špatně a každá jinak, je špatně, a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků – protože primární problém není v těch balíčcích, ale ve vzájemných vazbách. Řešit to postupně tak, že by ty jednotlivé části uměly komunikovat postaru i ponovu, by bylo na dlouho, přičemž ten nový kód by se dlouho nevyužíval, a navíc by se s sebou pořád táhla ta zátěž chyb staré komunikace. Kdyby se s tím začalo před deseti lety, asi by to bylo přijatelné, ale dnes už není čas čekat na to, že možná za deset let budeme mít rozumný způsob správy a komunikace služeb.

    Ano, někdo na to může mít jiný názor, ale pak je na něm, aby to implementoval. Jako to udělali autoři Devuanu. Třeba se časem ukáže, že měli pravdu oni, a Debian zanikne a bude pokračovat jenom Devuan, nebo se spolu zase sloučí a Debian z Devuanu převezme jako svou hlavní větev tu non-systemd.

  • 4. 5. 2016 13:48

    M. Prýmek

    > To, že je ten balíček komplexní, je právě ta podstata sporu. [...] a je potřeba místo toho přijít s něčím, co bude komunikovat jednotně a spolehlivě. Proto se to nedá řešit postupnými výměnami jednotlivých balíčků

    Tak v tom teda vubec podstata sporu neni. Neni nic spatneho na tom, udelat novy init+svc management+cron+at­d, pekne to promyslet, provazat, udelat k tomu API. Spor je o tom, jestli zrovna ta implementace systemd je dobre promyslena, jestli bude v provozu dostatecne robustni, jestli toho nahodou vic nepokazi nez spravi.

    Bud to nechapete nebo nechcete chapat, ale neustale tady cupujete strawmana. Kdybyste min mluvil a vic poslouchal, tak byste si to mozna uvedomil.

  • 4. 5. 2016 14:13

    Jan Mimránek (neregistrovaný)

    Víte, je software a software. Systemd zasahuje do moc věcí a tak zásadně, že to mohlo fakt asi počkat. Mimochodem ty early relase jsou proto, aby se mohlo budovat se zájmem a zpětnou vazbou od uživatelů, ne proto, že si budu vychytávat problémy až za běhu, nehledě na to, že to není nějaký prográmek a součást systému.

    Můžu Vás ujistit, že čím větší systém složený z částí, které nejsou schopny fungovat samostatně (nemyslím jen systemd ale distro jako celek) - modulárně - tím dřív se nakonec sesype, protože taková struktura musí mít nějaký hlavní regulátor a ten nakonec jednou nebude schopen uřídit všechno.
    Pod pojmem systém se můžete představit cokoliv, co je nějaký celek a nějak reaguje na vnější vstupy.
    Dobrým příkladem budiž EU. To je tak velký celek,který postupně méně a méně umožňuje samostatné a nezávislé fungování vnitřních součástí, že musí vydávat regulace na už vydané regulace aby mohl zavést nové regulace a bobtná a bobtná, ale to nejde udržet do nekonečna.

    Ale uvidíme. Možná se dočkáme dalšího historického větvení vývoje linux distribucí.

  • 4. 5. 2016 16:33

    Filip Jirsák

    Čekalo to patnáct let. Kdyby autoři systemd čekali dalších patnáct let, přišel by mezi tím někdo jiný, kdo by udělal klidně ještě větší zásah do systému.

    Testovací verze systemd samozřejmě existovaly, jenže když to testuje pár uživatelů, neodhalí se tím všechny možné kombinace prostředí. Mimochodem, to, že po světě existují miliony různých hacků správy služeb, které je problém naroubovat na systemd, je jenom dalším důkazem toho, že ten dřívější systém je špatný.

    Můžu Vás ujistit, že čím větší systém složený z částí, které nejsou schopny fungovat samostatně (nemyslím jen systemd ale distro jako celek) - modulárně - tím dřív se nakonec sesype, protože taková struktura musí mít nějaký hlavní regulátor a ten nakonec jednou nebude schopen uřídit všechno.
    A tohle je právě věc, kterou systemd řeší. Před systemd máte soustavu různých skriptů, udev pravidel, cronů a bůhvíčeho ještě, co je na sebe různě navázané a závislé. Systemd právě přináší tu modularizaci, protože ty komponenty si mezi sebou povídají stejným protokolem, takže můžete jednu komponentu snadno vzít a nahradit ji jinou komponentou, můžete snadno spouštěč události změnit z času na modifikaci souboru, start služby, přihlášení uživatele nebo cokoli jiného.

  • 4. 5. 2016 20:45

    Jan Mimránek (neregistrovaný)

    "Čekalo to patnáct let. Kdyby autoři systemd čekali dalších patnáct let, přišel by mezi tím někdo jiný, kdo by udělal klidně ještě větší zásah do systému."

    No super, takže důvod bychom měli. Ještě že tohle nefunguje třeba v letectví.

    "Testovací verze systemd samozřejmě existovaly, jenže když to testuje pár uživatelů, "

    Tak to jsou na tom teda dost blbě. No to jste mě teda uklidnil, že si udělají z uživatelů a ostrých nasazení test plant.

    "systemd právě přináší tu modularizaci, protože ty komponenty si mezi sebou povídají stejným protokolem, takže můžete jednu komponentu snadno vzít a nahradit ji jinou komponentou"

    Jinou komponentou, ale systemd komponentou. Oni se evidentně vy..li na interface a vše, na co narazí zahrnou do systemd. A to je právě ten problém. Kam ta jejich modularita vede se hezky probublalo až ke Gnome že, a taky jsem narazil na to, že Xfce ja na tom stejně. To je přímo ukázka nezávislosti.

    Jinými slovy, místo aby změnili/spravili článek mezi jádrem a desktopem, vedle cronu atd, tak vytvořili moloch, který nároky spojil všechno dohromady tak, že je systemd závislé i grafické prostředí a ještě ani neměli před nasazením možnost to otestovat. No to je teda modularita. Ale takovou metodu vývoje znám, jeto metoda ŽáVeS - "Žádní velké sraní ..."

    To si totiž pod pojmem modularita představujeme každý asi něco jiného. Já si pod pojmem modularita ne-představuji něco, co má nějaké části a někdo jim dá do jména "Modul" ale hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.

    Víte třeba jak se dělají změny na produkční databázi když ji prostě nemůžete jenom přehrát? Mám na mysli postup, že když chcete např. v tabulce Users zrušit sloupec "whole-name" a nahradit ho sloupci "first-name" a "surname", tak přece hned v aktualizaci nezlikvidujete sloupec a nenahradíte ho těmi dvěma, ale pouze vytvoříte ty dva nové, přehrajete do nich data a začnete tam přidávat i nové, běží to paralelně a pak, až Vám to hezky běhá s novými sloupci a nikdo nezaznamenává problémy, tak třeba v další aktualizaci odstraníte sloupec "whole-name" + kód k tomu a máte jistotu, že to všechno běží a nikomu nic nerozbíjíte. Ano, je to těžší postup ale nikomu z razu nic neodstřihnete

  • 4. 5. 2016 21:27

    Filip Jirsák

    No super, takže důvod bychom měli. Ještě že tohle nefunguje třeba v letectví.
    Taky doufám, že v letectví netrvá 15 let, než se začne řešit známý problém.

    No to jste mě teda uklidnil, že si udělají z uživatelů a ostrých nasazení test plant.
    Tak jako všichni ostatní, kteří píšou software, který se používá v milionech různých prostředí. Všechna ta různá prostředí totiž nejde nasimulovat.

    Jinou komponentou, ale systemd komponentou.
    Ne.

    Oni se evidentně vy..li na interface a vše, na co narazí zahrnou do systemd.
    Ne. Pouze píšou ty komponenty, které mohou z nového systému těžit a nenapíše je nikdo jiný.

    Kam ta jejich modularita vede se hezky probublalo až ke Gnome že, a taky jsem narazil na to, že Xfce ja na tom stejně. To je přímo ukázka nezávislosti.
    To, že nikdo jiný nenapsal implementaci logind, není chyba lidí od systemd. Pokud někdo che jinou implementaci, ať ji napíše. Nepsal už jsem to několikrát?

    Jinými slovy, místo aby změnili/spravili článek mezi jádrem a desktopem, vedle cronu atd, tak vytvořili moloch, který nároky spojil všechno dohromady tak, že je systemd závislé i grafické prostředí
    Ty nároky jsou mnohem menší, než byly u těch původních implementací. Vám pořád vadí, že nikdo nenapsal alternativní implementaci – ovšem vy patříte mezi ty, kteří ji nenapsali. Takže si stěžujete pouze na sebe.

    ani neměli před nasazením možnost to otestovat
    Mezi software, který takhle funguje, můžete zahrnout třeba také linuxové jádro.

    No to je teda modularita.
    Modularita znamená, že můžete komponenty přidávat a ubírat, aniž by o tom musely vědět ostatní komponenty. To, že třeba modul poskytující služby cronu nemůžete momentálně nahradit jiným modulem, protože neexistuje žádný jiný modul poskytující takové služby, není chyba modulárního systému. Je to chyba toho, kdo ten jiný modul potřebuje a nenapsal ho. To je jako kdybyste tvrdil, že linuxové jádro není modulární, protože když odstraníte modul ext4, nemáte žádný jiný modul, který by obsluhoval souborový systém ext4.

    hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
    Přesně takhle systemd funguje.

    Mám na mysli postup, že když chcete např. v tabulce Users zrušit sloupec "whole-name" a nahradit ho sloupci "first-name" a "surname", tak přece hned v aktualizaci nezlikvidujete sloupec a nenahradíte ho těmi dvěma, ale pouze vytvoříte ty dva nové, přehrajete do nich data a začnete tam přidávat i nové, běží to paralelně a pak, až Vám to hezky běhá s novými sloupci a nikdo nezaznamenává problémy, tak třeba v další aktualizaci odstraníte sloupec "whole-name" + kód k tomu a máte jistotu, že to všechno běží a nikomu nic nerozbíjíte. Ano, je to těžší postup ale nikomu z razu nic neodstřihnete
    Jenže pokud nemáte kontrolu nad všemi aplikacemi, které s tou databází pracují, zůstal byste na věky se třemi sloupci – protože některé aplikace by se prostě nepřizpůsobily, když by je k tomu nic nenutilo.

    Navíc pokusy řešit ty problémy cestou mírného pokroku jsou staré minimálně patnáct let – a žádný z nich se neujal. Protože kvůli zachování zpětné kompatibility přinášely pouze malé výhody, přitom ale byly s předchozím řešením nekompatibilní. Takže se to ve výsledku moc nevyplatilo nasazovat. Takže se dál bastlily hacky na hacky, až se dospělo do bodu, kdy energie potřebná ke změně je menší, než energie nutná na udržování těch hacků.

  • 4. 5. 2016 21:47

    Jan Mimránek (neregistrovaný)

    "Taky doufám, že v letectví netrvá 15 let, než se začne řešit známý problém."

    Jo, takže když už to trvalo dlouho, tak už to můžeme patlat a je to jedno. Zajímavé. Nehledě na to, že 15 let staré problémy akorát nahradili novými.

    "Jinou komponentou, ale systemd komponentou.
    Ne"

    Ano.

    "Ne. Pouze píšou ty komponenty, které mohou z nového systému těžit a nenapíše je nikdo jiný."

    Tak to by mohli napsat nový celý systém a nemuseli zasírat ten stávající. Těžit mohou z nového a nikdo jiný je nenapsal. Aneb použiji li Vaši oblíbenou paušalizaci - Nikdo je nenutil opravovat init, mohli si vytvořit vlastí systemd distro.

    "hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
    Přesně takhle systemd funguje."

    Nefunguje - protože ostatní moduly / celky pracující s ním musí změnit interface a zatratí tím interface k ostatním - Gnome, Xfce, cron zrovna přepsali .... Správně modulární by to bylo, kdyby se nic co je kolem systemd nemuselo měnit, jen systemd by sis tím co mu přijde přes interface nakládal po svém. ...

    "Jenže pokud nemáte kontrolu nad všemi aplikacemi, které s tou databází pracují, zůstal byste na věky se třemi sloupci – protože některé aplikace by se prostě nepřizpůsobily, když by je k tomu nic nenutilo."

    No to právě nechápete, protože záleží na Vás, na databázi, co poskytnete na interface. Pro ty staré poskytnete [pseudokod] concat( first_name, surname) pro ty nové můžete je poskytovat setejně + ještě odděleně a označit první způsob jako @deprecated --- ach,jak je tento postup neobvyklý, že? Takto se dodržuje modularita a ne že to změním a když se ti to nelíbí, tak si nainstaluj co chceš. Udělat to má právo, ale pak o něm mají lidi právo říct že je .... Zpětná kompatibilita je taky sprosté slovo že?

    "Navíc pokusy řešit ty problémy cestou mírného pokroku jsou staré minimálně patnáct let – a žádný z nich se neujal. "

    A to má jako znamenat, že někdo přijde a celé to rozbourá? Mimochodem kdyby nebyl systemd tak problémový tak by byl klid.

    "Protože kvůli zachování zpětné kompatibility přinášely pouze malé výhody, přitom ale byly s předchozím řešením nekompatibilní. Takže se to ve výsledku moc nevyplatilo nasazovat. Takže se dál bastlily hacky na hacky, až se dospělo do bodu, kdy energie potřebná ke změně je menší, než energie nutná na udržování těch hacků."

    No, malé pokroky jsou možná lepší, než vyměnit staré errory za nové.

  • 5. 5. 2016 6:55

    Filip Jirsák

    Kdyby nebyl systemd tak problémový, měli bychom tu pořád ten starý systém postavený na nekompatibilních programech, které jsou různými hacky provázané tak, aby to připomínalo to, co bylo původně požadováno. Ty problémy jsou totiž převážně způsobeny tím, když se někdo ty hacky hacků pokouší naroubovat na systemd. Je to podobné jako s přechodem na IPv6, který je pro spoustu lidí také problémový, protože nevědí, jak v síti použít IPv6 adresy z privátního rozsahu a celou síť „schovat“ za NATem.

  • 5. 5. 2016 8:13

    Jan Mimránek (neregistrovaný)

    "Kdyby nebyl systemd tak problémový, měli bychom tu pořád ten starý systém postavený na nekompatibilních programech, které jsou různými hacky provázané tak, aby to připomínalo to, co bylo původně požadováno. Ty problémy jsou totiž převážně způsobeny tím, když se někdo ty hacky hacků pokouší naroubovat na systemd."

    Takže je podle Vás v pořádku, že když si nainstaluji čistou Debian + systemd + Gnome a vyměním systemd tak už Gnome nespustím? No ještě že k tomu ostatní maintaineři balíčků přistupují svědomitě. Bylo fakt na prd vyměnit třeba nano za vim a už neotevřít žádný file, nebo nainstalovat htop a už nepustit ps. Ale jak to vypadá, možná i to bude nový standard. Ale co, jsem v klidu, protože si to přece můžu napsat sám, že?

    "Je to podobné jako s přechodem na IPv6, který je pro spoustu lidí také problémový, protože nevědí, jak v síti použít IPv6 adresy z privátního rozsahu a celou síť „schovat“ za NATem."

    Není, protože jim nikdo nesebral možnost mít ipv4, jinými slovy neplatí to, že jakmile odstraní ipv6, tak už některé věci bez hacků nepošlou po ipv4. Takž tento příklad trochu kulhá. Ale já Vám uvedu jiný.

    Vemte si že systém (distro) je jako panelový dům a bytové jednotky jsou moduly.
    Společný interface je schodiště, dveře do bytu a stoupačky. I okna, ale tam na ničem nic nezávisí.
    No a teď se několik nájemníků rozhodne, že si opraví své zastaralé byty na novější a lepší a chtějí posunout stoupačky a dveře do bytu ( jsou ve 2. patře - 2. SW level ) a když už jsou v tom, tak je potřeba změnit schodiště (kvůli novým bytovým dveřím). Hlasuje se nějaký způsobem (na tom nezáleží) a vyhráli, tak to celé předělali. Občas se ale stane, že přes jejich nové stoupačky něco neteče občas nefungují chody a těm nad nimi (další SW vrstvy), komu se to nelíbí, řekli, ať si najde jiný podnájem nebo se přizpůsobí --- ale taky si mohou postavit schodiště a trubky vlastní a oni je možná přijmou.
    O co v příkladu jde? Že nezachovali celek ___modul ( byt )__ s jeho rozhraním ale vrtali i do interfaces - zde spol. prostory ---- a proto kompatibilita s nimi znamená změny i pro ostatní byty a kdo nechce ať táhne nebo si udělá svoje, protože byt jejich tak je to jejich rozhodnutí --- samozřejmě majitel domu (zde třeba Debian) to v reálu povolit nesmí (naštěstí), ale u distra se to stalo.
    To vystihuje daleko víc současnou situací

  • 5. 5. 2016 9:15

    Filip Jirsák

    Takže je podle Vás v pořádku, že když si nainstaluji čistou Debian + systemd + Gnome a vyměním systemd tak už Gnome nespustím?
    Když nějaká komponenta vyžaduje nějakou službu, a já poskytovatele té služby vyměním za něco jiného, co tu službu neposkytuje, je v pořádku a logické, že ta závislá služba přestane fungovat. Když nainstalujete X a Gnome, a pak X vyměníte za framebuffer, Gnome vám přestane fungovat – protože vyžaduje služby X, které framebuffer neposkytuje.

    V pořádku není, pokud vám nějaká distribuce umožní udělat takovou „výměnu“, aniž by protestovala.

    V pořádku by také nebylo, pokud byste implementaci té služby vyměnil za jinou implementaci té služby, a přestalo by to fungovat. Pak může být problém v některé z těch implementací, v nejasném rozhraní nebo v tom, že závislá aplikace závisí na specifickém chování konkrétní implementace, které není rozhraním zaručeno.

    Není, protože jim nikdo nesebral možnost mít ipv4
    Pokud vám ty možnosti někdo sebral, stěžujte si na něj – z toho, co píšete, předpokládám, že vám ji sebrali správci Debianu. Systemd pokud vím stále může běžet jako PID>1, ze systemd stále můžete spouštět jakékoli skripty, včetně původních init skriptů, stále můžete používat různé implementace cronu. Systemd tomu nijak nebrání, takže chybu hledejte jinde.

    Ten váš příklad je úplně špatně. V původním řešení totiž neexistuje žádné jednotné rozhraní, každá komponenta s každou jinou komunikuje ad hoc rozhraním specifickým právě pro ty dvě komponenty. Správně by tedy ten příklad byl, kdyby ten původní dům žádný interface neměl. „Stoupačky“ by byly řešené tak, že by byla nějak přivedená voda do prvního patra, tam by se třeba před kohoutkem udělala odbočka, na ní nasadila hadice a tou voda vytáhla do druhého patra. Ve druhém patře by byla trvale zašpuntovaná vana, v ní ponorné čerpadlo a to by hnalo vodu do třetího patra – a kdyby ve vaně docházela voda, měli by z třetího patra dolů natažený provázek, kterým by zatáhli za pákový kohoutek ve druhém patře, aby se vana začala napouštět. Atd. atp.

    Pak by přišli s tím, že je potřeba s tím něco udělat, udělat v celém baráku jednotný interface (normální stoupačky). Udělalo by se to, a nájemníci by si začali stěžovat. Ten ze třetího patra by si stěžoval, co je to za pitomý rozbitý interface, být napojený na stoupačky. On byl zvyklý na svůj interface – ponorné čerpadlo a provázkem ovládaný kohoutek o patro níž. A teď když se pokouší se na to připojit, musel si pořídit sud, do kterého napouští vodu z těch stoupaček, protože ponorné čerpadlo neumí čerpat vodu ze stoupaček. K ovládání kohoutku pro plnění sudu ze stoupaček musel přidat kladku pod strop, protože kohoutek má najednou u sebe a ne o patro níž, a když od něj vede provázek nahoru, už na něj nedosáhne. Nájemníci by tedy začali brblat, jak mají ty stoupačky špatný interface, že je potřeba, aby se to u nich v bytě napojilo na ten jejich původní – ale jinak v domě ať jsou samozřejmě ty stoupačky, protože si nájemníci od 4. patra výš rychle všimli, že ve stoupačkách je voda pořád, a ne podle toho, jak zrovna funguje čerpadlo ve 3. patře.

  • 5. 5. 2016 9:29

    Jan Mimránek (neregistrovaný)

    "Když nainstalujete X a Gnome, a pak X vyměníte za framebuffer, Gnome vám přestane fungovat"

    Jenomže to tak není, protože Gnome před tím fungovalo a po výměně komponenty systemd se muselo změnit a už není kompatibilní s čím bylo

    " původním řešení totiž neexistuje žádné jednotné rozhraní, každá komponenta s každou jinou komunikuje ad hoc rozhraním specifickým právě pro ty dvě komponenty."

    Takže neexistují systémové proměnné a systémové funkce pro přístup ke zdrojům. Aha

  • 5. 5. 2016 9:55

    Filip Jirsák

    Co znamená „po výměně komponenty systemd“? Komponenta je podle mne něco, co přes nějaké rozhraní poskytuje nějaké služby. Takovou komponentou je třeba cron, který může být implementován třeba bcronem, dcronem, fcronem nebo cronie. Rozhraním té komponenty je správce systému, který pomocí textového editoru podle požadavků oedituje konfigurační soubor příslušného cronu.

    Systémové proměnné a systémové funkce pro přístup ke zdrojům neposkytují rozhraní potřebné pro dnešní systémy. Jak byste pomocí systémových proměnných a systémových funkcí pro přístup ke zdrojům informoval všechny komponenty, které to zajímá, že se právě k systému přihlásil nějaký uživatel, a předal jim informaci o prostředí a o tom, který je to uživatel?

  • 5. 5. 2016 11:21

    Jan Mimránek (neregistrovaný)

    "Co znamená „po výměně komponenty systemd“? Komponenta je podle mne něco, co přes nějaké rozhraní poskytuje nějaké služby."

    Komponenta může ale obsahovat další komponenty, ale to že je systemd komponenta jste potvrdil i Vy:

    Jí: "hromadu nezávislých komponent, který tvoří fungující a automaticky reagující celek.
    Vy: Přesně takhle systemd funguje."

    "Takovou komponentou je třeba cron, který může být implementován třeba bcronem, dcronem, fcronem nebo cronie. Rozhraním té komponenty je správce systému, který pomocí textového editoru podle požadavků oedituje konfigurační soubor příslušného cronu."

    Ano, ale i ty crony se dovolávají nějaké ho interface - nebo obsahují ovladače HW a Kernel? To asi ne, že?
    UI není jediné existující interface na světě. Jako příklad uvedu OLE, když už je řeč o komponentách a jejich fungování vzájemně, ale není jediné ....

    "Systémové proměnné a systémové funkce pro přístup ke zdrojům neposkytují rozhraní potřebné pro dnešní systémy. Jak byste pomocí systémových proměnných a systémových funkcí pro přístup ke zdrojům informoval všechny komponenty, které to zajímá, že se právě k systému přihlásil nějaký uživatel, a předal jim informaci o prostředí a o tom, který je to uživatel?"

    Nevím, nepracuji v tom několik let, ale asi bych to řešil rozhraním, které by tyto informace poskytovalo nezávisle.
    Prostě bych třeba zrovna ten jejich systemd-logind postavil mimo celek systemd, takže by se dalo použít i s initem a Gnome by ho klidně mohlo implementovat a toto využívat a nezáviselo by to systemd - prostě by logind jenom poskytoval informace o připojených uživatelích a tečka.Ty komponenty v tom případě, systemd a logind by spolu mohli klidně komunikovat jako bonus a to by mohla být další Lennartova zásluha a dodržel by "Dělám jednu věc ...." a měl by nezávislý logind který by dával linfo o uživatelích ale taky by neblokoval nic jiného. A dal by se instalovat a odinstalovat a pak by i platilo to v celém rozsahu to Vaše "Tak si ho neinstaluj". A taky při změně by bylo jednodušší opravovat jeden nezávislý balíček než když je zadrátovaný v celku (i neúmyslně) Jestli by to dalo více práce? Možná, teda spíš na 95% určitě, ono to totiž není úplně triviální tak jak se to řekne, ale jde to, a výsledek by byl dle mne lepší. A tak by to mohlo platit i pro ostatní balíčky a funkcionality. Jde prostě o to, přidat funkce systémově, případně vytvořit fungující alternativy a ne to prořezat a zadrátovat.

  • 5. 5. 2016 11:48

    Filip Jirsák

    Systemd jako PID=1 je jedna komponenta. Na té ale Gnome nezávisí. A pak existuje projekt, který se v této diskusi také nazývá systemd, a to je spousta různých komponent – jedna z nich je právě aplikace systemd. Pokud mluvíte o výměně komponenty, myslíte tím tedy tu jednu aplikaci systemd. Zajímalo by mne, za co jste ji vyměnil – já neznám žádnou jinou komponentu, která by implementovala stejné služby.

    Ano, ale i ty crony se dovolávají nějaké ho interface - nebo obsahují ovladače HW a Kernel? To asi ne, že?
    Nechápu, co se tím snažíte říct. Ano, crony neobsahují ovladače HW a kernel, využívají jiné komponenty. Stejně tak ani systemd-cron neobsahuje ovladače HW a kernel, ale využívá jiné komponenty.

    Nevím, nepracuji v tom několik let, ale asi bych to řešil rozhraním, které by tyto informace poskytovalo nezávisle.
    A kdybyste potřeboval informovat o jiné události, třeba připojení média, postavil byste jiné rozhraní, pokud možno na jiných technologiích? A pro události z časovače byste postavil další rozhraní? Není lepší mít pro to jednotné rozhraní, a jenom přes něj posílat různé typy událostí?

    Prostě bych třeba zrovna ten jejich systemd-logind postavil mimo celek systemd, takže by se dalo použít i s initem a Gnome by ho klidně mohlo implementovat a toto využívat a nezáviselo by to systemd
    A přesně takhle to dnes je. systemd-logind je samostatná komponenta, která nezávisí na systemd, ale jenom na určitém rozhraní. Dá se to klidně použít se SysVinitem, pokud SysVinit bude implementovat potřebné rozhraní.

    A tak by to mohlo platit i pro ostatní balíčky a funkcionality.
    Vidíte, ono by to takhle nejen mohlo platit, ale ono to tak platí.

    Jde prostě o to, přidat funkce systémově, případně vytvořit fungující alternativy a ne to prořezat a zadrátovat.
    Systemd nic nezadrátovává. Naopak, věci, které jsou teď řešené proprietárním rozhraním mezi dvěma konkrétními implementacemi, převádí na univerzální rozhraní, na které se může napojit každý.

  • 5. 5. 2016 12:11

    Jan Mimránek (neregistrovaný)

    "A přesně takhle to dnes je. systemd-logind je samostatná komponenta, která nezávisí na systemd, ale jenom na určitém rozhraní. Dá se to klidně použít se SysVinitem, pokud SysVinit bude implementovat potřebné rozhraní."

    A to určité rozhraní je systemd, že?
    https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
    "For one, in the last stages of GNOME 3.8.0 as release team we specifically approved some patches to allow Canonical to run logind without systemd."

    Tím pádem se není k čemu z toho elaborátu vyjadřovat.

  • 5. 5. 2016 12:25

    Lol Phirae (neregistrovaný)

    Tak určitě. Můžeš si reimplementovat systemd tak, aby se to chovalo přesně jako systemd, a po každém novém releasu to opravovat, protože ti to LP rozbil.

    Jirsáku, běž už do prdele.

  • 5. 5. 2016 12:27

    Jan Mimránek (neregistrovaný)

    Tak já nevím, já v tom linku čtu, že bez patchů logind bez systemd nejede, jak jste mi tvrdil zde.

    "A přesně takhle to dnes je. systemd-logind je samostatná komponenta, která nezávisí na systemd, ale jenom na určitém rozhraní. Dá se to klidně použít se SysVinitem, pokud SysVinit bude implementovat potřebné rozhraní."

  • 5. 5. 2016 12:32

    Lol Phirae (neregistrovaný)

    "Každý zákazník si může vybrat jakoukoliv barvu auta, jestliže to bude černá." (Henry Ford, 1909)

  • 5. 5. 2016 12:37

    Jan Mimránek (neregistrovaný)

    :-)))) A nebo si ho jak to říkává Filip Jirsák , pokud se mu barva nelíbí, tak si ho může sám natřít.

  • 5. 5. 2016 13:01

    Filip Jirsák

    Já v tom linku nikde nečtu, že to spustili proti alternativní implementaci těch služeb, a nefungovalo to. Což by byl důkaz, že to bez systemd nejede. Z toho linku se dá vydedukovat akorát to, že to nikdo nezkusil – což je něco úplně jiného, než že to nejde.

  • 5. 5. 2016 13:05

    Jan Mimránek (neregistrovaný)

    Jo aha, už to chápu, oni vytvořili patche, aniž by věděli jestli jsou vůbec potřeba a dali je Canonicalu a ti je nejspíš použili a nejspíš taky aniž by věděli, jestli jsou potřeba . . .

    :-D Zajímavé co všechno se to kolem systemd dějě

  • 5. 5. 2016 13:35

    Filip Jirsák

    To chápete špatně. Oni věděli, že ty patche jsou potřeba, protože ta bájná alternativní implementace logind, kterou chcete používat, je pořád jen ve stadiu bájí a ne a ne se zhmotnit na disku nějakého programátora.

  • 5. 5. 2016 13:13

    M. Prýmek

    Je potřeba se podívat na ty odkazy z odkazu. Konkrétně na tohle https://mail.gnome.org/archives/desktop-devel-list/2013-March/msg00092.html
    kde se celkem zevrubně popisuje, že Gnome NEZÁVISÍ na nějakém čistém API, jak se pořád snažíš namluvit, ale na implementačním detailu systemd (konkrétně existence /sys/fs/cgrou­p/systemd/) a tím vzniká bordel, kterej ten patch řeší.

    Takže ještě jednou: tvoje idea čistého API, které jenom stačí implementovat, je mylná. Kolem systemd/Gnome se motají všelijaké prasárny, které se musí opatchovávat, aby nedocházelo k neočekávaným efektům.

    Jestli to ve finále jde nebo nejde rozchodit, je celkem irelevantní. Důležitý je, kolik to dá námahy a kolik prasáren kvůli tomu musí člověk obejít - prasáren, který dřív obcházet NEMUSEL a které mu ZBYTEČNĚ PŘIDÁVAJÍ PRÁCI.

  • 5. 5. 2016 13:37

    Filip Jirsák

    Gnome NEZÁVISÍ na nějakém čistém API, […] ale na implementačním detailu systemd (konkrétně existence /sys/fs/cgrou­p/systemd/)
    Což je chyba systemd, že…

  • 5. 5. 2016 13:38

    M. Prýmek

    > Což je chyba systemd, že…

    Ne, to je tvoje chyba, že tvrdíš věci, které neodpovídají skutečnosti.

  • 4. 5. 2016 22:28

    M. Prýmek

    > Modularita znamená, že můžete komponenty přidávat a ubírat, aniž by o tom musely vědět ostatní komponenty.

    Coz presne u systemd nefunguje, protoze u internich API neni garantovana stabilita. Cili nahradit jednu cast systemd jde, ale neni garantovano, ze to zitra neprestane fungovat.

    The following interfaces will not necessarily be kept stable for now [...]
    The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise: [...]
    https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/


    When developing with systemd, don't use any of the latter interfaces, or we will tell your mom, and she won't love you anymore.

    Ha ha ha, tak aspon, ze jsme se zasmali...

  • 4. 5. 2016 22:31

    M. Prýmek

    ...a jestli to nekdo porad jeste nepochopil, tak systemd vicemene garantuje API jenom vuci APLIKACIM, ne mezi jednotlivymi svymi castmi. Cili kdokoli s kladnym IQ snad muze pochopit, ze snazit se ze systemd neco vykousnout, nebo to necim nahradit, je OPRUZUS MAXIMUS a nikdo soudny se do toho nebude poustet, pokud nebude mit fakt EXTREMNE silnou motivaci.

  • 4. 5. 2016 22:51

    Jan Mimránek (neregistrovaný)

    "...a jestli to nekdo porad jeste nepochopil, tak systemd vicemene garantuje API jenom vuci APLIKACIM, ne mezi jednotlivymi svymi castmi. "

    Více méně je hezké slovo, ale jak jde na Gnome vidět, tak to API vůči aplikacím je taky změna oproti stávajícím.
    Tedy pokud bych vzal distro jako panelový dům, tak by se dalo říct, že si někdo v 2. patře koupil byt, který fungoval špatně, začal ho opravovat a posunul vchodové dveře do bytu na druhou stranu patra a kvůli tomu předělal schodiště ve svém patře. Občas to schodiště ještě uprostřed schodiště změní že úplně nefunguje, ale kdo chce. může si udělat vlastní. Je tak?

  • 4. 5. 2016 23:14

    M. Prýmek

    > ale jak jde na Gnome vidět, tak to API vůči aplikacím je taky změna oproti stávajícím.

    Pozor, zmena proti stavajicim je to stoprocentne. Ja mluvim o stabilite toho _noveho_ API. Proste o API vuci aplikacim vyvojari slibili, ze ho nebudou moc menit, ale o internim neslibili vubec nic. Takze o nejake modularite a nahrazovani casti si Filip muze tak leda nechat zdat ve svych divokych snech.

  • 4. 5. 2016 23:34

    Jan Mimránek (neregistrovaný)

    No právě. Modularita by byla, kdybych si nainstaloval třeba

    i - interface

    Gnome => systemd + i + Gnome
    nebo
    Gnome => systemd + Gnome

    mohl bych vyměnit systemd za cokoliv (samozřejmě funkčního) a vše by dál fungovalo. A to mě na tom nejvíc vadí, protože přesto, že je škoda si čistou instalaci hned kazit vyndáváním systemd, klidně bych čas investoval, ale nemám záruku, že to pak bude bez problémů, že i když nějak bokem Gnome rozjedu (což je taky paráda do čisté instalace), tak že na tom vše pojede ok. Na pracovní stanici, dejme tomu, ale na produkčním serveru je to vyloženě koledování si o průser - tam nepůjde o Gnome, ale dříve či později o něco jiného, protože modularita je v ... pánu. A to je to co mě na tom vadí nejvíce. Na desktopu mám systemd, není to žádná hrůza, ale na servery to nechci a musím kvůli tomu použít buď distro, které je beta a kdoví + riskuji že balíčky kompatibilní za chvíli nebudou a nebo distro které neznám. Jo, je to furt linux ale flow a výhody a nevýhody kolem distra si musí člověk zažít. A nerad bych to celé za rok předělával.

  • 4. 5. 2016 23:38

    M. Prýmek

    > Modularita by byla, kdybych si nainstaloval třeba

    Ale jo, tak to je. Akorátže Gnome (AFAIK) interaguje s logind, což je součást systemd, ale nemůžeš použít ze systemd jenom logind, protože to je příliš provázané se zbytkem. Vnější API garantované máš, ale to vnitřní (logind <-> zbytek systemd) ne.

  • 5. 5. 2016 0:05

    Jan Mimránek (neregistrovaný)

    Aha. No hlavně by mě zajímalo, proč to ty distribuce tak přejímají v takovém stavu. Jako beru že na desktopu to asi není tak poznat, ale u sysadminů by si to mohli pěkně rozházet. Já teda nejsem full-time sysadmin, co se týče délky pracovního týdne ani part-time admin, ale už jsem přemýšlel i o Slackware ...

  • 5. 5. 2016 0:22

    M. Prýmek

    > No hlavně by mě zajímalo, proč to ty distribuce tak přejímají v takovém stavu.

    Protože RedHat má velkou ekonomickou sílu a nepřijmout znamená přidat si hodně starostí a práce, to je jednoduchý. A taky to pro většinu lidí není zas až tak špatné řešení. Prostě misky se naklonily na tuhle stranu no :) Však třeba maily členů debianní technical committee jsou dostupné, můžeš si jejich argumenty přečíst.

    > ale u sysadminů by si to mohli pěkně rozházet

    RedHat má velký štěstí, že RHEL 7 zároveň přichází s Dockerem, kterej je dostatečně buzzword na to, aby systemd přehlušil (a mj. z něj taky těží). Kdyby RHEL 7 nic zásadního nepřinášel a navíc měl systemd, tak by to myslím měli s adoption rate celkem nahnutý :)

    > už jsem přemýšlel i o Slackware ...

    Slackware je poslední aspoň trochu rozšířený a zároveň rozumně jednoduchý Linux, ale dost visí na jednom člověku a tvrdošíjný odmítání rozumnýho balíčkování nebo systému portů ho imho dost výrazně sráží. V kombinaci s portage nebo pkgsrc by to byl super OS. Bohužel ale pkgsrc se sice dá použít i svépomocí (celkem snadná instalace), ale pro Linux není nic moc (málo uživatelů). A naroubovat portage je asi zas celkem dost práce, to by musela dělat vyloženě nějaká dostribuce. A o žádné, která by to dělala, nevím.

  • 5. 5. 2016 0:46

    Jan Mimránek (neregistrovaný)

    No Slackware jsem testoval před pár lety, ale jsem smířený s tím, že pokud nasadím Gentoo, tak prostě budu muset kompilovat více než se Debianem. Nevím možná se pletu, ale proto mi ani ten Slackware tolik nevadil .... Samozřejmě dobrý balíčkovací systém a komunita, to je o něčem jiném ...

    Děkuji za osvětlení

  • 4. 5. 2016 10:25

    M. Prýmek

    > A toto bude asi taky jenom nějaký "trouba" Linus Torvalds said:

    Linus má k systemd ještě celkem shovívavý postoj. Daleko ostřejší je třeba ten výš zmíněný Theodore Ts'o.

    A vůbec nejlepší je pročíst si sám bugreporty. Není to ani zdaleka jenom široce propíraný debug flag, třeba i https://bugzilla.redhat.com/show_bug.cgi?id=753882 je dobrý žrádlo...

    It worked for years well enough, only having to set up xauth to let two separate environments access the same display. What made it suddenly impossible?

    Tohle jsou přesně ty věci, kvůli kterým jsou hlavně sysadmini nervózní - základní věci, na které se dalo desítky let spolehnout, najednou bez oznámení přestanou fungovat, těžko se zjišťuje proč vlastně a ticket na rozbitou základní funkcionalitu je otevřený dva roky, protože nikdo není schopný říct, jak by se ta věc vlastně v nově nastoleném prostředí měla řešit...

  • 4. 5. 2016 18:40

    Lol Phirae (neregistrovaný)

    A vůbec nejlepší je pročíst si sám bugreporty. Není to ani zdaleka jenom široce propíraný debug flag, třeba i https://bugzilla.redhat.com/show_bug.cgi?id=753882 je dobrý žrádlo...

    Takovejch brainfartů je ten křáp plnej odshora dolů. A ten promyšlený design a moderní socketová aktivace, to je prostě k nezaplacení, viz např. bludný kruh aneb kterak LP rozjebal CUPS aneb.

  • 4. 5. 2016 18:12

    BoneFlute

    "Neodbíhám, to jenom vy nevíte, co chcete."

    - Myslím, že jsem to už pochopil. Přeji vám pěkný den.

  • 2. 5. 2016 13:05

    klokan

    Se systemd ví spolehlivě, kdy je správná flashka je namontovaná. Jak tohle zjistí ten váš slavný oneliner v crontabu? Jestli hodláte číst /proc/mounts, tak to nefunguje, sorry.

    Dále se systemd se ví, kdy se flashka namontuje a kdy odmontuje, váš crontab provádí polling. Ne, to opravdu není lepší.

    Za třetí, se systemd se timer nahodí při namontování a první akce se spustí hned, neboli Frantovi se věci okamžitě synchronizují. U vás musí čekat, kdy proběhne příští cron.

    Jistě, já vím, ono by šlo implementovat atd... Prostě: ta implementace tady je v podobě systemd, a je robustní, osvědčená a s dobrou podporou. Akorát ji dělá někdo, koho je módní k smrti nenávidět. Jak už bylo řečeno, velmi podobná věc jako systemd je launchd, ten ale nikomu nevadí, protože ho nedělá Lennart ale Nejsvětější Apple. Ještě si vzpomínám, jak bsďáci a macisti pěli ódy na to, jak OSX drtí Linux, protože má launchd a Linux je s tím svým sysvinit k smíchu. Dneska je pro změnu FreeBSD mnohem lepší, než Linux, protože nemá sviňský systemd :D:D:D - ale jenom do té doby, než portují launchd na FreeBSD, o čemž se tam diskutuje, to pak zase bude skvělé, jak launchd zahrnuje úplně všechno, protože OS se má vyvíjet jako integrovaný celek a ne jako jednotlivé komponenty, víme. Vlastně mě to docela baví.

  • 2. 5. 2016 13:13

    M. Prýmek

    > Dále se systemd se ví, kdy se flashka namontuje a kdy odmontuje, váš crontab provádí polling.

    Ale to přece není pravda. Informaci o vložení zařízení má hotplug démon a ví to ihned a ihned může udělat jakoukoliv akci.

    > Jak už bylo řečeno, velmi podobná věc jako systemd je launchd, ten ale nikomu nevadí, protože ho nedělá Lennart ale Nejsvětější Apple.

    Ne. Launchd nikomu nevadí, protože dělá to, co dělat má a nepohlcuje další a další subsystémy.

    Ale opakuju: mně to je jedno. Klidně ať do systemd dají i Xka, mně to je fakt úplně ukradený, nepoužívám ho.

    > Ještě si vzpomínám, jak bsďáci a macisti pěli ódy na to, jak OSX drtí Linux, protože má launchd a Linux je s tím svým sysvinit k smíchu.

    A vzpomínáš si taky na daemontools? Už jsou na světě kolik? Patnáct let? Tohle přesvědčení o supermodernosti dávno známých konceptů, pokum možno ještě hloupě implementovaných, je super. Viz Docker :))

    > Dneska je pro změnu FreeBSD mnohem lepší, než Linux, protože nemá sviňský systemd :D:D:D - ale jenom do té doby, než portují launchd na FreeBSD, o čemž se tam diskutuje, to pak zase bude skvělé, jak launchd zahrnuje úplně všechno, protože OS se má vyvíjet jako integrovaný celek

    Ufff. Tak za prvé jsem myslím nikdy neřekl, že FreeBSD je mnohem lepší než Linux. Za druhé: kdyby měl Linux místo systemd launchd, nikdo by ani nepípl. Stejně jako nepípl, když měl Upstart. A proč? Protože 3. launchd nezahrnuje úplně všechno, ale dělá, co má dělat.

  • 2. 5. 2016 13:47

    klokan

    > Ale to přece není pravda. Informaci o vložení zařízení má hotplug démon a ví to ihned a ihned může udělat jakoukoliv akci.

    To je pořád dokola: ano, když to zařídí root a když se to naskriptuje způsobem, který sice nepřipadá komplikovaný unixovému adminovi (ačkoliv je velmi vzácné, aby to admin neudělal prasácky), ale - mírně řečeno - neodpovídá očekávání BFU. Tak ještě jednou: systemd je tu od toho, aby linux NEBYL jako unix, u kterého 24/7 musí sedět sysadmin a který se bohužel musí konfigurovat STATICKY protože jinak to NEJDE. Dobrá?

    > Ne. Launchd nikomu nevadí, protože dělá to, co dělat má a nepohlcuje další a další subsystémy.

    Tak si ho pořádně prohlédni.

    > Ale opakuju: mně to je jedno. Klidně ať do systemd dají i Xka, mně to je fakt úplně ukradený, nepoužívám ho.

    Když ho nepoužíváš a je ti ukradený, tak o co ti jde? Co se snažíš dokázat? Že ti strašně vadí, když někdo používá software, který je tobě ukradený?

    > A vzpomínáš si taky na daemontools? Už jsou na světě kolik? Patnáct let? Tohle přesvědčení o supermodernosti dávno známých konceptů, pokum možno ještě hloupě implementovaných, je super. Viz Docker :))

    O supermodernosti tady nebyla řeč. O podpoře, rozšířenosti a adoptování vývojáři ano. Je to stejný argument jako k čemu python, vždyť tu už před tím byl smalltalk.

    > Tak za prvé jsem myslím nikdy neřekl, že FreeBSD je mnohem lepší než Linux.

    Ne, neřekl. Ale je to častý diskurz notorických haterů. Dneska je nějaký OS lepší, protože nemá systemd, až bude mít něco podobného, bude zase jiný důvod brblat o systemd.

    > Za druhé: kdyby měl Linux místo systemd launchd, nikdo by ani nepípl.

    Tak jsme doma. Kdyby měl Linux prakticky totéž, ale nejmenovalo se to systemd a nevyvíjel by to Lennart, tak by nikdo ani nepípl.

    > Stejně jako nepípl, když měl Upstart.

    Tak si projdi stará fóra. Pípalo se dost. Polovina řvala, že ubuntu má upstart a tudíž už to není unix (v podstatě totéž, jak se dneska šílí o systemd) a druhá polovina, že si canonical jede na vlastní pěst s upstartem, místo aby měl taky systemd jako redhat a suse.

    > A proč? Protože 3. launchd nezahrnuje úplně všechno, ale dělá, co má dělat.

    Ještě jednou, informuj se.

  • 2. 5. 2016 13:59

    Lol Phirae (neregistrovaný)

    To je pořád dokola: ano, když to zařídí root a když se to naskriptuje způsobem, který sice nepřipadá komplikovaný unixovému adminovi (ačkoliv je velmi vzácné, aby to admin neudělal prasácky), ale - mírně řečeno - neodpovídá očekávání BFU.

    Zatímco nalinkované návody určitě plně odpovídají očekávání BFU, každý BFU je zvládne levou zadní, zcela neprasácky. Krom toho věci jako úprava souborů v /etc vůbec nevyžadují roota.

    Jo, to je opravdu pořád dokola - je to sice dál, ale zato je tam horší cesta a snadněji si na ní zlomíš haksnu.

  • 2. 5. 2016 14:00

    M. Prýmek

    > který sice nepřipadá komplikovaný unixovému adminovi, ale - mírně řečeno - neodpovídá očekávání BFU.

    Chápu to správně, že BFU neočekává, že by musel napsat jeden řádek do cronu, ale očekává, že bude vytvářet unitfile pro systemd? Proč si to myslíš? Jak víme, že to není právě naopak?

    > a který se bohužel musí konfigurovat STATICKY protože jinak to NEJDE.

    Nevím, co to znamená "konfigurovat staticky". Udev má definovaná pravidla, co se má stát, když se objeví nějaké nové zařízení. Systemd má nadefinováno, co se má stát, když se objeví nové zařízení. Asi jsem blbej, ale nějak tam nevidím žádný rozdíl v jakékoliv "dynamičnosti".

    > Že ti strašně vadí, když někdo používá software, který je tobě ukradený?

    Řekl jsem to už nejmíň třikrát: je mi líto, když software začíná být Linux-only z hloupého důvodu.

    > Dneska je nějaký OS lepší, protože nemá systemd, až bude mít něco podobného, bude zase jiný důvod brblat o systemd.

    Tak jistě můžeme fantazírovat, že to tak bude. Nebo si třeba můžeme představovat, že za pět let GNU dokončí Hurd a nikdo už nic jiného používat nebude, protože Hurd bude prostě jedinečný. Anebo Zemi ovládnou mravenci.

    > Tak jsme doma. Kdyby měl Linux prakticky totéž, ale nejmenovalo se to systemd a nevyvíjel by to Lennart, tak by nikdo ani nepípl.

    Tak samozřejmě některým lidem vadí, jakým způsobem se lidi od systemd chovají například k bugreportům. Například jistého Linuse Torvaldse to rozlítilo tak, že řekl, že od Sieverse žádný kód přijímat nebude.

    No a pak jsou lidi, kteří mají konkrétní technické výhrady. Jako např. jistý Theodore Ts'o.

    Oba to budou nejspíš nějací pošahaní hateři. Nevím, osobně je neznám.

    > Ještě jednou, informuj se.

    O čem byh se měl informovat?! Launchd zahrnuje to, co init systém zahrnovat má. Jestli máš pocit, že má něco navíc, tak to napiš. Těžko se můžu informovat o něčem, co si myslíš ty.

  • 2. 5. 2016 14:38

    klokan

    > O čem byh se měl informovat?! Launchd zahrnuje to, co init systém zahrnovat má. Jestli máš pocit, že má něco navíc, tak to napiš. Těžko se můžu informovat o něčem, co si myslíš ty.

    Viz http://newosxbook.com/articles/Ch07.pdf

    Launch má v sobě init, cron, atd a inetd, dále stejně jako systemd má uživatelské služby, timery, zařizuje nastavení limitů a reaguje na připojení nebo odpojení zařízení, kromě toho spravuje transakce, monitoruje souborové systémy (inotify), emuluje windowsový autorun, zajišťuje backup, DNS, sandboxy, nahrazuje syslog a spouští grafický shell.

    Jo a konfigurace je jak jinak než v XML.

    Ale není to Lennart a kromě toho na OSX se to smí, ale chraň bůh, kdyby Linux měl někdy být něco jiného než klon SysV před třiceti lety.

  • 2. 5. 2016 14:53

    M. Prýmek

    Tak to sis poněkud vyfantazíroval, ne? Zajišťuje backup?

    Ono nejde o to, co ten init systém všechno umí, ale jestli má jasné vazby, jednotlivé věci se dají debugovat, povypínat, PID 1 není přehnaně nafouknutý atd. atd. Svět není černobílý :)

    "Monitoruje souborové systémy", to zní drsně, co? Skoro stejně hrozivý jako když jakákoli unixová utilita pozná, že jí v cfg adresáři přibyl soubor :)

  • 2. 5. 2016 15:05

    klokan

    Přečetl sis ten manuál? To je jenom krátký výňatek všech vzájemně závislých funkcí, které launchd obsahuje. Ano, mimo jiné zajišťuje univerzální funkci monitorování FS pro všechny aplikace, které toto používají a přihlásí se k monitorovacímu launchd démonu. Tedy přesně to, na co na linuxu klientská aplikace zavolá syscall inotify. Akorát to jde přes launchdovský ekvivalent dbusu, založený na machových portech a který je další z mnoha nedílných součástí launchd.

    Ale je mi jasné, že jsi neochvějně rozhodnutý, že systemd je strašný na rozdíl od launchd, protože prostě proto. Takže tímto končím diskusi, která evidentně už nikam nevede.

  • 2. 5. 2016 16:02

    M. Prýmek

    Ono hlavně nemá smysl diskutovat na takové obecné a navíc emotivní rovině "na tohle jste si zasedli a přitom tamto vám nevadí!" Nevím o tom, že bych řekl, že launchd je ideální systém bez chyb, takže tahle rovina je úplně mimo mísu. Navíc MacOS/Darwin je desktopový systém, který není primární platformou pro OSS, takže i kdyby měl úplně nekompatibilní init, tak to na OSS nemá žádný dopad.

    Krom toho, když už se chci bavit o nějakých subtilních technických detailech, bylo by fajn být aspoň trochu přesný... (viz dál)

    > To je jenom krátký výňatek všech vzájemně závislých funkcí, které launchd obsahuje.

    Jak jsi přišel na to, že jsou vzájemně závislé? "Závislost" může vypadat různě. Buď tak, že když tu prerekvizitu odstraním, přijdu o nějaké funkce, nebo tak, že ta prerekvizita je tak prorostlá se zbytkem, že vůbec odstranit nejde (za rozumného úsilí).

    U systemd to nevypadá moc růžově - viz např. https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU

    > Ano, mimo jiné zajišťuje univerzální funkci monitorování FS pro všechny aplikace, které toto používají a přihlásí se k monitorovacímu launchd démonu. Tedy přesně to, na co na linuxu klientská aplikace zavolá syscall inotify.

    No a tohle je přesně příklad té zavádějící nepřesnosti. Jak přesně má souviset https://en.wikipedia.org/wiki/FSEvents s launchd?

    > Akorát to jde přes launchdovský ekvivalent dbusu, založený na machových portech a který je další z mnoha nedílných součástí launchd.

    A tohle už ani není nepřesnost, to snad musíš dělat schválně. Ne, machové porty nejsou na světě kvůli launchd. Je to součást kernelu, kterou samozřejmě launchd používá. Ale je to něco úplně jiného než dbus - Linux totiž úplně klidně můžu chtít provozovat bez dbusu (např. server), zatímco Darwin bez machových portů by se mi provozoval fakt obtížně :) Takže srovnáváš přidanou závislost (X, které musím *přidat*, aby mi Y vůbec fungovalo) s něčím, co je odjakživa integrální součástí systému.

    > Ale je mi jasné, že jsi neochvějně rozhodnutý, že systemd je strašný na rozdíl od launchd, protože prostě proto.

    Ne, o ničem takovém neochvějně přesvědčený nejsem, jak jsi toho pocitu nabyl?

  • 2. 5. 2016 16:35

    Lol Phirae (neregistrovaný)

    U systemd to nevypadá moc růžově - viz např. https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU

    Nojo, když von si ten nešťastník zpozdilá myslí, že "service <foo> stop" zastaví službu, tak to se nemůže divit, že mu to nechodí podle očekávání. Stop v moderním initu už dávno jako stop nefunguje, to by tak hrálo, aby si admin vypínal, co ho napadne, ať si trhne ploutví! A kdyby si snad myslel, že když použije "service <foo> disable", že už to konečně klapne, tak na to ať taky rychle zapomene. Služby teď vypínáme hypermoderně linkováním do /dev/null. To je panečku API jak stehno z mamuta!

  • 2. 5. 2016 16:39

    M. Prýmek

    > že už to konečně klapne, tak na to ať taky rychle zapomene. Služby teď vypínáme hypermoderně linkováním do /dev/null.

    Ano. A tato featura tam je proto, že to uživatelé chtěli. Jinak by to totiž autoři neimplementovali. Všem to totiž ušetří spoustu práce [1]. A komu se to nezdá, proč to neimplementuje jinak?

    [1] https://plus.google.com/+MichaelMolG/posts/hLa6bAJoGUJ

  • 2. 5. 2016 16:48

    Lol Phirae (neregistrovaný)

    A tato featura tam je proto, že to uživatelé chtěli. Jinak by to totiž autoři neimplementovali.

    Tak tak. Po implementaci následovaly tisíce děkovných dopisů denně. Prostě killer fíčura, bez které se moderní systém rozhodně neobejde!!!

  • 2. 5. 2016 13:16

    Lol Phirae (neregistrovaný)

    Kristova noho. Pokud chci něco zálohovat při připojení externího média, tak nebudu používat cron, ale udev skript. Světe div se, šlo to přes ten udev i před tím, než ten frikulínský kokot požral kde co, ono to dokonce šlo i předtím, než se používal udev (viz hotplug skripty).

    ta implementace tady je v podobě systemd, a je robustní, osvědčená

    A za robustní a osvědčenou implementaci to označuje kdo? LP a jeho fanklub?

    a s dobrou podporou.

    To jo. Pobavilo. Podpora je přímo výtečná, viz např. aféra s privatizací kernelového parametru debug nebo to, jak se Lennart rozhodl, že pokud najde jeho robustní a osvědčený init soubor /etc/mtab, tak prostě ne a ne a nenabootuje. To je přímo exemplární případ robustního designu. :-DDDDDDD

  • 2. 5. 2016 18:32

    BoneFlute

    Tak já mám Fedoru, ta má SystemD, a opravdu netuším, jak bych váš požadavek na zálohu fotek po vložení flasky řešil...

    Normálně bych se asi koukl do dokumentace, zda vložení flasky posílá nějaký event, který si mohu odchytit, a pak bych na něj posadil nějaký script. Hmm, ve SystemD se to dělá jinak?

  • 2. 5. 2016 18:42

    M. Prýmek

    > Normálně bych se asi koukl do dokumentace, zda vložení flasky posílá nějaký event, který si mohu odchytit, a pak bych na něj posadil nějaký script.

    Asi nejsi ten správný BFU, který *požadoval* aby se to skriptem nedělalo :)))

  • 2. 5. 2016 9:24

    klokan

    > Čili argument "chceme cgroups" je irelevantní pro otázku "potřebujeme systemd?"

    Chceme cgroups, tudíž potřebujeme systemd minimálně do té doby, než je bude podporovat i jiný správce služeb.

  • 2. 5. 2016 9:53

    klokan

    Právě, že ne. Alespoň pokud je mi známo, žádný jiný systém neumožňuje triviálně a deklarativně nastavit limity pro službu nebo službu a všechny její závislosti, nebo kategorii služeb. Navíc možnosti ulimit jsou proti cgroups strašně primitivní.

  • 2. 5. 2016 8:20

    M. Prýmek

    > mít API, aby šlo systém, služby, uživatelská sezení atd. ovládat a monitorovat programově.

    "Mít API" je široký pojem. Každý init systém má nějaké API, jinak by nebylo jak restartovat službu :) A pokud by z nějakého důvodu mělo být smrtelně důležité mít DBUS API, tak ani to by nebyl velký problém - jenom by to celé na tom imho nemělo stát a padat, protože DBUS je prostě netriviální závislost.

    > Požadavek 2: integrace mezi různými typy událostí. Příklad: chci si nastavit (jako běžný uživatel, ne root), aby ve chvíli, kdy si připojím svůj záložní USB disk, se mi automaticky zálohoval adresář s dokumenty

    To samozřejmě jde i bez systemd. Ale root to povolit musí, protože systém nemá jak poznat, že to je můj disk a ne disk kolegy, kterému bych takhle nepozorovaně ukradl data.

  • 2. 5. 2016 8:48

    Filip Jirsák

    jenom by to celé na tom imho nemělo stát a padat, protože DBUS je prostě netriviální závislost
    To, že se klidně vzdáte nějaké funkcionality, jenom aby aplikace neměla nějakou závislost, je naštěstí jenom váš názor. S tímhle přístupem by webový prohlížeč neměl být závislý na přítomnosti grafického prostředí nebo síťových funkcí, textový editor by neměl být závislý na přítomnosti souborového systému. Protože to všechno jsou netriviální závislosti. Ostatní úplně to obrací na ruby princip KISS, kdy každá komponenta má dělat svou práci, a když potřebuje něco jiného, použije jinou komponentu, která to umí – čímž se v dané funkcionalitě stane závislou na tom, že existuje jiná komponenta, která danou věc umí.

  • 2. 5. 2016 9:02

    M. Prýmek

    Žádné funkcionality není potřeba se vzdávat. API jde samozřejmě postavit i bez závislosti na DBUS. Nebo před vznikem DBUS žádná API neexistovala?!

  • 2. 5. 2016 9:14

    Filip Jirsák

    Samozřejmě, že jde API postavit i bez závislosti na DBUS. Ale proč vymýšlet vlastní DBUS, když už tady jeden je? Navíc je to obecné rozhraní, které může použít kdokoli – když budu ve své aplikaci záviset na několika komponentách, budu mnohem raději, když všechny budou používat stejný DBUS, než když si každá vymyslí svůj vlastní DBUS.

  • 2. 5. 2016 9:17

    M. Prýmek

    Není potřeba vymýšlet vlastní DBUS. DBUS má jednu zásadní nevýhodu - a to, že k jeho funkčnosti musí běžet démon. Pokud bude v démonu chyba, může se taky stát, že nebudu moct systém ani vypnout, protože se vypíná přes DBUS. To považujete za správné a robustní řešení? Já ne.

    Ale jinak proti DBUSu celkem nic nemám, jako *volitelná* možnost je fajn.

  • 2. 5. 2016 9:09

    klokan

    Nevím, jaké takzvané API má teda sysvinit. Je jedno, jestli je to přes dbus nebo jinak (v praxi přirozeně dbus, protože jde o IPC), ale u systemd je prostě k disposici kompletní a koherentní sada funkcí, umožňující správu nejen služeb, ale i dalších věcí jako je mountování, uživatelé, síť atd. Že by to šlo i bez systemd, to je jisté, až na to, že to prostě žádný jiný systém neimplementoval, až systemd. Takže až do případné implementace stejných rozhraní v openrc a jinde znamená nasazení systemd obrovský krok vpřed.

    > To samozřejmě jde i bez systemd.

    Mno takže konkrétně JAK? Nepochybuju, že "by to šlo" (kdyby to existovalo, ale ono to jaksi neexistuje).

  • 2. 5. 2016 9:34

    klokan

    > Čemu říkáte API?

    https://en.m.wikipedia.org/wiki/Application_programming_interface2

    Všimněte si prosím, že věci typu system("příkaz") se za API nepovažují.

    > Mno takže konkrétně JAK?

    Neodpověděl jste mi, což je logické. Ten příklad jsem si totiž zvolil schválně tak, aby narazil na to, že mezi init, session managerem, udev a cronem neexistuje komunikace (a ani to API, o kterém nevěřím, že nevíte, co se tím myslí).

  • 2. 5. 2016 9:44

    M. Prýmek

    > Všimněte si prosím, že věci typu system("příkaz") se za API nepovažují.

    Jenže smyslem init systému není naplnit definici API na Wikipedii. Smyslem init systému je např. startovat služby, případně je monitorovat a restartovat. K tomu s ním potřebuju nějak komunikovat. Jestli ta komunikace probíhá po socketu, dbusu, nebo vytvářením symlinků, je vedlejší. Důležité je, 1. jestli to dělá, co to dělat má 2. jestli je to robustní 3. jestli je to dostatečně malé, aby byl co nejmenší prostor pro chyby a útoky.

    > Neodpověděl jste mi, což je logické.

    Ale ano, odpověděl. Hotplug pozná vložení zařízení. Spustí skript. Skript může dělat COKOLI. Pod cokoli spadá i periodicky zálohovat disk.

  • 2. 5. 2016 8:41

    M. Prýmek

    Jo a ještě jsem zapomněl:

    > Požadavek 3: Možnost JEDNODUŠE omezit CPU a pamět pro danou službu. V systemd to jde díky podpoře cgroups.

    To pořád neimplikuje nutnost systemd se vší tou jeho krásou. Např. DragonBSD to má třeba vyřešené ještě líp - službu je možné *volitelně* spustit v jailu - viz https://www.dragonflybsd.org/cgi/web-man?command=svc§ion=8 Není důvod kvůli tomuhle požadavku nějak masivně rozbíjet současný systém, je to otázka jednoho parametru, který by šel snadno přidat do libovolného init systému.

  • 2. 5. 2016 9:10

    Filip Jirsák

    je to otázka jednoho parametru, který by šel snadno přidat do libovolného init systému.
    Ano, všechno, co dělá systemd, by se dalo udělat tak, že byste vzal nějaký jiný init systém a udělal v něm spoustu jednoduchých změn. Jenomže to nikdo před systemd neudělal. A mimochodem, vznikl by vám z toho systemd2, u kterého byste kritizoval úplně to samé.

  • 2. 5. 2016 9:12

    M. Prýmek

    Podívejte se na to nosh a pak se můžeme bavit dál. Snad pochopíte, že většinu funkcionality systemd jde implementovat úplně jinak, daleko čistěji a bez vedlejších efektů typu reimplementace DNS resolveru.

  • 2. 5. 2016 9:26

    Filip Jirsák

    To, že funkcionalita systemd se dá implementovati jinak, tvrdím celou dobu. Problém není v tom, že by to nešlo, problém je v tom, že to nikdo neudělal – všichni ti, kteří neustále fňukají v diskusích, jak je systemd špatný, právě jenom fňukají v diskusích, ale neudělají to jinak. I když jim v tom nic nebrání.

    Reimplementace DNS resolveru není klíčová věc pro systemd. Prostě jenom zjistili, že jim pro nějakou funkcionalitu stávající DNS resolver nevyhovuje (čemuž se nedivím), tak naimplementovali svůj, který můžete využít. Ano, já vím, je to přesný opak vašeho postupu – když autorům systemd něco nevyhovuje, tak sednou, a napíšou kód. Když něco nevyhovuje vám, tak sednete a začnete psát do diskusí, že by šlo napsat kód.

  • 2. 5. 2016 9:31

    M. Prýmek

    > když autorům systemd něco nevyhovuje, tak sednou, a napíšou kód. Když něco nevyhovuje vám, tak sednete a začnete psát do diskusí, že by šlo napsat kód.

    Mno, tak diskuse s tovýmihle argumenty (které jsou navíc v naprostém rozporu s tím, co už jsem několikrát napsal) se dál neúčastním. Bylo mi potěšením a zas někdy.

  • 2. 5. 2016 14:01

    rna (neregistrovaný)

    No wonder. Co jinýho by taky troll po přesném popisu=přímým zásahu moh´ udělat, že? :-D

  • 30. 4. 2016 12:01

    PPK (neregistrovaný)

    Nemuzu posoudit jak moc je systemd hruza. Ale v pripade debianu. Po prechodu na jessie sem si vsim zatim dvou veci zpusobenych systemd. Pokud je daemon ukoncen jinak nez pres systemctl stop, tak pak nejde spustit. Musi se ukoncit (i v pripade ze uz nebezi) pres systemctl a pak jde spustit. Druhy problem je ze pri ukonceni/restartu systemu nekdy daemonu nepride patricny signal a je ukoncen na tvrdo. Po zmene initu je vsechno zase v poradku. Nevim jestli je systemd tak rozbity, nebo je v jessie stara verze, kazdopadne ve stavu kdy nejdou zakladni veci to nemelo projit k ostrymu nasazeni.

  • 30. 4. 2016 22:33

    Murděj Ukrutrný

    Asi tak 3 roky zpátky jsem dostal firemní lenovo, s linuxem (ubuntu 13.něco) si moc nerozuměl, zatuhával při uspání blba wifi, .... V další verzi ubuntu už v pohodě. Potom jsem z verze 14.10 (kde fungovalo vše jak mělo ale nešel docker) přešel na 15.10 (první verzie systemd) a zas problémy se zatuháváním wifinou, ... Takže jsem zpět u 14.04.
    Možná za to může systemd, možná ne.

  • 1. 5. 2016 21:06

    ehmmm (neregistrovaný)

    Ja jsem se treba na chvili zasekl u openvpn serveru. Pridal jsem do /etc/openvpn dalsi konfigurak, vyresetoval openvpn a ono nic. Spravne reseni jsem nakonec vygooglil, ale koukal jsem na to jako tele na novy vrata.