Lennart Pottering o budoucích plánech

Na blogu Lennarta Poetteringa vyšel článek, kde popisuje svůj pohled na budoucnost Linuxového user space. Revisiting How We Put Together Linux Systems

1.9.2014 15:44 | lnykryn | Zajímavý článek

Komentáře

[Václav "Darm" Novák]

100, nebo pokorime i 200? :)

[Irvín]

+1

[j]

300 ... pevne doufam, ze ho nekdo povesi ... aspon za kulky do pruvanu.

[martin]

ja zas doufam, ze jednou naleznes lasku. nejlepe zeny...

[Honza Jaroš]

200

[ljhlkjh]

Tyvole, to je strasna picovina...

[ikarr]

+1

[Robert Šmol]

Nějaká konkrétní konstruktivní kritika by nebyla? Tohle plivání je nízké.

[ikarr]

-1

[Petr Ježek]

+10

[Karel]

Ten člověk mě vždycky překvapí. Při čtení jeho plánů do budoucna jsem měl lehké mrazení v zádech...

[Bubak]

Hu, jesteze tak. Tim vznikne Lenartinux a doufam, ze prestane otravovat a normalni distra budou moct fungovat v pohode dal

[deda.jabko]

Normalni clovek by si zalozil vlastni distro a pockal, jak se to uchyti, ale tihleti iluminati maji vetsi ambice. Co me desi:

The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, and yours truly) recently met in Berlin about all these things, and tried to come up with a scheme that is somewhat simple, but tries to solve the issues generically, for all use-cases, as part of the systemd project. All that in a way that is somewhat compatible with the current scheme of distributions, to allow a slow, gradual adoption.

(1) Co puvodne vypadalo jako dobry napad pro spravu procesu, bude opravdu nakonec omnipotentni zrudnost, starajici se o vsechno vcetne spravy balicku.

(2) Samozrejme, proc bysme se zabyvali nejakou kompatibilitou?

(3) ...aneb jdeme varit zabu.

[pavlix]

Co puvodne vypadalo jako dobry napad pro spravu procesu

Kdy přesně to vypadalo, že zůstane u správy procesů? Co má chudák Lennart dělat po takto fenomenálním úspěchu než pokračovat ve svém celoživotním díle? ;)

...aneb jdeme varit zabu.

Mám pocit, že žába už je značně rozvařená.

[TM]

A nešlo by toho magora nějak pacifikovat? Neříkejte, že u vás ve firmě s tím przněním Linuxu všichni souhlasí. Tomu prostě nevěřím. Třeba ho vykopnout někam na manažerskou funkci, kde by se nedalo tak škodit. Možná i pobyt v léčebném zařízení by mohl být řešením...

[pavlix]

Neříkejte, že u vás ve firmě s tím przněním Linuxu všichni souhlasí.

Mění to na věci něco?

[Robert Šmol]

dedo.jabko, chápete co řeší za problémy RedHat? Jaké jsou potřeby jejich klientů? Pokud se nad tím zamyslíte, uvidíte, že to co tady lidé kolem Lennarta dělají, je řešení škálování Linux/RedHatu tak, aby to byla nadále platforma která vydrží dalších 5-10 let. Proto nezakládají distro, už ho mají.

Ty problémy co tam na začátku popsal, se týkají i desktopářů, jak mám na Fedoře bez problému pustit aplikace, které jsou rozběhané jen na Ubuntu (namátkou QtSixa).

Nevím proč vám nefunguje správa procesů, ale Fedora i díky systemD je stabilní, bootuje velmi rychle a je konečně jeden rozumný nástroj pro multiplatformní nasazení námi napsaných serverových aplikací (prostě teď dodáváme 5x service files a jede to).

Kde vidíte problém s kompatibilitou? Já to chápu tak, že aplikace, které se rozhodnou využít těchto nových features (cryptograficky oveřené prostředí, immutable, zaručené updaty, sandboxing) proste budou dodávat kromě tarbalu i balíčky v této nové podobě a pokud to Váš systém bude podporovat, nainstaluje aplikaci novým způsobem.

[lol]

Redhat hlavně řeší, jak naroubovat do linuxu šmírování tak, aby si toho nikdo nemohl všimnout. A metoda "zabalit do do balastu" je stará osvědčená.

[Petr Ježek]

Upřesnit, prosím!

[lol]

Stabilita díky systemD jsem nějak nepochopil. Fedora 20 se mi zavěsila naposledy před deseti minutami. Stará dobrá F14, kterou mám na desktopy leta se nezavěsila nikdy. A taky - systemD je jedna z mála věcí, která dovede zapisovat na disk, který je přimontovaný read-only. Takže pokud dovede tohle, nedivím se, že ho jisté struktury tlačí do všech distribucí.

[pavlix]

systemD je jedna z mála věcí, která dovede zapisovat na disk, který je přimontovaný read-only

Dobrý základ pro konspirační teorii, ale hádám že fakta nebudou znít až tak zajímavě jako tento výkřik.

[Jendа]

Mně systemd zapsal na CD-ROM v nevypalovací mechanice.

[Václav "Darm" Novák]

Mně zabil kočku.

[lol]

Tvému tvrzení nevěřím. Zato systemD zapisovat na rootovský svazek, který byl remontovaný read-only, jsem viděl na vlastní oči.

[Jendа]

Jako že si ho to remountlo rw?

[lol]

Neremountlo so to rw. Byl pořád ro (kontrola pomoci touch). Všechny procesy kromě kernelových byly vypnuty, včetně journald. SystemD ale stále držel disk "busy" (nešel remoutnount zpět na rw). Disk se uvolnil až poté, co jsem systemD respawnul.

[pavlix]

Čekám na ta převratná fakta.

[Václav "Darm" Novák]

Problem komercnich uzavrenych aplikaci byl vzdy ten, ze se tvurce nemohl spolehnout na jednotne prostredi. Tohle je celkem elegantni reseni. A nahradit klasicke balicky si to za cil neklade - vzdyt v tom dokumentu Lennart pise ze je to pro spoustu pripadu vyborny koncept. (Navic to proste bez btrfs nebo filesystemu s podobnyma vlastnostma fungovat nebude)

[omg]

samozrejme tam mate hnedle nekolik chyb. Vznikne: Le Art in UX.

[Josef Kufner]

Vypadá to, že si našel novou hračku. To by mohl být příští rok systemd už použitelný.

[AsciiWolf]

[Ruža Becelin]

Ja mel za to, ze vendor doda .run balik, ktery se nalije do /opt a nezasahuje do systemu. Tohle vypada jako prezvejkany koncept, co ma Apple - nedal mu nekdo k Vancum Mac?

[s0]

On už o tomhle hovoří delší dobu. Já, resp. můj zaměstnavatel, by něco podobného ocenil. Jenže tohle kombo Lennart/Kay má dar dělat věci trošku složitější.

[Gilhad]

Nejak jsem nepochopil, jak by se v tomto schematu resilo, kdyz:

- mam nejakou aplikace A, B ktere maji smysl samy o sobe (a samy mohou byt skupinou zamenitelnych aplikaci se stejnou funkcnosti) a aplikace C, D, E, ktere je pouzivaji a nemaji bez ni smysl (vztah zhruba PAGER (less,more...) a EDITOR (vim, nano ...) vs. ruzne shellscripty a terminaly)

-- pokud dam A a B do app: tak musim resit vztahy mezi aplikacemi

-- pokud dam A a B do ruznych runtime: tak jak se urci, ktere vsechny runtimy potrebuje treba C, a pokud je dam do jednoho a C ho bude mit jiny nez D, tak se mi chovani C a D bude lisit pri strankovani

--- pokud dojde k sebemensimu (bezpecnostnimu) updatu A, tak to bude znamenat znovu zabalit a nainstalovat C,D,E v novych verzich, ackoli se nezmenily?

Jak chce resit, pokud treba cron vola pro kazdeho uzivatele nejakou ulohu - uzivatel neni zalogovany, nema namountovany HOME, cili budeme mountovat a odmountovavat jak o zivot? A resi to vicenasobne prihlaseni, kdyz je uzivatel prihlasen z nekolika mist a do toho ten cron a uzivatel se zacne postupne odhlasovat?

A jak se resi, kdyz vice uzivatelu sdili jeden adresar?

[.....]

Bind mounty a filesystem namespacy.

[Pali]

Mohol by uz niekto tomu cloveku povedat do oci, nech prestane jebat do userspacu a nutit ludi (cez vsetky distribucie) pouzivat tie jeho nezmysly? Nie kazdy s nim zdiela rovnaky nazor a pohlad na vec a nie kazdy ho ma zaujem uctievat ako boha.

[Václav "Darm" Novák]

Tak tohle snad ani jako povinná vlastnost udělat nejde.

[martin]

mno pokud pro tebe pouzivat software znamena uctivat jeho autora jako boha, tak to musis mit tezkej zivot, wtz!

[Irvín]

Pise tam presnej opak...

[martin]

zkus si to precist jeste jednou ;)

[j]

To by ses musel nejdriv naucit cist ty.

[mankind_boost]

Ted ses pekne ztrapnil

[pavlix]

+1

[mankind_boost]

wat?

[pavlix]

Martinova první reakce mi přijde zcela adekvátní.

[mankind_boost]

Utoci na autora kvuli necemu, co nerekl. Neprekvapuje me, ze ti to prijde adekvatni.

[pavlix]

Utoci na autora kvuli necemu, co nerekl.

Podle mě nikoliv.

[mankind_boost]

Podle me ano.

[pavlix]

Fajn, alespoň zajišťujeme pestrost názorů a interpretací.

[biolog]

Pottering nikoho nenutí. Nevím proč distribuce systemd a jiné potteroviny přecházejí, když jsou tak špatné (jak diskutéři píší).

Pokud distribuce přejdou i na tuhle vlastnost, tak jejich uživatelé budou muset přejít taky, třeba k jiné distribuci. Ale v tom případě ty lidi budou nutit distribuce (a GNOME atd), ne Pottering. Ten distribucím (a GNOME atd) nabídnul kód, ony samy si ho vybraly. Tomu se říká svoboda volby (pro distribuce). (Lidi si vybírají distribuce; nebo si vybírají mimo-distribuční software jako doplněk, to je jejich svoboda volby.)

Myslíte že Pottering nutí tím, že vyhrožuje, že uškodí linuxu? Nebo hrozí, že neudělá to něco, co má povinnost udělat?

[Pali]

Nie, Poettering uz nemysli...

[Ivan]

Pottering opravdu nikoho nenuti. On proste produkuje dost kodu - a celkem kvalitniho kodu a diky tomu si muze delat co chce. Jeho "produkty" - at jsou jakykoliv - nemaji konkurenci protoze alternativy jsou casto horsi (tim myslim hlavne vsechny alternativni sound daemony). Svet opensource ted ridi lidi, kteri jsou za to placeni. Nikdo koho open-source bavi nemuze konkurovat lidi, kteri se tomu venuji na full-time.

[ikarr]

Svet opensource ted ridi lidi, kteri jsou za to placeni. Nikdo koho open-source bavi nemuze konkurovat lidem, kteri se tomu venuji na full-time.

Je to tak. Idea opensource prodala svou svobodu.

[JS1]

Nechapu, jak ten fakt omezuje tvoji svobodu? "Idea opensource" neni zadna bytost, ktera by mohla udelat nejake umyslne rozhodnuti. Je jen na lidech, jak s tim nalozi.

[.....]

Nemyslím si, Lennartovi zakazovali začít pracovat na systemd v práci, tak si vzal dvou týdenní dovolenou a napsal to ve svém volném čase. A i teď do systemd přispívá spousta vývojářů, kteří na něm pracují ve svém volném čase.

[JS1]

Shodou okolnosti ve stejnou chvili na HN vysel jiny clanek, ktery myslim Lennarta dobre vystihuje (ale nejsem z RH a v Linuxu jsem jen pouceny laik).

[Tomáš Bžatek]

V tom mas docela pravdu. Je to videt na spouste projektu.

[pavlix]

Svet opensource ted ridi lidi, kteri jsou za to placeni. Nikdo koho open-source bavi nemuze konkurovat lidem, kteri se tomu venuji na full-time.

Dříve se to stejné říkalo o open source jako takovém v souvislosti s komerčním closed source. Především je i tady na abclinuxu vidět, že většinu o open source baví mluvit, nikoliv ho tvořit.

Je to tak. Idea opensource prodala svou svobodu.

A idea idey prodala svou ideu, že.

[biolog]

Především je i tady na abclinuxu vidět, že většinu o open source baví mluvit, nikoliv ho tvořit.

+1

(Matně si vybavuji, že jsem něco takového před rokem řekl taky. A dostal jsem za to pěkně vyhubováno, co že si to dovoluji.

[Marián Kyral]

Díky za námět. Dovolil jsem si redakci navrhnout anketu na toto téma.

[Václav "Darm" Novák]

No vidíš. A teď jsme na to málem zapoměli Napravím. (ale jinak souhlas)

[Václav "Darm" Novák]

Především je i tady na abclinuxu vidět, že většinu o open source baví mluvit, nikoliv ho tvořit.

Proč lžeš?

[kavol]

alternativy jsou casto horsi (tim myslim hlavne vsechny alternativni sound daemony)

tak naokraj, kolik toho víš třeba o JACKu?

[Václav "Darm" Novák]

Ja treba JACK pouzivam hodne. Neda se to porovnavat, oboje resi jine problemy.

[kavol]

Neda se to porovnavat ...

no, kolega zjevně porovnává ... jinak myslímže bychom měli (pokud bychom to chtěli nějak seriozně řešit, což se mi tu fakt nechce) především začít otázkou, nač jsou ti démoni vůbec potřeba ...

[Václav "Darm" Novák]

Ano, měl napsat „Alternativy jsou pro účel domácího počítače všechny horší“

Nač je PA už nebudu rozepisovat, flamů je na to dost. JACK je pro to naprosto nevhodný, ale pro tvorbu hudby, rt modulaci zvuku apod. je to nejvhodnější řešení. (jiné rt řešení vlastně asi není)

[Josef Kufner]

Co vlastně Jacku chybí, aby mohl zcela nahradit Pulseaudio, opomeneme-li rozšířenost podpory v aplikacích?

[Václav "Darm" Novák]

Větší zátěž systému a náchylnost na zátěž, podpora v aplikacích, není to (momentálně) úplně pohodlné na ovládání když se v tom člověk nechce hrabat (což v případě profi audia opravdu chce, ale jako domácí uživatel ne), nastavování hlasitosti jednotlivých streamů, nevím jak je na tom s podporou bluetooth zařízení.

[Václav "Darm" Novák]

Jo a ještě nevím jak to funguje s vícero zvukovkama, mám JACK do SB Live a PA do integrovaného realteku.

[Petr Ježek]

To je přesné. Mimochodem, dost vývojářů a maintainerů nemělo kapacity na řešení toho, s čím přišel Lennart, takže zcela logicky po tom sáhli, otestovali, zjistili funkčnost a potřebnou stabilitu, zapracovali do systému, zabalili a vydali. Takže to zdejší hudrání je spíše přiznáním vlastní neschopnosti vymyslet a vytvořit žádanou alternativu ke stávajícímu. Už mne nebaví čít záplavu bezduchých štěků nijak nesnižujících entropii.

[pavlix]

Už mne nebaví čít záplavu bezduchých štěků nijak nesnižujících entropii.

Proč bys měl chtít snížení entropie?

[Irvín]

Cekal jsem, ze neco takovyho Lennart vymysli uz tehdy, kdyz vymyslel vlastni verzi FHS.

 

Jeden system, jedno distro, jeden vudce. Hail Lennart!

[skunkOS]

On to určitě už tehdy vymyslel, ale ovečky musíš vést pomalu a opatrně.

[backinabag]

Uplne se mi to nezda, na prvni pohled divny a neelegantni, ale porad lepsi nez soucasny stav. Libilo by se mi, kdyby existoval jeden dobre navrzeny balickovaci system, a linuxova distribuce by pak nebylo nic jineho, nez mnozina balicku.

[Gilhad]

A kdyby existoval jeden dobre navrzeny FS a jeden dobre navrzeny editor ... ale problem je, ze ruzni lide maji ruzne predstavy a potreby.

[backinabag]

U standardu, platforem a API neni dobra fragmentace. Predstav si, ze by si kazda distribuce upravovala API linuxoveho jadra.

V dnesni dobe by jednotny balickovaci standard (ktery by vsichni dodrzovali, ne jako rpm) zpusobil vic dobra nez zla, protoze balickovaci systemy uz jsou pomerne dospela technologie. Vem si kolik casu a energie jde do vytvareni balicku pro x ruznych distribuci, pri tom to je v podstate duplicitni prace.

[Gilhad]

No, standardizovany system, ktery by spojoval vyhody .deb .rpm a .ebuild a pritom byl prehledny a cisty a nebyl to kockopes a bastl si nejak neumim predstavit.

A jeste min si umim predstavit, ze vsichni, kdo jsou zvykli na urcity typ prace a vsichni, kdo vyvyjeli ty ruzne systemy podle svych potreb najednou vse zahodi a prejdou na nej.

[Roslav]

Jj,dopadlo by to asi takto: Standards

[JS1]

Cetl jsem to na HN, a tesil jsem se, ze nekdo napise zpravicku..

Myslim si totez. Problemy, ktere se to snazi resit si jiz aspon dekadu zaslouzi vyresit, ale jestli je to ten spravny pristup, nevim. Jeste se to asi bude vyjasnovat.

[backinabag]

Cetl jsem to na HN, a tesil jsem se, ze nekdo napise zpravicku..

Do tehle diskuze jsem se dostal stejnou cestou

[JS1]

Tak jsem si to konecne poradne precetl, a myslim, ze je to revolucni napad. Konecne package management, ktery nema moznost provozu vic verzi jen tezkopadne nasroubovanou, ale je primo v zakladnim navrhu. (I kdyz na HN odkazovali na Nix, to je krok urcitym smerem, ale neco tomu chybi.)

Spousta lidi z toho bude nervozni, a asi pravem. Slozil dohromady skladacku, ktera vubec nevypada jako skladacka, protoze to vsechno tak pekne zapadlo (treba to pouziti btrfs!). Takze spousta lidi tu skladacku oznaci prvnim pohledem za monolit.

[kavol]

Takze spousta lidi tu skladacku oznaci prvnim pohledem za monolit.

a druhým pohledem taky

už jsi někdy viděl, aby v Lennartových "skládačkách" šel nahradit jeden dílek jiným, vyjma přechodných období, kdy potřebuje v rámci salámové metody ("my vám to nebereme, my si tady jen něco přidáme") dočasně zachovat kompatibilitu? - co třeba ten udev, co měl dle prohlášení před pár lety zůstat použitelný i nezávisle na systemd? (prohlášení formálně nelhala, on vlastně něco přes dva roky zůstal, nikdo neřekl, že to tak bude na věky, že ...)

[JS1]

Asi by bylo lepsi se bavit konkretne nad timto navrhem a nedelat pochybne analogie se systemd, pulseaudio apod. (Jinak si prece stale muzes udev forknout a udrzovat sam - svoboda OSS prece neni o tom, ze to nekdo musi udrzovat.)

už jsi někdy viděl, aby v Lennartových "skládačkách" šel nahradit jeden dílek jiným

No, pokud jsou ty dilky zvoleny opravdu dobre, bude to tezke. Ale ja narozdil od tebe v tom vidim spis kvalitu navrhu (dobre vybrane dilky) nez spatnou nahraditelnost.

Vezmi si treba to pouziti btrfs. Co vim, vsechny predchozi systemy se snazily podobne problemy (dependency hell) resit pres symbolicke linky. Posunout to do deduplikacni vrstvy je genialni krok, ktery spousta veci zjednodusuje (spravu linku), ale samozrejme predpoklada, ze je k dispozici dostatecne pokrocily FS, ktery to umi.

Tedy, ten navrh neni zavisly na btrfs, spis na jeho vlastnostech, ktere jsou unikatni. A tak je to u mnoha tech dilku.

[trekker.dk]

Asi by bylo lepsi se bavit konkretne nad timto navrhem a nedelat pochybne analogie se systemd, pulseaudio apod.

Označením té analogie jako pochybné Lennártovi neodpářete konzistentní styl.

No, pokud jsou ty dilky zvoleny opravdu dobre, bude to tezke.

Není problém ve volbě dílku ale v nerozdělitelnosti "skládačky". Příkladem budiž journald. (Ne, opravdu nemůžete přijít s rozumným argumentem, proč logování musí zajišťovat právě tento program.)

[JS1]

Není problém ve volbě dílku ale v nerozdělitelnosti "skládačky". Příkladem budiž journald.

Mozna me nekdo opravi, ale jak to chapu ja, tohle neni pravda. Lze pouzivat systemd i bez journald.

[j]

Jiste, pokud nechces logovat. Pokud logovat chces, tak to tam mit musis. Bez toho to nefunguje.

[......]

[Citation Needed] Co mi brání si spustit rsyslog a normálně poslouchat na /dev/log jak se to dělalo dřív?

[kralyk z abclinuxu]

$ ll /dev/log
lrwxrwxrwx 1 root root 28 27. srp 21.14 /dev/log -> /run/systemd/journal/dev-log

Heh...

[......]

Je to symlink, můžu ho smazat a udělat vlastní.

[Peter Golis]

Zmenu symlinku nie je treba. Ja mám jednoducho zo SystemD zapnutý SyslogNG.

[kralyk z abclinuxu]

No jo, to máš ale systemd → journald → syslogng (forwarding), ne?

[Peter Golis]

Skús.

[tqwert]

Nelze. A nelzi, nepomuze ti to.

[Václav "Darm" Novák]

Lze, když nechceš logovat

[JS1]

No, googlil jsem to, a nekdo tvrdil, ze to jde. Sam jsem to nezkousel a nemam tu potrebu.

[----]

blbost, v podstatě všechno (a ještě víc) co btrfs umí uměl zfs už dřív.

[JS1]

Nerikam, ze ne - IMHO kdyby jsi nahradil "btrfs" v tom dokumentu "zfs", bude to stejne validni.. Akorat to asi nepobezi na Linuxu.

[kavol]

Asi by bylo lepsi se bavit konkretne nad timto navrhem a nedelat pochybne analogie se systemd, pulseaudio apod.

"analogie"? - systemd (a tedy jím pohlcený udev) snad není přímo součástí konkrétně tohoto návrhu?

[JS1]

Ja to ctu, tak primo neni. Stejny koncept muze fungovat s libovolnym PID 1 ekosystemem.

[JanM]

Panečku, to je tu v diskuzi štěkajících psů, že? Mně se konkrétně tato lennartovina také líbí. Konečně něco zaměřeného uživatelsky. "Výhodu" roztříštěného linuxového desktopu tu máme desítky let a je to P.I.T.A.

Koncekonců, odpůrci mohou bez problémů provozovat nekonečné množství vlastních distribucí prostých lennártovin, nač tedy vlastně ten vztek? Asi, že jsou v menšině a vývojáři těch hlavních je nechtějí poslouchat? To jim pořád nedošlo, že FOSS není demokracie?

[Marián Kyral]

Hmm. Fakt nechci mít na disku X kopií téhož, jen v jiné verzi. A kam to vše nakonec povede je vidět na případu Skype. Nová verze vyžaduje PA a starou zařízli. Fakt super.

Místo aby se tlačilo na otevřené protokoly a otevřené zdrojáky, tak se naopak chystá přímá podpora uzavřených programů. Nic jiného v to není.

[pavlix]

Lennart se nikdy netajil tím, že linuxovou a unixovou filosofii nechápe a že linuxové komunitě nerozumí. Podle mě jsou jeho rozhodnutí do značné míry pragmatická s ohledem na kariéru a tedy i potenciální zaměstnavatele. Musím říct, že mi to z tohoto pohledu dává celé smysl.

[JS1]

Jenze bohuzel bez te podpory uzavrenych programu bude mit Linux stale ta 2%. Coz je vec, kterou ja si uvedomil uz asi pred 10 lety (ze by nekdo mel vyrobit infrastrukturu, ktera jde na ruku komercnim vyvojarum), a proto mi asi ten Lennartuv navrh nepripada tak spatny.

Muze se ti to nelibit (a me se to taky nelibi), ale bude to podobne jako narky levicaku nad kapitalismem - jsou logicke, ale bez rozumne vetsinove alternativy.

[Hans1024]

komercni != proprietarni

A o "uspech" v podobe proprietarniho SW opravdu nestojim.

[JS1]

komercni != proprietarni

V tomto kontextu na tom nesejde. Pristup ke zdrojakum nic nezmeni na tom, ze komercni firmy typicky podporuji jen male mnozstvi konfiguraci, z obchodnich duvodu.

A o "uspech" v podobe proprietarniho SW opravdu nestojim.

Jsi jeste mlady. Myslis, ze ti nikdy nebude vadit, ze tvoje partnerka, rodice, deti, znami, nebudou chtit Linux pouzivat? Ze budes vzdy spokojeny s temi 2%?

Ono je to IMHO trochu elitarska poza (podobne jako pise Kralyk niz). Ve skutecnosti si temer kazdy prejeme, aby byl Linux masove uspesny.

[Hans1024]

Me ani tak nevadi to, ze nechteji pouzivat Linux. Vadi mi kdyz lpi na pouzivani proprietarniho SW. Linux s proprietarnim SW je asi lepsi volba nez Windows, ale podle me porad spatna volba.

[pavlix]

+1

Nevím, proč by měl člověk chtít za každou cenu univerzálně prosazovat konkrétní kus software.

[kralyk z abclinuxu]

+1, to je přesně podstata věci.

[JS1]

Hm, mne prijde ze z tohohle:

Vadi mi kdyz lpi na pouzivani proprietarniho SW.

Vyplyva opak tohohle:

Me ani tak nevadi to, ze nechteji pouzivat Linux.

Pokud lpi na pouzivani nejakeho proprietarniho SW, bud takovy SW ma pro Linux alternativu, nebo nema. Pokud ji ma, neni duvod nepouzit Linux (a podle premisy bys to mel preferovat). Pokud ji nema, nic s tim nenadelas.

[Hans1024]

Hm, mne prijde ze z tohohle:

Vadi mi kdyz lpi na pouzivani proprietarniho SW.

Vyplyva opak tohohle:

Me ani tak nevadi to, ze nechteji pouzivat Linux.

Tahle uvaha by byla spravna, kdyby jediny zpusob jak nepouzivat proprietarni SW bylo pouzivat Linux.

[JS1]

Jaky jiny zpusob mas na mysli? Pouzivat treba BSD? Ale tam plati to same. Ano, zjednodusil jsem to na Linux, protoze je nejpouzivanejsi. Pointa je, ze pokud chces aby lide pouzivali OSS, chces, aby se nejaky z tech systemu masove rozsiril.

[Gilhad]

Rekl bych re to bylo mineno spis ve smyslu, v jakem ja (jsa prinucen pracovat na Windows) jsem pouzival jako textak gvim (cili nikoli proprietalni SW)

[kralyk z abclinuxu]

Pointa je, ze pokud chces aby lide pouzivali OSS, chces, aby se nejaky z tech systemu masove rozsiril.

Non sequitur.

[Hans1024]

Pointa je, ze pokud chces aby lide pouzivali OSS, chces, aby se nejaky z tech systemu masove rozsiril.

Ne. Kdyz se Linux masove rozsiri a vsichni na nem budou pouzivat Skype, Steam a Micro$oft Office for Linux (ktere tam budou diky Lennartovo vynalezu), tak to ke svobode uzivatele zas tolik neprispeje.

Daleko dulezitejsi je napriklad to, aby se pouzivaly otevrene standarty, takze clovek, ktery si vazi sve svobody, by pak mohl bez problemu s kompatibilitou zacit pouzivat kterykoli ze svobodnych operacnich systemu a jakekoli aplikace, ktere tyto otevrene standarty implementuji.

[pavlix]

otevrene standarty

To taky, ale hlavně otevřené standardy.

[Hans1024]

Nojo, asi je spravne standardy, ale z nejakeho duvodu mi to zni strasne divne...

[pavlix]

Mám to štěstí, že mi zní strašně divně ta nesprávná (neuznávaná) varianta, už jen proto, že takových slov má čeština spoustu, včetně těch zjevně přejatých.

[JanM]

no jo, protože vy jste schopen si doladit, aby uživatelská aplikace běžela. Já si taky vytvořím AUR balíček pro Arch Linux (5 minut až několik hodin, podle závislostí a dalších problémů při kompilaci).

Má drahá polovička zvládávala nainstalovat program na Windows (pak si mně vzala a už MS Win více doma neviděla), zvládla to v iOS, zvládá to v Androidu, ale výše uvedené prostě "nedá" a ani nechce.

V Linuxu jsme zatím opravdu uvyknutí na to, že programátor aplikace dá k dispozici tar ball a (v lepším případě) pár informací ke kompilaci. A spoléhat se na to, že to pro Arch/Debian/Fedora/Suse zabalíčkuje kdosi v rámci své "hobbyist" motivace? Plýtvání silami na rutinní záležitost...

Jestli je řešením nabídka aplikace slinkované s knihovnami pro jednu konkrétní "run-time" image a v případě jiné run-time image či nepodporované distribuce se využijí vlastní knihovny přibalené k aplikaci, proč ne. Můj stolní počítač není router s 8 MB flash diskem. Inženýr ve mně je sice nespokojen malou "čistotou" řešení, ale tak už to na světě chodí. Něco za něco.

P.S. Skype mne též nejprve netěšil, ale po pár týdnech oceňuji výhody PulseAudio - instalace i běh bez problémů i nutnosti konfigurace (v KDE). Když jsem to zkoušel před pár lety, tak jsem to zase rychle smazal. Teď nelituji.

[Marián Kyral]

no jo, protože vy jste schopen si doladit, aby uživatelská aplikace běžela. Já si taky vytvořím AUR balíček pro Arch Linux (5 minut až několik hodin, podle závislostí a dalších problémů při kompilaci).

Má drahá polovička zvládávala nainstalovat program na Windows (pak si mně vzala a už MS Win více doma neviděla), zvládla to v iOS, zvládá to v Androidu, ale výše uvedené prostě "nedá" a ani nechce.

Má drahá polovička nezvládne ani to. Přesto linux bez problémů používá. Nemusí nic instalovat. Na to jsem tu já.

V Linuxu jsme zatím opravdu uvyknutí na to, že programátor aplikace dá k dispozici tar ball a (v lepším případě) pár informací ke kompilaci. A spoléhat se na to, že to pro Arch/Debian/Fedora/Suse zabalíčkuje kdosi v rámci své "hobbyist" motivace? Plýtvání silami na rutinní záležitost...

Každý dělá, co jej baví. Developer vyvíjí, balíčkovač balíčkuje.

Jestli je řešením nabídka aplikace slinkované s knihovnami pro jednu konkrétní "run-time" image a v případě jiné run-time image či nepodporované distribuce se využijí vlastní knihovny přibalené k aplikaci, proč ne. Můj stolní počítač není router s 8 MB flash diskem. Inženýr ve mně je sice nespokojen malou "čistotou" řešení, ale tak už to na světě chodí. Něco za něco.

Jaký je rozdíl oproti čistě staticky slinkované aplikaci, případně pokud si aplikace přibalí vlastní verze knihoven? Pár (možná) ušetřených mega ve sdílených kontejnerech? Hlavní problém (uzavřené binární bloby závislé na konkrétním prostředí) to nevyřeší. Dodavatel vydá nějakou verzi závislou na určitém prostředí a tím to pro něj končí. Ve výsledku bude potřeba backportovat patche do nekonečného množství kontejnerů.

P.S. Skype mne též nejprve netěšil, ale po pár týdnech oceňuji výhody PulseAudio - instalace i běh bez problémů i nutnosti konfigurace (v KDE). Když jsem to zkoušel před pár lety, tak jsem to zase rychle smazal. Teď nelituji.

Jo jo. Následuje systemd. Ten prý taky není špatný (když po něm nechceš něco odlišného). Čím to skončí?

[kralyk z abclinuxu]

A spoléhat se na to, že to pro Arch/Debian/Fedora/Suse zabalíčkuje kdosi v rámci své "hobbyist" motivace? Plýtvání silami na rutinní záležitost...

Tohle by se ale dalo řešit IMHO mnohem lépe než co navrhuje Lennart (kterej to ve skutečnosti spíš workarounduje). Např. by mohl existovat nějaký standard pro něco jako 'proto-balíček', ze kterého by se daly generovat distro-specifické balíčky.

[mankind_boost]

Od toho v lsb mame rpm. To je standardni balickovaci system. Sice mam radsi deb, ale standardy jsou tu od toho, aby se dodrzovaly.

[Václav "Darm" Novák]

Neco jako PKGBUILD? Pise se snadno a mit moznost balit z toho i RPM, DEB apod. by bylo super. Jenze to resi tvorbu balicku, ne situaci, kdy specialni (prevazne proprietarni) software potrebuje k behu specificke prostredi.

[pavlix]

Neco jako PKGBUILD? Pise se snadno a mit moznost balit z toho i RPM, DEB apod.

Pokud vím, tak gentoo ebuildy se umí buildovat do RPM. Jenže pak degraduješ RPM a DEB na pouhé formáty binárních balíků, čímž ale ignoruješ jejich hlavní rozdíly a tedy důvody, proč se vůbec různé balíčkovací systémy používají a taky proč nejsou navzájem kompatibilní.

Pokud bys chtěl splnit všechno, musel bys mít ten formát a hlavně konkrétní balíky natolik univerznální, že z nich půjdou generovat skutečné zdrojové balíky, takové jaké se dneska v praxi používají, ale to už ti zase jeden člověk nenapíše, protože by tam musel dostat všechny prvky všech distribucí a hlavně prasáckých deb balíků.

[kralyk z abclinuxu]

Jenze to resi tvorbu balicku, ne situaci, kdy specialni (prevazne proprietarni) software potrebuje k behu specificke prostredi.

To "specifické prostředí" imho v podstatě znamená jen konkrétněji specifikovanou sadu závislostí (třeba i s konkrétními verzemi et al.), ne? Zbytek už je jen balíčkovacím systému, jak dobře to dokáže pořešit. Jestli se použijou frikulínské filesystémy nebo něco jinýho už je implementační detail...

Což je další věc, která mi vadí na tom Lennartovo brainfartu - většina textu řeší právě implementační detaily spíš než obecně platné vlastnosti / návrhy.

[pavlix]

Což je další věc, která mi vadí na tom Lennartovo brainfartu - většina textu řeší právě implementační detaily spíš než obecně platné vlastnosti / návrhy.

Aneb je to takový edison.

[Grunt]

Např. by mohl existovat nějaký standard pro něco jako 'proto-balíček', ze kterého by se daly generovat distro-specifické balíčky.

On je hlavně problém už více v základu. Já když tu ten preface co Lennart napsal, tak nemůžu nic jiného než souhlasit. Je to jako kdyby mi to z hlavy opsal. No takhle bych to neřešil. Já osobně vidím problém v GNU build systému (autoconf, libtool, …). Prostě už je to starý a dnešní dobu složitý systém (cmake o nic lépe). Přitom kompilace je základ. S jakýmkoliv balíčkem co jsem si kdy zkompiloval jsem neměl nejmenší problém (a pokud ano, tak pouze mojí vinou) zcela na distribuci nezávisle. Bohužel je to poměrně složitý systém a těžko chtít po uživateli aby ho do podrobna ovládal. Přitom kdyby instalace ze zdrojáků byla tak jednoduchá jako blahé paměti v Kuroo (grafická nádstavba pro Gentoo Portage), je dost pravděpodobné že by zvládla libovolný zdrojový balíček nainstalovat i moje babička. Já osobně doufal ve vznik jakéhosi ucelené OSS repositáře právě s něčím tak jednoduchým. No bohužel, převzal to Poettering.

[Grunt]

Kuroo

Resp. Porthole. Ten jsem sice v životě nezkoušel, ale z obrázku vypadá ještě líp.

[Marián Kyral]

Já těmhle grafickým nadstavbám nad emerge nějak nikdy nepřišel na chuť. Prostě otevřu na vedlejší ploše terminál a je to.

[biolog]

Právě jedním z hlavních rysů autotools je, že uživatel o jejich fungování nemusí vědět nic. Zadá ./configure s případnými parametry, a pak make a make install. Zato programátor to schytá...

[pavlix]

To vnímám jako velkou výhodu autotools a taky autotools udávají docela dobrý standard pro configure skripty a makefiles, který bohužel jiné systémy včetně cmake ani zdaleka nedodržují.

Vývojáři si to sice schytají, ale zatím mám dojem, že si to s každým jiným řešením buď schytají mnohem víc a nebo nedosáhnou odpovídajícího výsledku a značně tak zkomplikují práci druhým. Musím říct, že cmake mě nijak nenadchl a u custom makefiles co chvíli narážím na problém s věcmi, které jsou u autotools samozřejmostí.

[Josef Kufner]

Když jsem autotools před pár lety zkoumal, chvilku jsem koulel očima a pak šel dělat něco užitečnějšího. Ne že by se to nedalo rozchodit, ale ve srovnání s qmake to je naprostá zrůdnost.

[Václav "Darm" Novák]

I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.

[kralyk z abclinuxu]

[pavlix]

ale ve srovnání s qmake to je naprostá zrůdnost.

Nechce se mi autotools srovnávat s ničím, co nemá stejný účel, flexibilitu a rozsah funkcionality.

[Grunt]

uživatel o jejich fungování nemusí vědět nic.

Uživatel z minulého tisíciletí. Uživatel ze současného tisíciletí nebude rozbalovat tar, hledat README, číst to instalovat závislosti, nastavovat RPATH, atd. Ten potřebuje balíček s ikonkou archivu nebo papírové krabice, dvakrát kliknout, popř. nastavit kam nainstalovat (osobně vše co nemám od distributorů cpu do /opt), tlačítko "Zkompilovat", pak půl dne počká a v ideálním případě se vytvoří RPM/DEB balíček a sám se nainstaluje. Vše samozřejmě v GTK/QT.

[pavlix]

Uživatelem autotools je v tuhle chvíli packager. Pro uživatele systému, který se nechce dostat do problémů, je používání autotools zbytečné a nevhodné už jen proto, že výsledek závisí na explicitních konfiguračních volbách a detekci instalovaných komponent.

[Michal Kubeček]

Ve většině případů se navíc nedetekují ty komponenty, ale devel balíčky od nich, což vede k překvapením typu "Proč to nezahrnulo podporu knihovny X, když ji mám nainstalovanou?"

[pavlix]

Další důvod, proč je nesmysl takto přistupovat k binární distribuci, jejímž základním rysem je oddělený build proces.

[Grunt]

explicitních konfiguračních volbách a detekci instalovaných komponent.

Naprostý souhlas. Proto není autotools dobré pro moji babičku, ale o nějaké universálnější náhradě nic nevím.

[pavlix]

Autotools jsou pro vývojáře, experimentátory a balíčkáře, Není mi jasné, proč do toho pleteš člověka, který zjevně v této oblasti není ani jedno.

[Grunt]

Takže aby si mohl člověk užívat svobod, které software s otevřeným zdrojovým kódem nabízí, musí být vývojář, experimentátor nebo balíčkář? V podstatě to tím konstatuješ.

[pavlix]

Spíše to vidím opačně, tedy že ve chvíli, kdy začneš využívat těch svobod, staneš se postupně experimentátorem, balíčkářem a vývojářem.

Pokud jsi pouhým uživatelem, tak přímo využíváš jen svobody používat software k jakémukoliv účelu, tedy freedom 0 dle FSF, ostatních svobod využíváš jen nepřímo (jako uživatel těžíš z toho, že je využívají jiní). Jenže pro takového uživatele jsou nejvýhodnější předem připravené instalace a v případě samoadministrátorů binární balíčky.

[biolog]

Hm, to je vlastně pravda, autotools nic z toho neumí. Takže není pro uživatele, ale jen pro baliče, jak říká pavlix.

[Grunt]

A to je dle mého názoru chyba. GNU není binární OS, nýbrž zdrojový V podstatě se uživatelé binárních dister (co neumí samozřejmě kompilovat) dobrovolně obírají o jednu z největších výhod, které svobodný SW může nabídnout

[pavlix]

To podle mě není pravda. Od toho mají binární distribuce zdrojové balíčky nebo ebuildy a podobné, které zároveň člověku slouží jako specifický návod pro kompilaci daného software tak jak to bylo navrženo v dané distribuci. Uživatel binárního distra se tak sice by default vzdává kompilace (která mu zpravidla nijak nechybí), ale nevzdává se možnosti kompilace v případě, že se mu distribuční konfigurace některého balíku nelíbí.

[Grunt]

Jinak běžně s pomocí autotools instaluju, tak vím jak moc o tom uživatel vědět nemusí. Tohle prostě nemůžu chtít po mojí babičce.

[pavlix]

Pokud tvoje babička není package maintainer, tak je to vcelku pochopitelné. Nicméně pokud je balík i systém připravený, tak nemusíš ke kompilaci a „instalaci“ balíku vědět prakticky vůbec nic.

[kralyk z abclinuxu]

+1, instalovat balíčky je ve většině linux dister snažší než např. instalovat sw ve widlích.

[pavlix]

Popravdě jsem se vyjadřoval ke instalaci custom software ze zdrojáků pomocí svaté trojice.

[Grunt]

Takže to mám jako vyzkoušet na mojí babičce? A ještě po ní budu mít požadavek aby mi aplikace a přípojné knihovny nainstalovala do „/opt/aplikace“, uvidíme jak si s tím poradí…

[pavlix]

GOTO 252 nebo vysvětli, proč se ptáš pod mým komentářem.

[Grunt]

I zdrojové balíky?

[kralyk z abclinuxu]

Jo ty taky. Zkoušels někdy něco kompilovat na widlích?

[Grunt]

Ok. Uznavám. Možná proto se distribuují binární. Furt to nezvládne moje babička. A o moji babičku tu jde až v první řadě, ne?

[backinabag]

Je to hodne originalni a zajimavy napad. Celkem se mi to libi, ale zaroven nevim co si o tom myslet, jake presne vyhody a nevyhody to ma oproti dobre navrzenemu a vsemi pouzivanemu balickovacimu systemu.

[Václav "Darm" Novák]

A neni to nahodou samo o sobe namet na dobre navrzeny a vsemi pouzivany balickovaci system, ktery bude pro aplikace ktere to potrebuji bezet paralelne s distribucnim? :)

[j]

jawohl mein fuhrer ...

[Petr Ježek]

Na tom se lze jen těžko shodnout. Tři balíčkové standardy (rpm, deb a pkg) navíc s konverzními nástroji jsou celkem soludní kompromis mezi standardizací a možnosmi volby.

[Pavel Stárek]

No ale co je mi to platné, když si pak třeba na Indiegamestand koupím hru, ta je zabalená pouze do DEBu (to problém není, dá se to z něj vykopírovat, popřípadě alienem předělat na RPM), ale ve finále to stejně nespustím, protože autor použil dynamickou knihovnu ve verzi X, ale já mám v systému už verzi Y a tu starší do něj prostě nemám? Takže si ji buď můžu zkompilovat kamsi do /usr/local/lib (pokud se takompilace vůbec povede) a nebo se smířit s tím, že jsem vydanými penězi alespoň podpořil vývojáře Docela se mi líbí hry dělané v Unity (ono je to sice jakési Mono), s těmi jsem nikdy problém neměl, v balíku je zabalen celý runtime i s potřebnými knihovnami a prostě to funguje.

[skunkOS]

Zdá se mi to, nebo z toho článku čiší arogance a povýšenost? "My chceme, my navrhujeme, (a vy víte hovno.)"

[mankind_boost]

Jako kdybys neznal lennarta...

[Robert Šmol]

Kde tam čtete to "vy víte hovno"? Tihle lidé řeší konkrétní problémy, které dobře popsali a navrhli řešení. Vypadá komplikovaně, ale v podstatě je to docela logické, chytré a pro mne i srozumitelně popsané. Arogantní jsou zdejší diskutující, kteří by hned někoho za snahu věšeli za koule do průvanu.

[pavlix]

Tož většina vidí aroganci a povýšenost ve jméně v nadpisu článku ještě než začnou číst.

[Ilfirin]

No, zvykejte si. Pokud vím, tak doposavad měl naprostou úspěšnost v protlačení svých nápadů. Je tedy důvod očekávat, že naplní i toto.

[Peter Golis]

Kto kráča v tieni iných, nikdy nebude prvý.

[rakii]

Lennart Pottering je agent NSA

[marvn]

And who isn't?

[Pavel]

The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, and yours truly) ... met .. and tried to come up with a scheme that ... tries to solve the issues generically ... as part of the systemd project. All that in a way ... to allow a slow, gradual adoption.

Takhle to vypadá, že vzhledem k adopci systemd jednotlivými distribucemi bude adopce tohodle konceptu pouhá formalita (bude stačit jen držet aktuální systemd).

[juras]

Pokud tahle zhovadilost projde, tak je to definitivní konec linuxového desktopu.

[Peter Golis]

Dovolím si polemizovať. Penetrácia Linuxu v desktopoch je dlhodobo dosť malá. Takže akákoľvek zmena môže priniesť zlepšenie pozície.

[mankind_boost]

O to nejde, jde o to, že je to proti Bibli - kdyby si Lennart ráčil přečíst Starý zákon, tak by znal příběh o Babylonské věži - lidé mají být pro své dobro roztříštění, rozhádaní, nejednotní a pokud se jich sejde víc na jednom místě, mají si podříznout krk, takže jeho snahy o jakési sjednocení je urážka Boha. Dojel na to člověk, dojede na to Linux.

[Peter Golis]

Ty by si mohol byť trinástym apoštolom, ako Judáš.

[mankind_boost]

Chces diskuzni valku? Mas ji mit

[Petr Ježek]

No, zdá se, že tu někdo čte pouze oblíbené kapitoly...

[pavlix]

Lepší než konzumovat pouze servírované kapitoly.

[JanM]

Příloha:

• dispcalGUI packages.png (135406 bytů)

Přesně tak. Linuxový desktop doposud používá jen pár bláznů a jejich okolí. Teď bláznům vezme hračku, takže nezbude žádný uživatel.

Ale třeba se pak najdou uživatelé, kterým se to naopak bude líbit.

P.S. Jen je mi líto vývojářů aplikací pro uživatele, co pak budou dělat s tou hromadou volného času, který dříve tak přínosně strávili studiem různých distribucí a balíčkováním?

[vlastikroot]

Lennart ma husty drogy.

[pavele]

Nechápu, proč se do něj pořád navážíte. Nechcete popřemýšlet koho zastupuje, kdo to ve skutečnosti tlačí a programuje a kdo jak ovce vše přebírá?

[GeoRW]

no myslim, ze tu budeme mat skor stabilny GNU Hurd ako toto :-P

[Pali]

Hm... Tak ten clovek si uz aj zmenil meno? Pred tym sa volal Poettering, nie?

[pako]

Hádanka pro zvídavé hlavičky: Kde jsem to jen naposledy viděl, když se stále více a více konceptů (včetně balíčkovacích) nabalovalo kolem namakaného souborového systému. Ale to už je pár let zpátky a přesto pořád ještě nejsem přesvědčen, že to byl/je správný přístup. Krom toho se obávám, že ač technicky velmi zajímavý, btrfs bude z podstaty trpět stejnými (a podstatnými: je super pohrát si s tím ve VM nebo na experimentálním svazku. ale ostrá data/ostrý systém bych se raději několikrát rozmyslel) neduhy.

[HLuPaCeK]

Necham si poradit, kde? Nerikam, ze je to uplne a jedine reseni, ale z pohledu vyvojare me to vcelku zaujalo.

[pako]

Přece nebožtík OpenSolaris, resp. Solaris 11. Ne ten samý návrh, ale to obestavování souborového systému podobného designu.

[Petr Ježek]

Tam šlo o zcele jiný důvod neakceptace širokou uživatelskou obcí...

[pako]

Já jen pravím, že nápady odvinout kde co (třeba vlastnosti a fungování správy balíčku) od vlastností konkrétního fs, mi jej připomněli.

Proč se až tak nerozšířil (mj. např. pokud jste neměli jeden ze dvou, tří laptopů rozšířených mezi borci ze Sunu, hodně štěstí s rozchozením na Vašem HW) nebo proč dopadl, jak dopadl (konečná stanice Oracle), jsem tím vůbec neřešil.

[...]

Je treba rychlo nahradit systemd - uz ked som si nedokazal predstavit dalsi balast ktory tam chcu pridat, tak oni napisu takyto almanach. Uz teraz systemd linkuje s polovicou systemu, yack!

[milan]

systemd posledni hrebicek do rakve, ktery me presvedcil, ze linux pro me uz nema smysl a presel sem na osx

[.....]

Není nad to se po ránu pořádně zasmát. Strašná spousta věcí ze systemd projektu je inspirovaná právě OSX.

[kavol]

hm, a nebývá snad lepší používat originál nežli kopii pochybné kvality, co je na tom směšného?

[JZD]

Proč mám pocit, že to jsou další dvířka k rozšíření malwéru a dalšího hnoje tak jak je to na Androidu.

[martin]

protoze tomu hovno rozumis? (just guessin')

[pavlix]

Hence, even in this scheme RPM/DEB are highly relevant, though not strictly as an end-user tool anymore, but as a build tool.

A proto se pracuje na ostree.

[pavlix]

I originally intended to discuss this at the Linux Plumbers Conference (which I assumed was the right forum for this kind of major plumbing level improvement), and at linux.conf.au, but there was no interest in my session submissions there...

A já jsem si vždycky myslel, že Plumbers vznikla kvůli Lennartovi.

[kralyk z abclinuxu]

Co je tohle za bullshit? To je naprostej nesmysl.

1. Celej nápad je založenej na btrfs subvolumes, tj. specifická vlastnost jednoho filesystému (kterej je mimochodem už X let experimental). Žádný btrfs loopbacky na systému neplánuju mít, thank you very much. To je zas Lennartův zlozvyk kašlat na nějaký standardy a klidně záviset na jednom specifickým kusu SW.

2. app:<vendorid>:<runtime>:<architecture>:<version> -- This encapsulates an application bundle. (...) the <runtime> refers to the vendor id of one specific runtime the application is built for, for example org.gnome.GNOME3_20:3.20.1. (...) Example: app:org.libreoffice.LibreOffice:GNOME3_20:x86_64:133

   Dafuq? Jakože aplikace je závislá na jednom frameworku? To asi spadl z jahody na znak. Já například mám LibreOffice nainstalováno, ale Gnome ne. Nehledě k tomu, že balíčky závislé na X různých knihovnách/runtimech jsou celkem běžné.
3. Knihovny/frameworky mají mezi sebou taky závislosti.
4. Není mi moc jasný, jak si představuje aktualizaci - buď bude mít aplikace závislosti ve svým bundlu, což je windows-like prasárna a z bezpečnostního hlediska noční můra, nebo bude aktualizovat jednotlivý bundly a tím v podstatě skončí s ekvivalentem package managerů.

5. usr:org.archlinux.Desktop:x86_64:302.7.10

   LOL, no comment...

Tohle je hodně nedomyšlený.

[trekker.dk]

Tohle je hodně nedomyšlený.

Jedná se o Lennartware. Domýšlení není jeho práce, to budou mít na starosti lidi z distribucí (zdravíme lidi z Red Hatu), kterým spadne na hlavu podpora té věci.

[Heron]

Já například mám LibreOffice nainstalováno, ale Gnome ne.

No tak budeš mít, no. Lennart bude určovat, co máš mít nainstalováno, snad si nemyslíš, že si o tom budeš rozhodovat sám?

[Petr Ježek]

Archlinux? Slack?

[Sid]

Myslim, ze ten bod 2 nehovori o zavislosti na jednom frameworku - je tam ma napisane for example. Ale tiez by to mohlo byt app:org.libreoffice.LibreOffice:KDExx_xx:x86_64:133. Len dost dobre nechapem co ked tie zavislosti budu viacnasobne. Napr aplikacia je vytvorena pre Gnome a zaroven specialne napr kompilovana s podporou pre Wayland dajme tomu. Tj. dostane cosi ako app:org.libreoffice.LibreOffice:GNOME3_20_wayland:x86_64:133 a app:org.libreoffice.LibreOffice:GNOME3_20_xorg:x86_64:133? Ak ano tak mi to pride ako odsunutie problemu o level nizsie s tym, ze tak ci tak tam problem zostane.

[Petr Ježek]

Ten problém vyřeší uživatel výběrem (zde Xorg či Waylandu) nebo to za něj udělá distribuční architekt (preference jednoho z více). Takhle dnes vypadá dost nepřehledná koexistence balíčků pro provoz v 64 bit systému (nativních 32 bit a speciálek ve 32 bit pro 64 bit).

[Sid]

Myslim, ze ten bod 2 nehovori o zavislosti na jednom frameworku - je tam ma napisane for example. Ale tiez by to mohlo byt app:org.libreoffice.LibreOffice:KDExx_xx:x86_64:133. Len dost dobre nechapem co ked tie zavislosti budu viacnasobne. Napr aplikacia je vytvorena pre Gnome a zaroven specialne napr kompilovana s podporou pre Wayland dajme tomu. Tj. dostane cosi ako app:org.libreoffice.LibreOffice:GNOME3_20_wayland:x86_64:133 a app:org.libreoffice.LibreOffice:GNOME3_20_xorg:x86_64:133? Ak ano tak mi to pride ako odsunutie problemu o level nizsie s tym, ze tak ci tak tam problem zostane.

[Robert Šmol]

Já to chápu tak, že každá aplikace má svůj runtime a v něm jsou obsaženy všechny závislosti co potřebuje. Když máš pak dvě aplikace co používají svůj runtime a ty se překrývají (stejné závislosti na X..), tak díky brtfs ti to nezabere 2x tolik místa. Možná se pletu. Každopádně to chápu tak, že i nadále je možné provozovat klasický linuxový všehomix v /usr/lib. Má to přímo v requirements (že to chtějí umět). Já tohle celkově vidím jako velkou věc pro embeded a servery. Je zde prostě dobrý návrh jak realizovat masové updaty stejných funkčních boxů. Tohle by mohlo pomoci mít aplikace běhající opravdu všude. Celkem dobré.

Aktualizace je tam popsána, deserializuje se binární blob do n-foldu dané partišny.

Sám osobně na laptopu BRTFS mám, ale teď vidím, že je to celkem schopný filesystém.

Když něčemu nerozumíte, není nikdy na škodu šetřit ostrými výrazy typu "co je tohle za bullshit".

[Heron]

Já osobně BTRFS mám také, napsal jsem o něm několik článků apod.

A ten původní návrh JE bullshit, pokud si vynucuje použití nějakého konkrétního systému souborů (a to bez ohledu na to, že tento fs považuji za dobrý a rád s ním pracuji).

Ztrácí se tím flexibilita, možnost zvolit si to nejlepší řešení pro daný problém (ne, žádný systém souborů se nehodí na všechny situace a ani to nejde) a různorodost.

[lnykryn]

Btrfs se může používat jen na "balíčkování". /etc, /var může být libovolný filesystém, pak se jen namountuje na správná místa. Dokonce by tam člověk nemusel mít ani jednu zapisovatelnout btrfs subvolumu.

[kralyk z abclinuxu]

Já to chápu tak, že každá aplikace má svůj runtime a v něm jsou obsaženy všechny závislosti co potřebuje. Když máš pak dvě aplikace co používají svůj runtime a ty se překrývají (stejné závislosti na X..), tak díky brtfs ti to nezabere 2x tolik místa.

Tohle ale reálně ve většině případů nebude fungovat, protože vendor1 si k aplikaci přibalí libfoo-1.1.1, vendor2 si přibalí libfoo-1.1.3 a vendor3 si přibalí libfoo-1.2.0. Následně bude v libfoo-1.1.x nalezen vážný bezpečnostní problém, a co potom? Bude potřeba spoléhat na vendor1, vendor2 a všechny ostatní, kdo přibalili libfoo-1.1.x, aby aktualizovali svoje bundly, které se pak všechny budou muset stáhnout a aktualizovat.

Což bude vyžadovat, aby se někde vedla evidence, v kterých bundlech je jaká knihovna, a nějaký mechanismus, jak je aktualizovat. No a pak bude zbývat už jen pogratulovat k vynálezu kola - balíčkovacího systému.

Tohle by mohlo pomoci mít aplikace běhající opravdu všude.

Neřekl bych, je to pouze posunutí problému někam jinam nebo jeho ignorování, přesně jak píše někdo výše. "Aplikace běžící všude" je náročná věc z definice a neexistuje snadné řešení - řešení, které je snadné, způsobí dřív nebo později problémy.

[JS1]

Bude potřeba spoléhat na vendor1, vendor2 a všechny ostatní, kdo přibalili libfoo-1.1.x, aby aktualizovali svoje bundly, které se pak všechny budou muset stáhnout a aktualizovat.

Ano. Ale to je bohuzel realita komercnich tvurcu software, kterou tezko nejak technicky vyresis. Komercni tvurci, narozdil od OSS, proste certifikuji svuj SW pro relativne uzke mnozstvi verzi.

Ze to prinasi bezpecnostni problemy je nasnade. Ale Lennartuv navrh se nesnazi resit socialni problemy spojene s komercnim SW.

[kralyk z abclinuxu]

Linux je primárně free software platforma. Jestli chce někdo na Linuxové systémy naportovat komerční closed-source software tak by se měl přizpůsobit linuxovému ekosystému, ne naopak.

[Ivan]

To je sice hezky, ale ten ekosystem je nekdy dost prastenej. .ELF format napriklad umoznuje mit vice verzi symbolu v jedne binarce. Bohuzel tuhle vlastnost pouziva jen glibc. Ostatni radsi vydaji novou verzi knihovny. Na druhou stranu .ELF format neumoznuje menit RPATH u jiz zkompilovane binarky. Takze nemuzete behem instalace baliku rict, ze program hleda knihovny v "/usr/lib" resp. v /usr/lib64.

Dneska kdyz vyjde security update tak stejne musite aktualizovat 10 baliku, protoze nikdy netusite kde vsude se meni ABI. A to jsme "jen" u programu napsanych v cistem Ccku. V pripade C++ navic ruzne verze g++ menily ABI.

A jak se to resi? Napr.

• VMWare tools si sebou tahnou verzi gnome knihoven
• Oracle se distribuje ver forme .o souboru a binarky se linkuji az behem kompilace
• Informix vyzaduje LD_LIBRARY_PATH
• MegeRaid tools jsou slinkovane staticky
• dalsi programy pouzivaji relativni RPATH
• Na AIXu dovava "udev" pravidla dodavatel ovladace (a ne distribuce)

Cely problem je v tom, ze OS (a s nim spojene gcc) ma jine cykly nez vendor komercniho SW. Tohle ale tezko vyresi systemd. Tohle je problem tech co spravuji API zakladnich knihoven.

PS: porad je to ale lepsi nez kdyz jsme meli 2 verze libc (glibc vs. libc5) a 2 verzi threads posix threads vs. linux threads.

[pako]

Nepoplatnulo se Vám ABI a API?

Něco se kouzlit dát viz patchelf, já si tím upravoval Skype k obrazu svému (64b systém).

[Michal Kubeček]

Dneska kdyz vyjde security update tak stejne musite aktualizovat 10 baliku, protoze nikdy netusite kde vsude se meni ABI.

Vaše tvrzení je v zásadním rozporu s mou zkušeností.

[pavlix]

+1

[kralyk z abclinuxu]

+1, bezpečnostní patche většinou nemají tendence rozbíjet ABI...

[Ivan]

To nemaji. Jde o to, ze se z jednoho tarballu generuje nekolik baliku. Takze kdyz se najde remote exploit na bind, tak na svym Ubuntu desktopu budu aktualizovat nekolik baliku, ktery souvisi s DNS i kdyz vim, ze se me to CVE netyka - na desktopu bind neprovozuju. A podobne je to s Xkama. I kdyz se jedna o one-liner patch, ktery se tyka pouze klavesnice, tak budu stejne aktualizovat vsechny baliky, ktery pochazi ze stejnyho tar-ballu. V realu me ale nakonec verze SW stejne nic moc nerekne, protoze kazda distribuce aplikuje na tarball svoje patche. Na AIXu spustim instfix a hned vim jestli byl dany bug fixnuty na mym serveru. Nemusim to hledat nekde na webu, rekne mi to primo package manager, protoze kazdej balik vi, jaky bugy fixuje.

Pak se muze stat, ze Oracle rekne, ze svoji databazi certifikoval s verzi glibc x.y.z na serveru kde mel nainstalovany gnome ver. a.b.c. a jeste nekolik let maji lidi strach to aktualizovat. Protoze: "Co kdyby se to nahodou podelalo?".

Java, kterou nemam rad, umi u kazdy metody spocitat signatury jejiho API. C/C++ bohuzel nic takovyho neumi. A ani .ELF nic takovyho nepodporuje (pokud vim).

[pavlix]

Spousta balastu, ale podpoření původního tvrzení nevidím.

[Michal Kubeček]

Nemusim to hledat nekde na webu, rekne mi to primo package manager, protoze kazdej balik vi, jaky bugy fixuje.

Ve slušné společnosti bývá zvykem napsat tuto informaci do changelogu. Konkrétní distribuce mohou mít i systematičtější způsob evidence.

Java, kterou nemam rad, umi u kazdy metody spocitat signatury jejiho API. C/C++ bohuzel nic takovyho neumi.

Jazyk a standardní toochain sice ne, ale s trochou práce se to udělat dá.

[Michal Kubeček]

Já to chápu tak, že každá aplikace má svůj runtime a v něm jsou obsaženy všechny závislosti co potřebuje.

A až se objeví závažná bezpečnostní chyba v nějaké knihovně, kterou používají skoro všichni (třeba OpenSSL), tak místo updatu jednoho balíčku bude potřeba update všech těch runtime balíků od všech aplikací, které si přibalily různé verze té knihovny. Tak tomu říkám pokrok…

[pako]

ad 1. Tahle (nezdravá) závislost mi právě připomněla OpenSolaris (a jeho IPS a další). COW souborové systémy tohoto ražení navíc mají sklony k pár nepříjemným vlastnostem: rychlost některých operací (zejména mazání velkých stromů, ovšem když s tím člověk dopředu počítá, může tomu místo adresáře vytvořit svazek a ten pak celý odstřelit), fragmentace volného prostoru (s rostoucím věkem svazku a jeho klesající volnou kapacitou dá čím dál více zabrat hledání dalšího vhodného místa, až v krajním případě systém nedělá skoro nic jiného), při vyčerpání místa se kvůli COW mechanismu můžete dostat do stavu, kdy nelze ani tam (přidat data) ani zpět (smazat data) (pokud se nenajde vhodný svazek, který lze odstřelit a tím se zachránit).

[Petr Ježek]

Tak jest. Jenže tohle má řešení při firemním nasazení v podobě aktualizací obrazy či klony, kam ostatně byl Solaris určen. Právě proto tak snadno umřel na desktopech...

[pako]

Ano i ne. Na jednu stranu zde byl a je tlak na standardizované aktualizace, protože celá řada problému vzniká vyzobáváním (a to ostatně zmiňuje i Lennart, že není realistické, aby se otestovali všechny možné kombinace). Na druhé straně jsou to protiproudy: aktualizovat vč. funkcí, aktualizovat jenom bezpečnostně nezbytné minimum. A celá řada korporátní zákazníků chce jenom a pouze to druhé... a vyzobávají a vyzobávají, i když jim chcete dávat obrazy aktualizací podle jednoho vzoru. Nakonec je to ale samozřejmě součást obchodního modelu, zaplať dost navíc, můžeš dostat aktualizace na míru.

Na desktopech nikdy moc nežil a definitivně umřel, když ORCL (celkem správně) poznal, že z toho žádný kšeft nekouká (tedy to by poznal i Sun, kdyby to řešil).

[2014]

Ein Folk, ein Reich, ein Fuehrer !

Cast populace proste potrebuje instatni reseni problemu, nemuset se rozhodovat a samostatne myslet, nechat se vest, nekoho uctivat a odmitat diverzitu.

Jaksi nevidi, ze ta instantni reseni jsou neoptimalni nebo jen presouvaji problem z jednoho mista na jine, ze se resi jen zastupny problem a ten hlavni zustava, ze vzdavanim moznosti volby snizuji svoje sance do budoucna a modlictsvi s sebou nese nekriticke prijimani i zmetku, zavislost a manipulaci.

Nelze si nevsimnout opakovani principu - inteligentni sociopat zahackuje fanatickou skupina stoupencu - formou revoluce dojde k prosazeni vlastnich cilu - pro uzitecne idioty se nic nemeni. Socialni inzenyri a GK uz vedi.

[JS1]

Ne, neoptimalni je, kdyz si to kazdy resi po svem a mizerne.

A kdo je GK? Gott Karel?

[Zarko]

Tipoval bych Strazce Brany .

[mankind_boost]

Doufam, ze debian tuhle silenost neprijme. Vsadim se, ze se to lennart pokusi nejak procpat pres systemd (jak je jeho zvykem).

[lnykryn]

Tady vůbec nejde o to něco nahrazovat. Ano bude se muset udělat pár bolestivých změn jako přesun vendor konfigurace mimo /etc, ale Tradiční způsob jak shipovat systém (deb/rpm/...) pořád zůstane. Důvod pro celý tenhle návrh je, že spousta lidí chce mít na stroji různé stacky knihoven, chtějí kontejnery. A současná řešení jsou jen kupa hacků jak ohnout současný systém.

[pavlix]

Co má to, co Lennart popisuje, přesně společného s kontejnery?

[lnykryn]

Úplně všechno. Aplikace se právě spustí tak, že se ti všechny části spojí v kontejneru. Nebo image se základním systémem buď nabootuješ a nebo ho spustíš jako kontejner.

[Josef Kufner]

Jo, v tomhle kontextu to smysl dává. V konfiguraci VPS si naklikáš, co tam chceš, pak se ti jen složí pár read-only kousků do hromady a ten poslední kousek je tvoje jedna aplikace. Další aplikací jsou embeded zařízení, kde firmware bude několik obrazů, podle toho, co tam zrovna chceš. Udržovat takle desktopovou nebo i běžnou serverovou instalaci bych ale nechtěl a doufám, že si je toho Lennart vědom.

[Marián Kyral]

Obávám se, že jen u toho nezůstane.

[mankind_boost]

+1

[Grunt]

Jako nápad dobrej, ale i kdybych to chtěl vymyslet fakt složitě, na tohle bych asi nepřišel…

[lnykryn]

A tady je malý návod od Haralda Hoyera jak si pár btrfs imagů vyzkoušet. http://particles.surfsite.org/

[HLuPaCeK]

Uvědomil jsem si, že většina Lennardem zmíněných problémů je řešena už v NixOS a kupodivu je jejich přístup dost podobný (a nutně nezávisí na btrfs).

viz. http://nixos.org/

[Petr Ježek]

Díky za připomenutí, toho jsem si při zkoušení NixOS taky povšiml, ale zase vyhnal z hlavy... Právě NixOS je hodně zajimavý koncept z hlediska analýzy pro řešení budoucího vývoje linuxu.

[martin.k]

Je neco zasadniho, co tenhle Lennartuv novy navrh prinasi navic proti

• a) static buildu
• b) http://chakra.sourceforge.net/wiki/index.php/Bundle_System ?

(teda krome toho pozitiva, ze to je Lennartuv navrh :))

[little.owl]

Schopnost to uvest v zivot.

[backinabag]

Prijde mi, ze LP se projekty jako systemd nebo tohle snazi o centralizaci a "defragmentaci" Linuxovych distribuci. To co si ted kazda distribuce resi sama (spousteci skripty, balicky) – a co casto znamena duplicitni praci – se presune do novych projektu.

Pro vetsinu Linuxaru centralizace = zlo, ale to neplati obecne, zalezi na okolnostech a zrovna u Linuxovych distribuci je trocha centralizace potreba, takze mu fandim. (A RedHat ma mimochodem na svedomi i dalsi velmi sympaticky projekt, Ceylon.)

V desktopovem Linuxu je spousta veci spatne, je to znat napr. v porovnani s Androidem – sandboxing aplikaci, komunikace mezi aplikacemi, jednotne a zpetne kompatiblni API, atd.

[pavlix]

Prijde mi, ze LP se projekty jako systemd nebo tohle snazi o centralizaci a "defragmentaci" Linuxovych distribuci.

To sice zní rozumně, v kontextu ve kterém se to děje bych to spíš interpretoval tak, že používá linuxový ekosystém jako základ pro enterprise platformu a zároveň používá především komerční část linuxové komunity jako odbytiště a jako pool potenciálních chlebodárců.

Je to velice podobné až na to, že ta enterprise platforma v podstatě ani nevyžaduje ovládnutí všech distribucí, i když to asi značně pomáhá jejímu prosazení.

zrovna u Linuxovych distribuci je trocha centralizace potreba

Tomu nerozumím. Už jenom existence nezávislých linuxových distribucí je decentralizace ve své nejčistší podobě. Centralizované byly tradičně jednotlivé klíčové projekty jako je jádro, kompilátor a libc a historie vcelku jasně ukazuje poptávku po alternativách i jejich vznik. Jádro tak bylo v poslední době jako jediné relativně špatně nahraditelné, ale rozhodně ne nenahraditelné.

Mnohé projekty jsou ve své kategorii dominantní, jako třeba ty výše zmíněné. Z krátkodobého hlediska to pomáhá šetřit práci, ale z dlouhodobého diverzita stimuluje buď zlepšení dominantního projektu nebo vzestup jeho náhrady. Pokud je některá komponenta příliš obtížně nahraditelná, tak to podle mě ekosystému zase až tak moc nesvědčí.

Nehledě na to, že většina těch teorií o rostříštěnosti vychází z naivních představ o aktivní komunitě jakožto souboru lidských zdrojů. Jenže ani jednotlivci ani firmy nefungují tak, že by se po potopení jednoho alternativního projektu všichni honem vrhli na ten dominantní.

[omg]

proč furt musíš reagovat, když neumíš ani číst??

[pavlix]

Spíš mi není jasné, proč reaguješ ty.

[backinabag]

To sice zní rozumně, v kontextu ve kterém se to děje bych to spíš interpretoval tak, že používá linuxový ekosystém jako základ pro enterprise platformu a zároveň používá především komerční část linuxové komunity jako odbytiště a jako pool potenciálních chlebodárců.

No, ja to mozna trochu naivne vidim tak, ze Poetteringovi jde jednoduse o dobro desktopoveho Linuxu.

Už jenom existence nezávislých linuxových distribucí je decentralizace ve své nejčistší podobě.

Linuxove distribuce by IMHO mely byt pouze ruzne mnoziny defaultnich baliku, s tim ze balickovaci system by byl jeden, tady mi prijde diverzita kontraproduktivni. To se tyce distribuci jako Ubuntu, SUSE, Mandriva, atd., pro jine systemy zalozene na Linuxu (Android, Chrome OS) to samozrejme neplati.

[Marián Kyral]

Už jenom existence nezávislých linuxových distribucí je decentralizace ve své nejčistší podobě.

Linuxove distribuce by IMHO mely byt pouze ruzne mnoziny defaultnich baliku, s tim ze balickovaci system by byl jeden, tady mi prijde diverzita kontraproduktivni. To se tyce distribuci jako Ubuntu, SUSE, Mandriva, atd., pro jine systemy zalozene na Linuxu (Android, Chrome OS) to samozrejme neplati.

A Gentoo? To je distribuce linuxu, nebo systém založený na linuxu?

[pavlix]

To je teď distribuce linuxu, ale po unifikaci to bude systém založený na linuxu ;).

[pavlix]

Linuxove distribuce by IMHO mely byt pouze ruzne mnoziny defaultnich baliku, s tim ze balickovaci system by byl jeden, tady mi prijde diverzita kontraproduktivni.

Takovému modelu nevěřím. Stačí srovnat Gentoo, Fedoru a Debian a člověk vidí zcela odlišný přístup k balíčkování, který je jen těžko slučitelný.

[kralyk z abclinuxu]

Linuxove distribuce by IMHO mely byt pouze ruzne mnoziny defaultnich baliku, s tim ze balickovaci system by byl jeden, tady mi prijde diverzita kontraproduktivni.

No to se mi teda nezdá, imho distribuce není jen množina balíků. Například bych velmi nerad za cokoli jinýho měnil pacman z Archu, děkuji pěkně. Na druhou stranu je ale blbost nutit všem pacmana, že...

[backinabag]

Například bych velmi nerad za cokoli jinýho měnil pacman z Archu, děkuji pěkně.

Proc? Arch a pacmana taky pouzivam a klidne bych menil za to od LP, pokud by to byl standard.

[kralyk z abclinuxu]

Tak zaprvé nepoužívám btrfs a přecházet na něj nehodlám. Zadruhé pacman je výbornej pkg manager na KISS principu a nevim moc, proč bych ho měl měnit. Zatřetí LP na standardy zvysoka kašle, byl by to tak maximálně "de-facto standard" což imho není moc dobrý stav. A začtvrté to, co navrhuje LP, není plnohodnotnou náhradou balíčkovacího systému - vůbec se tam neřeší závislosti, způsob update, repozitáře atd., imho je to fakt spíš brainfart než cokoli prakticky použitelnýho...

[backinabag]

Nejsem o tom jeho napadu uplne presvedcenej a nerozumim tomu do detailu, ale vypada to velmi zajimave a promyslene. Brtfs to cele dost zjednodusuje, je to uplna zmena paradigmatu oproti klasickym balickovacim systemum.

Zavislosti se predpokladam resi takhle – aplikace jednoduse deklaruje, na jakych vsech souborech (vcetne verze) zavisi. A stahnou se jenom soubory, ktere lokalne chybi.

Zpusob update a repozitare tam (zatim?) neresi.

[backinabag]

Brtfs to cele dost zjednodusuje, je to uplna zmena paradigmatu oproti klasickym balickovacim systemum.

Napriklad dependency hell, konflikty, cyklicke zavislosti - nic z toho tam nemuze vzniknout.

[j]

Co myslis, co si nainstaluju az budu chtit windows ... lennartovo bazmek nebo bazmek od M$? Jo, mit na disku 100GB protoze si kazda appka potahne sebou svoje verze knihoven, to je mokrej sen kazdyho provozovatele libovolnyho stroje ... Pochopitelne to lennart jeste musi vylepsi - o to ze si system vsechny balicky vsech verzi poschovava do /linsx ...

[pavlix]

Co myslis, co si nainstaluju az budu chtit windows...

Nainstaluj si co chceš, jen mi není jasné proč to taháš do vlákna, kde se diskutuje o parametrech dvou odlišných řešení.

[kralyk z abclinuxu]

Zavislosti se predpokladam resi takhle – aplikace jednoduse deklaruje, na jakych vsech souborech (vcetne verze) zavisi. A stahnou se jenom soubory, ktere lokalne chybi.

1. Kde je tohle v tom Lennartovo textu? Píše se tam, že aplikace deklaruje jeden "runtime" jako závislost ("one specific runtime" - sic).
2. Jak se tohle liší od balíčkovacích systémů?

[backinabag]

Kde je tohle v tom Lennartovo textu? Píše se tam, že aplikace deklaruje jeden "runtime" jako závislost ("one specific runtime" - sic).

Tak jsem pochopil ten double buffering. Kdyz aplikace zavisi na trech ruznych knihovnach, tak vsechny budou v jednom runtimu, ktery bude specificky pro tu aplikaci.

[Marián Kyral]

Kde je tohle v tom Lennartovo textu? Píše se tam, že aplikace deklaruje jeden "runtime" jako závislost ("one specific runtime" - sic).

Tak jsem pochopil ten double buffering. Kdyz aplikace zavisi na trech ruznych knihovnach, tak vsechny budou v jednom runtimu, ktery bude specificky pro tu aplikaci.

No a jaký je rozdíl oproti tomu, když si aplikace ty tři knihovny nainstaluje k sobě do adresáře? Maximálně ten, že systém bude vědět, že tam ty tři knihovny jsou. Ale sám od sebe ty tři knihovny zaktualizovat nemůže, neb neví, zda tím tu aplikaci nerozbije. Takže ve výsledku se pak bude stejně čekat na autora, který tu aktualizaci musí otestovat.

Já fakt nechci mít na disku bambilión blobů s tou samou knihovnou, jen jednou to bude 0.97, podruhé 1.01 a potřetí 1.3. Fakt ne. Pokud aplikace potřebuje specifické prostředí, má možnost si vytvořit image a ten spouštět třeba pod vboxem. To vyjde ve výsledku nastejno.

[pavlix]

Podle mě chce prostě Lennart nabídnout implementaci Androidu, toť vše.

[little.owl]

Bude to vyzadovat redefinici Linux Standard Base, Filesystem Hierarchy Standard a pravdepodobne to v konecnem dusledku, v naslednych krocich pohrbi cely POSIX. Libi se mi to.

[backinabag]

:D +1

[DEbill]

Nastesti lennartovci od Linuse uz dostali jasny vzkaz, ze v kernelu jim psenka nepokvete. Pan Buh zaplat!

[pavlix]

Jenom aby za pár let nedostal podobný vzkaz Linus ;).

[Marián Kyral]

Pár let - to je ve světě počítačů hodně vzdálená budoucnost a co bude si vůbec netroufám odhadovat.

[kralyk z abclinuxu]

Právě mám čerstvou zkušenost s tím, jak některé firmy distribuují sw pro linux. Jedná se o Accelerated Parallel Processing SDK od AMD [1], čili není to žádný mrňavý startup co si právě založil Pepa vod vedle... (Pepa vod vedle by to možná naopak řešil líp).

V kostce:

1. Na stránkách APP SDK není přímý odkaz na balíček, mají tam místo toho javascriptem potvrzovaný formulář generující POST request. Formulář obsahuje serverem vygenerované číslo ("nonce"), které při requestu server kontroluje než naservíruje data.
2. Plot twist: nonce je pokaždé stejná, děkuji AMD za usnadnění balíčkování.
3. Tím ovšem sranda nekončí, po stáhnutí a rozbalení tarbz2 archivu zjistíte, že uvnitř je jediný soubor typu shell scrip o velikosti ~120MB.
4. Při bližším zkoumání vyjde najevo, že je to jakási samorozbalovací prasečina [2], která má zasebou prostě připojený další tarbz2 archiv. "Sympatické" taky je, že ta samorozbalovací věc po rozbalení spustí nějaký další skript z archivu. AMD doporučuje vše spouštět pod rootem. Tak určitě...
5. Po odpárání té prasečiny a rozbalení vnořeného tarbz2 se teprve dostanete k datům, které můžete nějakým způsobem zabalit do distribučního balíku jako u civilizovaných lidí.

Proč to píšu: Tohle je přesně důvod, proč si myslím (mimo jiné důvody), že ten Lennartovo návrh je zcestný. Jde o to, že v podstatě vendorům dává prostor dělat si co chtějí, což je, jak ilustrováno výše, zásadní chyba. Takže, ačkoli unifikovaný způsob je fajn, musí mít jasně daná pravidla kompatibilní s linuxovým a obecně nejlépe i unixovým světem a vendorům by mělo být jasně dáno najevo, že je mají dodržovat. Koneckonců, v různých appstorech a dalších prostředích to funguje.

[Marián Kyral]

Jo. Přesně toho se bojím. Ještě více uzavřených binárních blobů místo otevřených zdrojáků je akorát cesta do pekel. Rozumím té snaze nějak zautomatizovat instalaci, ale vedle toho můžou klidně dát i normální archiv pro normální lidi.

[little.owl]

Jde o to, že v podstatě vendorům dává prostor dělat si co chtějí, což je, jak ilustrováno výše, zásadní chyba.

Davat vetsi prostor vendorum neni chyba a jejich omezenim nicemu nepomuzete, nehledete k tomu, ze Lennartova koncepce vyrazne omezuje moznosti pripadnych skod. Budou k dispozici nejake QA standardy a stejne jako treba u RPM nastroje, ktere provedou nejakou zakladni verifikaci, a pak je na vas nepouzivat SW ze zdroju, ktere jim nevyhovuji. To se deje jiz dnes, ja take nepridavam kdejake pochybne repositories do instalacnich zdroju. Lennartuv navrh neudela situaci horsi nez dnes.

[kralyk z abclinuxu]

V tvém komentáři mi na několika místech chybí slůvko "protože" následované nějakým podepřením tvrzeného...

[little.owl]

Specifikujte.

Rekl bych ze si neuvedomujete posuv ktery nastal prichodem veci jako GitHub, ktere zmenily zpusob distribuce SW. Tam jsou miliony repositaru, a i kdyz 95% vseho je jen crap, stale je tam plno zajimaveho SW, zadna soucasna distribuce se svym standardnim balickovacim procesem s tim nemuze drzet krok a packageri budou dale spise ubivat. Pak je jakysi automatizovany/unifikovany system instalace aplikaci napric distribucemi cesta vpred, i kdyz jadro systemu se bude distribuovat jako dnes.

[kralyk z abclinuxu]

Specifikujte.

Např. proč by Lennartovat specifikace měla omezovat možnosti případných škod, odkud víš, že budou QA standardy, atd. vlastně celý ten komentář mi přijde naprosto nepodložený. Na mě to dělá ten dojem, že Lennart spíš ujíždí na cool fíčurách btrfs a jinak by všemu nechal volný průběh...

zadna soucasna distribuce se svym standardnim balickovacim procesem s tim nemuze drzet krok a packageri budou dale spise ubivat

Třeba v Archu, kde máme -git balíčky v AURu (a další VCS balíčky) mi přijde, že to funguje celkem dobře...

Pak je jakysi automatizovany/unifikovany system instalace aplikaci napric distribucemi cesta vpred, i kdyz jadro systemu se bude distribuovat jako dnes.

Tak to souhlas, ale o tom úplně vlákno není...

[little.owl]

Např. proč by Lennartovat specifikace měla omezovat možnosti případných škod, odkud víš, že budou QA standardy, atd.

Spise nesledujete, co se deje kolem lidi s tim spojenych, vcetne treba duvodu, ktere vedli k Fedora Next ci predtim Gnome OS. Ten navrh neni jen z hlavy LP, spise jen jeho neuplny prispevek k hledani dalsi cesty. Nevim jak Arch, ale Fedora ma pomerne prisne packaging standardy (s mojimi balicky by me asi vyhodili), Debian totez, vcetne toolu, a neni duvod si myslet, ze pokud nakonec neco pripravi, pod freedesktop.org nebude nejaky "standard". U Fedory pak cekejte i upravenou SELinux policy, ktera bude plno bezpecnostnich veci resit (viz treba soucasnou integraci SELinux/Docker/systemd/GearD/projectatomic).

Třeba v Archu, kde máme -git balíčky v AURu (a další VCS balíčky) mi přijde, že to funguje celkem dobře...

Znovu - pointa je ale jina - zadna distribuce nestaci drzet krok treba s GitHubem a uzivatelem, protoze mezi nimi je packager a to je proste bottleneck. Casto packager ani neni a pak je plno uzivatelu v (_!_). Pokud se vam podari vytvorit nejaky automatizovany system kompilace a deployment, uzivatel si stahne hotovy, treba on-the-fly zkompilovany/vytvoreny balicek pro svou distribuci, tak jako stahuje ted z GitHubu zip file.