Výsledky hlasování o init systému v Debianu

Debian zveřejnil výsledky hlasování o způsobu integrace init systémů v Debianu. V hlasování zvítězila možnost označovaná jako "General Resolution is not required".
Výsledkem hlasování je tedy prohlášení, že hlasování nebylo zapotřebí, a výzva k tomu, aby by se celoprojektové hlasování (GR) používalo citlivě, a ujištění o tom, že standardní procedury v Debianu fungují tak, jak mají.
(Detailní výsledky)

19.11.2014 12:33 | Foo Bar | Zajímavý článek

Komentáře

[pavlix]

Tak snad se vody uklidní ;).

[lqw]

Jackson je mozna dobry hacker a idealista, ale mizerny politik. Jinak by mu asi doslo, ze vyvojari teda spic balici si nevypusti rybnik a nebudou si sami pridelavat praci povinnym udrzovanim podpory pro ostatni inity. Zvlast kdyz system hlasovani v Debianu je preferencni a uvedomele masivni hlasovani pro jednu volbu je neobvykle. Ale zkusil to a podle me se uz na to vykasle.

Ze skodolibosti bych jim to i pral, stejne jako volicum kterym se jejich politik pak smeje do xichtu ;)

[Foo Bar]

Opravdu nerozumím, jak Váš příspěvek reflektuje výsledek GR, který říká - my se s tím popereme sami standardními mechanismy, a není potřeba, aby na to byl nějaký předpis zhůry.

[pita]

Pokud vim tak standardni rozhodnuti TC o initu negarantovalo ze maji baliky fungovat se vsemi inity a vice mene to bylo na libovuli spravce. GR to melo zakotvit jako podminku. GR samo sebe odmitlo, plati puvodni rozhodnuti TC. Jinymi slovy podpora ne-systemd initu je dobrovolna.

[little.owl]

Pokud vim tak standardni rozhodnuti TC o initu negarantovalo ze maji baliky fungovat se vsemi inity

To ale nemuze z principu garantovat zadne rozhodnuti TC ci GR, nebot oni nemohou diktovat jak si bude upstream vyvijet SW.

GR to melo zakotvit jako podminku.

GR melo rozhodnou o navrzich.

GR samo sebe odmitlo,

GR rozhodlo.

Jinymi slovy podpora ne-systemd initu je dobrovolna.

Cela prace na Debianu je dobrovolna.

[pita]

To ale nemuze z principu garantovat zadne rozhodnuti TC ci GR, nebot oni nemohou diktovat jak si bude upstream vyvijet SW.

O diktovani upstreamu pisu kde ?? TC nebo GR muze rozhodnout, ze se nebude uprednostnovat jeden init ale budou se podporovat vsechny, kde to bude mozne. Prectete si Jacksonuv navrh kde ty vyjimky uvadi, at tu neplacate nesmysly.

GR melo rozhodnou o navrzich.

Navrhy 1 a 3 mely zakotvit priority pro maintainery. Opakovat banalitu ze GR melo rozhodnout prinasi do debaty informacni hodnotu rovnou nule.

GR rozhodlo.

… ze neni potreba (General Resolution is not required). Jinymi slovy poprelo svuj duvod.

Cela prace na Debianu je dobrovolna.

To jsou dneska perly … Nezbyva nez odkazat na navrhy, ktere mely Debianni vyvojare k necemu zavazovat.

[little.owl]

O diktovani upstreamu pisu kde ?? TC nebo GR muze rozhodnout, ze se nebude uprednostnovat jeden init ale budou se podporovat vsechny, kde to bude mozne. Prectete si Jacksonuv navrh kde ty vyjimky uvadi, at tu neplacate nesmysly.

Nerikam, ze neco pisete o diktovani. Pointa je v tom, ze zadna garance neni z principu [bez podpory upstreamu] temer mozna, napriklad bez degradace funkcionality. O uprednostnovani jste take nemluvil, ale to ze se preferuje defaultni init system, je celkem pochopitelne.

Navrhy 1 a 3 mely zakotvit priority pro maintainery.

Tyto navrhy mozna, ale nikoliv GR, nema skutecne smysl predjimat co by GR melo.

Jinymi slovy poprelo svuj duvod.

Ne. Prectete si cele rozhodnuti, je to presne jak pise Ondrej Sury:

General Resolution is not required

The Debian project asks its members to be considerate when proposing General Resolutions, as the GR process may be disruptive regardless of the outcome of the vote.

Regarding the subject of this ballot, the Project affirms that the procedures for decision making and conflict resolution are working adequately and thus a General Resolution is not required.

Jinak: pokud rozhodnou, ze v danem pripade neni treba zadne rozhodnuti na dane urovni, nepopira to vlastni mechanismus rozhodovani a ani existenci problemu.

Prvni odstavec stoji za zamysleni take.

[pita]

Ale to je snad jasne ze byla myslena garance v ramci konkretniho navrhu GR, o kterem se tu debatuje. Absolutni garanci tu jen umele fabrikujete.

Opet. Rec byla o konkretnim GR init system coupling, jehoz vysledkem ze v tomhle pripade neni jeho pouziti zadouci. O zadnem zpochybnovani institutu GR nepadlo ani slovo.

[little.owl]

S garancemi jste zacal u TC, nicmene je to skutecne jedno: nikdo vam je dnes uz realne do budoucna dat nemuze, v Linuxu je standard systemd.

Musi stacit jen to, ze Debian ze vsech mainstreamovych linuxovych binarnich distribuci udelal zatim nejvice proto, aby si uzivatel mohl vybrat init. Do jake miry a jak dlouho je to udrzitelne, ukaze cas a plno faktoru stoji mimo ne.

[Foo Bar]

A já měl pocit, že z výsledků toho hlasování jde docela jasně vidět, že žádná masivní bouře (ani ve sklenici vody) nebyla...

Myslím, že se pořád zapomíná na to, že Debian není jedno tělo jedno duše jako jsou komerční (nebo malé) distribuce, a že "Projekt Debian" není entita a nemůže mít vlastní názor.

[x]

Tezko, ale to neni podstatne. Jsou tady dulezitejsi veci na opravu v Linux svete :D

[pavlix]

Ti budou mít ale dost práce.

[pavlix]

Zvláště když se v linuxovém síťovém stacku neopravují ani zjevné chyby, s odůvodněním, že by to čistě teoreticky mohlo rozbít něco v userspace.

[x]

No proto mi to prave prijde hodne zabavne. Facebook ma dojem (jako mnoho firem), ze staci dostatek penez a lidi a nejakym zazrakem se to zacne navrhovat poradne

[Atom321]

Asi jsem nějak méně chápající, ale stále mi uniká jedna zcela zásadní informace: Bude Debian Jessie fungovat i s jiným initem než systemd, nebo nebude?

[JoHnY3]

No, ted mi funguje bez systemd, ale pouzivam minimalistickou konfiguraci s par balikama pro LAMP, na desktopu to muze byt trochu jinak.

[Foo Bar]

apt-get install sysvinit-core

[trekker.dk]

Možná si pod tím pojmem představujeme něco jiného, ale já měl za to, že "fungovat" v dotazu předřečníka znamená nejenom, jestli půjde nainstalovat SysV init, ale jestli s tím taky budou fungovat programy. Osobně by mě to zajímalo taky - ze současných informací mám pocit, že to bude záviset na náladě správce toho kterého balíku, jestli se mu bude nebo nebude chtít dělat podporu pro různé init systémy.

[j]

Mas nohy? Tak hlasuj. Az klesne uzivatelska zakladna na tisicinu, tak se bude s velkym divenim se resit, proc.

[Frack]

Většině uživatelů je IMHO jedno, jestli Debian používá SystemV nebo systemd. Ti, kteří z toho dělají svatou válku, je relativně málo.

[j]

Vetsina lidi vyzaduje funkcni system, coz systemd naprosto neumoznuje provozovat. Opravdu nehodlam resit veci na tema "a jak si kua ted prectu ten binarni blob" ... "a co stim kua, kdyz to nefunguje". Coz v pripade scriptu umi kazdy admin lusknutim prstu byt treba provizorne poresit.

[kralyk z abclinuxu]

To je furt dokola.

Přepiš si posímtě httpd do bashe, protože jinak by se ti mohlo stát, že přestane fungovat, a co potom s tím binárním blobem?

[...]

neni.

ja od debianu odesel pred koncem podpory woodyho, kdyz se projevilo precisleni puvodni komunity vyvojaru lidmi z ubuntu.

stalo me to 1TB dat u gentoo.

a linux uz pro me existuje jen odsud-posud profesne.

[kralyk z abclinuxu]

Cool story, bro...

[trekker.dk]

Přepiš si posímtě httpd do bashe, protože jinak by se ti mohlo stát, že přestane fungovat, a co potom s tím binárním blobem?

Tohle je taky furt dokola. A furt je to blábol - jak už tady určitě padlo, když nejede http, na ten server se dostanu a můžu to řešit. Když nenabootuje a nástroje, se kterými se to dá řešit, jsou přístupné až po nabootování, tak mám smolíka. Cat a less jsou všude.

[kralyk z abclinuxu]

Tak v tom případě si budeš do bashe muset přepsat už i grub.

[Václav HFechs Švirga]

Hlavně interpret bashe musí byt v bashi!

[Frack]

Vetsina lidi vyzaduje funkcni system, coz systemd naprosto neumoznuje provozovat.

Oprostěte od těchto silných tvrzení, prosím. Provozuji systemd na hromadě produkčních serverů (CentOS 7) a nemám pocit, že by to nebyly funkční systémy. Podobná prohlášení jen dokazují, že to není válka argumentů, ale opravdu jen válka víry, což vždycky vedlo jen do...

[...]

ne je to jina doba. dnesni admin linuxu = have you tried to turn it off and on? really? have you tried to reinstall it?

[Frack]

To je částečně pravda, ostatně IT se neustále nafukuje, potřeba kvalifikovaných lidí narůstá a Gaussova křivka je neúprosná, takže tlak na zjednodušování je očividný a vzhledem k omezeným lidským zdrojům asi i nevyhnutelný, nicméně mi přijde dost nefér považovat ty, pro které se svět nezboří, když nespravují systémy zrovna se svým oblíbeným initem, za nekompetentní adminy. systemd dnes běží na tisících produkčních serverů a svět opravdu nezačal kolabovat, takže opravdu neplatí, že funkční systém se s ním opravdu nedá provozovat. No a pak je to otázka profesionality naučit se, co je potřeba.

[pavlix]

nicméně mi přijde dost nefér považovat ty, pro které se svět nezboří, když nespravují systémy zrovna se svým oblíbeným initem, za nekompetentní adminy

+1

Ono je to spíše naopak, flexibilita se na trhu práce cení.

[JS1]

Ono nejde ani tak o to, ze by nebylo dost kompetentnich lidi, spis je otazka, proc dal delat rucne neco, co se podarilo zautomatizovat?

[...]

proc provozovat do nekonecna zautomatizovany chybovy stav, ktery nevyhovuje zakaznikum, ale vyhovuje manazerovi do doby nez dostane z vyssich pozic poter co prijde z obchodniho skrz podil na mizernych obchodnich vysledcich, kdyz to muzu jednorazove opravit.

[little.owl]

A kdyz se to nenauci, nauci se to nejaky Ind v Bangalore pracujici za tretinovou cenu ...

[Heron]

Nechce se mi hledat diskusi o journald a binárním logování, ale zjistil jsem, že mi

journalctl --list-boots

neukazuje všechny starty. Nejmladší boot byl podle tohoto výpisu pár měsíců v minulosti.

Dále jsem zjistil, že:

journalctl -F _BOOTS_ID

Jich vypisuje mnohem víc (patrně všechny).

Potom jsem našel úžasný příkaz:

journalctl --verify

a nestačil se divit. Velmi oceňuji, že journalctl používá barvičky a že se mi monitor krásně začervenal. Více než polovina logů byla vadná. A to za situace, kdy je stroj za UPS, k výpadku napájení stejně nedošlo, HW nikdy nehavaroval, OS nikdy nespadl, dokonce ani nikdo nikdy nezmáčkl reset (protože ani není připojený) a FS je zcela v pořádku.

Takže journald kurví vlastní logy sám od sebe a zkurvené logy nejsou dostupné pomocí funkcí journalctl. Pochopitelně neexistuje ani funkce --repair k onomu --verify.

Pomůže ty vadné soubory smazat a potom už journalctl funguje dle očekávání.

Tolik tedy k binárním logům. Jak asi dopadne čtení logů po nějaké HW havárii, když za běžného stavu je 50% vadných?

[trekker.dk]

Tys to pořád ještě nepochopil, tohle je pokrok a cesta kupředu. Jakým směrem? To je fuk, ale hlavně že dopředu.

[Heron]

Já jsem to pochopil už dávno, ale vzhledem k tomu, že se systemd v produkci nevyhnu (zatím se to úspěšně odkládá, ale za rok, dva, ten RHEL 7 prostě nasadíme), tak už skoro rok systemd provozuju doma, v bezpečném prostředí, kde o nic nejde, a nestačím se divit.

Tohle není ani betaverze. Na co sáhnu, to nefunguje. systemctl nefunguje, journalctl nefunguje.

Jako, vážně, tohle mít nasazené v produkci a ve tři ráno na pohotovosti zjistit, že ani nemám logy a tedy ani nevím, co a proč se stalo (címž se potom poněkud komplikuje řešení)? Jak tohle může někdo provozovat?

Před nedávnem jsem řešil problém s časem (chci mít RTC čas v UTC, měl jsem to tak roky), čas byl o hodinu mimo. Problém byl samozřejmně v systemd-timedated, který zcela ignoroval běžící ntpd. Asi netřeba připomínat, že jsem nikdy systemd-timedated neinstaloval, pravděpodobně se tam dostal nějakým partizánským způsobem při update systemd.

[David Jaša]

V RHEL 7 jsou journalí logy defaultně volatilní, na perzistentní logy je tam furt rsyslog. Když smažeš /var/log/journal, tak v journalctl uvidíš akorát věci z aktuálního bootu a můžeš se chovat, jako kdyby tam žádný journald ani nebyl.

BTW co nefunguje v systemctl? Zatím stále používám service, tak mi asi něco uniklo. :)

Před nedávnem jsem řešil problém s časem (chci mít RTC čas v UTC, měl jsem to tak roky), čas byl o hodinu mimo. Problém byl samozřejmně v systemd-timedated, který zcela ignoroval běžící ntpd. Asi netřeba připomínat, že jsem nikdy systemd-timedated neinstaloval, pravděpodobně se tam dostal nějakým partizánským způsobem při update systemd.

To je defaultní konfigurace. Spíš by mě zajímalo, jak se ti ji povedlo rozbít...

[Heron]

co nefunguje v systemctl

Pořádně nefunguje systemctl enable (jako ekvivalent k chkconfig on), tedy zařazení služby se startu při bootu (ano, není to přesný ekvivalent, ale toto by fungovat mělo).

To je defaultní konfigurace.

Co je defaultní konfigurace?

[pavlix]

Pořádně nefunguje systemctl enable (jako ekvivalent k chkconfig on), tedy zařazení služby se startu při bootu (ano, není to přesný ekvivalent, ale toto by fungovat mělo).

Zdaleka to není přesný ekvivalent, což bylo i pro mě bolestné zjištění. O čem to přesně mluvíš, že by fungovat mělo a nefunguje?

[Heron]

Po sekvenci příkazů:

chkconfig sluzba on
reboot

se očekává, že při dalším bootu se ona služba sluzba spustí (minimálně se provede pokus o spuštění /etc/init.d/sluzba.

Toto u starého initu fungovalo roky.

Po sekvenci příkazů:

systemctl enable sluzba
reboot

Se pokus o spuštění služby někdy provede, někdy ne. Napříkad z 10 různých služeb se 5 prostě neenabluje.

Já naštěstí služby spíše vypínám a systemctl disable funguje (zdá se) vždy, ale pokud potřebuji nějakou z těch dříve vypnutých služeb znovu startovat, tak systemctl enable je sázka do loterie.

[David Jaša]

Co je defaultní konfigurace?

RTC v UTC:

# timedatectl 
      Local time: Tue 2014-11-25 14:10:23 CET
  Universal time: Tue 2014-11-25 13:10:23 UTC
        RTC time: Tue 2014-11-25 13:10:23
        Timezone: Europe/Prague (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2014-10-26 02:59:59 CEST
                  Sun 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2015-03-29 01:59:59 CET
                  Sun 2015-03-29 03:00:00 CEST

přičemž jediná změna oproti defaultu je přidání nějakých serverů do konfigurace chronyd.

Nebýt té zmínky o rocích, řekl bych, žes v době instalace měl RTC v localtime kvůli widlím a změnils to v průběhu života systému.

[Heron]

Nebýt té zmínky o rocích, řekl bych, žes v době instalace měl RTC v localtime kvůli widlím a změnils to v průběhu života systému.

Na tom stroji žádné Windows nejsou ani nikdy nebyly. RTC v UTC je tam od instalace před několika lety, stejně tak od počátku tam byl plně funkční ntpd.

Jak jsem psal, v rámci nějaké aktualizace se tam dostal systemd-timedated (vzhledem k tomu, že to není samostaný balíček (toho bych si všiml) ale je to schované v systemd, tak nevím kdy k tomu došlo). Po změně letního času jsem si všiml, že je čas mimo, spravil jsem to a zkontroloval (BIOS v UTC, hw clock v UTC, časová zóna správně). Po dalším rebootu (update jádra) to opět bylo mimo. To už jsem začal trochu pátrat a přišel na timedated.

Jako "řešení", které se mi sice vůbec nelíbí, ale zase přinese víc zkušeností s tímto ..... ..... .... systémem, jsem zrušil ntpd (po mnoha letech skvělých zkušeností) a ponechal pouze systemd-timedated. Zdá se, že to funguje.

Ale je to yet another věc, kterou Lennartware prostě rozbil a kterou po té nahradil.

Jak to udělat opačně, tedy ponechal si ntpd a odstranit timedated zatím nevím.

[kralyk z abclinuxu]

[0] 15:12 vojta ~/bu/sy/src/systemd-217 $ ./configure --help | igrep timedated
  --disable-timedated     disable timedate daemon

Ale vrchol pohodlí to pro admina asi není...

[Jiří J.]

Lennart k původnímu stručnému NOTABUG přidal nedávno i dodatečné vysvětlení, kvůli některým stránkám linkujícím na ten bug. To nevysvětluje, proč jsou logy poškozené, ale proč není --repair. Asi taky s ohledem na to, že by kvůli zpětné modifikaci nefungoval forward sealing u journald.

Docela by mě zajímalo, kolik z těch potenciálních use casů pro filtrování binárních logů má reálné použití a zda tedy mají praktický smysl.

[trekker.dk]

Taky to nevysvětluje, proč logy nemůžou být ukládány v textové, nikoliv binární podobě.

[sid]

Je problem s chapanim textu? Staci si pozriet nazov bugu a naozaj sa tam nespomina nic o text vs binary. Pripominate mi rimskeho senatora ktory kazdy prejav ukoncoval vetou "okrem toho si myslim, ze Kartago musi byt znicene". Chapem co vam vadi ale tento sposob diskuzie kde sa niekto bavi o chybe A a dalsi vytiahne uplne mimo chybu B je naozaj na dve veci.

[trekker.dk]

Máte problém s chápáním jednoduchých věcí?

Ano, v tom bugu se opravdu neřeší nic o tom, jestli se logy mají ukládat textově nebo binárně. Jenže na druhou stranu textový log poškodíte jenom poškozením filesystému a to poškození bude snadno rozeznatelné. Tudíž kdyby se pro logy používal (nebo mohl používat) nejrozumnější způsob jejich uložení - čistý text - není potřeba řešit neschopnost nějakého udělátoru ty logy opravit.

[Heron]

Samozřejmně souhlas, ale to, že je něco binárního ještě neznamená, že se to musí nutně poškodit. A to ještě za situace, kdy se tomu stroji nic neděje. Systémy souborů a databáze běžně přežijí bez ztráty jediného bajtu výpadek napájení. Ale chápu, LP trpí syndromem NIH, takže si všechno potřebuje zkurvit sám.

[sid]

ja pisem, ze vas chapem, akurat, ze ked sa niekto bavi o A tak tam nepletiem B. Predpokladam, ze tato vasa poziadavka je pravdepodobne tiez reportovana. PS : badate niekde,ze mam problem chapat co je binarny a co textovy format? Lebo celkom nechapem co ste ako planovali tym zvyskom okrem zaciatku druehej vety. Ujasnit si to sam sebe?

[kralyk z abclinuxu]

Jenže na druhou stranu textový log poškodíte jenom poškozením filesystému a to poškození bude snadno rozeznatelné.

Pobavilo. A to jsem přitom taky odpůrce journald... Jenže jestliže je v programu bug v zápisu/serializaci dat, tak je celekem šumák, jestli je zapisuje plaintextově nebo binárně, výsledek korektní nebude tak jako tak...

Zrovna u tohohle bugu mi WONTFIX přijde logické - řeší se tam následky, ne příčina.

[pavlix]

Zrovna u tohohle bugu mi WONTFIX přijde logické - řeší se tam následky, ne příčina.

Četl jsem to dneska poprvé a taky mi přijde postup nanejvýš logický, a to jak v případě binární, tak v případě textové serializace strukturovaných logů. Přijde mi, že s následky dělají to nejlepší, co jde, tedy je zakonzervují a umožňují je nadále přečíst v míře, jakou to umožňuje použitá verze readeru. Podle toho, co se tam píšeš v tomto ohledu udělali maximum a dál je potřeba soustředit energii na příčinu špatných logů.

[tomasgn]

tem, kterym je to jedno, je nejspis uplne jedno jaky system na pocitaci maji, a jeho instalaci a udrzbu dela patrne nekdo jiny.

[Frack]

Znám i plno adminů, kterým to je jedno. Ne, že by netušili, jaký init běží v jejich systémech, ale prostě k SystemV vs systemd staví indiferentně. Je nakonec součástí jejich práce, aby se s tím naučili pracovat. Ne pro každého je životní prioritou vést svatou válku vůči všemu, co se mu v Linuxu nelíbí.

[pavlix]

Je nakonec součástí jejich práce, aby se s tím naučili pracovat.

+1

A to platí jak pro sysvinit, tak různé nadstavby, tak pro systemd.

[pavlix]

Možná si pod tím pojmem představujeme něco jiného, ale já měl za to, že "fungovat" v dotazu předřečníka znamená nejenom, jestli půjde nainstalovat SysV init, ale jestli s tím taky budou fungovat programy

Taky mám ten dojem, že v té reakci není odpověď, ale jen letmo související návod na instalaci.

Osobně by mě to zajímalo taky - ze současných informací mám pocit, že to bude záviset na náladě správce toho kterého balíku, jestli se mu bude nebo nebude chtít dělat podporu pro různé init systémy.

Což u některých balíků může být fatální,.

[little.owl]

Rezignoval Ian Jackson.

[sid]

pri tomto tempe sa zda, ze clenovia TC budu co chvila nedostatkovy tovar :)

[little.owl]

Rekl bych, ze se to ted postupne uklidni.

[...]

jen se to presune mezi uzivatele... debian si tohle navaril sam, kdyz zkratil release cyklus a oriznul odpovidajicim zpusobem podporu. cimz v podstate sel proti vetsine svych stable instalaci.

[trekker.dk]

Věci se uklidní, nic se nestalo, a hlavně, že jsme se zbavili toho zmetka, který nám chtěl sebrat nůž na salámovou metodu...

[little.owl]

..., nic se nestalo,...

S ohledem na vysokou ucast a celkem jasny vysledek spise presne naopak.

[Bedňa]

Áno vaše víťazstvo sa blíži, na obetiach nezáleží.

Jak občasne sledujem dianie okolo komunity systemd, tak mi to jedného dňa docvaklo. Keď vidím tie stále nové a inovatívne nápady okolo systemd, tak zakaždým dostanú pochvalu od Lennarta a chápem že si začali žiť v nejakom osvietenom priestore kde je dobre a máme sa radi. Celkom ich už aj chápem.

Že je to šmejd na tom nič nemení, ale už som pochopil buď sa postaví opozícia ktorá bude naďalej veci robiť poctivo bez potlapkávania sa od najvyššieho, alebo vitajte v systéme kde sa probléme neriešia, ale vytvárajú a zahadzujú, proste anarchia ala MS.

Beriem to tak máme tu slobodný systém a stále mám cestu ako sa vyhnúť tomu čo nechcem. Už to nejak ani neprežívam, ale po tvojom komente mi nedalo nereagovať.

[little.owl]

Beriem to tak máme tu slobodný systém a stále mám cestu ako sa vyhnúť tomu čo nechcem.

Konecne.

ale po tvojom komente mi nedalo nereagovať.

Proc? Myslite ze se to neuklidni?

[Bedňa]

Proc? Myslite ze se to neuklidni?

Na chvíľu, zatiaľ sme videli len špičku ľadovca.

[little.owl]

V praxi je u FOSS rozhodujici nazor tech co tahaji pilku.

[Jiří J.]

Doporučuji přečíst si interpretace tohoto hlasování na planet.debian.org.

IMHO spíše než "init system coupling" bude zajímavé sledovat integraci / závislost na jednotlivých součástech systemd a zda se nahrazování GNU (nebo nezávislého) userspacu za systemd-* varianty v RHELu promítne i do Debianu.

Tím myslím konkrétněji třeba list z Wikipedie; consoled, hostnamed, journald, localed, logind, networkd, resolved, shutdownd, timedated, timesyncd, udevd, spolu s dalšími budoucími "moduly". Také není zaručeno, že systemd nepřidá náhlou "tvrdou" závislost na jednom z těchto modulů.

A to nezmiňuji související "coupling" problémy, jako systemd vs cgmanager, případně systemd vs kmscon, apod.

Žijeme to v divoké přítomnosti.

[mirec]

No Hardware-accelerated rendering: The linux console draws everything via simple 2D blitting operations directly into the framebuffer. This has been optimized with partial-redraws to improve performance. However, running linux on a slower machine with many monitors will horribly slow down your system. User-space can take advantage of OpenGL to draw consoles much faster.

Systemd nejako nesledujem, používal som ho kedysi keď bol ešte init systém + pár drobností ale ehm toto??? To mi chce niekto nahovoriť, že na konzaolu potrebujem OpenGL pretože údajne dokáže rýchlejšie vykresľovať? Čo na tom chcú robiť? Prehrávať video cez cacalib / aalib??? Že zápis do framebufferu je pomalší než OpenGL .. to im tak na intel grafike uverím. So zvyškom by sa dalo celkom aj súhlasiť, ale aj tak by som rád videl konzolu bez ohľadu na userspace. Síce možno s kernel panic-om ale aspoň viem, že sa nepdarilo namontovať systémový disk alebo niečo podobné.

[j]

Ne, jen z toho chteji vyrobit dalsi widle. Ty taky bez grafarny ktera neumi dx nenastartujou. Uz to vidim jako zivy, jak mi to na serveru do jakyhosi binarniho blobu zapise, ze hw neobsahuje vyzadovanou ogl funcionalitu a tudiz system nemuze byt spusten. A abych si to precet, tak budu muset vykuchat ze serveru disky a pripojit si je nekde jinde. A tam budu muset mit samo taky systemd, protoze bez nej si ten binarni blob neprectu.

[pavlix]

Jestli to opravdu nenabootuje bez grafárny s opengl, tak buď rád, protože to by vyřadilo systemd z části instalací. Ale osobně tenhle optimismus nesdílím.

[...]

tohle je tlak, ktery prichazi z mobilu a embedded. tam je ukrutny nedostatek celociselneho vykonu a grafika se vetsinu casu flaka a pritom je uz integrovana a v minimalni cene temer ve vsem.

[mirec]

Ja embedded robím aktívne. Mám na svojich zariadeniach funkčné OpenGL, ale napr. úvodnú animáciu zobrazujem dávno pred tým než je OpenGL inicializované (to inicializujem na pozadí zatiaľ čo video dekóder chrúme h.264 a vykresľuje priamo na fb) - ukážka s htopom vľavo hore. To, že dnešné zariadenia nemajú dostatočný výkon nie je dávno pravda. A postupne sa to bude zlepšovať. Okrem iného framebuffer môže byť akcelerovaný inak než OpenGL (g2d napr) s omnoho nižšou réžiou.

[little.owl]

môže byť akcelerovaný inak než OpenGL (g2d napr)

Narozdil od G2D je GLES standard podporovany na vsem co ma GPU.

[mirec]

GLES1? GLES2? GLES3? Čo hw čo má iba DX? Alebo HW s GLES ale musí sa špeciálne inicializovať inak zostane čierna obrazovka? Môžme sa tu hrať že akože máme štandard, ale ten štandard ani zďaleka aspoň na mobilných zariadeniach nie je dodržiavany všetkými výrobcami. Potom je argument, že kvôli embedded / mobilným zariadeniam potrebujeme akcelerovanú konzolu úplna blbosť.

[little.owl]

Mam zkusenosti s PowerVR, Adreno, Mali a Vivante, a treba s GLESv2 nebyl v soucasnosti az tak velky problem. G2D je proti tomu neportabilni joke.

[mirec]

GLESv2 je totálne pomalá katastrofa. Na rozumné vykresľovanie textu to chce minimálne 3. Dovtedy si môžme tlačiť texty do bitmapy a posielať grafike nech to vykreslí. Poklepeme sa po pleci ako sme zoptimalizovali vykresľovanie a ideme ďalej.

Okrem toho samotná zožitosť GLES prestáva byť výrobcom po chuti. Je to vidieť na rôznych nových API od AMD / Nvidie a myslím, že najnovšie metal od apple.

[little.owl]

GLESv2 je totálne pomalá katastrofa.

Jiste. A hlavne ze jsem ted schopen pres GPU vykreslovat do 3D modelu ctyri video streamy a delat v shaderech korekci a konverzi (iMX6 Vivante ci Tegra K1), a vy mi budete tvrdit, ze to konzole zadusi.

Okrem toho samotná zožitosť GLES prestáva byť výrobcom po chuti.

A proto K1 podporuje uz i OpenGL 4.4.

[mirec]

Vykresľovanie glyphov vyžaduje trochu viacej réžie než vykreslenie (aj keď s korekciou cez shadery) bitmapy. Na OpenGL je práve réžia spojená s volaním OpenGL API problémom, ktorý pri videu človek nepostrehne. U vyšších verzií OpenGL sa už dajú použiť celkom dobré prostriedky ako Geometry shader (už fakt blbší názov pre jednotku, ktorá konzumuje 1 primitivu [to čo je za slovo] a generuje niekoľko primitiv [aj 0]). U GLES2 musí aplikácia tlačiť mapu glyphov do GPU a potom tlačiť do vertex shaderu pozície na ktorých sa nachádzajú a pri takom unicode aj vyhadzovať nepoužívané čiže zase prepisovať mapu a podobné blbosti. Samozrejme ak sa nepoužíva OpenVG alebo niečo podobné tak fonty sa zvyčajne predrenderujú cez freetype (zatiaľ ma nikto nedokázal presvedčiť, že by sa dalo na grafike urobiť pekné rednerovanie, všade mi chýba hinting).

[little.owl]

Fajn, je tam nejaka rezije, ale nic co by byl problem pro soucasne GPU s GLES/OpenVG, a je to nesrovnatelne lepsi reseni nez vase G2D.

[little.owl]

A k tomu bych jeste pridal OpenVG, ale v podstate to sdili graficky stack s GLES.

[Jiří J.]

Mě se na ksmcon spíš nelíbí ta závislosti a závislost na KMS nebo fbdev. Tím spíš se mi líbí oddělení emulace terminálu do libtsm, kterou používá např. ukázkový emulátor ve waylandu. Tak mě napadlo, zda by se nedala použít pro vlastní minimalistický "rescue" emulátor (bez akcelerace, fungující i na VGA konzoli bez framebufferu, klidně vt100, ...). Trochu jsem zkoumal zdrojáky a nebylo by to úplně triviální, ale ani nemožné.

[little.owl]

To by bylo v pohode, ale kmscon pouzival pango pro rendering fontu, a predstava ze mul login zalezi na pango me znervoznuje.

[Jiří J.]

Čistě volitelně. Ale jelikož ten projekt roste a v minulosti bylo potřeba mít jen libudev, je klidně možné, že pango bude nutností. Mě třeba nedochází, proč libxkbcommon pro "providing internationalized keyboard handling" je povinná.

Popravdě nejsem proti vlastnostem kmscon, dovedu si představit použití na X-less systémech tam, kde je teď kernel VT + KMS + console-tools, ale chtělo by to i něco minimalistického bez dalších závislostí pro případ, kdy se mi qemu opět rozhodne sežrat vstup přes SDL a nereagovat na escape sekvence.

[mirec]

Osobne proti alternatívnemu VT tiež nie som. Proti fbtermu nič zásadné nemám. Ale prístup typu nanútime všetkým kms, opengl ... je mi proti srsti (nie len preto, že vlastním pár zariadení bez podpory ale celkovo ako fallback). Úplne najlepšie by bolo mať k dispozícii aj klasický textový terminál bez framebufferu.

[little.owl]

Nastesti systemd-consoled neni kmscon, veci dela jinak a tyto zavislosti nema.

[Jiří J.]

No, jelikož to dělá ten stejný člověk, moc se dopředu neraduj.

sd-gfx is a helper library in systemd to unify all the graphics, screen and font
handling. All following applications will use it, including:
 (daemon-names are subject to change!)
 - systemd-consoled: A systemd console (basic terminal emulator) used as
                     fallback session/console.
 - systemd-splashd: A boot-splash for initrds. This will not include eye-candy
                    but is only required to accept password-input for
                    encrypted root-partitions. Use Plymouth if you want
                    eye-candy!
 - systemd-welcomed: A login-screen to spawn sessions. This basically replaces
                     /sbin/agetty and /bin/login on a VT. After login it spawns
                     systemd-consoled.
 - systemd-er: The emergency-room helper. Basically an even-more stripped down
               systemd-consoled designed for developers. It avoids
               session-management, seat-assignments, privilege-separation and
               is just an hopefully-always-working-emergency-console. It's not
               enabled by default. Think of it as a userspace-variant of
               "magic sysrq".

(z 2013 patch série)

Trochu se to od té doby změnilo, ale i tak tam je podpora pro všechno od DRM až po vlastní input drivery.

[little.owl]

No, zatim tam jeste nejsou dancing pigs a tyhle zmeny davaji smysl. Stejne se to cele musi upravit kvuli [Windows] UEFI GOP.

[...]

ze se ani nikdo nepozastavil nad vykladem vysledku hlasovani..

rekordni ucast a pritom vysledek - nema smysl hlasovat. v minulosti se lidi proste nezucastnili. ci politika a jake cile jsou oproti drivejsim hlasovanim zdrojem toho vysledku.

[David]

Vysledek prece znamena "neni potreba do toho maintainerum kecat". Ekosystem si s konkurenci dokaze poradit sam. V tomhle konkretnim pripade to pravdepodobne znamena, ze se na Debianu bohuzel budem muset smirit se systemd.

[psio]

Pokud tomu dobre rozumim, tak Debian se tim postupne stava zbytecnou distribuci. O odvozenych nebo min rozsirenych ani nemluve. Nevidim totiz do budoucna zadny prakticky duvod pro jeho existenci, kdyz vyvoj systemove vrstvy se ted prakticky komplet presunul pod palec RedHatu. Rozdil v balickovacim systemu je hrozne malo. Tim spisk pokud se prosadi ten divoky napad s brtfs. Uzivatele a admini logicky radsi sahnou po Fedore a CentOS, kde budou mit vyvoj i aktualizace z prvni ruky. V baleni uzivatelskych aplikacich to vyjde zhruba na stejno a tech par problematickych hlavne kvuli US patentum se vyresi pridanim repozitaru treti strany jako to uz funguje ted.

Bye bye Debian, bye Linux Tech skoro 10 let bylo fajn a nastal cas opustit zahradu zadnimi vratky (FreeBSD a OpenBSD).

[pavlix]

Pokud tomu dobre rozumim, tak Debian se tim postupne stava zbytecnou distribuci. O odvozenych nebo min rozsirenych ani nemluve. Nevidim totiz do budoucna zadny prakticky duvod pro jeho existenci, kdyz vyvoj systemove vrstvy se ted prakticky komplet presunul pod palec RedHatu.

Existuje vůbec nějaká jiná velká stabilní binární distribuce, která je řízená čistě komunitně a nemá jednoho hlavního sponzora, který ji může ovlivňovat kvůli vlastním business zájmům? Já osobně o žádné nevím a právě to, že vývoj systemd probíhá ze značné části pod vlajkou jedné firmy bych viděl jako dobrý důvod takovou distribuci udržovat.

Rozdil v balickovacim systemu je hrozne malo.

Osobně bych považoval za skvělé, kdyby Debian přešel na nějaký balíčkovací systém ve stylu RPM, ebuild, pkgbuild a podobných, tedy na způsob práce, kdy člověk vytváří jeden definiční soubor s minimem boilerplate kódu a redundance. Osobně bych uvítal, kdyby přešel konkrétně na RPM vzhledem k množství jiných distribucí, které ho používají.

Tim spisk pokud se prosadi ten divoky napad s brtfs.

Jestliže se ten nápad (určitým způsobem) prosadí, tak to neznamená zánik distribucí, i když by si to tak možná mnozí přáli nebo se toho naopak bojí.

Uzivatele a admini logicky radsi sahnou po Fedore a CentOS, kde budou mit vyvoj i aktualizace z prvni ruky.

Někteří sáhnou, někteří ne. Zatím se mi Debian jako zbytečná distribuce nejeví a to i přesto, že je zatížen podle mě zbytečně silnou bariérou složitého balíčkovacího systému.

Bye bye Debian, bye Linux Tech skoro 10 let bylo fajn a nastal cas opustit zahradu zadnimi vratky (FreeBSD a OpenBSD).

Zatím vidím všechny o BSD psát, ale že bych viděl běžně třeba přednášky na konferencích, kde přijde člověk s nainstalovaným BSD a ukáže, jak mu to super funguje a vyhovuje, to nevidím, tedy pokud se nepočítá OS X. No dobře, ať nejsem zlý, tak aspoň přednášky, kde ve virtuálu poběží nějaký ten BSD server. Zato Debianu vidím až dost.

[Milan Jurik]

Zatím vidím všechny o BSD psát, ale že bych viděl běžně třeba přednášky na konferencích, kde přijde člověk s nainstalovaným BSD a ukáže, jak mu to super funguje a vyhovuje, to nevidím, tedy pokud se nepočítá OS X. No dobře, ať nejsem zlý, tak aspoň přednášky, kde ve virtuálu poběží nějaký ten BSD server. Zato Debianu vidím až dost.

A nebude to tím, že odchází z Linuxu generace, která kdysi přednášela, ale dnes už to nemá zapotřebí, a jen prostě migruje? Vysmíváš se a chováš se asi tak, jako před 15 lety ti guruové od MS.

[little.owl]

Urcite dochazi ke generacni obmene a prichazejici generace programatoru je jina. Rekl bych, ze je v podstate uz tolik nezajima systemove programovani, v centru jejich pozornosti je spise web a souvisejici technologie. Na PC budou s klidem provozovat Windows ci OS X, s Linuxem si vystaci nekde na automatizovane VPS, ci v Dockeru, az tolik se s tim uz nechteji patlat (systemd).
Pokud tomu tak je, do budoucna to poznamena vsechny FOSS operacni systemy a jadro jejich vyvojaru bude starnout, prestoze trend obecne v IT muze byt jiny. Zajimala by me tvrdsi data, ktera by to potvrdila ci vyvratila, a navstevnici tohoto serveru nejsou reprezentativni vzorek: presto ze se tady ve flamu serezeme jako psi, mame ve skutecnosti vice spolecneho, nez bychom si nekdy pripustili.

Presun od Linuxu k BSD. Take mi to prijde jako plane vyhrozovani. Jednak si nemyslim, ze treba podil BSD serveru nejak roste, tedy podle ruzne pochybnych zdroju jako je Netcraft. Nesvedci o tom ani jine indikatory, ktere me napadaji, jako je treba aktivita mailing listu ci statistika commitu v repositarich. Staci srovnat grafy provozu hlavnich mailing listu OpenBSD ci FreeBSD a treba kernelu ci systemd. Pokud se cela tahle oblast komoditizuje a automatizuje (systemd), coz nahraje prevazne velkym hracum, zacnou rozhodovat cim dale vice jine faktory nez jsou prani administratoru.

[TM]

Zájem o webové technologie opravdu nestačí - ať mně tady nadávají, jak chtějí, vždy to byla spíš doména těch technicky méně zdatných. Nedovedu si představit svět bez systémového programování - vše by prakticky ustrnulo. Pokud by to bylo, jak píšete, byl by to opravdu vážný problém a nikoliv jen "zajímavost" do flamewaru.
Pozornost lidí jako jsme my se prostě pomalu(ano - pomalu, zato jistě - ani já to nedělám nějak emotivně překotně) přesune k BSD, protože tam je zdravý základ a určitá nezávislost. Bojovat za linuxová distra už nemá moc smysl. Z RedHatu se stala klasická korporace, Linux chce komunitě prostě vzít a udělat z něj komerční nástroj pro generování zisku - k tomu potřebuje vysoce virulentní záležitosti jako je systemd, přes které se dá diktovat, jak má co vypadat a k nimž se dá vychovávat armáda laciných cvičených opic. Ono se to dalo čekat, jen jsme to dlouho nechtěli vidět a brali je jako "tu hodnou" firmu.
Lidí jako Stallman, Torvalds, atd... je mně líto - musí to být hrozný pohled, vidět jak člověku berou část celoživotního díla a jak jsou některé myšlenky zneužívány.

[pavlix]

Lidí jako Stallman, Torvalds, atd... je mně líto - musí to být hrozný pohled, vidět jak člověku berou část celoživotního díla a jak jsou některé myšlenky zneužívány.

Zkus se jich někdy zeptat na jejich pohled.

[Tonda]

Z RedHatu se stala klasická korporace, Linux chce komunitě prostě vzít a udělat z něj komerční nástroj pro generování zisku - k tomu potřebuje vysoce virulentní záležitosti jako je systemd, přes které se dá diktovat, jak má co vypadat a k nimž se dá vychovávat armáda laciných cvičených opic.

Ja bych rekl, ze toto je ten zasadni prispvek k tematu. A ja bych to jeste trochu rozvedl. Cetl jsem nedavno rozhovor se zakladatelem RH, ktery jiz v polovine 90. let investorum vykladal, jak bude jeho firma jednou vydelavat stomiliony na sluzbach. To nakonec rikal uz i RMS a vsichni jsme to slyseli.

Jen jsme nejak nerealizovali (ja tedy ne), ze k tomu aby bylo mozno delat ten servis a vydelavat na tom, se musi ten produkt na to upravit. Ja jsem dokonce presvedcen, ze je to cele takovy proces, ketry nema uplne presny scenar. SystemD se ted hodi do kramu, ale vpodstate je mozno pozorovat tu service-strategii i u jinych produktu (M$, Cisco ..) - 'zasmodrchej to tak, aby si lidi ten servis museli koupit'.

Ja bych rekl, ze to je to, co vsichni - zejmena ti zkusenejsi - citi, ALE diskuze se odehrava trochu vedle - radoby na technicke urovni. Jestlize bychom chteli byt uprimni, tak jde nam tem obycejnym adminum a vyvojarum, kteri linux nabizeji se svymi produkty vpodstate o job. V soucasnosti nas (skupinu kterou jsem popsal) nejaky init nezlobi. Jiste nejaky ten script clovek musi napsat, ale my neprovozujeme systemy s milionem uzivatelu a proto nemame ty problemy , ktere se neustale omilaji - procesy ktere se neukoncuji, demoni patrne neustale padaji a vzajemne se mezi sebou mlati kvuli spatnemu poradi apod. Nasi vyhodou je ale, ze ten system ovladame i s nasimi omezenymi zdroji. V tom okamziku, kdy budeme muset prochazet skolenimi a hrabat se v zasmodrchanem systemu jsme nezaplatitelni. A o to RH jde. Mala nebo stredni firma dnes vystaci s nejakym garazovym programatorem, ketry jim spravuje vedle i ty linuxy, to v budoucnu nebude. Bude si muset objednat sevis u RH nebo SUSe.

[little.owl]

Konspiracni teorie. Red Hat vas nemuze neco nutit pouzivat a kupovat, a ani vam branit ve svobode psat a udrzovat alternativu. To ze treba dostatecne pritazliva funkcni alternativa neni, znamena spise to, ze po ni neni dostatecna poptavka materializovana v neci praci, casto proto ze stavajici reseni jsou proste "good enough".

[Frack]

Kluci, teorie pěkné, ale přijde mi, že trochu odtržené od reality. Operační systém se čím dál více komoditizuje a to i ten pro enterprise. Jen tady na Abíčku má očividně hodně lidí pocit, že operační systém je středem všeho. Z technického pohledu ano, ale z obchodního ne. To historické okno, kdy se na něm dalo vydělat, se uzavírá. Osobně si myslím, že v Red Hatu si nelámou hlavu na tím, jak vydělat víc na Linuxu, ale na čem dalším vydělávat, protože pokud budou dál spoléhat jen na příjem z RHELu, tak budou brzo ze hry. Jejich budoucnost je v komplexnějších řešeních jako middleware, PaaS, IaaS (JBoss, OpenShift, OpenStack,...), kde komoditizace a sražení ceny prakticky na nulu nejsou tak jednoduché. Operační systém samozřejmě bude dál technicky podstatnou částí toho všeho, ale sám o sobě už to prakticky byznys nebude. Uvědomuje si to i Microsoft, který IMHO taky nevidí budoucnost v prodávání licencí k Windows, ale ve věcech jako Office 365 nebo Azure, kde je systém jen podpůrným produktem.

Pohádky o tom, jak Red Hat "zašmodrchává" Linux, aby na něm víc vydělal, jsou pěkné, ale chce to reality check

[pavlix]

Operační systém se čím dál více komoditizuje a to i ten pro enterprise. Jen tady na Abíčku má očividně hodně lidí pocit, že operační systém je středem všeho.

Taky tím trpím. Ale už jen třeba v práci zjišťuju, že se nově otevírají pozice kolikrát v úplně jiných oblastech.

[lima]

Operační systém samozřejmě bude dál technicky podstatnou částí toho všeho, ale sám o sobě už to prakticky byznys nebude. Uvědomuje si to i Microsoft, který IMHO taky nevidí budoucnost v prodávání licencí k Windows, ale ve věcech jako Office 365 nebo Azure, kde je systém jen podpůrným produktem.

Ale houby. Podle poslednich cisel Microsoftu za rok 2013 je 80% prijmu ze Server and Tools pochazi z primeho prodeje licenci a k zadnemu citelnemu propadu pomeru vuci sluzbam behem posledni dekady nedoslo. Souhrnny clanek Where does Microsoft make money? s odkazy na zdroje.

[Frack]

Samozrejme, ale ty prodeje casto rostou jen kvuli tomu, ze jsou Windows potreba jako soucast toho komplexniho reseni. Ciste jen na prodeji systému se vydelava cim dal hure a ten trend bude pokracovat.

[JS1]

Problem je, ze Wall Streetu na obratu nezalezi, ale zajima je rust. Jak se chteji vyporadat s fyzikalni realitou mi neni jasne - nejspis v ni ani neziji.

[mirec]

To sa týka všetkých ekonómov. Počas štúdia som sa nestačil diviť v akej realite títo ľudia žijú.

[Michal Kubeček]

Máte trochu zvláštní představu o tom, co takový support obnáší a čím se zabývá. Nevím jak to funguje u Red Hatu, ale my se neživíme tím, že bychom někomu spravovali jeho servery. Občas to sice dopadne tak, že někdo nahlásí chybu a skončí to tím, že mu vysvětlíme, co je špatně na jeho konfiguraci, ale rozhodně to není primární cíl a business plan.

[David Jaša]

Nevím jak to funguje u Red Hatu, ale my se neživíme tím, že bychom někomu spravovali jeho servery.

Red Hat taky ne.

[little.owl]

vždy to byla spíš doména těch technicky méně zdatných.

Kazda prace se musi umet, a i tam je plno zajimavych a netrivialnich veci, a taky jde o moznosti pracovniho uplatneni.

Pokud by to bylo, jak píšete, byl by to opravdu vážný problém a nikoliv jen "zajímavost" do flamewaru.

Tohle je jeden z duvodu vzniku RPi. Technologicke firmy v Cambridge, stejne University of Cambridge pozorovaly vyrazne rozdily mezi generacemi, ktere zacinali treba na ZX Spectrum a programovanim Z80 na strane jedne a na XBox a HTML/Javascriptu na strane druhe. V podstate to vypadalo tak, ze by jim universita musela pridat jeden rok navic, aby dosahli stejnych vysledku. Jejich teorie byla takova, ze teto generaci chyby vhodny levny pocitac, ktery by jim umoznil osahat si HW a umoznil experimentovat, a motivace byla na svete. RPi byl designovan jako skolni pocitac a tak velky uspech nikdo necekal. Jestli to pomuze, je jina vec.

Pozornost lidí jako jsme my se prostě pomalu(ano - pomalu, zato jistě - ani já to nedělám nějak emotivně překotně) přesune k BSD, protože tam je zdravý základ a určitá nezávislost.

Ja klidne verim, ze nekteri lide prejdou, zejmena pokud jim staci jen terminal a browser a par veci okolo. Jenze par vlastovek jaro nedela, a ja skutecne stejne jako Pavlix nevidim zadny hmatatelny dukaz, ze se jedna o masovy jev nebo zmenu trendu.

Vrchol FOSS distribuci nastal nekdy kolem 2005/7, od te doby to celkove spise klesa. Obvykle takove jevy maji zpozdeni za pricinou, takze duvod nastal jeste o neco drive. Muzeme spekulovat co za tim je, ale z casove posloupnosti to nejsou veci jako Gnome3, KDE4 ci systemd.

[Frack]

Presun od Linuxu k BSD. Take mi to prijde jako plane vyhrozovani.

Připomíná mi to tu atmosféru, když vyšlo GNOME 3. Taky plno lidí ohlašovalo, jak přechází na Xfce. Tomuto prostředí tady někteří předpovídali zářnou budoucnost a GNOME zánik. Dnešní realita: Xfce má minimum vývojářů a po stránce vývoje je prakticky mrtvé. GNOME má dnes ze všech desktopů komunitu přispěvatelů nejširší.

[pavlix]

GNOME má dnes ze všech desktopů komunitu přispěvatelů nejširší.

A nutno dodat, pořád to... ale co, teď mi dochází, že je větší část vývojáře u mého zaměstnavatele, takže no comment.

[...]

zda se mi to nebo neplacena komunita to proste vzdala?

[...]

.. (a zdrhla k macbooku)

[Frack]

Do každého releasu GNOME přispěje zhruba 1000 lidí. Nevím, kolik z nich je z Red Hatu, ale vzhledem k tomu, že podle Wikipedie v Red Hatu dělá 6500 lidí, což zahrnuje i administrativu, prodejce, markeťáky a GNOME je jen velmi malou podmnožinou toho, co všechno Red Hat dělá, nemyslím si, že by Red Hat sám dokázal zastavit propad zájmu z řad dobrovolníků nebo vývojářů z jiných firem. I kdyby byla většina lidí, přispívajících do GNOME, z řad placených vývojářů, nevidím v tom problém. Naopak je to plus pro daný projekt, že je dostatečně atraktivní i pro komerční subjekty.

[pavlix]

Já jsem ani tak nepsal o statistice.

[lima]

Do každého releasu GNOME přispěje zhruba 1000 lidí.

BS. On je rozdil prispeje a "prispeje". Neco jinyho je nakodovani rozsahly funkcionality jako podpora compizu a neco jinyho pull request na opravu slovicka v dokumentaci nebo jednoradkovy patch. A Red Hat je hlavnim donatorem GNOME foundation.

[vim]

Pokud se cela tahle oblast komoditizuje a automatizuje (systemd), coz nahraje prevazne velkym hracum, zacnou rozhodovat cim dale vice jine faktory nez jsou prani administratoru.

Pak docela nechapu Vase nadseni pro systemd, kdyz poukazujete na tento aspekt, ktery nejspise soucasne zmeny prinesou. Zrejme Vam asi vubec nedochazi, ze to muze znamenat pokles mezd a rapidni ubytek pracovnich mist v nasem oboru.

[pavlix]

Zrejme Vam asi vubec nedochazi, ze to muze znamenat pokles mezd a rapidni ubytek pracovnich mist v nasem oboru.

Nebo je mu to jedno, ne každý se zajímá o statistiku, stejně jako se ne každý zajímá o maximalizaci pracovních míst v určitém oboru, pokud už tedy budu předpokládat, že má k něčemu takovému skutečně dojít.

[Heron]

Já to vidím přesně opačně. Právě v důsledku této automatizace budou o to více ceněni ti z nás, kteří stále budou vědět, jak systémy ve skutečnosti fungují, kde jsou uložená data, že proces potřebuje procesor apod detaily. Dneska už vzniká buzzword hardware empathy jako označní pro zázračné lidi, kteří ví, jak funguje hw a jak se k němu chovat (tedy to, co naše generace považuje za samozřejmost).

Za pár let může vzniknout pojem system empathy pro zázračné jedince, kteří si ještě vzpomenou, co a jak dělá OS.

Já jsem proti systemd, ale zrovna tohoto aspektu se nebojím, právě naopak.

[Frack]

Kvalitní lidi budou vždycky cenění. To, že se administrace otévírá čím dál širšímu okruhu lidí, neznamená, že to nějak postihne ty kvalitní. Dnes je díky nejrůznějším frameworkům a vysokoúrovňovým jazykům také výrazně jednodušší programovat než před 30 lety, ale lidi, kteří umí nízkoúrovňové věci v assembleru nebo C jsou pořád stejně (nebo spíš ještě více) cenění než tenkrát.

[little.owl]

Na serveru ci desktopu preferuji systemd, v embedded Linuxu v soucasnosti nikoliv a jeho uziti zatim aktivne branim. Jsem tedy jen nadseny zastance?

Kazda technologie ma technickou a lidskou stranku, plusy a minusy, zalezi na pohledu. Luditismus neni cesta a my se musime prizpusobit. Je dost mozne ze bude potreba mene a vice znalych lidi (viz. Heron nahore), ale osobne bych vetsi problem v praxi videl v outsourcingu do levnejsich zemi - to dokaze zlikvidovat pracovni prilezitosti ze dne na den tak rychle, ze mate velmi omezenou sanci se prizpusobit.

[pavlix]

Na serveru ci desktopu preferuji systemd, v embedded Linuxu v soucasnosti nikoliv a jeho uziti zatim aktivne branim. Jsem tedy jen nadseny zastance?

A já?

[little.owl]

A já?

Ty? Na zacatku jsi byl jasne velky zastance, ktery me o cele rade veci presvedcil. Po prichodu do Red Hatu se na jeden cas kyvadlo vychylilo na druhou stranu zpusobem, kdy jsem si rikal, co ses tam sakra dozvedel, co s tebou udelali a zdali jsi treba schopen oddelit osobni antipatie vuci autorovi a jeho praci. V posledni dobe mi prijdes neutralni ci realisticky smireny, kazdopadne mavatka na Lennartuv prijezd bych ti z bezpecnostnich duvodu nesveril.

Je to hodne o osobni zkusenosti a ja tvou nemam.

[pavlix]

Na zacatku jsi byl jasne velky zastance, ktery me o cele rade veci presvedcil.

Krátce než jsem šel do RH, tak asi rok nebo dva předtím jsem přecházel na Fedoru z toho důvodu, že jsem se chtěl seznámit s novým vývojem v oblasti a Fedora se zdála mít k tomu novému vývoji nejblíž, což se pak ukázalo jako pravda. Jak Gnome 3, tak systemd byly relativně nové (a o to víc nové pro mě), že jsem každý nedostatek považoval za průvodní jev toho nového vývoje.

Gnome 3 jsem vzdal a dneska se podobně dívám na Enlightenment 0.19, který mi přijde podobně zabugovaný jako tehdy Gnome, ale tak nějak jsem se rozhodl to překousnout a touto dobou se chystám začít hlásit bugy a když čas dovolí (jakože na 99% nedovolí), pohrabat se v kódu.

Po prichodu do Red Hatu se na jeden cas kyvadlo vychylilo na druhou stranu zpusobem, kdy jsem si rikal, co ses tam sakra dozvedel, co s tebou udelali a zdali jsi treba schopen oddelit osobni antipatie vuci autorovi a jeho praci.

Nejsem, to se oddělit nedá. Pracoval jsem na věcech, které Lennart už věděl, že bude chtít ze systému vykopat a nahradit vlastními a to se značně podepsalo na jeho přístupu. V době, kdy jsem pracoval na NetworkManageru jsme měli problémy s integrací do systemd a nikdo nám nepomohl. Teď když je tu networkd a Tom Gundersen, tak je spolupráce mnohem lepší. Navíc už zjistili, že nemají čas udělat během pár měsíců z networkd nový NetworkManager. Jenže když jsem se poprvé potkal s Tomem na FOSDEMu, tak už jsem byl jaksi mimo hru.

V posledni dobe mi prijdes neutralni ci realisticky smireny

To by tak asi sedělo. Já jen že někteří ábíčkáři mě rádi hází do lennartovic škatulky ;).

[little.owl]

každý nedostatek považoval za průvodní jev toho nového vývoje.

Nevyhoda outsidera. Ja jsem to take prikladal radikalnim zmenam a nedostatku vyvojaru.

dneska se podobně dívám na Enlightenment 0.19,

Kolecko se opakuje. EFL se mi celkem libi, ale Enlightenment moc ne.

Nejsem, to se oddělit nedá.

Nekdy je to nutne, nebo by se mel clovek snazit. Take mam list lidi, ktere bych nejradsi vystrelil na Mesic, ale musim s nimi i pracovat, cast z nich skutecne umi.

tak už jsem byl jaksi mimo hru.

A na cem ted pracujes? Chtel bys zpatky do "hry"? A co by to melo byt, pokud bys mohl vybrat?

Já jen že někteří ábíčkáři mě rádi hází do lennartovic škatulky ;).

Tam by pro tebe jiz nebylo misto, tam jsem uz beznadejne napraskan ja.

[pavlix]

Kolecko se opakuje. EFL se mi celkem libi, ale Enlightenment moc ne.

Chtěl jsem zkusit něco nového a vývojáři se zdají být vcelku otevření, příjemný IRC kanál, měl jsem tam s jedním člověkem zcela zbytečný konflikt a bylo mi řečeno, ať se na to vyseru. Oproti tomu před časem na kanálu meego mi bylo vysvětleno, že dotyčný je vážený člen komunity a ať jdu do řiti. Pár věcí se mi na enlightenment nelíbí, ale tam je aspoň skutečně málo vývojářů (jeden pravidelný) a na to to vypadá velice dobře a dává to člověku šanci něco zlepšit, což mi u Gnome připadá nemožné. Trochu mi chybí Gnomácký minimalismus, na druhou stranu mi trochu vadí registry-style konfigurace.

A na cem ted pracujes? Chtel bys zpatky do "hry"? A co by to melo byt, pokud bys mohl vybrat?

Pracuju ve skupině packagerů síťových věcí kromě kernelu a NetworkManageru. Zpátky do hry bych za současné situace nechtěl, navíc jsem po důkladné rozvaze odcházel sám. Na předchozí pozici jsem se snažil fušovat do všech možných dalších projektu, dneska je to součástí mojí práce. Myslím, že bych se nechtěl vrátit ani za pro mě příznivé situace, NetworkManager je rozhodně zajímavý software a bylo fajn se mu věnovat naplno, ale popravdě by potřeboval pořádnou čistku, ale nikdo nebude platit lidi, kteří by se tomu naplno věnovali.

Jako musím říct, že změna pozice v rámci firmy je skvělý vynález. Když nepočítám to zdržení, ke kterému došlo u nás, tak jsem dostal nabídku ve známém prostředí, a jediné, co bylo k přechodu potřeba, bylo neposrat dodělávky do předchozího týmu, ale tak tím si člověk aspoň trochu potrénoval vůli. Žádné vyjednávání z cizími lidmi, žádná smlouva, žádná zkušebka. A vzal jsem si s sebou ty vedlejší projekty, o který se nový šéf narozdíl od starého zajímal. Zanechalo to ve mně dobrý dojem, že se brněnská pobočka o svoje lidi stará. Ale nemám tušení, jak to chodí v jiných firmách.

Tam by pro tebe jiz nebylo misto, tam jsem uz beznadejne napraskan ja.

To máš pravdu. Díky tobě mám teďka povětšinou klid. Zjevně trollům stačí ke spokojenosti jeden cíl ;).

[little.owl]

Uvidime, kam se posune desktop; nakonec budem jednou lipat frontend nad JS/CSS/HTML5.

Žádné vyjednávání z cizími lidmi, žádná smlouva, žádná zkušebka.

Kontakty jsou dobra vec, at uz v ramci firmy, ci mimo ni, a asi nejefektivnejsi zpusob jak si najit praci a nezacinat na zelene louce.

Ale nemám tušení, jak to chodí v jiných firmách.

Velke firmy na to maji casto specialni programy, kdy z jedne divize mohou jit lide na nejakou dobu do druhe, pripadne tam zustat, i v jine zemi. Marna snaha zlepsit rizeni molochu, kde leva ruka nevi co dela prava, a jednotlive divize mezi sebou skryte valci.

[mirec]

Uvidime, kam se posune desktop; nakonec budem jednou lipat frontend nad JS/CSS/HTML5.

To sa deje už teraz.

[pavlix]

No tak zrovna RH lidi do jiné země přesouvá spíše nerad, zvlášť pokud je to směrem na západ. Nejeden asiat už kvůli tomu měnil práci.

[pavlix]

A nebude to tím, že odchází z Linuxu generace, která kdysi přednášela, ale dnes už to nemá zapotřebí, a jen prostě migruje?

Samozřejmě je to možné, ale...

1) Occamova břitva mi napovídá, že to tak spíše nebude.

2) Na Linuxu oceňuju především aktivní komunitu. To, že si někdo soukromě provozuje servery třeba na Windows ME je mi jaksi dost jedno.

Vysmíváš se a chováš se asi tak, jako před 15 lety ti guruové od MS.

Co je tohle za hysterii, to už jsi vážně tak argumentačně na dně, že si musíš vymýšlet takovéhle věci?

Já se nevysmívám, jen upozorňuju na zcela konkrétní současnou realitu. Pokud, jak ty tvrdíš, na BSD migruje jen starší generace, která o tu mladší nemá dost zájmu, aby se čas od času někdo z nich objevil a chvíli popovídal, tak za těch patnáct let ta starší generace ztratí sílu a z části třeba i umře. Ale to jsou jen důsledky tvého názoru.

Na druhou stranu pokud za 15 let poletí všude FreeBSD, tak se nemusím bát, že bych měl problém sehnat práci ;).

[Milan Jurik]

Co je tohle za hysterii, to už jsi vážně tak argumentačně na dně, že si musíš vymýšlet takovéhle věci?

Nejsem argumentačně na dně, jen už nějak nemám potřebu o tom diskutovat, trávit čas vzájemnými monology. Nestojí mi to za to, jen jsem tu klidně poznamenal svůj názor

[pavlix]

s/poznamenal názor/hodil nějakou tu urážku, abych si dokázal, jaký jsem borec/

[Hans1024]

Zatím vidím všechny o BSD psát, ale že bych viděl běžně třeba přednášky na konferencích, kde přijde člověk s nainstalovaným BSD a ukáže, jak mu to super funguje a vyhovuje, to nevidím,

Ono by asi stacilo navstivit treba EuroBSDCon. Me spis zarazi to, ze chce nekdo kvuli systemd zahodit i Linuxove jadro i GNU a utikat hned k BSD.

[pavlix]

Ono by asi stacilo navstivit treba EuroBSDCon.

Kdyby se ani na BSD konferenci nemluvilo o BSD, tak by to už bylo hodně špatné. Ale já přece nepojedu na konferenci, která je celá o systému, který mě zajímá jen okrajově. Pokud by byla nějaká výrazná česká BSD komunita, tak uvidím přednášky o BSD na každém OpenAltu, ale podle mě i na InstallFestu a LinuxDays, protože nikdo neříká, že jsou tyhle akce striktně linuxové a to ani v případě, že to mají v názvu. Na mezinárodní úrovni je to trochu lepší, na FOSDEMu má BSD své zastoupení každý rok, ale ani tam to nevypadá, že by Linux kdovíjak ztrácel.

Me spis zarazi to, ze chce nekdo kvuli systemd zahodit i Linuxove jadro i GNU a utikat hned k BSD.

Tak ono je to logické, vzhledem k tomu, že Lennart&Kay na BSD aktivně nadávají a ani ho neplánují podporovat. Možná je to i strategie jak se zbavit nepohodlných kritiků, oni půjdou k BSD a lennartovi zůstane byznys ;). Přejít k BSD znamená v tuhle chvíli relativní jistotu, že tě se systemd nebude nikdo obtěžovat a že nepřestanou být podporovány alternativy.

[Hans1024]

Pokud by byla nějaká výrazná česká BSD komunita, tak uvidím přednášky o BSD na každém OpenAltu

Holt zastupci minority se tezko hledaji. Netusim, jak je to treba se zastoupenim Linuxu na prevazne Windowsich konferencich . A z par BSDaku co znam navic ziskavam pocit, ze Linux moc nemaji radi. A taky se mi zda, ze podpora svobodneho SW u nich neni tak silna, jako u komunity kolem Linuxu a casto se netaji tim, ze vesele pouzivaji OS X, nebo Windows a BSD jen na serveru. Ale tenhle muj pohled muze byt dost zkresleny, protoze jich zas tolik neznam (a v Cesku opravdu snad nikoho).

Přejít k BSD znamená v tuhle chvíli relativní jistotu, že tě se systemd nebude nikdo obtěžovat a že nepřestanou být podporovány alternativy.

Tak jsou i Linuxove distribuce, ktere jsou pevne rozhodnute nepouzivat systemd a pokud se nejaky software podari rozjet bez systemd na BSD, pak bude asi trivialni pouzit stejne patche i na techto distribucich.

[pavlix]

Holt zastupci minority se tezko hledaji. Netusim, jak je to treba se zastoupenim Linuxu na prevazne Windowsich konferencich .

Osobně jezdím i na konference, které nejsou čistě linuxové, a jestli tam linux převažuje, není dáno (pouze) zaměřením konference. Namátkou EurOpen, kam pravidelně jezdí i pár applařů, kteří mají pravidelně problém propojit laptop s projektorem, nedávný OpenAlt, který dokonce dostal nové jméno, aby se návaznost na Linux smazala, kde se přednášelo o mobilní aplikaci, která není k dispozici ani na Android. Jako ty konference jsou primárně zaměřené na otevřené systémy, takže prezentovat tam Windows a Mac OS X nedává smysl, ale prezentovat tam FreeBSD na serveru a připojovat se na něj z Applu myslím není až takový hřích.

Tak jsou i Linuxove distribuce, ktere jsou pevne rozhodnute nepouzivat systemd

Které to jsou. Zkus jmenovat alespoň jednu významnou nebo jednu, u které pevně věříš, že se významnou stane.

pak bude asi trivialni pouzit stejne patche i na techto distribucich.

Popravdě řečeno bych po Gnome 3 ani tak neplakal a nevím o nikom jiném, kdo by se chystal na tvrdou závislost na systemd.

[Hans1024]

Které to jsou. Zkus jmenovat alespoň jednu významnou nebo jednu, u které pevně věříš, že se významnou stane.

Nevim, co povazujes za vyznamne a nejsem vestec, takze nevim co bude vyznamne . Je pravda, ze moznost nainstalovat systemd asi nikde zamerne neodpiraji, mozna CRUX, nebo Slackware, zato odhodlani nikoho do instalace systemd nenutit se mi zda silne - viz Gentoo a z binarnich treba voidlinux.

[pavlix]

Asi jinak chápeme pojem distribuce, které jsou rozhodnuty nepoužívat systemd, to, co máš namysli bych spíše nazval distribuce, kde je systemd volitelné a to by ještě bylo dobré pořešit, zda je výchozí, tedy opt-in nebo opt-out. Pak lze mluvit o Gentoo a jeho opt-in podpoře pro systemd, o voidlinuxu jsem v životě neslyšel. Jestli je distribuce významná je samozřejmě subjektivní pohled, ale myslím, že u většiny se shodneme. Gentoo za významné považuju, voidlinux ne.

[Hans1024]

Mas pravdu, tech co "jsou rozhodnuty systemd vubec nepouzivat/nedistribuovat" asi moc neni, blbe jsem se vyjadril. Zkratka jsem chtel rict, ze myslim, ze lidem co utikaji pred systemd staci takove, ktere jsou rozhodnuty systemd nevyzadovat. To, ze vidim lidi odhodlane udrzovat alternativu mi pripada i jako vetsi zaruka, nez to, ze systemd je z technickych duvodu tezke naportovat na BSD.

[pavlix]

Já neříkám, že ty důvody jsou dobré nebo dostatečné, to si musí rozhodnout každý sám.

[Jiří J.]

Někteří sáhnou, někteří ne. Zatím se mi Debian jako zbytečná distribuce nejeví a to i přesto, že je zatížen podle mě zbytečně silnou bariérou složitého balíčkovacího systému.

Ale fuj, zrovna na RPM mi vadí neexistence Recommends / Suggests. (a taky závislosti na souborech, kdo pak má dohledávat reverzní závislosti)

(a na obou nesmyslně složitá custom struktura balíčků, měli by si vzít příklad ze Slackware (tarball/cpio))

[Frack]

Ale fuj, zrovna na RPM mi vadí neexistence Recommends / Suggests.

Myslíte toto?

[Jiří J.]

Jojo, teď už jen to dotlačit od case study do implementace. A taky správně používat.

(psst, to druhé nedělá na jedničku ani debian, spousta balíků má Depends na dbus nebo gconf2 a přesto jedou v pohodě bez nich)

[pavlix]

Ale fuj, zrovna na RPM mi vadí neexistence Recommends / Suggests.

A to je hrozný problém přidat dvě položky na metadata.

a taky závislosti na souborech, kdo pak má dohledávat reverzní závislosti

Debian dává do metadat pro závislosti seznam všech souborů? To by taky nebyl problém v RPM udělat, jen k tomu moc nevidím důvod. Ohledně reverzních závislostí, můžeš přesně specifikovat problém?

(a na obou nesmyslně složitá custom struktura balíčků, měli by si vzít příklad ze Slackware (tarball/cpio))

RPM jen přidává k tomu cpio hlavičku, pokud vím. To bude nejspíš nějaká optimalizace, jinak by šlo udržovat data čistě v tom archivu.

[Jiří J.]

A to je hrozný problém přidat dvě položky na metadata.

Já nevím, asi jo, když to nikdo v RPM světě neudělal.

Třeba jsou pro to legitimní důvody (třeba RPM nemá snadno rozšířitelnou oblast s metadaty).

Debian dává do metadat pro závislosti seznam všech souborů? To by taky nebyl problém v RPM udělat, jen k tomu moc nevidím důvod. Ohledně reverzních závislostí, můžeš přesně specifikovat problém?

Ale kdeže, to dělá přece RPM!

$ rpm -q --requires glibc
/sbin/ldconfig
/usr/sbin/glibc_post_upgrade.x86_64
basesystem
config(glibc) = 2.17-20.fc19
glibc-common = 2.17-20.fc19
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.2.5)(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libCNS.so()(64bit)
libGB.so()(64bit)
libISOIR165.so()(64bit)
libJIS.so()(64bit)
libJISX0213.so()(64bit)
libKSC.so()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libfreebl3.so()(64bit)
libfreebl3.so(NSSRAWHASH_3.12.3)(64bit)
libgcc
libnsl.so.1()(64bit)
libnsl.so.1(GLIBC_2.2.5)(64bit)
libnss_files.so.2()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libresolv.so.2()(64bit)
libresolv.so.2(GLIBC_2.2.5)(64bit)
libresolv.so.2(GLIBC_2.9)(64bit)
rpmlib(BuiltinLuaScripts) <= 4.2.2-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
/sbin/ldconfig
/usr/sbin/glibc_post_upgrade.i686
basesystem
config(glibc) = 2.17-20.fc19
glibc-common = 2.17-20.fc19
ld-linux.so.2
ld-linux.so.2(GLIBC_2.1)
ld-linux.so.2(GLIBC_2.3)
libCNS.so
libGB.so
libISOIR165.so
libJIS.so
libJISX0213.so
libKSC.so
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.1)
libc.so.6(GLIBC_2.1.2)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.2)
libc.so.6(GLIBC_2.3.3)
libc.so.6(GLIBC_2.4)
libdl.so.2
libdl.so.2(GLIBC_2.0)
libfreebl3.so
libfreebl3.so(NSSRAWHASH_3.12.3)
libgcc
libnsl.so.1
libnsl.so.1(GLIBC_2.0)
libnsl.so.1(GLIBC_2.1)
libnss_files.so.2
libpthread.so.0
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.1)
libpthread.so.0(GLIBC_2.2)
libresolv.so.2
libresolv.so.2(GLIBC_2.0)
libresolv.so.2(GLIBC_2.2)
libresolv.so.2(GLIBC_2.9)
rpmlib(BuiltinLuaScripts) <= 4.2.2-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Takhle - asi chápu důvody, dává to určitý smysl z pohledu samotných binárek i vícedistribučního prostředí, kde se jména balíčků mohou lišit, jen to má potenciál udělat obrovský bordel. A tohle nejsou data generovaná rpm binárkou při query, tohle je fyzicky uloženo v RPM metadatech, mrkni hexdump.

Reverzní závislosti se pak hledají špatně, pokud balíčky nemají v "provides" všechny soubory, které poskytují (což nemají, od toho jsou filelisty). Tady přichází na záchranu repoquery, který ty filelisty stáhne a zpracuje, ale vůbec to není diskově/síťově efektivní operace. Nicméně to už se dostáváme na úroveň manažerů balíčků, kde yum těžce saje např. oproti aptitude, takže to nechám raději na jindy. (čest Alešovi za dnf/hawkeye)

RPM jen přidává k tomu cpio hlavičku, pokud vím. To bude nejspíš nějaká optimalizace, jinak by šlo udržovat data čistě v tom archivu.

No, nějaký archiv tam je, ale ať hledám sebevíc, cpio hlavičku tam nikde nevidím. Nicméně zdroják rpm2cpio naznačuje, že tomu tak asi bude. Moje stížnost byla spíše taková "do větru", s optimalizacemi to nemá moc co dělat (metadata lze vložit i "do" archivu na určitý offset), jde spíše o to, že manuální rozbalování není zrovna častý usecase. Třeba DEB balíčky jsou platné GNU ar(1) archivy, které obsahují další komprimované tarbally.

To byl cíl mého "rantu" - pokud chci dostat data (soubory) z RPM, tak musím použít magii z librpm. Pokud chci dostat data z DEB, musím použít ar(1) v dočasném adresáři a pak dále přes tar rozbalovat control.tar.gz a/nebo data.tar.gz. Je to jako rozbalovat vánoční dárek ze 3 obalů. Podobně když chci takový balíček vytvořit.

Jak to udělat IMHO lépe? Nemám To Nejlepší Řešení (TM) . Slackware používá tarbally s install/slackdesc, což také není úplně optimální (musí se přeskočit install/ při rozbalování do /). Cpio AFAIK nemá žádný "comment" field ani v newc formátu, ale zase zachovává pořadí zabalených souborů, tedy metadata by mohla být "na začátku" na známém offsetu (ale opět by se musela přeskočit pomocí -f / --nonmatching při rozbalování).

Každým pádem jsem už hodně mimo topic, honem, musíme dohnat zbytek ohnivého davu!

[pavlix]

Já nevím, asi jo, když to nikdo v RPM světě neudělal.

Tož dělat by to měl ten, kdo to potřebuje, tak to v open source zpravidla funguje. Už tu padl i odkaz dokazující, že to někoho zajímalo dost na to, aby to aspoň sepsal. Já osobně lidi, kterým by to v RPM vyloženě chybělo neznám, takže nemůžu soudit.

Takhle - asi chápu důvody, dává to určitý smysl z pohledu samotných binárek i vícedistribučního prostředí, kde se jména balíčků mohou lišit, jen to má potenciál udělat obrovský bordel.

Nevím, proč by to mělo dělat bordel. Můžeš na tom vidět, že to ani nejsou závislosti na souborech, ale závislosti na „provides“. Je to docela šikovná věc a většina těch závislostí není ručně psaná, ale automaticky generovaná při buildu.

Reverzní závislosti se pak hledají špatně, pokud balíčky nemají v "provides" všechny soubory, které poskytují

Jak už jsem psal výše, představu, že se jedná o závislosti na souborech, považuju za omyl.

Tady přichází na záchranu repoquery, který ty filelisty stáhne a zpracuje, ale vůbec to není diskově/síťově efektivní operace.

Nevidím mezi file listy a provides souvislost.

Nicméně to už se dostáváme na úroveň manažerů balíčků, kde yum těžce saje

To už je ovšem těžce mimo téma toho, jak má vypadat zdroj pro buildování balíků.

metadata lze vložit i "do" archivu na určitý offset

To mi nepřijde o moc lepší než je přilepit před archiv.

To byl cíl mého "rantu" - pokud chci dostat data (soubory) z RPM, tak musím použít magii z librpm.

To teda nevím, proč bych na to používal magii nebo librpm. Mně osobně hlavička před archivem nepřijde jako kdovíjak velké zlo. Ale nedělá mi problém stejně dobře si představit soubory nebo adresáře v tom archivu. Považuju to za absolutně nepodstatný detail už jenom proto, že by balíčkovač klidně zvládl podporovat dva formáty s různými vlastnostmi, aniž by to zasáhlo do zbytku systému.

[Michal Kubeček]

A to je hrozný problém přidat dvě položky na metadata.

Já nevím, asi jo, když to nikdo v RPM světě neudělal. :-)

Vezmu-li v úvahu, že (přinejmenším) v SuSE distribucích se Recommends,Suggests a Supplements už pár let používají, přijde mi výraz nikdo dost přehnaný.

[pavlix]

Tím jsi to jaksi celé rozsekl.

[psio]

Zatím vidím všechny o BSD psát, ale že bych viděl běžně třeba přednášky na konferencích, kde přijde člověk s nainstalovaným BSD a ukáže, jak mu to super funguje a vyhovuje, to nevidím, tedy pokud se nepočítá OS X.

Treba na freebsd.org je kalendar *BSD konferenci, ale jestli se tam predvadelo jak jim to super funguje nevim a ani nechapu k cemu by to bylo dobre. Pro me je podstatne ze 10-Stable zatim bez problemu bezi na IBM x3500 vcetne raidu na hotswapech a testy na replikaci databaze z verejsi linuxove zalohy. Ostatni modely x na tom snad budou podobne. Na notasu mam zkusebne openbsd 5.6, kde funguje vsechno vcetne uspavani/probouzeni rovnou po instalaci. Zere to asi o 2W vic nez v Linuxu 3.14, ale to se posteluje. No a samozrejme neexistuje flashplayer, virtualbox nebo proprietarni ovladac grafiky od AMD, ale to me netrapi. Misto flashovych streamu bud html5 nebo smtube, do virtualboxu uz nelezu - stare ucetnictvi ve WinXP a vykon svobodneho ovladace pro Radeon je na moje potreby vic nez dostatecny. Fungujou jen dvojkovy USB porty, podpora pro 3.0 ma byt az v dalsim vydani. HDMI jsem zatim nezkousel, ale melo by fungovat. Vic az casem.

Ze zkusenosti vidim smysl konferenci jen pro navazovani zajimavych kontaktu a na tech lepsich i poradna zranice a konzumace dobreho moku ;) Prednasky jsou vetsinou plny bullshitu, radsi si to pak nastuduju sam v koncetrovany forme.

[pavlix]

Konference je jedna z mála možností, kde se potkávám s náhodnými lidmi z oboru. Několik lidí tu vyjádřilo dojem, že se teď hromadně přechází na BSD a já bych rád viděl nějaká vodítka, že se tomu tak opravdu děje a není to jen fáma, kterou si vymyslelo pár BSDčkářů, protože na to díky systemd byla zrovna vhodná příležitost, nebo naopak pár anti-systemd lidí, kterým by to přišlo děsně cool, kdyby to tak opravdu bylo.

Popravdě řečeno monokulturu nemám rád, takže bych to vývojářům i uživatelům *BSD přál, ale to ještě neznamená, že se takové přání plní.

[...]

923598848 Nov 20 21:03 FreeBSD-10.1-RELEASE-amd64.qcow2

[pavlix]

Kontext?

[little.owl]

Tak jsem schvalne nainstaloval tento release na stary laptop a preji vam hodne stesti v migraci. Z hlediska stability je to regrese vuci predchozi rade a stale plati problemy popsane zde. Nehnuli s tim vubec za dva roky a ted je to spise jeste horsi, desitka je slaba rada.

[pavel]

Snaha protlačit kdbus do jádra se zatím setkáva s "vřelým" přijetím Připomínám že kdbus je IPC infrastruktura pro potřeby systemd a zřejmě i způsob jak obejít GPL (schovat volání knihovních funkcí za RPC).

[kralyk z abclinuxu]

Připomínám že kdbus je IPC infrastruktura pro potřeby systemd a zřejmě i způsob jak obejít GPL (schovat volání knihovních funkcí za RPC).

To jenom aby bylo jasno, kdo jsou indiání a kdo banditi...

[pavlix]

To není obcházení GPL, ale obcházení některých zvláštních tvrzení o odvozených dílech. Navíc je na poskytovateli API zda ho poskytuje jako knihovný funkce nebo RPC. D-Bus v tomhle není o nic horší než kterékoli jiné RPC.

[JS1]

Co je na tom spatne? Mne to pripada jako normalni code review.

[little.owl]

Standardni code review, ktere dela software lepsi. Mate tri tydny stare informace, k dispozici je jiz druha iterace, ktera resi i odkazovane pripominky.

[pavlix]

Ta poznámka o exit-on-idle zní zajímavě. To asi ještě není nikde řešeno, že? Program se ukončí, ale jen v případě, že by po něm nezbyly zprávy, které měl ještě zpracovat.

[little.owl]

Cele tohle bylo reseno, nekolikrat, vetsinou blbe a navic to nikdo nakonec neudrzoval. Pokud to bude v kernelu, mame udrzovany a dobry standard.

[pavlix]

Vím minimálně o několika projektech, kde se tento požadavek už objevil. Další věc je, že NetworkManager přešel před časem na přímý socket pro early boot, což myslím používalo i systemd, takže teď používá dbus aktivaci, která v systemd nejde vůbec ovládat a nebude se to už v rámci klasického dbusu řešit a k tomu ještě klasický socket. A teď systemd funguje tak, že by člověk měl zvlášť vypínat/zapínat sockety, i když se dají služby různě svazovat, důsledkem toho je, že postavit služby pro NetworkManager není úplně triviální.

S kdbusem by podle mě odpadl důvod pro dvojí IPC a tím by se to celé zjednodušilo. Chybějící funkcionalitu systemd, se kterou se čekalo na kdbus vůbec považuju za velký problém. Někdo může právem namítnout, že je to funkcionalita, která by bez systemd nebo některých jeho částí či jiných funkcí nebyla potřeba, ale počítače jsou hlavně o tom, aby řešily problémy, které by bez nich nebyly, že.

Vidím to tak, že kdbus má šanci posunout systemd na trochu použitelnou úroveň i pro dbusové služby. Trochu čára přes rozpočet jak odpůrcům systemd, tak odpůrcům dbusu.

[mirec]

Ľudia už pretaňte používať slovné spojenie systemd haters / odporcovia systemd. Uvedomte si, že žiadni tú nie sú. Sú len ľudia ktorým vadí požiaranie rôznej funkcionality jedným projektom. No a potom je tu tá vec. Lenart. Všimol si niekto vlnu protestov keď kernel prebral loadovanie firmvéru? Nie pretože kernel je síce monolit ale každý má možnosť skompilovať ho na mieru.

[pavlix]

Ľudia už pretaňte používať slovné spojenie systemd haters

Nepoužívám.

odporcovia systemd.

Nevidím důvod přestat používat. Existuje kategorie lidí, kteří mají názor, že je koncept systemd od začátku špatně, nevěří tomu, že má smysl to jakkoli opravovat, a rádi by, aby jim ten software zmizel z očí. Bedňa ti to vysvětlí. Pak existuje další kategorie lidí, kteří jsou toho názoru, že se systemd mělo rozvíjet jen jako init a správce služeb. Důkazem budiž různé iniciativy od podpory sysvinitu, upstartu a openrc až po různé forky částí systemd. Kdyby ani to nestačilo, Bedňa ti to vysvětlí.

Uvedomte si, že žiadni tú nie sú.

Bullshit. Znám osobně několik lidí z první výše uvedené skupiny, další znám po netu, další jsou za již zmíněnými iniciativami. Popírání jejich existence je hrubá urážka, které se nedopustil ani Lennart.

[mirec]

Myslím, že bedňa nepatrí do tej kategórie (poznám ho trochu lepšie asi). Mňa by tiež niekto označil ako odporcu systemd. Používam na svojich strojoch openrc. Kedysi dávno som experimentoval s einit-om, ten sa mi páčil. Potom upstart ale ten je trochu previazaný s ubuntu. No a potom systemd. To bola ešte doba keď som chcel čo najrýchlejší štart (momentálne na to až na embeddd kašlem). Chvíľu som ho používal, potom zahodil. Na určité nedostatky v mladých projektoch som zvyknutý, tie by som prekusol. Ale že to bootovalo pomalšie než pred tým a v minimálnom systéme to malo > 100 unitov! (s openrc som mal dokopy 7 o ktorých som vedel presne čo robia) Ja by som veľmi veľmi rád prešiel na systemd, ale to sa musí dať vyhádzať všetko to čo tam nechcem podobne ako sa to dá z kernelu ...

No a potom je tu požieranie všetkého možného. Nemal by som nič proti tomu ak by bola každá časť dodávaná samostatne s možnosťou výberu či chcem nejaký nedorobok integrovaný so systemd alebo niečo iné (nedorobok v zmysle neimplementuje celé RFC, neumožňuje niečo čo potrebujem ...).

[kralyk z abclinuxu]

Ja by som veľmi veľmi rád prešiel na systemd, ale to sa musí dať vyhádzať všetko to čo tam nechcem podobne ako sa to dá z kernelu ...

To afaik jde, kromě journald.

[mirec]

Nejak som to neštudoval lebo to bolo moc veľké na mňa. Spýtam sa teda konkrétnejšie. Dá sa vypnúť aktivácia služieb udalosťami (nikdy som to nemal rád), socketmi (tie blbosti ako load balancing to aj tak neimpelementuje, takže si riešim aktiváciu posvojom), celá tá hŕba plug unitov, proste ponechať len čisté nič čo primontuje disky podľa fstabu, spustí getty, vymaže /tmp, spustí cron, dbus, syslog-ng, udev, hdparm -B 255 /dev/sda, slim, pppd, iptables-restore a dokopy 2 a pol služieb čo používam na stroji?

[pavlix]

Není vůbec zjevné, na co se ptáš. Zcela vypínat socketovou aktivaci je pitomost, ty služby na tom jsou postavené a musel bys předělat unity pro všechny služby. Nicméně svoje služby si můžeš psát, jak chceš a tedy vůbec nemusejí být aktivované jinak než přes systemctl start nebo závislostmi. Můžeš teoreticky vyčistit celý systém od různých vestavěných unit, které automatizují věci, které nepotřebuješ, otázka je, jestli má smysl si s tím dávat práci a pak to ještě udržovat vůči změnám v systemd, které třeba přidají další takové unity.

[mirec]

OK, to mi ako odpoveď postačuje, dik.

[pavlix]

Jinak, ta práce by určitě měla smysl, pokud by i upstream chtěl udržovat nějaký minimalistický profil a nové patche by s tím musely počítat.

[mirec]

Ja som si už celkom zvykol, že na mňa upstream kašle. Sám si prevádzkujem gentoo + paludis s vlastnými patchmi pretože vývojári si myslia, že na mojom filesystéme nemusí fungovať. Takže mám nastavený pekne vlastný adresár s patchmi. Pôvodný plán bol skúsiť systemd, opatchovať ho tak aby unity hľadal v /etc (čiste z praktických dôvodov - to čo je v etc musím potvrdiť pri aktualizácii takže sa mi tam len tak hocičo nedostane). Mám jednoducho gentoo rád pretože automaticky toho moc nerobí, nepridáva služby, ak nejaké init skripty upravuje tak to musím potvrdiť.

Takže ten predchádzajúci komentár interpretujem "dá sa to, ale je to pracné".

Za najviac killer funkciu pre mňa považujem peknú syntax unitov (v porovnaní s init skriptami). Nie že by sa v gentoo nedali urobiť deklaratívne init skripty ale vždy mi to pripadá také nabastlené, ukážka napr. cron:

command=/usr/sbin/cron
pidfile=/var/run/cron.pid

depend() {
	use clock logger
	need localmount
	provide cron
}

[pavlix]

Provozuju hromadu vlastních patchů, ale i většiny z nich je finálním cílem upstream.

Pôvodný plán bol skúsiť systemd, opatchovať ho tak aby unity hľadal v /etc (čiste z praktických dôvodov - to čo je v etc musím potvrdiť pri aktualizácii takže sa mi tam len tak hocičo nedostane).

Nestačilo by nakonfigurovat Gentoo tak, aby považovalo i /usr/lib/systemd za konfigurák? Popřípadě jinak pořešit kontrolu nově přidaných souborů na uvedené cestě?

Za najviac killer funkciu pre mňa považujem peknú syntax unitov (v porovnaní s init skriptami). Nie že by sa v gentoo nedali urobiť deklaratívne init skripty ale vždy mi to pripadá také nabastlené, ukážka napr. cron:

Hlavně má systemd dobře udělaný systém závislostí, což se o Gentoo rc říct nedá.

[mirec]

Nestačilo by nakonfigurovat Gentoo tak, aby považovalo i /usr/lib/systemd za konfigurák? Popřípadě jinak pořešit kontrolu nově přidaných souborů na uvedené cestě?

Dalo by sa, ale gentoo neupozorňuje na vytvorenie súboru. U /etc/init.d mi to nevadí lebo tam kým explicitne nepovolím službu tak sa jednoducho nezapne. Presun unitov do /etc by mi zabil 2 muchy jednou ranou - nemusím nič konfigurovať a pri upgrade systemd sa tam nedostanú nové unity.

[pavlix]

U /etc/init.d mi to nevadí lebo tam kým explicitne nepovolím službu tak sa jednoducho nezapne.

To stejné platí pro systemd, pokud ho tak nakonfiguruješ, klíčové slovo je systemd-preset. Nové unity se nainstalují, staré unity se upraví, ale nové se automaticky nezapnou, stejně jako je tomu v /etc/init.d.

[pavlix]

Myslím, že bedňa nepatrí do tej kategórie (poznám ho trochu lepšie asi).

To je bezva, že máš zákulisní informace, ale na abclinuxu se tak prezentuje.

Mňa by tiež niekto označil ako odporcu systemd.

Tebe jsem ani dosud nijak neoznačoval, takže můžeš být klidný.

[Bedňa]

To som rád že som spolu s little.owl označený za etalon systemd haters no každý z opačnej strany. To že sa už nejaký čas do týchto diskusií nezapájam niekomu uniklo :)

Nezapojil by som sa ani teraz nebyť toho že odchod Iana bol prezentovaný pozitívne a prakticky označený ako jediný problém. Som s Linuxom už pár rokov a na podobné trieštenie komunity si nepamätám, zlatý Miguel.

[pavlix]

Co si pamatuju, tak jsi tu nedávno propagoval boycott-systemd, ne?

[Bedňa]

Buď som o tom napísal, alebo len súhlasil sám si na to úplne nepamätám, ale neviem či to nebola aj posledná diskusia kde som napísal že s vyjadrovaním sa k tejto téme som skončil. So záujmom som od vtedy už len čítal, túto mám tiež celú prečítanú. Mám z toho dve ponaučenia, ani jedna strana neberie argumenty tej druhej a nestojí za to si robiť nepriateľov. Samo že teba aj little,owl beriem za priateľov z tohoto portálu a dúfam že raz prezriete :)

So long.

[pavlix]

Samo že teba aj little,owl beriem za priateľov z tohoto portálu a dúfam že raz prezriete :)

Tomu mám rozumět jak?

[little.owl]

Nacpal te se slzou v oku do me skatulky!

[pavlix]

To by přece...

[Bedňa]

Samo že teba aj little,owl beriem za priateľov z tohoto portálu a dúfam že raz prezriete :)

Tomu mám rozumět jak?

Tak si tam namiesto "a" daj bodku, prišla mi tá poznámka humorná v kontexte tohoto vlákna.

[pavlix]

Tenhle humor asi nedávám :).

[little.owl]

To som rád že som spolu s little.owl označený za etalon systemd haters no každý z opačnej strany.

Padouch nebo hrdina, my jsme jedna rodina .

[Bedňa]

Jasne bratu :)

[little.owl]

Ja bych rozlisil hatery a kritiky, i kdyz zkratkovitost a polarizace flamu muze nekdy stirat rozdily. Bednu, jak ho tady za ty roky znam, bych za hatera neoznacil.

[pavlix]

Potom kdo z nás kritikem není ;).

[j]

Navic ti i za 10let dost pravdepodobne vse pobezi i na 10let starym kernelu.

[little.owl]

Tam byl i silny tlak ze strany Genivi, kteri byli po vymeteni AFBUS docela dost rozladeni, a kdbus jim vytrhl trn z paty. V automotive je message based komunikace mezi moduly a jednotkami standardem, lide jsou na to zvykli (a porad mi to cpou pri review do architektury), existuje na to plno toolu a SW. GKH dava uz i historku "crazy automotive developers" obcas k dobru.

[Migi]

Jsem jediný, kdo systemd fandí, nebo jen ostatní mě podobní nemají potřebu neustále o tom flamovat? :)

[Václav "Darm" Novák]

Nejsi. Pár věcí by se, pravda, změnit mohlo. Ale zatím neznám jedinou uspokojivou náhradu.

[kralyk z abclinuxu]

+1, přesně tak. Až/jestli bude někdy čas, docela bych vyzkoušel uselessd.

[Bedňa]

Škoda že sami autori systemd neponúkajú možnosť použitia samostatného initu. Byť toho že sa napoja na ostatné projekty, tak tu neexistuje ani táto diskusia.

[Honza Jaroš]

Kdybyste byl jediný, neměla by tahle diskuse 188 příspěvků. Flame bez oponentů poněkud nefunguje...