Vlákno názorů k článku Ekonomická válka ve FOSS od muf - My vám to systemd vnutíme, i kdybychom Linux...

Ne. Prostě se jen bojí nekompatibility s distribucemi silného RedHatu, kterému začala vadit variabilita a snadná udržovatelnost linuxových distribucí bez komerční podpory. Prostě jim to kazí kšefty...

Nebuďte směšný, to co tady předvádíte...

Myslíte to blbnutí se zrcadlem, namířeným na ostatní?

Pise extremne nadstadardni blb Nekola, kterej jako vzdy vubec netusi o cem zvani ...

To bych taky rád věděl.

Nejsem expert na boot se systemd, vlastně jsem boot řešil naposledy na jednom embedded systému nějakých šest let nazpátek. O rozdíl mezi systemd a initd jsem se aktivně nezajímal, proč taky, když s tím zatím nikdy nebyl problém. Vlastně vím jenom to, co vypadává z flame:
- systemd pochází od RH.
- systemd je špatný, protože pochází od RH.
- systemd je ještě horší, protože je to nástroj RH, jak zastavit otáčení Země.

Aktivně jsem nehledal, čas je drahý na řešení každé blbosti, která mě osobně moc netrápí, ale je někde tabulka srovnání obou systémů bez nesmyslů typu "vymyslel to satan starý zlý chlupatý a smradlavý"? A seznámili se s ní všichni, kdo se toho flame účastní? Vidí do detailů? Prozuměli tomu dobře?

Vím, že každá změna znamená se něco učit a krátkodobě moc nepotěší, ale kdyby člověk o initu nic nevěděl a začínal se učit od nuly, který systém by byl výhodnější?

V té debatě ale _zdaleka_ nejde jen o init.
Pokud by systemd byl pouhý init, tak jako na začátku, skoro nikomu by nevadil, stejně jako nevadil upstart.

Zkuste o tom trochu něco nastudovat, protože ty vaše zdejší vÿkřiky jsou, s prominutím, dost hloupé.

Říkám, neřešil jsem to. Takže fakt nevím. Funkce obojího je stejná. Pro začátečníka je to prý jedno. A použít se dá obojí. Fakt mě nenapadá nic jinýho, než přeučení na nový systém. Ale pozor, problémy s přeučením nemusí být ve složistosti systému, ale i v nechuti / lenosti něco udělat. Jinak fakt nevím. Proto se ptám.

Netýká se to (jenom) initu, ale docela obdivuju ty, co místo hodiny zkoušení nové věci věnují 10 hodin očerňování autorů a sprostýho nadávání.

Funkce obojího je stejná - spouštnění a konfigurace. Každý to ale dělá trochu jinak.

Postaru se to zapisuje <i>SetProperty(5)</i>
Ponovu se to zapisuje <i>Property = 5</i>

Co mají společnýho? Třeba to, že

- obojí závisí na nějakým HW a po bootu je potřeba natáhnout ovladače
- na obojím můžou závidet nějací démoni (u sítě třeba automount, u podsvitu třeba něco ve styluRedShiftu) a systém by měl vědět, co je k dispozici
- Obojí může chctít nějaká aplikace nebo jiný balík konfigurovat. pokud je daný specifikací, kde a jak to změnit, je pro programátora jednodušší situace, než modifikovat pět různých typů skriptů podle výrobce, hledat v nějakým spustitelným souboru konkrétní kosntrukce,...

Pokud se to spojí v seznamu ovladačů k zavedení a v seznamu dostupných modulů, nevidím v tom problém. Pokud ovladač backlightu posílá něco po management busu fyzické vrstvy Ethernetu, je to průšvih.

Ok, takže kompatibilita s úplně jiným systémem z pravěku... Tu já rád, učení se nových technik zdržuje. Ale někdy prostě není zbytí...

Fajn, buďme kompatibilní s prasítí, kde byli jenom prověření zaměstnanci firmy a zahoďme SSH. Máme přece Telnet...

Zahoďme HTTPS, přece jsou to jenom prolinkovaný stránky textu od vědecké autority, na co šifrovat? Je tam přece jenom hrstka slušných lidí,co se k tomu dostanou...

Jo, a abych nezapomněl na starý dobrý neprolomitelný TSL... To byl řev, když nedávno vyšlo doporučení ho zabít na serverech...

Pokud něco nevyhovuje dnešním požadavkům, je to potřeba řešit. A když se najde lepší řešení, tak je fajn ho využít (tím neříkám, kdetý init systém je lepší) a vychytat mu mouchy.

Ať se na to podívám z jakéhokoliv úhlu, vidím v případě xBSD velmi profesionálně a čistě vyvíjené efektivní systémy s téměř nepřekonatelnou stabilitou, bezpečností a výbornou dokumentací.
Jistě ne náhodou z nich čerpá Apple i Microsoft(BSD licence je prostě tak benevolentní, že jí nevadí ani jisté vykrádání např. implementace TCP/IP). Mimochodem běží třeba i v Sony Playstation nebo routerech Juniper.
Ani náhodou pravěk. Jen čistota, řád, profesionalita.
Nesmíte dát na řeči narcistního asáka z Hannoveru, který chce "měnit svět".

ale je někde tabulka srovnání obou systémů bez nesmyslů typu "vymyslel to satan starý zlý chlupatý a smradlavý"?

Nejsem si jist, zda splním všechny požadované podmínky, nicméně jedním z výsledků diskuze technické komise debianu, zda systemd nebo upstart, jsou následující dokumenty:

https://wiki.debian.org/Debate/initsystem/systemd
https://wiki.debian.org/Debate/initsystem/upstart

Dávám sem i odkaz na upstart, protože v daném dokumentu je uveden i pohled na to, v čem je upstart lepší než systemd.

Díky, konečně to chápu. Je to boj mezi příznivci spouštění procesu stylem "napřed udělej to, potom tohle a nakonec tamto" a "tady je seznam toho, co musí běžet, tohle jsou požadavky co proces chce a mašino, standardně se s tím popasuj". Takže v podstatě jako přechod mezi C a VHDL, odlišná filozofie a styl myšlení. To bez vášní prostě nejde.

Příliš to nechápete pravděpodobně proto, že vám Unix nikdy moc neříkal. To opravdu nesouvisí příliš s initem.
To, že někdo Unix nepochopil, tomu rozumím, ale co nechápu je to, že se někdo snaží unixový OS přeměnit v cosi jiného, když takový OS už dávno existuje v podobě produkce Microsoftu a existoval i dříve např. v podobě VMS.

AFAIK si Linux na nějaký opravdový Unix nikdy nehrál. Být kompatibilní s Unixem mělo v začátcích Linuxu svůj smysl, ale IMHO to nikdy nebyl cíl, svatý grál Linuxu. Dnes už Linux Unix přerostl, je to nejpoužívanější systém na světě sám o sobě.

Držet kompatibilitou s ostatními systémy, aby byly aplikace skvěle portovatelné, je nádherná myšlenka, ale v praxi to znamená hodně snahy s minimálním efektem. Kompatibilita s BSD kernely byl hlavní argument proti systemd v Debianu. Když se Lennart zeptal na DebConfu v místnosti s několika sty vývojáři Debianu, kdo Debian na BSD kernelu používá, tak se nepřihlásil jediný, jediný (!) člověk.

Nikdy bych neřekl, že se někdy dožiju toho, že se na takovýchto webech a v takovýchto diskusích budou zcela vážně hlásat tyto názory. Ano, máte na ně právo, nikdo vám nebrání, ale podle mě prostě jste na špatném místě. :-(

Ale je fakt, že jsem se vždy děsil toho, co se bude dít, až jednou nastane na naše platformy invaze lidí, vychovaných na CP/M, MS-DOSu a Windows, případně staré VMS.
Ten způsob myšlení sem prostě nepatří a je vidět, že komunity kolem Linuxu byly od začátku svým způsobem slabé a příliš rozhádané na to, aby tomu efektivně bránily...

Nevím, jestli jsem vzhledem k realitě dnešního linuxového světa na špatném místě. Problém je v tom, že v diskusích pořád někdo kříčí, že se musí dodržovat POSIX a kompatibilita s Unixem, ale když dojde na nálámí chleba, tak se zjistí, že to prostě nechce nikdo dělat. Např. o Gnome se pořád píše, jak je čím dál víc Linux-only, ale je to hlavně kvůli tomu, že kompatibilitě s BSD je ochotný se věnovat jeden člověk ze zhruba 1000, kteří přispívají do Gnome, takže podpora je taková, jakou ten jeden člověk zvládne. A že by mu ostatní házeli klacky pod nohy, to se říct nedá.

Pro mě není v případě OS dogma POSIX a Unix (tím nechci říct, že to pro mě nemá žádnou hodnotu), ale otevřený vývoj s otevřenými zdrojovými kódy. To je asi zásadní rozdíl mezi mou a vaší filozofií.

BTW na CP/M, MS-DOSu, Windows, ani VMS jsem nezačínal. Ano, hádáte správně, byl to starý dobrý Unix, ale tak nějak od přírody nejsem konzervativní a ani Unix a jeho principy nepovažuju za něco, co nebude nikdy překonané.

Váš problém je v tom, že chcete "překonávat" a inovovat pomocí principů, které s Unixem existují paralelně dlouhá léta a za tu dobu prokázaly spoustu nedostatků. Určitě i pár předností, a právě od toho tu ty platformy jsou, aby sloužily těm, kterým vyhovují.

Vy nechcete tvořit něco nového. Jen se snažíte roubovat poměrně staré věci do světa, který je s nimi nekompatibilní. Výsledkem budou různí kočkopsi, daleko horší než to co bylo na obou stranách před tím.

Nepochybně. Pár konzervativců setrává na staré víře a pár "progresivních věřících" pálí staré knihy. Bylo to tu už mockrát. A když začnete smířlivě ve stylu "jasně, pokrok ano, ale proč za sebou rovnou pálit mosty?", tak vás semelou.

jo. semelou.

kdyz se totiz sejde dohromady cela slavna skupinka: firewalld, networkmanager, dbus, systemd

tak jednoho dne proste zjistis, ze jses v roce 2014, pouzivas aplikace z roku 2013/2014, ale nastroje na debugovani mas porad z roku 1990

Jste pragmatický. Jste tak ukrutně pragmatický, že se až divím, že jste nenavrhl Linux na desktopu zahodit a pohřbít, protože ho používá jen zanedbatelné množství kocových uživatelů.

A váš druhý odstavec odhaluje, v čem se lišíme. Vy chcete otevřený vývoj, já chci stabilní a odladěný systém, do kterého vidím.

To ze podporu pre BSD robi jeden clovek moze znamenat aj nieco ine ako ze o gnome na BSD nieje zaujem.

Cim je aplikacia napisana prenositelnejsie tym menej su potrebny ludia specializovany na dany posix/unix system. A pisat prenosne aplikacie nieje az taky problem jak sa zda.

Skor asi gnome nechce nikto pouzivat/udrzo­vat/vyvijat inde. Take KDE ktore pouziva QT je nadherne prenositelne. Naproti tomu Gnome/GTK+... Radsej sa nezmienovat.

Jedno druhe nevylucuje.

Ano, ale poslednych par rokov ma gnome a vobec cele GTK+ serie viac ako obycajne, tak som to dal patricne najavo. Zlate QT.

Opravdu VSECHNY programy a distribuce?

Tak asi vsichni systemd nechteji, ze? Jinak bychom tady nevedli tuhle diskuzi. Jinak by nevznikaly boycot stranky. Jinak by lidi vazne nepremysleli o forku debianu.

Vetsine lidem (tem, co jsou proti systemd) by systemd ve skutecnosti vubec nevadil, kdyby na nem nebyla NUTNA zavislost jinych aplikaci. Problem je, ze hodne baliku zacina byt na systemd zavislych. Kdybych si mohl vzdy vybrat, jestli chci systemd nebo systemv, tak si pro servery vyberu systemv, kde si kazdy init.d script muzu prohlednout a pripadne prizpusobit, kdyz neco nechodi a pro pracovni stanici, kterou casto zapinam/vypinam bych si zvolil systemd, aby to rychlejc startovalo.

Jenze, kdyz budu nuceny pouzivat systemd a neco nepujde nastartovat, protoze nekde bude chyba, tak do te 1MB binarky (ani do tech zdrojaku) systemd se jednoduse nepodivam (protoze nejsem programator) a nezjistim, kde je chyba.

V systemv je to jednodussi. Systemv init je jednoduchy hlavni proces, ktery na zaklade jednoduche prehledne konfigurace v jednom souboru startuje par shell scriptu (/etc/init.d/rc) a par binarek (getty). Dalsi veci uz se startuji pomoci toho rc a ty init.d jsou take shell scripty. V systemv init neni nic, co by mohlo prestat fungovat (a pokud kdy bylo, tak uz to bylo za tech X let pouzivani opraveno).

Systemd je novy, jeste se to poradne neozkouselo, dela to oproti systemv init spoustu jinych veci, ktery se muzou pokazit (je to neco jako Gentoo, kde je spousta variability ohledne instalace balicku). Jedine, co muzu jako admin/uzivatel ridit, jsou systemd config soubory, kde rikam, co se ma spoustet, co to potrebuje. Ale co kdyz bude nekde v systemd chyba a bude to zlobit? Co udelam? Reportuju na systemd upstream a dostanu odpoved notabug/wontfix/can­notduplicate? To mi bude na nic.

Je to opravdu boj o svobodu, podobne jako BSD vs. GPL. GPL zarucuje plnou svobodu uzivatelum, ale nuti programatora davat zdrojovy kod. BSD dava plnou svobodu programatorum, ze si muzou rozhodnout, zda daji zdrojaky nebo ne, ale uzivatel tedy o svobodu "ziskat zdrojovy kod" prichazi.

U systemd vs. systemv je to podobne. Bud budeme chtit zachovat svobodu uzivatelu, aby si zvolil systemv, pak ale sebereme vyvojarum/balic­karum svobodu zvolit si, jak a co budou podporovat (zda oba systemv a systemd nebo pouze systemd) a budeme je nutit podporovat oba systemy. Nebo se ted bere svoboda uzivatelum/ad­ministratorum zvolit si init system a jsou nuceni pouzivat systemd.

Proto hodne lidi systemd nema rado, protoze neni zamenitelny. Pokud neco funguje se systemd a pak to nefunguje s jinym init systemem. Pokud se pouzivaji rc a init.d scripty, tak je jedno, jaky system to spousti, jestli systemv, upstart (s nejakou init.d podporou) nebo systemd (s init.d podporou).

Takže kde je problém?

Hypoteticky, když se komunita dohodne (třeba 80% hlasů), že bude chtít u souboru v inodu atribut pro označení "hidden" pro uživatele, skupinu a ostatní a při té příežitosti upustí od tečky před souborem pro ty skrytý, někdo do bug reportu napíše "soubor s tečkou je vidět", co by měl dostat jako odpověď?

"Je to chyba, opravil jsem to revertnutím jádra"? "Není to chyba, soubory s tečkou měly automaticky nastaven atribut při migraci ze staršího systému a teď se podle konvence už půl roku nesmí jenom na základě tečky skrývat", nebo snad "Pošlu ti mailem fix, nahraj si ho do komplu a hlavně nikdy nepoužívej žádný update systému, ať si to nepřepíšeš"?

Jiná situace je v případě, že se soubor neskryje na disku přimontovaným po NFS na základě těch atributů...

A co se týká binárky, tak tam je poměrně jasno. Měla by dělat standardní věci - vzít si ze souboru ve standardním formátu informace o procesu a podle toho ho standardně spustit. Stejně pro aplikaci A, B i C. Když se někde chová nestandardně, tak místo skriptu zkontroluju data o procesu, jestli tam něco nechybí nebo nepřebývá. Nejste progamátor, tak by pro vás mělo být jednodušší zkontrolovat seznam něčeho, než sekvenci nějakých příkazů, dohledávat co který dělá,...

Co nechapes na tom, ze systemd pozral trebas udev, a zacal ho mrvit k obrazu svymu? Co nechapes na tom, ze admini chteji textovej log, a kazdej navic jinej, pricemz v systemd proste dostanou binarni blob? Co nechapes na tom, ze script si spravi kazdej pepek vyskoc, kdezto s binarkou neudela nic? Co nechapes na tom, ze zadnem svepravnej clovek nespousti na stanici dhcp server? Natoz aby spoustel zcela libovolny sitovy sluzby pred startem firewallu?

Ovšem na druhé straně:
- Initd je klubko skriptů, které se nedá používat pomocí API. Nejdou ani základní operace jako zjištění nainstalovaných deamonů, zjištění stavu deamonu, jeho nastartování a zastavení. Vám to jako adminovi asi může být jedno, protože API v životě neuvidíte, mě to jedno není.
- Initd neumožňuje ani zjistit jestli deamon běží. Obchází se to například pomocí signal files, ale ty nejsou spolehlivé (například když systém neočekávaně vypnete, signal file zůstane, takže deamon "běží"; ochrana číslem procesu v signal file není spolehlivá).
- Initd neposkytuje deamonům interface například pro jejich ukončení, takže se to implementuje jak se dá. Už jsem viděl i init skript, který se pomocí řádkového klienta připojoval k DB a posílal ji příkaz aby se ukončila. WTF?
- Initd prakticky neřeší závislosti.
- Initd skripty jsou klubko které si admini rádi přizpůsobují, i když mají jen startovat a zastavovat deamon. Jakýkoliv upgrade obsahující změnu init skriptu pak změny přepíše.
- Initd neřeší restart daemonu nebo jinou akci v případě neočekávaného ukončení daemonu.
- I unixová konkurence má lepší daemon management (nemluvě o Windows, které ho mají minimálně 19 let). Solaris má Service Management Facility, Apple má launchd (který je "standardně" zplácaný ve stylu Applu, ale na API se alespoň dá dostat).

Co nechápeš na tom, že SD je jiný, ale ne horší?

Vem si takový proces. Co představuje z pohledu jádra? Záznam v tabulce, kde je hlavní vlákno, vlastník, přidělená paměť,... a nějaká standardní část jádra s tím standardním způsobem pracuje. Nepíše se to pro každý proces extra.

Co je z pohledu systému to vlákno? BInární blob maplněný prioritou, statusem, vlastníkem, pointerem na instrukci, kde se tomu sebere procesor při multitaskingu, obrazem stack pointeru,.. obsluhovaným standardníma funkcema v jádře bez rozdílu. To zpracování a multiplex se neprogramuje pro každý vlákno extra.

Co je zavedení modulu / spuštění procesu? Z pohledu jednoho spuštění skriptu (čti extra programu) pro činnost, která se dělá na X modulech stejně, náchylná na chyby. Z pohledu druhýho nějaký popis, kde je napsáno, že požaduje běh toho a toho modulu, že vlastnost X má mít hodnotu Y,... a definovaným kódem, kde část ověří běh požadovaných modulů (případně je standardní cestou automaticky spustí, aniž bych musel dopisovat závislosti do skriptů), část se stará o to, aby pomocí nějaké funkce GetProperty(X) byla proměnná v procesu naplněna hodnotou Y. Obojí funguje, ale je tam jiná náchylnost k chybám, jiná údržba...

Co je ale zásadní, pokud dostanu při psaní SW požadavek " ovládací prvek funkce x se zobazí, pokud běží démon y, který s touto funkcí pracuje", budou dvě možnosti spuštění systému (skriptem, kde není korektní způsob, jak běh démona rozeznat (jeden dodavatel použije mutex v paměti, další něso píše do nějakýho souboru, v nové verzi se změní text v mutexu,...) a druhý na to má API funkci Is DaemonRunning() ), pochopitelně to napřed vyzkouším tam, kde je to jednodušší. Pokud se autoři distra domluví, že ten jednodušší systém bude preferovaný, protože jim ulehčí práci, bude postupně ubývat aplikací pro ten první. Až to dojde do bodu, že ten první zhyne na nedostatek kompatibilních aplikací. U initd je to teď ve fázi, kdy se nikomu z pogramátorů nechce dělat to pro dva systémy (stojí to čas a peníze) a nechce si komplikovat život s podporou obojího, když v jednom někde není jednoznačná specifikace, jak to udělat. Když chce někdo initd, může si to do balíků klíďo píďo dopsat, zdrojáky má k dispozici. Pokud nechce / neumí, musí holt vzít za vděk tím, co udělali jiní.

BInární log je taku jenom jedna z možností. Textpový je čitelnější, ale jak se do něj díváte? Napíšete příkaz a soubor logu. Jak se podíváte do binárního? Napíšete příkaz a soubor logu. Kde je tady sakra rozdíl v tom, jaký je formát dat toho souboru?

U binárního odpadá konverze do textu přímo v systému - ušetří se čas při pádu a není potřeba konvertovat data do logu, na který se nikdo nepodívá. Do stejně velkýho souboru na disku se vleze víc záznamů (char[16] vs. longint pro čas - 75% úspora bez ztráty dat apod.). Když chci vlastní pohled na data (třeba formát času v sekundách do konce století), stačí si přebuildovat prohlížecí nástroj a změnit formátovací string na jednom řádku bez toho, že bych psal nějakou novou utilitu, která bude parsovat text a pak ho zpracovávat... Možnost rovnou tu rutinu jednoduše upravit na výstup třeba v .html apod.

Nesmíš se na to dívat tak pesimisticky. Kdyby byl systemd blbost, tak by se nechytl. Asi hodně lidem dává něco, co starý systém neměl.

Od kdy nejaky api zjisti, jestli demon bezi? Jo aha, tys widle vzivote nevidel zejo ... lo lool looooll ....

Zrovna dneska sem resil, ze "sluzba bezi" ... ale jaksi ... nefunguje, protoze ... jo aha, ona nebezi, prestoze si api mysli ze bezi, a proto ji pochopitelne nedovoli nastartovat, protoze startovat bezici sluzbu je prece volovina, a stopnout ji nejde, protoze sluzba neodpovi ... lol.

Mno du preinstalot tuxe na widle, tam zabira aspon restart HW ... a kdyz nic jinyho, tak se muzu uspokojit tim, ze co znamena "neznama chyba #A32456786" nevi ani M$. A logy to projistotu nema zadny, takze ani nema smysl v nich neco hledat.

Pokud je to rozumně*) definováno a korektně**) implementováno na straně systému i démona, tak zjistí. Když to korektně nefunguje, dá se reportovat bug a řešit.

Horší je situace, kdy neexistuje standardní metoda, kterou by šlo takovou věc zjistit. Funguje snad jenom ústní dohoda s autorem, že máš zkusit něakou fintu... a když na tuhle dohodu původní autor zapomene nebo ve vývoji pokračuje někdo jiný, tak jsi se svou aplikací v háji.

*) Rozumně znamená s ověřováním za běhu, např. watchdogem, ne jenom uložení flagu při startu.
**) Autor musí vědět, co dělá. Podle jasné a jednoznačné dokumentace.

API zjistí, jestli je služba nastartovaná. Samozřejmě neřekne jestli ta služba dělá co má. Jinými slovy víte že DB engine je nastartovaný, ale nevíte jestli opravdu odpovídá na requesty. Přesně jako na Unixech.

Ad "sluzba bezi" ... ale jaksi ... nefunguje, protoze ... a stopnout ji nejde, protoze sluzba neodpovi - to máte nějakou chybu v dané službě (opět podobně jako se to občas stává na Unixech). BTW často je to vidět u služeb zbastlených přes prunsrv.exe nebo srvany.exe, kde executable není ve skutečnosti není služba. Workaround je sestřelit proces, pak je možné službu znovu nastartovat.

To co popisujete je popis chyby servisu, a tedy dost nezajímavé. Já psal o tom, že initd neposkytuje API pro 1. zjištění jestli je daemon nainstalovaný, 2. jeho spuštění, 3. jeho zastavení.

Ad co znamena "neznama chyba #A32456786" nevi ani M$ - pokud jde o standardní Win32 chybu, tak to samozřejmě MS ví. A jako admin byste to měl vědět i vy. Ale člověk nesmí mít na některé adminy přehnaná očekávání, že? :)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx
http://blogs.msdn.com/b/alexdan/archive/2008/02/28/looking-up-error-codes-with-err-exe.aspx

Imho se autor nestaví na žádnou ze stran a je objektivní. Říká, že když se někdo chová určitým způsobem, může to pro (jakýkoli) FOSS projekt znamenat problém a doporučuje způsob, jak reagovat, aby se dopady problému co nejvíce snížily.

Respektive protože Ubuntu integruje systemd, tak by šlo říct, že autor se staví na stranu systemd. Nicméně není mi jasné, z které části textu plyne, že autor "myslí" článek pouze za jednu ze dvou stran. Rád si přečtu objasnění.