Vlákno názorů k článku Co se systemd… a Linuxem od Lael Ophir - Upřímně moc nechápu, proč je okolo tohoto tématu...
-
Lael Ophir (neregistrovaný)
Upřímně moc nechápu, proč je okolo tohoto tématu tak mocná diskuse. Systemd spouští deamony, což je celkem triviální práce. Co je potřeba?
- Definovat jednotné rozhraní pro služby - start(), stop(), suspent(), resume(), případně nějakou rozšiřitelnost a callback pro případ změny stavu (servis se zastavil).
- Definovat způsob registrace servisů (executable, parameters, dependencies) a způsob startu (automatic, delayed, manual), případně recovery action (start again, run script)
- Vytvořit k tomu API, které umožní zjistit seznam servisů, zjistit jejich stav, provést na službě metody (start/stop/...), založit servis a odstranit ho.
- Zajistit inicializaci služeb při startu. Klidně s volbou pro paralelní/sériový start.
- Napsat nějaké GUI, s tím že další GUI za použití veřejných API se dá napsat kdokoliv později.Asi to není job na jeden víkend, ale pořád mi to přijde celkem jednoduché.
-
Jimmy (neregistrovaný)
Tak mocná diskuze je kolem toho přesně proto, že tuhle jednoduchou věc řeší neuvěřitelně složitým způsobem na 500 000 řádkách kódu (http://jdem.cz/bhu8f6)… a k tomu dalších milion věcí, který s init systémem vůbec nesouvisí (logování, device manager atd).
Přitom už tu dávno máme pokročilé, ale stále jednoduché init systémy, které tohle všechno umí (tedy krom recovery). Například OpenRC (ano, i paralelní start a ne, nejsou to „jen“ shell skripty, umí i zcela deklarativní konfiguraci).
-
Lael Ophir (neregistrovaný)
Přitom na NT to funguje zcela bez problému, a v Sunu udělali něco dost podobného.
http://docs.oracle.com/cd/E26502_01/html/E29003/hbrunlevels-25516.htm -
Tak nějak nevím, kde Phoronix vzal 500k, ohloh.net dává něco okolo 270k: http://www.ohloh.net/p/systemd a výstup cloc nad aktuální master branchí taky dává mnohem nižší číslo:
systemd (master)$ cloc . 1510 text files. 1394 unique files. 454 files ignored. http://cloc.sourceforge.net v 1.60 T=4.27 s (233.3 files/s, 78173.6 lines/s) -------------------------------------------------------------------------------- Language files blank comment code -------------------------------------------------------------------------------- C 482 53214 17237 177381 XML 184 6708 2494 37068 C/C++ Header 282 5275 6136 11775 make 8 1455 306 5820 m4 6 225 44 2223 Perl 3 107 35 1754 Bourne Again Shell 4 170 214 1016 Python 10 321 553 774 HTML 2 91 3 467 Bourne Shell 8 80 62 354 XSLT 2 32 33 183 CSS 1 42 3 151 Javascript 3 31 6 148 YAML 1 0 0 14 Lisp 1 1 3 3 -------------------------------------------------------------------------------- SUM: 997 67752 27129 239131 -------------------------------------------------------------------------------- -
Dobře, sice mi teď připadá, že kdo chce psa bít, ...
Stejně tady sem jako anti-FUD nástroj ještě hodím číslo, samotný systemd (tedy adresář src/core/) má 32k řádků a to je sakra rozdíl od půl miliónu...:
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- C 62 10131 2733 32168 C/C++ Header 62 1174 1169 2087 m4 1 0 0 322 make 1 4 19 5 ------------------------------------------------------------------------------- SUM: 126 11309 3921 34582 -------------------------------------------------------------------------------A osobně mi ten kód připadá čistě psaný a vcelku srozumitelný na to, že do něj koukám poprvé v životě...
-
Filip JirsákStříbrný podporovatelZkuste se podívat na Daemontools. DJB v době Sendmailu přišel s Qmailem, který místo jednoho velkého procesu pro vše zavedl specializovaný program pro každou část zpracování e-mailů. Pak v době Bindu přišel s TinyDNS, kde opět každý program dělá jen jednu věc. Takže z toho, že slévá vše dohromady bych DJB určitě nepodezíral. Přitom Daemontools je balík, který obsahuje správce služeb, logování a nastavení politiky procesů (uid/gid, limity).
Ony jednotlivé části zůstávají samostatné, každá má jednu zodpovědnost. Akorát se vyvíjejí společně – to je problém? Vždyť ty jiné části klidně můžete ignorovat. U jádra vám taky asi nevadí, že kód zajímavý pro vás (třeba platforma x86-64) je ve společném repositáři s ARM a SPARCem…
ČLÁNKY DO MAILU