Proč instalovat Gentoo (diskuse)

[Michal Fecko]

Proč instalovat Gentoo

Lebo mame radi CEZ/RWE...

[pán tě vidí]

Co víc si přát jako držitel akciového podílu.

[Hrabosh]

Čekal jsem, kdy se tento zcela inovativní a neotřelý vtípek objeví ... že to bude hnedka první příspěvek mě teda nenapadlo.

Nimcéně pravda to není ... kompilace běží v xtermu a já můžu klidne serfovat netem, koukat na filmy, nebo co.

Jinak já jsem na Gentoo přešel před lety z Debianu, kde jsem systém vždycky po čase dostal do "dependency hell". U Gentoo se mi to nepovedlo a to ho mám na dvou laptopech a desktopu - přemýšlím, že ho nacpu i na FreeRunner, který jsem tu před časem koupil

[Jendа]

Nimcéně pravda to není ... kompilace běží v xtermu a já můžu klidne serfovat netem, koukat na filmy, nebo co.

Většina počítačů má při zátěži vyšší spotřebu než v idle. Rovněž v idle se např. automaticky podtaktovává.

[Grunt]

Většina počítačů má při zátěži vyšší spotřebu než v idle.

Možná proto jsou zmínky o ccache a ditcc i v naprosto základním manuálu.

[Jan Kundrát (jkt)]

...spolu se zminkou, ze:

Warning: ccache is known to cause numerous compilation failures. Sometimes ccache will retain stale code objects or corrupted files, which can lead to packages that cannot be emerged. If this happens (if you receive errors like "File not recognized: File truncated"), try recompiling the application with ccache disabled (FEATURES="-ccache" in /etc/make.conf) before reporting a bug. Unless you are doing development work, do not enable ccache.

Jednoduse receno, nepouzivejte to.

[Scarabeus IV]

Verze v testing (trojkova rada) je zase vymazlena, dost sme se s tim srali, takze testing se zase da :)

[Grunt]

Ale prd velebnosti. Když farmu jež převádí ASCII do binární podoby, tak jedině s Gentoo.

[Halis]

CCACHE používám celé tři roky co jedu na Gentoo, a problém s ní jsem zaznamenal jednou, když jsem NTB vypnul v průběhu kompilace, a při opětovném pokusu se použila "špatná část kódu" z CCACHE, ale spravila to kompilace bez CCACHE (FEATURES="-ccache" emerge -pv ... nebo tak nějak). Ale je to jen moje subjektivní zkušenost, ostatní možná mají jiné.

[kotyz]

ja ji na archu pouzivam taky dlouho a taky sem s ni problemy nemel. ale ja toho zas tolik nekompiluju aby se stacilo projevit ...

[Grunt]

Já používal ccache rok a něco a nevzpomenu si na jedinou chybu…ani jsem nevěděl že ji mám. Netvrdím že je to naprosto dokonalé, sem tam se MD4 trefit nemusí a určitě by ccchace potřebovala trošku potweakovat (hlavně teda nějaký systém residua nebo tak), no když už ale někdo staví vytápěcí farmu, tak nějaký 1.5TB hadr za tři šlupky a jednu skořápku a CCACHE_DIR na něm (třeba i skrze to NFS jak píšou v manuálu) je naprosté minimum co člověk může udělat. A právě v tom Gentoo může hodně pomoct.

[vencour]

Jednou jsem na něco narazil, google mne pak navedl v hledání do bugzily (nebo kam), kde něco o ccache bylo.

[Grunt]

I přesto je to pouhá cache a ne jaderná elektrárna. Při nejhorším se dá buď (stejně jako všechny ostatní keše) flushnout (parametr -C) a nebo když ani to ne, tak se dá prostě vypnout.

[limit_false]

Ccache jsem pouzival nekolik let, ale ne v gentoo, primo v jednom produkcnim systemu pro urychleni kompilace. Kompilovalo se porad, i tak jsme narazili mozna tak jednou-dvakrat na nejaky bug, vzdy stacilo jenom smazat nacachovane fajly.

[Aleš Kapica]

Také jsem ji vyzkoušel. Ale přišlo mi to pak zbytečné. Aktualizuji denně, ale jelikož používám notebook, který si nosím sebou (rozuměj neběží neustále někde v koutě) nemá pro mne význam používat Gentoo, jelikož se dá stěží odhadnout jak dlouho taková rekompilace potrvá. A zkompilovat si sem něco na Debianu ze zdrojáku zase taková pruda není, jak si někdo myslí. Pro rekompilaci zdrojového balíku, která vyřeší problém chybějícího balíku stačí znát několik příkazů:

apt-get update
apt-get build-dep balik
apt-get -b source balik

V případě problémů se závislostmi je dobré vědět, že se nastavují v souboru debian/control, a autor zdrojového balíku může při kompilaci binárky používat jinou verzi knihovny než máte u sebe. Aby pak automatická aktualizace vámi upravený balík nechtěla převalit binárním balíkem distribučním, je dobré navýšit číslo verze. Je to opět záležitost několika příkazů

cd balik-0.1
dch -i
dpkg-buildpackage -rfakeroot
cd ..
dpkg -i *.deb

Pro aktualizaci jednoho balíku tak není nutné překompilovávat polovinu systému. A výhoda? Že pak lze několika příkazy hotové balíčky rozdistribuovat během okamžiku na všechny stroje na kterých jej chcete mít a apt si po instalaci již sám dotáhne chybějící balíky z repozitáře distribuce.

[rADOn]

A zkompilovat si sem něco na Debianu ze zdrojáku zase taková pruda není…

Ano, kompilovat zdrojové balíky je to jednoduché, rychlé a k ničemu.

…autor zdrojového balíku může při kompilaci binárky používat jinou verzi knihovny…

Tohle zneužívání dpkg-shlibdeps je jedna z věcí který mě na debianu neskutečne serou. Což vede k následujícímu:

…Pro aktualizaci jednoho balíku tak není nutné překompilovávat polovinu systému.…

Výhoda gentoo: pro rekompilaci jednoho balíku není nutné aktualizovat polovinu systému. A můžete jeden ebuild rozdistribuovat na všechny stroje a portage zkompiluje jen ty závislosti které jsou objektivně potřeba.

[Aleš Kapica]

Ano, kompilovat zdrojové balíky je to jednoduché, rychlé a k ničemu.

Tak to si poněkud ve svém zápalu pro gentoo ustřelil, ne? Jasně jsem tím sdělil že pokud někdo chce, tak si ty balíky překompilovat může, ne že musí. Pokud už je balík jednou hotový, tak už se nikde nic nekompiluje.

[rADOn]

Myslím to naprosto vážně, rekompilace jakou jsi tu uvedl je k ničemu. Můžes gcc podstrčit nějaké optimalizace – rozdíl v řádu jednotek procent. To nestojí ani za ten čas který ztratíš kompilací.

Kdyby ses obtěžoval RTFA, zjistil bys že můj zápal pro gentoo je veřejně zdokumentovaný a týká se něčeho úplně jiného – možnosti změnit parametry a průběh kompilace. To v apt i rpm znamená editovat zdrojové balíky, což samozřejmě není problém, ale ve srovnání s portage už to není ani jednoduché, ani rychlé.

[Aleš Kapica]

Ano, jenže rozdíl je jinde. Pokud už si dám tu práci a takový zdrojový balík udělám tak můžu vytvořit taky vlastní repository, kterou si může přidat a z ní instalovat balíky každý kdo mi důvěřuje. A to aniž by musel řešit nějaké flagy či závislosti potažmo vůbec tušil co ta kompilace obnáší. Instaluje se mu pak jen to co je skutečně třeba a ne hromada kompilačních utilit.

Zkrátka všechno má svoje.

[Halis]

Pokud už si dám tu práci a takový zdrojový balík udělám...

V gentoo se ale nejdná o práci, ale o součást instalace, konkrétně správné nastavení USE proměnných atd. což dodatečně umí vyřešit echo "kategorie/aplikace gtk" >> /etc/portage/package.use

[Aleš Kapica]

Jenže rozdíl je v tom, že kromě mne už pak nikdo nic dalšího nemusí řešit, kdežto u gentoo co stroj to originál.

[vencour]

Co originál proč? Onen konfigurák package.use můžu mít/mám na všech strojích stejný.

[mimi.vx]

+1

[Grunt]

Já jen čekal kdy se tady začnou propírat stará dobrá klišé. Lamy jsou prostě na obou stranách a to se holt jen tak nezmění (po těch pár letech určitě ne).

[Michal Fecko]

Noze a aky je najlepsi komp na zacatie skusania Gentoo (CPU, RAM, disky)?

[rADOn]

Ja zacinal na 300MHz celeru / 256M RAM, takze cokoliv dnesniho povazuju za nechutne predimenzovany Zalezi jak to pouzivas - nejlepsi je pokud muzes nechat masinu pustenou pres noc a neresit to, ale chce to trochu zkusenosti aby se hned prvni noc povedlo vsechno podle predstav. Na vyzkouseni a zacatek instalace je nejlepsi vybodnout se na livecd a instalovat z chrootu z existujiciho distra.

[vencour]

Jj a taky nezapomínat, že funguje něco jako "emerge --resume" ... čili se dá přerušit, pracovat na něčem, pokračovat.

[Grunt]

To je úplně jedno. Kompilovat se dá snad na všem. Klidně i na 720Mhz ARMu napájeném solárními články, když si to člověk udělá. Ale jinak bych doporučil zvážení nějaké té farmy ve sklepě.

[lukve]

eh, nezabudol si na "namesačnych" ktory po nociach kompiluju svoj linux za splnu mesiaca ?  www.lunar-linux.org ..... :)

[Marián Kyral]

Moc pěkný popis. Sám bych to nenapsal lépe.

[Grunt]

Gentoo má poměrně vysokou vstupní bariéru danou tím, že vyžaduje větší množství ruční práce než je obvyklé

Jo, jo. Udělat souborový systém, rozbalit tarball druhého stage a donastavovat konfiguráky pomocí Handbooku, to už vyžaduje raketového inženýra s diplomem z Harvardu. Nehledě na fakt, že existuje LiveCD.

[Grunt]

Vydáte se do divočiny, kde neplatí instalační příručky, mapy závislostí jsou staré a nečitelné a segmentation fault loví po nocích.

Jinak tohle také není pravda. Gentoo má jako jedno z mála široko daleko jednu z nejlepších dokumentací a Gentoo Wiki (akorát to není tak pohodlné) používám dodnes i na binárních distrech.

[pán tě vidí]

Hmm jenže mnohé informace jsou pěkně zastaralé a nereflektují aktuální stav.

[Grunt]

Myslím si, že taková krokovačka jako návod k uvaření polévky ze sáčku, který by fungoval na první pokus by byl pro Gentooisty urážkou.

[rADOn]

Gentoo má poměrně vysokou vstupní bariéru danou tím, že vyžaduje větší množství ruční práce než je obvyklé

Jo, jo. Udělat souborový systém, rozbalit tarball druhého stage a donastavovat konfiguráky pomocí Handbooku, to už vyžaduje raketového inženýra s diplomem z Harvardu. Nehledě na fakt, že existuje LiveCD.

To bychom měli nainstalovaný systém. Máš bragtoo – můžeš dělat ramena že máš všechno zkompilovaný a o úžasný 2% rychlejší A dál? Protože jestli to je všechno, tak jsi nikdy gentoo neprovozoval.

Vydáte se do divočiny, kde neplatí instalační příručky, mapy závislostí jsou staré a nečitelné a segmentation fault loví po nocích.

Jinak tohle také není pravda. Gentoo má jako jedno z mála široko daleko jednu z nejlepších dokumentací a Gentoo Wiki (akorát to není tak pohodlné) používám dodnes i na binárních distrech.

Dokumentace gentoo patří rozhodně mezi nejlepší. Viz třeba návod na proplutí ABI rozbíjejícím upgradem gcc – cca dvě strany textu s přesným postupem jsou rozhodně mnohem lepší dokumentace než debianí „napište apt-get dist-upgrade a zmáčkněte enter“. Jeden se až diví jak chudáci debianisti podle tak vágního popisu dokážou ten enter najít

[Grunt]

To je zas co za jelito? Měl bych na to reagovat nebo to nechat být?

[David Watzke]

Kdybych někdy v budoucnu nahazoval source-based distro na nějakej komp, tak jedině Exherbo, který je IMHO ještě lepší.

[LukynZ]

Po nejake dobe jsem se z Archu vratil na gentoo a byl jsem docela prekvapen rychlosti desktopu. Gtkperf mi nakonec hazi o 20% lepsi vysledek, nez tomu bylo na Archu (oba 64b). Inu ty veskere nastaveni a optimalizace primo na cpu maji svuj smysl :)

[Atrament]

Kdysi jsem Gentoo zkoušel ale přišlo mi to oproti LFS složité - všechny ty use flagy - stačila chvilka nepozornosti a už mi to kompilovalo hromadu věcí co jsem vůbec nechtěl. Samotná instalace systému do KDE4 trvala řádově o dost dýl než u LFS. Kdepak, když už Linux ze zdrojáků tak jedině LFS :)

[lokki]

Výhoda Gentoo sa však prejaví keď príde čas na updatovanie nainštalovaného softwaru.

[Atrament]

tak to už hodně záleží na úhlu pohledu - mně se třeba nelíbilo, že při pouhém upgradu nějaké aplikace se mi okamžitě začala automaticky překompilovávat půlka systému, takže na novější pidgin jsem čekal půl dne (ačkoliv imho mohl klidně použít většinu těch knihoven co jsem už v systému měl). V LFS to bylo o dost rychlejší a jednodušší - stáhl jsem a zkusil zkonfigurovat nové zdrojáky pidginu, zahlásilo to jednu knihovnu, že chce v novější verzi než mám tak jsem ji stáhl, zkompiloval a nainstaloval a následně už prošel i ten pidgin - akce na cca 15 minut.

Ale pokud chce mít člověk úplně všechno co nejvíce aktualizované, tak to asi fakt půjde v Gentoo udělat jednodušeji. Ale to pak aby člověku furt někde běžela kompilace něčeho :)Já jsem spíš příznivce toho udělat si podle LFS pořádně funkční systém a na ten pak pokud možno nesahat jenom si aktualizovat podle potřeby těch pár aplikací co používám a co se někde dočtu, že maj v nové verzi nějaké super featury.

[petr_p]

Stačí nepoužívat přepínač --deep.

[Atrament]

O existenci takového přepínače jsem nevěděl, takže bych řekl že jsem ho ani nepoužíval. Pokud se ale používá nějak defaultně, pak je člověk tam kde by byl s použitím i kdejaké binární distribuce - opět musí zkoumat co kde odstranit aby to fungovalo podle jeho představ, místo aby zkoumal co kam přidat :) A opravdu nevidím důvod proč studovat kdovíjak dlouho dokumentaci ke Gentoo a jeho nástrojům, když s přímým použitím zdrojáků dle LFS dosáhnu lepšího výsledku za kratší dobu i bez toho Gentoo mezičlánku.

Samozřejmě v případě, že má člověk x serverů na kterých chce udržovat aktuální a pokud možno záplatovaný systém, tak je Gentoo lepší volba než LFS. Ale na takové to domácí Linuxování je imho LFS mnohem lepší a pružnější... Jsou tu v diskusi hlasy jakože "Gentoo dělá přesně to co chci já", no já jsem z něj tento pocit neměl, ve srovnání s LFS jsem měl z Gentoo spíš pocit že cválám na neosedlaném koni po zadělané dráze :)

[petr_p]

emerge --deep není výchozí. Bez něj se aktualizují jen věci ve @world (a možná v @system), jejich závislosti jen pokud jsou potřeba. Nic vám nebrání emerge --update volat jen na konkrétní vámi zvolený balík.

[Atrament]

stejně tak mne nic nenutí vubec emerge a potažmo Gentoo používat, respektive nevidím žádný důvod to používat...

[sidik]

Mám občas takové kacířské myšlenky, že bych zkusil místo Debianu nahodit Gentoo ale pak si vzpomenu na to, jak jsem se kdysi trápil s Debianem a myšlenky zapudím několika Aptitudenáši :)

[Aleš Kapica]

Pěkné čtení. Ovšem pokud jde o KDE versus GTK (protože GTK to není jen Gnome), tak bych si dovolil nesouhlasit. Já naopak již před lety z (nejenom svého) deskopu KDE vykopel ve prospěch XFCE a prozatím se nenašel nikdo, kdo by si stěžoval že mu něco nefunguje, nebo nejde.

[limit_false]

Vyhody:

• Gentoo dela presne to co mu reknu

Nevyhody:

• Python - kvuli ABI nekompatibilite bylo nutne prekompilovavat vsechny pythoni balicky (s binarnimi extensions) pri zmene verze, ale od 2.6 nebo 2.7 uz zmrazili ABI, takze to uz nebude problem
• KDE 4 - je to proste opacha to zkompilovat, ale kvuli "-semantic-desktop -avahi" to stoji za to

OOO je i v binarni podobe (kompiloval jsem asi jen 2x) a vsechno ostatni se skompiluje do pul hodky (moc casto stejne nekompiluji, system je nainstalovan a drzi).

[limit_false]

A jeste nejvetsi vyhoda: lze celkem jednoduse mit starou verzi jednoho a novou druheho. V binarni distribuci to nelze, protoze by to neskousl linker (kvuli shared objects).

[kotyz]

i v binarnich to jde, jen to je komplikovanejsi. napriklad v archu sem mel 3 ruzny verze libjpeg a nicemu to nevadilo. akorat ze hlavickovy soubory byly jen u ty nejnovejsi ktera byla v repozitari, takze kdyz se neco kompilovalo tak jen proti ni.

[limit_false]

Nekdy to lze, ale je dost knihoven, ktere zmeni ABI a nezmeni soname. Priklad: Qt 4.5->4.6. Pak se to musi nejak nesystemove obchazet pres LD_LIBRARY_PATH nebo rpath.

Anebo to "vyresite" jak soudruzi z Adobe, kteri dali Acrobat Readeru rpath '.'. How do you FFFUUU today?

[michal]

Přesně tak, možnost kombinovat totálně zastaralé balíčky s těmi nejnovějšími je úžasná. Já používám nějaké velmi zastaralé grafické drivery=> zastaralé Xka, se kterými mi grafika běží nejlépe. A zároveň používám hromadu aplikací zase naopak úplně nejnovějších. Další věc, co je super, jsou overlays. Nové programy se tam občas objevují už půl dne po vydání, množství prográmků je opravdu úžasné a podle mě neporovnatelné s tím co nabízejí binární distribuce.

[Scarabeus IV]

Rozkosne, uz i uzivatele sere python. Asi s tim fakt neco budem muset udelat...
Jinak co pouziva Gentoo council member tak pro ukazku:

scarab@ugly-elf: ~ $ cat /etc/portage/package.mask/python 
>=dev-lang/python-2.7
>=dev-python/beautifulsoup-3.1.0

[limit_false]

LOL

Naposled me na upgrade pythonu (na 2.6) donutila portage. Ale v 2.7 uz nejsou tusim zadne zasadni jazykove zmeny a podle tohoto to vypada, ze se 2.6 jeste nejaky cas udrzi

BTW zkousel jsem i C++-kovou nahradu emerge (paludis), ale porad to chtelo tahat zbytecne mnoho baliku, a nedal si to vysvetlit, takze jsem sel zas zpatky k emerge.

[petr_p]

Jo. Na jednom hodně experimentálním systému jsem přešel na 2.7 a zaboha nemůžu rozjet XML parser v Pythonu. Ať už pyxml nebo binding na libxml2. Relevantní věci překompilovaný, ale interpreter furt hází podivné výjimky. To je taky známá vlastnost?

[rADOn]

Python…

To ale neni problem gentoo ale pythonu. A ebuild pythonu te upozorni co se stalo a jak to spravit. Porad lepsi nez ten odpornej bordel v debianu.

[Trained.Monkey]

Dobre na hrani. Na server jedine Centos (nebo Redhat)

[limit_false]

Zavisi co chce clovek od toho serveru, typicky bych taky sel do CentOS/RHEL. Ale treba kdybych chtel uber-bezpecny Linux server, pak hardened Gentoo s grsecurity (a pak ho zakopal do zeme a vypnul elektrinu ).

[Trained.Monkey]

Kdybych chtel bezpecny server tak tam dam freebsd. Security throught obscurity

[limit_false]

Zatim jsem nikde nenasel rozumny duvod, proc by melo byt freebsd bezpecnejsi nez hardened gentoo s grsecurity. Linux ma mozna deravejsi kernel (jenze vzdy lepsi vedet o dirach, nez mit falesny pocit bezpecnosti), ale grsecurity ho dela mnohem, mnohem lepsi (a to jsou "systemove" reseni, ne jen ad-hoc).

Nevim jestli ma freebsd RBAC (uz je to nejaky ten patek co sem si s tim hral), ale RBAC je v principu neco jako model checking - v momente, kdy se porusi model, process failne.

Stejne, proti nejakemu praseti, ktere udela chybu v php aplikaci, ktera umoznuje spoustet shell lokalne, nepomuze ani freebsd, ani grsecurity (mozna s RBAC by se tomu slo vyhnout).

SELinuxu bych neveril, protoze ho sponzoruje (sponzorovala?) NSA.

[Lama na entou]

Pises ze nepotrebujes skener a tiskarnu a tak kompilujes, ale co kdyz dostanes tiskarnu k vanocum a budes chtit vytisknout dekovnej dopis? Budes muset prekompilovat cely KDE nebo se da ta podpora nejak jednoduse pridat? O co mi jde, kdyz se na zacatku rozhodnu pro neco a casem zjistim ze to chci jinak, jak moc je to opruz? To ze si ten dopis vytisknes na vedlejsim pocitaci s win7 opomenem, delame ze mas jen gentoo a zadna jina moznost. Dik

[kotyz]

jo, to je dobra otazka!

[vencour]

Tak jako první bych možná zkusil v qemu pustit něco virtuálního a vidělo by se ... Kvůli jednomu dopisu

[Scarabeus IV]

I kdyz sane vypnes tak prekompilovat vse s podporou pro tisk (cups) a skenovani (sane) trva jen chvili, kouknem na to u toho cupsu:

scarab@ugly-elf: ~ $ equery hasuse cups
 * Searching for USE flag cups ... 
[IP-] [  ] app-emulation/wine-1.3.8:0
[IP-] [  ] app-text/ghostscript-gpl-9.00:0
[IP-] [  ] mail-client/thunderbird-3.1.3:0
[IP-] [  ] net-fs/samba-3.5.6:0
[IP-] [  ] net-wireless/bluez-4.81:0
[IP-] [  ] www-client/chromium-8.0.552.215:0
[IP-] [  ] x11-libs/gtk+-2.22.1:2
[IP-] [  ] x11-libs/qt-gui-4.7.1-r1:4

A nyni jednotlive casy komplikaci :P (nebo kompilaci):

     Mon Dec 13 18:59:57 2010 >>> app-emulation/wine-1.3.8
       merge time: 13 minutes and 1 second.
     Wed Nov 10 11:40:22 2010 >>> app-text/ghostscript-gpl-9.00
       merge time: 5 minutes and 56 seconds. 
     Thu Sep  9 16:54:08 2010 >>> mail-client/thunderbird-3.1.3
       merge time: 21 minutes and 7 seconds.   
     Wed Nov 10 18:26:39 2010 >>> net-fs/samba-3.5.6
       merge time: 9 minutes and 26 seconds.  
     Mon Dec 13 17:02:44 2010 >>> net-wireless/bluez-4.81
       merge time: 53 seconds.        
     Mon Dec 13 22:23:51 2010 >>> www-client/chromium-8.0.552.215
       merge time: 29 minutes and 58 seconds.                                                                         
     Mon Dec 13 17:32:10 2010 >>> x11-libs/gtk+-2.22.1
       merge time: 5 minutes and 31 seconds.      
     Mon Dec 13 16:55:01 2010 >>> x11-libs/qt-gui-4.7.1-r1
       merge time: 14 minutes and 4 seconds.  

Takze dejme tomu ze jsem sexy a chci tisknout ze sveho kde, tak jedine co potrebuju je ten cups zapnout na qt-gui a ghostcript-gpl, teoreticky mozna jeste na bluez jestli pouzivam modrej zub k tomu, zbytek sou jen takove tresnicky na dortu.

[lama na entou]

tak to jo, casove to vyjde asi jako hledat ovladace na win7 a pak parkrat restartovat

[limit_false]

Prakticky mi se soucasnymi procesory skutecne prijde rychlejsi kompilovat nez instalovat neco na Windows. Nez dostanu Windows do pouzitelneho stavu ("odvirit" nejaky nahodny pocitac, nainstalovat ovladace, cygwin, gvim, nejaky klon total commanderu, odstranit tu spoustu balastu, co se nainstaluje s ovladaci...) tak je dokompilovano. Navic kompilace nevyzaduje neustale klikani jako blbec. Vim ze ve win existuje automated/unattended install, ale to se hodi jedine kdyz to same clovek instaluje stejne veci na identicke/podobne masiny.

Kompilovat KDE 4 je opruz, protoze je to obluda, ale neni potreba to delat tak casto. KDE 3.5 byly skompilovany celkem rychle (sem nektere soucasti prekompilovaval kvuli bezpecnostnim chybam atd.)

Krome KDE 4 nebo zminovaneho pythonu je snad vsechno ok (a python by uz nemel byt problem do budoucna kvuli zmrazeni ABI).

[Kuk!]

Pouziva nekdo zdejsi Funtoo? Jake jsou vase postrehy/nazory na nej?

[Marián Kyral]

Vypadá to jen jako nadstavba nad Gentoo. Použití gitu pro strom portage je jediná věc, která mě zaujala. U Gentoo tedy zůstanu

[mimi.vx]

je tam par balicku navic + novy release tool ... a dela to puvodni zakladatel gentoo:)

[Let_Me_Be]

Uz se zlepsila kvalita balicku?

[Marián Kyral]

Kterých?