Jsou distribuce to co chceme?

Ja bych spis ocenil, kdyby se vymyslel nejaky frontend k balickovacim systemum, aby se kazdy balicek delal a opravoval jen jednou a ne pro kazdou distribuci zvlast a take kdyby se do standartnich distribuci nejak zapatlalo emerge z gentoo, abych mohl kompilovat a pritom mit dany program ve sprave balickovaciho systemu.
Ted mam na vyber jen zastaraly balicek a nebo kompilaci, ale bez pokryti balickovacim systemem.
Na gentoo mi zase vadi, ze musim kompilovat vsechno.
Pral bych si neco mezi, ale oboji v ramci balickovaciho systemu.
Jednotnost balicku by zajistila, ze bych vedel, ze co funguje v jedne distribuci bude fungovat i v jine.
Dnesni stav je, ze vsude funguje neco a brano dohromady vlastne v linuxu funguje temer vsechno.
Ale v konkretni distribuci se vzdy najde neco co nefunguje a pritom u konkurence ano:/

Myslim si, ze kvalitna distribucia ma aj svoje backporty najnovsieho software do stabilnych verzii. Tu je si treba uvedomit obrovske mnozstvo prace, ktore je treba urobit, aby sa otestoval kazdy program ich sucinnost a podobne, takze nie je podla mna realne mozne mat rychly vyvojovy cyklus a stabilnu distribuciu, kde vsetko funguje.

to Petr F:V debiane su aj balicky so zdrojovymi kodmi, takze si mozete nainstalovat a skompilovat konkretny program. Podobne na tom mozno budu aj ostatne distra.

[2] nevim jak v jinych distribucich, ale v debianu to s tim kompilovanim neni problem - proste nepouziju apt-get install balicek, ale apt-get -b source balicek. jen hlavne ne emerge ;)

ten frontend se dost dobre udelat neda, protoze se v ruznych distribucich jmenuji ruzne balicky s libkama, ty distribuce si kde co jeste navic samy upravuji (viz napr. to jak se tu nekdo nedavno rozciloval kvuli tomu xorg.conf.failsafe v ubuntu), takze to automaticky proste dost dobre delat nejde.

[3] omlouvam se, melo tam byt [1]

heh:) pripomina mi to ten stary vtipek o slovnikovom hesle "rekurzia: vid heslo rekurzia"

TO Petr F: Já si nemohu pomoct ale to co ty žádáš od distribuce přesně splňuje PACMAN v Archu. Většina standartního software je v repozitáři už v zkompilované podobě a řekl bych dost aktuální věci (jako v gentoo) no a tech pár ostatních specialit je v AUR, při zvolení správného frontend (yaourt) není problém tak propojit binární repozitáře pacmana a komunitní AUR (kompilovaný). Druhá věc je že balíky v PACMAN neni problém i individuelně zkompilovat sám (pokud ti jde o nějaou optimalizaci), nebo si překompilovat celý systém (ale kdo by to dělal)

Jinak plně souhlasím že je velice pozitivní mít více možností v podobě distribucí a ne jeden balíkovací systém. Na druhou stranu bych byl pro založení nějakého "naddistribučního zdrojového repozitáře" kde by všechny distribuce dobrovolně zasílaly svoje opravy a tak se jednoduše dělili s ostatními a na oplátky by zaintegrovávali opravy do svých repozitářů podle potřeby.
Né že by to asi tak nefungovalo ale s nějakým centrálním repozitářem by to zcela jistě bylo lepší.
Ale mít jeden jednotný systém, NE NE NE, třeba by to byly balíky RPM který kdykoli vidim nějakou takovou distribuci tak se mi ježej vlasy, protože sem s tim měl zatim jen problémy, a třeba by to byl právě zmíněný PACMAN, no ale pak by se to třeba nelíbilo jiným.

No na druhou stranu (ad: změna rozsahu distribuce) by byla celkem zajímavá distribuce postavená na principu Windows (teď mě nebijte). Myslím to takto: distribuce s funkčním balíčkovacím systémem (můj názor: deb,pacman) která by byla postavená jen do základu, řekněme grafického prostředí ale dál nic. Zbytek at si uživatel nainstaluje sám, pomocí vhodného GUI, frontendu apod. Protože znám spousty uživatelů kterí dokáží celkem jednoduše ovládat instalace normálních programů apod, ale do systému by se nepustili. (například všichni powerusers přecházející z win). Výsledek je asi takový dát uživateli větší volnost ale nezatěžovat ho tím o čem většinou už nemá ponětí (binutils, coreutils k čemu to je? já chci operu nebo firefox).

[6] Taketo nieco tusim existuje v nejakom klone BSD. Nainstalujete holy system s GUI. Dalej uz len stahujete balicky, na ktore staci kliknut, next, next a mate nainstalovany program.

Co se mě týká, tak mě více vyhovuje pomalejší vydávání ... jsem zastánce toho, proč něco přeinstalovávat novější verzí, když to původní funguje dobře. Jako osobně nemám rád představu, že bych musel přeinstalovávat počítač každého půl roku nebo za rok.

[8] Potrebujete urcitu vlastnost urciteho programu, ktora je vsak iba v novsej verzii, ako je v distribuci, ktoru mate nainstalovanu. Mozete zvolit niekolko ciest a to si ten program sam skompilujete; nainstalujete staticky skompilovanu verziu; hladate backport pre svoju verziu distra alebo si nainstalujete novu verziu svojho distra, kde uz program v pozadovanej verzii je.

Já osobně vidím Debianovské balíčky jako docela bezproblémové a každý si může sám vybrat úroveň, která mu vyhovuje (Stable, Testing, Unstable) nebo mezi nimi relativně volně pendlovat...

Na kompilace je tu buď apt-get source nebo checkinstall (vytvoří .deb balíček a nainstaluje ho místo checkinstall)

Ani na serverech nevnímám rychleji aktualizované distribuce jako problém, znám dost lidí, kteří používají třeba Debian Unstable nebo vývojovou verzi Ubuntu

mě osobně vyhovuje delší doba mezi jednotlivými vydáními, ale o to stabilněji by měli fungovat. Na notebooku mám SLED 10 a jsem spokojen. Na kancl práci mi stačí a v něm mám VirtualBox pro Win aplikace (firma). Potřeboval jsem stabilní systém který bude fungovat hned po instalaci. Problém byl jen s kodeky a problém mi dělalo se smířit s tím, že do Gnome aplikací byly zamíchány KDE aplikace. Ale jinak Enterprise Desktopy splňují dlouhodobý cyklus mezi vydáními ...

[1] To chceš má přece každá normální distribuce, ať už je to "apt-get -b source" nebo "rmpbuild" nebo něco jiného, všechny mají způsob, jak ze zdrojových balíčků vyrobit binární.

[1] To co chceš ...

omlouvám se

Zdravím,
já myslím, že otázka rozsahu dostribuce je skoro bezpředmětná. Prakticky vždy máme k dispozici obrovskou hromadu software v repozitářích, u kterého se obecně předpokládá (mimo různých testing a komunitníh věcí), že to spolu bude fungovat. Takže buď budu po instalaci hodně mazat, nebo hodně instalovat. O detaily se postará balíčkovací systém. Nevidím problém.
Ale půlroční vývojový cyklus mi přijde jako hodně rychlý. Rok s upgrady a doplněním ovladačů a tak by, dle mého, bylo akorát.

[14] Vojta
Právě že té "obrovské hormadě software v repozitářích" se říká distribuce (tedy pokud užíváte distribuční repozitáře). To kolik máte balíčků v systému po čerstvé instalaci neříká kolik balíčků má distribuce ... třeba v jedné distribuci u debianu je přes 18733 balíčků a všechny ty balíčky tvoří distribuci, během instalace se vám tolik balíčků neinstaluje.

Hmm, ten globalni velkej repozitar s veskerym softwarem me dost desi. Spis bych mnohem radeji, kdyby byl zaklad v podobe rozumny sady knihoven, jadra, etc. a zbytek by si clovek instaloval v podobe balicku primo vyrobce programu.
Kuprikladu ja pouzivam Ubuntu a v takove ty velke, "skutecne pouzivane" programy, neinstaluju z distribuce. Konkretne zrovna eclipse, firefox, blender, inkscape...
Jednoduse neni v moci spravcu vsechno to uhlidat, tak proc to nenechat na vyrobcich programu?
A napriklad za to, co ubuntu vyvojari provedli chudakovi eclipse, by zaslouzili poradnej zahlavec. Kdyby neco takoveho provedli mymu programu, tak bych se asi dost hadal...

[16]: To mně dost děsí. Proč bych si měl každý program hlídat já. Spustím firefox a ten se bude updatovat, pak to samé s thunderbirdem, vimem atd. Všechno s jiným rozhraním a jinak použitelné? Pche. To už rovnou můžeme používat Windows, kde to takto funguje.

Mně osobně vyhovuje jak to je. Prostě distributor se stará o to, aby mi to všechno fungovalo.

[17]: no jenze v mym pripade(ubuntu) to distributor krute nezvlada.
Rad bych veril, ze to nekdo zvladne, ale system, kdy se s nainstalovanym programem prida do nejakyho univerzalniho updatovace adresa s updatama, spravovana ovsem autory programu, mi prijde lepsi.
Nevim no, treba by my problemy vyresila proste jen nejaka lepsi distribuce, ale rekl bych, ze je to obecnej problem.

Ve Tvém předchozím postu někdo navrhoval, aby se oddělily knihovny od aplikací. Podle mě by měl být odlišný cyklus vydávání knihoven v distribuci, který by trval několik let - třeba čtyři roky a v mezičase by vycházely bugfixy a celou dobu by byla dodržena stabilita API i ABI. Ideálně by to bylo napříč distribucemi - tím by se stal Linux zajímavější platformou pro nezávislé vývojáře aplikací.

Každého čtvrt roku by pak klidně mohly vycházet aplikační updaty a bylo by poměrně snadné update provést nebo se vrátit k některé předchozí verzi.

[1] Systém Gentoo v tomto směru neřeší v zásadě nic. Pokud Ti někdo neudělá ebuild, tak nic nezkompiluješ a není žádná záruka, že se Ti podaří snadno upravit stávající ebuild, abys bez problémů zkompiloval a nainstaloval novější verzi. V podstatě to samé můžeš udělat i v rámci RPM (vzít stávající SPEC soubor a použít ho k sestavení novější verze) nebo v DEB apod.

[16] Pokud tuto správu Ubuntu nezvládá (nevím, sám ho už nějakou dobu nepoužívám) tak bych asi doporučil přejít jinam.

Jedním z důvodů proč se to začleňuje až později je kontrola, zda v balíčku není bezpečnostní problém nebo závažný bug, který by způsobil nestabilitu...

Pokud ale požadujete novější verze, zkusil bych třeba Debian Unstable, který je Ubuntu podobný, ale neustále zařazuje nové verze (třeba teď mám (plně funkční) OpenOffice 2.4-rc1-2 )

Zajimalo by me, jestli autor do sveho Linuxu vubec nekdy instaloval komercni software. Matlab nebo Mathematica se jakz takz daji skousnout, protoze maji radove rocni vyvojovy cyklus, ale specializovany software pro vizualizi muze mit vyvojovy cyklus delsi nez 2 roky. Tyhle firmy svuj software proti novym verzim Linuxu netestuji a v rade pripadu s novymi verzemi vubec nefunguje.

Pokud komercni software pouzivate, pak jsou diskuze o vyhodnosti rolling updates, pulrocnim vyvojovem cyklu, ... mrhanim casu. Frekvence upgradu je v tomto pripade definovana vyrobci komercniho software a zavery jako "pouzivejte Debian testing" jsou uplne mimo. V tomto dile to autor uz uznal, ale i tak si myslim, ze mu realita podnikoveho nasazeni Linuxu stale unika.

Pise se "jakz takz", kdyz uz, ty tupy sedlaku, takZe si to zapamatuj, nebo prestan tuto nic nerikajici priblblou frazi uzivat, ty dusevne autofelacni onanisto.

no kedy je problem dostat na novy linux starsi sw, ktere ma neuveritelne zavislosti nebo dokonce vyzaduje podporu v kernelu

[24]: no a pak jsou tu programy jako treba maple, ktery si s sebou nainstaluje i vlastni verzi Java JRE a odmita pouzivat systemovou Javu.
Nejhorsi je, ze se tomu vubec nedivim.

[25] ale to je dano programem, vetsina java aplikaci (nebo ktere vyuzivaji nejakou jeji cast) si prinasi vlastni jre

a nekdy kdyz se jim podstrci vyssi verze tak prestanou fungovat, proste vyzaduji tu svoji verzi

Základní problém je, že Linux má vývojový cyklus nastaven jako nesmírně časově náročný plýtvavý proces. Existuje-li jeden jediný program pro Linux, který bude součástí většiny distribucí, pak tento jediný program projde rukama spousty lidí - baličů u každé distribuce. To je nesmírná práce (vytváření instalace), která je mnohokrát zbytečně duplikována - a leccos z toho je pak tak jak je.

Podle mě dokud se nevymyslí proces (třeba špatně řešený, ale alespoň nějaký), který umožňuje vytvořit instalaci program jen jednou a pak jej (jakýmkoli způsobem) instalovat bez následných problémů s programem do jakékoli distribuce (bez nutnosti hacků stylu statické linkování všeho) - pak nebude lépe.

[27]: Idea, ze to jednou zkompiluji a ono to bude behat vsude, tu uz byla. Ten vytvor se jmenoval Java. Ale realita byla z hlediska uzivatele takova, ze to obvykle nebehalo nikde, protoze to jako na potvoru chtelo JRE verze x.y.z.2, zatimco uzivatel mel x.y.z.1, nebo to spoustelo nejake exe soubory, ktere byly jen pro Windows.

Proto se mi predstava, ze by to tak melo fungovat pro bezne binarky, ktere zavisi na HW architekture, knihovnach, uzivatelove prostredi, ... , zda nerealisticka.

Schudnou variantou je openSUSE Build Service https://build.opensuse.org/, ktery automaticky generuje baliky pro openSUSE, SUSE Linux Enterprise, Fedora, Debian, Ubuntu, Red Hat, a CentOS.

[19] Něco takového by se mi líbilo(4 roky je však moc). Ale nevím, jak moc by utrpěl vývoj v oblasti pokroku.
Mohl by se k tomu někdo znalí vyjádřit?

[15]: To vím, ale měl jsem pocit, že se tady mluví ve smyslu "distribuce = to, co mám v počítači po instalaci". To jen na vysvětlení.

[28]: openSUSE Build Service je sice krásný nápad, ale abych získal to, co mám v jednom normálním repozitáři, musím si přidat milion repozitářů, které se pak obnovují miliardu let... ;-))

[30]: Nepletete si nahodou openSUSE Build Service a One Click Install? Diskuse je o vytvareni celych distribuci a na to se Build Service pouzivat da, viz http://en.opensuse.org/Build_Service#For_Distributors. Ze si diky nemu mohou uzivatele pripojit desitky dalsich repozitaru je pravda, ale to je o necem jinem.

[27] Miloslav Ponkrác
Pod první odstavec se klidně podepíšu. Unixové systémy mi připadá přitažlivé právě proto, že není třeba dělat věci pořád dokola do "umření". Možná by se dala najít dostatečná míra abstrakce, která by před připravila programy pro integraci do distribucí. Duplicita alespoň ze strany práce vývojářů distribucí zmizela, uživatel by pak dále šahal po distribučně specifických balíčcích upravených podle dané "filozofie" distribuce automatickým nástrojem a překontrolovaných distributorem (ne žádný unifikovaný model, který řeší až při instalaci u uživatele co se vlastně a kam má umístit). Zastáncem univerzálního instalačního balíku nejsem... distributor by měl mít kontrolu nad tím jestli daný balík pro distro je správně vytvořen, u komerčních balíků by taková kontrola(balík je podepsán ditributorem) byla zárukou, balík by nemusel být přímo v repozitářích distribuce, tam by se mohl nacházet nějaký "odkaz" na balík umístěný u výrobce, který by si to komu a jak povoluje stažení aktualizací hlídal sám.

[23] Matthew
děkuji za upozornění na chybu. Frázi používat nepřestanu, ale nyní díky vám ji snad budu používat správně, takže píše se: "jakz takz", zapisuji do notesu.

Podle mě, je to s distribucemi zvláštní. Víte - všichni chceme funkčnost a samozřejmě i inovaci - ale je třeba si položit otázku? Má smysl všechno to půlroční vydávání nových verzí? Domnívám se, že kdyby se komunita kolem Linuxu sjednotila, výsledek by byl zcela jiný. Víte nového člověka ve světe Linuxu odradí fakt, že jeho systém bude aktualizovaný dejmetomu rok a pak má třeba i smůlu, protože inovace nového distra mu zkrátka neumožní plnou funkčnost systému tak, jak byl zvyklý - vemte si třeba nové verze - ovladačů xorg-ati, kde nefungunguje to, co vždy předtím fungovalo. Obecně vzato - líbí se mi v tomto např. styl Slackware nebo Debian.
Myslím si, že sjednocení komunit kolem linuxových distribucí by mohl být docela zajímavý cíl. Představte si jednu distribuci na které maká tisíce lidí - pak si myslím, že by vše bylo jiné.

Zajímavé zamyšlení... Možnost vybrat si třeba už při instalaci distra, jaké verze programů chci, bych vážně ocenil.

(BTW bleeding edge jako synonymum ke cutting edge se píše se dvěma "e"...)

[34] Eurik
jup ... bleeding edge je termín pro krvácející technologie (kompletně na špičce nevyladěné) cutting edge mají být za nima (tedy trochu lépe vyladěné bleeding edge) oficiální termíny...
mě se ale líbí více bleading edge - je to kombinace bleeding (krvácející) a leading (jako cutting, na špičce vývoje) ... myšlenka je technologie na špičce vývoje která krvácí: (b)leading edge ... vtip schovaný v chybě pravopisu a zároveň s hlubším významem, mám rád takový kravinky ;)