Evo OS, to poslední co by jste mohli chtít

17.3.2014 23:01 | Přečteno: 2290× | Linux | poslední úprava: 20.3.2014 03:30

Titulek zní tak trochu dvojznačně. Na to jsem přišel hned jak jsem ho dopsal a do určité míry to tak je. Zkusím shrnout podstatu, proč jsem se rozhodl k vyvoření distribuce, která by mi seděla víc než Gentoo. Už od roku 2007 jsem uživatelem Gentoo. Je to distribuce, která mi nesmírně vyhovovala a do jisté míry stále vyhovuje. Můžu si s ní dělat téměř cokoliv a přitom se z toho nezbláznit (ruční instalace SW je zlo, člověk potom někde zapomene knihovnu a diví se proč mu téměř nic nefunguje).

Poslední dobou jsem však nabyl subjektivní pocit, že v Gentoo je několik věcí, které mi nevyhovují

• velké množství neopravených bugů, některé se týkají i většího množství lidí a nemožnost si je jednodušše opravit sám
• nedostatek vývojářů (přímací proces je daleko od optima i dle vývojářů Gentoo, viz. Gentoo Quiz atd.)
• plno softwaru vyvijeného mimo hlavní strom, případně visícího v bugzille
• v hodně případech postoj "nesahat, může se to rozbít"
• když něco způsobuje problémy, místo opravy přijde downgrade a zamaskování
• v některých oblastech konzervativnější než Debian...

Nějaký čas jsem uvažoval nad tím stát se vývojářem a pokusit se věci měnit, ale postupem času mě to přešlo. Přesto si velice vážím práce některých vývojářů na Gentoo a jejich nadšení.

Také jsem se poohlížel nad Arch Linuxem, protože jejich ideologie, user-friendly & developer-friendly se mi vážně líbí, ale je tu pořád několik věcí, které mi Gentoo vyhovují - USE flags - a v Archu by to znamenalo ruční úpravu velkého množství souborů, abych si mohl hrát.

Teď bych rád řekl něco o své myšlence Evo-OS.

• aktuální software (po vzoru Archu, pro každý SW pouze nejnovější ebuild, případně pro každý slot jeden nejnovější)
• přehledné stránky, zase po stylu Archu
• portage v gitu (hotovo), možná jednoduchá spolupráce, pull requesty
UPDATE: exherbo repozitář v gitu
• žádné downgrady, pokud se něco s novou verzí rozbije, tak se to opraví
• komunikace s vývojáři Gentoo (některé změny a ebuildy půjdou zpět)
• snaha zaměřit se více na podporu musl-libc (náhrada glibc), systemd, wayland a QT 5 + KDE KF5, případně Enlightenment
• QA, komunikace s upstreamem - každý patch z Evo OS by měl mít číslo bugu či mailing list upstreamu
• setkání v ČR, meeting, hackfesty :)

Jsem prostě člověk, kterému vyhovuje mít systém postavený na cutting-edge i za cenu, že si budu muset pořešit pár bugů. Snad nejsem sám, kdo si rád "užívá" (možno brát dvojznačně) novinek a s ochotou přispěje do upstreamu nějakým patchem či bugreportem :)

Proč to píšu? Pokud se Vám tahle myšlenka líbí, můžete ho začít využívat. Projekt je zatím v plenkách, ale rád bych kolem něj vytvořil alespoň drobnou komunitu. Věřím, že některé body budou pro mnohé společné. Rozhodně je tu mnoho dalších nápadů na vylepšení atd. V blízké době zkusím připravit web, wiki a bugtracker po vzoru Archu. Další bod určitě livecd s co nejvíc zjednodušenou instalací + možnost automatizace.

Rád bych slyšel názory, třeba i něco takového již existuje a já to nevidím. Jsem otevřen návrhům, nápadům i kritice. Pokud si budete chtít pokecat online, jsem kromě jiných IRC i na #evo

taky jsem postavil malou stránku s shrnutím vlastností        

Komentáře

[Dirka]

A jakym zpusobem chces v par lidech mit aktualni verze? Nahodne sem zavital do net-news a vidim tam stejny obstarozni ebuildy jako v mainline. Predpokladam, ze ses te oblasti nedotkl, ale i tak ...

Pujde to rozjet nad existujici gentoo instalaci, teda pridam si te do overlay napr?

Celkova myslenka fajn, a bugzilla me vylozene sere a demotivuje neco logovat, kdyz se bavis s devama na irc, tak te poslou do bugzilly a pak na to rok (a to doslova) ani nesahnou :/ ... rozho by nebylo spatny mit pruznejsi gentoo, snad jednou v pristim zivote :)

Budu dal sledovat, ale mam pocit, ze sem podobnych pokusu uz par videl.

[David Heidelberg]

aktualizace zatím fungují jistým git pull --rebase způsobem :)

Zatím jsem tam nahrál jen věci z mé overlaye (ixit overlay), qt a kde overlaye. O všem SW nevím, všechen SW nepotřebuju.... ALE když mi dáš patch, budeš tam mít co potřebuješ :)

jinak je to celá portage, takže stačí si jí nahradit tu Gentíí /etc/portage/repos.conf/gentoo [DEFAULT] main-repo = gentoo

[gentoo] location = /usr/portage sync-type = git sync-uri = https://github.com/evo-os/portage.git

[David Heidelberg]

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = git
sync-uri = https://github.com/evo-os/portage.git

ALE POZOR, nehrozí že se posere systém, ale neřeší se zpětná kompatibilita tolik, takže třeba až překompiluješ teď LLVM, tak to bude chtít updatnou věci co na tom visí :) prostě je to cutting-edge, je nutný s tím počítat :)

[pavlix]

To je prasárna. Měl bys mít ten hlavní strom nazvaný jinak, pokud to není skutečné Gentoo. Tímhle tu spolupráci moc nepodpoříš.

[David Heidelberg]

je to prasárna, udělá se to líp. Je to prostě začátek.

[Josef Kufner]

Tohle mne už dávno přešlo. Systém má prostě fungovat, abych se mohl věnovat spoustě daleko zajímavějších věcí. A když se tomu mému hybridu Debianu unstable a experimantal něco rozbije, tak prostě jen downgraduju nějaký ten balík a chvilku počkám.

[David Heidelberg]

Jasně, ty už to dostaneš víceméně odladěné, právě díky těm lidem, co to otestují před Tebou, vytvoří bugreporty a případně napíšou patche :)

Někdy mě přepadne taky taková nálada, že bych byl rád jen uživatelem, ale za pár hodin si řeknu "fuck it, jdu si nainstalovat něco strašně novýho a právě ve vývoji" :D

[Josef Kufner]

Přesně tak. A jsem velmi rád, že se najde dostatek bláznů, kteří chtějí tu špinavou práci udělat.

[Grunt]

Tohle já mám vyřešené velice snadno: Experimentální systémy mám na USB fleškách (až na to Gentoo, ale zrovna jsem na něj dostal chuť a je fakt že mi nic nebrání koupit si další a prostě si ho na ni nainstalovat) a upgraduju vždycky balíčky u kterých chci nejnovější verze. Jen kdyby to nebylo tak zatraceně pomalé.

[Grunt]

Jinak u Gentoo by bylo parádní kdyby ebuildy, které si kdo nainstaluje a tím zkompiluje zase vracel zpět a vznikaly tak binární buildy pro různé kombinace e-flagů, architektury, atd. Akorát u toho asi hrozí nebezpečí infiltrace kódu, že?

[pavlix]

Právě. Musel bys mít u těch balíčků reproducable builds a musel bys dát nějaká pravidla, kolik lidí jakého ranku je potřeba, aby se build stal oficiálním nebo tak něco ve stylu gpg a následně to vše sdílet nějakým bittorrentem, protože nebudeš mít dostatek místa na oficiálních strojích.

[David Heidelberg]

Tahle myšlenka je zajímavá :) Pokud by se vyfiltroval seznam buildů na ověřené testery :)

[pavlix]

Tak ty bys mohl mít hash store, kde by ověření i neověření testeři automaticky sdíleli hash výsledných buildů a na základě toho bys mohl i rozlišit reproducable a non-reproducable ebuildy. Jenže těch možných kombinací různých nastavení především kompilátoru je tolik, že by i tak bylo vhodné se omezit na některé vybrané konfigurace.

[Grunt]

ověřené testery

Tak tento fork Gentoo se jmenuje Fedora Rawhide. Důvod proč RedHat ale ani třeba RPM Fusion (a předpokládám, že ani jakákoliv jiná distribuce) nechtějí do své buildovací infrastruktury nic cizího je, že by pak mohl kdokoliv snadno infiltrovat do oficiálních balíků nějaký zákeřný kód a v podstatě by se šířil jako oficiální podepsaný balíček. Jediný způsob jak se tomu vyhnout a co mě napadá je znát hash binárního výsledku ještě před tím než se zkompiluje ze zdrojáků. Good luck with that one.

[Josef Kufner]

Reprodukovatelné buildy by pomohly, ale v podstatě by stačilo, aby každý svůj build podepsal a svůj veřejný klíč zaregistroval na serveru, spolu s podepsanou fotkou (osobně zkontrolovanou) nějakého svého dokladu (občanka, pas). Takže pokud někdo něco provede, víš, kdo to byl a můžeš ho zabanovat a hnát k zodpovědnosti.

Pokud by buildy byly reprodukovatelné, umožní to nasazení torrentů a ověřování, že buildy jsou v pořádku. Na serveru by pak byly jen podepsané hashe a torrent soubory, případně i jedna kopie balíčku (server by byl jedním seedem).

[pavlix]

Reprodukovatelné buildy by pomohly, ale v podstatě by stačilo, aby každý svůj build podepsal a svůj veřejný klíč zaregistroval na serveru

Nereprodukované buildy jsou náchylné na různé chyby, odchylky a nedostatky. Možnost úmyslné manipulace je jen špička ledovce. Proto si myslím, že jsou reprodukovatelné buildy jediným možným řešením a v kombinaci s dalšími protokoly na základě hashů i docela elegantním řešením.

[xxxxxxxxxxx]

Pojd radši programit CAD.

[gsnak]

Akurat dnes som o tom tvojom kade premyslal v sprche. No vazne. Premyslal som nad tym, ze sucasne CADy maju dost zlozite featury ako nurbs a podobne, ale ked za 20-30 rokov dojde ropa a jediny kto bude na dvorku nieco kutit bude farmar co si sklada traktor na bionaftu. Ten urcite nebude potrebovat nurbs a spol, jemu by podla mna bohate stacil CAD ktory by pracoval len so standardizovanymi profilmi (I profil, U profil, L profil, rozne tyce, skrutky, atd...) a k dispozicii bude mat karbošku a zváračku. Mozno sustruh a flexu ale myslim ze to gro by boli tie profily a skladanie z nich, asi ako lego. Zda sa mi ze by to mohlo byt jednoduchsie spravit ako fully-fledged cad.

[xxxxxxxxxxx]

No je pravda že nurbs plochy vlastně pokud nejsi Automobilka vubec nevyužiješ. Stačilo by sčítat/odečítat více méně primitivní objekty. Já si zase pohrává ms myšlenkou tak nějak sepsat a vyvinout systém tvorby výkresové dokumentace pomocí fotek. Protože když vidím jak dokumentují stroje třebas bastliči 3D tiskáren tak se mě chce blejt... Samo kdyby se chtěl někdo váždě 3D cadu věnovat rád bych poradil co a jak...

[the.max]

Jak vidím systemd, vždy mě přepadne střevní chřipka.

[standa]

Mne zase přepadne sračka.

[pavlix]

Inu, nezbývá než popřát hodně štěstí.

[Marián Kyral]

Vypadá to zajímavě, ale momentálně nemám čas si s tím hrát.

Taky mně štve, že některé balíky, které používám, hnijí v bugzille. Naštěstí jich není moc, takže se to dá přežít.

[David Heidelberg]

pokud bys při nějaké úrovni použitelnosti měl zájem to používat, přijď aspoň na #irc, ať je vidět nějaký zájem :)

a taky víc hlav víc ví

[Marián Kyral]

Líbí se mi portage v gitu, ale momentálně většinu času věnuji OSM a snaze odladit dva java pluginy pro JOSM, abych je mohl dostat do repository.

[jadd]

přehledné stránky, zase po stylu Archu

Zmiňuješ Gentoo a Arch, proto mi přijde divný tento názor. Arch měl přehlednější wiki dříve ale po vytvoření nové Gentoo wiki, bych řekl opak. Pokud jsi měl na mysli tento typ stránek¿

Zrovna jsem se díval na Gnome v Arch wiki, začínají co dělat při zámrznutí, ocenuji, že problematiku neskrývají ale neumím si představit, že by dokumentace pro Windows™ začínala co dělat při modré obrazovce .. jen mi to přišlo úsměvné.

[pedro]

Ehe, a já si myslel, že bleeding edge distribucí, kde je pořád něco rozbité, máme již dost. Ne, bez prdele, opravdu si myslím, že spíše se nedaří na tom poli stabilizace a QA. Gentoo je v tomto docela cenné, i když tedy většina uživatelů to asi neocení (příliš složité). Čistě prakticky, fakt si myslíš, že pokud se najde v nějakém kódu, který ani neznáš, který používá knihovny, které ani neznáš, nějaká chyba, že je to někdo s výjimkou (někdy) autorů programu schopný opravit?

[pavlix]

Okiáš si věří, okiáš je génius, to jen všichni ostatní to dělají blbě ;).

[FrostyX]

+1 a potom díky

žádné downgrady, pokud se něco s novou verzí rozbije, tak se to opraví

budou mít všichni rozesraný systém, dokud se to autor programu neodhodlá vyřešit.

[David Heidelberg]

takže když se vydá nový kernel s nějakým bugem, tak mají všichni rozesraný systém?

ano, někteří ano, downgradnou "a čekají až to někdo opraví za ně" Jiní ovšem nahlásí bug, vezmou git bisect a za půl hoďky mají commit (s automatizací u toho ani třeba nemusí sedět), který to způsobuje, ten odešlou upstreamu.

Workaround bývá revertnutí patche, to není žádný downgrade. A později se začlení patch s opravou.

Co je na tom konkrétně složitého?

[jadd]

neznalost možností? mám 3 knihy o Linuxu ale takové věci tam nejsou. Můžeš říct kde ses o tom dověděl ty? škola, internet, přítel, střepiny (novatv), online(ct)

[David Heidelberg]

o tělocviku za základce

[pavlix]

Kup si jednu knihu o Gitu ;).

[jadd]

Dal jsem na tebe. Kdy jí ale dočtu je ve hvězdách.

[pavlix]

Doufám, že aspoň v originále, protože česká verze se mi doma válí.

[jadd]

Spousty informací také poskytuje pořad Vědmy radí, na ten jsem zapoměl.

[Josef Kufner]

To ovšem znamená, že jejich počítač je tak den až dva nepoužitelný.

[pavlix]

V případě kernelu je zvykem, že distribuce umožňuje triviální downgrade například jen výběrem staršího kernelu v GRUBu bez potřeby downgrade balíku jako takového. Takže bych se spíše zaměřil na ty obecné balíky.

Okiáš nadhodil, že bude jen jedna verze pro balík (a slot) a že se nikdy nebude downgradovat v případě problému. Takhle svým způsobem funguje naprostá většina binárních distribucí, ale to především proto, že si nemůžu dovolit udržovat více balíků a že downgrade je potenciálně nebezpečný. Jenže vymazání starších verzí ve skutečnosti neřeší vůbec nic.

Potom Okiáš tvrdí, že bude mít nová distribuce lepší QA, ale nepřednesl žádnou zřetelnou QA koncepci. Největším úskalím QA nekomerčních projektů je kritický nedostatek lidí. Okiáš sám používal na desktopy Gentoo testing, čímž se ve výsledku vyřadil z nejdůležitějšího QA procesu na Gentoo, kterým je dle mého laického názoru testování jednotlivých testing balíků a zakládání stabilizačních bugů.

O preferenci Gentoo testing jsem slyšel od více uživatelů a ta myšlenka mi přijde značně zcestná. Narozdíl od binárních distribucí lze na Gentoo vcelku pohodlně provozovat takřka libovolné testing balíky a ověřit tak, zda má smysl je začlenit do stable. Z binárních distribucí takto funguje Fedora, kde se ovšem nekompatibilní upgrade nechává na aktuální rawhide větev.

[Josef Kufner]

Ono je úplně jedno jestli se rozsype jádro, window manager nebo nějaká důležitá knihovna, kterou zrovna potřebuje můj pracovní nástroj. Downgrade sice může být nebezpečný, ale často je to to nejlepší, co lze udělat.

Datové formáty bývají zpětně i dopředně kompatibilní. Pokud zrovna nejsou a nová verze migrovala stará data na nový formát, tak by stará verze měla zakřičet, že tam má nějaké blbosti a padnout, takže ke škodě nedojde a stačí upgrade zpět na porouchanou novou verzi. Tedy není to horší než když downgrade není k dispozici. U programů, které to neřeší to obvykle odnese jen kus nějakého nepodstatného nastavení, které lze snadno napravit (a proto to neřeší). Databáze, kde na tom záleží, to zas řeší důkladně.

[Marián Kyral]

O preferenci Gentoo testing jsem slyšel od více uživatelů a ta myšlenka mi přijde značně zcestná. Narozdíl od binárních distribucí lze na Gentoo vcelku pohodlně provozovat takřka libovolné testing balíky a ověřit tak, zda má smysl je začlenit do stable. Z binárních distribucí takto funguje Fedora, kde se ovšem nekompatibilní upgrade nechává na aktuální rawhide větev.

Tohle je problém slepice a vejce. Dokud bude stabilní větev daleko vzadu za mainstramem, budou uživatelé používat testing. A dokud budou uživatelé používat testing, nebude je trápit, že stable větev je zoufale neaktuální.

Když jsem před pár lety dostal nový služební NB, byl jsem rozhodnut dát na něj stable. Vydrželo mi to necelý den. Starý gimp (1.x), staré KDE... Bylo toho tolik, že mi přišlo jednodušší nahodit testing, než neustále řešit, co je třeba odmaskovat a mít stejně většinu systému testing. Možná se od té doby situace změnila, ale nemám důvod ani čas zkoušet znova stable a řešit problémy s tím spojené. Za celou dobu se jen jednou stalo, že po updatu systém nenabootoval - chyba v glibc rozbila init.

Stable určitě na server, desktop konzervativního uživatele, ale pro uživatele preferujícího aktuální verze a nové funkce je lákavější testing. V každém SW je minimálně jeden bug. Může se stát, že na něj nenarazím. Pak mi nevadí. Nebo narazím, ale na internetu najdu patch, který jednoduše aplikuji (moc díky vývojářům za /etc/portage/patch/). A pokud patch není, nebo to není jen tak, tak můžu vždy nahrát starší a funkční verzi.

[pavlix]

Tohle je problém slepice a vejce.

Jen teoreticky.

Dokud bude stabilní větev daleko vzadu za mainstramem, budou uživatelé používat testing.

Mně osobně Gentoo stable nepřijde nijak děsivé. Jistě, používám pár věcí z testing, používám pár vlastních ebuildů, ale nemyslím si, že by stable větev byla nepoužitelná.

Starý gimp (1.x)

Jednotlivý software neřeším.

staré KDE...

Osobně nepoužívám, ale pokud někdo chce tvrdit, že dokáže zlepšit QA, tak měl alespoň uvážit pokus o stabilizaci.

Bylo toho tolik, že mi přišlo jednodušší nahodit testing,

Jednodušší ano, ale trochu bych se bál právě ztráty toho QA, kdy testing může chvílema vypadat dost děsivě. Osobně mi přišlo, že mu i věnuju víc času při řešení různých konfliktů a rozbitých programů.

Za celou dobu se jen jednou stalo, že po updatu systém nenabootoval - chyba v glibc rozbila init.

I kdybych se vyhnul jen téhle jedné situaci, stojí mi stable za to ;). Chci mít rozbitý systém jen ve výjimečných chvílích, kdy vědomě experimentuju. Jako když jsem zkoušel nabootovat se systemd. To se navíc naštěstí opravilo restartem do normálního prostředí.

Stable určitě na server, desktop konzervativního uživatele

Zjevně jsem kombinací konzervativního uživatele a nevyléčitelného experimentátora :D.

ale pro uživatele preferujícího aktuální verze a nové funkce je lákavější testing.

Tomu jsem nikdy nerozuměl. Chci stabilitu u toho software, kterému moc nerozumím a se kterým nechci řešit problémy. Chci nové funkce u toho software, kde vím o konkrétních nových funkcí, které se mi hodí. Chci mít možnost rychle nainstalovat aktuální verzi na vyzkoušení a rychle se vrátit o osvědčené verzi v případě problémů.

na internetu najdu patch, který jednoduše aplikuji (moc díky vývojářům za /etc/portage/patch/).

Po pravdě /etc/portage/patch sice používám denně, ale kupodivu i na stable je většina takto aplikovaných patchů mých vlastních.

A pokud patch není, nebo to není jen tak, tak můžu vždy nahrát starší a funkční verzi.

Problém je v tom, že nahrát starší verzi něčeho, co je závislostí pro mnoho jiných balíků, není vůbec jednoduché. Proto preferuju funkční základ systému a experimentovat opravdu jenom v míře, kterou si sám zvolím.

[pedro]

+1 používám Gentoo stabilní větev úplně stejným způsobem a v tomto je Gentoo naprosto nenahraditelná distribuce.

[pavlix]

Mimochodem, co takhle nějaký Gentoo sraz, Okiáš něco chystá.

[Marián Kyral]

Mimochodem, co takhle nějaký Gentoo sraz, Okiáš něco chystá.

Nejsem proti, ale nic neslibuji

[Marián Kyral]

Dokud bude stabilní větev daleko vzadu za mainstramem, budou uživatelé používat testing.

Mně osobně Gentoo stable nepřijde nijak děsivé. Jistě, používám pár věcí z testing, používám pár vlastních ebuildů, ale nemyslím si, že by stable větev byla nepoužitelná.

Jak jsem už psal, je to pár let. Mezitím se mohla situace změnit. V té době se sw vyvíjel raketovou rychlostí a třeba KDE 4 se v té době snažilo napravit pošramocenou pověst a neustále doplňovalo chybějící funkce. Dnes se vývoj zpomalil, většina sw se dostala do stádia, že všechny hlavní funkce jsou implementovány a vývoj teď probíhá formou postupné evoluce.

Starý gimp (1.x)

Jednotlivý software neřeším.

No právě. Ale o tom to celé je. Chci gimp 2. Ten chce knihovnu X ve verzi Y. A ta zase závisí na knihovně W ve verzi Z. A pokud ta knihovna není ve slotu, tak musím aktualizovat balíčky I, J, K - ty potřebují zase knihovnu G... A tak dále.

Dnes už to možná bude jiné. Portage udělala velký skok dopředu, má možnosti co dříve nebyly, knihovny se více slotují. Třeba už to není takové harakiri.

staré KDE...

Osobně nepoužívám, ale pokud někdo chce tvrdit, že dokáže zlepšit QA, tak měl alespoň uvážit pokus o stabilizaci.

KDE je velký balík se spoustou modulů, ve kterých se může objevit spousta chyb. Než se všechny podaří vyřešit, tak to nějakou dobu trvá a mezitím vyjdou další dvě verze KDE, které spoustu chyb opraví a jiné zase přidají. No a jsi na začátku.

Bylo toho tolik, že mi přišlo jednodušší nahodit testing,

Jednodušší ano, ale trochu bych se bál právě ztráty toho QA, kdy testing může chvílema vypadat dost děsivě. Osobně mi přišlo, že mu i věnuju víc času při řešení různých konfliktů a rozbitých programů.

Za celou dobu se jen jednou stalo, že po updatu systém nenabootoval - chyba v glibc rozbila init.

I kdybych se vyhnul jen téhle jedné situaci, stojí mi stable za to ;). Chci mít rozbitý systém jen ve výjimečných chvílích, kdy vědomě experimentuju. Jako když jsem zkoušel nabootovat se systemd. To se navíc naštěstí opravilo restartem do normálního prostředí.

Na experimenty nemám moc čas. Zatím jsem třeba ještě stále na starém grubu. Funguje, tak proč ho měnit Ale jádro 3.13.6. Věřím Linusovi ale i tak na novou řadu jádra přecházím až po nějaké době, kdy první odvážlivci vyzkouší, že tam není žádný kritický bug.

Update spouším tak jednou za dva týdny až měsíc, když vím, že v případě problémů budu mít čas se tím zabývat. Ale nepřijde mi, že by mi to žralo nějak extrémně moc času. Většinou spustím update přes noc a ráno vše normálně funguje

ale pro uživatele preferujícího aktuální verze a nové funkce je lákavější testing.

Tomu jsem nikdy nerozuměl. Chci stabilitu u toho software, kterému moc nerozumím a se kterým nechci řešit problémy. Chci nové funkce u toho software, kde vím o konkrétních nových funkcí, které se mi hodí. Chci mít možnost rychle nainstalovat aktuální verzi na vyzkoušení a rychle se vrátit o osvědčené verzi v případě problémů.

Ale já ty aktuální verze nechci jen zkoušet. Já je chci aktivně používat Ono to není až tak horké. Většinou se stejně nová verze trochu zdrží u maintainera, případně nějakou dobu trvá, než se dostanu k aktualizaci, takže mám celkem slušnou šanci, že se případné chyby najdou dříve, než stihnu aktualizovat. A když ne, tak se třeba něco přiučím

na internetu najdu patch, který jednoduše aplikuji (moc díky vývojářům za /etc/portage/patch/).

Po pravdě /etc/portage/patch sice používám denně, ale kupodivu i na stable je většina takto aplikovaných patchů mých vlastních.

Nikde jsem nepsal, že to nejde používat na stable

A pokud patch není, nebo to není jen tak, tak můžu vždy nahrát starší a funkční verzi.

Problém je v tom, že nahrát starší verzi něčeho, co je závislostí pro mnoho jiných balíků, není vůbec jednoduché. Proto preferuju funkční základ systému a experimentovat opravdu jenom v míře, kterou si sám zvolím.

Opravdu jen málokdy musím downgradovat nějakou knihovnu a ani tak to není až tak hrozné. Jediné, co mne napadá je Xorg. Ale tam jsem stejně většinou nějakou dobu blokován starší verzí nvidia-drivers a čekám na aktualizaci, která umožní běh s novými Xorg.

Ve zkratce, každý přístup má svá pro a proti a záleží na každém konkrétním jedinci, který přístup si vybere. Ty mně nemusíš chápat, možná ti to připadá nelogické, ale tak to je a takto mi to vyhovuje. Ty to nezměníš.

Nicméně můžu ti slíbit, že až budu zase instalovat nový počítač, tak experiment se stable zopakuji. Mám jej v dohledné době v plánu. Zatím je sice manželka proti, ale pracuje se na tom

[pavlix]

Naštěstí nepoužívám žádný software, který by měl se stabilizací takové problémy jako KDE. Opustil jsem KDE někdy ke konci třetí řady, kdy pomalu ale jistě přestávaly aplikace fungovat dle mých dosavadních návyků. Pokud jde o závislosti GIMPu, tak bych docela rád viděl soupis toho, co brání zkompilovat GIMP ve stable a proč to nebylo vyřešeno.

GRUB2 používám už mnoho let a používal jsem ho pokud vím už na Fedoře 15 a Debianu 5 proto, že mi vadilo přizpůsobovat layout disků bootloaderu.

Nikde jsem nepsal, že to nejde používat na stable

Nikde jsem nepsal, že jsi to psal.

Ve zkratce, každý přístup má svá pro a proti a záleží na každém konkrétním jedinci, který přístup si vybere.

O tom snad není pochyb.

Ty mně nemusíš chápat, možná ti to připadá nelogické, ale tak to je a takto mi to vyhovuje.

Já tě chápu, své důvody jsi popsal velice srozumitelně. Nicméně se pořád mýlíš v interpretaci toho, co jsem zde psal a vztahuješ na sebe výtky, které se tě pravděpodobně vůbec netýkají.

Má výtka ohledně nepoužívání stable je namířená vúči těm, kteří si stěžují na QA a nebo tvrdí, že chtějí pro QA něco udělat. Pokud tě QA nezajímá, nemáš důvod se nad tím nijak rozčilovat. Naopak pokud tě QA zajímá, pak si úplně nemyslím, že by bylo možné ten zájem realizovat na testing větvi.

Nicméně můžu ti slíbit, že až budu zase instalovat nový počítač, tak experiment se stable zopakuji.

Jestli ho zopakuješ, mě samo o sobě moc netrápí. Ale pokud by kolem toho vznikl nějaký článek zahrnující konkrétní problémy a zkušenosti, tak budu rád. Pokud dosáhneš stabilizace nějakých klíčových komponent, tak tím líp.

[Marián Kyral]

Jestli ho zopakuješ, mě samo o sobě moc netrápí. Ale pokud by kolem toho vznikl nějaký článek zahrnující konkrétní problémy a zkušenosti, tak budu rád. Pokud dosáhneš stabilizace nějakých klíčových komponent, tak tím líp.

Pokusím se. Nejdřív musím vybrat vhodný noťas a pak přesvědčit manželku.

[pavlix]

Těžký to život máš. Btw, na ten sraz, co vypsal Okiáš na apríla se ti do Prahy asi nechce, že?

[Marián Kyral]

Což o to. V Praze pobývám celkem pravidelně vždy úterý-čtvrtek na služebce. Ale jednak mi JBoss nic neříkám a druhak, v tom odkazu vidím Brno

[pavlix]

Erm, o zprávičku vedle, toto jsem měl namysli.

[Marián Kyral]

No to už vypadá líp Dorazit bych teoreticky mohl, Jen to asi bude později. 17:30 většinou končím na Letňanech. Jinak souhlasím s Jendou. I když tu mapu vidím, je lepší napsat přesnou adresu. Takhle to vypadá, že setkání bude někde na ulici

[pavlix]

Já jsem jen obyčejný návštěvník. Mapu reklamovat u jiných :D.

[jadd]

Dokud bude stabilní větev daleko vzadu za mainstramem, budou uživatelé používat testing.

Mně osobně Gentoo stable nepřijde nijak děsivé. Jistě, používám pár věcí z testing, používám pár vlastních ebuildů, ale nemyslím si, že by stable větev byla nepoužitelná.

někdo je za takový stav rád, že je to v místech mezi CentOS Debian .G. Ubuntu Fedora. Jen Gnome, jim trvalo trochu déle, ale lépe později než aby se to sypalo.

[pavlix]

lépe později než aby se to sypalo.

To tak nějak shrnuje můj názor na věc, nejen ohledně Gnome. Nejsem proti tomu, aby stabilizace probíhala rychleji, pokud jsou lidi ochotní na tom pracovat. Na druhou stranu to vyžaduje i značnou spolupráci maintainerů, kteří by měli řešit odhalené chyby a tam se dá rovněž očekávat nedostatek dobrovolné pracovní síly.

[Spike]

To se mi líbí, určitě budu sledovat / zkusím.

Před časem jsem hledal, zda se někdo zabývá něčím jako tvorbou distribuce "bez historické zátěže" (i kdyby to měla být jenom hračka), ve které zprvu poběží dvě užitečné GUI aplikace.

[Spike]

Závorka měla končit asi až za "GUI aplikace".