Gentoo nám umírá? Možná jenom trochu hnije. Co teď? (diskuse)

[wifinista]

Ehm, v ruce CD s gentoo, před sebou počítač, po přečtení tohoto článku CD s gentoo položeno zpět na stůl a ruka sáhla vedle po CD s ArchLinuxem, teď si oči archa prohlížejí a já uvažuji, zda svou volbu zvolit gentoo ještě jednou pořádně nezvážím. btw, přemejšlel si i o alternativě z trošku jiný rodiny operačních systémů?

[Let_Me_Be]

Jakou konkretne? Valgrind nema skoro nikde alternativu. Kvuli nemu jsem presel kompletne na Linux.

[wifinista]

Mno jde o pribuzneho GNU/Linux, splnuje normu POSIX a patri do rodiny BSD systemu, napriklad FreeBSD, PCBSD apod...

[Let_Me_Be]

Tady narazim na HW podporu :(

Muj kompl ma lepsi HW podporu pod Linuxem nez pod Windows (to byl pro mne docela sok), kdyz si teda odmyslim chybejici dmraid v drtive vetsine dister. Silne pochybuji ze bych na nem rozjel BSD (i kdyz ke Gentoo to nema moc daleko).

[Let_Me_Be]

A ted jeste koukam ze valgrind tam nema moc podporu.

[raxas]

nechal ses zbytecne vydesit blabolenim nezodpovedneho pedagoga

[Max]

Kvůli pár z výše zmíněných věcí + ještě nějakým navíc jsem přešel k archu ...
Zdar Max

[bazil]

Hlasuji pro ArchLinux

[Shadow]

Taktéž.

[Karel]

Taky, mam ho na NB a nestezuji si. :)

[pools]

Taky jsem přešel od Archlinuxu ke Gentoo

[Shadow]

Mám Arch, nějakou dobu jsem se poohlížel po Gentoo, ale jak to tak vidím, asi si nechám zajít chuť.

[raxas]

i ty ses nechal zbytecne vydesit blabolenim nezodpovedneho pedagoga

[Shadow]

OK, možná jsem se trochu unáhlil. Gentoo časem určitě zkusím.

[TanisCZ]

Neřekl bych, že je na tom Gentoo tak špatně. Jinak archlinux a stabilita jde celkem dohromady, pokud jsou v pacmanu zakomentovány zdroje unstable a testing. Ale je pravda, že občas při pacman -Syu je dobré sledovat Archlinux.org(kdo si pamatuje na problém s udev, ví o čem mluvím) Takže také bych Ti doporučil Aršíka :)

[saly]

Heh, já mám Arch Linux a chtěl jsem vyzkoušet Gentoo :) Jinak Archa můžu doporučit, měl jsem ho na desktopu, teď ho mám i na notebooku.

[xm]

Arch Linux mohu jedině doporučit, PKGBUILDy v Archu jsou nesrovnatelně jednodušší na psaní než ebuildy v Gentoo (Arch se drží filozofie KISS), systém je krásně čistý (opět KISS), je to čistě rolling updates distribuce a dle mých zkušeností celkově aktuálnější než Gentoo (najdou se i balíčky kde je to naopak, ale je jich minimum), stabilita je alespoň pro mě perfektní (ovšem před updatem musí člověk číst informace na webu/RSS, jinak může jednou za čas narazit).

Také vývojáři Archu jsou dle mých zkušeností mnohem otevřenější komunitě a nesrovnatelně méně arogantní než vývojáři Gentoo, viz např. celý AUR (Arch Linux User-community Repository) kam může PKGBUILDy přidávat kdokoliv a ty kvalitní a používané jsou následně adoptovány Trusted Users a přidány do binárního repozitáře [community].

[xm]

Jinak co se týče kvality balíčkovacího manageru, tak Pacman (specielně od verze 3.0) nemá IMHO konkurenci Mám dlouhé zkušenosti s portage, apt-getem a yumem, přičemž Pacman mi vyhovuje suveréně nejvíc (perfektně řešené závislosti u balíčků, plně funkční reverse dependencies, filozofie KISS, atd.).

[Let_Me_Be]

To neznas paludis :)

[xm]

Máš pravdu že neznám, klidně může být dobrý (určitě stejně jako portage bude mít perfektní podporu pro source-based balíčky - Pacman je oproti tomu čistě binární balíčkovací systém), nicméně se obávám že z portage zdědil její složitost (respektive prostě ebuildy jsou dle mého názoru zbytečně překomplikované).

Pacman dělá to k čemu je určen (správa binárních balíčků) perfektně a je přitom krásně jednoduchý a rychlý. Na tvorbu balíčků z PKGBUILDů je tu samostatný program makepkg, který je opět jednoduchý a svou funkci plní na výbornou. Prostě filosofie KISS. I když Arch tím samozřejmě ztrácí flexibilitu Gentoo (USE flagy), osobně mi to nevadí a k Gentoo už bych se nevrátil nikdy. Výhody Arch Linuxu u mě jasně převážili nad výhodami Gentoo.

[Tom]

Paludis je prave resenim problemu s emerge, ktere delaji gentoo spatne jmeno :)

USE jsou pro men zcela kriticke, pokud by je treba centos nabidl, jiz bych vahal - takhle si tam doted musim kompilovat kvuli zavislostem a tim padem ztracim vyhodu binarnich aktualizaci. A v kompilacich je gentoo lepsi/

[thl]

Pro mě má source based důležitost 10 z 10.Soft zkompilovaný s kdejakou obskurní závislostí je více náchylný na chyby, zabírá víc místa a nejspíš bude i pomalejší.A optimalizace na míru hardware je taky víc než vhodná.

[Let_Me_Be]

Tak to mam podobne. Ale jsem ochoten se toho vzdat ve prospech ostatnich faktoru.

[thl]

Hele a proč má Paludis v závislostech tetex? To mi právě připadá jako obskurní závislost.Emerge -pv paludis celkem ke stažení 105 mega, přičemž samotný tetex má 102 mega.

[Let_Me_Be]

Hmm, to jsem si zatim vazne nevsim (bude tim ze tex pouzivam). A netaha to jiny balicek?

[Luboš Doležel (Doli)]

tetex nainstalovaný nemám a instalovat ho to nechce. Ani v ebuildu není zmíněný.

[thl]

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild N ] virtual/c++-tr1-type-traits-0 0 kB

[ebuild N ] net-libs/libwww-5.4.0-r7 USE="ssl -mysql" 15 kB

[ebuild N ] app-admin/eselect-news-20071201 6 kB

[ebuild N ] dev-python/setuptools-0.6_rc7-r1 244 kB

[ebuild N ] virtual/c++-tr1-memory-0 0 kB

[ebuild N ] virtual/c++-tr1-functional-0 0 kB

[ebuild N ] app-text/tetex-3.0_p1-r6 USE="X tk -Xaw3d -doc -motif -neXt" 102,314 kB

[ebuild N ] dev-python/pygments-0.9 USE="-doc" 763 kB

[ebuild N ] dev-python/epydoc-2.1-r2 USE="pdf -doc" 518 kB

[ebuild N ] sys-apps/paludis-0.26.0_alpha7 USE="bash-completion python -doc -glsa -inquisitio -pink -portage -qa -ruby -vim-syntax -visibility -zsh-completion" 1,386 kB

tohle vše se chce nainstalovat

[Dušan]

USE="-pdf" emerge -pv paludis

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] virtual/c++-tr1-type-traits-0  0 kB
[ebuild  N    ] dev-python/epydoc-2.1-r2  USE="doc -pdf" 518 kB
[ebuild  N    ] app-admin/eselect-news-20071201  6 kB
[ebuild  N    ] dev-python/pygments-0.9  USE="doc" 763 kB
[ebuild  N    ] virtual/c++-tr1-memory-0  0 kB
[ebuild  N    ] virtual/c++-tr1-functional-0  0 kB
[ebuild  N    ] sys-apps/paludis-0.26.0_alpha7  USE="bash-completion doc python -glsa -inquisitio -pink -portage -qa -ruby -vim-syntax -visibility -zsh-completion" 1,386 kB

Total: 7 packages (7 new), Size of downloads: 2,672 kB

[Let_Me_Be]

Jo jinak bacha na to je potreba jit podle navodu co ma paludis na netu. Je tam i skript, ktery prevede nastaveni do formatu pro paludis.

[Tom]

epydoc ma nataven flag pdf, kvuli jehoz tvorbe chce TeX - zruste flag a zmizi TeX

[thl]

díky

[Dušan]

Sakra

[Shadow]

A optimalizace na míru hardware je taky víc než vhodná.

Hmm... jak moc veliký reálný význam má tohle v dnešní době s dnešním HW? O kolik je source based distro reálně rychlejší než binární? Neměl by někdo odkaz na nějakou (nedávnou) statistiku?

[Michal Kubeček]

Záleží na aplikaci. U takového OpenSSL nebo mencoderu to může být zajímavé. U běžných aplikací (ať už desktop nebo server) většinou procesor není úzkým hrdlem, takže tam žádný pozorovatelný efekt neočekávejte.

[Ignor]

Těžko říct jak se měří rychlost distribuce

Zkompilovat si software na míru jde v každé distribuci a myslím si, že je nejlepší dělat to jen tehdy, když to má smysl Kompilovat každou hovadinu, kterou použiju jednou za život pro mě smysl nemá. Hlavně u věcí jako openoffice.org to "na míru hw" nemá smysl vůbec žádný, smysl by mohlo mít "na míru", ale na to ty se neptáš.

[Non_E]

Vím o lidech z gentoo fóra, kteří přešli spokojeně na opensuse. Přemýšlel jsem ho zkusit, ale mám gentoo příliš vytuněné

Z tvého textu se mi zdá, že od gentoo očekáváš víc, než může dát.

K čemu jsou člověku binární balíčky? Abych si od někoho jiného nastahoval aplikace skompilované třeba s odlišnou verzí ffmpeg, (C|CXX|LD)FLAGS a bez xml use flagu? Podle mě jsou dobré jen tehdy, když potřebuju testovat novy sw - například kombinace xorg-server a ati-drivers.

Pomalé přijímání ebuildů - mám vlastní overlay a ještě z laymana. Zkouknout bugzillu je taky na chvilku. Pokud o nějakém sw nevím, ani mi nechybí - až bude ozkoušen, přijde sám. Pomalost emerge mě taky nepálí - když budu kompilovat systém hodinu, minuta čekání je v klidu. A gentoo jsem začal používat právě proto, že obsahovalo víc sw než fedora. Tam jsem si nakonec psal a upravoval vlastní rpm na kernel a programy, co sleduju. Ebuildy jsou se *.spec docela srovnatelné...

Gentoo mirrory fungují, na fóru si pořád píší lidi, nadšenci spravují overlaye; nevidím ten úpadek ať se snažím jak se snažím.

[Let_Me_Be]

Njn, tohle jsem si taky myslel. Pak jsem jednou potreboval nutne nainstalovat prohlizec djvu a byl jsem v p...

Trochu mam pocit ze si to ani necetl.

[Non_E]

Četl a dvarát Kdybych to nečetl, tak se nebudu namáhat reagovat a zaplevelovat diskuzi.

Na víc lidí asi přijde občas puzení vyzkoušet jinou distribuci, protože ta aktuální dělá tohle špatně a tamto nesmyslně pomalu. Jen jsem chtěl nějak vyjádřit, že důvody, které předkládáte, mi nepřijdou, že by zásadně omezovaly a poškozovaly to, jaké a čím gentoo je.

Btw. s djvu problém nemám, používám app-text/djvu.

[Petr "Glubo" Sýkora]

Evince s useflagem djvu je zase má volba

[Ignor]

Docela přitažlivá vlastnost je podpora rollbacků pro instalovaný software a updaty. Umí to třeba balíčkovací systém Conary.

Na něco jsem narazil i diskuzi o zypperu (openSUSE):

> I have another question about Zypper, do you have any plan to include > Rollback support? Or at least support for some rpm transacrion set, such > as noscripts, notriggers, nodocs, test, repackage... Rollback is a nice > feature and I use it on my Fedora 7 machines.

Yes, this is planned.

However, the term 'rollback' has quite different meanings depending on whom you talk to. As we support a wide range of architectures with our SUSE Linux software, rollback for e.g. zSeries (IBM s/390) users means 'bit identical' reversion to a previous state. Thats rather hard to achieve with rpm.

Akorát mi není jasné, zda plánují opravdu něco jako je v Conary nebo půjde jen o možnost rollbacku aktualizace, která selhala. Spíš jen to druhé.

U distribuce s pověstí Archu bych si nedovedl představit, že bych ji používal a neměla tuhle fíčuru.

Mně jde hlavně o to, aby distribuce fungovala aspoň nějak a nic po mně nevyžadovala openSUSE s vypnutými aktualizacemi to docela splňuje

[Michal Kubeček]

Rozumný balíčkovací systém mi kvůli funkci kterou nepoužívám nenainstaluje polovinu Gnome (používám KDE).

To není vlastnost balíčkovacího systému, to je otázka toho, jak balíkáři rozdělili systém do balíčků a jak (ne)definovali závislosti.

[h.xman]

Ne tak docela. Vtip je asi v tom, ze autor je zvykly na Gentoo, kde si nastavite USE flagy (napr. -gnome) a kdyz pak neco instalujete, tak system si ty flagy precte a volitelne zavislosti nastavi podle vasich preferenci.

[Michal Kubeček]

Což samozřejmě jde udělat i u RPM a nejspíš i u debianního package manageru. Jen se těm věcem říká jinak…

[Let_Me_Be]

Balickovaci system vnimam v kontextu dane distribuce.

[h.xman]

Ano? To jsem nevedel. Abych tomu spravne rozumel, mate na mysli ze jde tak jako u USE flagu v Gentoo nastavit to generalne? Nejde ovlivnovat zavislosti jen pri konkretni instalaci, u jednotlivych balicku? Jak se to dela?

[Michal Kubeček]

Princip viz např. Yetiho seriál.

[h.xman]

Tak jsem si to precetl a s USE flagy mi to prijde naprosto nesrovnatelne. Pripada mi to mnohem, skutecne mnohem slozitejsi, az natolik ze pro prumerneho uzivatele jako jsem ja je to nezvladnutelne.

[Michal Kubeček]

Uvědomte si, že ten díl seriálu se nezabývá použitím, ale implementací. Implementace těch USE flagů v ebuildech také není triviální záležitost. A naopak, napsat si zvolená makra do ~/.rpmmacros není o nic těžší než nastavit si USE flagy...

[Ignor]

Ale to pořád mluvíme o jednom balíčku. Je potřeba ještě dodat jak zkompilovat balíček se všemi jeho závislostmi. Tedy nějakou kompilační alternativu k "zypper install balíček".

[Michal Vyskočil]

No to, jak zkompilovat balíček se všemi jeho závislostmi je Build Service. Pravda, člověk se napíše o něco víc, než v Gentoo, ale Suse holt není source based distro.

[honza_t]

Treba takto :)

$EDITOR /etc/make.conf
USE="-muj_nejgeneralni_useflag muj_rovnez_generalni_useflag"

[Ladislav Hagara]

> Je relativně malá, tudíž výběr SW nebude asi právě ideální.
Aktuální počet spellů (balíčků) v Source Mage je 5701.

[David Jaša]

Tak mě napadlo, používáte v SM nějaký spellchecker?

[pht]

Co treba LFS?

[xm]

To má být vtip? Spravovatelnost LFS po instalaci je jedině pro čistokrevné masochisty (tím myslím systémový update softwaru, atd.).

[r]

ani ne, staci si k tomu dopsat tuny skriptu a zautomatizovat si to...
hm a pak muze clovek pojmenovat novou distribuci co vytvoril :D

[xm]

Ano, pak už je z toho nová distribuce Ostatně pokud vím i třeba Arch Linux vzniknul z LFS (Judd Vinet si chtěl udělat podobnou distribuci jako Crux a začal právě s LFS).

[pht]

To si nemyslim. Nemusite updatovat neco co funguje. Pokud chcete updatovat jeden software, tak ho proste znova prelozite. Hotovo. Zadne zavislosti. Zadne celonocni kompilovani pulky systemu.

[Almad]

Díky za popsání mého dilematu, které vrcholí s tím, že si pořizuji nový comp.

Mám akorát problém v tom, že dávám 9-10/10 možnosti "něco jako USE flagy".

Na nb a v práci jedu Kubuntu a to mě mocně saje :]

[h.xman]

Mám akorát problém v tom, že dávám 9-10/10 možnosti "něco jako USE flagy".

Jo, ja bych dokonce dal 10/10 - USE flagy je IMO nejgenialnejsi vychytavka Gentoo. Ovsem samozrejme hraji roli i jine veci, a po jejich zvazeni mi jako nejprijatelnejsi nahradnik Gentoo vychazi Arch - smim-li se pritomnych Arch-istu zeptat, Arch nepodporuje neco podobneho jako USE flagy?

[David Jaša]

Mě by z pohledu ubuntisty/debianisty zajímalo, zda mají USE flagy vůbec nějaký význam mimo systémy, kde záleží na velikosti binárek.

[Let_Me_Be]

Celkem fatalni vzhledem k tomu ze urcuji zavislosti. Na jednom balicku muze jit i o stovky MB velkou vetev. Nemluve o tom ze dost USE flagu je konfliktnich. Typicky u mc mas podporu ncurses nebo slang (v bin distru mas jednu variantu a hotovo).

[kozzi]

no tak u archu si muzu vybrat jak mc se slang tak s ncurses

[h.xman]

Me pripada na USE flags prima napriklad to, ze si je muzu nastavit jednou provzdy. Preferuju KDE a Gnome mi nevyhovuje a chci Gnomi knihovny v systemu co nejmin, tak si dam do USE flagu kde -gnome a dal uz se nestaram, nemusim si vybirat ty spravne balicky, nemusim nic zkoumat, cokoli instaluju si vybira zavislosti na KDE a ne Gnome... a je tu spoustu dalsich vyhod.

Povim vam jeden pribeh z davnych a davnych dob - nez jsem presel na Gentoo, tak jsem zkousel Mandrake a SuSE, a v obou jsem mel problemy s nastavenim fontu. Moril jsem se tim asi tyden, a nepodarilo se mi to. To bylo trauma, ktere me poznamenalo nadosmrti

Nektere aplikace si braly fonty z nastaveni Gnome, nektere z KDE, a nektere to michaly takovym zpusobem ze se mi vubec nepodarilo prijit na to, co urcuje nastaveni jejich fontu. Procetl jsem hromady navodu na netu, stahoval podle nich ruzne fonty a umistoval je do ruznych podivnych adresaru. Zeditoval jsem asi tak milion konfuguraku, v ruznych nastavovacich centrech jsem nastavoval fonty a jejich velikosti, rozliseni a dalsi veci, ktere si uz radeji nepamatuju, a neustale se mi stavaly takove veci, ze jsem konecne dosahl toho, ze v jedne aplikaci fonty vypadaly jak jsem chtel, a nasledne se v jine aplikaci uplne rozhodily a ja musel koukat na centimetrove pismena tam, kde do te doby byly ok.

Tehdy mi doslo, ze v systemu opravdu vsechno souvisi se vsim a ja nemam nejmensi tuseni, co souvisi s cim. Uvedomil jsem si, co to znamena nemit ty vztahy pod kontrolou, nemit pod kontrolou zavislosti.

Ke konci tydne uz jsem silel, z poslednich sil jsem odolaval pokuseni prohodit notebook oknem a nevedel jsem uz ani jak se sam jmenuju. Pak jsem zkusil Gentoo... nastavil jsem do USE flagu kde -gnome truetype a bylo vymalovano, od te doby jsem byl ok a k USE flagum mam vztah temer jako k nekomu, kdo mi zachranil zivot. Kdo nezazil, nepochopi

P.S. Vubec nepochybuju, ze jsem si za ty problemy mohl sam a ze jine distribuce maji sve zpusoby, jak se s tim vyporadat - ja jen ze pro me proste byly USE flagy to prave.

[michich]

Nabízí se otázka, proč bych si vůbec měl chtít vybírat mezi slang a curses.

[Let_Me_Be]

Protoze treba slang umi UTF a ncurses NE? Nebo naopak slang je relativne malo pouzivana knihovna, zatimco nad ncurses jede snad vsechno.

[michich]

Protoze treba slang umi UTF a ncurses NE?

Jestli je to tak, tak volba je tím pádem jasná. UTF-8 je dneska nezbytnost.

Nebo naopak slang je relativne malo pouzivana knihovna, zatimco nad ncurses jede snad vsechno.

Což uživatele vůbec nemusí zajímat.

[David Jaša]

Nesouhlasím - většinu z popsaných věcí zařídí odstupňované závislosti, možnost logického OR v závislostech a virtuální balíčky - viz třeba ubuntí totem, který je virtuálním balíčkem a může mít jako backend buď xine nebo gstreamer, ale ne oba naráz nebo debianí freeradius, který nepovinné moduly pouze navrhuje ("suggests"; nejslabší závislost) a tudíž se samy od sebe neinstalují. Do schopností USE flagů tak schází jediná - nabízet defaultně k instalaci ty závislosti, které jsou v proměnné.

[h.xman]

Do schopností USE flagů tak schází jediná - nabízet defaultně k instalaci ty závislosti, které jsou v proměnné.

Jenze to je IMO na cele veci prave to podstatne.

[David Jaša]

Mě to nějak moc nechybí, protože v Aptitude si před instalací/upgradem prolítnu navrhované změny a doladím je ručně.

[kozzi]

řekl bych že nee, ale popravdě pořádně ani nevidím význam v useflagech, teda jako né že by to nebylo super, ale u archu se stejně používá spíš binární forma balíčků a tamto IMHO nemá vyzanm a u PKGBUILDů si to už člověk může nastavit sám sčím se mu to bude kompilovat.

[David Jaša]

Pokud se systém tváří, že zabírá moc místa na disku, tak zkuste dát do /etc/apt/apt.conf řádku:

Aptitude::Recommends-Important "false";

(případně Aptitude nahradit za APT podle používaného frontendu).

[kozzi]

Ve škole máme asi 30-40 pc + serve na kterých bylo gentoo i na serveru. Bohužel poslední dobou se vše začalo spomalovat, komplikovat, často padal provoz na síti atd. Prostě to celý uhnilo. Důvodů je určitě hodně a gentoo mohlo možná jen za 1 procento chyb, ale i tak se nakonec rozhodlo nahodit místo gentoo Archlinux. Dokonce jsem se nebál o stabilitu a nasadil jsem ho i na server (mám archlinux delší dobu a vím že je opravdu stabilní, dřív se párkrát stalo že se něco pokazilo, ale v dnešní době si už tvůrci archu dávají pozor a asi více testují balíčky). Přechod proběhl naprosto bezproblémů. Jediná potíž bylo že jsem plánoval použít nfs4 ale stím se to chovalo nestabilně, takže se teď používá nfs3 a vše je OK. Jinak většina lidí si všimla rozdílu, že to teď běhá mnohem lépe. Krom toho pacman je prostě super balíčkovací manager a jinak existence PKGBUILDů ti dává možnost přizpůsobit si balíčky svým potřebám. Hardwarová podpora mi příjde perfektní. tam kde jiné distribuce zkrachovali Arch si bezproblémů poradil (O zkoušeno na mnoha pc, ale netvrdim, že arch je na tom vždy lépe než jeho konkurence). Množství softwaru je prostě v Snad ve většině případech si vystačíš se základnímy repositáři( sem počítám i community) a když náhadou nastala situace že daný balíček nebyl v repo, tak byl v aur nejakej PKGBUILD takže stačilo si balíček vygenerovat, k tomu se hodí nainstalovat yaourt který má stejnou syntaxi jak pacman ale instaluje balíčky právě s AURu

[jm]

Stable core - důležitost 8z10

Bleeding edge updates - důležitost 10z10

Priste si ujasni, co vlastne chces, nez zase nejakou podobnou perlu vypustis do elektronickeho eteru.

[kozzi]

? A proč vždyt to rekl jasne si to poradne precti a pak neco postuj.

[jm]

Samozrejme, bleeding-edge updated a stabilita, to jde perfektne dohromady, zejmena co se tyka toolchain...

[kozzi]

No znovu Vás poprosím aby jste si to přečetl pořádně, pokud to opět nepochopíte, tak už zbývá jen .....

[David Jaša]

Mluvíš s vývojářem Gentoo. Otázka je, zda z toho titulu dané věci rozumí mnohem více než ty nebo naopak vůbec.

[jm]

Pardon, ale pokud nekdo nechape, ze stabilita system nestoji na kernelu + X serveru, tak asi vazne neni o cem.

Pokud chce nekdo pouzivat bleeding-edge toolchain a zaroven pozaduje prioritne stabilitu systemu, tak to bude asi potencialni uspesny kandidat na vynalez perpetuum mobile. Hodne stesti.

K jinym nesmyslum:

Krásnou ilustrací tohoto problému je fakt že ebuildy pro KDE 4 se začali připravovat až den po oficiálním vydání a vyřešení kolizí trvalo šest dní. Když si uvědomíte, že datum vydání bylo známo minimálně měsíc dopředu a freeze SVN byl minimálně týden předem, je to velká ostuda.

Aha, tys to asi sledoval z Pendolina, mam takovy dojem. Na ebuildech pro KDE4 a prislusnych eclass se pracovalo mesice predtim, nez bylo KDE4 'final' vydano. Za tyden by to opravdu nikdo nestihl ani omylem.

Vývojáři často zdržují balíčky (stačí se podívat do bugzily) tak dlouho že ebuild nemá šanci dokonvergovat do funkčního stavu (obvykle se protočí mnoho nových verzí).

Jiste, dodej tak 50 kompetentnich vyvojaru a mas sanci, ze se alespon petina z cca 2500 balicku, co maji pozadavky na zacleneni v bugzille, do distribuce skutecne dostane. Do te doby jsou priority nekde jinde nez v zaclenovani novych balicku, na ktere nema nikdo cas.

Systém rozhodně zajímavý nicméně díky relativní složitosti a již vzpomínaným problémům emerge je tvorba ebuildů značně složitá.

Zatimco tvorba korektnich RPM balicku je tak trivialni, ze si vyslouzila tady mnohadilny serial. To je fakt argument jak hrom.

Atd. atd. atd., skoda casu...

[kozzi]

No vida konečne opodstatněné vyjádření . jinak k tomu jestli stabilita systému souvisí s jádrem + Xserverem, tak to snad závísí na každým znás. každý máme své priority a pro každého znás vypadá stabilní systém jinak. Pro mě je stabilní každý systém na kterém najede alspoň jádro a pár základních initscriptů tak abych se mohl přihlásit a vše co nefunguje opravit . Jinak k tem ostatnim nesmyslum toho moc rict nemuzu deni oklo gentoo jde mimo mě. Snad jen takový detail posuzovat složitost něčeho podle toho, jak dlouhý článek o tom vyšel je IMHO trochu nepřestné. Někdy se i jednoduchá věc dá rozebrat na několik stránek textu .

[Let_Me_Be]

A co ma sakra stabilita systemu spolecneho s tim ze mam bleeding edge GDB nebo valgrind (jo uznavam u GCC to tak neplati)? Naucte se cist nez na neco reagujete.

Ano na Beta a RC a SVN ebuildech se pracovalo, vzdyt taky byli k dispozici vetsinou ten samy den co dana verze vysla. A ano sledoval jsem to docela pozorne vcetne jednotlivych bugu. Rychlost odstranovani byla jeden za den. A ano KDE 4.0 melo byt v portage ten samy den co vyslo. Libovolne zpozdeni je ostuda.

"Jiste, dodej tak 50 kompetentnich vyvojaru a mas sanci, ze se alespon petina z cca 2500 balicku, co maji pozadavky na zacleneni v bugzille, do distribuce skutecne dostane. Do te doby jsou priority nekde jinde nez v zaclenovani novych balicku, na ktere nema nikdo cas."

A to jako ci problem? Santa Clause? Jo predstav si ze je to problem Gentoo.

"Zatimco tvorba korektnich RPM balicku je tak trivialni, ze si vyslouzila tady mnohadilny serial. To je fakt argument jak hrom."

Jo, jenomze RPM pouziva neporovnatelne vic lidi a taky je k tomu k dispozici neporovnatelne vic nastroju. Taky nikde netvrdim ze tvorba RPM je jednoducha, ani netvrdim ze je to nejaky argument.

Tvorba ebuildu je slozita zalezitost a obvykle vam s tim nikdo nepomuze. Tecka.

[jm]

A to jako ci problem? Santa Clause? Jo predstav si ze je to problem Gentoo.

Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice balicku do distribuce, aniz by o ne mel libovolny z vyvojaru zajem. No, tak to holt vyhnije v bugzille, nebo si je muzou dat uzivatele do overlay a pouzivat je. Kde nic neni, ani smrt nebere.

Taky nikde netvrdim ze tvorba RPM je jednoducha, ani netvrdim ze je to nejaky argument. Tvorba ebuildu je slozita zalezitost a obvykle vam s tim nikdo nepomuze. Tecka.

Tvorba RPM/DEB je slozita zalezitost a obvykle vas s tim nikdo nepomuze. Stejne nicnerikajici bezcenne tvrzeni pouzite jen za ucelem flamewaru.

[Let_Me_Be]

"Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice balicku do distribuce, aniz by o ne mel libovolny z vyvojaru zajem. No, tak to holt vyhnije v bugzille, nebo si je muzou dat uzivatele do overlay a pouzivat je. Kde nic neni, ani smrt nebere."

O duvod vic prejit k jine distribuci. Je dobre vedet ze vyvojari Gentoo kaslou na uzivatele

"Tvorba RPM/DEB je slozita zalezitost a obvykle vas s tim nikdo nepomuze. Stejne nicnerikajici bezcenne tvrzeni pouzite jen za ucelem flamewaru."

Jo hlavne ze za tim navazuje sekce kde se pise ze spely v Source Mage jsou jednodussi. Ale to nic, ja vim ze jste to stejne necetl.

[jm]

"Tvorba RPM/DEB je slozita zalezitost a obvykle vas s tim nikdo nepomuze. Stejne nicnerikajici bezcenne tvrzeni pouzite jen za ucelem flamewaru."

Jo hlavne ze za tim navazuje sekce kde se pise ze spely v Source Mage jsou jednodussi. Ale to nic, ja vim ze jste to stejne necetl.

Co je mi po nejakym Source Mage? Pro me je spel spanelska vesnice, pro jineho je spanelska vesnice RPM/DEB, pro jineho ebuild. Bud se to nauc a napis si ten ebuild/vytvor balicek, kdyz to holt nikdo neudelal za tebe, protoze jsi jaksi zapomnel dotycnemu zaplatit, nebo si nestezuj.

[h.xman]

Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice balicku do distribuce, aniz by o ne mel libovolny z vyvojaru zajem. No, tak to holt vyhnije v bugzille, nebo si je muzou dat uzivatele do overlay a pouzivat je. Kde nic neni, ani smrt nebere.

Ja vas chapu, vy developeri se snazite jak tojde a uzivatele to kolikrat ani neoceni, tu obrovskou praci co uzivatelum zadarmo venujete - meli bychom vam byt skutecne vdecni. A verte mi, rad bych pomohl i jako developer, kdybych k tomu mel znalosti.

Ale na druhou stranu, jak muzete napsat to "Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice..."? Nepripada vam to jako protimluv? To nechapu - k cemu ta distribuce bude kdyz ne pro ty uzivatele? Pokud nejaky zasadni podil uzivatelu (tisice) ma problem, tak ma problem distribuce.

IMO to neni tak, ze chudaci developeri nestihaji protoze je jich malo, a uzivatele to nechapou a opruzuji. To neni nahoda, kdyz nejaka distribuce nema dost vyvojaru. To muze byt taky systemova chyba. Myslim ze Robbins ma pravdu v tom, ze vstupni bariera pro prechod od uzivatele k vyvojari je prilis vysoka - je spousta schopnych lidi (nekteri se vyjadrili k Robbinsove postu), kteri by radi pomohli, ale proste jim pripada ze nez vubec zacnou musi prekonat prilis vysoke prekazky. Navic council nebyl schopny eliminovat lidi jako McCreesh, ktery je sice vyborny programator, ale ma takove komunikacni schopnosti ze spousta lidi nechce byt v prostredi kde se vyskytuje on, takze se pak jaksi nedostava lidi...

Uricte jsou i dalsi veci o kterych nevim, nejsem insider jako vy... to jen kdyby vas nahodou zajimal pohled "zvenku".

Diky za vasi praci pro Gentoo.

[jm]

Ale na druhou stranu, jak muzete napsat to "Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice..."? Nepripada vam to jako protimluv? To nechapu - k cemu ta distribuce bude kdyz ne pro ty uzivatele? Pokud nejaky zasadni podil uzivatelu (tisice) ma problem, tak ma problem distribuce.

Pro vyvojare... vyvojar je taky uzivatel. Pokud nikdo nema o dany novy balicek zajem, mas v zasade dve moznosti - stan se vyvojarem, nebo si to udrzuj v overlay (lokalnim, nekdo nekterem, ktere za timto ucelem existuje, napr. Sunrise).

IMO to neni tak, ze chudaci developeri nestihaji protoze je jich malo, a uzivatele to nechapou a opruzuji. To neni nahoda, kdyz nejaka distribuce nema dost vyvojaru. To muze byt taky systemova chyba

To neni o nedostatku vyvojaru, to je o nezajmu vyvojaru o nove balicky. Temer kazdy, kdo da novy ebuild do bugzilly, trpi bohuzel predstavou, ze bez daneho balicku nikdo nemuze zit a proste musi v te distribuci byt - coz je bohuzel zasadni omyl.

A ne, opravdu nemame dost vyvojaru na to, abychom pridali dalsich 2500 balicku. Ono uprimne receno, tak polovina z tech balicku uz davno umrela na nezajem upstream vyvojaru, aniz by se dotycny uzivatel obtezoval dany bug uzavrit. Takze proste hnije, hnije a hnije, dokud si ho nekdo nevsimne a neuzavre ho jako WONTFIX.

[Let_Me_Be]

Ok, takze abych byl plnohodnotny uzivatel Gentoo musim se stat vyvojarem (coz rozhodne nebude trivialni proces) abych si mohl do distribuce vlozit vlastni balicky. Pak ale rozhodne ma smysl hledat alternativu, protoze na tohle vazne nemam cas.

Overlay je problem, neni mozne zarucit dostatecnou uroven QA. Kdyby existovalo neco jako ma Arch Linux, proste repozitar, kam lide davaji ebuildy ktere jdou primo testovat a je to soucasti distribuce, kde se hned odhali ze neco nekde koliduje, nemel bych namitek.

[jm]

Ok, takze abych byl plnohodnotny uzivatel Gentoo musim se stat vyvojarem (coz rozhodne nebude trivialni proces) abych si mohl do distribuce vlozit vlastni balicky. Pak ale rozhodne ma smysl hledat alternativu, protoze na tohle vazne nemam cas.

A co si predstavujete pod takym slovom 'plnohodnotny uzivatel', Kefalin?

Overlay je problem, neni mozne zarucit dostatecnou uroven QA. Kdyby existovalo neco jako ma Arch Linux, proste repozitar, kam lide davaji ebuildy ktere jdou primo testovat a je to soucasti distribuce, kde se hned odhali ze neco nekde koliduje, nemel bych namitek.

Zatimco ebuild v oficialnim repozitari, o ktery se nikdo nestara, je uzasnou zarukou QA. No, tudy asi cesta nevede, rekl bych...

[Let_Me_Be]

+1

[kavol]

meleš <|>-oviny

Jiste, dodej tak 50 kompetentnich vyvojaru a mas sanci, ze se alespon petina z cca 2500 balicku, co maji pozadavky na zacleneni v bugzille, do distribuce skutecne dostane. Do te doby jsou priority nekde jinde nez v zaclenovani novych balicku, na ktere nema nikdo cas.

A to jako ci problem? Santa Clause? Jo predstav si ze je to problem Gentoo.

Ne, to neni vubec problem Gentoo. To je problem uzivatelu, kteri se snazi vecpat tisice balicku do distribuce, aniz by o ne mel libovolny z vyvojaru zajem. No, tak to holt vyhnije v bugzille, nebo si je muzou dat uzivatele do overlay a pouzivat je. Kde nic neni, ani smrt nebere.

- to JE problém Gentoo

za dva měsíce (převážně oprašování vědomostí a nic-počítačového-nedělání přes svátky) jsem se stal přispěvatelem ve Fedoře (a Livně) s balíčky pro qmmp

v Gentoo bugzille mi hnije několik ebuildů, o které se příležitostně (dle vlastní potřeby, neb coby prostý uživatel k nim nemám závazky) starám, již léta ... z dostupných materiálů jsem vyrozuměl, že je zájem pouze o lidi "na plný úvazek", nikoli o přicmrndávače

takže je chybou Gentoo, že část lidí, co by nějaký z těch 2500 balíčků mohli udržovat, prostě posílá do háje - a pokud jsem to blbě pochopil, a Gentoo by uvítalo i takové lidi, pak je opět chybou Gentoo, že to nedá jasně najevo

Taky nikde netvrdim ze tvorba RPM je jednoducha, ani netvrdim ze je to nejaky argument. Tvorba ebuildu je slozita zalezitost a obvykle vam s tim nikdo nepomuze. Tecka.

Tvorba RPM/DEB je slozita zalezitost a obvykle vas s tim nikdo nepomuze. Stejne nicnerikajici bezcenne tvrzeni pouzite jen za ucelem flamewaru.

nevím jak u deb, ale přinejmenším o rpm to neplatí - aspoň pro Fedoru (a před pár lety pro Mandrake )

tak laskavě nelži

[Ignor]

ŽeňTó nemá žádné alternativní repozitáře, kam by šlo snáz natlačit svoje balíčky?

Z celé diskuze jsem vlastně nabyl dojem, že existuje buď jen jeden všeobjímající repozitář nebo že provozování vlastních repozitářů je věc nesnadná a jejich používání taky není tak samozřejmé jako v jiných distribucích.

[pools]

tu nebo tu

[Let_Me_Be]

Spis jde o to ze kdyz si v debianu pridas nejaky jiny repozitar, tak se ti v podstate nema co rozbit. Maximalne ziskas nestabilni system. U Gentoo se toho muze rozbit docela dost.

V Gentoo si muzes udelat lokalni repositar a do nej vlozit libovolne ebuildy, bohuzel je potreba ty ebuildy udrzovat aktualni vuci zbytku systemu, jinak prestanou casem fungovat (casto relativne jednoducha cinnost).

Existuje spousta overlays. Ty technicke jednoucelove jsou vetsinou v dobre kvalite, horsi je to s overlays, ktere jsou obecne a obsahuji hromady balicku ruzneho zamereni.

[kavol]

... jejich používání taky není tak samozřejmé jako v jiných distribucích.

záleží, co si představuješ pod tím "samozřejmé" ...

v Archu je AUR

v Mandrivě si přidám PLF kvůli kodekům apod. a mám klid

ve Fedoře si přidám Livnu (zanedlouho RPM Fusion) kvůli kodekům apod. a mám klid

v Gentoo si mám přidat co? - která overlay obsahuje všechno co potřebuju, je konsistentní s aktuálními stabilními i vývojovými verzemi balíčků v hlavním stromu Portage, a dodržuje stejné požadavky na kvalitu jako hlavní strom?

krom toho, přidávání nějakých third party bastlů jaksi trošinku popírá smysl distribuce, to už rovnou můžu jít do LFS a instalovat software přímo od autorů ... jak pozoruju komunitu kolem MDV a Fedory, nebýt sw patentů a obskurních licencí, PLF ani Livna by nemusely existovat, dostat balíček do distra není těžké - ale ne tak v Gentoo

[Let_Me_Be]

Priste necti jenom nadpisy nez budes reagovat.

[kozzi]

reaguješ sám na svuj blogpost ? Jasny kazdej se preklikne

[Let_Me_Be]

Taky cumim

[Jiří Němec]

Záleží na tom jak je člověk náročný. Já jsem asi náročný moc a distro bez USEflagů (ty další flagy beru jako velké plus) by mě moc svazovalo. Po několika mesících používání Archa na notebooku jsem se moc rád vrátil k Gentoo.

Na Archu se mi líbilo jak je jednoduchý. Možná bych ho dal na počítač na který se jednou nainstaluje a už se na něj nemákne, ale na počítače které mam v moci já už nic tak primitivního nesmí. Snad jen to OpenWRT bych mohl tolerovat.

[slayn]

Mam zkusenosti jak s gentoo, tak s archem i se source mage. nejdriv jsem pouzival gentoo, ale zacal jsem si, stejne jako ty, vsimat ze to s nim jde z kopce. presel jsem na arch, ktery ti mohu jedine doporucit, je to imho rychla, cista a stabilni distribuce. ovsem po case sem si zacal rikat ze mi chybi USE flagy.. rozhodl jsem se vratit ke gentoo, ale to se od te doby moc nezmenilo, spis k horsimu, a ja se dozvedel o source mage. cely koncept se mi okamzite zalibil a uz tu spokojene pohani muj desktop.. system otazek mi vyhovuje vic nez USE, ale to je asi dost subjektivni. s aktualnosti nebo dostupnosti "kouzel" bych si hlavu nedelal, protoze si myslim ze je na slusne urovni a diky programu quill a tomu, ze se zdrojaky stahujou primo ze serveru autora je otazka aktualizace spellu otazkou vyberu polozky v menu a prepsani cisla verze.. jestli dela bordel? zatim se mi nezda. k odinstalovani "nepohodlnych" casti slouzi prikaz sorcery exile, ktery zajisti ze se dany program jiz nikdy nenainstaluje (pokud to ovsem nepovolime;)). vubec vsechny funkce systemu se mi libi, napriklad gaze voyeur umoznuje sledovat prubeh kompilace, coz vyuzivam kdyz neco kompiluju na konzoli a nechce se mi prepinat, nebo gaze alien, ktery najde soubory ktere nenainstaloval balickovaci system, coz je dalsi dodatek k te cistote.. mno a abych jenom nechvalil - podpora binarnich balicku je imho jeste horsi nez u gentoo, ale zase ne nulova, firefox nebo openoffice kompilovat nemusim.. dalsi nevyhodu se urcite najdou, obcas se neco nezkompiluje jak ma, instalace x.org neni zrovna nejidealnejsi (binarka asi neni) a init simpleinit-msb neni sysvinit, coz muze nekoho rozhodit.. subjektivne ho ale mam radsi:) no tak tedy to je vse co me k tomu v tuto chvili napada, a uprimne doufam ze se pocet kouzelniku rozsiri:)

[Jan Kundrát (jkt)]

Protoze hadani se v diskusi je nekulturni a neefektivni, hezky jsem si zablogoval jako odpoved :).

[Michal Kubeček]

Dva flamy místo jednoho jsou kulturnější a efektivnější? Jaké je zastoupení dvoujádrových uživatelů? :-)

[Jan Kundrát (jkt)]

Pokud nekdo v nejakem blogu prokazatelnou lzi kazi dobre jmeno Gentoo, je bohuzel neefektivni na to poukazat v diskusi o 80 postech.

[kozzi]

rejp: seš si jistej že kazí "dobré" jméno gentoo

[pools]

já ano. pokud je distribuce, která staví na systému "uživatel je pán" a uživatel si stěžuje, že musí něco dělat ručně i když by to mohl dělat systém za něj tak vidím problém v uživateli, ne v systému.

[Let_Me_Be]

Cetl ten muj blogpost vubec nekdo? To je hrozny co za blbosti tady lidi pisou.

Kde si stezuju ze musim delat neco rucne. Pokud jde o balicky, tak ty fakt nemaji tvorit uzivatele, to je prace pro lidi, kteri tomu rozumi. Ze se jim to nechce delat (jak jasne uvedl vyvojar v reakci na muj blog) a ze jich je malo je proste problem distribuce.

Ja tady pisu veci co se mi na Gentoo nelibi (jsou to stroha fakta), pak pisu co by mela vybrana distribuce splnovat a pak nasleduji jedine dve alternativy, ktere jsem nasel (ocividne asi jedine, kdyz se tady nic noveho neobjevilo).

[pools]

ale jo, ale byly tam desny ***...

[jm]

Pokud jde o balicky, tak ty fakt nemaji tvorit uzivatele, to je prace pro lidi, kteri tomu rozumi. Ze se jim to nechce delat (jak jasne uvedl vyvojar v reakci na muj blog) a ze jich je malo je proste problem distribuce.

Patrne jsi neco zasadne nepochopil. Gentoo je komunitni distribuce, na ktere pracuji neplaceni vyvojari, a jestli si myslis, ze je budes ukolovat, tak to jses asi pomatl na rozumu. Proc by mel nekdo tvorit ebuildy pro aplikace, o ktere nema zadny zajem?!

[h.xman]

Proc by mel nekdo tvorit ebuildy pro aplikace, o ktere nema zadny zajem?!

Napriklad proto, ze to pritahne uzivatele, kteri tu aplikaci potrebuji, a ti pak budou hlasit bugy i u ostatnich distribuci, a prospeje to cele distribuci? Obecne, neni snad cela Linuxova komunita o mmj. tom, ze kazdy nedela jen to, co potrebuje on, ale mysli ina to, ze kdyz prospeje druhym, tak oni zas prospeji jemu?

Prosim nezlob se, ale mam pocit, ze si to co Let_Me_Be pise beres moc osobne. On prece nerika, ze ti soucasni vyvojari maji drit po nocich, aby psali ebuildy pro aplikace, ktere je vubec nezajimaji. Spis by mozna bylo uzitecne premyslet, jestli neni chyba treba nekde v naborovem procesu, ze se nedari ziskavat nove vyvojare, kteri by o ty chybejici aplikace zajem meli.

[jm]

Proc by mel nekdo tvorit ebuildy pro aplikace, o ktere nema zadny zajem?!

Napriklad proto, ze to pritahne uzivatele, kteri tu aplikaci potrebuji, a ti pak budou hlasit bugy i u ostatnich distribuci, a prospeje to cele distribuci? Obecne, neni snad cela Linuxova komunita o mmj. tom, ze kazdy nedela jen to, co potrebuje on, ale mysli ina to, ze kdyz prospeje druhym, tak oni zas prospeji jemu?

No to je prima, a cas na to maji ty lidi vzit presne kde? Proste nebudu udrzovat neco, co me nezajima, to je jednoducha vec. Nez mit v oficialnim repozitari balicek, ktery nekdo zacleni jenom proto, aby tam byl, nacez se na nej vybodne a necha ho hnit, nebude opravovat chyby a aktualizovat ho, to je lepsi ho tam nemit vubec. Pokud uz neco zaclenim, tak to musim udrzovat v takovem stavu, aby to nedelalo ostudu.

Prosim nezlob se, ale mam pocit, ze si to co Let_Me_Be pise beres moc osobne. On prece nerika, ze ti soucasni vyvojari maji drit po nocich, aby psali ebuildy pro aplikace, ktere je vubec nezajimaji. Spis by mozna bylo uzitecne premyslet, jestli neni chyba treba nekde v naborovem procesu, ze se nedari ziskavat nove vyvojare, kteri by o ty chybejici aplikace zajem meli.

Ja nevim, odkud presne pochazi tenhle mytus, ze se nedari ziskavat nove vyvojare. Vyvojari stale prichazeji, odchazeji a nic se v tomhle ohledu nezmenilo. Pokud by mel mit nekdo o chybejici aplikace zajem, tak je to predevsim ten, kdo o ne zada. Ale bohuzel v polovine pripadu se dotycny ani nesnazi vyprodukovat nejaky pokus o balicek a plete si bugzillu s vymennou burzou ebuildu.

[h.xman]

No to je prima, a cas na to maji ty lidi vzit presne kde? Proste nebudu udrzovat neco, co me nezajima, to je jednoducha vec.

Prosim... prece v druhem odstavci jasne pisu jak tohle vidim, neni snad nutne mi pripisovat neco jineho nez co tvrdim.

Ja nevim, odkud presne pochazi tenhle mytus, ze se nedari ziskavat nove vyvojare. Vyvojari stale prichazeji, odchazeji a nic se v tomhle ohledu nezmenilo.

Jakto? Vzdyt vy sam pisete, ze je tisice uzivatelu, kteri maji zajem o aplikace, na ktere soucasni vyvojari nemaji cas a zajem. Copak z toho neplyne, ze by bylo zadouci ziskat vyvojare, kteri by ten cas a zajem meli?

Jiste, muzeme mluvit o lenosti uzivatelu, ale to nic neresi. Mozna mate skutecne pravdu - ale nestalo by za to se alespon zamyslet nad tim, jestli mezi temi tisici uzivatelu neni i spousta tech, kteri by ten zajem i cas meli (ku prospechu vsech), ale proste jim v tom brani neco v tom, jak je organizacne usporadano Gentoo? Uz jsem tady odkazoval na reakce lidi, kteri tvrdi, ze oni by do toho sli, ale brani jim v tom prave urcite systemove bariery Gentoo. Odstranit tyhle bariery by mohlo Gentoo pomoci.

Pece nam oboum jde o to nejlepsi pro Gentoo.

[Michal Kubeček]

Vzdyt vy sam pisete, ze je tisice uzivatelu, kteri maji zajem o aplikace, na ktere soucasni vyvojari nemaji cas a zajem. Copak z toho neplyne, ze by bylo zadouci ziskat vyvojare, kteri by ten cas a zajem meli?

No jo. Ale kolik z těch tisíců uživatelů je ochotno se těmi vývojáři stát, tedy svůj zájem transformovat v to, že vytvoří balíček a budou ho nadále udržovat? Silně pochybuji, že by u Gentoo takové uživatele odháněli holí…

[jm]

Vzdyt vy sam pisete, ze je tisice uzivatelu, kteri maji zajem o aplikace, na ktere soucasni vyvojari nemaji cas a zajem. Copak z toho neplyne, ze by bylo zadouci ziskat vyvojare, kteri by ten cas a zajem meli?

No jo. Ale kolik z těch tisíců uživatelů je ochotno se těmi vývojáři stát, tedy svůj zájem transformovat v to, že vytvoří balíček a budou ho nadále udržovat? Silně pochybuji, že by u Gentoo takové uživatele odháněli holí…

No to je presne. Bohuzel takovych uzivatelu je naproste minimum. Pokud se najdou a jedna se o jednotlive balicky, neni problem spravovat ten balicek jako proxy maintainer, tzn. je commity bude delat oficialni vyvojar, ale jinak ma bugy, aktualizace atd. na starosti dany uzivatel. I z toho minima tak polovina uzivatelu po par mesicich zmizi a dany balicek hnije. Takze divit se tomu, ze vyvojari jen tak nepridavaji nove ebuildy jen protoze je nekdo z uzivatelu mermomoci chce, tomu vazne nerozumim, to vubec nedava smysl.

[h.xman]

Silně pochybuji, že by u Gentoo takové uživatele odháněli holí…

Jiste ne holi, ale... ja celou tu diskusi sleduju dost pozorne, a rada lidi - i insideru - tvrdi, ze bariery ktere musi prekonat ti, kteri se chteji stat developery, jsou prilis vysoke. Kdyz to tvrdi i sam zakladatel Gentoo Robbins, ktereho dost respektuju - proste tomu prikladam jistou vahu.

Navic nejde jen o to zajemce neodhanet, ale pokud mozno jim co nejvic usnadnit cestu - lepsi pacifikace jedincu, kteri svym chovanim odrazuji slusne vyvojare, co nejlepe propracovany program mentoringu novych vyvojaru... jiste jsou i dalsi moznosti - napada vas neco originalniho?

[Let_Me_Be]

Ano Gentoo je komunitni distribuce a i kdyz konecne vytvorim balicek o ktery bude zajem tak kdyz ho nebude pouzivat zadny z vyvojaru (coz je pro urcitou tridu balicku vysoce pravdepodobne), tak se proste do distribuce nedostane i kdyz bude balicek sebelepsi.

Proste Gentoo komunita == vyvojari Gentoo. To si chtel rict? To ze Gentoo pouziva docela hodne lidi a ze by obcas neco potrebovali je celkem jedno. Pokud to netrapi zadneho z vyvojaru, tak proste smula.

Jasne, jste neplaceni, ale jak se rika: "Budto to delej dobre, nebo to nedelej." Sorry to je proste fakt. Nebo dejte na web upozorneni ze na uzivatele kaslete a ze kdyz chteji neco zmenit, maji se stat vyvojari (ted se mi vynorilo "vstoupit do strany", ale to uz je moc velka provokace).

P.S. za kvalitni udrzovany fork Gentoo bych si klidne zaplatil.

[Bluebear]

kdyz konecne vytvorim balicek o ktery bude zajem tak kdyz ho nebude pouzivat zadny z vyvojaru (coz je pro urcitou tridu balicku vysoce pravdepodobne), tak se proste do distribuce nedostane i kdyz bude balicek sebelepsi.

Nedostane, a to je jedině dobře, protože balíček, o který se nikdo z vývojářů nezajímá, v distribuci nemá co dělat. Aby mohl balíček dlouhodobě existovat, musí existovat vývojář, který se o něj bude starat, vkládat opravy chyb, balit nové verze, reagovat na stížnosti v bugzille, atd. Pokud balíček nemá svého vývojáře, je odsouzen k zániku.

Pokud ovšem máš o nějakou aplikaci zájem, vytvoříš balíček a prohlásíš, že se o něj budeš starat, tak je to jiná. V tom okamžiku se totiž sám stáváš vývojářem se všemi právy a povinnostmi a balíček je teď tvou zodpovědností - dokud se o něj budeš starat, bude v distribuci.

[h.xman]

Pokud ovšem máš o nějakou aplikaci zájem, vytvoříš balíček a prohlásíš, že se o něj budeš starat, tak je to jiná. V tom okamžiku se totiž sám stáváš vývojářem se všemi právy a povinnostmi a balíček je teď tvou zodpovědností - dokud se o něj budeš starat, bude v distribuci.

Opravdu? To rikate jako vyvojar Gentoo? Podle toho jake ja jsem mel informace, tak to neni zdaleka tak jednoduche. Ale mohu se mylit.

[Let_Me_Be]

Nedostane, a to je jedině dobře, protože balíček, o který se nikdo z vývojářů nezajímá, v distribuci nemá co dělat. Aby mohl balíček dlouhodobě existovat, musí existovat vývojář, který se o něj bude starat, vkládat opravy chyb, balit nové verze, reagovat na stížnosti v bugzille, atd. Pokud balíček nemá svého vývojáře, je odsouzen k zániku.

Ano, a Gentoo ma malo vyvojaru => neni schopno pokryt aktualni pozadavky uzivatelu => je smysluplne hledat alternativy.

[jm]

Nedostane, a to je jedině dobře, protože balíček, o který se nikdo z vývojářů nezajímá, v distribuci nemá co dělat. Aby mohl balíček dlouhodobě existovat, musí existovat vývojář, který se o něj bude starat, vkládat opravy chyb, balit nové verze, reagovat na stížnosti v bugzille, atd. Pokud balíček nemá svého vývojáře, je odsouzen k zániku.

Ano, a Gentoo ma malo vyvojaru => neni schopno pokryt aktualni pozadavky uzivatelu => je smysluplne hledat alternativy.

Jo to je logika jak stehno. Chci, aby mi peceni holubi padali primo do huby, a vono kua furt nic!!!111! Stoji to za hovno, jdu hledat alternativy.

[Bluebear]

Chci, aby mi peceni holubi padali primo do huby, a vono kua furt nic

To je tím, že tvá WiFi karta má příliš nízký výkon.

[jm]

Chci, aby mi peceni holubi padali primo do huby, a vono kua furt nic

To je tím, že tvá WiFi karta má příliš nízký výkon.

No na tom asi neco bude. To ADSL zahodim.

[Bluebear]

Je to otázka priorit. Pevná linka má mnoho výhod, ale k lovu na pernatou zvěř se nehodí.

[Josef Kufner]

Nainstaluj si Debian a nezlob

Co jsem tak koukal, tak by měl vyhovovat cca z 95 %.

[Bluebear]

Víš... snad bys opravdu měl zkusit vytvořit a spravovat vlastní distribuci. Myslím, že řada věcí, které považuješ za zbytečné komplikace, zmatek a nedomyšlenosti, by se ti najednou začala jevit úplně v jiném světle.

Udržovat linuxovou distribuci, to znamená permanentně držet pohromadě tři věci: systém, balíčky aplikací a lidi. Každá z těchto položek je naprosto kritická, bez ní se všechno sesype. Každá zároveň vyžaduje jiný přístup a spoustu kompromisů. Když se díváš jen na jednu z těchto stránek (v tomto případě ses soustředil na balíčkovací systém), může leccos vypadat jako konina, zatímco při znalosti dalších faktorů to do sebe zapadne.

Například: jeden z bodů Tvé kritiky je skutečnost, že Portage je napsané v Pythonu. Ano, díky tomu je poněkud pomalejší (ale IMHO ne zase o tolik, protože hlavní zdržení není v kódu, ale v algoritmech a v komunikaci se sítí). Ale na druhé straně díky tomu automaticky funguje na všech platformách, snadněji se udržuje, lépe se v něm hledají chyby. Protože Portage je nástroj, který drží celou distribuci pohromadě, je u něj spolehlivost a udržovatelnost mnohem důležitější než rychlost běhu.

Pokud jde o to, že autor nějaké aplikace většinou nepřipraví ebuild, tak to je sice pravda, ale totéž můžeš říct i o jiných balíčcích. Pokud má autor čas a chuť, tak někdy připraví ebuild, někdy DEB, někdy RPM, podle toho, co zná a co je mu blízké. Řekl bych, že žádný balíčkovací systém nemá převahu (u RPM balíčků je to o to složitější, že distribucí založených na RPM je víc a co funguje na jedné, nemusí fungovat na druhé).

Já pracuju v SUSE, takže vím, že i u nás všechny balíčky aplikací připravují naši balíkáři; od třetích stran nemůžeme chtít, aby pro nás připravovaly balíčky na míru. Teď se začíná situace trochu měnit díky službě OpenSUSE Build Service, kde si každý může připravit balíček sám, ale samozřejmě musí vyrobit správné zdrojové soubory pro RPM. U jednoduchých aplikací je to jednoduché, ale u složitých a komplikovaných projektů je to... složité a komplikované

Zkrátka bych řekl, že u všech balíčkovacích systémů je to stejné - všude je chleba o dvou kůrkách. Snad to platí i o distrech, i když samozřejmě různá distra se různě profilují - na desktop uživatele, který chce s počítačem pracovat a nezajímá se příliš o problematiku, bych rozhodně nedával Gentoo, ale například openSUSE; na server bych nasadil SUSE Enterprise Server nebo Debian. A na počítač krutého a drsného hackera se samozřejmě hodí Gentoo, Slackware, Linux from Scratch, nebo pro ty civilizovanější Debian. A tak dále.

Fuj, to jsem se rozkecal, snad si z toho něco vybereš, a nezlob se, že jsem didaktický

[Let_Me_Be]

Víš... snad bys opravdu měl zkusit vytvořit a spravovat vlastní distribuci. Myslím, že řada věcí, které považuješ za zbytečné komplikace, zmatek a nedomyšlenosti, by se ti najednou začala jevit úplně v jiném světle.

Ale ja na to nemam cas a proto hledam alternativu. Jo, asi bych podle reakci za to mel byt upalen.

Například: jeden z bodů Tvé kritiky je skutečnost, že Portage je napsané v Pythonu. Ano, díky tomu je poněkud pomalejší (ale IMHO ne zase o tolik, protože hlavní zdržení není v kódu, ale v algoritmech a v komunikaci se sítí). Ale na druhé straně díky tomu automaticky funguje na všech platformách, snadněji se udržuje, lépe se v něm hledají chyby. Protože Portage je nástroj, který drží celou distribuci pohromadě, je u něj spolehlivost a udržovatelnost mnohem důležitější než rychlost běhu.

Achjo, zase python. To ze je to v pythonu jsem si vzpomel az kdyz mi to bylo vytknuto v reakci. Problem je v tom ze nalezeni osamocenych balicku pomoci externich nastroju trvalo v dobe kdy jsem prechazel na paludis 5 hodin. Paludis to zvladne behem par minut. Ja se ted nebavim o kompilaci, ja se bavim o rychlosti nastroje a jeho moznostech. Bohuzel emerge je prikladem toho ze to s tou udrzovatelnosti nebude tak horke.

Pokud jde o to, že autor nějaké aplikace většinou nepřipraví ebuild, tak to je sice pravda, ale totéž můžeš říct i o jiných balíčcích. Pokud má autor čas a chuť, tak někdy připraví ebuild, někdy DEB, někdy RPM, podle toho, co zná a co je mu blízké. Řekl bych, že žádný balíčkovací systém nemá převahu (u RPM balíčků je to o to složitější, že distribucí založených na RPM je víc a co funguje na jedné, nemusí fungovat na druhé).

Nechapu, presne tohle pisu.

[Bluebear]

Ale ja na to nemam cas a proto hledam alternativu. Jo, asi bych podle reakci za to mel byt upalen.

Ale prosím tě... Vždyť ti nikdo nenadává, nepadají žádná sprostá slova - skoro bych řekl, že na místní poměry je to vysloveně vlídná diskuse. Podívej se na LKML, jakými výrazy se častují naši přední kerneloví vývojáři. A to ještě pořád není nic proti diskusím, jaké se vedou na některých českých politicky zaměřených webech.

Pokud jde o pocit, že ti lidé nerozumějí, tak se obávám, že to je prostě život. Mně se to stává také. Koneckonců, jako přednášející na vysoké škole bys měl být na ten pocit zvyklý

[Let_Me_Be]

Pokud jde o pocit, že ti lidé nerozumějí, tak se obávám, že to je prostě život. Mně se to stává také. Koneckonců, jako přednášející na vysoké škole bys měl být na ten pocit zvyklý

Vis jaka je to tady pohoda? Jo, sice si obcas pripadam jako kdybych hazel hrach na zed, ale nastesti na zaverecnych vysledcich je ten rozdil jasne videt.

[Michal Kubeček]

Hrách na zeď, to ještě jde… Jsou i jiná úsloví, ve kterých se házejí malé kulaté objekty… :-)

[pools]

Konečně rozumná slova. Začínám stavět hranici. Vyhovuje ti to zítra na Staromáku?

[Let_Me_Be]

LOL, dalsi dukaz ze tady nikdo nic necte Jak vidis jsem z Brna. Nebo spis v Brne.

[Michal Kubeček]

No a? Proč by brňáka nemohli upálit v Praze na Staromáku? Pražáci nejsou vybíraví a turisti si to taky rádi vyfotí bez ohledu na původ… :-)

[Martin Tůma]

Naopak, bude-li pálen někdo z Asie, zcela jistě to zvýší zájem Japonských turistů

[kavol]

... někdo z Asie ...

to si pleteš, orient začíná až v Lednici, Brno je o 12' západněji

[pools]

Otázka ovšem je, jak moc si Japonští turisti užijou upalování vesničana.

[David Jaša]

Českou přehradu na tebe.

[pools]

Tak to se mi ulevilo, bydlím totiž tady.