Názory k článku
Gentoo má nové profily 17.0
-
FíkZlatý podporovatelmyslím, že právě naopak, t.j. pokud máte hardened s PIE, pak nejsou potřeba:
If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps... -
No, ono je to právě naopak. V newsce píšou doslova toto:
If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:Hardened profil používá implicitně GCC se zapnutým PIE, takže ty speciální kroky se mě netýkají, pokud již klasický hardened používám (pro kontrolu viz gcc-config -l, pod profilem hardened). Ve všech ostatních případech to řešit musím, což mě osobně velmi točí, protože už jsem dost strojů přeložil novým GCC a teď to můžu dělat znovu.
-
No, sám jsem na to zvědavej u mě. To zase bude knfliktů a keců. Zase budu odebírat balíky a ručně je přidávat zpět, než se systém uspokojí s momentálníma verzema... ALe to není přechodem z 13 na 17, ale mojí neschopností dělat update přiměřeně často... :-)
Na x86 mi to teď visí ve stavu, kdy padá kompilace něčeho kvůli přítomnosti jednoho balíku. Když ho odeberu, zkompiluju to, ale některý balíky ho potřebujou... Ale co, zase je s Gentoo sranda :-D
Nejvíc srandy jsem si užil, když mi to svorně tvrdilo, že perl nový verze nelze nainstalovat kvůli závislostem na sobě samotnym. Unmerge starý verze a při merge nový už přišel ten novej perl a bez keců. Problém? Nikde. Čas strávený všelijakými pokusy a rekompilacemi? Raději neměřit :-D
-
Jo jo, upgrade PERLu je opich. Iterativně jsem dospěl k následujícímu postupu:
1) upgrade perl-cleaner (emerge -1 perl-cleaner)
2) emerge perlu bez závislostí (emerge -1 --nodeps perl)
3) rebuildnout vše, co na PERLu visí (perl-cleaner --reallyall)V drtivé většině případů tento postup konverguje k výsledku velice rychle.
-
zs (neregistrovaný)
PIE ma vyrazne negativni efekt na vykon 32bit x86 aplikaci, napr. https://nebelwelt.net/publications/files/12TRpie.pdf
IP-relativni adresovani je nativni az u amd64. Nenapada me ted jina vyhoda PIE (nemyslim PIC u knihoven) nez moznost ASLR, coz je pro potencialniho utocnika jen mensi prekazka (google ASLR bypass).
Gentoo pouzivam na starsich strojich v 32bit modu. Pokud uz nepujde pouzit nopie/nossp USE, budu asi muset vytvorit lokalni overlay nebo patche... no jsem zvedavy. Radost mi kluci neudelali. -
peterffffff (neregistrovaný)
Varuji vas pred tymto linuxem. Mnel jsem ho nainstalovan na notebooku, myslel jsem ze uz nebudu muset nikdy instalovat na tenhle stary notebook jinej OS, ze notebook dozije spolu s gentoom. Asi po 2 letech jsem dal gentoo updejtovat - aktualizovat cely system pres portage, a samozrejme se vsechno dosralo. Kompletne neopravitelne znefunkcnen system. Mozna v minulosti to pekne fungovalo ale ted uz ne.
-
Trupik (neregistrovaný)
Gentoo máš jednoducho aktualizovať častejšie. My aktualizujeme každý týždeň a aj inštalácie z roku 2006 nám ešte stále fungujú a sú na najnovších verziách balíčkov. Niekde nám zákazník prestal platiť, tak sme neaktualizovali, a po pol roku pokus o aktualizáciu dopadol tak ako si popísal. Treba to proste robiť častejšie a ak sa Ti nechce, tak Gentoo nie je pre Teba. To nie je chyba, to je vlastnosť.
-
brk (neregistrovaný)
Ty máš fakt Gentoo u zákazníku na serverech? Doma ho mám 12 let a líbí se mi, jak to je "gumové". Někdy to chce trošku času, ale jsem si to schopen přihnout tak jak chci. Pěkná hračka.
Gentoo sice není žádná rychlokvaška a stable balíčky tam jsou často starší než u distribucí s pevným vývojovým cyklem, ale stejně bych si to do produkčního prostředí asi nedovolil nasadit. Pořád na tom řeším víc problémů i než na Ubuntu LTS server a o SUSE, RHEL, Debian stable, ... ani nemluvě.
-
Trupik (neregistrovaný)
Nie "mám", ale "máme" - nie som v tom sám. Prešli za dobu existencie firmy rôznymi derivátmi Redhatu, Suse, Debian, Slack a nakoniec sa ustálili takmer univerzálne na Gentoo. Keď máš viac strojov, tak máš možnosť aktualizácie vyskúšať vopred na nejakých menej dôležitých serveroch. Už si ani nepamätám, kedy naposledy bol nejaký problém, že by sa niečo aktualizáciou rozbilo - je potrebné čítať upozornenia z emerge a eselect news a riadiť sa nimi. Za 12 rokov by si aj pri použití Debian LTS musel už 2-3 krát preinštalovať celý stroj. S Gentoo ani raz.
-
mhepp (neregistrovaný)
S tím přeinstalováním Debianu bych polemizoval. Pár serverů instalovaných v té době (12 let zpět) stále mám a jsou na aktuálním stable bez problémů. Také desktop v práci mám asi 7 let bez přeinstalace, to mi tam běží Debian unstable a aktuálně běží již na třetím počítači (vždy vytáhnu disk za starého, dám do nového a rsyncnu systém na nový disk).
Spíš by mne zajímalo, o kolik serverů se takhle staráte a jestli na všech strojích děláte pořád upgrade systému ručně. Ptám se proto, že my jsme agresivně sjednotili všechny systémy na Debian stable a ve výjimečných případech na Centos právě kvůli automatizaci údržby serverů. Serverů takhle máme nižší tisíce v jednom systému automatizace a vyšší desítky v druhém systému automatizace.
-
j (neregistrovaný)
Proc ne? Mam takovych serveru par taky - beznej ostrej provoz. Narozdil od binarnich dister nemusim resit, ze se celej system podela pri upgradu. Coz je presne priklad blbuntu a dalsich.
Navic kdyz neco nekde zmeni chovani, a je treba to prenastavit, je to jedna vec, a ne vsechno najednou.
-
mhepp (neregistrovaný)
S mnoha distribucemi mám špatné zkušenosti při upgradu ve stylu staré LTS na nové LTS. U Debianu rozbití při aktualizaci byl obvykle způsoben tím, že správce systém svojí neschopností/nezkušeností/neznalostí totálně doprasil. Jinak upgrade vždy proběhl bez obtíží, obvykle až na pár zastaralých voleb v konfiguraci a podobně. Debian je totiž intenzivně laděn pro hladký upgrade.
-
Filip JirsákStříbrný podporovatelGentoo je distribuce pro lidi, kteří se v Linuxu vyznají. Ti pro linuxovou distribuci nepoužívají označení „tento linux“, a hlavně vědí, že Gentoo je distribuce určená pro průběžnou pravidelnou aktualizaci. Holt vám s Gentoo někdo špatně poradil, pro aktualizaci jednou za čas je potřeba používat distribuce, které jednou za čas vydávají novou verzi (třeba CentOS nebo Ubuntu). Ale pokud ten počítač je připojený do internetu, je potřeba i v takových distribucích instalovat alespoň bezpečnostní aktualizace.
-
tomas (neregistrovaný)
gentoo rules
jako naprosty novacek, netusic co je kernel jsem s tim pred ~ 15ti lety zacinal
a diky gentoo jsem se naucil vetsinu veci, veci ktere na "normalni" distribuci nepotkate, neresite.
takze za me gentoo je i pro naproste novacky, nicmene ty, kteri to mysleji vazne, maji chut badat a zkouset, poznavat -
Mám inštaláciu gentoo z roku 2007, ktorú používam na všetkých počítačoch (upravené march podľa potreby). Aktualizácie robím prevažne skriptami. portage a distfiles mám spoločné na serveri, slabšie stroje využívajú výkon servera cez distcc. Kompilácia nie je problém, kľudne pri nej dokážem pracovať. Na strojoch mám väčšinou 16GB RAM, takže aj kompilácia je celá v RAM a nemám žiaden problém.
Keď vieš ako narábať s Gentoo, tak to ide takmer samo a bez problémov. -
Ja tvoji poznamku chapu, pokud by sis prostudoval zaklady systemu, tak bys pochopil, cim je tato situace zpusobena a take zjistil, jakym zpusobem aktualizovat stare instalace.
https://wiki.gentoo.org/wiki/Upgrading_Gentoo:
Plus mas k dispozici i navod na to, jak aktualizovat hodne stare instalace :-)
https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Updating_old_systems -
Přezdívka: (neregistrovaný)
Přesně. Po dvou a více letech? To jsou situace, kdy už je výrazně snazší, levnější a bezpečnější celé Gentoo nainstalovat na jiný HDD (v chrootu, virtuálu) od základu znovu a pak přenést jen konfiguraci.
Ale ze zkušenosti, dá se updatovat i po cca 1/2 roku, ale už je třeba být opatrnější a obrnit se trpělivostí. Příp. být připraven na masivní emerge -C (zvláště grafická prostředí) a postupné vracení balíčků...
Zrovna teď aktualizuju jeden stroj (jednu z instalací serveru, která slouží jen jako betatest než se pustím do ostrých) naposledy aktualizovaný 08/2017 a stále ok, bez potíží, jen těch balíčků je hodně.
-
Jel jsem na gentoo celých 15(??+-) let. Na desktopu, a několik let na serveru. Zlatej systém. Zejména ze v začátcích kde byl každej kompilací získanej tik procesoru znát a jiné distribuce nenabízely některé softvéry a tak je bylo nutno tak jako tak kompilovat...
Ale doba pokročila, já jsem zase o něco zestárnul, a nejak mě začalo štvát právě to spravování po každým updatu. Ano, updatoval jsem kolikrát klidně i po půl roce, ale doteď to tak nějak šlo. Jenže ona se nabalovala celková složitost, počet use flagů (kolik jich má teď vlc?), zastaralé balíky a, ano, chyby. Takže naposled když jsem naposledy zase upgradoval. Dopadlo to přesně jak popsal autor.
Přesedlal jsem na desktopu na arch a jsem více-více-méně spokojen.
Na serveru bych zůstal u gentoo.
-
Uz jsem nekolikrat zatim neuspesne :-) (skoncili jsme pouze na urovni debat na foru nebo irc), a nejenom ja, rozjizdel iniciativu, jak udelat z Gentoo binarni distribuci pri zachovani vsech vyhod, ktere gentoo dava.
Slo by to to navrhnout a provozovat nejakou globalni infrastrukturu, ktera by uzivatelum poskytovala predkompilovane binarni balicky dle jejich konfigurace (config fingerprint).
V zasade jsem se dostali vzdy pri debatach na takovyto postup
1. Anonymne zacit sbirat konfiguraci systemu (installed packages a cely obsah /etc/portage)
2. Nasledne rozparsovani techto dat a vyhodnoceni, ktere sestavy jsou nejvice pouzivane. Aby se proste nekompilovaly jen dummy vsechny mozne kombinace.
3. Zacit provozovat online distcc clustery, ktere by kompilovaly package podle skoringu do queue podle sebranych konfiguraci z bodu 1, vysledky by se ukladaly na binarni host.
4. Pokud jdu nasledne kompilovat, tak muj lokalni system online zjisti jestli je balicek pro moje sestaveni (CFLAGS, USE flags, etc.) k dispozici v binarni forme, pokud ne, tak ho budu kompilovat zaroven lokalne i za pomoci volnych zdroju distcc klusteru. Samozrejme nektere package toto neumoznujou, takze by dochazelo k automatickemu failover kompilovat jenom lokal, nebo jenom remote. V druhem pripade by uzivatel cekal, az bude balicek k dispozici pres globalni binhost. Samozrejme pouziti PKI a symetrickych sifer pro komunikaci a sifrovani dat apod.
5. Binhost by mel funkci offline replikace. Aby si lide mohli provozovat na svych sites svoji instanci, ktera by pouze synchronizovala balicky z globalniho hostu a poskytovala je lokalne serverum bez moznosti internetoveho pripojeni, neco jako Nexus pro java nebo docker images, etc.Dost jsme resili bezpecnost a asi jednim takovym predikatem, ze je nemozne aby, lokalni uzivatel neco kompiloval a pak to sdilel do binarniho hostu. Vsech nabizeno na binarnim hostu by musela byt pouze produkce zabezpeceneho distcc clusteru pod kontrolou Gentoo komunity.
Jelikoz vidim, ze je tu spousta Gentoo uzivatelu, tak se ptam, jestli by nekdo nemel zajem na tomto experimentovat. Ja mam v soucasne chvili asi 248 jader pro distcc v privatnim DC.
Ted jsem se dostal k instalaci na Dell XPS 13 a opet jsem plakal. Ale i na serverech by to instalaci urychlylo.
Pokud by mel nekdo zajem, tak se mi ozvete: archenroot {at} gmail {dot} com
-
Trupik (neregistrovaný)
Možno nie som úplne objektívny, lebo gentoo používam už len na serveroch, ale podľa mňa by si to mnoho používateľov nenašlo. Možno pred 10-timi rokmi na jednojadrovom Celerone by som to využil, ale dnes je väčšina vecí zbuildovaných do 10 minút. Kto to pociťuje ako problém, použije binárnu distribúciu, alebo distcc.
Aj realizovateľnosť by bola otázna - kompilovať všetky kombinácie USE-flagov? Balíky s mnohými nepovinnými možnosťami ako Apache, PHP, či mplayer, majú aj 80-90 USE-flagov. To je 2^80 kombinácií, čo je astronomické číslo. Keby kompilácia PHP zabrala len sekundu, a mal by si milión strojov, ktoré by to touto rýchlosťou kompilovali, aj tak by trvalo miliardu rokov, než by to dokončili.
-
Diky za feedback. Ohledne kombinaci. Proto je tam prvni krok sber lokalnich konfiguraci
1. budou se pouze kompilovat kombinace, ktere uzivatele chteji
2. dale by se u nektery packages, nebo use flags dala tato remote funkce uplne vypnoutChapu, ze se bavime v nekterych pripadech o astronomickych cislech.
Ja zas pouzivam Gentoo i na serverech, desktopech a laptopech. Gentoo komunita investuje hodne casu do dekstopu nejruznejsich typu a prave tychlost nahozeni si myslim, by mohla pomoci alespon trochu adopci novych uzivatelu.
Distcc asi v server prostredi ano, v desktopu, laptop hure. Jde take o to, ze by si system dokazal zjistit, jake package se musi buildovat lokalne, jake napr. jen s MAKEOPTS=-j1, apod. a vlastne by dochazelo i k ladeni packages na pozadi.
Ten sber konfiguracnich dat by mohl byt vyuzit nejenom pro tento napad, ale dal by zpetnou vazbu Gentoo councilu o pouziti systemu, architektur, konfiguraci (chapu, ze ne vsichni by to tam posilali, protoze proste systemy nemaji zadnou internetovou konektivitu napr. v produkci, nebo to lide nechteji). Minimalne ten sber dat mam uz kompletne navrzeny s REST API backendem.
Dalsi pozitivni vliv vidim automaticke generovani bugu na nejakem centralnim build clusteru.
Diky za pripominky.
-
Trupik (neregistrovaný)
Rozumiem - všetky kombinácie nie sú potrebné. Na prvýkrát som to nepochopil, aj keď si to tam písal už predtým. Mno, na notebooku tá kompilácia desktopových balíkov asi nie je bohvieaká zábava. Spomínam si, že som kedysi dávno práve na tom Celerone kompiloval Openoffice, trvalo to asi osem hodín a na konci som dostal hlášku, že došlo miesto na disku. :)
-
Dalsi vec je, ze by se nesestavovaly baliky po vsech use flags, ale po groups of flags.
Firefox-bin a firefox (source) nemaji stejne use flags, tj. ani dnes Gentoo nenabizi binarni balicek presne pro konkretni sestaveni, ale spise ve smyslu, dostanes skoro vsechno. To same se da udelat pro apache, ffmpeg. Cimz opet cela komplexita klesa.
Pozn: Ale stale plati, ze tu nejde o naplneni vsech kombinaci, ale pouze o ty, ktere uzivatele opravdu pouzivaji.
-
Jeste doplnim, situace, jdu kompilovat napr. Apache s nejakym setem use flags. portage posle dotaz, zda sestaveni existuje jako binary, pokud ne, necha ho na remote clusteru sestavit a je mi dodany jenom binarni balicek. V nekterych pripadech se ten binarni balicek nemusi na centralnim binhostu ani ukladat, protoze prave vystupem muze byt velky pocet kombinaci. takze se to jenom bude kompilovat on-demand.
Ten prinos je v tom, ze globalni distcc infrastruktura by byla uz odladena. Kdokoli delal na ruznych architekturach distcc (powerpc, arm, x86), tak snad uzna, ze kazda unikatni konfigurace prinasi sve vlastni problemy, ty jsou vyreseny, ale znalosti jsou ztraceny, resp. nedostupne pro ostatni po svete. To je dalsi prinost. Tech prinosu je tam skryto opravdu vice, nez to na prvni pohled vypada.
Dale treba ikdyz nechces nebo nemas ze serveru pristup na internet. Mohl bys si komplet konfiguraci vykopirovat z globalni pro svou lokalni instanci. Nebo naopak rucne nakopirovat svoji lokalni zpet, pokud jeste neexistovala.
-
Filip JirsákStříbrný podporovatel
Jeste doplnim, situace, jdu kompilovat napr. Apache s nejakym setem use flags.
To ale přece nestačí. Závisí to ještě na kompilačních závislostech, jejich verzích a na tom, jaké mají nastavené use flagy, a stejným způsobem to mohou ovlivnit i tranzitivní závislosti. -
Jak nestaci? psal jsem, ze portage sebere a provede tzv configuration fingerprint, tj. cluster vi, jake se maji buildit verze. Opravdu by slo vlastne o nejakou sluzbu distcc, samozrejme by tam byl nejaky wrapper pres http, ktery by fungoval asi takto:
RX(input) - lokalni konfigurace bud kompletni /etc/portage obsah, nebo jen vystup z konkretniho volani emerge na specifickou package
TX(output) - jeden,nebo vice balicku v binary -
Filip JirsákStříbrný podporovatel
Obávám se, že když se udělá otisk z použitých use flagů a nainstalovaných verzí knihoven, bude každá instalace unikátní.
-
Nejsi sam, kdo ma takove obavy, ale jelikoz v tuto chvili nelze rici, jestli jsou nebo nejsou opravnene, jedna se pouze o spekulace, resenim, ktere by si na celou problematiku rozsvitilo, by byl prave sber konfiguraci od uzivatelu behem nejake doby (3-6 mesicu) a nasledna analyza. To je krok jedna, ktery jsem popisoval, pouze jeho vystup muze v nejake mire ukazat dalsi indicie vedouci k validaci reseni. Tak to vidim ja.
Tato prvni faze by znamenala celkem trivialni rozsireni portage a postaveni serverovych API a navrhu databaze (nosql, graphdb).
-
Nektere debaty, ktere jsem nasel jsou stare i 10 let, a ja sam jsem se k financovani v diskuzich ani jeste nedostal, ale samozrejme, ze to samo o sobe muze byt blocker. Zatim jsme se vzdy bavili o konceptu jako takovem a use cases, kdy by se takovy system hodil, a jestli je ten prinos pro konkretni use case byl vyznamny.
Z pohledu financi na vypocetni infrastrukturu jsme se bavili na foru, nebo irc i o tom, ze by uzivatel nahodil klienta, a cluster by byl vlastne slozen z uzivatelskych stroju. Koncept distribuovanych vypoctu boinc. Jenze tento koncept ma znacna bezpecnostni rizika, tj. ja ti poslu kod ke kompilaci a ty mi do toho zkompilujes jeste backdoor a binarku mi vratis. Diskutoval jsem i reseni v techto pripadech, ale bylo by to neumerne narocne na vyvoj.
Proto jsem zde psal jen moznost centralniho clusteru pod kontrolou Gentoo. Takze celkove financovani taky nevim no... Proto to strilim do sveta a diky za nazory, ktere ukazuji, jestli je ta myslenka validni a/nebo realizovatelna.
-
Jen rozvedu trochu ten koncept s uzivatelskou siti nodu.
Samozrejme zadne rozumne cesty jak zverifikovat zdroj vs binarku neexistuje, jelikoz se jedna o one-way process (prevazne). Jedina varianta schudna z pohledu zabraneni nutnosti navrhnovani nejakych komplexnich zasifrovanych sandboxu a izolaci v ramci klienta by mohla byt, ze pokud by sit byla velka (napr. 1000 uzivatelskych stroju), tak by se kompilace provadela nahodne na minimalne dvou strojich. Nasledne by se porovnaly otisky zdroje i binarek z obou stroju a pokud by sedely, tak by clovek dostal vystup.
V pripade, ze by se binarka neukladala, tak by se na serveru minimalne ulozil jeji otisk, tzn. pokud nekdo v budoucnu pozada o produkci stejne binarky, uz se bude kompilovat pouze na jednou, protoze otisk uz existuje.
Takovyto pristup by byl z pohledu narocnosti na vyvoj rozhodne jednodussi nez se snazit kompilacni process izolovat jak na urovni os, tak nejakych sifrovacich technik apod.
-
Tohle jsou detaily, ja to tu primarne postoval, pokud by mel nekdo zajem na tom spolupracovat, tak at se mi ozve do emailu.
Spousta veci, ktere uz jsem navrhnul tu vubec nepopisuju...
To, co zrovna popisujes souvisi s urcitou entropii v systemu, abych se snazil tyto moznosti eliminovat, tak napr.:
1. nody pouzite v prvnimu batchi nesmi byt vubec pouzity v druhe vlne. Toto jde granulovat i na uroven chunku (podmnozina setu, pozor set muze byt i jen jedna package), tj. chunk je vicemene soubor nebo set souboru
2. Lze nastavit nejenom 2 ale napr. 10 parallelnich kompilaci pro zvyseni bezpecnosti
3. Je to o kompromisech, takze napr. by se akceptovaly 2 iniciacni kompilace pro overeni bezpecnosti binarky, ale provadela by se zpozdena post-quality kontrola, kdy by se zpozdenim nekde na slabsim Gentoo managed serveru byla fronta a tam se packages jeste znovu overovaly, pokud by ale zde vylezl problem, tak uz ma uzivatel chybu/diru na systemu, coz asi neni uplne koser, ale taky to otevira otazku, jak ho o tom informovat. Take by to muselo generovat problem s node, ktery je podezrely s poskozeni (to muze byt zamerne, ale i nezamerne)......Takze je to hodne komplexni... diky za poznamky
-
Ja jsem si zrovna ted o vikendu postavil mobilni server (chci to narvat do dr zaber sentry case) zalozeny na 18 jadernem (36threads) E5-2697 v4 (sehnal jsem ho za 13 tisic korun LOL, ES verzi teda ). Kompiloval jsem si tam plasma-desktop. Ani ne plnej plasma-meta balik, a i tak to trva proste dlouho. Ja uz dnes instaluju gentoo pres jeden pulstrankovej slozenej prikaz :-), abych u toho nemusel sedet, ale z meho pohledu je stale 10 minut na package hodne...
Samozrejme si tady identifikoval krasnej priklad na package qtwebengine, qtwebkit, ktera by byla dobra v binarnim formatu. Jde o to, ze soucasne binarni balicky nepodporuji stejny use flag selection. ma taky malo use flags napriklad oproti ffmpeg.
Cela tahle moje iniciativa je zalozena na predstave dostat full desktop install ready do jedny hodiny max. A slo by o kombinaci dostupnych balicku binary s vykonnym compilacnim clusterem. Ja sam jsem treba ochotnej na to dat nejakou infrastrukturu do zacatku a sponzorovat to i par tisicema mesicne. Ale chtelo by to vic lidi, ktery by projevili zajem na tom hlavne pracovat. Nemam na to casove abych z toho udelal one man show i z duvodu rychlosti dokonceni.
-
To nabyva pouze z tveho pohledu kterym pozorujes celou moznou komplexitu systemu. To ale neni problem,. protoze vysledek nebude tak komplexni jak si ho predstavujes, viz opet bod 1. Ten system se vubec o komplexitu a jeji pocitani snazit nebude. On je proste uplne stateles, ceka jaka moznost v systemu nastane v okamziku, na ni reaguje a jde dal. Pouze zaznamena otisk konfigurace systemu a otisk vysledne binarky, pokud ji nema ulozenou. V nekterych vybranych pripadech jako (gcc, qt, nebo graficke aplikace, office, ) se budou ukladat i binarky, ale v plne source konfigurable ceste.
System dela, jen co se po nem chce, ne ze se pripravuje na vsechny moznosti.
Ja mel vzdycky rad diskretni matematiku, ta ukazuje krasne, jak jsou nase dnesni procesory jen naprosto nevykonne sroty :-))) ber me s rezervou, nebo taky ukazuje ze byt pripraven na vsechny mozne situace je ve vesmiru nemozne a musime hledat jine cesty
-
# (neregistrovaný)
Jako fajn, ale neni tady trosku problem toolchain a kombinace stable ~ a pripadne masked? To by imo pak chtelo mis spoustu chrootu s jinyma kombinacema toolchainu, a tyto veci se meni hodne casto.
Dalsi apekt jsou balicky z overlay a taky mam samozrejme naky lokalni balicky - tim nerikam, ze by to mel ten system resit, limitace na main gentoo repo je zrejme ok, ale pokud bude mit clovek z overlay cast toolchainu, tak to zrejme problem bude.
-
" To by imo pak chtelo mis spoustu chrootu s jinyma kombinacema toolchainu, a tyto veci se meni hodne casto."
Ja to vidim jako serverless architekturu, funkce existuje jenom jako definice, ktera nema instanci. instance se stvori jakmile nekdo funkci potrebuje s jeho konfiguraci, jakmile je funkce provedena, instance se znici. Nektere vystupy se mohou ulozit jako metadata/results. Tak ja si umim predstavit nejaky generator base image na zaklade analyzy portage, resp. umi sestavit jakoukoli kombinaci s tim, ze aby to bylo rychle, tak by pokud mozno byly tyto zakladni bloky uz jako binarni bloby k dispozici. Opet jelikoz diverzita muze exponencialne narustat se to bude dat konfigurovat (napr. binary pokryvame jen amd64 a ostatni architektury jen on demand creation.
Ten koncept stejne jako s toolchain je uplne stejny jako s vlastnima balickama, nechci vytvaret system,ktery zna vsechny kombinace, resim vzdy jen tu konkretni, kterou nekdo pozaduje, bud k ni uz mam metadata predem nebo i binarni balicek, jelikoz to uz nekdo zadal drive, nebo nemam a po sestaveni ze zdoju on the fly ulozim urcite metadata a na zaklade nejakeho skoringu rozhodnu, jestli ulozim i binarku. Skoring nemam jeste uplne navrzeny, ale vicemene velke package by mely byt v binary. Take se bude ukladat, kolikrat nekdo chtel nejake konkretni sestaveni. Pokud uvidim napr. ted dummy scenario, ffmpeg am hodne use flagu:
ffmpeg - useflag1 useflag2 - zadano 300
ffmpeg - useflag1 -zadano 1Tak muze skoring ovlivnovat i tato informace, kdyz vic nez 300 lidi, uloz i binarku, ne jenom metadata (fingerprint, apod.)
-
"Dalsi apekt jsou balicky z overlay a taky mam samozrejme naky lokalni balicky - tim nerikam, ze by to mel ten system resit, limitace na main gentoo repo je zrejme ok, ale pokud bude mit clovek z overlay cast toolchainu, tak to zrejme problem bude."
Podobne napsal Filip Jirsak vyse:
"Obávám se, že když se udělá otisk z použitých use flagů a nainstalovaných verzí knihoven, bude každá instalace unikátní."Oba tyto predpoklady jsou spekulace nepodlozene nicim. Abych mohl uvazovat podobne situace, proto je potreba nejdrive provest krok 1, zacit sbirat anonymni konfigurace systemu, naladovat je do nejaky nosql/grafove databaze a provest nad nimi analyzu, co se bude sbirat jsem jiz uvedl (ted to trochu upresnim):
- kompletni obsah /etc/portage
- emerge --info a/nebo emerge world -ep
- instalovane overlays (layman)Tohle bych videl jako takovou prefazi, ktera by bezela treba pul roku nebo rok a data by se prubezne analyzovala. Opet spis poukazuju na to, ze vysledek takoveho sberu dat by mel spustu jinych uzitku
-
Trupiku, jeste to sem postnu nejak trochu jednoduseji, ackoli jsem to psal nize.
Ta tvoje uvaha je matematicky spatne, resp. sedi jenom jako cista kombinatorika, ale zde musis vysledek namapovat na dostupne instance. Instance je jeden Gentoo system running na planete zemi.
A s otisky se to ma takhle
Otisk configurace v case = jedna gentoo instance
Otisk configurace se muze menitOtisk configurace ma zavyslost 1:N k otiskum produkovanych binarek.
Realny pocet otisku, o kterem se bavime, je z meho pohledu radove mensi a nema co delat s kombinacemi, ktere uvadis. To realne cislo bude daleko mensi, rekl bych ze smesne :-) co rikas?
Ale diky za feedback, pokud se ve sve uvaze pletu nejak, dej mi prosim vedet.
-
Trupik (neregistrovaný)
Tvoja úvaha o počte kombinácií je správna, moja bola chybná. Nie sú potrebné všetky kombinácie, len tie, ktoré niekto reálne používa, pričom reálnych používateľov celkom určite je omnoho menši než 2^80.
Vyzerá to tak, že táto myšlienka na vzdialene kompilované Gentoo Ťa neopúšťa. Najlepší liek na takéto "svrbenie mysle" IMHO je začať myšlienku realizovať. Nepýtať si povolenie na Gentoo fóre, ale proste pustiť sa do toho. Držím palce, aj keď cieľovou skupinou asi nebudem.
-
Diky za konfirmaci, protoze uz jsem z toho taky nekdy zblblej a nevim, ktera bije :-)
No uz jsem v kontaktu s Gentoo devs, ze bych se stal taky Gentoo dev, protoze bych rad dostal AI frameworky do hlavni vetve.
Prvni krok bude naimplementovat odesilani anonymnich konfiguraci na nejaky centralni server pres REST API, oni se budou sbirat 3 otisky ke 3 kontentum:
- emerge --info | sha512sum
- find /etc/portage -type f -exec sha512sum {} \; | sort -k 2 | sha512sum
- eix-installed -a |sha512sumPOZN: Kazdy request bude mit unikatni fingerprint systemu:
dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g' |sha512sumNejdrive se odeslou na server jenom tyto fingerprinty, server odpovi, ze je budto zna (a incrementuje pouziti, pouzije fingerprint systemu, aby to byli jen unikatni requesty), pak se nic nedeje, nebo odpovi, ze je nezna, na to portage reaguje tim, ze dodatecne odesle cely kontent ale pouze k neznamemu fingerprintu. Tim se zefektivni a zrychly cely proces eliminaci posilani dat, ikdyz nejsou potreba.
Cele se to bude ridit promennou v /etc/portage/make.conf:
SHARE_ANONYMOUS_USAGE_STATISTICS="yes"Mam hotovy prototyp ciste v pythonu (klient), backend REST API jsem vyvinul v Jave (SpringBoot, Spring Data Rest a JPA), backend je MongoDB (nosql document databaze).
Takze doufam, ze do tohoto programu se take zapojis. Tyhle informace se budou dat vyuzit na kouncilu ohledne preferenci napr. nebo priorit ve strome balicku.
Ted budu muset vyjednat integraci do portage a zjistit, kam vydeployjovat ten backend, kdo tobude managovat, apod.
No a az toto pobezi treba pul roku a nasbira "dost dat" (co to vlastne je dost dat???) :-), tak se bud ano, nebo nepustim do toho open clusteru.
-
Presne, kdy se ta informace bude sbirat, resp. kam vsude umistit trigger, v tom jeste nemam jasno. Mozna, ze ji sbirat i pred i po akci nad lokalnim systemem. Z pohledu statistik se jevi jako vhodne ji sbirat PO dokonceni nejake akce jako result.
Pokud se v dalsi fazi rozhodneme to pouzivat a implementoval bych tu myslenku open clusteru(pominu ted problemy s bezpecnosti apod.), tak ta by se stejne asi aktivovala pres jine prepinace v make.conf, napr. USE_SHARED_PORTAGE="yes" (fakt jen priklad), takze tam se tato data musi sbirat PRED vykonanim prikazu, protoze by se pozadavek posilal prave na backend a zjistovalo se tam, jestli to backend zna, jestli ma volne zdroje, apod. jestli s tim a jak muze pomoci.
-
Ale v pripade open cluster bude muset bezet neco jako portage deamon, ktery si otevre dvousmernou komunikaci pres https, nebo websocket, aby mu mohl server posilat pozadavky, ktere bud klient zamitne, nebo ne. Bude to chtit robustni konfiguraci. Napr. ze nebudu kompilovat pro ostatni, pokud moje CPU nad 60%, nebo pocet jader ktere budu sdilet, nebo limit cpu loadu, nice level. Cilem neni zastavit klientsky pocitac, ale nechat uzivatele nastavit, kolik ze svoji kapacity by byl eventuelne ochoten sdilet.
Premyslim, ze bych si vzal sablonu z projektu BOINC, to mi prijde asi jako nejblizsi myslenkove....
-
martin-ux (neregistrovaný)
Ja si neviem predstavit ako udrzat bezpecnost v tomto projekte.
Kto podpise/overi, ze ten binarny balik je spravny ? Odmyslim si vsetky baliky a zoberiem si na musku len gcc.
Kazda noda v clustri musi byt trusted, tj, pre dany kod a flagy musi existovat fingerprint vystupu. Pri rovnakom gcc (POZOR: a jeho zavislostiach , tj. tools + libs (a tie mozu mat opat svoje flagy)) a gcc USE flagoch je to mnoho kombinacii.Argument moze byt, ze pri danom release ma vacsina uzivatelov rovnaky setup. Dajme tomu. Kto ale podpise kod pre dany gcc setup ? Jedine trusted servre v clustri. A to mozu byt len gentoo servery. Tj. pridavat cudziu nodu do clustra je obrovske riziko - nemas ako overit blob ktory poskytol je spravny. Jedine tak, ze trusted cluster to skompiluje sam. Lenze potom uz nepotrebujes tu cudziu nodu -- balik je uz skompilovany. A jednorazovo, ze cudzia noda dodala spravny kod nic neznamena.
Ten, kto potrebuje binarne baliky by asi presiel ku klasickej distribucii ako je debian.
-
Ten system bude operovat na otisky konfiguraci, on se nesnazi komputovat vsechny moznosti, jak napr. nekdo uvadel viz vyse ze mame 2*80 kombinaci pro apache. Ale to neni pravda! Takova uvaha je spatna, protoze pocita, ze mame k dispozici 2^80 pocitacu, kde je nainstalovat, ale my je nemame, to same plati pro kompilaci jakychkoli balicku. My jsme limitovani realitou, coz je v tomto pripade dobre. Takze veskere uvahy co do poctu instanci moznosti jsou omezene poctem instalaci Gentoo :-)))
Ad bezpecnost i toolchain libs uz diskutujeme viz vyse....ale kratce
Kombinace use flags (genericky na urovni jakekoli package, nezajima me toolchain, apod. to je vsechno jen package).
Ty vidis nutnost pokryti vsech kombinaci, ale to neni realita. Ty mas pouze jednu kombinaci v case a zadas system aby pro tebe udelal nejake operace:
1- dej mi binarku jestli ji mas pro moji kombinaci
2- zkompiluj ji pro me nezabezpecene,tzn. nekdo uz prede mnou kompiloval stejnou kombinaci, ale server neukladal binarku (na zaklade konfigurace), ale ma ulozeny otisk binarky. Takze open cluster zkompiluje v jedne instanci a server overi vysledek otiskem.
3- zkompiluj ji pro me zabezpecene,to znamena, ze pro server je tato kombinace uplne novaAd 3 - to je varianta ohledne zabezpeceneho procesu.
Jeden z konceptu je, ze poprve se neznama konfigurace zkompiluje paralelne, vzdy na jinych, nebo jine kombinaci nodu (2, nebo 3? independent kompile procesy minimalne). Vysledky (binarka a logy) jdou na nejaky gentoo server, a pokud jsou stejne, vytvori se otisk a binarka se preda klientovi. Backend dodatecne rozhodne, zda ulozi jen otisk binarky, nebo binarku celou (podle skoringu). Pokud nejsou otisky stejne, klient failoveruje do lokalniho kompile modu automaticky, nahlasi se problem a jeho detaily. Timto zpusobem nebude potreba mit velke naklady na gentoo infrastrukturu.
Dalsi koncept je, ze Gentoo bude compile cluster bude vzdy ten, ktery kompiluje balicky a generuje k nim otisky. Pokud je rozhodnuto, ze po kompilaci se binarka neuklada a nekdo v budoucnu chce stejnou configuraci, lze ji jiz spustit na uzivatelskem clusteru jelikoz vysledek se jen porovna s otiskem. Tim ale davame na gentoo infrastrukturu burden v podobe nejeno backend dataze a analytiky, ale take je potreba platit vypocetni cluster.
Tento druhy koncept muze fungovat, protoze cluster bude stale buildid na zaklade aplikace fronty, tj. bude prednostnekompilovat kombinace s vice uzivateli. Uvedomme si take, ze bych planoval stahovani data behem pul roku-1 roku, kdy uz paralelne muze bezet vytvareni balicku na backendu. Takze jakmile se vyda portage upravena o cele reseni, spousta realnych kombinaci uz bude k dispozici at uz v binarni podob
Poznamka nakonec: Opravdu prosim neuvazujte ze je nekde velke mnozstvi kombinaci. Proto uvazuju ten system jako event driven, tj. Hypoteticky je rozsahly co do poctu moznych sestaveni, ale pokud se neprovede prvni krok ve forme sberu dat a neudela se nad nimi analyza, tak je to pouze slepa spekulace. tzn. kdyz ja reknu, ze pocet kombinaci je maly a vy budete rikat, ze je urcite vetsi nez muj, tak mame oba pravdu :-))).
-
V zasade backend udrzuje tyto entity pro predstavu nejakeho modelu:
1. otisk konfigurace systemu
Tato informace se generuje na zaklade obsahu /etc/portage, pripadne plus emerge --info.
Backend nezna neco jako system (podle IP apod), Takze pokud neco upravim a posilam pozadavek vytvori se novy otisk
V teto entite jsou rozparsovane vsechny global, local use flags per package + make.conf, apod, ale ulozi se to jako nejaky document v jednom lobu (forma JSON napriklad)
2. otisk konfigurace package
Po pozadavku na urcitou package se vytvori otisk package, ale zaroven jejich dendency tree.
Opet se ulozi k otisku i dokument obsahujici celou konfiguraci (verze a flags) + cela konfigurace dependency treeOtisk konfigurace systemu a package muze byt M;N, tj. ruzne systemy mohou mit stejne otisky package
3. Posledni je otisk binary vysledku doplneny pripadne o link ulozene binarky (pokud se bude ukladat)
otisk binarky je 1:1 k otisku konfigurace
