Jsem hater

13.9.2014 16:55 | Přečteno: 2723×

V poslední debatě o Lennartových výstřelcích zazněl názor že kritici systemd jsou haters. Něco na tom bude. Když jsem naposledy psal něco o Lennartware, objevily se v diskusi takové bludy že jsem ho chudáka nakonec ještě bránil. Po přečtení jeho posledního díla jsem ale pevně rozhodnut připojit se s nadšením a zápalem zpátky k haterům.

Pominu technickou stránku která je jen vágní nástřel a nebylo by fér ji proto kritizovat. Pominu že prezentované důvody považují za celý linuxový svět úzkou skupinu zákazníků redhatu. Pominu i že předkládaná myšlenka naznačuje jak autoři vůbec nepochopili že mezi linuxovým distribučním modelem a jeho úspěšným tažením světem by mohla být nějaká souvislost. Co mě udeřilo do očí je že se nám tu rýsuje další Canonical. Počítejme paralely: jak Lennartova samozvaná "kabala", tak Cannonical začaly chvályhodnou snahou vyřešit zřejmý a palčivý problém. Oba projevili odvahu řešit věci neortodoxně. A obojí se zvrhlo v obyčejný NIH syndrom, kyselé vtipy o tom jak se systemd stává systémem v systému nápadně připomínají odřezávání Canonicalu od zbytku linuxového světa. I Lennartovo "The future is going to be awesome!" jako by vypadlo z nějakého Markova blogu. A oba si vypěstovali početnou "love-to-hate" komunitu. Ubuntu dnes pomalu upadá do bezvýznamnosti – ostatně relativně k velikosti instalované userbase byl jeho vliv vždy disproporčně malý. Definitivně potopit ho stačila maličkost – aby Mint nabídnul staré dobré "zastaralé" gnome o které podle géniů z Canonicalu přece nikdo nemůže stát. A teď Lennartova vize že unix je vlastně hrozně zastaralý a nikdo o něj nemůže stát, jak to asi může skončit?

Technické meritum s tím nemá nic společného, zato Lennartovo přesvědčení že on je Budoucnost. A podtext vinoucí se jako smrad kanálem – že Budoucnost je jen jedna a každý kdo by se odvážil nesouhlasit je už jen proto zpátečník a luddita. Ale proč bych měl věřit v Lennartovu Budoucnost? Linux je tu desítky let, je oblíbený a úspěšný všude od superpočítačových clusterů přes průzkum kosmu a internetovou infrastrukturu až po polovinu chytrofonů na planetě. A teď najednou všechno závisí na tom aby se dobře balil do nějakého embeded zařízení? Směšné. Rozšířenost linuxu nepramení ze žádného zázračného technologického trendu, ale z toho že se dokázal všem těm rádobyrevolucím přizpůsobit. Že ho lze přitesat a přiohnout do těch nejdivočejších těch tvarů na nejroztodivnějších zařízeních, ze kterých se zítra může stát hit.

To neznamená že by embedded zařízení právě teď neměla potenciál a nebyla to obrovská příležitost. Ale jsou i jiné příležitosti – teď i v budoucnosti. Embedded technika není první a už vůbec ne poslední věcí jenom proto že Lennart nedokáže vidět nic jiného. Budoucnost linuxu nezávisí na tom jak se jí přizpůsobí (protože už je přizpůsobený více než dobře) ale na tom jak se popere s tím co přijde pak. S tím o čem ještě nevíme co to bude. Tím méně lze říci jak to dopadne. Ale co můžu říci s naprostou jistotou je, že spíš než na jakýkoliv Lennartův výtvor si vsadím na technologii která se ukázala býti nejodolnější, nejpřizpůsobivější a nejdéle fungující v historii ítý. "Kabalisté" jsou přes všechny vzletné fráze směšně krátkozrací a skutečná budoucnost jim uniká. Klidně si říkejte že jsem hater.        

Komentáře

[Joseph]

Linux je tu desítky let, je oblíbený a úspěšný

Meh...

[pavlix]

Když jsem naposledy psal něco o Lennartware, objevily se v diskusi takové bludy že jsem ho chudáka nakonec ještě bránil. Po přečtení jeho posledního díla jsem ale pevně rozhodnut připojit se s nadšením a zápalem zpátky k haterům.

To je právě ten problém, když se začnou stírat rozdíly mezi technickou kritikou (návrh a zpracování software), komunitní kritikou (vztah mezi projektem a zbytkem komunity) a obyčejným nadáváním. Jsou to tři různé věci a pokud si chce člověk zachovat jasnou hlavu, měl by je jako takové brát a důsledně je rozlišovat.

Zatím vím o jednom projektu, který se snaží maximálně obejít bez lennartware (ač se tam často používá pulseaudio a avahi) a přitom jít nějak dopředu, a to je OpenWRT. Ještě pokud vím, tak v rámci Gentoo je netriviální množství lidí, kteří se snaží převážně zakonzervovat stav a udržet schopnost Gentoo fungovat bez systemd.

I Lennartovo "The future is going to be awesome!" jako by vypadlo z nějakého Markova blogu.

Je pravda, že slyším Lennarta nejvíc nadávat na vše okolo BSD a vše okolo Ubuntu. Přitom systemd jakožto repozitář pro celý nový linuxový userspace v lecčems připomíná fungování BSD projektů. Třeba má i jeho hate vůči Ubuntu podobný základ.

"Kabalisté" jsou přes všechny vzletné fráze směšně krátkozrací a skutečná budoucnost jim uniká.

Kabalisté si už teď do budoucna zajistili přístup k lukrativním pracovním pozicím, takže věřím, pro ně je celá akce čistý zisk.

[Bedňa]

Hoci rADOn kritizuje praktiky Canonicalu, tak ten aspoň nezväzuje ruky a stále sa dá napísať do skriptu

apt-get --yes remove ubuntu-desktop compiz-gnome ibus ibus-gtk ibus-gtk3

Toto beriem ako veľmi pozitívne, pokiaľ si tvorím vlastné IceBuntu a skript mi z toho distra vykuchá závislosti ktoré nepotrebujem.

Stále je to také linuxové ako to mám rád. Horšie je keď si firma vo svojom záujme kutí softvér kde je problém s nasadením alternatívy. Mne je systemd už u prdele, len aby neinfikovalo linux enviroment, toto pokladám za najväčšiu hrozbu a myslím že nebudem sám.

Rovnako sa bojím čo sa stane keby sa Linusovi a prípadne Theodorovi niečo stalo, tak si RedHat zaplatí ďalších a ďalších. GKH je už na výplatnej listine a pretláča tam veci v záujme RH, čo sa stane keď Lenartware haters Linus a Theodore odídu? Kernel Windows?

[pavlix]

Mne je systemd už u prdele, len aby neinfikovalo linux enviroment, toto pokladám za najväčšiu hrozbu a myslím že nebudem sám.

Rád bych viděl lidi, kteří pro to něco reálně dělají. Tedy nemůžu říct, že bych nevěděl o žádných, ale vnímám značnou disproporci vůči těm, kteří o tom s oblibou mluví.

Kernel Windows?

Nevstoupíš dvakrát do téže řeky, výchozí podmínky jsou značně odlišné, takže ať se bude dít cokoliv, srovnání s Windows to asi nesnese.

[Bedňa]

Zabudol som reagovať, ale

Rád bych viděl lidi, kteří pro to něco reálně dělají. Tedy nemůžu říct, že bych nevěděl o žádných, ale vnímám značnou disproporci vůči těm, kteří o tom s oblibou mluví.

Čo by mali robiť, keď im vyhovuje terajší stav, jediné čo sa dá robiť vykrikovať nešahajte na to, robte si čo chcete, ale neserte to do jadra a nezaťahujte do prostredia zbytočné závislosti. Ja mám desktop výborne vyľadený a fakt by ma naštvali pokiaľ sa nebude dať používať ako chcem a aby bol rock stable ako doteraz. Na serveri detto, alebo existuje nejaký lepší systém podľa ktorého treba zmeniť smerovanie? Však je tu dosť práce so sieťami, teda aspoň podľa toho čo občas píšeš (prednášaš), tak nedorobíme jedno, zahodíme to a zas na zelenej lúke s novými bugmi a tak dookola.

Tak mi poraď čo mám robiť, keď nechcem nič meniť (nehovorím o prirodzenom vývoji) čo mám robiť aby to tak ostalo.

Nevstoupíš dvakrát do téže řeky, výchozí podmínky jsou značně odlišné, takže ať se bude dít cokoliv, srovnání s Windows to asi nesnese.

Však oni to už nejak zrovnajú.

[pavlix]

Však oni to už nejak zrovnajú.

Spíš se obávám, že všechny přirovnání vycházejí ze základu... nemám rád windows, nemám rád systemd, tedy systemd a windows jsou to samé. To je logika na úrovni... kočka má čtyři nohy, kráva má čtyři nohy, kráva je tedy kočka.

[Bedňa]

Roky spokojné užívanie nieje argument? To prečo sa Linux dostal na tak vysokú úroveň je vďaka tomu, že sa nebúralo, ale stavalo. Je úplne jedno či sa budeme baviť o kernely, alebo živote, sú postupy ktoré fungujú.

Mačka je zviera, takže krava nemôže byť zviera.

[pavlix]

Roky spokojné užívanie nieje argument?

Roky spokojené používání skutečně není argument pro zcela nesouvisející tvrzení.

Mačka je zviera, takže krava nemôže byť zviera.

Wut?

[Bedňa]

Roky spokojené používání skutečně není argument pro zcela nesouvisející tvrzení.

Pre mňa je ale jediné podstatné. Už si niekedy opravoval niečo čo funguje? Pokiał niekomu inému nejaká funkčnosť chýba tak nech si ju dorobí, ale necpe ju ďalšiemu. Nech sa správa k ostatným tak ako tu bývalo zvykom. Bohužiał nemám žiadny reálny nápad ako tomuto zabrániť, tak mi ostáva len nadávať. Ale vidím to aj u nás v práci, nech už hocikto príde so sebeväčšou kravinou tak sa to ujme pokiał vie o tom krásne rozprávať, alebo kričať, prípadne oboje.

[pavlix]

Pre mňa je ale jediné podstatné.

Chápu, že jsou lidi, kterým něco přijde natolik podstatné, že to nacpou do jakékoli diskuze, ale komunikovta s nimi je dost náročné.

[Bedňa]

Chápu, že jsou lidi, kterým něco přijde natolik podstatné, že to nacpou do jakékoli diskuze, ale komunikovta s nimi je dost náročné.

Dík za pochopenie. S tebou budem určite rád hocikedy rád komunikovať, ale nedá sa s niekym, ako je Lennart ktorý na teba pošle psy hoci len animované na obrázku. Mám proste vždy nutkanie pridať svoj názor, že je to neskutočný arogantný hajzel a takýto v dejinách nikdy nič nepriniesli.

Zas to beriem ako hnací motor pre udržiavanie si svojho Linuxu a už mám aj parťáka :) Nieje to žiadny truc podnik, mám proste rád veci tak ako chcem. Pritom to dá menej námahy ako nastaviť aby rock stable IceWM pod systemd nepadlo.

[pavlix]

Zas to beriem ako hnací motor pre udržiavanie si svojho Linuxu

Děláš mi radost. A na čem to stavíte?

[Bedňa]

Kámo toto si prosím prečítaj celé a nie len TL;TD

Mno keby som napísal úplne pravdu, tak na tom najlepšom zo všetkého :) Teda vlastne riešime použiteľný desktop a pokiaľ by si mal napr. dve killer features so systemd pre ktoré sa ho oplatí použiť, tak by sme sa ich pokúsili vykostiť a implementovať. Negarantujem že skôr ako za pol roka za rok, osobne máme plán do 2016 spustiť projekt do nejakej beta verzie a uvoľniť slobodne. Tak časti sa budú postupne uvoľňovať, ale to v rámci "IceBuntu". Pokiaľ by si sa zaujímal len o Init, tak do OpenRC komunity možno treba strčiť správnym smerom a pohne sa to samo. Upstart má výborný základ, ale kurwa, ale na launchpade robí kopec ľudí ktorí ani neodpovedajú na problémy, kde sú staré začiatky Ubuntu. Preto napríklad veľa vecí riešim cez IRC, inak nikoho nedokopeš ani aplikovať patch hoci mu ho pošleš a to patch na dva riadky, nedá mu ani status. Je to kopec roboty, kopec srandy. Na GitHub sa nadáva pre TOS, ale tá komunita ktorá tam chodí a nemá problém pomôcť proste milujem, to si človek nájde priateľov po celom svete a bez problémov tolerujú maďarskú angličtinu a poďakujú za feedback, hoci si urobil chujovinu ty a ešte ťa pozvú na drink až by si náhodou ukázal niekde v Bristole. That is free software.

[pavlix]

do OpenRC komunity možno treba strčiť správnym smerom a pohne sa to samo.

Pokud jde o strkání, do komunit, co se pohnou pak samy, tak mě zajímají až výsledky, nikoliv kecy ;).

Preto napríklad veľa vecí riešim cez IRC

To jsem se v RH taky rychle naučil ;).

Na GitHub sa nadáva pre TOS, ale tá komunita ktorá tam chodí a nemá problém pomôcť proste milujem, to si človek nájde priateľov po celom svete a bez problémov tolerujú maďarskú angličtinu a poďakujú za feedback

Zatím musím říct, že jsem na GitHub chodil jenom pro kód a to ideálně od lidí, které už znám jinak, nikoliv pro komunitu.

hoci si urobil chujovinu ty a ešte ťa pozvú na drink až by si náhodou ukázal niekde v Bristole.

A co takhle drink v Brusellu, pojeď na FOSDEM, není to nějak nákladné, když vše zařídíš včas!

[Bedňa]

A co takhle drink v Brusellu, pojeď na FOSDEM, není to nějak nákladné, když vše zařídíš včas!

Tak cca?

[pavlix]

Vstupné dobrovolné, letenka kolem 3k, ubytování kolem 3k, něco na jídlo. Na ubytování se dá asi ještě ušetřit.

[Bedňa]

Tak asi by som sa zviezol s niekym s autom, chodieva tam dosť ľudí.

[pavlix]

Já se loni svezl redhatím autobusem ;).

[Bedňa]

To bolo asi veľmi veselé :)

[xkucf03]

Případná rizika nezávislí až tak na tom co dělá Lennart, jako spíš na tom, co dělají ostatní. Jde tu o závislosti komponent v systému a možnost je vyměňovat.

Bude jádro závislé na systemd? Budou aplikace a pod-systémy závislé na systemd? Případně které?

[pavlix]

+1

[Kvakor]

Bude jádro závislé na systemd?

No, nevím, zatím mám pocit, že tendence je spíš opačná, viz např. devtmpfs nebo možnost vestavět soubory s firmware (stejně jako initramfs) přímo do jádra. Což nzmená, že např. pro jednoduché embedded systémy není pro dynamické položky v /dev už potřeba udev (pokud nevadí absence nastavení práv a přídavných symlinků).

[Sten]

Udev snad nikdy nebyl potřeba. Teda alespoň si pamatuju dobu, kdy se soubory zařízení vyráběly přes mknod a taky to fungovalo.

[pavlix]

Spousta věcí se přes udev a podobné automatizuje, nejen vytváření nodů.

[vlastikroot]

Delal jsem si svuj embedded system, jen jadro a minimalni userspace s aplikaci v Qt. A funguje to Veskera konfigurace hardwaru je zakompilovana v jadre, pripadne mam moznost nacitat nejake moduly (nacitam tak napr. GPU ovladac). Je to sestaveny z baliku z debianu, neni tam zadny init system, vsechno obstrarava kratky jednoduchy skript.

[xkucf03]

A používáš Xka nebo něco jiného? Pro jakou platformu to je?

[vlastikroot]

Je to TS4800. Xka nemam, je to pres EGL (v Qt -platform eglfs), da to sice trochu praci rozjet na tom proprietarni ovladac na OpenGL ES2, ale stoji to za to. Input jede pres ovladace uvnitr Qt, zatim je tam ovladac na mys, klavesnici a multitouch display (pres evdev z jadra).

[Václav "Darm" Novák]

Tohle zní dobře, něco podobného budu brzo potřebovat (s dotykáčem)

[mirec]

Hmm, ako je na tom Z430 s podporou linuxu? Nie že by som teraz chcel prejsť na niečo podobné, práve včera som rozbehal na linuxe nové ovládače mali 400 (ehm to bolo peklo na vytrhanie vlasov, v podstate som musel dopísať časť open source driveru aby to bežalo na mojej krásnej novej A20) - foto (nič moc kvalita, s polarizačným filtrom som mal problém odfotiť tak aby dotyková vrstva nerobila problémy).

[vlastikroot]

Podpora je pres proprietarni driver (AMD GPU Z430 Z160), aspon na tom TS4800 - modul do jadra je open source a closed source libGL. Melo by to jit na freedreno, ale nevim jestli k tomu je ten KGSL modul do jadra, neresil jsem to. Kazdopadne to neni nic moc, co se tyce svobody, verzovani a tak - drzi me to na jadre 2.6.35. Ale OGL jde bez problemu (po tom co se to cely rozmaka). Bylo by moc hezky, kdyby nekdo tu podporu pro Z430 do freedreno dopsal

[mirec]

Mám taký pocit, že mali je v ešte väčšom bahne V každom prípade o tom v najbližšej dobe napíšem krátky blog.

[Bedňa]

To si si mohol použiť TCL je tam veľa vecí vyriešených a máš to bez práce.

Skúšal si niekedy flashnúť U-Boot do telefónu a dostať tam Linux? Tým tvojim komentom si ma naštartoval, asi to dnes testnem. Prípadne nepoznáš nejaké "bezpečné" riešenie ako predať boot nejakému linuxovému bootloaderu.

[vlastikroot]

Mival jsem N900 Ale predtim jsem zkousel linux na widle PDA, to se ale zavadelo pres exe aplikaci ve widlich. Taky jsem si hral s FreeRunnerem, tam byl u-boot. Ale na nic jsem primo u-boot neflashoval.

[Bedňa]

Jako U-boot tam nieje problém dostať, práve som tam narval SHR (následovník Openmoko). Píšu že prvý boot môže trvať, ale už to beží dve hodiny a nič (asi skapalo), tak skúsim niečo iné.

[Václav "Darm" Novák]

Na hraní si s Linuxem na PDA jsou úžasná zařízení Sharp Zaurus  Linux mají defaultně, na mém SL-C3000 jsem rozběhal i OpenBSD.

[kotyz]

Já chtěl na Palm Tungsten T3 hodit linux, ale nepodařilo se mi sehnat image nebo instalačku, sice byl na to na hackndev návod, ale linky nefunkční. Asi sem přišel moc pozdě, v době kdy už to nikoho nezajímalo...

[Václav "Darm" Novák]

A ten Sharp bys nechtěl? Já mám teď jiné problémy a věci co chci řešit

[kotyz]

Tak vždycky je lepší ho mít než nemít, ikdyby se měl jenom válat v šuplíku jako se teď válí i ten Palm T3...

Čas by byl, ale zase nejsou žádný prachy (na nový hračky).

[Kvakor]

Udev snad nikdy nebyl potřeba. Teda alespoň si pamatuju dobu, kdy se soubory zařízení vyráběly přes mknod a taky to fungovalo.

Proto píšu dynamické, na statické opravdu stačí udělat /dev ručně mknodem a třeba ho i zakompilovat do jádra jako součást initramfs.

[Sten]

Na to býval v jádrech 2.6 devfs

[User682]

zdravim,

pridam jedno male cislo, ktere mozna napovi par informaci k tomu co pisete.

Osobne jsem se uz parkrat domnival, ze vsechny distrubice na Linuxu maji nejake rovnomerne zastoupeni, co se tyce uzivatelu a stejnou kupni silu.

Za 2 roky jsem si overil na prodejich, ze uzivatele Ubuntu nakoupi 4-6x vice nez uzivatele jine distribuce. Pokud nekdo pouzivate reklamni systemy, tak vidite i co uzivatele kolikrat hledali a ziskate podobny pomer...

Cim to presne je to nevim.

gf

[SheSedSheIs18]

Pretoze Ubuntu funguje a Ubuntisti teda maju cas zarabat peniaze. Uzivatelia Gentoo, Archu, Debiana, Fedory cely den hackuju svoj OS aby im fungoval takze potom nemaju cas zarabat money.

[rADOn]

Však bych se taky neodvažoval tvrdit že ubuntistů je málo. Ale relativně k počtu má mizivý vliv – který projekt Canonicalu se dá považovat za obecně rozšířený? Co si pamatuju tak jen upstart měl ambice proniknout ven z ghetta. Dokud bude ubuntu fungovat podle filozofie že svět končí launchpadem a upstream je sprosté slovo, tak může mít kolik chce uživatelů (a kdybych byl Mark tak bych dnes byl velmi znepokojený nástupem Mintu) a pořád bude v širší komunitě zanedbatelnou položkou.

[backinabag]

Ze zapisku se mi nepodarilo vyparsovat konkretni a jasny argument proti. Nemyslim, ze by Lennarta zajimaly embedded zarizeni, ten projekt se snazi resit problemy desktopoveho a serveroveho Linuxu.

Desktopovemu Linuxu chybi jednotne API a to je podle me dost zasadni problem, ktery zatim nikdo nevyresil, protoze neexistuje zadna centralni autorita. Windows ani OS X tento problem nemaji. Je sice hezke, ze existuje milion ruznych distribuci, ale co to znamena pro vyvojare aplikaci? Ze si musi vybrat jednu nebo vic konkretnich distribuci s <1% podilem na trhu nebo doufat, ze distribuce jim udelaji balicky.

[xkucf03]

Zrovna většina desktopových aplikací s init systémem vůbec nijak do styku nepřijde, zajímá je tak leda jestli je tam GTK nebo Qt (přičemž většina desktopů bude mít oboje) a víc není potřeba moc řešit, poběží to všude. Naopak se ty aplikace běžně portují i na úplně jiné OS.

[FrostyX]

Je sice hezke, ze existuje milion ruznych distribuci, ale co to znamena pro vyvojare aplikaci? Ze si musi vybrat jednu nebo vic konkretnich distribuci s <1% podilem na trhu nebo doufat, ze distribuce jim udelaji balicky.

Což ovšem systemd vůbec neřeší.

[backinabag]

Ten jeho novy projekt ano, teda castecne. Ale myslel jsem to i jako obecnou poznamku, z pohledu vyvojaru by bylo idealni, kdyby to fungovalo podobne jako na Androidu.

[FrostyX]

Můžu poprosit o link na ten projekt?

[backinabag]

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

[pavlix]

Ten jeho novy projekt ano

Toho si nejsem vědom. Nový projekt řeší jen alternativní způsob distribuování linuxu pomocí hotových obrazů a jejich identifikaci. Neznamená ani přechod všech distribucí na ten nový způsob, ani v případě přechodu jednotné rozhraní, a pokud se nepodaří prosadit jednu distribuci na úkor ostatních, tak ani fungování podobné Androidu. Ale jinak klobouk dolů za marketingovou stánku.

[backinabag]

Pokud to adoptuji dve az tri vetsi distribuce nebo pokud si ten balickovaci system nainstaluje dostatek uzivatelu, tak vyvojar bude moci vytvorit balicek, kterym pokryje velkou cast linuxovych uzivatelu a zaroven bude mit temer jistotu, ze to vsem bude fungovat uplne stejne, bez ohledu na nastaveni jejich systemu.

Systemd vlastne taky pomohl k sjednoceni linuxove platformy. Systemd skripty si muze psat rovnou autor softwaru, driv se musely spousteci skripty delat na miru konkretni distribuci.

Marketing nic moc, z diskuzi to vypada, ze 90% lidi nepresvedcil.

[kralyk z abclinuxu]

Pokud to adoptuji dve az tri vetsi distribuce nebo pokud si ten balickovaci system nainstaluje dostatek uzivatelu, tak vyvojar bude moci vytvorit balicek, kterym pokryje velkou cast linuxovych uzivatelu a zaroven bude mit temer jistotu, ze to vsem bude fungovat uplne stejne, bez ohledu na nastaveni jejich systemu.

Nevím jak ty, ale já teda mezi pojmy "jednotné API" a "každá appka si sebou potáhne v balíku veškeré závislosti, i kdyby to měl bejt třeba befunge interpretr napsaný ve whitespacu" vidím jistý rozdíl.

To druhé mi naopak přijde jako krok pryč od jednotného API.

Systemd vlastne taky pomohl k sjednoceni linuxove platformy. Systemd skripty si muze psat rovnou autor softwaru, driv se musely spousteci skripty delat na miru konkretni distribuci.

Ano, to už by se za krok směrem ke sjednocení API dalo považovat. Akorát by to ještě chtělo, aby to API bylo trochu víc standardizované, modularizované a mělo by být nějaké cyklus/roadmap atd., jako je zvykem v civilizované společnosti, ne že se tam každou chvíli objeví něco co zrovna systemd tým napadne.

[backinabag]

Abych to ujasnil, "jednotnym API" myslim v podstate neco jako je Android platforma.

Ten Lennartuv projekt k tomu smeruje: 1) snazi se vytvorit univerzalni format balicku 2) mam pocit ze nekde psal, ze si to predstavuje tak, ze aplikace budou cilit na nejaky framework v nejake verzi, naprikad na Gnome 3.11, s tim ze tenhle framework bude obsahovat veskere API, takze i glibc atd. a ze to bude trochu podobny system jako na Androidu. Ostatni zavislosti budou v soucasti baliku, ale pokud jsem to dobre pochopil, bude tam nejaky chytry buffering, takze se budou stahovat jenom soubory, co jsou potreba.

[frdrx]

Přesně to poskytuje Debian, ne?

[backinabag]

V podstatě* jo, s tím rozdílem, že má tak 10% podíl z Linuxových desktopů. Stejně tak Ubuntu, proto spousta vendorů cílí na Ubuntu, např. Steam.

*Na úrovni Androidu to ale není.

[frdrx]

Vendoři === distributoři proprietárních ***ček? Ať si je nechaj.

[backinabag]

No, proste autori softwaru pro Linux.

Na proprietarnim softwaru neni nic apriori spatnho, ale to je offtopic...

[kralyk z abclinuxu]

V podstatě* jo, s tím rozdílem, že má tak 10% podíl z Linuxových desktopů. Stejně tak Ubuntu, proto spousta vendorů cílí na Ubuntu, např. Steam.

Čili v podstatě říkáš, že výhodou Lennartova systému je to, že se vnutí všem?

[backinabag]

Neni to daleko od pravdy. Pokud by se desktopove distribuce dohodly na nejakem rozumnem standardnim zpusobu distribuce softwaru, tak by to melo pro desktopovy linux pozitivni prinos. To myslim obecne, nevim jestli to co navrhuje Lennart je to spravne reseni, jenom ze jde tim spravnym smerem.

Centralizace neni z podstaty spatna (ani dobra). Proto existuji standardy. Webove prohlizece se taky dohodly na jednotnem formatu webovych stranek. Nikdo z webaru nevola po diverzite, skoro mam pocit ze naopak.

[mirec]

Prosím pripísať mňa medzi tých, ktorí chcú diverzitu ;) Alebo aspoň zrušiť celý ten js bordel a zaviesť namiesto toho bytekód nezávislý od platformy (nech si to beží kľudne aj nad java vm).

[pavlix]

Pokud to adoptuji dve az tri vetsi distribuce

Základním důvodem pro existenci množství distribucí je jejich odlišnost. To, co navrhuješ, efektivně znamená o tento koncept přijít a zavést jednu standardizovanou distribuci a říci, že tě zajímají jen uživatelé této distribuce a jejích rebrandingů. Jedna taková distribuce tu už je a jmenuje se Android a je v celku pochopitelné, že by si někteří rádi zopakovali jeho úspěch.

tak vyvojar bude moci vytvorit balicek, kterym pokryje velkou cast linuxovych uzivatelu

To ale už platí. Vývojář dnes může cílit na Android a tím na nejpočetnější skupinu uživatelů systému s linuxovým jádrem. A nelze říci, že se Android nepočítá, protože bys pak musel připustit, že se nebude počítat ani tebou předvídaný systém.

Stejnětak bude moci vývojář cílit na jakoukoli majoritní distribuci, ať už bude distribuovaná v jednotlivých balících nebo ve formě obrazů. Nevidím v Lennartově textu nic, co by jen naznačovalo, že tento problém magicky zmizí, i když podobnou formuli tak rád používá.

Systemd vlastne taky pomohl k sjednoceni linuxove platformy. Systemd skripty si muze psat rovnou autor softwaru, driv se musely spousteci skripty delat na miru konkretni distribuci.

Sice je to značné odběhnutí od tématu, ale pokud jde o sjednocení konfigurace systémových služeb, tady nelze zásluhu popřít. Jednak systemd definuje určitou sadu chování, která je v tuto chvíli na nejlepší úrovni z toho, co znám. Dále definuje syntaxi pro zápis toho chování a adresářovou strukturu, přičemž obojí je natolik triviální, že by nebyl problém napsat konvertor do syntaxe jiného software, který by tu stejnou sadu chování implementoval.

Takže na jednu stranu je to přínos systemd, na druhou stranu pokud by šlo jen o tyto vlastností, zítra to může být přínos systemxyz. Mnohem důležitější je celý systém vlastností, který vyvolává dojem, že se bez systemd nelze obejít.

Marketing nic moc, z diskuzi to vypada, ze 90% lidi nepresvedcil.

Pokud jde o komerční úspěch, někdy je lepší přesvědčit menšinu, která rozhoduje o financích, než většinu, která se vykecává v diskuzích. Nehledě na to, že o bezvýznamném projektu by v diskuzích nemluvili vůbec.

[backinabag]

Základním důvodem pro existenci množství distribucí je jejich odlišnost. To, co navrhuješ, efektivně znamená o tento koncept přijít a zavést jednu standardizovanou distribuci a říci, že tě zajímají jen uživatelé této distribuce a jejích rebrandingů. Jedna taková distribuce tu už je a jmenuje se Android a je v celku pochopitelné, že by si někteří rádi zopakovali jeho úspěch.

Lennartuv balickovaci system sebere pouze cast odlisnosti, a to balickovacich systemu. Coz povazuju za dobry trade-off, myslim ze po secteni negativ a pozitiv vyjde kladne cislo. A samozrejme se to tyka pouze typickych desktopovych a serverovych distribuci jako Debian, Fedora, Arch, atd.

Vývojář dnes může cílit na Android a tím na nejpočetnější skupinu uživatelů systému s linuxovým jádrem.

Ale pouze pokud to je aplikace pro mobil / tablet.

[pavlix]

Lennartuv balickovaci system sebere pouze cast odlisnosti, a to balickovacich systemu.

Lennart pokud vím zatím žádný balíčkovací systém nenavrhl.

[backinabag]

To o cem psal je sice dost vagni, ale az to bude hotovy, soucasti bude neco jako balickovaci system nebo ne?

[pavlix]

Já vycházím z toho, co se tam píše, nikoliv z toho, co si k tomu umím představit dle svých vlastních zkušeností a přání (alespoň do té míry, do jaké to dokážu). Moje zkušenost je totiž taková, že ve většině případů, kdy mě nadchne něčí nápad, mě ve skutečnosti nadchne až verze, kterou jsem si rozšířil ve svojí hlavě a dotyčný mi pak vysvětluje, že až tak to nemyslel a nebo nevěřícně kroutí hlavou.

Jestli lennart přijde s balíčkovacím systémem považuju stejně pravděpodobné, jako že přijde s čímkoliv jiným, co ještě v systemd není ;).

[backinabag]

No, uvidíme, jsem zvědavý na další vývoj :)

[kralyk z abclinuxu]

A samozrejme se to tyka pouze typickych desktopovych a serverovych distribuci jako Debian, Fedora, Arch, atd.

U wot m8? Ty si skutečně myslíš, že se v Archu pacman nahradí touto BTRFS-only věcí, která v podstatě není vůbec slučitelná s rolling-release modelem? To seš tak mimo mísu, že s**** na náměstí...

[backinabag]

Zavislost na btrfs se mi taky nelibi.

která v podstatě není vůbec slučitelná s rolling-release modelem

Jak to?

[kralyk z abclinuxu]

Zaprvé, jak to podle tebe fungovalo? To by se každej den vydával novej usr: bundle, nebo by žádnej nebyl a všechno by byly aplikační a framework bundly?

Zadruhé, v rolling release jde o to dostat co nejdříve nejnovější verzi všeho, včetně knihoven, nástrojů, prostředí, atd. Jak například aktualizuješ python na nejnovější verzi, když každá aplikace používající python má ve svém bundlu svůj python? To samé s knihovnami a dalšími věcmi...

[pavlix]

Zadruhé, v rolling release jde o to dostat co nejdříve nejnovější verzi všeho, včetně knihoven

Já myslel, že v rolling release jde jen o to vyhnout se nutnosti upgrade.

[David Jaša]

To se vyhneš tak leda v RHEL/Centos jedné verze, a ještě ne tak docela, i tam se někdy něco rebasuje na novější verze.

[pavlix]

RHEL ani CentOS rolling release nejsou. Rolling release je o tom, že nainstaluješ distribuci a ta nezastará, protože se balíky updatují průběžně, tedy nikdy nedojde na chvíli, kdy musíš upgradovat systém na novější verzi.

[David Jaša]

Pointa je ta, že většina sw má čas od času větší upgrade, na který se musí nějak reagovat, a co do celkového času stráveného nad těmito upgrady je jedno, jestli je to dávkované po jednom v rolling distribuci, nebo se to shrne jednou za čas dohromady do nějakého releasu.

[pavlix]

To ale na definici rolling distribuce nic nemění, že. Já jsem jen upozorňoval na to, že rolling distro rozhodně nemusí být závod o to co nejdříve uživatelům nainstalovat právě vydané verze software, což je mimochodem vidět in na gentoo stable.

[David Jaša]

však to nerozporuju. Rozporuju to, že se vyhneš upgradu - nevyhneš, jen ho rozdrobíš na spoustu malých upgradíčků.

[pavlix]

To je jen chytání za slovíčka, je vcelku jasné, že v té větě byl myšlen upgrade distribuce, nikoliv update/upgrade aplikací.

[lertimir]

To záleží co se bere pod pojem "upgrade" i u standardní "releasované" distribuce běží průběžné opravy a aktualizace, ale nejsou to změny majoritních releasů těch balíčků. U "roling release" distra jsou zahrnuty větší změny v těchto průběžných aktualizacích. Což je drobně větší riziko rozbití něčeho při každé aktualizaci, proti většímu riziku rozbití něčeho při aktualizaci releasu. A některá distra s release politikou mají i vedlejší repa, kde je z vybrané oblasti aktuální soft. Např. moje openSUSE má kromě hlavních repozitářů i repozitáře "BuildService" (filesystems, KDE:Extra, Gnome:Apps, LXDE, LibreOffice, a další) kde je aktuální soft a mohu si vybrat jestli balík budu brát z hlavního repa nebo z build service. Nicméně to nemění nutnost celeho upgradu při nové verzi.

[rADOn]

To tedy mění. Na rolling distru takový upgrade nemusí vůbec nastat. Což sice většinou není třeba resp. je ti to putna, ale pokud máš balík který nechceš upgradovat tak jsi v úplně jiné situaci. Já třeba nechci upgradovat na novější udev kvůli závislosti na systemd, takže suším na disku už značně foustatý udev. Dokud nebudu potřebovat něco co bez něj nefunguje, můžu ho takhle sušit roky, zatímco zbytek systému rolluje dál. V releasujícím distru doroluješ do příští verze a pak jsi buď skončil nebo se musíš babrat s backportováním. To co popisuješ je určitá forma rollování, ale proti skutečně release-less distru je to velmi omezené a nepraktické. Jen tak pro ilustraci, nejstarší verze libc v portage je teď glibc-2.9_p20081201 (čímž nechci říci že balíků které proti ní půjdou zkompilovat bude mnoho

[rADOn]

To je pravda. Na gentoo není nic divného mít třeba včerejší kernel a k němu libc která pamatuje ještě debian sarge

[backinabag]

Vsechno aplikacni a framework bundly. Python a knihovny by predpokladam byly soucasti aplikacniho bundlu. Takze by nesly aktualizovat oddelene, to je pravda, jako protiargument to beru. Na druhou stranu, nemohlo by se stat, ze updatuju knihovnu a pak se mi rozbije neco, co na ni zavisi.

A jednim zpusobem by to bylo pro rolling release naopak vhodnejsi, ted musim cekat, nez nekdo updatuje PKGBUILD... tenhle krok by odpadl.

[backinabag]

Mimochodem, nejsem o tom napadu uplne presvedcenej, z jinych duvodu - 1) neni jasne, jak to bude resit pluginy, fonty, ... 2) trochu se bojim, ze to bude pomaly, konkretne to btrfs deduplication.

[lertimir]

Základním důvodem pro existenci množství distribucí je jejich odlišnost. To, co navrhuješ, efektivně znamená o tento koncept přijít a zavést jednu standardizovanou distribuci

S tím souhlasím. Odlišnost distribucí je podstatná. Ale otázka je, co je podstatné pro jejich odlišnost. Nemyslím si, že je to, že Fedora a Debian mají knihovny umístěny v jiném místě stromu, nebo že síťové konfigurační soubory jsou u Debianu, CentOSu a nebo openSUSE na jiném místě, a ani to že máme mraky různých balíčkovacích systémů. Za podstatné považuji to, že mám nějaké funkční celky, které mají nějaké vlastnosti, mohu si vybrat, které funkční celky zahrnu a mnohdy je mohu realizovat různým způsobem a vyberu si kterým. Třeba typ webového serveru, file systému, mail serveru nebo GUI. Distribuce je v podstatě názor, jak mít sestaven z elementárních kostiček funkční systém. A proč by nebylo možné vytvářet různé distribuce nad společnou bází. Tím, že není žádná společná báze, tak není možné sdílet administrativní nástroje.

Pro mne třeba typický příklad: Mám rád Yast z openSUSE jakožto administrativní nástroj systému. Líbí se mi, že je jak GUI tak i terminálové ncurses. Ale neexistuje možnost, jak tímto nástrojem ovládat systém v Debianu nebo v CentOSu. Na rozdíl od toho, že v každé z nich si mohu svobodně vybrat, webový server, mail server nebo GUI, administraci ne, protože je u každého jiná.

[rADOn]

Tim jsi ale cely linuxovy ekosystem degradoval na uroven sbirky derivatu ubuntu. A tvuj "typicky" priklad je opravdu typicka ukazka toho jak se subjektivni preference nedaji povazovat za technicky argument. Ja bych treba na yast nesahl ani klackem, rpm povazuju za bordel a obecne se vyhybam vsemu co si sam nezkompiluju. Takze bud se budem hadat ci "spolecna baze" je na draka nebo se proste smirime se tim ze kazdej ma svoji oblibenou prichut.

[FrostyX]

Takze bud se budem hadat ci "spolecna baze" je na draka nebo se proste smirime se tim ze kazdej ma svoji oblibenou prichut.

Třeba co se týká balíčkování, pro každý balíček je ve všech distrech potřeba napsat a udržovat soubor, ve kterém je spousta informací o balíčku (název, verze, kategorie, závislosti, etc). Potom tam bývá napsáno, jak že se ten balíček má vybuildit, nainstalovat, etc.

Na Gentoo máme ebuild, na Archu pkgbuild, Fedora má spec, Debian nějakých pár souborů v control.tar.gz. Všechny popisují totožné informace, pouze malinko odlišným způsobem. Kdyby se domluvil standard pro takovýto soubor, usnadnilo by to spoustu věcí, protože už by nebylo potřeba vytvářet balíčky pro jednotlivé distribuce, ale prostě pro linux.

A protože by byl standardizovaný jen takovýhle popis balíčku a nic nad tím, distribuce by mohli stále mít úplně stejné balíčkovací systémy a poskytovat ty výjimečnosti jako doposud.

Everybody wins. Jenže to je utopie, protože by to dopadlo spíš takto http://xkcd.com/927/

[rADOn]

To je hezká teorie ale má chybu v bodě "totožné informace". Právě proto že distribuce nejsou úplně stejné tak informace v controlu, specu neřkuli ebuildu nemohou být shodné. Ano jsou tam _některé_ věci stejné ale nedá se na to spoléhat a k vybuildění balíku to nestačí. Pro začátek jedna z věcí na kterou se spolehnout nedá je jméno balíku… má cenu to dál rozvádět?

BTW existoval jistý projekt v tomto směru (a nejspíš ne jeden) na univerzální popis balíku. AFAIK si nedělal ambice na automatické balení, ale jen na usnadnění práce s balením tím že by závislosti byly popsané v nějakém jednotném formátu. Ale ten formát byl nějake hrozné XMLko takže se to neujalo.

[FrostyX]

Pro začátek jedna z věcí na kterou se spolehnout nedá je jméno balíku… má cenu to dál rozvádět?

Jestli na mě máš chvilku času, poprosil bych o to vysvětlení. Možná máš pravdu a moc rád to potom uznám, ale v tuhle chvíli mě nenapadá, proč by se balík nemohl na všech distribucích jmenovat stejně.

[mirec]

Gentoo / Arch: libniečo

Debian a deriváty: libniečo, libniečo-dev

Gentoo: uwsgi

Debian a deriváty: uwsgi-plugin-admin uwsgi-plugin-cache uwsgi-plugin-carbon uwsgi-plugin-cgi uwsgi-plugin-echo uwsgi-plugin-erlang uwsgi-plugin-fastrouter uwsgi-plugin-fiber uwsgi-plugin-graylog2 uwsgi-plugin-greenlet-python uwsgi-plugin-http uwsgi-plugin-jvm-openjdk-6 uwsgi-plugin-jwsgi-openjdk-6 uwsgi-plugin-logsocket uwsgi-plugin-lua5.1 uwsgi-plugin-luajit uwsgi-plugin-nagios uwsgi-plugin-ping uwsgi-plugin-probeconnect uwsgi-plugin-probepg uwsgi-plugin-psgi uwsgi-plugin-pyerl-python uwsgi-plugin-pyerl-python3 uwsgi-plugin-python uwsgi-plugin-python3 uwsgi-plugin-rack-ruby1.8 uwsgi-plugin-rack-ruby1.9.1 uwsgi-plugin-rpc uwsgi-plugin-rrdtool uwsgi-plugin-rsyslog uwsgi-plugin-signal uwsgi-plugin-symcall uwsgi-plugin-syslog uwsgi-plugin-ugreen uwsgi uwsgi-extra uwsgi-plugins-all uwsgi-core uwsgi-infrastructure-plugins uwsgi-app-integration-plugins uwsgi-emperor uwsgi-plugin-alarm-curl uwsgi-plugin-alarm-speech uwsgi-plugin-alarm-xmpp uwsgi-plugin-coroae uwsgi-plugin-curl-cron uwsgi-plugin-emperor-pg uwsgi-plugin-geoip uwsgi-plugin-jvm-openjdk-7 uwsgi-plugin-jwsgi-openjdk-7 uwsgi-plugin-ldap uwsgi-plugin-pam uwsgi-plugin-router-access uwsgi-plugin-sqlite3 uwsgi-plugin-v8 uwsgi-plugin-xslt

[FrostyX]

No jasně, protože třeba Gentoo používá kategorie/balík. Ale ptám se, opravdu chceme, nebo potřebujeme, aby to každá distribuce měla jinak, nebo se to prostě liší a proto říkáme, "ono by to nešlo, protože se ty názvy liší, a měnit se to nesmí"?

[FrostyX]

Dohodneme se na tom, že formát názvu balíčku bude nejlepší kategorie/název, protože je to nejpřehlednější a nemusí se ke každému druhému názvu balíku cpát nějaký prefix.

Současný stav je takový, že každé distro má definované nějaké kategorie balíčků. Ty rozhodně nejsou stejné, ale jak moc se asi můžou lišit? Někde můžou být trošku konkrétnější, někde trošku míň, případně jsou ty názvy navzájem synonyma. Co přesně brání tomu, abychom se všichni domluvili na stejných kategoriích? Neříkejte mi ale, že je vlastně dobře, že jsou ty kategorie všude jiné, protože nám to dává možnost volby, nebo tak něco. Praktická výhoda toho, že jsou na každé distribuci jiné názvy kategorií balíčků, není prostě žádná.

Potom už ani není problém mít stejné názvy balíčků.

Já teď rozhodně nechci říct, že teď jsem to vymyslel úplně tím nejlepším způsobem. Rozhodně bylo by potřeba tohle vyřešit opravdu kvalitně.

Jen nechápu, proč by to z principu nemohlo jít. Prý to nešlo to ani s initem a pak stačilo aby přišel jediný člověk a bylo. Tam byl akorát problém v tom, že to byl zrovna Lennart.

[kralyk z abclinuxu]

Současný stav je takový, že každé distro má definované nějaké kategorie balíčků.

Arch nemá kategorie balíčků. Některé balíčky jsou ve skupinách, ale zdaleka ne všechny.

Potom už ani není problém mít stejné názvy balíčků.

Pak už jen zbývá vyřešit ten drobný problém, že různé distribuce sestavují balíčky různě - všelijaké ty kompilační přepínače jako --wtih-libfoo a podobně, aplikované jsou různé patche, atd.

V té chvíli si uvědomíš, že distribuce nedělají jen to, že by různým programům dávaly různá jména balíčků, aby naschvál způsobily rozdíly, ale jejich práce je v podstatě poskládat z mnoha různých kusů SW z mnoha různých zdrojů a v mnoha různých jazycích dohromady nějaký funkční celek. Kdo by podle tebe měl tuhle práci dělat, když ne distribuce?

[FrostyX]

Pak už jen zbývá vyřešit ten drobný problém, že různé distribuce sestavují balíčky různě - všelijaké ty kompilační přepínače jako --wtih-libfoo a podobně, aplikované jsou různé patche, atd.

To nemusí být problém ne? Nikdo by nebránil distribucím mít vlastní repozitáře, ve kterých by měli svoje recepty pro svoje balíčky. Jen by ty recepty byly ve stejném formátu jako mají ostatní. Takže debian by si klidně buildoval bar s --with-libfoo, Fedora bez něj. Nemusím vymýšlet kolo, abych dal konkrétnější příklad. Všechny tyhle --with-libfoo by se třeba mohli popisovat pomocí USE flagů jako na Gentoo a jednoduše by si každá distribuce buildila balíčky s jakými flagy by chtěla.

Ty by klidně mohli být definované v jiném souboru a ten by mezi sebou distribuce nesdíleli, není problém. Potom když bych chtěl jakožto třeba balíčkář Fedory zabalíčkovat foo z Debianu, prostě bych stáhl recept z debianu, vytvořil bych k němu jen soubor s flagy, případně ho zkopíroval taky a hotovo.

Jako já si dovedu představit, jak moc nereálně to zní, ale jako proč ne?

... ale jejich práce je v podstatě poskládat z mnoha různých kusů SW z mnoha různých zdrojů a v mnoha různých jazycích dohromady nějaký funkční celek. Kdo by podle tebe měl tuhle práci dělat, když ne distribuce?

To by pořád dělali distribuce - viz první odstaveček, ale když přijde člověk s nějakým SW a chce ho nějak dostat mezi lidi, tak si ty balíčky prostě musí udělat sám. A měl by to o dost jednoduší, když by mu stačilo napsat soubor v jednom formátu, ze kterého by potom mohl vytvořit balíčky pro všechny distra, místo toho, aby musel popisovat ten balíček pro každou distribuci.

Ale snazší by to bylo celkově pro každého.

[vlastikroot]

Opravdu, obalit gentoo build system treba DEB balickem, pridat nejaky dependence solver a jsme tam. Jednoduchost archu s vyhodama gentoo a debianu. Pak uz je z mnohauhelniku kolo a neni treba nic dalsiho vymyslet.

[kralyk z abclinuxu]

Jako já si dovedu představit, jak moc nereálně to zní, ale jako proč ne?

No, muselo by v podstatě existovat něco jako meta-balíčkovací framework, který by ale musel poskytovat velkou flexibilitu a spoustu featur, aby z něj mohly vycházet různá distra... Teoreticky by to šlo. Prakticky nevím...

[lertimir]

Jenže není žádný důvod, proč by modifikace balíků, které si distribuce udělá, nemohly být stejné struktuře. To že je jiná kompilace nebo jiná patch do baličku nezmění způsob práce s ním. Proč by nemohl být vyměnitelný za jinak optimalizovaný. Z uživatelského pohledu je pro mne balíčkovací systém jen struktura udržující informace o vzájemných závislostech balíčků a jejich verzí, jak v nainstalovaném systému tak v repozitáři a umožňují akce na jejich synchronizaci. A v podstatě všechny používané systémy tuto funkci splňují plně, takže z uživatelského pohledu jsou pro mne ekvivalentní.

To, že někdo má jinak optimalizovaný balíček při překladu, nevylučuje, že by to nemohl být "drop in replacement". To, že jsou různé názory, jaký ten funkční celek má být je přirozené, ale proč to není nad stejnou strukturou. Podobně mnohé konfigurační soubory mají různé distribuce jinde a podobnost struktur v /etc je hodně přibližná. Naprosto zbytečně.

[rADOn]

To, že někdo má jinak optimalizovaný balíček při překladu, nevylučuje, že by to nemohl být "drop in replacement".

To tedy vylučuje. Kdyby to tak bylo, mohl bys vzít balík z blbuntu, rozbalit ho do klobouka, podle lddčka dohledat a nainstalovat knihovny a fungovalo by to. Ale pokud (například) program chce nptl a já mám glibc zkompilovanou s linuxthreads, tak to nebude chodit ani kdyby jsi balíčkovací systém naučil tancovat kozáčka. Balíčkovací systém tyhle problémy nezpůsobuje a už vůbec neřídí, takže je ani nemůže řešit. Leda by to bylo na gentoo, ale to je trochu jiná pohádka (nápověda: portage není "balíčkovací" systém) a nemá šťastnej konec.

[backinabag]

Sel bych na to jinak, pro zacatek jeden format balicku, ale mely by namespacy. Takze by byl arch:firefox, debian:firefox atd.

[pavlix]

Dohodneme se na tom, že formát názvu balíčku bude nejlepší kategorie/název, protože je to nejpřehlednější a nemusí se ke každému druhému názvu balíku cpát nějaký prefix.

Nejlepší je používat kategorii, protože je to přehlednější a nemusí se používat prefix, prefix, protože všude jinde se prefix používá, navíc kategorie sama o sobě není víc než obyčejný prefix, který je tam teď dokonce dvakrát, Ve skutečnosti jsou kategorie vhodné jen ke zmatení a řešení jinak zbytečných duplicit, kdy název balíku přestane fungovat v den, kdy někdo zabalí související perl modul.

[rADOn]

Ne, kategorií to není. V tom prvním příkladu má debian rozdělený binárky a hlavičky knihovny do dvou balíků. Pokud nepotřebuješ proti knihovně kompilovat vlastní kód (což platí o většine instalací linuxu), tak hlavičky nepotřebuješ. Takže je dobrej nápad to rozdělit tak aby sis nemusel instalovat balast kterej nepotřebuješ. Ale nemusí to tak být (slackware to myslím nemá oddělené, ale ruku bych na to nedal). A v gentoo kde se kompiluje úplně všechno takovýhle dělení nemá žádný smysl, takže to _musí_ být jeden balíček. Takže ten -dev balíček je jen taková užitečná ale umělá konstrukce.

Ve druhém příkladu máš jeden balíček s hromadou modulů, který se přeloží do oddělených .soček. V gentoo se řídí USE flagy který moduly chceš nebo ne (což se předá jako parametry do configure skriptu) takže máš jeden balíček. V binárním distru z principu tohle nejde, takže se to řeší… různě. Nejčastěji (a svým způsobem nejčistěji) tak že se každé .sočko zabalí do vlastního balíku. To je užitečný protože si můžeš zase nainstalovat jen ty části který potřebuješ (některý moduly mohou i kolidovat, třeba OpenSSL vs. GnuTLS nebo klientsky knihovny mysql vs. mariadb vs. percona apod.) ale takovej balík je vlastně kouskem jinýho skutečnýho balíku a má jméno který je vymyšlený a nemá jinej smysl než být vidět jako závislost. Jiný distro si může vymyslet jiný jméno, nebo ty kousky nemusí balit tímhle způsobem nebo dotyčný modul vůbec nemusí mít.

Kromě toho je tu ještě věc že binární distra často dávají do jmen i čísla aby se kolizní verze vnímaly jako jiný balík, takže máš třeba balíky "python2" a "python3". Což zase není špatně anžto takhle můžeš provozovat nekompatibilní verze, ale je to zase něco specifickýho pro každý distro. A týká se to i nejzákladnějšího ze všech základních balíků glibc.

No a pak je tu ta drobná věc že nejsou všechno závislosti. Balík s controlem pro ubuntu na mým systému neubalíš ani kdyby ses rozkrájel, protože nemám nainstalovaný PA, nemám v systému milion patchů který žijou jen v launchapdu, mám jinej init systém a některý systémový knihovny ve verzích a variantách o kterých se blbuntu ani nezdá. Můžu mít uclibc místo glibc, wayland místo X, různý zákeřný volby který mění linkování (třeba --as-needed může závislostma docela zahýbat).

Zkus si pár let provozovat gentoo a uvidíš sám jak moc se může lišit _jeden_ systém (a leccos se i přiučíš)

[FrostyX]

Díky za moc pěkné objasnění. Souhlasím s tebou.

Ale vyplývá mi z toho to, že nemůžu (alespoň ne tak jednoduše jak jsem si představoval) mít stejný název balíčku na source-based a binárním distru, ale nevidím důvod, proč by to nemohlo být jednotné pro binární distra.

Komentář k druhému odstavci už jsem vlastně napsal v #130, tak to nechci zbytečně duplikovat.

Když tak nad tím přemýšlím, Gentoo už vlastně pár (3) let provozuju.

[Sten]

Jakožto vývojář pro Android musím poznamenat, že ani na Androidu to zrovna moc nefunguje. A to i když dáte rovnítko mezi Android a Google Play (systémy bez licencovaného Google Play, jako třeba Kindle, MIUI či Cyanogenmod, jsou ještě zábavnější). Přesněji to funguje asi tak stejně, jako když v Linuxu použijete alien. Většina aplikací nějak fungovat bude, ale ty pokročilé se bez workaroundů neobejdou.

Ale tohle se zatím nepodařilo vyřešit nikomu, ani kompatibilita různých verzí a podverzí Windows není zrovna bezproblémová.

[pavlix]

Hlavně, že věříme, že to Lennart vyřeší a to ještě nic v tomto směru nepředvedl a snad ani se vší vážností neříká, že předvede, pokud nepočítám jeho: „And everyting will magicaly work.“

[rADOn]

Zrovna toho bych se nebál, Lennart & co. už předvedli že prgat umí. Ostatně je to jen přeorganizování klasického přibalování knihoven.

[pavlix]

Nějak mi není jasné, čeho byses nebál. Já mluvím o tom, že se tu objevují divoké spekulace o vyřešení „problému“, na kterém nejspíš ani nikdo nepracuje.

[backinabag]

Muzes dat priklad? Prijde mi, ze az na vyjimky to funguje velmi dobre. Resp. pokud to nefunguje, je to typicky chyba vyrobce telefonu, chyba vyvojare appky nebo nedostacne presne specifikovane API. Narozdil od desktopoveho Linuxu to neni problem navrhu celeho systemu, vzdy jde o nejakou nizkourovnovou chybu.

Je pravda, ze posledni dobou se nektera API presouvaji do Google Play, cimz se Google snazi ziskat nad Androidem kontrolu a paku na vyrobce, ale to je jiny problem...

[Sten]

Ano, většinou je to chyba výrobce telefonu, ale to vás jako vývojáře aplikací zrovna moc nepotěší, pokud se týká hodně prodávaných modelů.

Příklady:

1. rychlé spouštění a vypínání audia (např. pípání) na Galaxy S2 zatuhne ALSA
2. některé telefony Galaxy hlasí, že podporují resampling, a umožňují spustit přehrávání s resamplingem, aniž by ho uměly (prostě jen nepřehrávají)
3. nahrávání pomocí Bluetooth headsetu často víc nefunguje než funguje
4. některé telefony Galaxy mají špatně specifikované otočení fotoaparátu
5. některé telefony HTC ignorují android:inputType="textNoSuggestions", takže bez workaroundu zobrazují spellcheck pro hesla a ukládají je do uživatelského slovníku
6. KitKat zavedl fast path audio pro všechny aplikace používající OpenSL, včetně těch cílících na starší API, bez možnosti to vypnout; <sarkasm>ne, Google, vůbec to nerozbilo zpětnou kompatibilitu</sarkasm>

[frdrx]

Souhlasím, že v zápisku není žádný argument pro nic, ani proti ničemu.

[marvn]

Taky o sobe pise, ze je hater...ti argumenty nepouzivaj a ani nepotrebujou

[kralyk z abclinuxu]

Desktopovemu Linuxu chybi jednotne API a to je podle me dost zasadni problem, ktery zatim nikdo nevyresil, protoze neexistuje zadna centralni autorita.

Tohle ale ten Lennartovo návrh vůbec neřeší.

[backinabag]

Nevim jestli je API ten spravny vyraz... v podstate jsem myslel to, ze pokud bude ten projekt uspesny, autor aplikace vytvori balicek, uzivatel si ho nainstaluje a bude mu to fungovat. Stejne jako na Androidu. Predstav si, ze by vyvojari pro Adroid museli delat balicky pro Samsung, HTC, ruzne custom ROMky atd. A u nekterych aplikaci jeste x ruznych verzi spoustecich skriptu. Ale nastesti Android je jasne definovana a verzovana platforma. Takze kdyz vytvorim aplikaci, ktera cili na Android 2.3+, tak vim ze to pujde nainstalovat a pobezi i za rok na nejnovejsim telefonu od Samsungu, i prestoze tam maji upraveny Android.

[xkucf03]

Jenže Android je distribuce. Jedna z mnoha. Aplikace pro Android ti taky nepoběží na jiných platformách¹ Je to jako kdybys řekl, ať všichni používají Ubuntu², ať je to jednotné a stačí dělat jeden balíček.

_{[1] na některých ano, ale tam museli jejich autoři vyvinout zvláštní úsilí a napsat nějakou překladovou vrstvu – pro balíčky máš zase překladače mezi .rpm a .deb
[2] nebo SUSE, Fedoru, Debian… dosaď si cokoli}

[pavlix]

Je to jako kdybys řekl, ať všichni používají Ubuntu2, ať je to jednotné a stačí dělat jeden balíček.

+1

A nastavit mu závislost jen na ubuntu-desktop, popřípadě používat nějaký ubuntu development kit, který tu závislost nastaví sám a před vývojářem komplexitu závislostí zcela skryje.

[backinabag]

Nikdo nechce sjednocovat zpusob distribuce softwaru u vsech systemu s Linuxovym jadrem. Ale u typickych distribuci jako Debian nebo Fedora to myslim smysl ma.

[pavlix]

Ale u typickych distribuci jako Debian nebo Fedora to myslim smysl ma.

Nahradit RPM a deb něčím jako je RPM by rozhodně smysl mělo ;).

[backinabag]

Nemel bych s tim problem :) , ale to co navrhuje Lennart mi prijde potencialne mnohem prinosnejsi, zalezi na detailech.

[pavlix]

To nic, co navrhuje lennart bude určitě mnohem lepší ;).

[pavlix]

v podstate jsem myslel to, ze pokud bude ten projekt uspesny, autor aplikace vytvori balicek, uzivatel si ho nainstaluje a bude mu to fungovat.

Non sequitur. Zda balíček bude fungovat závisí na tom, pro jakou distribuci ho autor vytvořil a na jaké distribuci byl otestován. Jediný způsob, jak docílit toho, že balíček bude testován na distribuci X distribuci a bude fungovat na distribucích z množiny Y je, že množina Y bude obsahovat pouze distribuci X a rebrandované distribuce, kompatibilní s X.

Jediné, co Lennartův návrh z hlediska závislosti nabízí, je agregovat závislosti do jedné. Jenže to umí i tolikrát kritizované Ubuntu, stačí vyrobit balíček a jako závislost mu dát ubuntu-desktop.

Ale nastesti Android je jasne definovana a verzovana platforma.

A systemd je předpokládám taky jasně definovaná a verzovaná platforma, na které se přechodem na novější verzi nikdy nic nerozbije.

Takze kdyz vytvorim aplikaci, ktera cili na Android 2.3+, tak vim ze to pujde nainstalovat a pobezi i za rok na nejnovejsim telefonu od Samsungu, i prestoze tam maji upraveny Android.

Toto je jistě lákavá představa, ale pokud vím, tak se Lennartův návrh vůbec nezabývá jejím naplněním.

[User682]

Dost casto slysim o tom, ze Linux nema jednotne API a tak.

Co ale neslysim je to, kolik casu stravi vyvojari na Linuxu treba oproti Windows tim, ze resi nejednotne API. Vi nekdo presnejsi cisla ?

Podle toho, co slysim v diskusich, tak mi to prijde, ze tento problem zabira programatorum asi tak 30-80% casu vyvoje. Bud je to tak, anebo se to umele prifukuje. Nejak si clovek musi omluvit, ze to nejde....

Pokud jsem mel za poslednich 15 let sanci neco vysledovat pri vyvoji, tak minimalne 80% casu programujete nejakou bussiness logiku. Klidne 90% casu. A pak teprve resite nejake portace na ruzne systemy.

To same, kdyz vidim .NET na Windows, tak preklad kodu do nove verze frameworku, tak neni vzdy bez problemu.

Muze to nekdo podlozit nejakymi cisly ?

gf

[xkucf03]

Podle toho, co slysim v diskusich, tak mi to prijde, ze tento problem zabira programatorum asi tak 30-80% casu vyvoje.

30-80 je hodně velké rozpětí, tam se vejde skoro všechno. Těch 30 by mohlo být reálných, když někdo podporuje hodně distribucí nebo obecně prostředí a ten program používá hodně nízkoúrovňové věci. Ale v dlouhodobém horizontu by to mělo klesnout mnohem víc – jak už to jednou automatizuješ, tak to jde samo, jen reaguješ na změny, ale neděláš znova a znova tu samou práci při vydávání každé nové verze.

Těch 80% mi přijde zcestných – na to by se každý vykašlal a podporoval buď jen jedno distro nebo to začal dělat jinak (třeba použil nějaký framework nebo abstrakci, které ho od těch rozdílů odstíní).

A hodně programů portují dobrovolníci nezávisle na autorovi ve svém volném čase, případně je za to platí někdo třetí, ale pochybuji, že by tomu věnovali tolik úsilí – to by si totiž mohli pomalu napsat vlastní program.

Na diskuse bych moc nedal, protože tam se většinou ventilují špatné zkušenosti – když to jde hladce, tak to hodně lidí bere jako samozřejmost, není o čem mluvit. Naopak s nějakým zapeklitým problémem se rádi pochlubí nebo si zanadávají.

[rADOn]

Windows mají nějaké "jednotné" API? To slyším prve. Takže už nebudou muset být zvlášť binárky pro win 9x, xpčka a visty? To by bylo fajn

Srsly, unix má jednotný a univerzalní API. Říká se mu POSIX. Pokud do něj opřu binárku bude fungovat i na dvacet let starém 2.4 kernelu. Stejně jako bude exáč zkompilovaný na osmičkách opřený do win32 API fungovat na Windows 98, že?

Ono je to spíš tak že wydle nemají žádné "stabilní" API, jen se vyvíjejí tak pomalu že to tak vypadá. Když budeš kompilovat na linuxu všechno proti stable debianu tak to máš stejný.

[pavlix]

Srsly, unix má jednotný a univerzalní API. Říká se mu POSIX.

Teorie fajn, praxe občas pokulhává.

Když budeš kompilovat na linuxu všechno proti stable debianu tak to máš stejný.

+1

[kralyk z abclinuxu]

Srsly, unix má jednotný a univerzalní API. Říká se mu POSIX.

Tak určitě (viz PTY_BYTES_AVAILABLE)

[martin]

S prominutim, ALE PRD. Na widlich to funguje tak, ze si kazda aplikace veze potrebne dll s sebou . Bud si je (v lepsim pripade) placne do Program Files (pak to je de facto ekvivalent static linked binary), nebo (v tom horsim) je naprasi do windows\system32. Bo widle nemaji verzovani dll, tak je jasny, ze tim ta appka neco prepise nejaky jiny app. A pak to bud je zmena, ktera tu druhou app rozbije nebo ne. Doporucuju se strejdy googla zeptat na dll hell.

Jednotne API na linuxu je, desitky let, jmenuje se POSIX. Neni to jen API, je to norma. A neni jen na Linuxu ;) To ze na nej nektery jedinci (zdravim Lennarta) se*ou, neni problem POSIXu ale jejich. POSIX je tak dulezity industry standard, ze ho neimplementuji jen Linux nebo obecne Unixy, ale i dalsi OS, napr. QNX se primo pysni tim, ze je POSIX compliant (uprimne si myslim, ze POSIX bude relevantni prumyslovy standard i v dobe, kdyz Lennarta a jeho crew prestane Linux bavit a zacne si hrat na nejakym jinym pisecku). Stejne tak neni problem "Linuxoveho API" to, ze vyvojari nekterych tookitu pro tvorbu GUI (napoveda: toolkit na 3 od G.) maji pojmy jako "backward compatibility" tezce na haku, takze jejich recentni tvorba se da shrnout do reklamniho sloganu "GTK3 - breaking API since 2010" a pak se jeste divi, proc vyvojari aplikaci radsi z GTK2 migrujou na QT nez na GTK3.

I kdyz mam hlubokou uctu k vyvojarum linuxovych GUI - ano i k lidem kolem GNOME - desktopovy linux nebyl, neni a nikdy nebude relevantni mimo uzkou skupinu uzivatelu- fandu (osobne to povazuju za klad). Prachy se toci nekde jinde. Nebyl relevantni a neni; to ze nebude dovozuju z toho, ze behem nekolika malo let nebude relevantni ZADNY desktop. Vyvoj je neuprosny a vede od klavesnice s mysi k tapani upatlanyma prstama do diplayi.

Lennartuv brainfart neresi ABSOLUTNE NIC co by uz nebylo vyresene davno at uz a) statickymi buildy b) aplikacemi distribuovanymi ve forme pripojitelnych loop devices (Chakra a jeji bundles) c) striktnim dodrzovanim zpetne kompatibily ASPON v ramci major verzi knihoven. Jak se to rika Linus? WE NEVER BREAK USERSPACE. NEVER!

To co on navrhuje vede k dll hell implementovanemu na urovni FS. Jaky pokrok!

[pavlix]

uprimne si myslim, ze POSIX bude relevantni prumyslovy standard i v dobe, kdyz Lennarta a jeho crew prestane Linux bavit a zacne si hrat na nejakym jinym pisecku

Tak to doufám, že se do té doby POSIX posune o krok dál, teď jsem třeba narazil na stack overflow na dotazy na thread safety běžných funkcí a zjistil jsem, že to snad POSIX ani nedefinuje. Taky nemám moc rád vícevláknové procesy, kvůli ladění a tak, ale POSIX by přecijen měl být standardem i pro ty, kteří mají.

Vyvoj je neuprosny a vede od klavesnice s mysi k tapani upatlanyma prstama do diplayi.

Jen by mě zajímalo, kdy se oddělí samostatný trh pro nerdy.

Lennartuv brainfart neresi ABSOLUTNE NIC co by uz nebylo vyresene davno

S tím bych tak nějak souhlasil, ale budu rád, když [někdo] vyřeší aspoň to, aby tyhle věci s upsreamovým systemd fungovaly.

[rADOn]

Tak to doufám, že se do té doby POSIX posune o krok dál, teď jsem třeba narazil na stack overflow na dotazy na thread safety běžných funkcí a zjistil jsem, že to snad POSIX ani nedefinuje.

POSIX.1-2001 and POSIX.1-2008 require that all functions specified 
in the standard shall be thread-safe, except for the following functions: 

asctime()
basename()
catgets()
crypt()
ctermid() if passed a non-NULL argument
ctime()
dbm_clearerr()
dbm_close()
dbm_delete()
dbm_error()
dbm_fetch()
dbm_firstkey()
dbm_nextkey()
dbm_open()
dbm_store()
dirname()
dlerror()
drand48()
ecvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
encrypt()
endgrent()
endpwent()
endutxent()
fcvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
ftw()
gcvt() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
getc_unlocked()
getchar_unlocked()
getdate()
getenv()
getgrent()
getgrgid()
getgrnam()
gethostbyaddr() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
gethostbyname() [POSIX.1-2001 only (function removed in POSIX.1-2008)]
gethostent()
getlogin()
getnetbyaddr()
getnetbyname()
getnetent()
getopt()
getprotobyname()
getprotobynumber()
getprotoent()
getpwent()
getpwnam()
getpwuid()
getservbyname()
getservbyport()
getservent()
getutxent()
getutxid()
getutxline()
gmtime()
hcreate()
hdestroy()
hsearch()
inet_ntoa()
l64a()
lgamma()
lgammaf()
lgammal()
localeconv()
localtime()
lrand48()
mrand48()
nftw()
nl_langinfo()
ptsname()
putc_unlocked()
putchar_unlocked()
putenv()
pututxline()
rand()
readdir()
setenv()
setgrent()
setkey()
setpwent()
setutxent()
strerror()
strsignal() [Added in POSIX.1-2008]
strtok()
system() [Added in POSIX.1-2008]
tmpnam() if passed a non-NULL argument
ttyname()
unsetenv()
wcrtomb() if its final argument is NULL
wcsrtombs() if its final argument is NULL
wcstombs()
wctomb()

Pravda je ze najit prislusnou manstranku (pthreads (7)) by se mi bez googla asi nepovedlo.

[pavlix]

Stále nemůžu najít primární zdroj.

[martin]

http://pubs.opengroup.org/onlinepubs/7908799/xsh/threads.html ?

[pavlix]

Jo, to je primární zdroj pro to, že to tak má být, ale není to ani POSIX1-2001 and POSIX1-2008, což mě trochu zaráží, když se všude odkazují na tyto dva dokumenty.

[martin]

Ok, to co jsem posilal je SUS v2, 1997. POSIX 2003 vzniknul ISO certifikaci SUS v3, takze tam muzou byt rozdily.

Tady je, jak to je aktualne:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

SUS v4 aka. POSIX1-2008 aka. IEEE Std. 1003.1-2013 - revize z roku 2013 (opravy problemu nalezenych po publikaci POSIX1-2008).

Hope it helps :)

[pavlix]

Teď abych si to zabookmarkoval ;). Každopádně díky za vyčerpávající informace.

[rastos]

Bo widle nemaji verzovani dll

Dobrý deň, dovoľte aby som vám predstavil Side-by-Side Assemblies.

[kralyk z abclinuxu]

In the preceding example, both Comctl32.DLL version 6.0 and Comctl32.DLL version 5.0 are in the side-by-side assembly cache and available to applications.

Ano, a tato cache narůstá a narůstá, dokud nepohltí veškerý volný diskový prostor. Nové možnosti vyčištění sxs cache sice do jisté míry fungují, v dlouhodobém měřítku ale pouze oddalují nevyhnutelné.

[rADOn]

To nam predstavovat nemusis, zpusob jakym ta kravovina pozira pamet i disk je vpravde neprehlednutelny. Teda, vsechna cest ze se moftu povedlo to vubec nejak vyresit. Lec to ze se museli uchylit k takovymhle prasarnam jen dokumentuje ze dobre overzovany .socko je nejlepsi vynalez od krajenyho chleba, dekuju pekne.

[=^..^= AmigaPower®]

Seš asi píčus néééé? druhej Jílek, todle číst nebudu, FUJ!

[Matlák]

Lennart nám podle všeho dělá z GNU/Linuxu pěkný nový OSX. Od Applu ukradl launchd (pardon, systemd), a teď jim krade dmg app balíčky

[Václav "Darm" Novák]

Ta věc od Lennarta je ještě trochu sofistikovanější, dmg se IMO spíš podobá PBI z PCBSD nebo bundles z Chakra Linuxu.

[TM]

Vždy jsem bral spíš na lehkou váhu některé argumenty lidí kolem BSD proti Linuxu a věcí kolem něj.
Ve světle aktuálního dění se jim začínám omlouvat a pomalu ve svém okolí připravuju migraci k BSD systémům(tam, kde to bude alespoň relativně bezbolestně možné). Je to pravda, BSD je opravdový Unix, z Linuxu(userspace) se stává jakási beztvará konzumní sračka.... K čemu...o takovou podobnou už přece léta zakopáváme na každém kroku.
Bohužel se ukázalo, že komunita kolem distribucí je velmi slabá a zranitelná - stačí jeden dostatečně drzý, plodný a výřečný magor s mesiášským komplexem a pár přicmrndy kolem a dokáží přes jednu firmu zasvinit, ne-li zničit, skoro vše v userspace

Pokud se časem neobjeví distribuce, která se tomu bude bránit(mimo jiné třeba nastubováním systemd, aby měly infikované aplikace pocit, že magor trůní v systému), bude to konec Linusova snu o vlastním svobodném Unixu...

Hrdě se hlásím k tomu, že jsem hater... Mimochodem, zabývám se tak trochu Minixem3. Začíná už být trochu reálně použitelný, přičemž přebírá dost věcí kolem ze světa BSD a Linuxu si téměř nevšímá... Konečně chápu proč.

[pavlix]

Pokud se časem neobjeví distribuce, která se tomu bude bránit(mimo jiné třeba nastubováním systemd, aby měly infikované aplikace pocit, že magor trůní v systému), bude to konec Linusova snu o vlastním svobodném Unixu...

Tedy další čekatel na spásu, ale budiž ti k dobru to, že si alespoň hledáš alternativu. Moc by mě potěšilo, kdyby až ten přechod na BSD dokončíš a necháš své okolí si trochu zvyknout, napíšeš blogpost o tom, jak to probíhalo a dopadlo.

Začíná už být trochu reálně použitelný, přičemž přebírá dost věcí kolem ze světa BSD a Linuxu si téměř nevšímá... Konečně chápu proč.

Že by kvůli licencím?

[lm]

Proc si sam nezkusis treba aktualni FreeBSD-stable ? Kdyz mas tolik casu zabijet ho tlachanim na forech. Mozna budes prekvapeny, ale z pohledu uzivatele je to system nerozeznatelny od Linuxu. Kupodivu userspace upstream vetsinou podporuje jak Linux tak svobodne *BSD.
Pro adminy a dodavatele systemu je stabilni API a jednoduchy unix-like zaklad naopak hotovym pozehnanim. Chapu ze pro nekoho to je cerna skrinka a neoceni to. Pro nas ktere to zivi jde ale o kritickou vlastnost.

[pavlix]

Proč mi raději nenapíšeš, co jsi na mém komentáři nepochopil?

[lm]

Proc mluvis hned o nepochopeni ? To je nejaka zautomatizovana obrana ? Cituji:

Moc by mě potěšilo, kdyby až ten přechod na BSD dokončíš a necháš své okolí si trochu zvyknout, napíšeš blogpost o tom, jak to probíhalo a dopadlo.

Podle vyse uvedeneho zadas jineho o sdeleni zkusenosti s prechodem na BSD, nepises nic o vlastni.

[pavlix]

Správně cituješ.

Dotyčný sdělil, že ve svém okolí připravuje migraci k BSD systémům, tedy předpokládám, že se chystá migrovat větší množství systémů používaných větším množstvím lidí. S člověkem, který něco takového provede bych se skutečně rád ze zvědavosti pobavil o pozitivech i negativech a vůbec o tom, jak to celé proběhlo a co si o tom zpětně myslí.

V tomto kontextu mi přijde nanejvýš zábavné, když někdo přijde do diskuze, z nějakého důvodu usoudí, že chci zkusit BSD, a na základě toho mi poradí... zkusit BSD. Dobře, zkusit FreeBSD stable, ať nejsem nespravedlivý.

Pro nas ktere to zivi jde ale o kritickou vlastnost.

Tak tě živí provoz BSD systémů. Mně zase momentálně živí vývoj těch linuxových a bude mě podle všeho živit minimálně dokud neopustím současnou práci, ale nikdo si z toho na prdel nesedne, že.

nepises nic o vlastni.

Napsal bych, pokud by to někoho zajímalo natolik, aby se zeptal.

[já]

Je pěkný jak i víceméně úplně content-free blog dokáže přilákat tolik komentů, stačí zmínit systemd (druhou nejlepší věc po krájeném chlebu).

[Václav "Darm" Novák]

Používám systemd a chleba nejradéji trhám. Tak nevím :D

[pavlix]

+1

Na LinuxDays budu mít nějakou přednášku a taky myslím, že mi přilepení systemd na konec názvu přinese větší část posluchačů.

[já]

No, to je určitě skvělej způsob jak zajistit, aby žádné dotazy nebyly zajímavé a k věci.

[pavlix]

Na dotazy nezbyde čas, trollové se budou zase muset vyřádit jinak.

[Já]

Když je blbá přednáškovka, kde je slyšet i od publika, tak může bejt problém dotazům zabránit.

[pavlix]

V tom případě alespoň udělám dobrý skutek. Pokud přitáhnu debily do jedné přednáškovky, tak bude všude jinde klid ;).

[xkucf03]

Ještě bys mohl přidat nějakou vtipnou příhodu: třeba že jsi cestou do kostela autem přejel cyklistu bez odrazek, protože jsi zrovna na palubním počítači sledoval, jak bootuje Systemd. Sice to není horší než Hitler nebo Abigail, ale diskuse by mohla být výživná.

[martin]

#joke: Jeste lepsi bude dat systemd na zacatek nazvu. Nebo na zacatek i na konec. Anebo: co zakomponovat i Lennarovo jmeno? Sal bude praskat ve svech a naval zajemcu (vcetne tech s platy vajec v rukou) budou muset krotit narychlo privolani bouchaci z nedaleke posilovny ;)

[pavlix]

Jeste lepsi bude dat systemd na zacatek nazvu.

To dělám zas na ábíčku, ale jenom u postů, kde je systemd primárním terčem. Ale je fakt, že to funguje ;).

[lm]

Slovo je mocne. Staci byt i nesmyslne oznacit nalepkou hater, luddita, terorista, zly, hodny a vetsina osliku souhlasne zahyka a newspeak se stane soucasti zivota. Staci jen akceptovat cizi vuli bez zapojeni vlastniho rozumu.

Tohle je jen zabo-mysi valka, bohuzel stejny princip funguje i u tech realnych. Kvuli hlouposti se budou chyby i nadale opakovat. Demokracie je diktatura hrstky vychytralych prostrednictvim manipulace tupou vetsinou. Presto zustavam i nadale optimistou.

[vons]

má řeč! +1