Po 9 letech opouštím Gentoo

18.2.2012 02:09 | Přečteno: 6671× | programování | | poslední úprava: 18.2.2012 03:07

Gentoo je skvělá distribuce, mnoho jsem se u ní naučil, ale jednoho dne mi přišlo že přinejmenším na desktopu mi už nevyhovuje. Po zvažování kandidátů (Arch, Debian, Sabayon, CentOS, RHEL, Suse) jsem si nakonec vybral Scientific Linux (RHEL klon). Aka: krátká recenze Scientific Linuxu po pár měsících provozu na třech strojích.

Proč už ne Gentoo

Filozofie Gentoo nebyla tím hlavním problémem. Umím si představit například überparanoidní serverovou instalaci, kde chce mít člověk všechno do puntíku pod kontrolou a Gentoo se tam hodí. Rekompilace KDE 4 a věcí závislých od Pythonu ale začala být na desktopu otravná:

• vždy, když jsem si řekl, že zkusím nějaký nový program z KDE 4, chtělo to v zásadě kompletní rekompilaci KDE 4 (v porovnání KDE 3.5.9 nebyl žádný monolit, většinou stačilo rekompilovat jednu z nějakých desítí částí).
• Python: portage závísí na pythonu, update pythonu kvůli zpětně nekompatibilnímu ABI se muselo všechno závislé na pythonu rekompilovat, i molochy jako PyQt a matplotlib; někdy již některé balíky neexistovaly
• změna baselayoutu: možná to nebylo tak hrozné, ale pro mě poslední kapka

Jak padlo rozhodnutí na Scientific Linux

RHEL vs CentOS vs Scientific Linux

Všechny tyto tři distribuce jsou ± stejné (RHEL klony). CentOS jsem kdysi dlouho používal na serveru, odradilo mě, že komunita kolem CentOS vypadala mírně "zombioidně" (CentOS 6 se po nástupu RHEL 6 objevil snad za rok - teď to už vypadá lépe). RHEL mi po dlouhé úvaze i s nejlevnější desktop licencí přišel moc drahý (platí se ročně místo jednorázově), výhoda jsou mírně rychlejší security updaty.

Pak zůstal Scientific Linux - je za ním CERN a Fermilab, komunita vypadá solidně. Když sem nějakým "bážkem" v distribuci vpustí Ctulhu z jiné dimenze, reinkarnují Nixona nebo se na nich naštve Higgsův boson, strangelet a jiné částice, může mi to být opravdu jedno. Když tak můžu ještě rychle zamávat platební kartou, za hoďku zazálohovat a přeinstalovat root partici na RHEL

Proč nevyhrál Arch, Debian, ...

Uvedené důvody jsou spíš založeny na zkušenostech než že bych dělal model-checking, která distribuce má nejméně chyb:

• Debian: RHEL-like distribuce mi přijdou víc otestované. Debian squeeze mám stále na jednom serveru, ale narazil jsem na nepříjemný bug v debianím Postgresu, který vytvářel špatně indexy (v squeeze je již fix, ale oprava indexu byla přinejmenším otravná); SL už v tom čase ten update měl
• Arch: určitě jsem chtěl mít package manager s podporou signatur. Plus kdysi jsem narazil na problém s downgradováním (po upgrade X.org se rozsypal a zpětný downgrade byl pruda)
• Ubuntu: ještě jsem neviděl, že by upgrade na novší verzi někdy fungoval bez problému; příliš neotestované balíky
• ostatní volby (Sabayon, Suse, ...): málo praktických zkušeností, vím o nich z čtení a doslechu, párkrát jsem je zkoušel, ale na důkladné otestování nebyl čas

Scientific Linux — mini-recenze

Nejlepší je začít tím co funguje. Hm, vlastně všechno. SL je podobně jako RHEL/Debian konzervativnější distribuce - tj. typicky starší, ale otestované verze softwaru. LUKS full-disk encryption lze nastavit již v instalátoru a zatím jsem s tím neměl nejmenší problém (ale pro jistotu zálohuji častěji). Defaultní SELinux security policy je funkční. KDE je sice v "obstarožní" verzi 4.3.4 s nějakými backporty, ale funguje super stabilně (žádné pády KDE aplikací nebo memory leaky), pro mě ideální. Novější verze Firefoxu a Thunderbirdu lze použít přímo ty od Mozilly (místo ty z distribuce).

Je tudíž jednodušší jenom popsat "bážky" na které jsem narazil:

• již opraveno v SL 6.2
  • na starších strojích (> 4 roky) grafický instalátor hodil exception, textový funguje
  • gnome lock-screen má vždy default nezměnitelnou anglickou klávesnici
  • vlc z rpmforge háže SIGABRT kvůli "glibc memory corruption detected" (tohle je složitejší, viz níže)
• pořád v SL 6.2
  • nm-applet (tray-icon aplikace pro NetworkManager) občas blbne, ale stačí nm-applet zabít a spustit znova (je možné, že jenom nemá rád KDE)

Extra repozitáře

SL je proti Gentoo nebo Archu mírně chudší na nabízený software, ale je spousta extra repozitářů, seznam některých užitečných s návodem na instalaci:

• EPEL
• rpmforge
• tor (jsou tam jenom i686 a zdrojové balíky, já si to kompiluji, ale i na x86_64 lze použít i686 rpm, pro Tor Browser Bundle je nejlepší sledovat TBB download stránku a Tor blog, kde jsou oznámení o nových verzích)
• virtualbox

Rozumné je nekombinovat příliš mnoho repozitářů (nebo použít rpm package pinning a z každého repozitáře explicitně vybrat zajímavé balíčky - hledejte includepkgs a exclude v manuálové stránce k yum.conf). Zde se dostáváme k tomu vlc: v čisté instalaci SL 6.2 funguje vlc z rpmforge bez problémů, zmíněný SIGABRT na který jsem narazil je zřejmě způsoben tím, že developeři knihovny X změnili ABI a nezměnili soname (ještě jsem to podrobně nezkoumal která je to knihovna, anžto používám hlavně mplayer).

Kompilace ze zdrojáků

Samozřejmě "svatá trojice" ./configure && make && make install funguje vždy, ale budete v tom mít časem bordel. Buďto lze použít ./configure --prefix=/opt/directory a pak hraní s ldconfig, ale IMHO je nejlepší najít src.rpm (pokud nenajdete rpm pro vaší architekturu). Zdrojový src.rpm balíček lze zbuildit nástroji mock nebo rpmbuild.

Dobrá služba na vyhledávání jak binárních tak zdrojových rpm je rpm.pbone.net. Pokud src.rpm neexistuje, většinou lze do 5 minut najít nějakou starší verzi src.rpm, většinou stačí upravit jenom "version" v nazev-baliku.spec, předhodit klasické tar.gz/bz2 a zbuildit. Zatím jsem takhle buildil asi jenom pět balíků (tor-experimental, dar, truecrypt...), většinu lze nalézt v extra repozitářech.

fstab, ext4 a atime

Defaultně je v SL atime u ext4 zapnuto, člověk ho musí vypnout v /etc/fstab. Vlastně doteď netuším, proč je atime dobrý: jediný důvod je pokud vím forenzní analýza, jenže když vám někdo rootne stroj, tak je mu atime u prdele. Hlavně v případe instalace na SSD se vyplatí dát noatime do mount options.

Tipy k "manažování" GPG klíčů a signatur

Test signatury balíčku:

rpm --checksig -v balicek.rpm

I když není autor známý, vyplivne to ID klíče, který je potřeba získat a ověřit, ten klíč lze pak získat z některého keyserveru, ověřit fingerprint a importovat do ekosystému yum/rpm:

gpg --keyserver pool.sks-keyservers.net --recv-keys 0x45a1d0671abd1afb
gpg -a --export 0x45a1d0671abd1afb > packman.asc
rpm --import packman.asc #klíč musí být ASCII-armored, jinak import neohlásí chybu!

Zjištění a vylistování importovaných klíčů:

rpm -qa gpg-pubkey #listing všech klíčů
rpm -qi gpg-pubkey-1abd1afb-48d62ce0 #informace o konkrétním klíči

Závěrem

Ouroboros. Meridian. S Red Hat linuxem jsem v 199x začínal (když pominu dvoudisketový Brutalware linux), a po dlouhé době jsem tam dostal zpátky.

       

Komentáře

[Jardík]

> Arch: určitě jsem chtěl mít package manager s podporou signatur.

Něco takového bylo do pacmana nedávno dobastleno :D

OT: Proč je quote značka zakázána? Vždycky fungovala

[limit_false]

V Gentoo GPG podpisy experimentálně dobastlili taky cca 5 let zpátky, ale nakonec to do produkčního stadia nevedlo. Sice používali asi 4 hashovací funkce při kontrole checksumu ebuildu, což je sice relativně dobrá obrana proti prolomení jedné z nich, ale neudržuje identitu/pseudonymitu.

Ono je vlastně zajímavé, že problém distribuce klíčů nebyl za 20-30 let "neprůstřelně" vyrešen ani s PKI, ani s web-of-trust. Nicméně to vytváří podivný diskrétní graf, něco jako "spirálu" s několika cykly. Whitfield Diffie (myslím) řekl, že "kryptografii jsme vyřešili, teď je hard-problem distribuce klíčů". Ten hard-problem je "bootstrap" - jak vědět, že prvotní klíč patří správnému člověku?

Příklad: člověk si stáhne ISO image distribuce. Googlením ověří, že existují https stránky, které uvádějí checksumy. Jenže jak může vědět, že certifikáty dokazující identitu HTTPS stránky jsou správné? Protože jsou distribuovány třeba s Firefoxem. Jak ověří, že si stáhnul správnou binárku Firefoxe? .... pořád je to bootstrap problem. Vtipný a stručný popis co jsem viděl: "it's turtles all the way down; no 'magic' turtle present that would automagically finish the chain".

Nicméně, vzhledem k této podivné tranzitivní struktuře (jakkoliv je nedokonalá), je prakticky velmi těžké napadnout uživatele kontrolující checksumy, podpisy, ...

Vysoce doporučuji: myšlenku Petera Gutmanna "Continuity" - zkráceně ji lze popsat:

- důvěru a istotu v správnou identitu nelze vyjádřit "binárně" (jak to dělají současné implementace), je to "spojitá" funkce

- má server stejný klíč jako naposled? Jak dlouho?

- je ve stejném ASN jako naposled? Jak dlouho?

- ... (pár dalších drobností)

Napadlo mě to dávno nezávisle od Petera (a nebudu jediný). Otázka je, jak to rozumně kvantifikovat?

Zaručuji každému řešiteli nehynoucí slávu, pokud jeho/její řešení bude "(uživatelsky) rozumné", "výpočetně proveditelné" a "finančně/organizačně možné".

Částí řešení již nakóděny jsou, jde o to dát do dokupy. Odkaz na podrobnější popis Continuity: http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf (odkaz na knihu, goto page 315), slady vysvětlující problém v zkratce: http://www.cs.auckland.ac.nz/~pgut001/pubs/prot_browser_users.pdf

[Petr Tomeš]

Chvíli jsem zkoušel a používal Sabayon. Možná by Vám mohl vyhovovat, protože se v něm nevyskytuje to, co Vám vadí.

[tomr peteš]

proč lžeš?

[w4rr10r]

To já taky. Měl přesně ty vady, kterých se autor zápisku chce vyhnout.

[Petr Tomeš]

Vadilo mu portage, a to používat nemusí, protože tam je Magento/Entropy. Vadilo mu komplikovat a to v Sabayonu taky nemusí. Pak záleží na tom baselayoutu, nakolik je to pro něj důležité.

[vencour]

Přidal jsem do výběru.

[brk]

Připadá mi trošičku úsměvné, že zrovna teď ti začalo vadit občas něco rekompilovat. Když zavzpomínám na svůj 2GHz Celeron, který by se dal tak nějak zaškatulkovat do kategorie před devíti lety, tak tam mi kompilace OpenOffice trvala cca 16 a půl hodiny. Rok stará i7 to má za 55 minut a to je asi to největší zlo, které v Portage najdeš.

Dřív jsem používal binární verzi, teď už to přeložím. Takové ty běžně permanentně "idlící" programy to ani nepoznají, že se tam někde něco kompiluje a zpomalení je takřka nepatrné. OOo je moloch. U běžných věcí už ty časy kompilace pomalu nestojí ani za řeč.

[limit_false]

OOo jsem kompiloval párkrát v Gentoo, pak mi přišlo jednodušší použít binární ebuild. Pořád trvám na tom, že KDE 4 je ještě větší moloch než OOo, to je tak na kompilaci přes noc i na Core 2 Duo Thunderbird a Firefox od verze kolem 8-9 taky "pěkně" narostly.

Mně procesor až tak často neidlí, dost často něco vyvíjím. Mít všechny jádra volné a skompilovat Tor za 23 sekund je příjemnější než se dělit o jádra s buildením systému.

[AsciiWolf]

Heh, to já používal cca. 2 roky* OpenBSD na "úžasném" stroji s Pentium 1 @ 85MHz a 32MB RAM.

Podotýkám, že téměř všechen SW jsem instaloval (kompiloval) přes porty.

Ale zase je pravda, že jsem nekompiloval "molochy" - používal jsem Fluxbox, Dillo a podobné programy.

*Poté jsem tam hodil Debian a udělal z toho kompu Samba + LAMP server; jelikož byl ten stroj docela hlučný a navíc to bylo fakt efektivní topení, nahradil jsem jej po roce "krabičkou" s OpenWrt.

[Arnošt Málek]

Pridavam se k nazoru, ze dneska uz kompilace takovy problem neni. Stroje jsou rychle, pri "bezne praci" se stejne porad flakaji. Mam gentoo na svem pracovnim stroji a v podstate o nem nevim. 1x za tyden pustim "sync" a "update world" a ani o tom nevim. Kompilace ma snizenou prioritu, takze v pohode. Ted jsem podstoupil takovy maly experiment - na hrani ma Asus EEE a i tam jsem nacpal gentoo ... a nebyla to takova hruza. Za vikend funkcni system s fluxboxem, ted jsem zkusil i KDE a ono to funguje . Subjektvne lepsi, nez puvodni Win7. Ale s OO, pardon, libreoffice jsem nepochodil - pry malo pameti pro kompilaci , takze zatim bin. No, az dodam dalsi pamet tak to stejne zkusim.

Ale jinak samozrejme, kazdeho volba a preju hodne stesti a spokojenosti. Ja se priznam, ze od Gentoo snad jedine k arch, nebo lfs.

[Filip F.]

Můžu se zeptat jak tu prioritu máte sníženou? Já mám nastaveni nice na 19 a emerge spouštím ionice -c 3. Ale někdy se stane že systém začne swapovat(ne moc třeba obvykle okolo 400MB) i když má ram volnou ale využije ji jako diskovou cache. Začne disk hrabat, gui je neuvěřitleně pomalé, sekne třeba i celé na půl minuty. Stačí pozastivat emerge dohrabe to a jede ok. Příjde mi to jako by mi nefugoval ionice nebo nefungoval pro to když emerge swapuje :(. Ale příjde mě že s tím mají problém novější jádra asi tak od 2.6.25. Dokonce už se mě to stalo když jsme kopíroval na nějakou pomalou USB flash ale to zas tehdy nebylo naswapovane nic a přesto GUI se nedalo vůbec používat.

[vencour]

S tim mam podobnou zkušenost, přestal jsem na 4GB RAM používat swap a v poslední době mi OOM killer něco sestřelí, když dlouho kompiluju ... před tim je vše zamrzlé, kdybych měl swap, tak se mi plní, takhle odstřelim Xka a ... nekompiluju, hledání řešení jem zatim odložil.

[petr_p]

Vypnout memory overcommitment nebo změnit pro X oom_adj.

[vencour]

Děkuji.

[petr_p]

ionice nefunguje na swap. Zvýšená spotřeba paměti souvisí s novým linkerem v binutils a samozřejmě na tom mají svůj podíl monstrózní C++ programy.

[Filip F.]

No tak Linux neumi zajistit aby idle proces se choval opravdu jako idle ? Ma predstava o tom je ze takovy proces spustim a nebude pokud mozno vubec poznat ze bezi. A ne ze nasledky jeho behu se uplne zablokuje cely system. Vyssi spotreba pameti s tim nijak nesouvisi a ani me moc nevadi.

[petr_p]

Vyšší spotřeba paměti s tím souvisí. Jinak by se neswapovalo. A swapuje jádro, ne proces. Jádro má výsadní postavení v plánovači I/O.

Linux má docela špatně udělané řízení sdílení fyzické paměti anonymními a neanonymními stránkami. Vývojáři do toho občas rýpnou, ale zatím nikdo s ničím rozumným nepřišel. Je to totiž zapeklitý problém.

[Filip F.]

Mě ale navadí že to swapuje :)Ok tak swapuje jádro, ale přece ví kterému procesu ta stránka patří ne ? Tak proč do swapu nestrčí jenom to co patří tomu emerge, to by mě vůbec nevadilo i kdyby kvůli toho ty kompilace mely bežet 10x pomaleji protože je to furt lepší než tyhle zaseky. :) No ale stejně to nevysvětluje problém když se kopíruje třeba na to pomalé USB flash, ve swapu nic, plno volné paměti a stejně GUI se seká. Používám občas i widle a taky někdy naserou ale takhle brutální záseky tam nejsou a to maj naswapováno snad už od spuštění vždy aspoń gigabajt...

[limit_false]

Procesu lze zabránit v swapování - viz mlockall(2). Některé aplikace/knihovny to dokonce používat musí, protože není úplně dobré, kdyby se privátní klíče dostali na swap (pořád lze ale i swap šifrovat, třeba tím LUKS-em).

Jinak kernelu lze říci, jak má rozdělovat paměť mezi diskovou cache, aplikace, dirty pages, atd. přes sysctl.

BTW stejně je největší brzda pomalý disk, mezi 5400 a 7200-rpm disky je veliký rozdíl (mnohem větší než by se zdálo z podílu 7200/5400), proti SSD pak úplně neuvěřitelný. Tam nepomůžou sebelepší elevator nebo scheduler algoritmy.

[petr_p]

Mě ale navadí že to swapuje

Vadí, protože záseky jsou způsobené tím, že proces čeká, až se jeho data nebo kód natáhne z disku do paměti.

Tak proč do swapu nestrčí jenom to co patří tomu emerge?

Protože ten, kdo potřebuje paměť je „emerge“. Aby „emerge“ dostal paměť, musí jádro někoho jiného vystrčit do swapu. „emerge“ odswapovat nemůže, protože ten je zablokovaný čekáním na paměť. Kdyby to jádro udělalo, máte uváznutí nebo ping-pong efekt jako vyšitý.

když se kopíruje třeba na to pomalé USB flash, ve swapu nic, plno volné paměti a stejně GUI se seká.

Předpokládejme, že to není USB 1. To by byla kapitola sama pro sebe. Problém je obdobný, jako když se o fyzickou paměť perou procesy. Stránky blokové keše vytlačují stránky procesů. Jádro nemůže vědět, jestli keš bude, nebo nebude potřeba, tak ji uchovává. Kdyby proces označil dané I/O za přímé, tak se keš uchovávát nebude (porovnejte dd s argumenty of=direct if=direct a dd bez nich). Jenže ani to nemusí stačit, protože ještě se mohou nezapsaná data hromadit v bufferech. Algoritmus dělící stránky procesů a stránky keše a bufferů lze do jisté míry ladit (příspěvek přede mnou), ale problém je, že každé nastavení je specifické pro danou situaci. Co vám bude vyhovovat na USB paměti, bude vám vadit s ATA diskem. Ano, je tu prostor pro zlepšení, ale je to těžké. Lze čekat, že s diverzifikací blokových zařízení (rychlosti, velikosti sektorů, velikosti bufferů) se tohle začne řešit.

Pokud jde o widle, tak tam mám pocit, že používají synchronní přenos už od dob disket, aby uživatel nemusel odpojovat souborový systém, takže prostě obětovali propustnost.

[Filip F.]

Protože ten, kdo potřebuje paměť je „emerge“. Aby „emerge“ dostal paměť, musí jádro někoho jiného vystrčit do swapu. „emerge“ odswapovat nemůže, protože ten je zablokovaný čekáním na paměť. Kdyby to jádro udělalo, máte uváznutí nebo ping-pong efekt jako vyšitý.

No právě normálně to chápu, ale proč když je ten emerge spuštěný s idle a nejnižším nice prostě raděj nepočká až bude té paměti dost. To by určitě šlo ne? Třeba až večer půjdu spát zavřu svoji operu-paměť se uvolní a emerge by mohl pokračovat.

No ale už jsem to vyřešil objednáním další 4GB RAM :)

[rADOn]

AFAIK tenhle problém je už dávno vyřešený. Dokonce bych řekl že se při nedostatku paměti chová linux lépe než wydle. Problém s kousáním při velkým i/o je regrese někdy kolem 2.6.2x kdy kernel přitlačil na propustnost za každou cenu a neumí/nechce čekání v blokové operaci využít jinak. Mě se to projevuje tak že mám dost volné paměti, CPU tráví všechen čas v kernelu a mašina je na plech. Ve 3.x se to subjektivně zlepšilo.

[limit_false]

Kompilace samotná až takový problém není, ale v počátečních dobách KDE 4 jsem uvažoval často nad tím, jestli update víc opraví než rozbije. Takže pak občas nasledovala kompilace zpátky na původní verzi.

Vítěz v soutěži o nejčastější downgrade byl intelí driver na grafiku - nevím jak to soudruzi z intelu dělali, ale dokázali asi rok vydávat verze, kde vždy něco víc a víc rozbili (to už je ale pár let zpátky).

Dokud byla databáze glsa-check nějak rozumně udržována, šlo updatovat pouze security bugy a "emerge world" jenom občas (s mnoha updaty je celkem oříšek dohledat, která knihovna něco rozbila; a že je něco rozbitého jsem často zjistil až o týden později).

Po update pythonu 2.X na 2.{X+1} teoreticky stačilo pustit "python-updater", prakticky jsem se musel seznamem stovky ebuildů prokousávat a vyhazovat ebuildy, které mezičasem zmizli z portage (prošel jsem 3 iterace, 2.3-2.6). Naštěstí tuším od 2.7 Guido slíbil, že nebude měnit pythoní ABI.

Ono i z RHELu lze udelat "Gentoo": vše lze kompilovat ze src.rpm, emulovat některé featury make.conf přes rpmmacros apod.

[petr_p]

quickpkg.

[#]

presne tak quickpg, ono jde na gentoo *samozrejme* preservovat stav pred updatem a neni nutnost zpetne rekompilovat, tech veci by se naslo vice, napr jake aplikace vyzaduji rebuild komplet kde? treba neco co chce novejsi kdelibs nebo jinej useflag? ano, to urcite, ale dal pochybuju ... nicmene, chapu, sam sem po prechodu na kde4 premyslel o zatraceni gentoo a po zmene na lxde pochopil, ze gentoo neni ten problem :) (imo)

[#]

jinak abych tvuj koment i castecne podporil, ano, glsa-check je podle me velkej pruser, driv (nekolik let), sem to pouzival na desktopu zrejme podobne jak ty, proste prevazne k zaplatam a jednou za cas velkej upgrade, to uz ale bohuzel nejde :/ a nikdo z councilu ani vyvojaru to neni schopnej pochopit :/

[limit_false]

Ano, na zachování stavu před emerge je spousta nástrojů (jenže kromě molochů typu KDE je zpětný downgrade rychlejší). Akorát zrovna KDE se mi od verze 4.3 začalo celkem líbit.

Na glsa-check DB by prostě potřebovali dalšího člověka, který by se staral jenom o to. Plus musí maintainery ebuildů přesvědčit na přidání patchů, pokud na to upstream kašle.

Pak jsem narazil na broken libtool fajly (tímhle typicky trpěl X.org), revdep-rebuild (taky není chyba Gentoo, že vývojáři některých knihoven změní ABI a nezmění soname). Všechno jsem vždy uměl rychle [ou]pravit, třeba i postupně spouštením "ebuild X configure" -> úprava zdrojáků -> "ebuild X install".

Napsal jsem dokonce vlastní nástroj rev-depgraph, který v tu dobu měl korektnější algoritmus než emerge a gentoolkit pro vyhodnocování zpětných compile/runtime/postmerge závislostí (a pravděpodobně to platí doteď). Používal jsem to pro zjištění, co by se mohlo při updatu rozbít. Když to skombinuješ s SleepyGraph, tak se na to bude dát dívat real-time, protože nejdéle trvalo načíst ten graf. Příklad generovaného grafu.

Ale všechno je to jenom otázka preferencí: jedna věc je že si to umím ohnout na svůj obraz, druhá věc jak dlouho to trvá a třetí jestli se mi to vyplatí.

[limit_false]

BTW velmi velmi zjednodušenou verzi toho rev-depgraph algoritmu jsem dával onehdá jako zápočtový test na MFF pro C++ (plnou by neměl nikdo šanci stihnout za ty 3 hodiny).

"Interní" apel na Plášilovu MFF "component systems group": matchování ABI podle signatury symbolů (aka gcc/clang "manglování") místo soname mi přijde jako vynikající výzkumní projekt (odtud pochází můj rev-depgraph). V zásadě jde o dosažitelnost v diskrétním grafu, je potřeba se podívat jestli existují "hnusné" speciální případy.

[volani.webnode.cz]

Má kompilování smysl pro BFU?
Je kompilovaný OS a všechny programy rychlejší než instalace z binárek?
- Výpočetní výkon nutný ke kompilaci se dá využít jinak (boinc atd.) Navíc PC přizátěži žere více elektřiny..

Který linux má nový sw (byť neotestovaný) a snadno se přidávají/odebírají repozitáře a přitom je přívětivý pro BFU?

U LMDE se mi stávalo že přestali fungovat updaty s i jen přednastavenými repozitáři (a sw tam byl také často zastaralý)..

Ubuntu má dle mně děsně zastaralý SW a musím do něj rvát desítky externích repozitářů.. navíc se mi nnelíbí nové gnome, takže bych musel používat xfce (xubuntu), kterému mám obavu budo chybět některé funkce a nebo překosnout a ponastavit KDE4 a používat tam některé gnome aplikace..

Já měl zato že výhoda linuxu je že tam budu mít aktuální svobodný SW, ale přijde mi paradoxně že s novými verzemi svobodného software je to lepší na windows..

Tam se mi to něják nerozbijí :D, byť je pravda že packetmanagery pro windows obsahují málo SW a trpí podobnmi problémy jako repozitáře v linuxu.. :) (zastaralý SW, chybné skripty, nemožnost si naklikat v instalátoru které komponenty z aplikace chci..).

[limit_false]

Který linux má nový sw (byť neotestovaný) a snadno se přidávají/odebírají repozitáře a přitom je přívětivý pro BFU?

"Nový (neotestovaný) SW a přívětivý pro BFU" je oxymoron. Nový neotestovaný SW nemůže být přívětivý. Nejblíže k původnímu požadavku bych si tipnul že bude asi Fedora (ale je to už nějaký ten pátek co jsem Fedoru zkoušel). Pro většinu repozitářů existuje rpm, user stáhne, odklikne že to má otevřít package manager a nemusí editovat /etc/yum.repos.d ručně. Stejně si myslím, že tato varianta není pro BFU.

Já měl zato že výhoda linuxu je že tam budu mít aktuální svobodný SW, ale přijde mi paradoxně že s novými verzemi svobodného software je to lepší na windows..

To je pravda jenom s pár instancemi SW (možná Libre Office, Tor). Jednak je to dáno firemní politikou v upstreamu, druhak politikou v distribucích. U Toru se to může zdát mírně zvláštní: v Iránu/Sýrii/Číně bych si teda používání Toru na windows nejalznul (i když se musí uznat, že s windows 7 je to už mnohem lepší než kdysi; teď se o štafetu nejděravějšího běžného SW dělí Flash s Javou).

[pavlix]

Raši bych šel do RPMFusion. Leccos tam je pro Fedoru, takže i kdyby pro EL chybělo, můžu případně pomoct s balíčkováním (stejně už jsem to někomu slíbil).

[limit_false]

Díky. Všimnul jsem si, že jsem už něco z rpmfusion instaloval, protože jsem měl již naimportován jejich GPG klíč.

BTW jenom bych zmínil pro ostatní že defaultně se po instalaci RPMFusion zapnou i repozitáře s testovacími balíčky (co mi přišlo trocha neočekávané).

[pavlix]

Díky. Všimnul jsem si, že jsem už něco z rpmfusion instaloval, protože jsem měl již naimportován jejich GPG klíč.

RPMFusion nabízí neintruzivní rozšíření EPELu, který nabízí neitruzivní rozšíření RHEL klonů. Takže pokud se držíš této sekvence, tak byses měl vyhnout všem konfliktům.

Problém je v tom, že RPMFusion pro EL je dost slabý. Ale to můžem během času vyřešit.

BTW jenom bych zmínil pro ostatní že defaultně se po instalaci RPMFusion zapnou i repozitáře s testovacími balíčky (co mi přišlo trocha neočekávané).

Nahlaš jako chybu a dej odkaz na bugreport. Prosím.

[kavol]

Problém je v tom, že RPMFusion pro EL je dost slabý.

já bych řekl, že ten začíná už u EPELu ...

Ale to můžem během času vyřešit.

no to jsem na tebe zvědav :)

[pavlix]

já bych řekl, že ten začíná už u EPELu ...

Spíš je problém u epelu ekvivalentní s problémem u rpmfusion. Balíčky se dělí mezi epel a rpmfusion podle právních kritérií nezajímavých pro uživatele.

no to jsem na tebe zvědav :)

Jo ták :D. No víš, věc se má tak, já už mám skoro hotovo a chybí mi tak možná jeden balíček. A věř, že jeden balíček udělat zvládnu.

Jestli sis nevšiml, použil jsem množné číslo. Ve smyslu, kdo chce, aby mu EPEL+RPMFusion vyhovoval, tak mu vyhovovat bude :). Nestojí to zase tak moc času.

[kavol]

já bych řekl, že ten začíná už u EPELu ...

Spíš je problém u epelu ekvivalentní s problémem u rpmfusion. Balíčky se dělí mezi epel a rpmfusion podle právních kritérií nezajímavých pro uživatele.

podstatnější ovšem je, jak se dělí vývojáři -

až na konečný počet vyjímek jsou vývojáři EPELu podmnožinou vývojářů Fedory

rovněž vývojáři RPMfusion jsou až na vyjímky podmnožinou vývojářů Fedory

a ne každý z té druhé podmnožiny patří do té první ...

[pavlix]

A pointa?

[kavol]

ta je výše

[limit_false]

Balíčky se dělí mezi epel a rpmfusion podle právních kritérií nezajímavých pro uživatele.

Njn, právní kritéria jsou mor. "Nejdál" to dotáhnul Debian, kde v spoustě balíčků nahradili linkování libreadline za ubohou libedit, protože se "bije" nějaká klauzule licence tuším OpenSSL a libreadline. Tak na debianu musím dělat LD_PRELOAD nebo rlwrap (oni to už začali dávat do skriptů taky).

Asi nejkrutější "právní bordel" jsem zažil při použití komerční Qt, PyQt, pythonu a ještě nějakého kódu. Každá licence moje použití osobitně povolovala, ale PyQt licence "nefungovala" s komerční Qt licencí (teď je to už jedno, protože Qt je LGPL, tehdy byla buď GPL nebo komerční). Technicky se to nějak ochcalo, protože technicky to vždy nějak ochcat jde

BTW když si mohu udělat wish-list na pár balíčků, bylo by to:

vlc, dar (http://dar.linux.free.fr/), calc (http://www.isthe.com/chongo/tech/comp/calc/) a truecrypt. Nijak to nespěchá, zbuildil jsem si je sám (mám když tak src.rpm). U truecryptu je drobnost že se balíček nesmí volat truecrypt (licence) a calc má prasácký makefile (musí se buildit v jediném procesy s make -j 1, jinak to zhebne).

[pavlix]

Právní bordel je nepříjemnoust, ale nezpůsobují ji apriori distributoři. Ti ty licence nevymýšlejí a často ani nevybírají.

Vidím, že sis pár věcí vybuildil sám. Já taky. A všechny, které šli, jsem buď dostal do distribuce, chystám se k tomu, nebo, výjimečně, mě daný soft už přestal zajímat, tak na to kašlu. Kdyžtak když to budeš dostávat do distribuce ty, můžu ti zkusit pomoct.

Když už máš ten wishlist, bylo by dobré vědět dvě věci. Kde ty balíčky chybí a kde k dispozici jsou.

Jinak truecrypt:

TrueCrypt

Permalink of this answer

The TrueCrypt software is under a poor license, which is not only non-free, but has the potential to be actively dangerous to end users or distributors who agree to it, opening them to possible legal action even if they abide by all of the licensing terms, depending on the intent of the upstream copyright holder. Fedora continues to make efforts to try to work with the TrueCrypt upstream to fix all of the issues in their license so that it can be considered Free, but have not yet been successful.

http://fedoraproject.org/wiki/Forbidden_items#TrueCrypt

To chápu, že s tím (zatím) nechtějí mít nic společného a oceňuju to. Stejně jako oceňuju snahu situaci napravit.

Na druhou stranu...

Fedora Suggests: Avoid this software entirely.

tcplay is an independently developed TrueCrypt-compatible program under the BSD license. A tcplay package has been submitted for package review for possible future inclusion in Fedora.

[limit_false]

Wow. Platí tá čast o "poor truecrypt license" pořád? Naposled jsem ji před builděním rychle prohlédnul (odtud si pamatuji tu klauzuli o name-brandingu).

Mnoho licencí a smluv má klauzuli "my někdy můžeme zveřejnit update kdesi na lokálním plánovacím úřadě u Alpha Centauri, naleznete to v suterénu v spodním šuflíku na bývalém hajzli, který je zamčen a dveře mají ceduli 'Pozor: tiger, nevstupovat'".

Uvedeným "Alpha Centauri morem" trpí všechny smlouvy od bank, ISP/telefonních operátorů, pojišťoven, CPS certifikačních autorit, Chrome webstore...nelze se tomu vyhnout (pominu otázku jak vůbec něco takového může v nějakém "právním" státě "fungovat").

BTW klidně zapomeň na ten wishlist. Truecrypt partici přehodím na LUKS (stejně to mám jenom kvůli "zpětné kompatibilitě").

[kavol]

Uvedeným "Alpha Centauri morem" trpí všechny smlouvy od bank, ISP/telefonních operátorů, ...

všechny ne, někteří se zavazují, že ti update budou dávat na vědomí rozumným způsobem a tak, abys mohl jasně přijmout/odmítnout změnu před dalším využíváním služeb (a dokonce tak v reálu činí )

problémem spíše je "buď update přijmete nebo s váma komplet končíme"

[limit_false]

Co si tak pamatuji, dělají to banky zobrazením zprávy v internet bankingu a ještě jsem dostal mailem změny vešobecních podmínek od UPC.

Například kdysi u Volného (ADSL) jsem o změně vůbec nevěděl. Změny mají jedinou výhodu pro uživatele v tom, že může vypovědět smlouvu bez penále (do nějakých 15 dní nebo tak nějak).

U Vodafone jsem si taky není jistý jestli jsem dostal zprávu o zrušení tarifu.

[limit_false]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2183

[pavlix]

Díky, zatím jsem se aspoň přidal do CC :).

[Filip F.]

Me na Gentoo treba ze tam nejsou schopni udelat aby se sosla java, truecrypt apod. Fakt nechapu proc to neumej udelat :( Clovek nekdy spusti emerge jde spat, a rano zjisti ze se skoro nic neudelalo protoze to chciplo na takove blbosti.

[petr_p]

Za RESTRICT="fetch" distributor opravdu nemůže. Stěžujte si u Oraclu.

[#]

To jde samozrejme vyresit - http://forums.gentoo.org/viewtopic-t-497125-postdays-0-postorder-asc-start-0.html - pouzivam doted ... jinak bych rekl ze dnesni portage to uz resi tak jako tak FU a podobny, takze podle me jen kecas ...

[Filip F.]

hm to jsem neznal, bohuzel dnesni portage to neresi zrovna vcera jsem na to narazil a zase nadaval :) Zrovna u toho oraclu to jde v pohode sosnout wgetem, takze podle me by stacilo kdyby se mazlo to RESTRICT a melo by to fungovat.

[#]

Jenze ten restrict tam neni proto, ze se nekdo snazi tebe nebo me nasrat, ale protoze ma ten balik jistej typ licence ... konkretne u javy ti muzu doporucit prejit na dev-java/icedtea od verze 1.7 (7.xx) je stejne referencni a nemelo by byt potreba pouzivat oracle (zatim jsem nezaznamenal zadnej problem); u balicku jako truecrypt je to slozitejsi, holt manual fetch no (byt souhlasim neco jako "do you want to fetch manually y/n" by bodlo).

[Filip F.]

aha mno licence to je peklo, no takhle varianta me vubec nenapadla, moc ty licence technicky nechapu, kdyz je to stejne zdarma ke stazeni, nechce zadavat zadny licencni klic ani hw klic pod.....Popravde me to sralo i koupenych win softu furt to s necim buzeruje a pritom z pirate bych si to mohl sosnout casto uz cracknute primo v instalacce a nic me neotravuje s nejakym zadavanim a ctenim neceho. Takze platiciho zakaznika si firma nasere hned u instalace. Nastesti takhle zkriplenych softu pro Linux moc neni. :)

[Filip Jirsák]

emerge -a vám vypíše příznak F u těch balíčků, které potřebují manuální stažení (f pak znamená, že už máte balíček stažený). Pokud neinstalujete desítky balíčků najednou, dá se to prolétnou očima.

[Honza Jaroš]

No hlavně to ještě na předposledním řádku napíše něco jako

Fetch Restriction: 1 package (1 unsatisfied)

[Honza Jaroš]

Zpět, při prostém emerge -a to nevypíše, chce to emerge -av

[Petr "Glubo" Sýkora]

Jeste k vyse zminenemu bych dodal poukazani na parametr --keep-going, ktery je nedocenitelny prave pri velkem updatu.

[Ash]

Clovek nekdy spusti emerge jde spat, a rano zjisti ze se skoro nic neudelalo protoze to chciplo na takove blbosti.

Když něco děláte a nevíte co, tak to budete nadávat celej živoot. Není jednodušší se před spaním podívat, kolik balíčků potřebuje ruční stažení a stahnout je? Čísla kolik jich je jste si jestě všiml, a velké červené F u jeho názvu taky dost dobře přehlédnout nejde. Taky si můžete předem postahovat všechno, kdyby vám v noci nedej bože chcípnul internet. To už samozřejmě chvilku trvá, v závislosti na rychosti vašeho připojení, ale jde to, stejně jako cokoliv jiného. V Gentoo jste prostě Bůh, můžete všechno.

Ale vy asi chcete nadávat?

[kavol]

Není jednodušší se před spaním podívat, kolik balíčků potřebuje ruční stažení a stahnout je? Čísla kolik jich je jste si jestě všiml, a velké červené F u jeho názvu taky dost dobře přehlédnout nejde. Taky si můžete předem postahovat všechno, kdyby vám v noci nedej bože chcípnul internet.

no, ono je rozdíl "spustit emerge" a "spustit emerge", že?

když spustím emerge -uDN world, tak můžu jít spát - a ráno pak nadávám, že to celý vyfailovalo hned na začátku kvůli nějaký fetch-restriction

když spustím emerge -avuDN world, tak jít spát nemůžu, čumim u toho dobu, než mi to všecko spočte, pak mi to dole sice vypíše, že jsou tam nějaký balíčky k ručnímu stažení, ale to červené F stejně marně očima hledám, když je těch updatů více než malé množství, tak si to spustím ještě jednou s přesměrovaným výstupem do souboru, abych si to grepnul, další dobu čumim, pak mi to vybleje na terminál, takže zjistim, že musim přesměrovat stderr, takže znova, dobu čumim, pak to v tom výstupu teda nějak najdu, stáhnu, a už můžu pustit emerge -uDN world, a jdu spát, akorát o hodinu pozdějš, než jsem chtěl ...

Ale vy asi chcete nadávat?

zato ty asi chceš jen autora setřít, že?

[Petr "Glubo" Sýkora]

--keep-going viz vyse

[rADOn]

Nejdřív pustit --fetchonly

[aka]

Ak nevies co znamena "aka" a v akom kontexte sa pouziva, tak to slovo nepouzivaj...

[limit_false]

Generická odpověď pro Mr. Grammar Nazi: https://chzdatingfails.files.wordpress.com/2012/01/dating-fails-no-grammar-no-interest-comic-love-notes.jpg

Že tě s tím nějaká ženská/chlap odmítla?

[munich machine]

Genericka odpověď pro Mr. Know-it-all: uz mamka ma ucila, aby som nepouzival slova, ktorym nerozumiem.

[limit_false]

Učila, ale já znám všechny slova. Protože jsou obsaženy v Gödelovém univerzu a vyšších abstrakcích.

A keď už mám písať po slovensky, tak ti tam kurva chýba otáznik. Poď so mnou na pivo cicka a uvidíme jak budeš odvážny.

[munich machine]

Aky grammar? Semantika.

[limit_false]

https://xkcd.com/326/

Daj si za mna facku faktorizovanym modulom 0x959563e50382bf3a69d55491205fd36387bda1440eb5f3725cb047c93153813a7b6d87b17b111d6248fbf774fbd8074c422629038ac35d3fd7af6df3b0a3bc69.

[Ruža Becelin]

Dobrá služba na vyhledávání jak binárních tak zdrojových rpm je rpm.pbone.net

V posledni dobe jsem u RHEL/CentOS/Fedora presel na tenhle vyledavac, prijde mi, ze najde vic veci...

[#]

Rad bych se zeptal jako uzivatel gentoo neznaly problematiky; zkusil sem si vyhledat par baliku (krudsader/akregator/icedtea/jbidwatcher/rss-guard/a par dalsich) a vetsinou to dopadlo tak, ze aktualni byl kazdej v jinym jakoze-repozitri (centos/fedora/arch/slack), toto lze takto bez problemu kombinovat? nebo pak kazdej repozitar builduje s jinyma zavislostma? pokud to druhy jak se to nasledne resi?

[limit_false]

Bohužel je náhodně kombinovat nelze. To je nevýhoda binárních distribucí, ale v důsledku se týká i Gentoo.

Ve skutečnosti není ani problém, že má distribuce binární balíčky, pointa je, aby knihovna libwhatever.so.X měla vždy stejné ABI. Což obecně neplatí a nastává to i v Gentoo (viz můj komentář výše o rev-depgraph a revdep-rebuild).

Zkušenější vývojáři o tom vědí, například vývojáři větších knihoven jako Qt si na to dávají pozor.

Šlo by to vyřešit třeba závislostí na "signatuách" symbolů místo "soname" knihovny (gcc/clang stejně podle argumentů "manglují" názvy funkcí). Zdá se mi dokonce že jsem už někde viděl řešení založené na stejném nápadě (v zásadě nic složitého, prostě další grafový algoritmus dosažitelnosti).

[petr_p]

gcc/clang stejně podle argumentů "manglují" názvy funkcí

To mluvíte o jazyce C?

[limit_false]

Obecně o C, C++, Go a všem co generuje nativní kód. Akorát C nemá přetěžování funkcí, tudíž není nutné brát v potaz argumenty a ve výsledném symbolu je akorát název funkce, plus případně nějaké speciality (@plt apod.). C++ ale mangluje i argumenty, u Go nevím z hlavy.

Kdysi jak jsem dělal PhD jsem to chtěl implementovat, ale odešel jsem před dokončením.

Algoritmus velmi jednoduchý:

1. Vezme se syntaktický analyzátor kódu, rozparsuje to (je něco jako gcc2xml, zapomněl jsem název).
2. Vidíme, s jakými typy a počty argumenty se která funkce volá.
3. Seznam symbolů s parametry a typy se uvede jako závislost.
4. Při instalaci se otestuje prachobyčejným algoritmem dosažitelnosti v grafu.
5. ???
6. Profit

V zásadě dynamic linker většinu toho dělá, u C++ kontroluje "trochu" i typy argumentů kvůli manglování. Takže implementace není složitá (ale je tam pár drobností jako weak symboly apod).

[petr_p]

Já to chápu, jen jsem se podivoval nad C, protože tam se žádný name mangling nedělá (kromě verzovaných symbolů, ale to dělá linker, ne předkladač).

Váš přístup je zajímavý a kontrola signatur se skutečně používá třeba při regresních testech. Avšak není postačující. SONAME se je v podstatě verze ABI. A tudíž se má měnit i při změně sémantiky (například knihovna přestane kontrolovat ukazatel na NULL s tím, že od nové verze je to problém aplikace). Rovněž do ABI patří velikost typů a pořadí a zarovnání prvků struktur. Tohle všechno vaše technika nepostihuje. Navíc složitost by neúměrně narostla. Proto se obecně spoléhá na vývojáře, že si ABI pohlídají, a do závislostí binárních balíků pak jde už jen agregovaný údaj – SONAME.

[limit_false]

Zarovnání apod je typicky dáno architekturou a calling convention. Ale jasně že by to tam šlo doplnit. Je to už tak 5 let zpátky co jsem se tomu věnoval, nepamatuji si všechny detaily. Plus dynamický linker se pořád vyvíjí.

Ad SONAME: ano, měnit by se to mělo při změne ABI/sémantiky, na tom jsme se shodli už dávno, ale prax je, že se to obecně není pravda :-/ Vždy se najde nějaká výjimka. Počty spuštění revdep-rebuild za ty léta u mně jdou řádově minimálně do stovek, možná tisíců.

Ad nárust složitosti: nesouhlasím. Check se dělá jednou, a to při instalaci. Složitost by byla afaik nejvíce O(n) kde n je počet vrcholů v grafu se symboly. Lze vymyslet optimalizace jako např. seřadit symboly dle počtu použití. Může to být optional featura, může to dělat build server při testování nightly buildů. Je to jeden automatický nástroj navíc. Možností je spousta.

[limit_false]

V předchozím komentáři jsem se možná vyjádřil moc složitě, takže krátká odpověď:

Lze je kombinovat, ale někdy může yum protestovat kvůli konfliktním závislostem (ekvivalent "block" u emerge). Jediný nepříjemný případ je změna ABI knihovny bez změny soname - je to spíš rarita, ale občas nastane (ten příklad s vlc). Ale je úloha vyvojáře dát to správně.

Mám na SL nainstalované balíčky původně určeny pro Fedoru, Suse, atd. A šlape to.

[Mustafa]

Gratuluji, jeste dasich 9 let a prejdes na operacni system. Nekomu to trva dyl no