Debian řeší, čím nahradit SysVinit

Vývojáři Debianu řeší, kterým initem nahradit SysVinit. Měl by to být systemd nebo Upstart? Do diskuse se zapojil i Lennart Poettering na Google+. Nevěnuje se pouze technickým otázkám (cgroup, kdbus, logind). Píše, že záleží pouze na Debianu, zda bude následovat Canonical s Upstartem, Mirem a Unity. Rozhodovat bude technická komise (Debian Technical Committee, #727708). Minimálně dva její členové ale hrají významnou roli ve vývoji Ubuntu a jsou spoluzodpovědní za strategii Canonicalu. Je tedy nepravděpodobné, že by hlasovali proti Upstartu.

30.10.2013 00:39 | Ladislav Hagara | Komunita

Komentáře

[aa]

Upstart nebrat: https://bugs.launchpad.net/upstart/+bug/406397

Na demonstraciu krasy navrhu staci tam napisany workaround:

#!/bin/bash

usleep 1 &
firstPID=$!
#first lets exhaust the space
while [ $! -ge $firstPID ]
do
    usleep 1 &
done

while [ $! -le $1 ]
do
    usleep 1 &
done

[Michal Vyskočil]

A já si do teď myslel, že fakt, že upstart používá ptrace() je Lennartova ošklivá pomluva ...

[PavelC]

Kazdymu co jeho jest, ale nastesti je tu jeste Slackware pod vedenim osvicieneho diktatora ;)

Dalsim krokem bude odstraneni shellu a prepsani skriptu do C ? Odstraneni konzole a emulator terminalu na urovni cmd.exe z Win a jen po instalaci baliku gnome-extra-unsupported-tools-for-naggers ?

Vymenit jednoduchost, univerzalnost a osvedcenost za teoreticky rychlejsi boot a podporu zcela okrajovych cgroups, mi neprijde jako dvakrat moudre. Ale cas samozrejme ukaze. Kazdopadne mam pocit, ze vrchol uz linux zazil a ze to jde v posledni dobe nejak z kopce, za velkeho prispeni komercnich firem jako RH a Canonical. GNOME 3 vs 2, KDE4 vs 3, Gtk+ 3 vs 2, Firefox 24 vs ~>4, Linux >3.5 vs 2.6 atd.

[PavelC]

s/osvicieneho/osviceneho/

[aa]

neni to spis narek proti jakekoli zmene? Az bude KDE5, tak budete tvrdit ze KDE4 bylo lepsi a ze to jde z kopce. Obecne: kazda novejsi verze prinasi nove chyby, tudiz se vam muze subjektivne zdat horsi (protoze stara verze uz ma chyby vychytane), a pokud jste zvykly na stare veci, ani nechcete (nemate potrebu) vyuzivat nove vlastnosti a tedy vidite pouze ty chyby a zadny rozvoj. Nektere programy jdou z kopce, ale podle vaseho vyjadreni jde z kopce snad vsechno, takze v tom vidim spis maly nadhled.

[kavol]

Obecne: kazda novejsi verze prinasi nove chyby, tudiz se vam muze subjektivne zdat horsi (protoze stara verze uz ma chyby vychytane), a pokud jste zvykly na stare veci, ani nechcete (nemate potrebu) vyuzivat nove vlastnosti a tedy vidite pouze ty chyby a zadny rozvoj.

poslyš, a viděl jsi KDE 4.0 (4.1, 4.2, 4.3)? - to nebylo o nových chybách, tam chyběly zcela zásadní featury z KDE 3.x ... a čím to, že mezi KDE 1 a 2, a potom 2 a 3, si uživatelé tak nestěžovali?

[Raduz]

A viděli kritici, kteří ze setrvačnosti melou pořád dokola to svoje "KDE4 je strašný, samá chyba, zlatý KDE3, to byl nejlepší DE, ještě že máme Trinity, toho se nikdy nevzdáme!", KDE 4.9, 4.10, 4.11? KDE3 jsem používal ve své době jako hlavní desktop hodně dlouho, a dnes bych se k němu od KDE4 v posledních verzích nechtěl vracet ani za zlatý prase. Jo, první čtyřkové verze byly nepoužitelné s strašné, ale upřímně, koho to dnes ještě zajímá? Když teda nepočítám hledače hole na bití psa?

[R]

Pokial viem, tak KMail dodnes nefunguje. Ale predpokladam, ze ho nepouzivas, tak je KDE4 vyborne...

[Raduz]

Používám KMail denně a bez problémů. Věřím že s ním lidi někdy mívají potíže, ale bude asi rozdíl mezi "nefunguje" a "v některých případech dělá problémy", že ano...

[pavlix]

ale bude asi rozdíl mezi "nefunguje" a "v některých případech dělá problémy", že ano...

Přesně tak. Je rozdíl mezi je vhodný pro ukázky a je vhodný na práci.

[Bhua]

> "nefunguje" a "v některých případech dělá problémy"

Jeste je horsi stupen, vsechno funguje zdanlive dobre ale obcas 'zmizi' email. Dolovat o overovat 20GB mailu z inkrementalnich zaloh bylo fakt super.KMail nikdy vice.

[marek_hb]

no, tak nevím proč mi teda kmail2 a vlastně celý kontact funguje bez problémů - maily, kalendář a já nevím co ještě

[Prcek]

Měl jsem s novým kmailem hodně problémů (všechno mu trvalo jak psovi pastva a kolikrát ani nechtěl otevřít mail). Ukázalo se, že problémy dělal jeden z mých účtů, které jsem měl v kmailu nastaveny. Všechno to jsou IMAP účty. Když jsem ten jeden problémový vyřadil, tak všechny problémy přestaly a ostatní účty fungují v pohodě. Sice nevím, proč jsou s tímhle konkrétním účtem takové problémy, ale pozitivní je, že kmail je v tom částěčně nevinně - možná je to částečně chyba v nastavení IMAP serveru toho účtu, kdo ví...

[dustin]

Problém je, že se nové KDE do běžných distribucí dostaly příliš brzo a tím si výrazně poškodily pověst. A ta se hodně těžko napravuje, trvá roky, než nedůvěra vyprchá. Ale to měli vývojáři moc dobře vědět. Jenže samozřejmě každý chce vidět své dítko běhat po světě, každý se chce co nejrychleji pochlubit. To samé se týká pulseaudia, systemd, unity, gnome3 atd. Bohužel to dle mého názoru není ani trochu profesionální přístup.

[kavol]

píšu z počítače s KDE 4.11.2, takže něco málo o tom vím, a jak správně píše kolega, použitelnost některých komponent je i v této verzi, řekněme, diskutabilní(*) ...

nicméně, já jsem rozporoval tvrzení, že u KDE4 by ten dojem byl subjektivní, že by to bylo jen o tom, že si nevšiml nových featur apod. - sám mi dáváš za pravdu ohledně stavu raných verzí, takže co to meleš o hledání hole?

a to, že KDE 4.0 dnes uživatele 4.11 nezajímá, ještě neimplikuje, že bychom na něj měli zapomenout z hlediska správy projektu - nebo ty snad toužíš zopakovat si historii a opět mít na dva roky totálně rozbitý desktop, až se ti někdo rozhodne nahrnout nedodělané KDE5?

(*) včera mi například po restartu stroje volala máti, že jí kmail nenaběhne - WTF??? - "normálně" se odhlásila, ale když jsem se tam nasshačkoval, tak jsem zjistil, že po ní zbylo asi dvacet KDE procesů jako kwin apod., hm, pozabíjel jsem to, zkusil si pustit kmail, tvářil se normálně, no tak jsem zvědav, s čím přijde dnes ...

[Raduz]

Bavíme se o dvou úplně rozdílných věcech. Jo, souhlasím s tím že první verze KDE4 byly strašné, a taky jsem ho začal pořádně používat až někdy okolo verze 4.5. Nicméně je to dávná minulost, a hledisko správy projektu je mi z mého hlediska koncového uživatele zcela ukradené. A ne, nestojím o to mít s příchodem KDE5 rozvrtaný desktop. Pokud k tomu dojde, počkám až ho zase dovrtají dohromady, a pak uvidím jestli mi bude vyhovovat. Do té doby mám na čem fungovat. Je jen únavné pořad dokola číst ty samé mantry o "nepoužitelném" KDE4, které už dávno nemají opodstatnění. Tím neříkám že je KDE dokonalé a bezvadné, ale to není žádný systém na žádném počítači. Dokonalé a bezvadné jsou jen systémy které už nepoužíváme, a měli jsme už tudíž čas zapomenout na jejich chyby (já to mám takhle s Amigou).

[lertimir]

To je ale více vina správců distribucí, než vývojářů KDE. Měli KDE4 zařadit až v dostatečně funkčním stavu. A možná KDE tvůrci měli číslovat více defenzivně, něco jako 4.0.1, 4.0.2 .. a 4.1 mít až použitelný desktop. Ostatně jakou verzi KDE4 zařadili správci profi dister RH/CentOS, SLED do svých desktopů?

[kavol]

To je ale více vina správců distribucí, než vývojářů KDE. Měli KDE4 zařadit až v dostatečně funkčním stavu.

ale ne, už zase tenhle nesmysl? - jdi s tím papouškováním Aaronovejch kydů někam ...

[little.owl]

Na to neni treba Aaron, aby to cloveka napadlo ...

[lertimir]

Nikoho jsem nepapouškoval, protože to je naprosto logické. Když se provádí takto obrovská změna, tak je jasné, že nějakou dobu bude systém/prostředí v prealfa a alfa fázi. Komerční firma jako MS nebo Apple si tuto fázi vyřeší interně a má na to svou armádičku testerů. Komunitní projekt takové interní testery nemá a musí proto testování směřovat na komunitu. Navíc množství aktivních vývojářů je v komunitním projektu méně než v silné firmě, takže vývoj trvá déle. A bylo čistě na správcích distribucí jestli zvolí vývojářskou volbu nebo stabilní volbu. Proto jsem měl dotaz: Kdy zařadili do distribuce KDE4 komerční distra RH a SLED?

[trekker.dk]

Když se provádí takto obrovská změna, tak je jasné, že nějakou dobu bude systém/prostředí v prealfa a alfa fázi

A proto se to označí číslem verze například 4.0a, 3.99 nebo tak něco. A ne, že se vydá 4.0 a pak se (nadsázka) dodatečně někam dopíše, že jsme jasně psali předem, že to je jenom taková beta.

[kavol]

Nikoho jsem nepapouškoval, protože to je naprosto logické.

hmmm ... jaké máš zkušenosti s distribucí software? - udržuješ v nějakém downstreamu balíčky, anebo vyvíjíš v upstreamu něco, co ti někdo jiný balí?

já na tom neshledávám nic logického ani z pohledu uživatele(*), natož z pohledu distributora - upstream mi dal balíčky, já je dám lidem, hotovo

Když se provádí takto obrovská změna, tak je jasné, že nějakou dobu bude systém/prostředí v prealfa a alfa fázi. Komerční firma jako MS nebo Apple si tuto fázi vyřeší interně a má na to svou armádičku testerů. Komunitní projekt takové interní testery nemá a musí proto testování směřovat na komunitu. Navíc množství aktivních vývojářů je v komunitním projektu méně než v silné firmě, takže vývoj trvá déle. A bylo čistě na správcích distribucí jestli zvolí vývojářskou volbu nebo stabilní volbu.

stejně jako Aaron popíráš sám sebe

to komunitní testování mohlo probíhat i bez toho, aby se to vydalo jako 4.0 - byly různé nightbuildy, návody jak to zkompilovat ze svn atd.

správci distribucí nezvolili žádnou "vývojářskou volbu", oni prostě zabalili to, co upstream označil za stabilní

(*) tady je na místě vrátit se k tomu logické/nelogické z pohledu uživatele: jsem BFU, jdu na stránky projektu, dozvím se, že verze 4.0 je the latest and greatest a mnohem lepší než 3.x, jdu zpět ke svému distru a očekávám, že tam teda tu latest & greatest verzi budu mít (plusmínus nějaký ten měsíc jak se sejde vývojový cyklus) a ono hovno a budu distributorům líbat ruce za to, že jsou tak pomalí a ještě to tam nemají?

Proto jsem měl dotaz: Kdy zařadili do distribuce KDE4 komerční distra RH a SLED?

RHEL hned v prvním vydání po vydání KDE4, tedy v RHEL 6

SLED rovněž tak (akorát číslo verze nebylo 6 ale 11 )

[dustin]

Souhlasím, že vývojáři sami neměli projekt vychvalovat do nebes a lákat na něj uživatele, ale na férovku napsat, že je to syrové a vhodné jen pro testery. Jenže...

[Ruža Becelin]

Nebyla 4.0 jenom v bete? RHEL 6.0 release notes uvadi KDE 4.3, ktere je tam doted?

[kavol]

Nebyla 4.0 jenom v bete? RHEL 6.0 release notes uvadi KDE 4.3, ktere je tam doted?

dotaz zněl na KDE4, přičemž KDE4 != KDE 4.0 nýbrž KDE 4.0 ∈ KDE4

RHEL6 vyšel v listopadu 2010, KDE 4.0 v lednu 2008; KDE 4.3 v srpnu 2009, čili to odpovídá zhruba ročnímu zmražení před vydáním (to je to "plusmínus nějaký ten měsíc jak se sejde vývojový cyklus") - stejně tak jestliže RHEL7 je teď v public betě s KDE 4.10, tak se asi pro RHEL 7.0 nebude těsně před releasem rebasovat na KDE 4.12 který vyjde v únoru 2014

[Ruža Becelin]

RHEL7 je teď v public betě s KDE 4.10, tak se asi pro RHEL 7.0 nebude těsně před releasem rebasovat na KDE 4.12 který vyjde v únoru 2014

Hmm tak to je docela blby, minimalne 4.11 by se sikla

[Kaacz]

Mně nesralo to, že do enterprise SLED 11 dali KDE4. Chyba byla ta, že tam nenechali KDE3. Chyba byla "KDE4.0 ONLY".

Zrovna v té době jsem to v jedné firmě dával na upgradované nadupané "workstation" pro výpočet/návrh turbin. Uživatelé byli zvyklí na KDE3 .. ale raději přešli na Gnome2 .. prostě potřebovali pracovat a ne ladit nějakou betu.. :)

Že dali KDE 4.0 na Fedoru nebo openSuSE ? .. ok .. ale na enterprise distru to nemělo co dělat. A pokud ano, mělo souběžně zůstat zachováno KDE3 ..

[Rezza]

Zrovna v enterprise distru si nemuzes dovolit podporovat neco, na co hodil upstream bobek... Nebo muzes, ale bude to 2x tolik bolet. Na tech deset let .

[Rezza]

Znas to - opakovana lez se stava pravdou a nakonec ji kazdy uveri. Takze styl 1984 ma samozrejme velkou sanci projit :).

[little.owl]

To je ale více vina správců distribucí, než vývojářů KDE.

Muhehe.

Mne u Kavola neprosel ani pomer 60:40, i kdyz s ohledem na jejich release process me celkem presvedcil.

[Kaacz]

V té době používalo na desktopu Linux hodně málo lidí a ještě méně nějaká KDE (1,2,3). Dá se říci, že teprve KDE 3 k sobě přitáhly větší počet uživatelů (logika Windows, lepší ergonomie) a zároveň i Linux dospěl k desktopové použitelnosti. Logicky tedy při mnohem větší základně jsou výkřiky nevole více vidět. To asi tak vše k tomu rozdílu.

Samozřejmě násobeno předčasným vrhnutím KDE 4.x mezi běžné uživatele...

[kavol]

V té době používalo na desktopu Linux hodně málo lidí a ještě méně nějaká KDE (1,2,3). Dá se říci, že teprve KDE 3 k sobě přitáhly větší počet uživatelů (logika Windows, lepší ergonomie) a zároveň i Linux dospěl k desktopové použitelnosti. Logicky tedy při mnohem větší základně jsou výkřiky nevole více vidět. To asi tak vše k tomu rozdílu.

ale prdlačku, když si u nějaký verze stěžuje padesát lidí z tisíce, a u další by to tedy teoreticky bylo pětset z deseti tisíc, a ono je to pět tisíc z deseti tisíc, tak je to prostě vidět a neschováš to za to, že vzrostl počet uživatelů z tisíce na deset tisíc

[Mti.]

stara verze uz ma chyby vychytane

... nebo uz sme si na ne zvykli. Kdezto u nove/jine verze jsou jine chyby, na ktere si musime teprve zvykat.

[potato]

Napsat ‚zcela okrajových cgroups‘ je snadné. Rozhlédnout se kolem sebe a přiznat si, kdo a co je tu vlastně okrajové, je zřejmě obtížnější...

[Nikola Ciprich]

+1

[Dvorak]

+1

[Foo Bar]

Jde vidět, že jste v životě nepsal žádný složitější init script. Jinak byste nemohl napsat takový nesmysl o shell init scriptech jako "jednoduchost, univerzalnost a osvedcenost".

[kralyk z abclinuxu]

+1, to jsou už klasický kecy obhajující smrad a teplíčko starých init skriptů.

Další taková oblíbená fáma je to "teoretické" zrychlení, které je ve skutečnosti nejen teoretické, ale i praktické, a to dost výrazně.

[j]

Nazdar praktiku ... ty startujes svoje stroje 10x za hodinu? To bys mel ovsem zmigrovat na widle, ty sou stabilnejsi. V opacnym pripade je rychlost startu OS zcela irelevantni parametr, protoze ja svuj stroj (desktop) zapinam jednou denne, a jestli mi bude startovat 30s nebo minutu je mi zcela uprdele.

Zato co pro me rozhodne relevantni parametr je, je bordel v logu. Proto nepouzivam v zadnym pripade zadny zpusoby paralelniho startu, protoze pak appky logujou jedna pres druhou, a kdyz se neco podela, tak to je vazne posusnani ... a tohle presne systemd dela. Navic na scriptu se dost tezko neco podela, kdezto binarka se muze podelat dycky ... script si pripadne spravim, binarku tezko ... jo jiste, muzu nasosat zdrojaky, stravit par dnu hledanim bugu a pak si to trebas i spravit ... Uz vubec nemluve o tom, ze kdyz se podela script, tak je to jeden script jedny veci ... rozhodne se mi kvuli tomu nestane, ze nenastartuje system. Kdyz se podela systemd ... tak nenastartuje nic.

[Sešívaný]

Je celá řada oblastí, kde je rychlost startu systému sakra důležitá a troufal bych si tvrdit, že zrovna tyto oblasti jsou čím dál důležitější. Když jsem slyšel, kolik je průměrná doba běhu virtuálních mašin v Amazonu, tak jsem nevěřil vlastním uším. Tam je rozdíl 30 sekund naprosto zásadní. U embedded zařízení to je taky dost důležité.

[little.owl]

U embedded zařízení to je taky dost důležité.

Embedded svetu se systemd spise libi. Tam nejde jen o rychlost bootovani, ale i o koncept event driven rizeni i za behu a moznost limitovat resources.

[x]

No, tak treba rump na NetBSD. Start v milisekundach, protoze nevirtualizuju cely OS, ale jen komponenty, ktere nutne potrebuju k behu danne aplikace. Napriklad jen TCP/IP stack a filesystem a nic jineho atp. To vse na masine, ktera muze bezet mesice bez rebootu a pouzivam logicky a snadno ovladatelny rc system, ktery pochopi kazdy se zaklady IT a schopnosti cist anglicky a pouzivat mozek.

Ale obecne jsem rad, ze zde existuji Open source Unix-like OS, ktere nejsou zavsivene komercnima firmama a "vyvojarema", kteri neco prekopou, rozbiji, "zesloziti" jen proto, ze zrovna muzou a proto, ze maji dojem, ze kdekdo musi byt programator a mit pochopeni pro jejich zabavu, ktera je o vyvijeni a hrabani se v kodu, ne o tom aby to fungovalo.

[little.owl]

NetBSD rump kernel a Anykernel jsou ale uplne neco jineho, s limitovanym pouzitim,

[kralyk z abclinuxu]

Co je irelevantní pro tebe, nemusí být irelevantní pro mě a co je pro mě relevantní parametr OS, to posoudím sám Startuju OS ještě méně častěji než ty, ale pomalý start mi prostě hodně vadí. A se starými init scripty byl ten start neskutečně pomalej.

Bordel v logu nepozoruju.

Navic na scriptu se dost tezko neco podela

lol

[chrono]

Čo je neskutočne pomalé pre teba, nemusí byť neskutočne pomalé pre mňa. ;)

[Kaacz]

Pánové, pamatujete si ještě o čem je tato diskuze? Je o Debianu, serverové distribuci. Ne desktop.

A víte jak často u nás v práci restartujeme servery ? Jen při upgrade jádra. Pokud se upgraduje technologická platforma na tím, není důvod restartovat. Technologické servery ochráněné zvenčí jsou často i updatově zamražené na příkaz dodavatele. Ty mají uptime několik roků. Některé od vzniku dané technologické platformy až do jejího zrušení. 5-6 roků není žádný problém.. Pak většinou daná technologie končí nebo se přesune na novější HW. Často bývá upgrade HW dřívější důvod k ukončení uptime.

Server má běžet co nejdéle, reboot je nežádaná situace na úrovni závady s dopadem na poskytovanou službu. Tak mi vysvětlete jediný důvod proč na serveru paralelizovat boot, který by v ideálním případě měl proběhnou jen jedinkrát za dobu "životnosti" serveru.

Mnoho profi serverů má tak dlouho trvající HW diagnostiku v BIOSu, že doba bootu je úplně nezajímavá. Navíc to zrychlení je nepodstatné a když se něco nevede, ta paralelizace to jen stěžuje debugovat. Ja teda na serverech s distry, kde už to je, tu paralelizaci vypinám ..

Nechápu, proč do diskuse o serverovém distru píšou lidé, kteří evidentně nemají žádné zkušenosti s opravdovými enterprise servery, na kterých je poskytována služba.

[kavol]

co se týče "opravdového enterprise", pak ty prozměnu opomíjíš virtualizaci (nicméně to je na zcela jinou diskusi, jaký má smysl nahazovat celou mašinu včetně boot procesu, když máme uspávání, popřípadě technologie jak "dostat do chlívečku" jen nějaký kus softu nad běžícím systémem, apod.)

[little.owl]

(a) Debian neni jen serverove distro

(b) Vy na opravdove 'enterprise servery' cpete Debian?

[David Jaša]

(c) vy ještě nevirtualizujete?

[Pev]

(c) vy ještě nevirtualizujete?

I hosty je občas nutné aktualizovat a pak restartovat (security patche na kernel jsou časté).

[David Jaša]

Doba bootu hosta je snad nezajímavá, protože 1. se VMky odmigrují jinam a zátěž převezmou další stroje v clusteru a 2. ve srovnání s minutami POSTu jsou maximálně desítky sekund rozdílu mezi sysvinit a čímkoliv rychlejším nezajímavé. Zato boot VMek je zajímavý - už jen protože POST tam trvá sekundy a druhak kvůli věcem jako třeba pooly.

[Pev]

Pánové, pamatujete si ještě o čem je tato diskuze? Je o Debianu, serverové distribuci. Ne desktop.

Já tedy používám Debian jak na serverech, tak i na notebooku, kde je pro mě rychlost zajímavý parametr (ne nutně nejdůležitější).

Mnoho profi serverů má tak dlouho trvající HW diagnostiku v BIOSu, že doba bootu je úplně nezajímavá. Navíc to zrychlení je nepodstatné a když se něco nevede, ta paralelizace to jen stěžuje debugovat. Ja teda na serverech s distry, kde už to je, tu paralelizaci vypinám ..

Tak tak, naběhnutí železa nám na dom0 trvá opravdu nejdéle . Ale nevím, jestli bych se kvůli tomu s virtualizací vypínal (samotné guesty pak také nějakou dobu nabíhají).

[Jendа]

Já tedy používám Debian jak na serverech, tak i na notebooku, kde je pro mě rychlost zajímavý parametr (ne nutně nejdůležitější).

Já mám na notebooku uptime asi měsíc.

Tak tak, naběhnutí železa nám na dom0 trvá opravdu nejdéle .

Jo, to je tragický.

[trekker.dk]

to jsou už klasický kecy obhajující smrad a teplíčko starých init skriptů.

No a tohle zase klasický kecy hujerů, co bezmyšlenkovitě přeberou jakoukoliv hovadinu, jenom protože je nová a ne stará.

Další taková oblíbená fáma je to "teoretické" zrychlení, které je ve skutečnosti nejen teoretické, ale i praktické, a to dost výrazně.

a) na většině instalací to není relevantní, protože se nestartují každých pět minut.

b) s init skripty se paralelní start dá udělat taky. Debian Testing už to tak AFAIK má (a jo, hned mě to koplo)

Tím neříkám, že s init skripty na věčné časy a nikdy jinak. Ale pro uživatele (admina) je pro mě - vcelku logicky - primární to, aby věci fungovaly a dalo se s nimi pracovat. Opravdu nestojím o sračku, která loguje binárně a potřebuju udělátor xyz na to, abych ty logy mohl přečíst. Stejně tak nestojím o hromadu dalších věcí, jmenovitě třeba o to, aby mi nějaký polobožský nástroj ukradl kontrolu nad cgroups, nad spouštěním (a zastavováním) služeb.

A rozhodně nestojím o nepromyšlené a přesložitělé hurá init systémy, protože čím složitější systém, tím snáz se v něm udělají hůř hledají podivné chyby, které jednou za čas někoho kopnou.

Pokud se vývojářům Debianu nelíbí init skripty a pláčou, když musí vytvořit další, fajn. Ale chtělo by to trochu soudnosti v tom, jestli je opravdu dobrý nápad nahrnout na uživatele něco, o co opravdu nestojí.

[kralyk z abclinuxu]

No, tak pokud by existoval projekt, který by měl výhody systemd nebo obecně 'moderního' init sytému, ale neměl by ty problémy, co má systemd (jako např. to, že je do něj zaintegrováno všechno možný - journald, logind, whateverd,...), tak tomu bych fandil. Aktuálně ale nic na obzoru nevidím...

[j]

Prave i proto je lepsi zustat u stareho, mozna "spatneho", ale provereneho, nez vymejslet novoty, ktery nefungujou. Uz vidim jak zivy ... "nenastartoval mi systemd ... co stim" ... "mno ... sezen si nekde druhej stroj, na nem si to prekompiluj ... a pak to nejak dostan na disk toho puvodniho stroje .... a pomodli se".

Uz vubec nemluve o tom, ze tux odjakziva fungoval na principu jednoucelovych malych nastroju, a ne se vseobjimajicim molochem.

[kralyk z abclinuxu]

Uz vidim jak zivy ... "nenastartoval mi systemd ... co stim" ... "mno ... sezen si nekde druhej stroj, na nem si to prekompiluj ... a pak to nejak dostan na disk toho puvodniho stroje .... a pomodli se".

A to se ti reálně stalo, nebo to jen tak fantazíruješ? Systemd se samozřejmě dá konfigurovat bez překompilovávání a služby jsou definované v textových (.service) souborech. U upstartu to je podobné.

Jinak tenhle argument je dost mimo, v systému je binárek neurekom od kernelu až po naprostou většinu userspace. Počítám, že ty bys radši úplně všechny programy přepsal do bashe, protože co kdyby náhodou v některým z nich byl bug, že?

Uz vubec nemluve o tom, ze tux odjakziva fungoval na principu jednoucelovych malych nastroju, a ne se vseobjimajicim molochem.

Jj, molochovitost systemd mi taky vadí.

[Václav "Darm" Novák]

Jestli se mi nějak poškodí binárka systemd, nabootuju z live CD a přeinstaluju balíček systemd. To mi připadá jako opravdu strašná práce. U starého initu bych nabootoval z live CD a opravoval skripty.

Zbytek konfigurace systemd, včetně služeb, je textový a krásně přehledný.

[Kaacz]

V tomto pripade se skripty neopravuji ale take jen jednoduse nakopiruji ty fungujici .. je to ekvivalentni te oprave systemd, mozna i jednodussi, protoze se jen kopiruje obsah jednoho adresare a nemusi se nic instalovat. Takze se ta zachrana da udelat z uplne cehokoli, co spravne primountuje dany disk. Ze stejneho duvodu se drzim stareho GRUB. Nepotrebuju k oprave spravne live cd jako u GRUB2. Takze toto vase zduvodneni pokulhava, ba dokonce vyjde systemd hure .. :)

[Václav "Darm" Novák]

Tak ona by se ta poškozená binárka taky dala opravit pouhým zkopírováním.

[pc2005]

Systemd binárka je staticky zkompilovaná se všema knihovnama? To musí být strašně velký :-O. V opačném případě hrozí zkopírování nekompatibilní verze. To skripty mají limitně stabilní syntaxi.

[marbu]

Proc myslis? Ono systemd je normalne zkompilovane dynamicky:

$ ldd /usr/lib/systemd/systemd
        linux-vdso.so.1 =>  (0x00007fff37b2c000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f5b6103d000)
        libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x00007f5b60e39000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007f5b60c26000)
        libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f5b60a1b000)
        libpam.so.0 => /lib64/libpam.so.0 (0x00007f5b6080d000)
        libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f5b605e6000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f5b603e1000)
        libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f5b601cb000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f5b5ff84000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f5b5fd7c000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5b5fb66000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5b5f949000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5b5f588000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003f87a00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5b5f384000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f5b5f11f000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f5b5ef06000)
        libattr.so.1 => /lib64/libattr.so.1 (0x00007f5b5ed01000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f5b5eadb000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f5b5e8c5000)

[pc2005]

Takže když omylem smažu/zničím libz, tak nenabootuju?

[pavlix]

A když omylem smažeš init, tak taky ne ;).

[pc2005]

Šance na znepřístupnění je vyšší při větším počtu závislostí na knihovnách.

[pavlix]

Jen teoreticky.

[pc2005]

Nechápu. Jako že v praxi není méně spolehlivější mít víc prvků z nichž stačí porucha jednoho na selhání celku, než jeden samotnej prvek? Samozřejmě jsou zdroje poruch, na kterých jsou závislé všechny členy (hmm upadnutí disku na betonovou podlahu), ale je zde mnoho zdrojů poruch, které mohou postihnout jen jeden člen (porucha balíku s libz).

Myslím, že moje tvrzení lze dokázat u modelu: program se závislostí na externím libz a ten samý program bez závislosti na externí libz. V případě zničení externí libz přestane první program pracovat. V případě druhého programu se nic nebude dít.

[pavlix]

Problém typu a co když si omylem smažu libxyz nepovažuju za hodný řešení. Howgh.

[pako]

Kde jsou ty časy, kdy měl člověk na systému staticky zkompilovaný shell v /sbin/sh. A to ještě ani nebyli vysoce "inteligentní" správci balíku, kteří ochotně řešili závislosti, aby jim to při tom sem tam ujelo.

[Jendа]

Kde jsou ty časy, kdy měl člověk na systému staticky zkompilovaný shell v /sbin/sh.

Nejlépe se SUID bitem .

Já ho mám furt a furt funguje (Debian, staticky linkovaný busybox).

[David Jaša]

s/aby jim to/proto to správcům/

... a taky právě proto tam ten statický /sbin/sh byl.

[pako]

Asi dost záleží na osobě správce. Osobně jsem vícekrát zažil/viděl malér na "chytrém" systému, který se úspěšně sám podkopal, než že by to podělal admin. Ale chápu, že admin je dnes kde kdo, kde co, a pak může být lepší to raději svěřit nějakému skriptu. ;)

[David Jaša]

Já bych linuxové balíčkovací systémy a jejich distribuční QA po ~15 letech historie nenazval "nějakým skriptem", kterému se něco "svěřuje".

[kralyk z abclinuxu]

Tak což o to, ten libz je ještě relativně ok, ten má stejně jako závislost polovina systému, ale proč tam je ještě liblzma? Ten tam např. u mě (Arch Linux) není.

[Václav "Darm" Novák]

Mimochodem, ve chvíli kdy se mi na disku rozbije binárka systemd mám pravděpodobně podstatně větší problém než opravu systemd. Protože to znamená průser hardware, nebo nakoplý filesystém a nějaká oprava initu je to poslední co mě štve :)

[trekker.dk]

Souhlas s předřečníkem. Když není nic nového a funkčního na obzoru, tak je snadné (a rozumné) počkat, až bude. Do té doby není žádný problém zůstat u aktuálního řešení, které funguje

[Ivan]

Souhlas. Muj oblibeny OS (AIX) uz takhle ceka 20 let. A prestoze se jeho bootovaci proces tak dlouho nezmennil, tak obsahuje vlastnosti ze kterych by se mohl poucit i Linux.

[kavol]

Jde vidět, že jste v životě nepsal žádný složitější init script.

tož já bych se s dovolením hloupě zeptal ... a proč by měl?

Jinak byste nemohl napsat takový nesmysl o shell init scriptech jako "jednoduchost, univerzalnost a osvedcenost".

nešlo by i toto trošinku podložit nějakými argumenty? - když se já na to podívám, tak ...

jednoduchost - to je asi subjektivní, nicméně tedy použít skriptovací jazyk, který znám a používám i jinde, se mi jeví jako jednoduché; naopak pracovat s obludou, kde typický odkaz na dokumentaci je někam do blogu, je tak trochu naprd

univerzálnost - otázkou jest, co přesně se tím myslí, nicméně tedy obecně shell je dostupný na celé škále systémů, zatímco systemd jen na linuxu (a to ještě jen určitým, v některých scénářích nežádoucím, způsobem zkonfigurovaném)

osvědčenost - no, třicet let používání na různých systémech v různých podmínkách je málo? je snad systemd osvědčenější? co si mám myslet o člověku, co tvrdí, že "osvědčenost" je u sysv initu nesmysl?

[pavlix]

Jde vidět, že jste v životě nepsal žádný složitější init script.

Co je to složitější init script a jak vypadá jeho ekvivalent pro systemd?

[Foo Bar]

On nemusí být ani nutně složitější:

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.init

vs

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.service

nebo

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.upstart

A co si budeme povídat, ten shell init skript nemá supervizor, takže aby byl ekvivalentní tomu pro systemd/upstart tak by tam musely být přibalené ještě nějaké daemontools.

Ale jako příklad něčeho složitějšího je třeba oficiální init skript pro gitlab. Místo jednoho skriptu, který nahazuje dvě služby, mám těd dva service skripty, které udržují gitlab v chodu (nějakou dobu ten jejich sidekiq s nějakou verzí ruby masivně padal).

Prostě /etc/inittab nestačí a po chvíli každý soudný člověk zjisti, že služby, které nejsou supervizované, jsou akorát generátor poplašných hovorů ve tři v noci.

P.S.: Pokud si všimnete, tak v balíku php5-fpm mám init skripty pro tři různé init systémy. A moc mě to teda nebaví...

[kavol]

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.init

hm, podívám-li se na konstrukce typu:

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

měl bych spíše pochybnosti o kvalitách autora skriptu nežli o sysv initu ...

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.service

nebo

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-fpm.upstart

nějak nevidím, jak tyto dva implementují reopen-logs? (což mimochodem chybí v Usage, k čemuž bych řekl totéž co výše, autor je prostě prase)

[little.owl]

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

měl bych spíše pochybnosti o kvalitách autora skriptu nežli o sysv initu ...

Tohle je celkem bezna konstrukce, kterou najdete u debianich init skriptu daemonu.

[kavol]

že je něco běžné ještě neznamená, že je to v pořádku

za prvé, komentář vůbec neodpovídá akci

za druhé, tiše umřít bez vypsání chyby a nastavení příslušného chybového kódu je velmi velmi špatná praktika

- jak se s tím má popasovat ostatní software? - zavolám ve svém skriptu něco jako "service php5-fpm start", exit kód je nula, žádná chyba, takže vesele pokračuju, a pak se mi můj skript totálně vysype, protože služba neběží?

[little.owl]

O tom, ze je to spatne, netreba debatovat, jen bych se za to do autora nenavazel. On postupuje konzervativne v duchu Debianu, kde jsem tenhle pristup videl uz pred 13 lety a evidentne to nikoho nepalilo. Debianni SysV init skripty jsou ukazkou proc shell skripty radsi uz ne a ani Fedori pred Upstartem nebyly zadna slava.

[kavol]

O tom, ze je to spatne, netreba debatovat, jen bych se za to do autora nenavazel. On postupuje konzervativne v duchu Debianu, kde jsem tenhle pristup videl uz pred 13 lety a evidentne to nikoho nepalilo.

ok, pak to ale má dávat za příklad hnilobných debianích praktik, a ne za problém sysv samotného :-p

Debianni SysV init skripty jsou ukazkou proc shell skripty radsi uz ne

viz výše, prasit se dá v čemkoliv, to není argument proti něčemu

a ani Fedori pred Upstartem nebyly zadna slava.

... a proto jsme dělali aktivity jako "initscripts improvement project"

[trekker.dk]

ok, pak to ale má dávat za příklad hnilobných debianích praktik, a ne za problém sysv samotného :-p

Nejspíš (nejsem správce balíků) to vychází z faktu, že init skript je v /etc, tudíž je to konfigurační soubor. Tzn. při odinstalování balíku se zachováním konfiguračních souborů zůstane zachován i init skript a tahle konstrukce zajistí, že odpadnou chyby při startu.

Ostatně bych to volání nepovažoval za tak velký problém. Jestli neexistuje démon volaný daným init skriptem, tak ho někdo odinstaloval a je jeho blbost očekávat, že se ta služba nastartuje.

[kavol]

Ostatně bych to volání nepovažoval za tak velký problém. Jestli neexistuje démon volaný daným init skriptem, tak ho někdo odinstaloval a je jeho blbost očekávat, že se ta služba nastartuje.

takže můj skript má mít křišťálovou kouli, která mu řekne, že někdo něco odinstaloval a že se ani nějakou službu nemá pokoušet startovat, namísto toho aby ji prostě zkusil a sledoval, jestli vrátí chybu a má se podle toho zachovat (skončit) nebo nulu a tedy může v klidu pokračovat?

nesouhlasil jsi o kousek níže s tím, že by se ti líbil initsystém jednotný přes různá distra, a najednou do toho budeš tahat rozhodování podle toho, jaký balíčkovací systém distro vůbec používá, aby si něco na init systém navázaného zjistilo, jestli má smysl pokoušet se startovat nějakou službu? eh?

[trekker.dk]

takže můj skript má mít křišťálovou kouli

Nevím, co je to za skript, který by měl startovat init.d službu (ty se tak nějak startují samy při bootu, ne?) A pokud už něco takového dělá, tak ho máš upravit nebo smazat s tím, když jsi smazal toho démona.

nesouhlasil jsi o kousek níže s tím, že by se ti líbil initsystém jednotný přes různá distra

Ne. Respektive jestli to někde bylo, tak ve výčtu dalších vlastností a zrovna tahle mě nezajímá. Různá distra nepoužívám - dokud mi bude Debian fungovat ke spokojenosti, jinde si dělejte (a používejte) takový bordel, jaký se vám zlíbí

Zbytek odstavce viz výše. Pokud voláš init skript odinstalované služby, je to administrátorská chyba.

[little.owl]

Pokud tam je chyba, ma skript vratit chybovy kod, to neomluvite. Debian ma jakousi souvisejici policy, a chybove kody by mely byt LSB compatible.

[Pev]

Pokud tam je chyba, ma skript vratit chybovy kod, to neomluvite. Debian ma jakousi souvisejici policy, a chybove kody by mely byt LSB compatible.

1) Opravdu je to LSB incompatible?

2) Myslím, že bez detailní znalosti debian policy je nesmysl hodnotit kvalitu init scriptů (věci mají svůj důvod).

[little.owl]

ad 1) Ano, viz zde.

ad 2) Nevim, ale o LSB compatible skryptech uvazovali uz pred lety, kouknete se sem.

[trekker.dk]

Debianni SysV init skripty jsou ukazkou proc shell skripty radsi uz ne

Jasně, radši použít systemblackbox. Tam na prasárny není vidět hned, takže je všechno v pořádku.

[little.owl]

Dokumentovany system s deterministickym chovanim a interfacem neni problem (od bugu odhlednem).

[trekker.dk]

S tím souhlasím. Jenže tohle tvrzení nemá se systemd moc společného.

[kralyk z abclinuxu]

měl bych spíše pochybnosti o kvalitách autora skriptu nežli o sysv initu ...

Jasně, že chyba není v SysV initu, vzhledem k tomu, že sysv init program jako takový je brain dead simple software, který dělá jen naprosté minimum (spustí nějaký skript podle aktuálního runlevelu). Chyba je v tom, že správce je primitivností sysv initu nucem psát skoro celý init systém v bashi...

[j]

Mno autor ten script napise jednou, ze ... ale uzivatel/admin si pak predesim ten script muze snadno precist, zjistit co dela/nedela a pripadne si do nej neco dopsat nebo ho upravit podle svych potreb ... uz vidim jak nekdo upravuje systemd, kdyz nebude delat to co ma nebo to co dotycny potrebuje ... nemluve o tom, ze bash +- aspon na zakladni urovni zvlada vetsina adminu, a je defakto uplne vsude.

[kralyk z abclinuxu]

Mno autor ten script napise jednou, ze ...

Ne. Skripty je potřeba udržovat - mění se potřeby distribuce, mění se ty samotné služby,...

ale uzivatel/admin si pak predesim ten script muze snadno precist, zjistit co dela/nedela

Jo, měl jsem za dob sysv init párkrát "tu čest" dohledávat něco v init skriptech, bylo to dost děsný. Ve výsledku jsem tam stejně většinou někde doplnil nějakej hack, kterej byl stejně přepsán při příštím upgradu.

a pripadne si do nej neco dopsat nebo ho upravit podle svych potreb

Aha, takže už i uživatel si bude psát init systém na koleně... Super

[j]

Jasne, on uzivatel radsi bude resit nefunkcni binarni blob ... a 10let cekat, jestli se nahodou nekdo nesmiluje a neopravi bug ktere tam je.

[kralyk z abclinuxu]

O jakém bugu je řeč?

[Jakub Lucký]

Třeba ten s nemožností vypnout automaticky aktivované služby, který ó-velký považuje za feature?

[kralyk z abclinuxu]

Njn, to je špatný, otázka ovšem je, jak moc by pomohlo, kdyby podobně "osvícený" vývojář něco takového udělal v klasickém init skriptu. Muset si udržovat patch init skriptů nebo patch systemd service fajlů mi přijde jako prašť a uhoď...

[Jakub Lucký]

Právě že já si tuhle věc v init skriptu opravím a zakážu jeho upgrade... U systemd je ale problém někde v binárce (že se to chová takhle není problém service files, ale obecné chování u socket-activation) a pokud se jeho veličenstvo Lennart rozhodne, že je to feature, neudělám (skoro) nic...

[kralyk z abclinuxu]

No jo, ale pak ne-upgradování toho skriptu může způsobit nějaký jiný problém... Mam taky takhle pár věcí v upgrade ignore listu, v podstatě to ale je jen workaround. U toho systemd se tohle afaik dá taky workaroundovat opravou v service files...

[Jakub Lucký]

ale pak ne-upgradování toho skriptu může způsobit nějaký jiný problém

Pokud bude správce nějakého SW dělat svýma initskriptama paseku, tak si při každému upgradu sjedu diff (Debian nabízí) a projdu changelog (Debian umí), tak s investicí 15 minut/rok budu žít s workaroundem...

U toho systemd se tohle afaik dá taky workaroundovat opravou v service files...

Zrovna v tomhle konkrétním případě ano... A co až lennartware(tm) zas vymyslí další takovou kulišárnu, která už obejít nepůjde? A tohle nevnímám jako hypotetickou možnost, ale velmi reálnou (protože dalších podobných bugo-featur už tady bylo několik a vždy velmi obhajovaných)

[Foo Bar]

Nekandidoval jste na Stranu přátel organizovaného zločinu? Pokud ne, tak byste to měl zvážit, s Vaším stylem byste parádně zapadl možná i do současné vlády.

Již poslední diskuzi jste mne přesvědčil, že se sem chodíte pouze hádat, a když Vám druhá strana poskytne technické a věcné argumenty, po kterých jste tak nahlas řval, tak na to již nereaguje, protože Vám to nezapadá do scénáře, kde můžete dělat ramena na druhé svou hrubostí a agresivitou. S buranem a trollem nelze vézt žádnou diskuzi, natož kultivovanou.

[kavol]

jistě, stejně jako v minulé diskusi ad hominem namísto nějak rozumně obhájit, proč nemám nárok říkat, že coby autor výše uvedeného kódu jseš prase ... úplně to samé, soustředíme se na to děsné hulvátství, že jsem řekl "prase" a ne "o stylu toho kódu by se dalo s úspěchem pochybovat", a zcela se vykašleme na pointu, ou jé, to ti tak strašně jde, dělat tady klaďase, protože oponent nemá náladu na ty tvoje diplomatický tanečky, však to známe, je to pravda odvěká, šaty dělaj člověka ...

no jsem zvědav na ten "technický a věcný" argument, proč je v pořádku v případě selhání nevrátit chybový kód ale nulu?

[mirec]

Ja som sa minule pokúšal nejako rozbehať gitlab, sidekiq a redmine na debiane. Init skripty vážne nie kvôli chýbajúcemu dohľadu nad padaním. Preto som zvolil sv ... ale nebola to najšťastnejšia voľba, asi v 50% prípadov štartu (takmer denne nám vypadáva prúd) sa jedna zo služieb redmine / sidekiq / gitlab zasekne na nekopnečnej slučke kde sv donekonečna zabíja a spúšťa passenger. Absolútne netuším prečo to robí. Ah zlatý upstart / systemd kde to jedneoducho funguje.

[chrono]

Ja som radšej, keď sa mi služba kvôli chybe nespustí, ako keby sa tvárila ako spustená a na problém by som prišiel až pri prvom použití.

[pavlix]

Já tedy vidím jako planý poplach především to o těch složitějších initskriptech.

[Foo Bar]

Taková malá lokální statistika init souborů v debianu... (a to jsou jenom balíčky, se kterými jsem nekdy přišel do styku).

[...] 130 opendnssec-enforcer.init 132 bind9.init 134 sks.init 136 bird.bird6.init 139 unbound.init 142 murmur.init 145 bind9.init 146 python-poker-network.init 149 calendarserver.init 152 httpd.init 154 dspam.init 155 httpd.init 158 nsd.init.d 161 dnssec-tools.rollerd.init 168 citadel.init 169 stompserver.init 176 php5-fpm.init 178 php5-fpm.init 185 c-icap.init.d 187 mysql-server-5.5.mysql.init 193 dovecot-core.init 195 slapd.init 209 mysql.init 225 pdns-server.pdns.init 235 apache2.2-common.apache2.init 241 cfengine3.init 249 phreld.init 251 udev.init 274 exim4-base.exim4.init 276 apache2.2-common.apache2.init 282 mydns.init 284 pdns-recursor.init 289 cyrus-common.cyrus-imapd.init 298 autotrust.init.d 301 dsc-statistics-collector.init.d 318 gridftpd.init 323 sasl2-bin.saslauthd.init 402 sasl2-bin.saslauthd.init 403 sasl2-bin.saslauthd.init 415 apache2.init 1340 sendmail.init.d

Jasně, že tohle všechno nepůjde jednoduše přepsat do deklarativního zápisu (ten sendmail je fakt extrém), ale troufám si tvrdit, že většina z těch s průměrnou velikostí okolo 150 se dá přepsat do pár řádek.

[pavlix]

Já v tom nevidím nic víc než neschopnost či nechotu maintainerů Debianu vytvořit si nějaký rozumný systém initscriptů. A tím nemám namysli nahrazení procesu s číslem jedna, ale jednotný postup, jak psát rozumné initskripty.

Stačí se podívat, jak vypadají skripty v Gentoo. Neříkám, že je to ideální a některé z těch initscriptů využívají vlastností OpenRC, takže je potřeba je ze srovnání vynechat, ale ukazuje to staré známé:

Kdo chce hledá způsoby, kdo nechce, hledá důvody.

Samozřejmě to lze řešit pomocí systemd, upstart či openrc, ale nalijme si čistého vína, že k psaní rozumných initscriptů není nic z toho nutnou podmínkou, tudíž bych toto konkrétně neviděl jako relevantní důvod k přechodu.

[kralyk z abclinuxu]

Já v tom nevidím nic víc než neschopnost či nechotu maintainerů Debianu vytvořit si nějaký rozumný systém initscriptů.

A tobě nepřijde rozumnější, aby existoval nějaký obecně použitelný init systém, který by distribuce mohly nasadit a nakonfigurovat, ie. nemusely to psát celé znova a každý zvlášť? Už tak mají dost jiných starostí.

Pozn.: Tím nemyslím konkrétně systemd, ale obecně...

[trekker.dk]

A tobě nepřijde rozumnější, aby existoval nějaký obecně použitelný init systém, který by distribuce mohly nasadit a nakonfigurovat, ie. nemusely to psát celé znova a každý zvlášť?

Já jsem pro. Jenže s otázkou "vyměníme init skripty za upstart nebo systemd" už tohle má docela málo společného.

[kavol]

přijde

[kralyk z abclinuxu]

Zajímavý je, že u každé jiné části systému krom initu s tím nemá nikdo problém (a s tím, že nejsou v bashi, taky ne...)

[Jakub Lucký]

mám s tím stejný problém u pulseaudia (používáno a po dlouhém znechucení zrušeno) a journald...

[kralyk z abclinuxu]

Tak zrovna pulseaudio jsem taky znechuceně odinstaloval

[Jakub Lucký]

takže očividně to lidem (alespoň dvěma) jedno není... a nepochybuju o tom, že pokud začneme třeba do journald šťourat, tak těch protestujících málo zrovna nebude...

[Honza Jaroš]

Já bych řekl, že s tím není problém ani u initu, pokud zrovna nejde o systemd.

[Foo Bar]

Osobně postupuju vždycky tak, že udělám:

cp /etc/init.d/skeleton debian/<package>.init.d

Případně vezmu to, co mi do balíku vygeneruje dh_make.

A to si upravím ke svým potřebám. Hádám, že velká část maintainerů postupuje stejně.

Nicméně problém je i v tom, že ten skeleton vypadal před 10 lety úplně jinak než vypadá dneska, a můj pocit je, že je to v podstatě neupgradovatelné, protože jsou to z velké části špagety.

Samozřejmě, že všechno jde ohackovat tak, aby to vypadalo pěkně, ale nedostali bychom se pak stejně k něčemu jako je OpenRC (tady se omlouvám, ale moje znalost OpenRC končí na tom, že je to sada shell skriptů, která umí zpracovávat deklarativní syntax init skriptů)?

Moje důvody, proč si myslím, že je potřeba přejít na moderní init systém: - deklarativní zápis (mnohem snazší na údržbu) - supervizor (!!!)

Taky nesmíte zapomínat, že Debian je spíš taková snůška individuí, z nichž každý má jinou motivaci, jinou agendu a jinou firmu na výplatní pásce.

[pavlix]

Já neříkám, že je OpenRC jediná správná varianta™, ale troufám si tvrdit, že kdo neviděl jediný OpenRC initskript neměl by hodnotit nejen OpenRC, ale tuhle oblast obecně, a hlavně, neměl by na zelené louce psát nová řešení.

deklarativní zápis (mnohem snazší na údržbu)

Zajímavostí je, že OpenRC initscripty jsou imperativní a přesto jsou stokrát udržovatelnější než initscripty v Debianu. To ukazuje, že k dílčímu úspěchu kolikrát stačí trocha snahy namísto věčné argumentace, že by se muselo všechno předělat od základu, tak to radši necháme, jak to je.

Nehledě na to, že to není rozhodování mezi deklarativním a imperativním přístupem, protože pro správnou funkci je do jisté míry potřeba obojí. Sám jsem obecně spíše pro deklarativní zápis, ale nepovažuju to za nejvyšší kritérium.

supervizor (!!!)

Naprosto souhlasím. A detekci/odstranění zapomenutých procesů (například pomocí cgroups, jako to dělá systemd). Nikdy jsem se netajil tím, že se mi ten koncept líbí.

Co si budem povídat, udělat supervizor třeba i s integrací cgroups není zas až takový problém, a nejspíš ke svému běhu vůbec nepotřebuje pid 1. Pokud jde o deklarativní zápis, tak není až takový problém se k němu dopracovat postupně. Navrhnout ho dobře na zelené louce je o dost horší. Samotné zpracování konfiguračních souborů zase až taková divočina není.

Taky nesmíte zapomínat, že Debian je spíš taková snůška individuí, z nichž každý má jinou motivaci, jinou agendu a jinou firmu na výplatní pásce.

To vypadá jako by Gentoo byla nějaká hyper cool bohatá komerční firma, když už tady byla řeč o OpenRC a inteligentních bashovských initscriptech. Nehledě na to, že už je to jednou prošlapaná cesta a není problém si vypůjčit nápady třeba tam.

[Foo Bar]

Ad OpenRC - je mi upřimně jedno, co to bude, když už to nebude sysvinit. OpenRC v Debianu nemá žádného navrhovatele (narozdíl od systemd a upstartu).

Ad supervizor - tak jistou forma supervizoru má i sysvinit, jen to nikdo nepoužívá, že? :). Supervizorů je docela dost (počínaje djb), jde o to se sjednotit na jednom a ten používat pro všechny služby. A to se pokud vím do příchodu upstart (a systemd) v žádném distru nestalo.

Takže se v podstatě v důvodech pro přechod na moderní init shodeme, ne?

Ad Debian vs. Gentoo - mám pocit, že Debian má pořád největší množství správců balíčků ze všech dister, ne? Tj. neříkám, že Gentoo je hyper cool komerční firma, ale že okometricky cca 300 lidí (http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml) se koordinuje lépe než cca 1000 (debian-keyring.gpg + debian-maintainer.gpg).

[little.owl]

To neni o poctu lidi, ale o binci v Debianu.

[pavlix]

Takže se v podstatě v důvodech pro přechod na moderní init shodeme, ne?

Když do toho nebudeme tahat nesmyslné argumenty jako dosavadní neschopnost Debianu přejít na nějaké rozumné initscripty, tak nám skutečně zbydou mlhavé výhody deklarativního jazyka na jedné straně a supervizor na druhé straně. To první samo o sobě lze realizovat postupně a bez nějakých velkých problémů. To druhé lze realizovat postupně a případně i bez výměny pid 1.

jde o to se sjednotit na jednom a ten používat pro všechny služby.

Ve finále je nanejvýš vhodné se shodnout na jednou a používat ho nejen pro všechny služby, ale ideálně i pro všechny běžné distribuce, popřípadě mít k dispozici více alternativ se společným API. To je ale možnost, kterou systemd efektivně zabíjí a ani upstart v tomto moc nepomohl.

ale že okometricky cca 300 lidí (http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml) se koordinuje lépe než cca 1000 (debian-keyring.gpg + debian-maintainer.gpg).

Nevidím rozdíl v přípravě guidelines pro psaní initscriptů a zajištění softwarové podpory (třeba ve formě bashovských funkcí) pro 300 vývojářů a pro 1000 vývojářů. Jestli v rámci Debianu takovýto argument obstojí proti možnosti s tím něco udělat, pak se není čemu divit.

[little.owl]

Neblazni, to je Debian.

Ti maximalne doplni jejich guidelines o dalsich par paragrafu a ty budes potrebovat konzultaci s pravnikem pro napsani init skriptu, pokud je budes chtit nasledovat.

Ondrej Sury ma pravdu, pro Debian je cesta do budoucna volba mezi systemd a upstart.

A ja jen dodavam, ze pokud si vyberou upstart, potvrdi mi jen, ze jsou vytunelovana filialka Canonical.

[pavlix]

Ondrej Sury ma pravdu, pro Debian je cesta do budoucna volba mezi systemd a upstart.

To nepopírám, nicméně to stále hodnotím jako výběr mezi dvěma zly.

[Foo Bar]

Díky, pobavil jste mne. (A teda máte v prvních dvou odstavcích bohužel pravdu.)

[Rezza]

Ony byly jednoduche a univerzalni - kazdy vracel svuj univerzalni exit code :).

[Jendа]

Vymenit jednoduchost, univerzalnost a osvedcenost za teoreticky rychlejsi boot a podporu zcela okrajovych cgroups, mi neprijde jako dvakrat moudre.

Tak on debianí init systém je bohužel rozbitý (např. nejde disablovat služba, aby to přežilo upgrade), ale spíš než upgrade na něco jiného bych se věnoval jeho opravě…

[trekker.dk]

update-rc.d služba disable X?

Nebo - když vadí, že předchozím způsobem se služba v daném runlevelu vypíná místo spouštění - dokonce snad funguje i přejmenování skriptu z Sxx na Xxx

[Jendа]

update-rc.d služba disable X?

Upgrade balíčku spustí /etc/init.d/služba restart.

Nebo - když vadí, že předchozím způsobem se služba v daném runlevelu vypíná místo spouštění - dokonce snad funguje i přejmenování skriptu z Sxx na Xxx

Upgrade balíčku tyto soubory přepíše distribučná verzí.

[trekker.dk]

Upgrade balíčku spustí /etc/init.d/služba restart.

Některé init skripty při volání restart neudělají nic, pokud služba neběží.

Upgrade balíčku tyto soubory přepíše distribučná verzí.

Jsi si jistý, že to pořád platí? Včera jsem to zkoušel a update-rc.d při --reinstall akorát řekl, že se výchozí nastavení spouštění liší od současného. Symlinky nechal napokoji

[Jendа]

Některé init skripty při volání restart neudělají nic, pokud služba neběží.

Jak které… Upgrade lighttpd mi teď prošel, ale třeba zbavit se samby se mi nepovedlo.

Jsi si jistý, že to pořád platí? Včera jsem to zkoušel a update-rc.d při --reinstall akorát řekl, že se výchozí nastavení spouštění liší od současného. Symlinky nechal napokoji

No jo, vypadá to, že už to jde. Super.

(btw. ještě jeden problém - jak nainstalovat server, aniž by se spustil s defaultní konfigurací? třeba postfix nebo ziproxy jsou defaultně otevřené do světa a to určitě nechci)

[trekker.dk]

třeba postfix nebo ziproxy jsou defaultně otevřené do světa a to určitě nechci

Postfix ve které konfiguraci? Co si tak vzpomínám, tak se mi vždycky spustil s nasloucháním jenom na localhost. A i kdyby ne, tak výchozí konfigurace stejně nepřijímá žádnou poštu kromě @mailname a @[ip.ad.re.sa]

[Jendа]

Poslouchá podle toho, co se mu nastaví při instalaci (defaultně všude), ale OK, nemá relay.

[kouzer]

OpenRC už je ze hry? Osobně bych ho bral místo obou zmíněných "zel"... :(

[Robert Smol]

Co je spatneho na systemd? Vzdyt je to dobre promysleny daemon, ktery konecne prinasi cross-distro stejne unit files.

[pavlix]

Až bude umět univerzálně zastavovat služby, tak se můžeme bavit o nějaké promyšlenosti.

[Robert Smol]

Muzete to prosim rozepsat? Sam pouzivam systemd jak na samotne sluzby tak, na groupy sluzeb a nemam pocit ze by to neumelo sluzbu zastavit. Diky cgroups dokonce dohleda i forknute jedince a zastavi i ty.

[pavlix]

Muzete to prosim rozepsat?

Vždyť už je to folklór. Oni předefinovali akci „stop“ ze „zastav do nejbližší akce administátora“ na „zastav do nejbližší ho pokusu službu použít“, to platí jak pro služby aktivované přes UNIX socket (tam to jde obejít „zastavením“ toho socketu), tak pro služby aktivované přes D-Bus (tam se to obchází už podstatně hůř).

Nedávno mi bylo definitivně vysvětleno, že se na straně systemd jedná o vlastnost, nikoli chybu a jediný problém je, že D-Bus ještě není v kernelu.

Diky cgroups dokonce dohleda i forknute jedince a zastavi i ty.

Nikoliv.

On rovnou sestřelí celou tu cgroup a nic nedohledává, navíc to dělá by default. Tím dostává služby do nedefinovaných stavů a vcelku nedávno se řešilo, že kvůli tomu zamrzávala fedoří instalace při bootu z NFS (systemd sestřelil dhclienta, na jehož selhání reagoval NetworkManager úklidem a NFS tak ztratilo síť).

Fakta jsou taková, že promyšlené rozhodně není a že autoři systemd by default počítají s tím, že ten, kdo se bude přizpůsobovat a řešit vzniklé problémy, je okolní svět. Můžeme se bavit maximálně o tom, do jaké míry je to v pořádku.

[dustin]

Oni předefinovali akci „stop“ ze „zastav do nejbližší akce administátora“ na „zastav do nejbližší ho pokusu službu použít“

K čemu je taková změna užitečná?

[Robert Smol]

Diky, to je zajimave info. Ja pouzivam normalni daemony, kde systemctl stop mi opravdu sluzbu zastavi. Chapu ze dbus aktivovanych sluzeb asi pribyva, zajimalo by mne jak se tohle vlastne treba v openRC ci upstartu resi.

[little.owl]

jediný problém je, že D-Bus ještě není v kernelu.

Bude, see here, a uz to celkem chodi.

Můžeme se bavit maximálně o tom, do jaké míry je to v pořádku.

Do urcite miry to v poradku je, nicmene okolni svet by mel mit vice moznosti do toho kecat a nebyt postaven pred hotovou vec.

[pavlix]

Co není jasné na slovu ještě?

[j]

A jako bonus vyrabej jeden obrovskej binarni blob, do kteryho se snazej integroavat uplne vsechno, vcetne udevu, aby vsechny donutili si tuhle sracku nainstalovat.

[kavol]

hm, až to bude cross-platform, tak povídej něco o promyšlenosti :-p

[Robert Smol]

Opet nerozumim. Jak developeri postgresql udelaji cross distro startup skripty? Kazda distribuce musi dany SW zaradit do vlastniho repozitare a dodat tam svoje vlastni startup skripty. Drive jsem na gentoo dost casto narazel na situaci, ze dany SW nebyl v repozitari a ja si musel nejake skripty dopisovat sam.

Se systemd napises jeden unit file a bezi to na vsech distribucich kde je systemd.

[kavol]

za prvé, seš si jist, že to má být reakce na můj příspěvek?

za druhé, ať tak či tak, nerozumím, proč do toho taháš postgresql?

za třetí, to je argument pro argument - když vývojáři "daného SW" napíšou skript pro OpenRC, tak to bude běžet na všech distribucích, kde je OpenRC ... kde je rozdíl?

[luky]

Opet nerozumim.

Zrejme jste si jeste nevsiml, ze Linux neni jediny kernel podporovany Debianem.

[Petr Ježek]

asi tak :)h

[orm]

Dobrý den, vaše myšlení je omezeno jen na Linuxový svět. Debian, ale tento svět přesahuje. Kromě Linuxového jádra, obsahuje i jádra FreeBSD a Hurd. Mít různé init systémy pro každé jádro by pro Debian bylo zbytečnou komplikací.

[little.owl]

Resi Upstart versus systemd a Upstart take neni cross-platform. To by znamenalo se vzdat platform specific veci, coz nemusi byt dobra vec, zejmena ted u Linuxu.

[pavlix]

s/vzdát se/nezáviset na/

[kavol]

nerozumím, čeho by se měli vzdávat? - resp. pokud platí pavlixova substituce, tak pak zase nevím, proč by to nebyla dobrá věc

[little.owl]

Systemd je designovan jako Linux only s tim, ze na jine systemy nebudou brat ohledy, coz mi prijde jako legitimni vec. Vyhody i nevyhody jsou snad zrejme.

[pavlix]

Vyhody i nevyhody jsou snad zrejme.

Rád bych potkal člověka, kterému jsou výhody tvrdé závislosti na Linuxu upřímně zřejmé. A tím nemyslím Lennarta, kterému činí potěšení házet špínu na cokoli, co je alternativou k jeho oblíbencům včetně Linuxu.

Sám jsem narazil na oblast, kde Linux/GNU poskytuje lepší prostředky než obecně uznávané standardy, s FreeBSD a podobnými si ovšem netroufám srovnávat. Možná je to pro mě dostatečný důvod ty další systémy do jisté míry ignorovat, ale nevidím problém v tom, když někdo přijde s úpravami, které zajistí běh i nad jinými jádry.

Linux je jen nástroj. A jestliže už někdo plká o budoucnosti, měl by počítat i s tím, že v budoucnosti může přijít zajímavá alternativa k Linuxu (kernelu) nebo může Linux a jeho vývoj projít podstatnými změnami. Ale chápu, že je rozdíl mezi tvorbou software ve smyslu umění a tvorbou software ve smyslu kariéry.

[Sešívaný]

No, já myslím, že zřejmou výhodou je vertikální integrace. To, že můžu naplno využívat vlastnosti linuxového kernelu a opírat se o ně už v samotném návrhu. A naopak. Samozřejmě vertikální integrace má i svoje negativa, především nižší univerzálnost a flexibilita.

Nikdo nebrání nikomu udělat podporu systemd pro jiná jádra. Autoři systemd od začátku hlásají, že projekt je zaměřený pouze na Linux, a mají svaté právo ty patche nepřijímat, protože platí pravidlo, že co upstream jednou přijme, o to se musí starat, a do podpory BSD je nikdo nutit nemůže.

[pavlix]

No, já myslím, že zřejmou výhodou je vertikální integrace. To, že můžu naplno využívat vlastnosti linuxového kernelu a opírat se o ně už v samotném návrhu. A naopak.

To je skutečně zřejmá teoretická výhoda. Ale musíš mít dostatek znalostí, abys věděl, zda se ta výhoda skutečně projeví. Pokud je tvým argumentem, že se ti nechce řešit jiná jádra, je to zcela legitimní. Jenže pokud je tvým argumentem, že by to na jiných jádrech ani nešlo, je to nesmysl, protože zítra může přijít někdo, kdo potřebnou funkcionalitu do *BSD doprogramuje. Abyses mohl do takové debaty legitimně poušetět, musel bys znát přesný výčet funkcionality, která ti na jiných platformách chybí.

Nikdo nebrání nikomu udělat podporu systemd pro jiná jádra. Autoři systemd od začátku hlásají, že projekt je zaměřený pouze na Linux, a mají svaté právo ty patche nepřijímat, protože platí pravidlo, že co upstream jednou přijme, o to se musí starat, a do podpory BSD je nikdo nutit nemůže.

Na tomhle je právě vidět rozdíl mezi open source licencí a komunitním vývojem. V případě open source licence máš možnost forkovat či udržovat sady změn, zatímco v případě komunitního vývoje máš možnost stát se součástí upstreamu, který si pak nastavuje mechanismy údržby funkcionality, která je specifická pro menšinu uživatelů.

Funkcionalita je pak součástí upstreamu po tu dobu, co jsou součástí upstreamu její maintaineři. Nebo myslíš, že se na to dívám špatně?

[little.owl]

Pokud je tvým argumentem, že se ti nechce řešit jiná jádra, je to zcela legitimní.

Jenze o to presne jde.

[pavlix]

Potom máš zřejmě lepší informace než Lennart :).

[little.owl]

Pak jsem treba nepochopil, co chces rici .

[pavlix]

Pokud si dobře pamatuju, tak Lennart neříkal, že si to BSDčkáři budou muset doprogramovat sami, ale že systemd na BSD nikdy nepoběží, protože BSD je sračka.

[Sešívaný]

To je skutečně zřejmá teoretická výhoda.

To je IMHO dost praktická výhoda. I kdyby výhody vertikální integrace nebyly někomu zřejmé, už to, že podpora dalších kernelů vždycky znamená více práce, kterou autoři můžou místo toho věnovat zlepšování podpory Linuxu, je argument. Všimni si, že nijak neobhajuju specializaci pouze na Linux. Jenom říkám, že to svoje výhody prostě má.

Jinak co se týče budoucnosti, tak tu nikdo zatím číst neumí, takže člověk může tak maximálně odhadovat budoucí vývoj a je realitou, že Linux je a v následujících letech s největší pravděpodobností i bude zdaleka nejrozšířenějším systém unixového typu. Množství jeho vývojářů je řádově někde jinde a trend je rostoucí. Pokud Linux někdy v budoucnu skončí, tak s ním s největší pravděpodobností skončí i systemd a myslím, že to je riziko, které jsou jeho autoři ochotní podstoupit.

[little.owl]

No, já myslím, že zřejmou výhodou je vertikální integrace.

Ano. A navic casto nic jineho stejne neni vubec podporovano, pak obcas QNX a zridka Windows.

[little.owl]

Rád bych potkal člověka, kterému jsou výhody tvrdé závislosti na Linuxu upřímně zřejmé.

To jsem nerekl. Jde o to, ze pokud navrhujes system, tak aby behal na vice OS, pouzivas nejvetsi spolecny jmenovatel a to nekdy muze omezovat. Pokud designujes veci pro jeden system, na ostatni nemusis brat vubec ohled a to je co Lennart dela.

A jestliže už někdo plká o budoucnosti, měl by počítat i s tím, že v budoucnosti může přijít zajímavá alternativa k Linuxu (kernelu)

Jak bude vypadat budoucnost nevis a tak se na to nemuzes pripravit. A az se neco takoveho objevy, bude se to resit.

[pavlix]

To jsem nerekl. Jde o to, ze pokud navrhujes system, tak aby behal na vice OS, pouzivas nejvetsi spolecny jmenovatel

To vůbec nemusí být pravda.

Jak bude vypadat budoucnost nevis a tak se na to nemuzes pripravit. A az se neco takoveho objevy, bude se to resit.

Proto ta věta začínala:

Když někdo plká o budoucnosti...

[Petr Ježek]

V Redmondu se také nebral ohled k jiným kernelů. Výsledek chce k pochopení zažít nejen uživatelsky a programátorsky.

[kavol]

Jde o to, ze pokud navrhujes system, tak aby behal na vice OS, pouzivas nejvetsi spolecny jmenovatel a to nekdy muze omezovat.

mno, to "někdy" a "může" je takové ... no spíše nelichotivé pro autora návrhu

[AsciiWolf]

+∞

[Foo Bar]

Thomas Goirand (vlastně jediný proponent OpenRC v d-d@l.d.o) ustoupil na základě toho, že nemá čas se OpenRC věnovat (a jeho integraci do Debianu) a nikoho jiného OpenRC vlastně vůbec nezajímá.

[kavol]

a nikoho jiného OpenRC vlastně vůbec nezajímá.

... až na lidi kolem kFreeBSD a Hurdu

je nutné je urážet předstíráním, že jsou míň než vzduch?

[little.owl]

... až na lidi kolem kFreeBSD a Hurdu

je nutné je urážet předstíráním, že jsou míň než vzduch?

Na to ani neni treba predstirat, viz zde:

alpha            : 14         graph
amd64            : 92571      graph
arm              : 37         graph
armel            : 953        graph
armhf            : 206        graph
hppa             : 15         graph
hurd-i386        : 26         graph
i386             : 63189      graph
ia64             : 37         graph
kfreebsd-amd64   : 73         graph
kfreebsd-i386    : 56         graph
m68k             : 8          graph
mips             : 5          graph
mipsel           : 38         graph
powerpc          : 745        graph
ppc64            : 1          graph
s390             : 18         graph
s390x            : 4          graph
sh4              : 10         graph
sparc            : 162        graph
sparc64          : 1          graph
x32              : 2          graph
unknown          : 97         graph

Pomery budou nejspise spravne, a kolik promile pak maji kfreebsd-* a hurd-* ?

[kavol]

z deště pod okap

mimochodem, jedna ze zajímavejších odpovědí na ten Lennartův blábol

[Robert Smol]

Tak ten clovek si za jedno odpoledne precte neco o CGroup a uz je opravnen to radne komentovat ;) Dnesni zeleza jsou tak vykonna, ze pro rozumne rozdeleni prostredku mezi stovky nejakych virtualnich kontejneru je cgroup dost podstatna zalezitost.

KDbus je evoluce DBusu. Nemuzete vzit userspace a 1:1 je narvat do jadra. DBus je prima, ale v designu ma vykonnostni problemy.

Obecne ze nejsou spravna API lze asi vytknout, ale ta API se resi na pochodu a pokud OpenRC jeste ani poradne nepodporuje cgroups, tak bych spise rekl, ze se k premysleni nad problemy implementace s kdbus ani nedostali.

Lennart ma urcite obcas dost nevhodne vyjadrovani, ale v podstate ma pravdu. Podivejte se do repozitaru u Upstart a systemd a uvidite jaka je kde aktivita.

[R]

Otazka je: kto potrebuje "stovku nejakych virtualnych kontajnerov"? Na desktope a notebooku? Na serveri, kde bezia dve aplikacie?

[Robert Smol]

Vetsina dnesniho SAAS by takto klidne mohla bezet. Nebo dalsim prikladem jsou mene vytizene hostingy, kde muzes mit az tisice hostu. Systemd dokaze probudit kontejner v radu desitek ms.

Ono ale preci jakekoliv zrychleni neni na skodu ne? Osobne si dovedu predstavit, ze z toho tezi i desktop aplikace (pripadne smartphony).

Lide zde zapominaji, ze Linux neni jen desktop ci gentoo server jako hosting 20ti webu. Je to v androidu a ci real-time systemech.

[pavlix]

Popravdě řečeno když jsme s kamarádem zakládali kdysi hosting (byli jsme mladí a hloupí), tak jsme se snažili jednotlivé zákazníky oddělit co nejvíc, cgroups a navázaná funkcionalita je na to zdá se ideální.

[pavlix]

Nemuzete vzit userspace a 1:1 je narvat do jadra.

Mě ani tak nezajímá, jestli to jde nebo nejde, ale jestli je to k něčemu dobré.

[Robert Smol]

Zkuste treba tenhle vycuc od Greg Kroah-Hartman, je to clovek zodpovedny z kdbus implementaci. https://github.com/gregkh/presentation-kdbus/blob/master/kdbus.txt

Nejak dalsi info jsem videl na ruznych konferencích. Cele je to diky tomu, ze DBUS proste nelze pouzit pro rychle IPC (asi kvuli context switchum, ale expert nejsem).

[pavlix]

Zkuste treba tenhle vycuc od Greg Kroah-Hartman, je to clovek zodpovedny z kdbus implementaci. https://github.com/gregkh/presentation-kdbus/blob/master/kdbus.txt

Já to nevidím úplně k tématu, protože si nemyslím, že celý projekt kdbusu má za cíl jen optimalizaci pomocí odstanění context switchů. Hádám, že tam bude hromada dalších optimalizací a hlavně přesun dále racionalizuje závislost na D-Busu a potažmo systemd.

Nejak dalsi info jsem videl na ruznych konferencích. Cele je to diky tomu, ze DBUS proste nelze pouzit pro rychle IPC (asi kvuli context switchum, ale expert nejsem).

Je legrační, jak se dle potřeby D-Bus nejdřív prezentuje jako úžasný a univerzální nástroj, ale najednou, když je třeba odůvodnit kdbus, tak se přijde na to, že je to celé nesmyslně pomalé a že to mělo být navrženo úplně jinak.

Dneska už je kdekomu (ať to řekne nahlas nebo ne) jasné, že čím podobnější bude kdbus původnímu dbusu, tím to bude hůře navržené, jenže dbus už de facto patří do rodiny systemd, tady mezi ty služby, které se nepřizpůsobují, ale kterým se přizpůsobují ostatní. Takže nezbývá než doufat, že Greg udělá, co bude v jeho silách.

[little.owl]

Takže nezbývá než doufat, že Greg udělá, co bude v jeho silách.

Nejvetsi tlak prisel ze strany Genivi, kde doslova znasilnovali dbus a pouzivali ho zpusobem, ke kteremu nebyl designovan. Tisice zprav za sekundu, cpali tam veci primo z CAN busu. Protoze to samozrejmne nefungovalo, prisli AF_BUS, ktery jim ale nevzali do kernelu a pak se toho chytil Lennart && spol, tem to take neproslo, nakonec byli spolecne schopni vytvorit tlak a dotlacit GKH k nejake implementaci.

[pavlix]

To zní jako hezká pohádka, otázka je, kolik toho má společného s realitou a jaké další okolnosti jsou nevyřčené.

[little.owl]

otázka je, kolik toho má společného s realitou a

A co chces zpochybnit? Tohle lze rici o vsem.

a jaké další okolnosti jsou nevyřčené.

To bezesporu.

[pavlix]

Přinášíš ničím nepodloženou leč očividně zjednodušující teorii o tom jak věci mohly probíhat. Na tom snad ani není, co zpochybňovat, ledaže bych si vycucal z prstu (a dostupných útržků více či méně pochybných informací) teorii vlastní.

[little.owl]

Nepodlozenou? Precti si treba blog GKH o AF_BUS. Muj zamestnavatel je clenem Genivi - tech crazy automotive Linux developers - stejne jako polovina nasich dodavatelu a mezi cleny Genivi jsou i relativne velci prispevatele do jadra a sponzori Linux Foundation, takze uplne nesli ignorovat, a integrace AF_BUS do kernel 3.4 byla jen naplast aby se nepodelali. Mam pristup k protokolum jednani a mailing listu a Lennart se prisral pozdeji, kdyz si protagoniste uvedomili ze treba spojit sily.

[Petr Ježek]

Tentokrát +1 s malou rezervou pro případ, že cíle vývoje a managementu se podstatné, byť dobře skytě liší.

[pavlix]

To už je podstatně lepší než ta původní střelba do prázdna.

[little.owl]

To vubec nebyla strelba do prazdna. Historie kdbus se zacala psat na meetincich Genivi v 2009/10, kde se resilo co je potreba udelat, aby Linux byl vhodnou platformou pro automotive; respektive aby slo cestou nejmensiho odporu naportovat stavajici aplikace. Lennart a spol se prifarili mnohem pozdeji, kdyz protlacovali systemd.

[pavlix]

To vubec nebyla strelba do prazdna.

Tak si to po sobě přečti a zkus si představovat, že jsi nezúčastněný člověk. Jsem si jistý, že pochopíš.

[henkye]

Co vím (ze studia C API), tak o D-Busu se otevřeně říkalo, že nikdy nebyl navržen pro rychlost.

[kralyk z abclinuxu]

Pokud vím, tak to se vztahuje na referenční implementaci.

[little.owl]

(asi kvuli context switchum, ale expert nejsem).

Nejen kvuli kontext switchum, slo o mnozstvi kopirovanych dat, systemovych callu,celkovy overhead, problem byla hlavne latence a propustnost.

[Heron]

A on DBUS má jít použít pro IPC? Není náhodou na IPC určeno něco jiného (od signálů po shared mem)?

[Josef Kufner]

IPC = Inter-Process Communication. Je to obecný termín, který zahrnuje i DBus a další technologie.

[paul]

+1

ale je to marny, je to marny ..

[pavlix]

A pro co jiného by se D-Bus používal než pro komunikaci mezi procesy (inter-process communication)?

[pako]

A on DBUS má jít použít pro IPC?

:D

A co na to Wiki?

D-Bus is a free and open-source inter-process communication (IPC) system...

A D-Bus sám o sobě?

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication...

Takže já bych to viděl tak, že D-Bus by asi k IPC jít použít měl, nebo se něco hodně nepovedlo. ;)

Není náhodou na IPC určeno něco jiného (od signálů po shared mem)?

Ale jo, náhodou mj. tyhle taky.

[Heron]

Používat pro IPC něco, co běží jako služba, která může kdykoliv neběžet, mi přijde minimálně jako velmi křehké řešení a celkově padlé na hlavu.

[pavlix]

1) V mnohých instalacích nemůže kdykoli neběžet, přestalo by fungovat tolik věcí, že je to z hlediska uživatele srovnatelné se selháním kernelu.

2) Ne vždy, když někdo řekne D-Bus, musí to být nutně řešení pomocí D-Bus démona.

3) Práce na přesunu D-Busu do jádra pokud vím pokračují. V kernelu tenhle problém odpadne a taky to umlčí většinu kritiků. Protože v userspace je každý démon bloated, ale v kernelu je všecko v pořádku ;).

[Heron]

Ad 1) Celkem by mě zajímalo v jakých. Já dbus démon vypínám a nějak jsem si nevšiml, že by něco nejelo.

Ad 3) To je na tom to nejhorší. Že se takový nepotřebný nesmysl dostane do jádra. Stačí jít vyšlapanou cestou. Vytvoří se nesmysl, potom ho někdo (třeba z donucení) začne používat. Zjistí se, že nesmysl je pomalý a v jádře by to bylo víc cool, tak se nesmysl nacpe do jádra.

[pavlix]

Ad 1) Celkem by mě zajímalo v jakých. Já dbus démon vypínám a nějak jsem si nevšiml, že by něco nejelo.

Oni vypnuli google?

To je na tom to nejhorší. Že se takový nepotřebný nesmysl dostane do jádra. Stačí jít vyšlapanou cestou. Vytvoří se nesmysl, potom ho někdo (třeba z donucení) začne používat. Zjistí se, že nesmysl je pomalý a v jádře by to bylo víc cool, tak se nesmysl nacpe do jádra.

A není to taky trochu tím, že lidé štěkají, že D-Bus přece není IPC (a co by to asi bylo?), místo toho aby se věnovali skutečným problémům a možnostem něco zlepšit?

[Heron]

Oni vypnuli google?

Nevím. Ale v diskusi bývá běžné, pokud někdo něco tvrdí, že to taky umí doložit. Proto se ptám tebe, jaké systémy znáš, u kterých je nefunkčnost d-bus stejně závažný problém, jako chyba kernelu.

A není to taky trochu tím, že lidé štěkají, že D-Bus přece není IPC (a co by to asi bylo?), místo toho aby se věnovali skutečným problémům a možnostem něco zlepšit?

Tak lidé se věnují skutečným problémům. Třeba rozchození zvuku po té, co se do systému nasralo pulse audio a podobné radosti života (nebudu rýpat ).

[pavlix]

Nevím. Ale v diskusi bývá běžné, pokud někdo něco tvrdí, že to taky umí doložit. Proto se ptám tebe, jaké systémy znáš, u kterých je nefunkčnost d-bus stejně závažný problém, jako chyba kernelu.

Vážně nevíš o jediné službě, která bez D-Busu přestane fungovat?

[Heron]

Já dbus démon vypínám a nějak jsem si nevšiml, že by něco nejelo.

[pavlix]

Věřím, že je to jenom provokace a že ve skutečnosti dokážeš rozlišit, zda taková věc existuje (a někdo ji používá) a zda ji používáš ty (a navíc si všimneš jejího selhání).

[Heron]

Ne, to není provokace. To je o úhlu pohledu. Pokud nějakou věc můžu beztrestně vypnout, aniž by cokoliv přestalo fungovat (a nebo třeba začalo fungovat lépe), tak začnu mít pochybnosti, proč v tom systému (ještě k tomu by default zapnuté) vůbec je.

Protože podle mě by mělo být vše by default vypnuto (to je alespoň takový základ bezpečnosti, služba která neběží se nedá napadnout) a zapínat by se mělo pouze to, co je nezbytně nutné. V tomto se neshodneme, už dříve jsi psal, že uživatelé často nemají důvod něco vypínat. Moje uvažování je přesně opačné, měl by existovat důvod pro zapnutí, pokud není, tak nechat vypnuté.

DBUS (pulse, nm) je přesně tento případ. Nevidím důvod ten démon mít zapnutý a to, že ten systém běží k mojí spokojenosti (servery, desktopy, virtuálky) mě ujišťuje v tom, že toto rozhodnutí je správné.

[pavlix]

Ne, to není provokace. To je o úhlu pohledu. Pokud nějakou věc můžu beztrestně vypnout, aniž by cokoliv přestalo fungovat (a nebo třeba začalo fungovat lépe), tak začnu mít pochybnosti, proč v tom systému (ještě k tomu by default zapnuté) vůbec je.

To je úplně jiné téma.

Moje uvažování je přesně opačné, měl by existovat důvod pro zapnutí, pokud není, tak nechat vypnuté.

Tvoje uvažování je opačné vůči tomu, vůči čemu se chceš vyhrazovat, nikoli však vůči mému. Rozdíl mezi námi je v tom, že mě zajímají širší souvislosti a z toho důvodu připouštím více možností užívání systému postaveného na open source komponentách. Z toho vyplývá, že já tvoje požadavky budu vždycky chápat, zatímco ty budeš ty moje maximálně tak tolerovat ;).

Nevidím důvod ten démon mít zapnutý a to, že ten systém běží k mojí spokojenosti (servery, desktopy, virtuálky) mě ujišťuje v tom, že toto rozhodnutí je správné.

Souhlasím, jen je to úplně jiné téma, než ke kterému jsem se výše vyjadřoval a nic to ani nemění na existenci služeb, které ke své práci vyžadují dbus démona (dokud je někdo neupraví nebo dokud se neimplementuje dbus kombinací kernelu a systemd).

[little.owl]

Třeba rozchození zvuku po té, co se do systému nasralo pulse audio a podobné radosti života (nebudu rýpat ).

Jen si rypnete a budte trochu konkretni. Na Fedora/CentOS jsem minimalne za posledni ctyri roky snad nemel jediny problem s PA.

[pavlix]

Předpokládám, že tím rýpnutím měl namysli NetworkManager, jehož vylepšováním jsem taky jistě způsobil mnoho nářků a pláče ;).

[Heron]

Vylepšováním ne. Právě naopak. Pokud se z toho někdy stane i díky tvojí pomoci použitelný produkt, bude to jedině dobře.

Ale příště by chtělo při nasazování zvolit poněkud jiný postup.

[pavlix]

Ale příště by chtělo při nasazování zvolit poněkud jiný postup.

Rád si poslechnu cokoli, co se mě nějak týká, jenže já jsem začal kopat do NetworkManageru loni v létě a po letošním létě už na to mám jen minimum času a nezbývá mi než spoléhat se z velké části na tlaky komunity a zákazníků. Pokud jde o komunitu, tam se snažím, co to jde, ale ne každý má chuť a čas věnovat se NetworkManageru, i kdyby to mělo být jen v bugzille.

[Heron]

Netvrdím, že se to týká přímo tebe. Ale z reakcí v diskusích je jasné, že postup nasazování (nejenom) NetworkManageru, nebyl zvolen zcela nejlépe.

Je tu nový produkt, který má cosi nahrazovat. A tento produkt se ve fázi, kterou lze těžko nazývat produkční kvalitou, dostal do distribucí (různými způsoby). Potom se nelze divit, že si tento produkt vytvoří poněkud negativní reputaci. Nahrazuje něco, co funguje a na co jsou všichni zvyklí a není zřejmý důvod, proč to nahrazovat (a nikdo se ani nesnaží s tím důvodem přijít).

Takže to potom dopadá tak, že ti lidé si to zvyknou vypínat (selinux, networkmanager, pulseaudio, avahi apod) a víc se o to nezajímat. Tím vzniká další tření jak se to postupně dostává do dalších dister a je těžké se toho zbavit (systemd).

Myslím si, že komunita má obecně ráda nový software a těší se na nové verze. Takže by default je nastavená pozitivně a rozhodně nelze říct, že by se něco nového odmítalo (nové fs, například, se dostávají i do produkce ještě v devel stavu, protože je hlad po jejich funkcích). Proto má diplomacie kolem nového produktu poměrně pěkně připravenou cestu a je docela těžké si to pokazit. Ale některým projektům se to daří excelentně.

[Jendа]

a není zřejmý důvod, proč to nahrazovat (a nikdo se ani nesnaží s tím důvodem přijít)

Já třeba ten důvod mám (na notebooku). Chodím mezi různými sítěmi (doma, eduroam, dvě odlišné VLAN v brmlabu - a to ještě každá v drátové a bezdrátové variantě) a rád bych, abych vždycky nemusel ručně spouštět dhclient, občas i restartovat wpa_supplicant a řešit radosti s tím, že se nesmaže nefunkční (RA-přidělená) IPv6 adresa/routa při přechodu mezi sítěmi, takže se pak IPv6 pakety ztrácí.

[pavlix]

Ten pohled má mnoho problémů, od toho, že NetworkManager není nový software, přes to, že maintaineři by měli mnohem víc přemýšlet nad klíčovými komponentami svých distribucí a pokud možno se podílet i na jejich vývoji (i kdyby jen v bugzille).

Často je problém i v tom, že prostě nejsou lidi. Ne vždy jde jen o to, že by jich byl příliš malý počet, často jde spíš o to, že ti, kteří jsou, nemůžou z nějakého důvodu zastat všechny potřebné funkce.

Pokud jde o NetworkManager, tak do podzimu 2012 neexistoval reálný tlak na to uzpůsobit NM pro použití s dalšími nástroji a především s virtualizací. Pak zas byly problémy s komunikací. Ze serverového pohledu lze NM do podzimu 2012 považovat za mrtvý projekt.

Jenže nikdo do té doby nepřipravil univerzální alternativu, která by byla vhodná jak pro servery, tak pro desktop. To činí z NetworkManageru přes všechny ty nepříjemnosti unikátní projekt, ať už to ve výsledku dopadne jak chce.

[Heron]

Jenže nikdo do té doby nepřipravil univerzální alternativu, která by byla vhodná jak pro servery, tak pro desktop.

Otázkou je, proč by měla existovat.

[pavlix]

Takovou otázku bych očekával pouze od člověka, který na svém desktopu/laptopu nikdy v životě nepustil serverovou službu ani virtualizaci, a který nepoužívá ani jiný software (třeba linuxové jádro) na strojích s různým účelem.

[little.owl]

To mi bylo jasne, ale kdyz jsem zacal tahat PA ....

jehož vylepšováním jsem taky jistě způsobil mnoho nářků a pláče ;).

Za praci na NM mas u mne hodne kladnych bodu, diky.

[pavlix]

Za praci na NM mas u mne hodne kladnych bodu, diky.

Já doufám, že ještě nějaké nasbírám, byť teď už za jednotlivosti.

[Heron]

Tak on je zvuk a zvuk. Můj cíl je udělat z PC HiFi přehrávač (samozřejmě je otázka, zda je to samo o sobě dobrý nápad, protože už jen výběr zvukovek je značně omezen) a to je věc, kterému PA úplně nepomáhá (ale jako není sám, v zásadě všechny démony, co se vsunou do zvukové cesty, jsou zlo). Základem je, aby do zvuku nic nezasahovalo (ideální případ je kodec -> DAC -> zesilovač), dělalo se minimum konverzí apod. A systém, který je navržen na "just works" je v podstatě přesným opakem. Ten se snaží vše zkonvertovat na nějaký společný formát, ty filtry jsou navrženy na rychlost a ne na kvalitu (přitom ten HW by si to uměl udělat sám) apod.

Takže hraje to, ale to je tak všechno.

[lertimir]

Používám zvukovku Asus Essence ST a jsem velmi spokojen. V čem konkrétně jsou démoni vsunutí do cesty zlo? Podle mne podstatné je, aby DAC dostal digitální data včas, a jestli mezitím projde přes několik démonů, které data nezkreslují (pouze úpravy hlasitosti), je v podstatě jedno. Pak kvalita závisí na kvalitě DAC a zamezení rušivých signálů do vstupu do analogové cesty.

[trekker.dk]

jestli mezitím projde přes několik démonů, které data nezkreslují (pouze úpravy hlasitosti)

...přičemž úprava hlasitosti vůbec nezanáší zkreslení.

Navíc, nemění náhodou PA sample rate přehrávaných dat?

[lertimir]

Ale úpravu hlasitosti někde řešit musíš, buď v analogové části nebo v digitální. Osobně dávám přednost veškerým úpravám v digitální části, protože už to vyrobit potenciometr s kvalitním souběhem je dost hrůza. Převzorkování samozřejmě je nepřípustné.

[Heron]

Pokud se sníží hlasitost v digitální části, tak se tím efektivně přichází o rozlišení (na data efektivně zbude méně bitů - znížení hlasitosti o 6dB je 1b dolů). Obyvkle se to dělá v předzesilovači, tedy v analogové části hned za DAC.

[little.owl]

Pokud digitalne mixujete vice normalizovanych vstupu do normalizovaneho vystupu, musite omezit dynamicky rozsah vstupu, jinak vam to zacne orezavat.

Obyvkle se to dělá v předzesilovači, tedy v analogové části hned za DAC.

Tam si zase pak snizite odstup signal sum, coz je do znacne miry ekvivaletni ztrate bitoveho rozliseni (kvantizacni sum).

[dustin]

Obvykle = v tomto případě audiofilsky. Dnes je digitální regulace zcela běžná a kvalitativně srovnatelná s běžnou analogovou regulací. Samozřejmě kvalitní analogová má práh šumu ještě níž, ale to už je i cenově trochu jinde. Diskutováno např. nedávno http://hifi.slovanet.sk/bb/viewtopic.php?t=16635

[lertimir]

To nepřípustné převzokování jsem myslel downsampling. Před pár lety jsem společně s pár kamarády se snažil si vyřešit otázku kvalitního hifi z kompu (a výsledkem bylo i zakoupení uvedené karty) a poslouchal jsem dost široké spektrum nahrávek s různým samplingem jak přímo tak nahoru převzorkované, a můj závět je takový:

• Převzorkování nahoru dobrým algoritmem (na 176.4k/192kHz@24Bit) se pozná tím méně, čím je kvalitnější DAC. Ve slepých testech na externích DACích a v mnoha případech i na své vlastní zvukovce jsem nepoznal rozdíl mezi přímým vstupem a převzorkovaným signálem. Na špatném DACu byly převzorkované signály jasnější, vysvětluji si to tak, že špatný DAC udělá špatnou obálku nad těmi vzorky.
• Zvýšení bitové hloubky na 24 bit bylo místy slyšitelné zjasněním zvuku v tichých partiích. Opět si vysvětluji tak, že pokud nejdříve převedu 16 bit na 24 a pak nějak upravuji tak mám dost bitů rezervy.

Od té doby provozuji zvukovku skoro výhradně v režimu 192k@24Bit.

[little.owl]

špatný DAC udělá špatnou obálku nad těmi vzorky.

To je hlavne otazka vystupniho filtru a dobry filtr je drahy => v ramci koseseni kostu pada jako prvni. V posledni dobe DAC s integrovanym zesilovacem ve tride D to o neco zlepsily, e.g. TLV320DAC3100.

[dustin]

Tak SNR DACu 95dB není žádný zázrak a filtry na fs přes 300kHz po oversamplingu nejsou až tak náročné.

[little.owl]

Kdybych chtel uvadet spickove DAC, volil bych jiny cip, nehlede k tomu ze cena konstrukce, napriklad kvuli narokum na napajeci zdroj, stineni ci layout je pak jinde.

Pointa byla v tom, ze v poslednich trech letech doslo diky teto kategorii ke kvalitativnimu posuvu i u zarizeni, kde se setri na kazdem detailu a doba, kdy clovek slysel na pozadi pohyb hlav disku se opet vzdalila, i u levnych zarizeni; a hadam ze vetsina z nas pouziva zabudovanou zvukovku.

[dustin]

Zvýšení bitové hloubky na 24 bit bylo místy slyšitelné zjasněním zvuku v tichých partiích. Opět si vysvětluji tak, že pokud nejdříve převedu 16 bit na 24 a pak nějak upravuji tak mám dost bitů rezervy.

Jak takové zvýšení konkrétně probíhalo? A byly ty testy opravdu poctivě naslepo?

Většina resamplerů pracuje interně ve float32, některé ve float64. Dmix in-resampler-out vše v 16bitech natvrdo, PA myslím float32, jackd float32. Nebo jsi cíleně omezoval bitovou hloubku za resamplerem (což v PA ani nevím, jak udělat)?

Tvá zvukovka akceptuje S16_LE a S32_LE, ale DAC je čistě 24bitový. Zdá se mi dost nepravděpodobné, že by ti do zvukovky šlo 16bitů - kontroloval sis to?

[lertimir]

Tehdy jsme to zkoušeli na WinXP s proprietálními drivery na zvukovky. S tím že zvuk dodával přehrávač Foobar 2000 v konstantím nastavení, a veškerá úpravy (hlasitost a vzorkování) se prováděly v driveru zvukovky. Slepý to bylo tak, že dva počítače, se dvěma zvukovkama krmily zesik (myslím že to byl Marantz, ale typ si už nepamatuji a za ním byly repro nebo sluchátka (AKG 601 a model repro si už nepamatuji, ale byly to s té kategorie špičkových beden počátku 90 let, každá měla objem tak 100 litrů). Jeden člověk přepínal (zvukovky, vzorkování a popřípadně zdroje, protože máme pár nahrávek ve flacu jak 44.1k/16 tak 88,2k/24) a druzí dva poslouchali a komentovali, co slyší.

[dustin]

Typická audiofilská diskuse Jaké zkreslení zanáší digitální úprava hlasitosti (tj. dělení fixním číslem) v PA oproti úplně stejně digitální úpravě hlasitosti v DACu přes čudlíky alsy? A pokud máš analogovou regulaci v předzesilovači, co ti brání nastavit v celém řetězci hlasitost na 100%?

PA je mixer, tedy musí sjednotit streamy na společnou FS. Umí dvě různé fs, které se přepínají dle prvního přehrávaného streamu.

Není problém mu podstrčit novou soxr-lsr (stejně jako xbmc, mpd a dalším softům využívajícím korektně libsamplerate). Ani s nejvyšší kvalitou pak nežere resampling skoro nic http://blog.ivitera.com/pavel/linux-audio/pulseaudio-with-ld_preloading-libsoxr-lsr

A když mi ukážeš důvěryhodný výsledek slepého testu, že sluchem spolehlivě rozpoznáš rozdíl mezi originálem a resamplovanou verzí např. přes "SoX VHQ", smeknu.

[little.owl]

Navíc, nemění náhodou PA sample rate přehrávaných dat?

Dela. Mixovat data s ruznou sample rate do vystupu s dalsi sample rate neni sranda a nejjednodussi cesta je presamlovat vsechno na sample rate vystupu (casto omezeno HW) a pak to mixovat.

Resampling ale zahrnuje interpolaci a zmenu frekvencniho rozsahu.

[dustin]

Bez resamplingu na společnou fs to nejde vůbec - zvukovka běží jen na jedné fs.

Kvalitní resampling je slepým uchem neslyšitelný. Samozřejmě v kombinaci s okem (tedy hlavou) je slyšitelné absolutně vše, ale to už je úplně jiné téma

[little.owl]

Existuji multirate metody kde se provadi mixovani a interpolace treba ve frekvencni oblasti, ale resampling a mixovani v casove oblasti je asi jednoduzsi.

[dustin]

A z toho pak leze single fs?

[little.owl]

Protoze se to transformuje zpet do casove oblasti, nelze tomu uteci.

Resampling na vstupu je predzpracovani pro urcity typ mixovani, nejcasteji pouzivany, ale neni jediny. Srovnat "meritko" ale musite, at to udelate v casove ci frekvencni oblasti, ci jine domene. Z me strany to bylo puvodne opatrne vyjadreni, mozna zbytecne, nebot jine metody se u zvuku temer nepouzivaji.

[dustin]

Díky za rozšíření obzorů :)

[dustin]

Pokud chceš mít jistotu, že v řetězci nenaskočí žádná konverze, pak ale nejsi běžný uživatel a musíš si to nastavit sám. Nakonec to není žádná věda. Běžný uživatel nic takového nepotřebuje, naopak vyžaduje to "just works" - tedy PA.

[little.owl]

Můj cíl je udělat z PC HiFi přehrávač

Uvedomujete si vas cil se pak diametralne lisi od cilu PA?

Základem je, aby do zvuku nic nezasahovalo (ideální případ je kodec -> DAC -> zesilovač), dělalo se minimum konverzí apod.

PA musi byt schopno mixovat zvuk z vice zdroju, z vice formatu, provadet konverzi a dynamickou normalizaci, ekvalizaci (ok, tu dela bidne), na stranu druhou jsou tu pozavky na nizky pocet interruptu - napriklad kvuli spotreba, a tak se toleruje vyssi latence.

Vasim potrebam vyhovuje jack2, ktery ale s PA dokaze rozumne existovat a dynamicky prevzit plne kontrolu zvukovky a pak se velmi priblizite vasemu modelu.

[Martin Mareš]

Vasim potrebam vyhovuje jack2,

To jsem si také jednu dobu myslel... leč rovněž má své nectnosti, a to nikoliv malé: není schopen najednou fungovat v programy více uživatelů a přenos zvuku po síti se mezi různými verzemi jackd2 často nedomluví.

Ale na nic lepšího jsem zatím nenarazil. Když jsem se k podobným věcem snažil přiohnout PA, narazil jsem na takřka kontinuum bugů, které tomu bránily, a kvalita kódu nedává moc nadějí, že by to brzy mohlo být lepší. Takže osobně mám z PA pocit "myšlenka hezká, implementace saje". Vlastně stejný jako ze systemd.

[little.owl]

To jsem si také jednu dobu myslel... leč rovněž má své nectnosti, a to nikoliv malé: není schopen najednou fungovat v programy více uživatelů a přenos zvuku po síti se mezi různými verzemi jackd2 často nedomluví.

Ja ho pouzivam jen tam kde potrebuji definovanou/stabilni latency, zadny adaptivni clipping, tam nemam problem, prenos pres sit jsem nikdy nezkousel, tipuji ze mate pravdu.

Takže osobně mám z PA pocit "myšlenka hezká, implementace saje".

Je to sileny kod, Lennart nikdy nedelal signal processing a tak mi prijde ze snad kopiroval nektera reseni slepe z internetu.

Vlastně stejný jako ze systemd.

Snad si Lennart najde lepsi pastvinu a pujde od toho, a necha to dodelat nekoho, kdo sice nema tak progresivni mysleni, ale schopnost dotahovat veci do konce.

[pako]

Pokud si dobře pamatuji, tak prakticky všechna data mezi jednotlivými komponentami a aplikacemi v MeeGo šli přes D-Bus. Selhání D-Busy by tak z hlediska fungování systémů nebylo až tak jiné, jako selhání jádra (tedy asi by to nazatuhlo, ale nešlo by to použít).

Podstatné je. Můžeme debatit, k čemu se ten nástroj hodí a k čemu ne, ale D-Bus je prostě napsaný pro IPC. Takže by nebylo od věci uznat, že jste se sekl, a pak se dá případně dostat k věcné diskuzi, kdy je jeho použití rozumné a kdy ne (třeba to MeeGo). ;)

[pavlix]

+1

[little.owl]

To je na tom to nejhorší. Že se takový nepotřebný nesmysl dostane do jádra.

Nepotrebny jak pro koho. Cela rada OS ma messaging zabudovany primo do kernelu.

[little.owl]

ale v kernelu je všecko v pořádku ;).

Ja bych spise rekl, ze zalezi kdo to tam protlaci, a u GKH to bude urcite v poradku; proto tam ostatne je .

[kavol]

Tak ten clovek si za jedno odpoledne precte neco o CGroup a uz je opravnen to radne komentovat ;)

no, ty si ani pořádně nepřečteš, co napsal, a už jsi oprávněn to řádně komentovat ... :-p

[Robert Smol]

I'm quite sure I understood the general concept in the afternoon it took me to write the initial OpenRC support .

Asi je to fakt mastr, jen spravna implementace libcgroup trvala mesice. Ono je jedna vec udelat initial support a druha vec je udelat neco poradne.

[trekker.dk]

On ale nemluví o porozumění libcgroup, ale o tom, co dělají cgroups. Což je opravdu na pár hodin, maximálně dní. To, že lennartware umí z jednoduché věci udělat přesložitělou složitost, je věc jiná.

[Robert Smol]

OK, ale k cemu je mi API v kernelu bez knihovny pro obsluhu? Jestli to Lennart dela slozitejsi nez je potreba nedokazu posoudit (nejsem cgroup vyvojar). Jen mi pripada usmevne, ze za odpoledne je z nekoho mastr, kdyz se ta vec resi jiz minimalne 2 roky a nejednou to bylo prepsano. Mozna naopak uz jsme ve stadiu, ze cgroup je jednoducha vec. Proc ne.

[pavlix]

A něco víc než prázdné řeči?

[trekker.dk]

"API v kernelu" je přístupné přes pseudo-fs. Nová cgroup? mkdir xyz. Další, která bude hierarchicky pod ní? mkdir xyz/abc. Zařadit do ní proces? echo "12345" > xyz/abc/tasks

Složitější případy možná budou chtít složitější obsluhu, ale i tak mi dát tohle do nějaké knihovny opravdu nepřijde jako něco, co by vyžadovalo práci na několik let.

[pavlix]

+1

[little.owl]

No, Tejun Heo, maintainer cgroups, dela redesign cgroups, ktere vyvijely spise chaoticky, takze zasah byl nutny. Kayem Sievers vycitil prilezitost a tak na tom delaji spolu, tudiz kernel subsystem se ohne ku potrebam systemd.

[kavol]

přesně tak - ocitovat, že jde o "general concept", a pak mlít něco o vývoji knihovny ... asi se budu muset Honzy přeptat, v čem tedy že ty "complexities" spočívají, nicméně co si vybavuju, když se o tom před těmi šesti lety s Ivanou bavili, tak mám dojem, že si pochvaloval, jak je to krásné, mocné a jednoduché

[Michal Vyskočil]

On ale nemluví o porozumění libcgroup, ale o tom, co dělají cgroups.

Akorát, že Patrik reaguje úplně mimo, protože Lennartovo "don't even remotely understand the complexities of this" se netýká cgroups jako takových, ale "a single arbitrator component for cgroups" a úvahám o vytvoření odděleného démona sloužícího jako "arbitrator component".

[little.owl]

Presne tak, me stacila uz jeho prvni reakce, abych ho dale uz nebral moc vazne.

[Heron]

"We don't even pretend to understand the Unix philosophy anymore"

Ano. Tohle neví víc projektů. Bohužel.

[msk]

Ja som myslel, ze Debian uz na nejaku takuto zrudu presiel, pretoze pred pol rokom som zapasil s XBian-om a z toho init systemu co pouziva ma prisaham bohu skoro nacisto jeblo.

[Kaacz]

Taky mam pocit, ze uz od 6 tam neco jako upstart je ..

[ncweohfnow]

Gentoo pristup k rieseniu (tusim OpenRC) sa mi zatial paci najviac z tych par roznych systemov, co som poznal. Zavislosti sa tam riesia pekne a aj ine bezne veci...

PS: Je nejaky system, ktory rozdych, ze mam na diskoch mdraid, na ktorom je potom lvm (zatial to je OK) na ktorom mam logical volumy, na ktorych je dalsi mdraid (samozrejme s nejakym fyzickym diskom, ktory ale mdraid neposkladal pri starte, lebo mu chybala druha cast raidu)?. Preco v case udev a podobne nemame zavesene lvm a mdraid init skriptiky na pripojenie disku? Co sa stane, ked pripojim usb kluc, na ktorom je jedna cast raid0 pola a nasledne pripojim druhy usb kluc s druhou castou pola? Musim to rucne "assemble"-ovat... Preco je mdraid a lvm sucastou boot procesu a nie sucastou udev pravidiel? Vie mi niekto kvalifikovane odpovedat?

[----]

OpenRC. Jestli Debian přejde na Systemd nebo Upstart, přecházím na Gentoo (popř. Funtoo).

[kavol]

to je přehnaný optimismus, Gentoo už se salámovou metodou chystá na systemd taky

[j]

jj, me osobne nejvic nasrali (doslova) tim, ze se eth neda prejmenovat na eth ... kdyby se mi dotycny dostal pod nohu, tak mu s radosti prokopnu rit. Navic se to zcela bez jakyhokoli upozorneni jednoduse objevilo ve stable ... a teprve expost, kdyz zacli lidi rvat ze jim jejich systemy nebootujou, pripadne jim nejede sit ... prisla newska ... proste lol.

[Pavel Stárek]

S touhlectou "featůrou" už přišel před nějakou dobou poměrně obstarožní CentOS 6. Ale naštěstí to jde vypnout. Jde to vypnout i ve Fedoře 19, a půjde to vypnout i v tom Gentoo. Problém je, pokud na to vývojáři předem neupozorní, popřípadě to nedají do release notes.

[j]

Mno ono to vypnout ... nejde.

Jde o to, ze puvodne slo podle MAC adresy rict "ty budes eth0" a "ty budes eth1".

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:02:96:00:3f:aa", NAME:="eth0"

Na coz jsou samo navazany spousty dalsich veci - konfigurace site, sluzby, firewall ... to ted jednoduse nelze, protoze prislusna cast kodu byla z dovodu "cistoty" odstranena. Takze nezbyva nez nechat system nabootovat, pockat jak si sitovky pojmenuje, pak nalezite prehazet kabely a doufat, ze si to priste nerozmysli, a nepojmenuje je naopak (coz se dost pravdepodobne stane pri nejaky zmene HW).

Druha varianta je prepsat vse zminena na ty zhuverilosti typu enp0s3 (fakt uzasny nazev pro zarizeni, kterymu se 30 let rika eth). Mno a protoze kernel dal pouziva eth, tak kvuli odstraneni prislusne casti kodu nejde rict ze enp0s3 == eth0.

Mno a ono prehazovat kabely na 1000km vzdalenym stroji, to se fakt dela celkem dobre ...

[PaulosV]

To snad ne. Oni tu featuru odstranili? Doufam, ze si uvedomuji, ze treba aktivace SW Maple je zavisla na tom, ze se sitovka jmenuje prave eth0... (Coz sice neni problem systemd, ale kdyz chci Maple pouzivat, musim tuhle vec respektovat.)

[j]

Ale jim je zcela zjevne uplne putna ze tim rozbijou sytemy uplne vsem a uplne vsude, to neni jejich problem, oni budou mit svuj uzasny binarni blob.

[kralyk z abclinuxu]

Ale jasně, že neodstranili (viz níže), ten člověk tady akorát neskutečně mlží...

[Pavel Stárek]

Vypnout to jde. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Dole v sekci I don't like this, how do I disable this?

[pc2005]

You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules, then edit the file there and change the lines as necessary.

Tak odstranili to s tou MAC nebo ne?

[Pavel Stárek]

Částečně ano (tedy alespoň ta udev pravidla psaná tak, jak psal kolega výše). Ale šlo by použít asi takové nějaké udev pravidlo:

SUBSYSTEM=="net", DRIVERS=="?*", ENV{ID_NET_NAME_MAC}=="enx000296003faa", NAME="eth0"

[pc2005]

Tak díky za info.

Ještě, že ve Slacku je zatím udev v182.

[kralyk z abclinuxu]

Mno ono to vypnout ... nejde.

Mno, vypnout to jde.

Konkrétně se to dělá takhle:

# cp /dev/null /etc/udev/rules.d/80-net-name-slot.rules

(Viz ten dokument, co linkoval pan Stárek.)

Praktická ukázka na mém systému:

$> pacman -Q systemd
systemd 208-2
$> cat /etc/udev/rules.d/80-net-name-slot.rules
# This file masks persistent renaming rules for network devices. If you
# delete this file, /usr/lib/udev/rules.d/80-net-name-slot.rules may
# rename network devices according to ID_NET_NAME_{ONBOARD,SLOT,PATH}
# properties of your network devices, with priority in that order. See
# the output of 'udevadm test-builtin net_id /sys/class/net/$interface'
# for details on what that new name might be.
#
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
$> cat /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="--MAC adresa--", NAME="hokuspokus0"
$> ifconfig hokuspokus0
hokuspokus0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether --MAC adresa--  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 18
$>

(Svou MAC adresu jsem vycenzuroval)

Jinak opravdu nevim, proč uživateli "j" ty kecy baštíte, evidentně není vůbec psychicky způsobilý o systemd diskutovat...

[Pavel Stárek]

Děkuju Ti náčelníku, že ses mě zastal a prosím nevykat. Nicméně, zaráží mne, že ti funguje to ATTR{address}. Protože já když zkusím:

[pavel@pavel-fc19 udev]$ udevadm info /sys/class/net/eth0
P: /devices/pci0000:00/0000:00:06.0/0000:02:00.0/net/eth0
E: DEVPATH=/devices/pci0000:00/0000:00:06.0/0000:02:00.0/net/eth0
E: ID_BUS=pci
E: ID_MM_CANDIDATE=1
E: ID_MODEL_FROM_DATABASE=Motherboard
E: ID_MODEL_ID=0x8168
E: ID_NET_NAME_MAC=enx6cf049137c3d
E: ID_NET_NAME_PATH=enp2s0
E: ID_OUI_FROM_DATABASE=GIGA-BYTE TECHNOLOGY CO.,LTD.
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd.
E: ID_VENDOR_ID=0x10ec
E: IFINDEX=2
E: INTERFACE=eth0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: UDEV_BIOSDEVNAME=0
E: USEC_INITIALIZED=82071
E: biosdevname=0
E: net.ifnames=0

a ten atribut ADDRESS tam není. Jen ten ID_NET_NAME_MAC .

[kralyk z abclinuxu]

Já to v udevadm info výpise taky nemam, ale přesto to funguje, netušim proč

P: /devices/pci0000:00/0000:00:1c.2/0000:09:00.0/net/hokuspokus0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.2/0000:09:00.0/net/hokuspokus0
E: ID_BUS=pci
E: ID_MM_CANDIDATE=1
E: ID_MODEL_FROM_DATABASE=88E8040 PCI-E Fast Ethernet Controller
E: ID_MODEL_ID=0x4354
E: ID_NET_NAME_MAC=enx--mac--
E: ID_NET_NAME_PATH=enp9s0
E: ID_OUI_FROM_DATABASE=Dell Inc.
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd.
E: ID_VENDOR_ID=0x11ab
E: IFINDEX=2
E: INTERFACE=hokuspokus0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/hokuspokus0
E: TAGS=:systemd:
E: USEC_INITIALIZED=52530

[little.owl]

Ja jsem ted dvacet minut koukal do posledniho kodu udev a jsem z toho volaky zblbly, uz je to zase cele prekopane od doby, co jsem do toho koukal naposledy.

Prejmenovani je implementovane v udev_event_execute_rules() v souboru udev-event.c:

udev_rules_apply_to_event(rules, event, sigmask);
/* rename a new network interface, if needed */
if (udev_device_get_ifindex(dev) > 0 && streq(udev_device_get_action(dev), "add") &&
	event->name != NULL && !streq(event->name, udev_device_get_sysname(dev))) {
    	char syspath[UTIL_PATH_SIZE];
        char *pos;

        err = rename_netif(event);
        if (err == 0) {
        	log_debug("renamed netif to '%s'\n", event->name);

            /* remember old name */
            udev_device_add_property(dev, "INTERFACE_OLD", udev_device_get_sysname(dev));

            /* now change the devpath, because the kernel device name has changed */
            strscpy(syspath, sizeof(syspath), udev_device_get_syspath(dev));
            pos = strrchr(syspath, '/');
            if (pos != NULL) {
            	pos++;
                strscpy(pos, sizeof(syspath) - (pos - syspath), event->name);
                udev_device_set_syspath(event->dev, syspath);
                udev_device_add_property(dev, "INTERFACE", udev_device_get_sysname(dev));
                log_debug("changed devpath to '%s'\n", udev_device_get_devpath(dev));
            }
        }
}

Vypada to, ze pokud defaultni jmeno je stejne jako puvodni navrzene kernelem, prejmenovani se nekona a pokud se kona je nastaven atribut INTERFACE_OLD. Funkce rename_netif() se mi zda celkem transparentni a probubla pres RTNL do zmineneho device_rename(). Atributy jako ID_NET_NAME_PATH jsou nastaveny pres nove naming schema. Blokaci pro defaultni kerneli jmena nikde nevidim, vypada to, ze jak jsou popsane rules, tak se to nastavi.

Tusi nekdo jak to je a kde se zamezuje prejmenovani?

[pavlix]

Tusi nekdo jak to je a kde se zamezuje prejmenovani?

Do kódu už jsem nešel, držel jsem se jen toho, co psal Lennart jako autoritativní zdroj.

[little.owl]

Trochu scary. Celkem zasadni vec, kazdy tu dostava trochu jine vysledky, dokumentace mozna neupdatovana, zmeny v kodu nejasne; ted na to nemam cas.

[Lol Phirae]

To neřeš. Když v LTS verzi Blbuntu dojebali síť "zabudováním" dnsmasq do NetworkManageru, tak to taky nikdo neřešil. A dodnes nevyřešil.

[pavlix]

dojebali síť "zabudováním" dnsmasq do NetworkManageru

V tom bugu se píše něco jiného. Podle všeho se bug netýká ani NetworkManageru, ani dnsmasq, nýbrž balíku jménem resolvconf, který nikdy nebyl moc dobrým řešením zajištění interoperability mezi různými konfiguračními nástroji.

[pavlix]

Kdyby to šlo vypnout (nebo spíše přepnout do původního stavu), tak kolem toho není zdaleka tolik keců.

[Pavel Stárek]

Tak nevím, asi jsem možná blbej, ale ip link show (toto je prosím výpis z Fedory 19, která tuhle featůru zcela jistě používá):

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 6c:f0:49:13:7c:3d brd ff:ff:ff:ff:ff:ff

A docílit toho lze velice jednoduchým způsobem. Spustit anacondu s parametry kernelu bisodevname=0 net.ifnames=0 . Nevěřím, že to samé nejde udělat třeba v Gentoo.

[pavlix]

Jsi si jistý, že se to rozhraní nejmenovalo eth0 už podle kernelu?

[Pavel Stárek]

Jsem. Alespoň Anaconda ho poprvé pojmenovala tím debilním způsobem enp0s1 (nebo tak nějak).

[pavlix]

Jsem. Alespoň Anaconda ho poprvé pojmenovala tím debilním způsobem enp0s1 (nebo tak nějak).

A kernel ho pojmenoval prosím jak? Když jsi si jistý, že jinak než eth0, tak bys to měl vědět.

[Pavel Stárek]

No nevím, v dmesg mám r8169 0000:02:00.0 eth0: link down, takže eth0, ale mám tam ty parametry kernelu bisodevname=0 a net.ifnames=0. Ale zdali budeš chtít, tak extra nabootuju instalační DVD Fedory 19 a řeknu ti, jak blbě to pojmenovává normálně.

[pavlix]

Pokud to kernel pojmenoval eth0 a nakonec se to podařilo přejmenovat na eth0, tak je to bohužel chybný test přejmenování na ethx, protože u přejmenování na původní jméno je velké riziko, že to bude speciální případ.

Je potřeba testovat například přejmenování kernelového eth0 na eth1. Pokud to půjde s aktuální (nepatchovanou) verzí systemd, pak by to podle mě teprve vyvracelo, co píše autoritativní zdroj. Ale pro jistotu bych dal přednost plnému testu a zkusil to s alespoň dvěma rozhraními nechal bych je přejmenováním prohodit.

Někdy si to i zkusím, ale teď jsem tomu schopný dát max pár slov v diskuzi a nějaké to hledání.

[little.owl]

Tam jde o to, ze mu prestali chodit rules jako:

ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", NAME="eth0"
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", NAME="eth1"

Duvod je ten, ze:

(a) Prejmenovani interfacu v kernel space neni jiz podporovano a tudiz interfacy musi mit unikatni jmeno, aby nedochazelo ke konfliktum.

(b) Nepodporuje se vymena jmen, protoze to koliduje s tvorbou interfacu ve stejny cas.

(c) ... /nekdo doplni/.

[Pavel Stárek]

Jo, teď jsem četl nějakou doukumentaci, ale to je záležitostí kernelu, ale ne udevu (systemd). https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html

Nicnméně to neznamená, že po přechodu na udev nelze mít pojmenované net interfaces po staru stačí zadat parametr kernelu net.ifnames=0. Možná tedy asi nepůjde přejmenovat eth0 na eth1 a eth1 na eth0, ale to bych si musel vyzkoušet.

[pavlix]

Nicnméně to neznamená, že po přechodu na udev nelze mít pojmenované net interfaces po staru stačí zadat parametr kernelu net.ifnames=0.

To záleží, jak definuješ po staru. Posledních mnoho let jsem používal mapování ethx podle MAC adresy, což je právě ta funkce, která byla odstraněna. Na některých distribucích včetně myslím Debianu a Ubuntu byla takováto funkcionalita dokonce zapnuta ve výchozí konfiguraci a mapování se trvale ukládalo. Na dalších distribucích bylo mapování mezi ethx a MAC adresou hojně využíváno na základě dokumentace.

Nemám zapotřebí se vyjadřovat k tomu, zda je to dobře nebo špatně. Ale fakta i dostupná dokumentace hovoří jasně. Funcionalita, o které se bavíme, byla odstraněna.

[little.owl]

Ano, to jsou prave body (a) a (b) z vami odkazane dokumentace:

In the meantime, during renaming, your target name might be taken by another driver, creating conflicts. Or the old name is taken directly after you renamed it -- then you get events for the same DEVPATH, before you even see the “move” event. It's just a mess, and nothing new should ever rely on kernel device renaming. Besides that, it's not even implemented now for other things than (driver-core wise very simple) network devices.

V podstate pokud mate vice NIC, mohou byt inicializovany v nahodnem poradi, i v dobe kdy uz se prejmenovava net device na jmeno ktere muze byt kernelem defaultne pridelovano (ethX) ve stejny cas, a je tu problem. Jak chapu, ze zmena chovani by vyzadovala zmeny v celem device driver modelu a hlavne v samotnych driverech, a do toho se nikomu nechce, zejmena kdyz je to problem predevsim u sitovek.

No a vyvojari udev-u, protoze spravne dosli k zaveru, ze oni s tim po letech omylu a chybovych reportu nic delat nemohou, a v situaci kdy mic je na strane vyvojaru kernelu, to vyresili vyjmutim souvisejiciho kodu a implementaci unikatnich jmen na ktera je mozne bezpecne prejmenovat (zadne ethX).

Vyjmuti je samozrejme sporne, mohlo by tam byt prechodne obdobi a tech placicich adminu by bylo o kapku mene.

[Pavel Stárek]

No, takže už se tedy nějak dopracováváme k výsledku, nicméně se zeptám ještě jednou, zápis tohoto pravidla v udevu

SUBSYSTEM=="net", DRIVERS=="?*", ENV{ID_NET_NAME_MAC}=="enx000296003faa", NAME="eth0"

bude fungovat, nebo nebude? Já si myslím že ano, ovšem myslet znamená houby vědět, že ano :) Nevím, kdy udev začne zpracovávat pravidla, jestli až se startem init ale kernel už si síťovky nějak pojmenoval, nebo může právě nastat situace, že kernel začne pojmenovávat a udev (systemd) taky.

[pavlix]

Dle FDO by to takové pravidlo obecně platit nemělo, citaci už jsem do diskuze posílal. Pokud se ti podaří prohodit eth0 a eth1, znamenalo by to, že zmíněná dokumentace již neplatí, aniž by to bylo jakkoli ohlášeno.

[Heron]

To už rovnou FreeBSD.

[----]

FreeBSD jsem používal a používal bych pořád, kdyby měl aspoň takovou podporu pro Optimus grafiky, jako Linux (tzn. něco jako Bumblebee) - bohužel nemá (musel by se portovat bbswitch a další věci)

Taky jsem přemýšlel nad spuštěním vlastního distra postaveného kolem jádra, musl libc, FreeBSD userlandu, Clangu a dalších komponent - asi to někdy začnu...

[lko]

cft tweet: https://twitter.com/freebsdhelp/status/334446070597812224

patch: https://github.com/nemysis/FreeBSD_Ports/tree/master/Call-for-Test/x11

Ten patch jsi uz zkousel?

[little.owl]

Tam je hlavni konflikt zajmu, kdy by o tom meli rozhodovat zamestnanci Canonical. Vzpominam si, ze Langasek obcas pouzival argumenty proti systemd, ktere budily dojem, ze se nepodival ani do man stranek, o kodu nemluve.

[Foo Bar]

Zajímavé je, že největši obavu o nezávislost Steva a Colina mají lidi, co Debian ani nepoužívají... natož aby byli Debian Developeři.

[little.owl]

V praci jsem ho a jeho klony nucen pouzivat.

Fakt je, ze tam je konflikt zajmu a jedina a standardne uzivana cesta v takovem pripade je vzdat se hlasovani, jinak nikdy nezabranite spekulacim. Nikdy.

Vcera jsem souvisejici thread debian-devel cetl a ty pochybnosti se tam objevily - a vy to vite sam neb se tam k tomu vyjadrujete, vectne zasahu velkeho tvurce stanov.

[Foo Bar]

Ale taky se tam mnohokráte objevilo (a nejenom ode mne), že Steve a Colin mají důvěru (včetně důvěru v to, že jsou soudní a sami se vzdají hlasování, pokud usoudí, že nejsou nestraní). A největší křiklouni (Uorti, Christoph[*], ...) nejsou členy Debian komunity.

Osobně souhlasím s Ianem spíš v tom, že pokud je tam konflikt zájmů, tak spíše vychází z toho, že Steve je maintainer balíčku upstart, než na základě toho, kdo mu každý měsíc posílá peníze na účet. Je dobře, že se o konfliktu zájmů "ví", ale osobně budu spokojený s libovolným výsledkem, který povede k adopci moderního init systému, neboť s každým dalším napsaným init skriptem v balíčku mám pocit zmaru nad vyhozeným časem. I když člověk používá nějaký standardní init.d skeleton, tak je to stejně na hlavu, když ví, že se to dá v deklarativním zápisu vyjádřit na maximálně pět řádek.

O.

* – C.A.M. má vůbec silný názor na všechno, báječně by se hodil do zdejších flamewars...

[Michal Vyskočil]

osobně budu spokojený s libovolným výsledkem, který povede k adopci moderního init systému

Není jeden z nich spíše debugger, který se shodou okolností tváří jako init systém?

[Foo Bar]

Já myslím, že ten blueprint docela pěkně popisuje problém i jeho řešení (cgroups), ne?

Nemyslím si, že se vybírá řešení, které by bylo dokonalé, ale řešení, které je v tuto chvíli nejlepší možné (pro Debian, pro správce Debian balíčků i pro Debian uživatele).

Ostatně ve chvíli, kdy se přejde na deklarativní způsob definování init skriptů, tak to docela usnadní případné další budoucí změny.

[Michal Vyskočil]

Já myslím, že ten blueprint docela pěkně popisuje problém i jeho řešení (cgroups), ne?

To rozhodně, ale o problémech, které způsobuje používání ptrace se ví prakticky od počátku upstartu a za uplynulých 7 let se na to nezměnilo nic. Pochopitelně tomu moc nepomáhá, že původní autor už v Canonicallu nepracuje. No a konkurence je na onom řešení (cgroups) postavena od počátku.

Nemyslím si, že se vybírá řešení, které by bylo dokonalé, ale řešení, které je v tuto chvíli nejlepší možné (pro Debian, pro správce Debian balíčků i pro Debian uživatele).

Pochopitelně a hlavně je potřeba, aby si Debian zvolil jeden init systém. Snažit se podporovat všechno možné je cesta do pekel - nikdo nemá tolik zdrojů, aby to mohl reálně dělat. Takže hodně štěstí s výběrem.

[pavlix]

To zní jako systemd byl kdovíjak čistý init systém, který nic jiného nedělá.

[Michal Vyskočil]

Pochybuji, že /sbin/systemd a /sbin/init (myšleno PID 1) se nějak fundamentálně liší a základní bloky (parsování deklarativního zápisu, řešení závislostí, nějaká kompatibilita se sysvinit, ...) tam budou imho více méně stejně. Rozdíly jsou až v navázaných službách.

[Jakub Lucký]

Rozdíly jsou až v nevyhnutelně navázaných službách.

[pavlix]

Pochybuji, že /sbin/systemd a /sbin/init (myšleno PID 1) se nějak fundamentálně liší a základní bloky (parsování deklarativního zápisu, řešení závislostí, nějaká kompatibilita se sysvinit, ...) tam budou imho více méně stejně.

Jakože například mezi /etc/inittab a kompletní konfigurací služeb v systemd není žádný zásadní rozdíl? O tom bych se rád nechal poučit. Ani poskytovaná API mi nepřijdou srovnatelná co do šíře ani metody přístupu.

[Michal Vyskočil]

A můžu já za to, že vývojáři upstart museli svoji binárku pojmenovat právě /sbin/init a matou tak nebohé čtenáře, jako třeba teď tebe? Jinak se omlouvám, věta měla být "a /sbin/init z upstartu (myšleno PID 1)".

[pavlix]

Jinak se omlouvám, věta měla být "a /sbin/init z upstartu (myšleno PID 1)".

To ovšem zásadně mění význam.

[little.owl]

Steve je maintainer balíčku upstart

A Colin Watson je vyvojar upstartu, navic clen Ubuntu Technical Board.

že pokud je tam konflikt zájmů

Pokud? Tam je konflikt zajmu podle jakekoliv definice, jakou jsem kdy videl.

Ale taky se tam mnohokráte objevilo (a nejenom ode mne), že Steve a Colin mají důvěru

Tam nejde jen o vyvojare, ale i o uzivatele. Pokud nepouziji systemd, uzivatele to nejspise brzo pociti, a jsem zvedav jak jim to pak obhaji, zejmena v kontextu vyse uvedeneho.

[kralyk z abclinuxu]

Já bych lidi, co rádi spekulují a vytvářejí konspirační teorie, nechal, ať si dělaj, do je baví. Těm se totiž stejně nezvaděčíš, ať už uděláš cokoli, takže je to jedno...

[little.owl]

V tomhle pripade jim to skoro nelze ulehcit vice.

[trekker.dk]

Skoro z toho mám pocit jako z našich voleb. Nejlepší možná varianta pro normální lidi bude, když se nedohodnou.

[martin]

to ty spis pripominas "typickeho" ceskeho volice...

[trekker.dk]

Tak to vážně ani náhodou...

[Petr Ježek]

Kdyby se kernel developers nedohodli, většina ze zdejšího fóra by ještě svá data přehazovala widlemi včetně mne. Nejlépe si sami velí ti, co se v úprku za svým cílem na nikoho a nic neohlížejí. Děkuji, nechci.

[Foo Bar]

Pane Hagara, co kdybyste laskavě přestal ve zprávičkách šířit FUD tohoto typu:

Minimálně dva její členové ale hrají významnou roli ve vývoji Ubuntu a jsou spoluzodpovědní za strategii Canonicalu. Je tedy nepravděpodobné, že by hlasovali proti Upstartu.

Colin i Steve jsou členy Debianu ještě déle než nějaký Canonical vůbec vznikl, a mnoho Debian vývojářů dalo najevo, že jim důvěřuje, že budou při rozhodování v tech-ctte hlasovat dle svého nejlepšího vědomí a svědomí.

Proto by nebylo od věci, kdybyste do zpráviček přestal vkládat hnus tohoto typu.

[Tutor]

Soudný člověk v záležitostech, kde hrozí střet zájmů, prostě nehlasuje. To je totéž, jako když politik přijímá nějaké rozhodnutí, ze kterého pak bude mít prospěch. I kdyby to bylo to nejlepší rozhodnutí na světě, je seriozní se hlasování neúčastnit, protože ty pochybnosti vyloučit nelze a nehlasování ničemu neškodí. To platí obecně.

Jinak je mi to buřt, protože nepoužívám ani Debian, ani bubuntu. Jen reaguji na nesmysl, že hlasovat o vlastním zájmu je transparentní a OK.

[Foo Bar]

Ale to je úplně jiné sdělení než:

Je tedy nepravděpodobné, že by hlasovali proti Upstartu.

Ne?

[Ladislav Hagara]

Jedná se o slova Lennarta Poetteringa, jak je ve zprávičce uvedeno: Do diskuse se zapojil i Lennart Poettering na Google+. Nevěnuje se pouze technickým otázkám (cgroup, kdbus, logind). Píše, ...

It is highly unlikely that they will vote against Upstart when it comes to it (I mean, how would they explain this to their space boss?).

[Foo Bar]

Ne, ve zprávičce to není uvedeno. Nebo neumíte pořádně označit citaci. A chcete říct, že jste zprávičku složil ze dvou vět a zbylých 80% je citace autora systemd? Ani nevím, o čem si mám myslet, že je horší.

[Ladislav Hagara]

Je to jenom zprávička. Ve zprávičce nelze použít formátování.

[egg]

Je tedy nepravděpodobné, že by hlasovali proti Upstartu.

Tohle ovšem není v rozporu se vzdáním se hlasování.

[kavol]

OT:

Jinak je mi to buřt, protože nepoužívám ani Debian, ani bubuntu.

pokud nepoužíváš wokna nebo mac apod., tak by ti to buřt bejt nemělo, neboť toto rozhodnutí ovlivní i jiná distra, bohužel

[Kaacz]

Nejakou malou mnozinu dister. protoze RH-like a suse-like distra uz na to presly.. debian/*buntu like je taky velka rodina .. uz toho moc nezbyva .. :)

[karel]

Tohle ale není žádná náboženská nebo politická debata. Tady je nutné to rozhodnutí pragmaticky stavět na základě argumentů. A kdo jiný bude mít relevantní argumenty než člověk, který daný systém zná. Pro nezaujaté hlasy bysme museli vyloučit všechny lidi co dělali s jedním nebo druhým systémem a nechat to na úplných laicích.

[AraxoN]

Z môjho pohľadu systemd rieši virtuálne problémy, ktoré nepociťujem. V procese ich riešenia vytvára collateral damage - nové problémy, ktoré sú reálne a ktoré sa ma už dotýkajú. Napríklad už spomínaná nemožnosť premenovať v Gentoo ethX na ethY a následný problém so spustením siete si u mňa vyžiadala služobnú cestu, dva dni v prdeli, noc strávenú v serverovni a stovky EUR. A preto čím menej systemd, tým lepšie.

[dustin]

K čemu je výhodné nemít možnost přejmenovat interface? Vždyť ta jména bývají natvrdo ve všemožných skriptech a když mi je udev při přehození síťovky přejmenuje, musím mít možnost to vrátit zpět. Nebo si chci prohodit síťovky. A nebo jsem to nepochopil :)

[little.owl]

(a) To ze problemy nepocitujete vy, neznamena ze je nepocituje nekdo jiny.

(b) Determiniticke pojmenovani interfacu ma smysl a pokud se vam to nelibi, mate asi jen ctyri moznosti jak to disablovat.

[AraxoN]

Prosím nevykať...

Keď niekto cíti potrebu používať systemd, tak nech si ho používa. Verím, že takí ľudia sú. Čomu nerozumiem je to, že keď sa niekde spomenie OpenRC alebo SysVInit, tak sa nikto nerozčuľuje. Ale keď sa v diskusii zjaví zaklínadlo "Systemd", tak je z toho hneď flamewar. Čím to asi je? Ukazuje to na kvality Systemd?

Inak deterministické pomenovanie interfejsov som mal aj predtým. Prvý iface dostal eth0, druhý eth1 a keď som niektorý vymenil, tak ten nový bol eth2 a mohol som si ho premenovať. Ale to bolo zjavne príliš málo zložité a príliš uncool, takže od udev-200 (plusmínus) táto možnosť už nie je. A prečo nie je? Lebo systemd to tak potreboval a udev je s ním v jednom monolite, takže preto.

[JohnDoe]

A prečo nie je? Lebo systemd to tak potreboval a udev je s ním v jednom monolite, takže preto

Sám seba klamať a presviedčať sa o nepravdách je určite jednoduchšie ako si zistiť relevantné fakty. Deterministické názvy si predtým nemal ani náhodou, pokiaľ si nepoužíval nejakú vlastnú schému pre pomenovanie rozhraní (stále možné používať aj teraz)

systemd funguje rovnako aj keď "Predictable Network Interface Naming" užívateľ zakáže. Argument "systemd to tak potreboval" je ničím nepodložený blábol.

Bolo by skvelé keby niektorí diskutujúci predtým ako "prispejú" k diskusii do-neba volajúcou hlúposťou aspoň trochu pochopili problematiku, o ktorej chcú viesť flamewar.

[AraxoN]

Predikovateľné, alebo nie, mne sa to chovalo deterministicky. Ja nevravím, že všetkému rozumiem. Ja vravím, že ten ich bazmek mi spôsobuje problémy aj keď ho nepoužívam. Možno sú jeho odporcovia príliš hlúpi na to, aby ocenili jeho nesporné prednosti, alebo aby ho dokázali používať bez rozbitia systému, alebo aby vôbec o ňom mohli diskutovať. Nadľudia zo Systemd by to mohli zobrať na vedomie a prestať sa snažiť svoj názor nasilu nacpať všade. V Tvojom vesmíre Ti možno pripadá, že hádžeš perly sviniam, ale ja o nich proste nestojím! V mojom vesmíre je Poettering Microsoftom a jeho Systemd je ako Windows8 - preč sú časy, keď si si mohol vybrať, už je len jedna položka.

[little.owl]

Predikovateľné, alebo nie, mne sa to chovalo deterministicky. J

Na boardu s TI DM8168 a dvema GMII ethernet porty mi to reprodukovatelne selhavalo, v podstate ze stejneho duvodu.

To ze vyvojari hledali v ramci moznosti reseni, ktere nepripomina ruskou ruletu a nezavisi na race conditions, kdyz kernel vytvari nove interfacy ve stejnou dobu, je krok spravnym smerem.

Udrzovat dlouhodobe vetev kodu, ktere je rozbita z pohledu designu je nesmysl.

[Michal Vyskočil]

Udrzovat dlouhodobe vetev kodu, ktere je rozbita z pohledu designu je nesmysl.

No, všichni zainteresovaní už tuší, že hlavní blbost byla myslet si, že omezení daná kernelem se dají obcházet v user space.

[little.owl]

Ano, a nezainteresovani vam budou tvrdojisne tvrdit jeste za deset let, ze tam zadny problem nikdy nebyl, nebot jim to vzdycky fungovalo.

[j]

Ono je dycky fajn rozbit funcionalitu, ktera chodi aspon nekomu, idealne tak, aby to nechodilo vubec nikomu, ze ... kuprikladu fakeraid ... od jadra 2.6.18 ... v pic... Takze pokud ma nekdo dualboot system, tak si muze strcit raid doprdele, nebot sw raid nepripoji ve widlich a fake raid prozmenu v tuxovi. Jo, pravda, muze si koupit za 10k+ HW radic.

[pavlix]

kuprikladu fakeraid ... od jadra 2.6.18 ... v pic...

Zdroj?

[j]

Ty neumis pouzit google? raid45 dmraid ...

[little.owl]

A nebyl dm-raid45 experimentalni feature, ktera padla za obet unifikaci? Viz zde.

[j]

Kdyz to rusili tak pindali, ze to prevedou na modul raid456 ... neni to dodnes. A je uplne jedno jak je co experimentalni ... hlavne ze se vsichni kolem tuxe chlubej, ze nerozbijej veci ... a hlavne ze ze resi, jak zachovat zjevne zabugovany chovani ... v nekterych pripadech ... a v jinych se pouzivana a funkcni vec proste rozbije bez nahrady.

[pavlix]

... a hlavne ze ze resi, jak zachovat zjevne zabugovany chovani ... v nekterych pripadech ...

To můžu z oblasti sítí potvrdit.

[pavlix]

Vidím, že se to skutečně už řešilo. Zajímavé je, že třeba u síťování spíše narážím na to, že se tvrdě brání i vyloženě chybné chování jádra jen pro zachování kompatibility.

Existuje nějaký rozumný zdroj ohledně současných jader a fakeraid ve smyslu co funguje, co nefunguje apod? To mi popravdě z googlu nevypadlo.

[little.owl]

Existuje nějaký rozumný zdroj ohledně současných jader a fakeraid ve smyslu co funguje, co nefunguje apod?

Ano. Nefunguje v podstate nic. Viz Ctrl+C/P odpoved zde.

[pavlix]

Hezké.

[little.owl]

idealne tak, aby to nechodilo vubec nikomu, ze

Jenze ono to chodi a lepsi mit jistotu, nez hrat ruletu.

To ze mate v aplikacich natvrdo zahackovane nazvy interfacu a horite na tom, ze soucasne reseni nemusi byt ve vsech pripadech zpetne kompatibilni, je jina vec.

Pak pouzivejte poradne distro, kde se tohle nemeni a pri prechodu na novejsi verzi provedte portaci aplikace.

To vy nedelate?

[j]

To by me fakt zajimalo, co ty pises do firewallu na misto i/o ethx ... fakt me zajima, co tam pises, specielne kdyz mas aspon 10+ stroju na ktery potrebujes dostat firewall ... a na kazdym se ti ponovu budou sitovky jmenovat jinak. Fakt uzasny ....

[pavlix]

To je prostě konflikt mezi pohledem vizionáře a pohledem praktika.

[little.owl]

Kazdych 10-15 mesicu rozbijim/designuji veci na novem projektu, nova generace, od navrhu po produkcni stabilizaci, takze koukam na veci z jineho pohledu a tyhle minoritni zmeny me rozhodne nevytaci.

[pavlix]

To by odpovídalo.

[little.owl]

Tigri bestie !

[little.owl]

Tak admini nasi cele divize se staraji asi o 1000 Linux desktopu, odhadem 22000 Win desktopu a strategie je jasna - limitovany pocet HW konfiguraci (cca 5) a remote deployment a maintenance pres nastroje co vse automatizuji.

[pc2005]

Udrzovat dlouhodobe vetev kodu, ktere je rozbita z pohledu designu je nesmysl.

To by se muselo z kernelu vyházet mnoho věcí mnohem dříve. Třeba v tty subsystému je stále (tedy podle nějakých Jadernych novin před pár lety) kompatibilita se starými bugy.

[pc2005]

alebo aby ho dokázali používať bez rozbitia systému, alebo aby vôbec o ňom mohli diskutovať.

No minimálně měli nastavit výchozí chování, které nerozbije současné konfigurace (byť možná plné hacků). Pořád se vyplatí víc, když vývojář stráví 100 hodin nad implementací kompatibility, než když pak musí 100 adminů strávit 1 hodinu offline rekonfigurací výdělečného stroje.

Nehledě na to, že si tím developeři škodí, protože [joke] admin, který musí pracovat na opravě konfigurace[/joke] si jejich software zrovna neoblíbí.

[pavlix]

Myslím, že systemd dokazuje, že negativní publicita se může vyplatit i v oblasti open source software. Lennart ji dokáže velmi dobře obrátit ve svůj prospěch.

[pc2005]

U mě ne.

[pavlix]

Parse error.

[David Jaša]

Spíš si předřečník o sobě myslí víc, než je. Tedy pokud se nepodílí na vývoji nebo prosazení konkurence systemd.

[pc2005]

prosazení konkurence systemd

Počítá se i používání osvědčeného původního systému?

Pokud někdo udělá z mého pohledu blobovitou aplikaci a snaží se jí různě protlačovat, tak rozhodně moje sympatie negativní publicitou nezíská.

[David Jaša]

Počítá se i používání osvědčeného původního systému?

Samozřejmě že ne. Počítá se údržba, vývoj a prosazování v distribucích. Pouhý uživatel se počítá tehdy, pokud si platí někoho, kdo za něj bude dělat alespoň jedno z těch tří výše.

[pc2005]

Jo aha tys myslel z pohledu vývojáře distribuce (který rozhoduje o začlenění/nahrazení původního systému). Já myslel obecně (z pohledu programátora) a v případě systemd z pohledu uživatele.

Žádno distribuci (kromě busyboxích) jsem nevyráběl, ani bych nechtěl, jsem spíš proti drobení linuxového světa.

[David Jaša]

Ne, já to myslel z pohledu celého linuxového ekosystému. I kdyby lennartovu propagandu nežral ani jeden admin na světě, ale zato by mu to sežrali i správci Gentoo, Ubuntu a Debianu, tak k čemu je v dalších releasech těm adminům dobré to, že propagandu nesežrali?

[pc2005]

Když bude dost naštvaných adminů a opravdu žádná použitelná jiná nebude, tak si založí vlastní distribuci. I já bych si v nejhorším případě založil vlastní (ideálně pomocí LFS). Doufám ale, že tato situace nikdy nenastane. Značilo by to mnohem závažnější problémy.

[pavlix]

Když bude dost naštvaných adminů a opravdu žádná použitelná jiná nebude, tak si založí vlastní distribuci.

Pokud se bude jejich naštvání projevovat jen plkáním v diskuzích tak dost těžko. Distribuce nerostou na stromech.

I já bych si v nejhorším případě založil vlastní (ideálně pomocí LFS).

To by byla jiná. Nicméně jestliže tě oslovuje LFS, tak se mnohem radši odpichoval od Gentoo s nějakým tím overlayem a profilem výchozích use flagů. Oproti LFS máš k dispozici spoustu základních toolů a nějaké ty lidi, se kterými se dá spolupracovat. Navíc není až takový problém, aby alternativní init zvládal i systemd service files, takže by neměl být problém utvořit nějaký kompromis mezi uživateli OpenRC, systemd a případně i jiné alternativy.

Já osobně ale předpokládám, že kdokoli za svoji hlavní náplň považuje správu počítačových systémů, si na nové nástroje prostě zvykne i s jejich nedostatky.

[pc2005]

Jo gentoo mám nainstalovaný ve virtuálu, jenom instalace ale trvala tak zhruba měsíc (pomalej ale speciální komp), takže se do kompilace čehokoliv většího (LibreOffice, Firefox, desktop, ...) moc nehrnu .

Nejspíše se ten systemd časem vyřeší (koneckonců i ve slackwaru byly věci jako hald). Já jsem ale spíše do embedded a tak mě je proti srsti, když projekty kumulují funkčnost ostatních programů a ještě rozbijí třeba zpětnou kompatibilitu. Stejně tak mám rád věci jako KISS (proto to s tím statickým initem).

[pavlix]

Jo gentoo mám nainstalovaný ve virtuálu, jenom instalace ale trvala tak zhruba měsíc (pomalej ale speciální komp), takže se do kompilace čehokoliv většího (LibreOffice, Firefox, desktop, ...) moc nehrnu .

Používal jsem to dosud jen na x86, takže jsem měl vždy možnost provést kompilaci na rychlém stroji i kdyby to nebyl ten, kde to budu následně provozovat. Na speciální pomalé stroje pak spíše vycházejí lépe nástroje typu OpenEmbedded ;).

Stejně tak mám rád věci jako KISS (proto to s tím statickým initem).

Problém je v tom, že KISS dost záleží na úhlu pohledu. Někdy prostě člověk musí volit mezi jednoduchostí užití a primitivností implementace. Já jsem třeba vždy dával přednost start/stop/enable/disable před editací /etc/rc.conf.

Pokud jde o statické linkování základních toolů, tak to je fakt pod moji rozlišovací úroveň. Buď je systém v pořádku, pak nic neřeším, nebo je systém nějak zásadně rozbitý, pak ale musím být vždy připravený i na to, že nenabootuje. Jistě existují případy mezi tím, ale já osobně dávám přednost řešením, co pokryjí co nejširší škálu takových situací, ať už je to live systém z externího média nebo třeba rescue initramfs image.

[pc2005]

Používal jsem to dosud jen na x86,

To já v tom virtuálu taky, jen mám jenom pomalý hw (a nový požadovaných parametrů jsem nenašel).

Jistě existují případy mezi tím, ale já osobně dávám přednost řešením, co pokryjí co nejširší škálu takových situací, ať už je to live systém z externího média nebo třeba rescue initramfs image.

Pokud to není třeba router.

[pavlix]

Pokud to není třeba router.

Nevidím důvod router vyčleňovat, snad jen že u něj je to ještě jednodušší, pokud mu připravíš na míru image a upgraduješ ho jako celek a nikoli po balíčcích.

[little.owl]

To já v tom virtuálu taky, jen mám jenom pomalý hw (a nový požadovaných parametrů jsem nenašel).

Co vas brzdi na novem HW?

[pc2005]

No ta "stará" má 1xLPT, 4xCOM, 3x1G ethernet, wifi, 1xPCI, 1xPCIe a VGA. To vše ve formátu mini ITX. Nová deska se hledá těžko (navíc bych už nešel do Intelu).

[David Jaša]

Když bude dost naštvaných adminů a opravdu žádná použitelná jiná nebude, tak si založí vlastní distribuci.

Buď, nebo se zapojí do správcování jejich oblíbené (tedy pokud to její politika umožňuje). A v té chvíli už dotyčný dělá něco z toho, co jsem jmenoval výš, a tudíž se stává relevantním v F/OSS komunitě.

[little.owl]

OK, tahle myslenkova konstrukce dava smysl, beru ji za svou, doufam ze na to nemate copyright.

[pavlix]

Přidávám se :).

[David Jaša]

Jen jsem v tomhle vlákně trochu rozvedl slovo meritokracie.

[j]

Boze, dalsi kterej plka kraviny ...

Deterministky sem si pojmenoval sitovku podle MAC adresy, to uz ten NELZE a muzes se postavit trebas nahlavu a odstrkovat usima, ale sitovku na eth0 neprejmenujes, ani kdyby ses posral. Prislusny kus kodu byl prave v udev 200 odstranen. A odstranen byl prave v souvislosti s integraci do ty systemd sracky.

A nelze to proto, ze ethx bylo prohlaseno za prostor jadra ... takze jadro sice sitovkam umi dal dat ethx, ale neni mozne to zafixovat na tu mac adresu => muze se to naprosto kdykoli zmenit. Ano, byl to mozna "hnusny hack", ale fungovalo to a pouziva to 99,999% vsech uzivatelu. A vazne nevim, proc bych kvuli nejakymu blbovi mel prepisovat vsechny konfiguraky v systemu a firewall + resit, ze hromada appek nic jinyho nez ethx na pozici sitovky jednoduse neakceptuje a netusi, co ze by to jako enp0s3 melo byt.

[lnykryn]

Ve fedoře síťovku pořád přejmenovat jde. Stačí jen v ifcfg změnit DEVICE a /usr/lib/udev/rules.d/60-net.rules ji jméno změní. Nefunguje jen přehození jmen.

[j]

A proc myslis ze se to pouzivalo proboha ... system s jednou sitovkou je naprosto nezajimavej, ty da jadro dycky eth0.

[Pavel Stárek]

Já nevím, ale podle mne, by sis měl asi nejprve přečíst nějakou tu dokomentaci a pak si napsat udev pravidlo:

SUBSYSTEM=="net", DRIVERS=="?*", ENV{ID_NET_NAME_MAC}=="enx000296003faa", NAME:="eth0"

Popřípadě to celé vypnout pomocí net.ifnames=0 a biosedvname=0 zadané jak parametr kernelu.

Jinak v té dokumentaci ( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) se píše:

3. You alter the default policy file, for picking a different naming scheme, for example for naming all interface names after their MAC address by default: cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules, then edit the file there and change the lines as necessary.

[Václav Vanc]

Tohle nefunguje ve chvíli, kdy je tam těch síťovek víc (vlastní zkušenost). Dřív to fungovalo, ale bylo to z UDEVu odebráno

[j]

Jak bylo receno, kdyby sis tu dokumentaci precet ty, tak bys trebas vedel ze to od udev 200 NEFUNGUJE. Kdyby to fungovalo, nebyly by po netu desetitisice postu na tema "upgradnul sem a nenajela mi sit". S vypnutim tech zhuverilych nazvu to absolutne nijak nesouvisi.

[Pavel Stárek]

Co kua nefunguje? Ještě jednou a naposled, jde napsat takovéhle pravidlo:

SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_MAC}=="enxc80aa9429d76", NAME="eth0"

Kde MAC adresa je c8:0a:a9:42:9d:76.

[pavlix]

To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[trekker.dk]

The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed.

A tohle se vážně někomu stalo? (A nebo spíš - a bylo jich tolik, aby to ospravedlnilo rozbití sítě všem ostatním?)

[pavlix]

O tom nemám bohužel informace.

[trekker.dk]

Tak to byla spíš otázka do pléna, zejména směrem k příznivcům systemd.

[pavlix]

Popravdě řečeno si dokážu představit, že Lennart dostal do ruky bug report, který na něco takového ukazoval a rozhodl se to do budoucna vyřešit tím, že tu funkcionalitu zablokuje. Ale stejnětak je možné, že viděl pouhou možnost, že ten race nastane. A Lennart je příznivcem jednoduchých řešení, tedy těch, se kterými má nejméně práce.

Nicméně se jedná o regresi (ztrátu funkcionality), takže přirozená reakce distribucí by měla být blokace nové verze systemd (distribuční QA) a následná příprava a údržba patche (distribuční vývoj) nebo vyřešení problému s upstreamem.

Jestliže se distribuce s touto změnou (na úkor zachování stávající funkcionality) smířily, lze to brát jako potvrzení, že upstream jedná správně.

[kralyk z abclinuxu]

Jakou regresi máš na mysli?

[trekker.dk]

Jestliže se distribuce s touto změnou (na úkor zachování stávající funkcionality) smířily, lze to brát jako potvrzení, že upstream jedná správně.

... to spíš jako potvrzení, že jsou to pitomci.

[kralyk z abclinuxu]

Nevím o tom, že by se skutečně stala nějaká chyba, ale před tou změnou 'Predictable Network Interface Names' bylo u mě na laptopu bežné, že síťovky měly při každém bootu jména přidělena náhodně - ie. ethernet byl buď eth0, nebo eth1 a wifina to druhé.

Řešilo se to udev pravidlem, IIRC úplně stejným jako dnes.

[Pavel Stárek]

Nu což, nevím jak v Gentoo, ale ve Fedoře to vypnout jde, dokonce jde nejspíš zachovat si udev pravidla pro přejmenování pomocí MAC adres. A ať jsem včera studoval changelogy udevu mezi 197 (kde to prý ještě jelo) a 200 (kde to prý už nejde) jak chtěl, tak jsem se nic takového nedozvěděl, že by nemohlo jít přejmenovávat síťová rozhraní na základě udev pravidel. A odkaz na Lennartovo povídání kde vysvětluje proč něco z udevu odstranil mi (pokud tady v diskuzi je) asi nějak unikl.

[little.owl]

Ano, stava se to a je to hlavne otazka jak je inicializovan HW.

Pokud jsou sitova karty detekovany v rychlem zavesu za sebou a navic v nahodnem poradi, jde do toho lehce spadnout. Drive, s ohledem na rychlost enumerace PCI zarizeni to asi nebyl tak velky problem, ale ted je tlak na rychly boot a dostava se to i tam. Druha vec - a tady nevim - je virtualizovane prostredi - tam ten "HW" asi take muze nabehnout velmi rychle - netusim, jestli by to mohl byt problem i tam.

U embedded veci se s tim muselo pocitat, uboot treba inicialiloval sitovky, nastavil MAC adresy, pak se sekundarni vyradily a po inicializaci kernelu postupne zapisem nekam do HW registru aktivovaly, jinak to mohla byt ruleta.

[pc2005]

Děsná škoda, že nejsou ethernet device dostupná jako soubor (třeba ve formě MAC názvu) v /dev/. To by si pak každej mohl udělat symlink na co by chtěl a šlo by psát servery přímo v shellu (bez použití nc nebo toho "hacku" v bashi).

[pavlix]

Hledáš jak složitě udělat to, co se dosud řešilo jednoduše? Typický server nepotřebuje se síťovým rozhraním nijak komunikovat. Je dobré se seznámit se systémovým síťovým API než člověk začne vymýšlet nesmysly.

Server si v shellu můžeš napsat triviálně a na jeho zprovoznění stačí nakonfigurovat inetd, xinetd nebo dneska i systemd, stačí si vybrat.

[pc2005]

Samozřejmě dneska by to byla neefektivní práce na víc, to bylo spíš povzdechnutí nad unixovským heslem: "všechno je soubor". Plan 9 si ale kvůli tomu instalovat nebudu .

Server si v shellu můžeš napsat triviálně a na jeho zprovoznění stačí nakonfigurovat

Pokud ovšem bude jedna z mých třech síťovek vůbec přístupná . BTW v bashi nepotřebuju ani jedno, tam stačí ">/dev/tcp/www.google.com/80". Hmm doufám, že systemd nekanibalizuje i bash .

[pavlix]

Samozřejmě dneska by to byla neefektivní práce na víc

Nikoliv. Ten koncept, že bude aplikace používat síťové API prostřednictvím síťových rozhraní (a nikoliv síťová rozhraní prostřednictvím síťového API), je sám o sobě nesmyslný.

to bylo spíš povzdechnutí nad unixovským heslem: "všechno je soubor".

Mám dojem, že Linux tento koncept ještě zdokonalil, jestliže i polling nad filedeskriptory je realizován filedeskriptorem a stejně tak lze filedeskriptorem přistupovat k signálům a timerům.

Pokud ovšem bude jedna z mých třech síťovek vůbec přístupná .

Pokud ne, tak nepomůže ani svěcená voda.

BTW v bashi nepotřebuju ani jedno, tam stačí ">/dev/tcp/www.google.com/80".

To je to, o čem jsem psal výše. Jenže tady jsi trochu vedle, ledaže bys mi ukázal, jak na /dev/tcp postavit server.

[pc2005]

ad všechno je soubor: On Linux kdysi /dev/eth0 málem podporoval, ale umřelo to na nezájem. Použití /dev/ethX by bylo mnohem blíž čtení zápisu do souboru než třeba požadavek na mmap buffery u /dev/video0 V4L zařízení. Koneckonců ethernet je taky jen stream dat. Některé netradiční způsoby připojení pak používají /dev zařízení bezproblémů.

Pokud ne, tak nepomůže ani svěcená voda.

Proč? Vždycky můžu přece zapojit jeden ve čtyř sériáků a ovládat z terminálu .

ledaže bys mi ukázal, jak na /dev/tcp postavit server.

Jo bash umí jen klient socket. Ale je to příklad použití "souboru" (IMHO dost hack) pro komunikaci po síti (konkrétně na TCP/IP úrovni).

[pavlix]

ad všechno je soubor: On Linux kdysi /dev/eth0 málem podporoval, ale umřelo to na nezájem.

To se nedivím. Přímá práce se síťovým rozhraním je pro aplikace jednak neužitečná a jednak nebezpečná, tudíž přístupná jen dostatečně privilegovaným aplikacím.

Koneckonců ethernet je taky jen stream dat.

Není. A i kdybys ho prezentoval jako stream dat (stream ethernetových rámců), platí, co jsem psal výše o neužitečnosti a nebezpečnosti.

Jo bash umí jen klient socket.

Ale to vůbec není vlastnost bashe.

Ale je to příklad použití "souboru" (IMHO dost hack) pro komunikaci po síti (konkrétně na TCP/IP úrovni).

Mimochodem volání `socket()` taky vrací file deskriptor, tedy starý dobrý unixovský soubor, jen bez cesty.

[pc2005]

Přímá práce se síťovým rozhraním je pro aplikace jednak neužitečná a jednak nebezpečná, tudíž přístupná jen dostatečně privilegovaným aplikacím.

A /dev/mem ti nevadí?

Ale to vůbec není vlastnost bashe.

Přiznám se, že jsem na servery používal vždycky netcat, takže jak je přesně /dev/tcp implementovaný nevím, ale vím, že existuje.

Ale to už se bavíme hodně mimo téma. Mě šlo o velmi triviální mechanismus definice jmen rozhranní, kde by jednak aplikace byla nucena implementovat libovolné jméno (a ne natvrdo ethX) a konfigurace by byla triviální. Prostě něco jako by-id/by-path/by-uuid v /dev/ (konfigurace přejmenování v udevu se sice taky zdá triviální, ale očividně to má své mouchy).

[pavlix]

A /dev/mem ti nevadí?

$ cat /dev/mem
cat: /dev/mem: Permission denied

Nevadí. A nejsem si vědom toho, že by bylo určeno pro aplikační software.

Přiznám se, že jsem na servery používal vždycky netcat, takže jak je přesně /dev/tcp implementovaný nevím, ale vím, že existuje.

Jak můžeš obdivovat, že je na unixech všechno soubor a přitom si myslet, že ten soubor poskytuje bash? Vždyť by to byl úplně pitomý návrh. Filesystémy poskytuje jádro.

Mě šlo o velmi triviální mechanismus definice jmen rozhranní, kde by jednak aplikace byla nucena implementovat libovolné jméno (a ne natvrdo ethX)

Aplikace se jména síťových rozhraní netýkají, pokud se nejedná speciálně o nějaký konfigurační software nebo něco hodně spraseného, co se snaží obejít kernelové síťové prostředky.

a konfigurace by byla triviální. Prostě něco jako by-id/by-path/by-uuid v /dev/

Takhle to řeší třeba NetworkManager, kde máš možnost vázat konfiguraci na MAC adresu nebo na jméno rozhraní. Symlinkový přístup by v tomto případě mohl dávat smysl, síťová rozhraní ve filesystému už jsou, zkus:

$ ls /sys/class/net

Jen je podle mě blbost si myslet, že nejlepší síťové API udělám tak, že budou běžné aplikace psát přímo do Ethernetu.

(konfigurace přejmenování v udevu se sice taky zdá triviální, ale očividně to má své mouchy).

Hlavní moucha je to, že se udev a kernel přetahují místo aby spolupracovaly. Pak by totiž žádné kernelové pojmenování nemuselo v případě spuštěného udevu existovat a nedocházelo by k žádné kolizi. Ale to už si myslím půjčuju slova dejva.

[Lol Phirae]

Takhle to řeší třeba NetworkManager

Pomoooooooooc!!! Už nééééééééé!

[pavlix]

Co kdybysis šel hrát na píseček ;).

[Lol Phirae]

No, a nebo kdyby si tam šli hrát Lennart a spol., místo naprosto zcestného kurvení fungujících a masově používaných věcí?! Krucifix, já nechci žádný NM ani jiné univerzální kurvítko na serverech!!!

[little.owl]

Zalezi na scenari pouziti, ne?

[Lol Phirae]

A on to snad Lennart rozjebal jen na desktopu? :-P

[little.owl]

Mel jsem na mysli NM, tam mohou byt scenare, kdy jeho pouziti na serveru muze mit smysl; o tom by ale mohl rici vice pavlix.

[pavlix]

Jedna věc je stěžovat si na problémy způsobené druhými lidmi, jiná věc je držet si seznam klíčových slov, pod které v diskuzi budu psát infantilní komentáře.

[little.owl]

nebo něco hodně spraseného, co se snaží obejít kernelové síťové prostředky.

A nebo neco, co se snazi obejit 'spraseny' network stack.

[pavlix]

V tomhle případě (aplikační software) si to nemyslím, ale jestli máš nějaké jiné informace, nechám se poučit.

[little.owl]

Delal jsem pred rokem a pul uvodni prototyping AVB stacku na Linuxu, pouzival jsem zpocatku raw sockets, ale kvuli performace jsem nakonec psal kod nad net_device a sk_buff (a nakonec modifikoval i driver) a tak presunul cast aplikace do jadra. Hlavni duvod byl, ze kdyz load cpu dosahl cca 80%, nebyl jsem schopen zpracovat packety vcas, vznikaly nepredikovatelne lagy a cela synchronizace se mi rozpadala.

[pavlix]

To je jiná, i od Michala Zimy (WrapSix) o rozdílech v rychlosti low-level síťování něco málo vím, a tam se dokonce jednalo o propustnost, ne latenci. Jenže ty, jak sám píšeš, jsi skončil nakonec až na úrovni driveru a se specializovanou aplikací, která skutečně staví nad Ethernetem, nikoli nad TCP/IP.

[pc2005]

Nevadí. A nejsem si vědom toho, že by bylo určeno pro aplikační software.

/dev/ethX by nemuselo být taky. Klidně by mohl být /dev soubor pro každou vrstvu ethernetu. Jinak já si přes /dev/mem napsal pseudo driver v bashi .

že ten soubor poskytuje bash

Já si ale nemyslím, že ten soubor poskytuje bash. Hlavně protože ls /dev/tcp/ neexistuje. Protože se mě nechce zbytečně zkoumat dokumentaci/zdrojáky bashe, tak usuzuju, že bash má ty syntaxi přesměrování výstupu nahackovanou (takže se dá říct, že to připojení zápisem do "souboru" poskytuje bash - samozřejmě jen v bashovským skriptu).

ls /sys/class/net

Vím, ale do tuny konfigurací stejně musím psát ethX (nebo to iptables - i třeba v busyboxu - umi?).

Jen je podle mě blbost si myslet, že nejlepší síťové API udělám tak, že budou běžné aplikace psát přímo do Ethernetu.

To jsem nikde nepsal. Nehledě na to, že původní moje reakce byla hlavně povzdech nad tím, že nejde napsat server přímo v čistém bashi. Zhruba stejně jako lze používat v bashi i pojmenovanou rouru.

Hlavní moucha je to, že se udev a kernel přetahují místo aby spolupracovaly.

Souhlas, pokud by šlo nějak zajistit, aby se síťové rozhraní pojmenovalo nějak inteligentně a deterministicky, tak by mě bylo naprosto jedno zda to dělá kernel nebo udev.

[pavlix]

/dev/ethX by nemuselo být taky. Klidně by mohl být /dev soubor pro každou vrstvu ethernetu. Jinak já si přes /dev/mem napsal pseudo driver v bashi .

Nápadů je spousta. Otázka je zda by to bylo vůbec užitečné.

Protože se mě nechce zbytečně zkoumat dokumentaci/zdrojáky bashe, tak usuzuju, že bash má ty syntaxi přesměrování výstupu nahackovanou (takže se dá říct, že to připojení zápisem do "souboru" poskytuje bash - samozřejmě jen v bashovským skriptu).

Ano, bash nabízí prostředky pro přístup k souborům. Jak překvapivé.

Vím, ale do tuny konfigurací stejně musím psát ethX (nebo to iptables - i třeba v busyboxu - umi?).

Nemám tušení, na co se ptáš. A busybox bych do toho vůbec netahal.

Souhlas, pokud by šlo nějak zajistit, aby se síťové rozhraní pojmenovalo nějak inteligentně a deterministicky, tak by mě bylo naprosto jedno zda to dělá kernel nebo udev.

Nebo ve spolupráci. Udev by mohl dostat šanci rozhraní pojmenovat namísto kernelu.

[pavlix]

K tomu bashi a /dev/tcp viz níže.

[marbu]

Jak můžeš obdivovat, že je na unixech všechno soubor a přitom si myslet, že ten soubor poskytuje bash?

Ale ono ten /dev/tcp vážně řeší přmo bash. Viz man bash:

       Bash  handles several filenames specially when they are used in redi-
       rections, as described in the following table:

              /dev/fd/fd
                     If fd is a valid integer, file descriptor fd is  dupli-
                     cated.
              /dev/stdin
                     File descriptor 0 is duplicated.
              /dev/stdout
                     File descriptor 1 is duplicated.
              /dev/stderr
                     File descriptor 2 is duplicated.
              /dev/tcp/host/port
                     If  host  is  a valid hostname or Internet address, and
                     port is an integer port number or  service  name,  bash
                     attempts  to open a TCP connection to the corresponding
                     socket.
              /dev/udp/host/port
                     If host is a valid hostname or  Internet  address,  and
                     port  is  an  integer port number or service name, bash
                     attempts to open a UDP connection to the  corresponding
                     socket.

       A failure to open or create a file causes the redirection to fail.

     

[pavlix]

A jo. Díky za upozornění, to zásadně mění situaci. A vzhledem k resolvingu je to vlastně i celkem logické, mělo mě to napadnout.

[lertimir]

To mě vysvětlilo, proč jsem na žádném systému několika různými distribucemi v ls -a /dev žádné /dev/tcp neviděl.

[pavlix]

Nic proti, ale než začnu kopat kolem sebe a udělám ze sebe hlupáka, tak si aspoň přečtu co ostatní píšou a co na to dokument číslo jedna o nedávných změnách v pojmenovávání síťových rozhraní pomocí systemd-udevd (viz výše).

[j]

Nevis o cem pises, jde "nepouzivat" tuhle debilitu, ale nejde rict sitovce, ze se ma jmenovat eth0, viz vejs. A prave TO je ten problem. A muze za to prave ten posratej systemd.

[Michal]

Momentalne mam pred sebou cistu instalaciu Fedory 19 (minimal install, vmware virtual) a sietovku som v pohode premenoval na eth0 z povodneho mena ens33.

[chrono]

Ak by tam boli dve sieťové karty, tak sa eth1 nedá premenovať na eth0 (aj keď sa to predtým urobiť dalo).

[Václav Vanc]

+1

[jyrki]

s Linuxem jsem byl spokojen prakticky až do doby systemd. Poslední problém který jsem potkal, particie zapsaná ve fstab a nastavená jako automaticky připojovaná při startu zmizela (odpojený externí disk). Linux se systemd se na tom totálně zasekl, neustále opakoval jednu chybovou hlášku dokola, nebral žádný vstup z klávesnice a v tu chvíli ještě nebyl spuštěný sshd. Musel jsem PC vypnout, nabootovat z CD, připojit systémovou particii, smazat particií která dělala problém z fstab. Pak vše naběhlo ok. Wtf? Tohle chování jsem s žádným jiným initem nepotkal.

[j]

To je prece ta uzasna ficura - system dal jasne najevo, ze mu neco chybi, jinak by sis trebas ani nevsim ... ;D.

[jyrki]

kdyby zastavil boot nebo nabootoval do konzole a pockal na input uzivatele, ok. Ale takhle? Z Linuxu se stava stejna sracka jako jsou Windows, je velka skoda ze FreeBSD ma tak slabou hardware podporu...

[j]

jj, stema widlema naprostej souhlas, tam taky jeste v XP stacilo zmenit textak a zmenilo se poradi/cekani/... bootu, od vist vejs uz je na to treba binarni tool ... tomu se rika pokrok. Takze kdyz se neco posere, tak misto zmeny jednoduchyho textaku musi clovek resit, jak funguje ta kkokotina, a resit, kde ten disk pripoji k jinejm widlim, protoze z placky jako live nabootovat neumej ...

Systemd je presne stejnej shit ... dtto grub vs grub2 ... clovek si udela jednoduchou malou partisnu aby se k tomu snadno dostal kdyz se neco podela ... a pak zjisti, ze je mu to khownu, protoze na to potrebuje jeste 100MB tools, aby to spravil, pristup do / ...

[Honza Jaroš]

Ehm... Takže po sto desáté:

Grub2 může mít taky jednoduchý konfigurák. Ta hromada toolů nedělá nic jiného, než že vám vytvoří jeden grub.cfg, který se nechá editovat stejně jako předtím. Minimalistická verze grub.cfg nemusí být o mnoho delší než v případě Grubu 0.x. Samozřejmě pak je třeba nějak domluvit distribuci, aby vám do toho nehrabala, ale to už není problém Grubu...

Jinak se zbytkem souhlas.

[Honza Jaroš]

PS: jeden drobný, ale hezký příklad je tady na konci stránky.

[jyrki]

tak zrovna s grub2 nevidim zadny problem

[pavlix]

Není nad to se pořádně ztrapnit (narážím na neinformovanost ohledně grub2).

[j]

Neni nad to psat picoviny ...

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

Ale jiste, muzu si prepsat pulku distribuce a editovat si to rucne ... a modlit se, ze pri nejaky aktualizaci se to nerozjebne ...

[Honza Jaroš]

A to jako v debianím grub.conf, pokud si nainstalujete grub-legacy (nevím, jestli ve Wheezym ještě je, ale šestkový Debian určitě umožňoval instalaci obou verzí), nic podobného nemáte? Tam se přece grub.conf také generuje automaticky. A brání vám to nějak soubor grub.cfg ručně upravit pomocí jakéhokoli textového editoru v případě havárie, jak jste naznačoval výše?

[pavlix]

Takže zatímco při GRUB1 je potřeba bránit se různým distribučním skriptům, při GRUB2 si můžeš vybrat jestli hledat distribuční skript nebo zablokovat jen grub-mkconfig (popřípadě grub2-mkconfig), což funguje všude. Rovněž se do značné míry omezily distribuční odlišnosti při generování konfigurace. Z tohoto pohledu je GRUB2 obrovské zlepšení, které nevidí jen ti, kteří se rozhodli, že správně jsou jenom ty věci, které byly když oni začali používat Linux.

[j]

Vis co? Radsi uz nic nepis, kdyz ja zacinal s tuxem, tak na tebe zjevne vasi jeste nezadelali ... protoze tehdy zadnej grub neexistoval. Proti lilu pak byl grub nepochybne zlepseni, minimalne nebylo treba pri zmene konfigurace prepisovat MBR.

[pavlix]

Škoda, že jsi jen anonymní srab.

[j]

Skoda ze ses mladej utrinos.

[kralyk z abclinuxu]

Jenže on má pravdu,

You can choose to automatically generate or manually edit grub.cfg. [odtud]

Jestli máš nějaký distro, kde není možné automatické generování grub.cfg zakázat, tak je to chyba toho distra, ne GRUBu.

Přijde mi, že se tady v diskusi akorát snažíš aktivně najít problémy tam, kde nejsou.

(PS. osobně taky používám grub legacy, ale jen proto, že jsem línej přejít na syslinux...)

[Honza Jaroš]

A stále žádná odpověď na otázku, v čem se liší v případě havárie ruční editace grub.cfg od původní ruční editace grub.conf či menu.lst. Místo toho jen osobní útoky. Zvláštní...

[j]

Zeby v tom, ze ty scripty ho obratem prepisou? Zeby v tom, ze syntax je desna? Mel bys asi navstivit ustav ve svym bydlisti.

[Jendа]

Zeby v tom, ze ty scripty ho obratem prepisou?

Jaké skripty?

Zeby v tom, ze syntax je desna?

menuentry 'Debian' {
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        linux   /vmlinuz
        initrd  /initrd
}

Co je na tom děsného?

Mel bys asi navstivit ustav ve svym bydlisti.

S tímto ústavem spolupracuji (HW prototyping a taky jsem byl v kontrolní zdravé skupině na pokusy), nicméně o GRUBu jsme se ještě nikdy nebavili.

[little.owl]

Ja to tu za vas vyresim . Grub2 je rubbish. Radsi primy UEFI boot [a treba gummiboot].

[pc2005]

S tímto ústavem spolupracuji (HW prototyping a taky jsem byl v kontrolní zdravé skupině na pokusy), nicméně o GRUBu jsme se ještě nikdy nebavili.

Teď nevím, jestli jsem to vlákno pochopil, ale brmlab (?) už dělá pokusy na nemocných skupinách? :-O

[Jendа]

Ne, tohle naprosto nesouvisí s brmlabem. Je to projekt PL Bohnice, ČVUT a budoucího NUDZ (btw. budou tam mít MEG!!!) ohledně výzkumu schizofrenie. Cílem bylo hrát multiplayer Pong ve fMRI skeneru.

[pc2005]

btw. budou tam mít MEG!!!

WOW

Cílem bylo hrát multiplayer Pong ve fMRI skeneru.

To by mě zajímalo jak se schizofrenie projeví na hraní pongu :-O (no možná radši ani ne )

NUDZ

Vtipně zvolené jméno .

[Jendа]

To by mě zajímalo jak se schizofrenie projeví na hraní pongu :-O (no možná radši ani ne )

Jde o to, že chvíli ovládáš hru ty a chvíli někdo jiný (a náhodně se přepíná řízení). Schizofrenici mají problém odlišit, kdy je něco z jejich vůle a kdy z vůle někoho jiného (proto slyší hlasy, ovládají je ufoni a tak…).

[pc2005]

Aha ono se multiplexovalo mezi hráči, tak to jo. Ale stejně bych si nezahrál, mě by to chvíli trvalo detekovat .

[Honza Jaroš]

Zeby v tom, ze ty scripty ho obratem prepisou?

To ovšem není problém Grubu, nýbrž vámi používané distribuce. Takže si to vyřiďte s jejími správci. Moje distribuce, ze které teď píšu, to například nedělá.

Zeby v tom, ze syntax je desna?

Už jsem sem ten odkaz dával, přímé srovnání máte na konci stránky zde. Samozřejmě, pokud chcete používat pokročilejší vlastnosti, které původní Grub neměl, je zápis složitější.

Mel bys asi navstivit ustav ve svym bydlisti.

A vy byste měl trošku ubrat, chováte se jako hulvát.

[Jendа]

Mohl bys mi prosím vysvětlit, jak datum narození souvisí s platností podložených argumentů a formální správností vyvozených závěrů? Vídám to docela často a nechápu to. Protože jsem jeden z těch později narozených, myslím, že se mě to týká taky a tak bych to o to víc rád věděl.

A taky by mě zajímalo, jak souvisí LILO s GRUBem v této diskuzi.

(jo a jinak pavlix má rok narození v profilu, za domácí úkol ho můžeš porovnat s rokem, ve kterém byl oznámen kernel)

[Honza Jaroš]

Mohl bys mi prosím vysvětlit, jak datum narození souvisí s platností podložených argumentů a formální správností vyvozených závěrů?

Nijak. Jen to je hůl, která se hodí když dojdou argumenty.

[little.owl]

Mozna zkusenosti a ty se nekdy spatne sdeluji.

[Honza Jaroš]

V tomto případě bych řekl, že pavlix i Jenda mají zkušeností víc...

(což mimochodem píšu z pozice počítačového veterána, který má taky nějakou tu desítku let odslouženou)

[pavlix]

V tomto případě bych řekl, že pavlix i Jenda mají zkušeností víc...

To je na těchhle argumentech to nejsmutnější.

[Jendа]

Aha, takže od „grub2 je sračka“ jsme se dostali k tomu, že tvoje distribuce je sračka. S tím už se dá souhlasit. Doufám, že příště už na GRUB2 nadávat nebudeš.

[Honza Jaroš]

No pokud se jedná o Debian, tak bude problém spíš mezi klávesnicí a židlí:

If you configured /boot/grub/custom.cfg, there is no need to run update-grub; the file will be automatically loaded by /boot/grub/grub.conf at boot.

[nyan]

No me naposled nasralo, kdyz nejakej idiot v archlinuxu se rozhodl dat do "unit" file jedne sluzby natvrdo optiony, misto toho aby cetl konfigurak z /etc. Uzasny "prechod" na systemd, fakt.

[Michal Vyskočil]

Asi ten idiot počítal s tím, že kdo chce měnit konfiguraci, jednoduše to udělá v /etc/systemd/system/služba.service.d/vlastní.conf

[Michal]

ExecStart nie je mozne "prepisovat", systemd chape ExecStart= vramci .conf ako dalsi vyskyt tejto konfiguracnej volby, ale volbu ExecStart mozu mat viackrat uvedenu iba sluzby typu oneshot. U vsetkych ostatnych typov je to chyba a systemd odmietne danu sluzbu spustit.

[pc0]

Asi ten idiot počítal s tím, že kdo chce měnit konfiguraci, jednoduše to udělá v /etc/systemd/system/služba.service.d/vlastní.conf

To byl sarkasmus ? Pokud ne, tak si radsi si bez dat sprchu.
To je fakt lahudka, kdyz nejaka aplikace ma v koreni /etc konfigurak kterej je ignorovanej, protoze nekde hluboko v stromu systemd je ten "pravej". Zmeny v puvodnim se neprojevujou a nastava tak detektivni patrani po pricine. Jeste ze je uz systemd podezrelej od pohledu a vetsinou se zjisti, ze je i na vine.

[little.owl]

Mam pocit ze michate nekolik veci dohromady. Prvni je konfigurace pouzita pro spusteni daemona, druha je konfigurace daemona, a treti je pokulhavajici migrace/integrace nekterych dister.

Zatim vetsina problemu, na ktere jsem narazil, odhlednuli od obcasnych bugu, pramenila z neznalosti systemd - dokumentace je najednou trochu moc, tech novych veci take a chova se to jinak..

[pavlix]

Zatim vetsina problemu, na ktere jsem narazil, odhlednuli od obcasnych bugu, pramenila z neznalosti systemd - dokumentace je najednou trochu moc, tech novych veci take a chova se to jinak..

Dokumentace je co do množství hodně, ale nepokrývá mnohé velmi důležité věci.

[little.owl]

Dokumentace je co do množství hodně, ale nepokrývá mnohé velmi důležité věci.

Tak na nektere veci jsem koukal do kodu, ale neslo o nic, co by trapilo bezneho uzivatele. S ohledem na stav cele rady projektu, je dokumentace systemd velmi dobra, jen bych to vyhodil z blogu.

Nepise se uz dokumentace k RHEL7?

[pavlix]

Tak na nektere veci jsem koukal do kodu, ale neslo o nic, co by trapilo bezneho uzivatele.

Běžný uživatel nepotřebuje dokumentaci k systemd.

[vlastikroot]

Bezny uzivatel nepotrebuje systemd.

[nyan]

Prectete si pls znovu co jsem napsal v puvodnim komentari. Ten balik v /etc zadnej soubor krome /etc/default/<sluzba> nevlastni (a ten soubor je ignorovan).

[pavlix]

Odkaz na bug report?

[vlastikroot]

Ja treba pouzival archlinux i kvuli jednoduchemu init systemu nastavitelnemu v /etc/rc.conf. Kdyz tohle odstranili, prestal me archlinux zajimat. To samy absence pouzitelneho instalatoru (ten posledni i predposledni byli super, nechapu proc to rozbili a zbavili se toho). Kdyz nekdo udela neco dobre, nemuze se to tak nechat, musi se to rozbit a predelat na neco horsiho. Jo, archlinux ma porad neco do sebe, ale uz ne to co mel pred cca 3 roky.

[coques]

Ja treba pouzival archlinux i kvuli jednoduchemu init systemu nastavitelnemu v /etc/rc.conf.

+1

Arch bol v tomto jedinečný a preto bol tak obľúbený. Obávam sa, že zlaté časy Linuxu už navždy skončili.

[pavlix]

V tom případě snad stačí si vybrat nějaký méně úspěšný unixový OS, ne?

[little.owl]

Obávam sa, že zlaté časy Linuxu už navždy skončili.

Oh, yes, the days of wooden ships and iron men.

[coques]

little.owl & pavlix

chlapci na vás nemá zmysel reagovať, vidíte to proste inak, ja vám to neberiem, ale hodne mi pripomínate 'vynálezcu systemd' v šírení vašej pravdy. Proste nie aby to niekto videl inak!

[pavlix]

Trochu toho matroše bych od tebe rád koupil.

[coques]

Ešte chýba komentár od little.owl, aj ten má odpoveď na všetko.

[pavlix]

Rád se dozvím, co ti tedy vadí na šíření „mé pravdy“, tedy šíření mých výhrad vůči kvalitě, vývoji a komunikaci projektu jménem systemd? Bylo by lepší, kdybych ten projekt začal chválit?

[little.owl]

vidíte to proste inak, ja vám to neberiem,

To by byla nuda, pokud bychom si tu jen notovali.

ale hodne mi pripomínate 'vynálezcu systemd' v šírení vašej pravdy.

No fuj.

[coques]

ale hodne mi pripomínate 'vynálezcu systemd' v šírení vašej pravdy.

No fuj.

Možno to nieje s tebou až tak zlé ako som si myslel :)

[Václav "Darm" Novák]

Pokud si dobře vzpomínám, člověk co vyvíjel a udržoval instalátor s tím přestal a není nikdo, kdo by ho zastoupil. Zbytku komunity ty instalační skripty nijak zvlášť nevadí.

[vlastikroot]

OMG to je mi teda pristup. Nekdo se s tim pise a oni misto toho, aby opravili pri rozbiti chybu (stylem menime tohle chovani, opravime i instalator), radsi to vyhodi jako nefunkcni vec. A ten systemd je to samy. Nerikam, ze je spatny, jen je to overkill na jinak tak jednoduchou distribuci. Kdysi stacil jeden konfigurak, ted je jich 1000 poschovavanych kdesi po FS. Pouzival jsem archlinux kvuli jednoduchosti a pruhlednosti (nainstil jsem system z pameti za 20 minut se vsim vsudy), tohle je uz asi pryc.

[kralyk z abclinuxu]

Arch je zcela komunitní projekt. O co není zájem / na co nejsou lidi, to se prostě nevyvíjí. Má to své klady, má to své nevýhody...

[vlastikroot]

I komunitni projekt muze byt tak jakoze konzervativni a drzet se celkove nejakych cilu. Vim, ze arch se snazil byt edge distribuci. Pokud ale nasazeni jedne veci zpusobi rozbiti druhe, tyhle veci se planuji dopredu a meli by byt trosku externe (na arch wiki je hromada ruznych nestandardnich konfiguraci, navod je lepsi nez default). Ja mel arch vzdy vsude, k domacim i pracovnim ucelum (nebal jsem se mit tak i server), dokonce jsem to instaloval lidem. Ted je pro me ale sprava hromady arch stroju neunosna, proto to nahrazuji xubuntama (ubuntu je kategorie sama pro sebe, tam neni co resit). Ale kde si chci byt jisty, mam debian. Desim se toho, ze do debianu narvou defaultne nejakou prasarnu.

[Kaacz]

Mně tak trochu děsí to, že se do serverové distribuce začíná infiltrovat hnůj z desktopů...

[pc0]

Jj, NetworkManager, D-Bus, Pulse Audio a de facto i systemd jsou pomsty desktopu serveru a facka promyslenym systemovym resenim :-/

[Václav "Darm" Novák]

Tak minimálně PA je dost mimo místo. Na kolika serverech je potřeba zvuk?

[pavlix]

facka promyslenym systemovym resenim :-/

Kterým?

[Michal Vyskočil]

No přece ifup/ifdown skriptům, ne? Jednoduché, přehledné, funkční ...

[pavlix]

;)

[Xerces]

Tak jsem to tu pročetl a jako dlouholetému uživateli Debianu je mi nějak mdlo P8r výkřiku do diskuze. Pokud jsou tedy pochybnosti o kvalitách upstartu a systemd a sysvinit se jeví špatně udržovatelný, což místo náhrady sysvinit prostě zrušit Ve finále se tady kočkujeme ale poslední slovo musí mít stejně ti, kteří se s tím dnes a denně perou a to jsou správci balíčků.

[jyrki]

osobne jsem byl nejvice spokojeny s OpenRC. Skoda ze neni pro kazde distro projekt jako je openrc4arch. A je zajimave ze privrzenci systemd ted nervou ze je treba freedom of choice, coz je oblibeny argument pro pocet distribuci, desktop prostredi a vubec vseho...

[Václav "Darm" Novák]

Freedom of choice stále beru, ale jsem zcela spokojen se systemd, takže nemám důvod řvát.

[Rezza]

Systemd lidi jsou prave proti tomu freedom of choice. Integraci ma delat systemd, vsude stejny system, distribuce maji jen distribuovat balicky a nic vic.

[little.owl]

A ten jeden integrujici kernel pod diktatorem Linusem vam nevadi?

[pavlix]

Gentoo a Debian svorně dokazují nesmyslnost této otázky.

[little.owl]

A debianni statistika uzivani portu a architektur (hurd, freebsd), mimochodem uvedena nahore, zas nesmyslnost tve odpovedi. Pokud bych to bral takto, pak na poli s pid1 neni vlastne zadny problem, nebot nepredpokladam, ze systemd bude mit nekdy vice nez 99%.

[David Jaša]

Nicméně tak tvá otázka nestála. Tedy GNU & friends userland nad kfreebsd nebo hurdem jde, a pokud se nepletu, tak patche do něj opravující problematická místa přijímány jsou (tedy pokud se nenacházejí ve zdrojovém stromě systemd). Oproti tomu systemd je účelově psán jako funkční monolit, jehož jedna část se nahrazuje jinou účelově blbě, přestože k tomu není technicky žádný důvod (viz logind, journald a další přidruženosti, které JeSpr init nutně nepotřebuje a naopak ony nutně nepotřebují JeSpr init). Přijde mi, že Lennart & spol si tak zajišťují práci na desetiletí dopředu, zneužívaje při tom toleranci zaměstnavatele k popírání toho, na čem vyrostl.

[David Jaša]

Chce se mi dodat - ona asi přijde doba, kdy se systemd bude modularizovat do té míry, že jednotlivé části onoho funkčního monolitu budou použitelné samostatně, nahraditelné a reimplementovatelné, protože se vyvrbí nějaké nepřekonatelné omezení současného kódu. A čim později to nastane, tím hůř se budou ty Lennartovy (& spol.) špagety rozplétat.

[little.owl]

ona asi přijde doba, kdy se systemd bude modularizovat do té míry, že jednotlivé části onoho funkčního monolitu budou použitelné samostatně, nahraditelné a reimplementovatelné,

Jiste, ale to bude v dobe az nebudeme resit, zdali systemd, sysv, openrc nebo upstart, nybrz jak vylepsit systemd, ktery uz beha vsude. Do te doby budou nejspise veci psane tak, aby nesly vykuchat, s nestabilnimi vnitrnimi interfacy, protoze proste neni zajem to ostatnim ulehcit, ostatne Lennartuv prispevek to rika.

To neni nic noveho, meli jsme tu Unix war a potom valku free OS v devadesatych letech, kde ucelove treba zametly pod podlahu jakekoliv snahu unifikovat driver model, s pristupem Linuse, ze vyvojari *BSD jsou vetsinou idioti, kterymi se nenecha omezovat, ale nakonec jsme vsichni tezili z vitezneho Linuxu do ktereho se vyplatilo firmam investovat.

Unifikovany init system je dalsi krok a take se casem vyplati.

[Jakub Lucký]

Já myslím, že principiální problém s unifikací nebude tak velký, jako problém s unifikací v tento moment se současnou nabídkou. Až se objeví systém s rozumnou modularitou a nastavitelností, přiměřeně se chovajícím správcem, rozumným rozhodovacím procesem vývoje, přiměřenou možností kombinovat ho s exotikou a všemi těmi vychytávkami, po kterých prahnou maintaineři, tak to pojďme sjednotit. Ale to v současné nabídce skutečně nemáme...

[little.owl]

To je jak cekani na blahoslaveneho spasitele.

[Jakub Lucký]

Asi budu radši čekat, než se svěřit zrovna Lennartovi s jeho přístupem...

[pavlix]

Někdy je lepší na spasitele čekat, než ho mít ;).

[little.owl]

Nerouhej se a maz se uctive omluvit sv. Lennartovi za pochybovani.

[j]

Jestli ma byt zrovna on spasitelem, tak naprosto souhlasim se zidama, ukrizovani je jediny spravny reseni.

[pc2005]

+1 !

[little.owl]

Jadro me argumentace bylo jine.

Jak Linux kernel, tak systemd, z hlediska sve pozice a podpory velkymi hraci, limituji v praxi volbu uzivatele.

Pokud nejste spokojen s Linux kernelem, nemate rozumnou alternativu, u jinych kernelu ani kolikrat nenabootujete na novem HW.

U systemd dochazi k necemu podobnemu take.

Ja ted nerikam, jestli je to dobre nebo spatne, tech pohledu je vice, ale ze neni mozne kritizovat z teto pozice jeden projekt a druhy nikoliv.

Přijde mi, že Lennart & spol si tak zajišťují práci na desetiletí dopředu, zneužívaje při tom toleranci zaměstnavatele k popírání toho, na čem vyrostl.

S tim bych souhlasil.

Nicmene pochybuji, ze Red Hat ma zajem podporovat Canonical.

[David Jaša]

Jadro me argumentace bylo jine.

Já to chápu, nicméně mi to přijde jako zcela nesouvisející věc.

Nicmene pochybuji, ze Red Hat ma zajem podporovat Canonical.

Nechápu souvislost.

[pavlix]

A debianni statistika uzivani portu a architektur (hurd, freebsd), mimochodem uvedena nahore, zas nesmyslnost tve odpovedi.

Podle mě statistiky ukazují, že lze vyměnit jádro za jiné a co víc, dokonce to i někdo dělá a není k tomu potřeba vyměnit hromadu dalších klíčových komponent. O nějakém bránění v možnosti volby tudíž nemůže být řeč.

[little.owl]

Jadro lze vymenit, ale o tom nebyla prece rec, ta byla o svobodne volbe a jejim omezeni. Ty statistiky jasne ukazuji, ze pro vetsinu uzivatelu to neni alternativa - a list proc je sakra dlouhy - pak moznost volby v praxi je jen zdanliva.

[pc2005]

Tak i jedno procento je důležité.

[little.owl]

Kde by ho vzali?

[pc2005]

Jako, že není 1% ze všech non linux ale OSS uživatelů? Tak to je jedno, klidně 0.1%.

[pavlix]

Uniká mi, proč si pleteš statistiku s možností volby.

[little.owl]

Nepletu.

[Ivan]

Kernel se porad jeste drzi Posix-u. Vyvoj probiha evolucne a ne revolucne. A (alespon jak se zda) rozhodovani se nedelaji za zavrenymi dvermi. Kernel se snazi byt zpetne kompatibilni. Linus ma preci jenom lepsi komunikacni schopnosti.

[little.owl]

Vyvoj probiha evolucne a ne revolucne

To u systemd ted jiz take, revoluce byla kdyz prisel.

A rozhodovani se nedelaji za zavrenymi dvermi.

To si nemyslim. Velky vliv ma ten, kdo plati vyvojare, ostatne jako i u systemd (i kdyz tady ...).

Kernel se snazi byt zpetne kompatibilni.

Systemd take.

S predchozimi verzemi systemd.

Linus ma preci jenom lepsi komunikacni schopnosti.

Ano.

Nicmene to vse nemeni nic na faktu, ze v praxi mate Linux a pak dlouho nic, takze s tim svobodnym vyberem to take neni slavne.

[dustin]

To u systemd ted jiz take, revoluce byla kdyz prisel.

Obvykle argumentuješ věcně, tak proč tohle? Pro všechny, kdo systemd ještě nepoužívají (což např. na stávajících serverech skoro všude), to bude revoluce (tedy boj), evoluce možná až za pár let.

[little.owl]

OK, to jsem nevzal potaz, pro uzivatele kteri si zili ve skleniku a najednou jim po updatu spadl do klina systemd, to je i dnes revoluce. Nicmene od [profesionalniho] admistratora bych predpokladal, ze bude sledovat vyvoj a pak uz nebude zaskocen, systemd je jiz tri roky stara zalezitost.

[j]

1) 3 roky nejsou v profesionalnim IT vubec nic - to je tak alfa stadium vyvoje. 2) profesionalni admin je konzervativni - proto zasadne neinstaluje nikam nic, co neni aspon 5let provereny (= ve znacnym rozsahu pouzivany). Pokud mu distribuce neco takovyho vnucuje, casto v ramci sandardni aktualizace, tak to bere tak, ze ta distribuce prestava byt pouzitena - na naprosto cokoli.

=> nainstalovat si tuhle hruzu na provozni system muze leda silenec.

[little.owl]

To je otazka spolehlivosti, a tady s vami celkem souhlasim.

RHEL7 prijde snad nekdy pristi rok, osobne bych to nepouzil na kriticke veci pred 7.1+, a jsme u peti let od uvedeni systemd, pro dalsi je tu stale podporovany RHEL5/6.

Cast adminu v City, u firem pouzivajicich RHEL, ma na testovacich strojich i Fedoru, takze nebudou uplne nepolibeni. A cast z nich to vidi pozitivne - pokud to tedy Red Hat vychyta, prusvih to nebude.

[jyrki]

ja to nemyslel na vyvojare systemd, ale uzivatele, kteri vzdycky krici a zastavaji se kazdeho projektu, ale v podobe systemd sklonili hlavu a prijali jej

[trekker.dk]

ale poslední slovo musí mít stejně ti, kteří se s tím dnes a denně perou a to jsou správci balíčků.

Uživatele ignorovat?

[Foo Bar]

Pokud nebudou žádní správci balíčků, tak nebudou ani žádní uživatelé...

Kromě toho se zeptám, kolik si myslíte, že je uživatelů, kterým záleží na tom, jaký vlastně distribuce používá init systém. Osobně si myslím, že použití procent v odpovědi bude overkill, a lepší bude používat malá přirozená čísla.

[pc2005]

správci balíčků

Počítají se do toho i autoři ebuild (a podobných) skriptů?

[trekker.dk]

No tak pokud vím, tak uživatelé Debianu jsou stále z větší části správci serverů. A to bych byl opravdu opatrný tvrdit, že jim na výsledku téhle hurá akce nezáleží...

[dustin]

Přesně tak, sakra moc mě zajímá, kolik mi dá práce upgradovat servery na nový debian a s jakými riziky. Spoustu lidí se dnes na linux kouká optikou hracího desktopu...

[Václav HFechs Švirga]

+1

[tomvec]

Tolik těm init-záležitostem nerozumím, ale zeptám se. V Debianu Sid je spousta adresářů a souborů se systemd v názvu (/etc/systemd, /lib/systemd, /var/lib/systemd... To je ten systemd o kterém se tu dohadujete, jestli v Debianu bude on nebo upstart?

[Jakub Lucký]

Debatuje se ten, který bude jako default, který se bude upřednostňovat a masivně testovat...