Btw na modernim HW to Gentoo neni tak pomale - jsem se vcera konecne odhodlal k migraci sveho hlavniho pc - desktopu - z 32bit (instalovano cca 15 let zpet) na 64bit ... 1341 balicku, pod 6 hodin (5:37) na i9-10900K (jen pro ucely kompilace), ktery ale dost casu zevlil, protoze ty mezikroky jako ./configure jsou single thread.
Kdyz to srovnam s instalaci macOS 12, ktery ma cca 13GB instalacku a jede to taky hodinu a pul na jejich apple hw.. a je to pouha binarka, tak je to vlastne zanedbatelny rozdil :)
Taky! K vánocům jsem rodině nadělil nové "herní" desktopy (slušnější Ryzen, slušnější GPU, rychlé nvme, hodně RAM). Svůj jsem prohlásil za buildserver/binhost, nakopíroval do něj svůj starší Zen 1 systém, upravil CFLAGS na Zen 3, a nechal to všechno překompilovat. Hotovo během pár hodin (lehce pod 1000 balíčků a minimum s Qt, webkitem a podobnými těžkými kusy).
Spise by mne zajimal nazor soucasneho uzivatele na prinosy. Pred 20 lety kdyz clovek pustil to same na tom samem zeleze tak s Gentoo to diky optimalizacim pri kompilaci melo sanci "jet" citelne rychleji. Tenkrat Gentoo dokazalo z uz ne moc pouzitelneho stroje udelat jeste celkem uchazejici, pokud clovek dokazal venovat te kompilaci treba vikend nebo mel nekde dostupne silnejsi zelezo kde si to zkompiloval. Tenkrat sem byl velky fanda a chvalil Gentoo kudy sem chodil.
Postupne sem ho ale z lenosti prestal pouzivat a presel na Debian protoze nainstalovane je to za pul hodky a vykon dostacuje i na starsim zeleze. A tam kde nedostacuje tam uz to Gentoo (podle mne) nezachrani.
Je to stejné jako před 20 lety, Gentoo je prakticky čistý upstream ze kterého si můžete poskládat co chcete. Je to primárně o konfigurovatelnosti a flexibilitě, je to metadistribuce ze které si lidé skládají svoje distra. U toho Debianu si velmi těžko budete v jednom repozitáři držet konfiguraci a build recipe desktopů, laptopů, embedded media centra atd. zatímco s Gentoo/Exherbo je tohle triviální. Mám na starosti pár desítek počítačů (což je příliš málo na enterprise řešení a příliš mnoho na individuální přístup) různorodého zaměření a takhle dělám plošně změny jedním commitem do repozitáře. Např. vyvíjíme si jeden clusterový filesystem, commitnu patch do portage patches, převezme si to CI/CD mašinerie a za chvíli je to nasazeno na koncích.
Co se výkonu týče, před pár dny tu byla zprávička o Ubuntu, kde si kompilací pro trochu vyšší target přinesli z některých aplikacích velké zvýšení výkonu. +20% v některých grafických operacích, +100% ve forking benchmarku, atd. Na Zen 3 jede libx265 encoder skoro o polovinu rychleji když je sestaven s -march=native, oproti -march=generic distribučního protivníka. Jinými slovy když investuji 90 sekund do kompilace encoderu tak potom stihnu za den stejnou práci jako distribuční stíhá za 35 hodin :-)
1) nenainstaluje se ti tuna naprosto nesmyslnych zavislosti (videl sem binarni distra, ktery i bez GUI instaluji Xka, qt, ...)
2) mas relativne aktualni verze (potazmo tam snadno dostanes i patch ktery vysel pred minutou)
3) mas kompletni build prostredi = nemusis vymejslet co kde chybi aby se to ci ono prekompilovalo
Vpohode se to prekompiluje na CPU jako je athlon nebo duron ... zadny problem. Narozdil od binarnich dister, ktere ti vynadaji ze CPU neumi to ci ono ... i kdyz to nanic nepotrebujes.
ja teda nepouzivam gentoo kvuli rychlosti, ale kvuli tomu ze se mi libi. Jak maji udelane konfigy, struktura /etc atd atd
RedHat a Debian a vse na nich zalozene je totalni bordel, v /etc je asi milion souboru a zadny podadresar, je to neprehledne a je mi to celkove nesympaticke ty distra.
bohuzel uvazuji po 20+ letech gentoo opustit a to prave kvuli te kompilaci. Vubec mi nevadi ze to trva, ale spis to ze se rychle dostanete do dependency hell, kdy se nic zkompilovat nechce. Nebo proste ty kompilace nedobehnou, to se mi stava taky casto a stalo semi to dokonce ikdyz jsem posledne instaloval from scratch.
Jo mozna by cast mych problemu vyresilo, kdybych poustel denne update world, ale to se mi nechce, treba i proto ze to casto nedobehne.
ale uz o tom uvazuji asi 3 roky, tak nevim :)
Mozna ty binarni balicky by byla cesta?
Ze nejaka kompilace selze se mi moc casto nestava - jedes na stabilni, nebo testovaci ~arch?
U toho neupdatovani - cesta je spis si na to udelat jednou za rok den, kdy vyresis ty zavislosti a udelas update. Ono to jde vzdy, jen to chce se tomu venovat a poresit konflikty.
Alternativne poustej update jednou v tydnu - to by melo postacit odchytit i nejake news, ze se neco chysta k promene - a je dobre si to precist (ostatne, ty news jsou personalizovane na tvoji instalaci).
Může to být úplně mimo, ale pokud jde o Internal Compiler Errors a děje se to na konkrétním počítači, zkusil bych memtest. Časté náhodné build failures jsou slušným indikátorem, že v paměti něco nedrží.
Denně určitě updates potřeba nejsou, tohle není archlinux kde přestane jít instalovat software už pár dní od updatu, protože na fileserverech je už novější verze. Pár updatů do roka je bez problémů, stačí si přečíst všechny nasbírané "eselect news" a provést, co se v nich doporučuje, ideálně chronologicky.
Jinak from-source distro bez možnosti dependency hellu je NixOS :-)
ee ... co se stava je typicky to, ze sudruhovia vydaji treba novou verzi pythonu ... a tobe se to dostane do stavu, kdy balicek A chce verzi X, a balicek B, ktery je tam kvuliva balicku A chce verzi X-1.
Tohle se deje pomerne pravidelne ... a vetsinou na ro zabere aktualizaci o tyden, nebo dva odlozit.
Nekdy je to trochu zapeklitejsi, a system chce nejdriv aktualizovat balicek B, ovsem ten A ma nastaveno ze potrebuje verzi B-1, pricemz ale jeho verze ktera je k aktualizci by se uz spokolila s B, ale na to nedojde protoze ...
Pokud se budem bavit o tom, cim mne gentoo doslova sere, tak to jje odstranovani veci proto ... ze se nejakemu frikulinovi nelibi. Coz se v poslednich par mesicich pomerne rozmohlo. Takze tam treba nenajdes smokeping, protoze pry ma nejakou ubermegahypotetickou chybu ... V tomhle ohledu me nejvic dojalo vyhozeni opentmpfs ... coz je asi tak 3radkovy script ... a misto toho tam nacpali 10MB systemd ... jo, tahle jebka je uz i v gentoo "povine".
To je s prominutím FUD. Smokeping jsme odstranili z hlavního repozitáře protože měl několik aktivních CVE včetně root priv escalation a upstream nereagoval. Můžeš si ho nainstalovat z několika jiných repozitářů, jen to není v hlavním, kde platí určité bezpečnostní záruky.
Opentmpfiles byl vyhozen protože je to mrtvý projekt, je proti němu několik CVE, mnoho otevřených bugů a *sám autor opentmpfiles říká, ať na to nikdo nesahá a používá něco jiného*. Bylo to nahrazeno balíčkem systemd-tmpfiles (dnes součástí systemd-utils), který *nezávisí* na systemd, dbusu ani jiné ptákovině, je to ±přepis původního programu do C. Gentoo nadále je a bude OpenRC distribuce, systemd optional.
Ty popisované situace se závislostmi jsou normální provoz, a Portage to řeší operativně. Pozdrží blokující update než se v repozitáři všechno aktualizuje. Děláme to ve volném čase a zadarmo, někdy prostě nejde dělat updaty velkých frameworků atomicky a tak se to dělá per partes. Aktualizaci není třeba o týden odkládat, jen tam prostě týden bude viset varování, že update B přeskakujeme protože není splněna závislost.
Presne jak sem rek, naprosty kecy ....
Autor opentmpgs se vyjadril v tom smyslu, ze tu hypotetickoy chybu opravovat nebude, protoze by to cele rozbil, a vte uzasne "nahrade" je tech chyb radove vic.
Systemd je povine, krome tmpfiles bylo zruseno i eudev, takze laskave nezvan. Uz je to tam cele. Opet, kecy o tom ze to nema spravce si odpust, hlasil se a byl odignorovan.
Smokeping kupodivu provozuji lidi ... pod rootem. Takze to ze root muze ziskat roota je jjim uplne urite.
Vsechny ty tvoje CVE jsou na tema, ze kdyz vyjde na obzoru Mars 30 unora a bude pri tom prset zlato ... tak se muze neco stat.
Portage nic neresi, je to na uzivatelich, tak maximalne se na netu objevi nejaky arogantni post nejakeho prudkeho ynteligenta.
*facepalm* autor opentmpfiles je vývojářem gentoo, tak leda že by odignoroval sám sebe, když o migraci na tmpfiles před dvěma lety rozhodoval.
Přímo eudev můžeš používat dál z repozitáře without-systemd (krom lidí z Gentoo to vyvíjí lidi z Alpine, Voidu a Devuanu), nebo můžeš použít standalone udev, který je součástí systemd-utils, stejně jako další OpenRC komponenty. Na systemd to nezávisí ani to žádnou jeho komponentu nelinkuje. Jen se to hostuje ve stejném monorepu.
Smokeping má setuid bit, takže privilege escalation CVE bereme vážně. Nechápu co máš za problém s tím, že je to v jiném repozitáři, vždyť to uživatelsky ani není poznat, jen máš ve výpisech balíčků místo ::gentoo napsáno ::něco_jiného.