abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

    včera 12:11 | Nová verze

    SteamOS (Wikipedie) byl vydán ve verzi 3.2. Přehled novinek v oznámení.

    Ladislav Hagara | Komentářů: 1
    včera 09:00 | Nová verze

    SecureDrop (Wikipedie, GitHub) je open source platforma pro bezpečné a důvěrné sdílení informací mezi žurnalisty a jejich zdroji. Vydána byla nová verze 2.4.0.

    Ladislav Hagara | Komentářů: 0
    26.5. 20:33 | IT novinky

    Společnost Proton AG představila novinky ve svých službách Proton Mail, Proton VPN, Proton Calendar a Proton Drive. Služby jsou přístupné z nového webu proton.me. Aktualizován byl ceník. Představen nový vizuál.

    Ladislav Hagara | Komentářů: 1
    26.5. 19:22 | Nová verze

    Týden po vydání Red Hat Enterprise Linux (RHEL) 9.0 byl vydán jeho klon AlmaLinux 9. Podrobnosti v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 4
    26.5. 15:00 | IT novinky

    Broadcom kupuje firmu VMware za 61 miliard dolarů.

    Ladislav Hagara | Komentářů: 11
    26.5. 09:55 | Nová verze

    Google Chrome 102 byl s verzí 102.0.5005.61 prohlášen za stabilní. Opraveno bylo 32 bezpečnostních chyb. Přehled novinek na Chromium Blogu nebo na Chrome Platform Status. Oficiální přehled novinek (New in Chrome, YouTube) zatím nebyl publikován. Přehled novinek v nástrojích pro vývojáře je bez videa.

    Ladislav Hagara | Komentářů: 0
    26.5. 01:55 | Komunita

    The Open Source Software Security Mobilization Plan (pdf) je konsorciem The Linux Foundation zastřešen plán na zvýšení bezpečnosti open source softwaru.

    Ladislav Hagara | Komentářů: 2
    26.5. 00:11 | Zajímavý článek

    Minulý týden proběhla hackerská soutěž Pwn2Own Vancouver 2022. Máte-li na starost bezpečnost IT, výsledky vás nepotěší. Microsoft Teams, Oracle Virtualbox, Mozilla Firefox, Microsoft Windows 11, Ubuntu Desktop, Apple Safari, Tesla Model 3 Infotainment System. Vše potopeno. Demonstrované bezpečnostní chyby ve Firefoxu jsou již opraveny ve verzi 100.0.2.

    Ladislav Hagara | Komentářů: 0
    25.5. 13:22 | Nová verze

    Lokální úložiště Stratis (Wikipedie), alternativa k úložištím s ZFS a Btrfs, bylo vydáno ve verzi 3.1.0. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 5
    25.5. 13:11 | IT novinky

    Sdružení CZ.NIC dnes vrátilo do zóny dříve vyřazená jména domén dezinformačních webů.

    Ladislav Hagara | Komentářů: 39
    Na sociálních sítích nebo jiných webových diskuzích vystupuji pod
     (60%)
     (17%)
     (23%)
    Celkem 344 hlasů
     Komentářů: 29, poslední 24.5. 00:02
    Rozcestník
    Pozor, nebezpečná radiace!Ne, tento blog opravdu nemá nic společného s vývojem Linuxového jádra :-) Jako "Jaderný blog" jsem jej pojmenoval jen kvůli mé oblibě jaderné fyziky a chemie.

    Věnovat se chci především Linuxu a Free Softwaru, prezentovat zde svůj pohled na věc a věnovat se všem palčivým otázkám a problémům, na které narazím. Určitě se zde také objeví články týkající se KDE, jelikož jsem velkým milovníkem tohoto desktopového prostředí a obecně eye-candy (k velké nevůli "pravověrných" Linuxáků ;-)).

    No a když už se to tu jmenuje Jaderný blog, možná se někdy dočkáte i nějakého populárně-vědeckého příspěvku, především pokud se bude jednat o nějaké ožehavé aktuální téma...


    Kategorie zápisků
    Aktuální zápisy


    Proč jsem přešel z Gentoo na Arch

    11.6.2005 04:27 | Přečteno: 2569× | Linux | poslední úprava: 22.11.2005 19:17

    Už jsem na pár místech sliboval, že vysvětlím důvody, které mě vedly k přechodu z mého milovaného Gentoo na můj (nyní již také milovaný) Arch Linux... takže tady to máte :-)

    Začátky (klidně přeskočte ;-))

    Asi tak před 2 lety (možná o něco málo déle) jsem přešel z Windows na Linux. Mojí první distribucí byl Red Hat 8.0 (který jsem velmi brzy upgradoval na 9.0). Vše bylo krásné a začal jsem pomalu pronikat do světa Linuxu. Ovšem asi tak po roce, když jsem již do tajů Linuxu jakž takž pronikl, mi Red Hat přestal vyhovovat. Za tu dobu se z mé instalace Red Hatu stala nesmírně "bloated" věc (nebo možno také použít výrazu "bordel" ;-)), zažil jsem si trochu toho RPM dependency hell a hlavně mi strašně vadilo, že jsem v Red Hatu neměl dokonalou kontrolu nad systémem. Systém jakým v Red Hatu byly řešeny některé konfigurace, atp. se mi prostě zhnusil.

    Vzhledem k tomu, že jsem chtěl mít nad systémem opravdu dokonalou kontrolu (a už tehdy se mi líbila myšlenka kompilace celé distribuce ze zdrojáků), rozhodoval jsem se mezi dvěmi možnostmi - Linux From Scratch a Gentoo. Jelikož nejsem masochista (nic proti lidem kteří LFS používají, obdivuji je ;-)) a svůj system sem chtěl mít neustále aktuální, rozhodl jsem se nakonec pro Gentoo.

    Mé milované Gentoo

    Gentoo jsem si nesmírně zamiloval. Nejvíce mě na něm uchvátila portage, rychlost a stálá aktuálnost systému. Vskutku ze začátku jsem měl vždy prakticky ihned ty nejnovější verze programů a to jsem používal stable x86 system. Princip "rolling-updates" jsem si zamiloval, někdo může sice potřebou mít vždy ty nejaktuálnější verze programů opovrhovat, ale každý jsme prostě jiný a máme jiné priority :-)

    Za tu dobu co jsem používal Gentoo jsem se (nejen) o Linuxu naučil neuvěřitelnou spoustu věcí. Stále se považuji za začátečníka (protože člověk se má pořád co učit), ale to nic nemění na tom, že Gentoo mě k získávání stále nových a nových informací a zkoušení nových věcí nesmírně motivovalo. Je pravda, že instalaci Gentoo podle dokumentace by zvládl možná každý kdo umí číst a dělal někdy na PC, ale Gentoo prostě člověka tak nějak vede k tomu, aby se toho o Linuxu naučil více.

    Co mě tedy k přechodu z Gentoo na Arch Linux dovedlo? Vždycky sem chtěl mít system co nejaktuálnější, ovšem nechtěl jsem nad ním ztrácet kontrolu. Zprvu jsem i při použití stable x86 system krásně aktuální měl, avšak později jsem musel přidávat stále více a více věcí do /etc/portage/package.keywords jako unstable ~x86. Nakonec to dopadlo tak, že můj soubor package.keywords měl délku přes 6 obrazovek a pomalu mi začínala docházet trpělivost. Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat. Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl). A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.

    To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.

    Můj milovaný Arch

    A tak jsem tedy vyzkoušel Arch. A jsem s ním spokojen :-) Na Archu se mi líbí, že je to nesmírně čistý system (podobně jako Gentoo nebo Slackware... osobně jej právě považuji za spojení toho nejlepšího z Gentoo a Slackwaru), disponuje výborným balíčkovacím managerem pacman (který se v mnohém vyrovná emerge a v něčem ho i předčí - třeba v tom že podporuje "reverse dependencies") a ABS (Arch Build Systemem), což je systém portů podobných portage pro kompilaci ze zdrojáků. Navíc je Arch optimalizován pro i686 a jedná se o vskutku velmi rychlý system. Co je ovšem pro mě taktéž velmi důležité - striktně se drží filosofie "rolling-updates" a vždy máte k dispozici ty nejnovější verze programů, některé často novější i než unstable ~x86 verze v Gentoo.

    Co se mi také hrozně moc líbí na Archu je jeho otevřený přístup ke komunitě. Na stránkách archu máte AUR (Arch User Repository) - repozitář PKGBUILDů (obdoba ebuildů z Gentoo určená pro Arch Build System), kam může naprosto každý přispívat svými vlastními PKGBUILDy. Neznamená to ovšem, že by zde neexistovalo žádné QA - nad AUR dohlíží skupina Trusted Users, kteří ho mají rozděleni podle kategorií a oblíbené PKGBUILDy mohou přijmout pod svůj patronát (přejdou z unsupported do community), načež později mohou přejít i do oficiálního extra či current repozitáře Archu. Tohle je přesně ten otevřený přístup ke komunitě, který mi u Gentoo chyběl, což mě ve svých důsledcích dovedlo až k tomu, že jsem přestoupil na Arch.

    I přes to všechno co jsem napsal se prosím nenechte zmýlit - Gentoo stále považuji za z mého pohledu nejlepší distribuci pod Sluncem a pokud se v něm situace zlepší, možná se k němu v budoucnosti vrátím...

           

    Hodnocení: 100 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    11.6.2005 10:23 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
    Rozbalit Rozbalit vše podobne problemy
    ano cesta ke gentoo byla u mne obdobna... a trapi me stejne veci...

    umi tedy arch kompilovat programy tak jak to umi gentoo - tedy puze s vybranymi zavislostmi a jak je to tam reseno?

    ps: zatim toho v ~x86 moc nemam (cele kde a par drobnosti). hard masket take pouzivam (treba momentalne amarok) ale je pravda ze obcas spadne.
    never use rm after eight
    JaMa avatar 11.6.2005 10:37 JaMa | skóre: 1 | blog: jama
    Rozbalit Rozbalit vše Re: podobne problemy
    Pouzivam jeden system s x86 a par baliky (<10) z ~x86 a jsem spokojen

    Druhy system mam na ~x86 se spoustou odmaskovanych baliku, nekolika baliky z fluidportage (cvs verze) a system je z 50% prekompilovany gcc-4.1 a stejne nepozoruju nejake padani.

    Myslim ze zase tak spatne to neni..
    11.6.2005 10:40 Martin Beránek | skóre: 33 | blog: mousehouse | Brno
    Rozbalit Rozbalit vše Re: podobne problemy
    mit tolik mista na disku na dva systemy... ale mam jen 40G hadr a to tak staci na ty WinXP na hry, Linux na praci a data...
    never use rm after eight
    Mikos avatar 11.6.2005 14:48 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: podobne problemy
    "umi tedy arch kompilovat programy tak jak to umi gentoo - tedy puze s vybranymi zavislostmi a jak je to tam reseno?"

    Arch je stavěn jako binární distribuce, Arch Build System je pouze doplňková věc, aby sis mohl libovolný program jednoduše překompilovat (a vytvořit z něj balíček) se svými možnostmi (pokud se ti u nějakého programu nelíbí jeho defaultní nastavení). Nebo aby sis mohl lehce vytvořit PKGBUILDy pro nové programy. Nicméně nic jako USE flagy nepodporuje, bylo by to v takovémto případě (jak se Arch jako distribuce profiluje) myslim i docela zbytečné...
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    Mikos avatar 11.6.2005 14:49 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: podobne problemy
    Ovšem závislosti (jak runtime závislosti, tak případné závislosti nutné pouze ke kompilaci) v PKGBUILDu samozřejmě nastavuješ...
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    11.6.2005 14:55 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: podobne problemy
    Nicméně nic jako USE flagy nepodporuje, bylo by to v takovémto případě (jak se Arch jako distribuce profiluje) myslim i docela zbytečné...
    Navic IMHO i neresitelne, proste by nemeli sanci udelat buildy tolika balicku...
    JaMa avatar 11.6.2005 10:33 JaMa | skóre: 1 | blog: jama
    Rozbalit Rozbalit vše Jenom k tomu nedostatku ebuildu v portage
    Kdyz nejaky neni v portage tak pouzivam postup Bugzilla, Forum, Google a resi to 70% pripadu. Ve zbyvajicich 30% se vyplati poslat request do bugzilly a pokud clovek chce prispet komunite tak do Bugzilly poslat i vlastni ebuild. On ho obcas nekdo zkusenejsi jeste parkrat zreviduje a pokud bude uzitecny a ok tak se urcite casem dostane i do portage.
    11.6.2005 12:22 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše ?
    Zvažoval jsem i kompletní přechod na ~x86, ale to se z mého hlediska rovnalo ztrátě kontroly nad systemem, čemuž jsem se chtěl za každou cenu vyvarovat.
    Jak to myslis? Jaka ztrata kontroly?
    Některé ebuildy byly navíc neaktuální i v jejich ~x86 verzi, jiné zas byly hard-masked (a odmaskovávat hard-masked ebuildy jsem opravdu nechtěl).
    Z jakeho duvodu? Pokud si myslis, ze vis lepe nez vyvojari distribuce, ze dany balicek bude stabilni, tak si ho klidne odmaskuj. Ale pokud jim veris, ze to opravdu blbne, tak nechapu, kde beres jistotu, ze to jinde blbnout nebude.
    A co mě ještě více vadilo - spousta balíčků v portage vubec nebyla a musela se hledat po fórech a v bugzille.
    http://www.gentoo.org/proj/en/devrel/staffing-needs/index.xml
    To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu. Gentoo developeři (kterých si jinak velmi vážím, prosím neberte to nijak špatně!) se sice omlouvali stylem "je nás málo", ovšem že by začali více přijímat nové developery z řad komunity nebo zrevidovali system přijímání ebuildů a udělali ho otevřenější komunitě, to ne.
    A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?
    Mikos avatar 11.6.2005 14:42 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: ?
    "Jak to myslis? Jaka ztrata kontroly?"

    V okamžiku kdy přejdu na celý systém unstable ~x86 kontrolu (alespoň z mého pohledu) opravdu částečně ztrácím. Věci se pak velmi rychle mění a za tu dobu co používám Gentoo se v ~x86 už párkrát nějaké kritičtější problémy objevili. Pokud vím přesně které balíčky mám unstable, prostě mám nad tím větší kontrolu. Navíc v případě použití unstable ~x86 bych částečně ztratil podporu developerů v případě nějakých problémů (respektive řešení problému by mohlo trvat o dost déle). Prostě preferuju takovou distribuci, která bude plně aktuální (a spodporou) i v její stable verzi. Jsou to mé preference, nic jiného...

    "Z jakeho duvodu? Pokud si myslis, ze vis lepe nez vyvojari distribuce, ze dany balicek bude stabilni, tak si ho klidne odmaskuj. Ale pokud jim veris, ze to opravdu blbne, tak nechapu, kde beres jistotu, ze to jinde blbnout nebude."

    Šlo o věci jako třeba Java 1.5 (od Sunu). Důvod proč byla (a možná ještě je) hard-masked sem si samozřejmě četl, ale zajímavé je, že v jiných distribucích (tedy tam kde Java vubec je ;-)) to nedělá problémy ;-)) Ale byly i jiné příklady (na které si teď už asi nevzpomenu), u kterých mi důvod jejich hard-maskování přišel (z mého hlediska) neoprávněný.

    "A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?"

    To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    11.6.2005 14:54 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: ?
    "Jak to myslis? Jaka ztrata kontroly?"

    V okamžiku kdy přejdu na celý systém unstable ~x86 kontrolu (alespoň z mého pohledu) opravdu částečně ztrácím. Věci se pak velmi rychle mění a za tu dobu co používám Gentoo se v ~x86 už párkrát nějaké kritičtější problémy objevili. Pokud vím přesně které balíčky mám unstable, prostě mám nad tím větší kontrolu.
    Nejak se mi nechce verit, ze by Arch Linux (ktery podle meho odhadu bude mit asi mensi user-base i pocet vyvojaru nez Gentoo, ktere tu uz nejaky ten patek je) mel lepsi QA nez Gentoo, i kdyz muze byt.
    Navíc v případě použití unstable ~x86 bych částečně ztratil podporu developerů v případě nějakých problémů (respektive řešení problému by mohlo trvat o dost déle).
    To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".
    Prostě preferuju takovou distribuci, která bude plně aktuální (a spodporou) i v její stable verzi. Jsou to mé preference, nic jiného...
    Jak muze neco byt "stabilni, vyzkouseny a podporovany", kdyz je to tri hodiny stare?
    "A co maji delat? Davat commit access do portage kazdemu, kdo submittne dva ebuildy? Co treba nejaky "rm in global scope", cili jeden malicky ebuild, ktery ti pri `emerge sync` "smaze pulku systemu" (on je tam sandbox, ale jde o princip - proste tyhle prava se nerozdavaji automaticky...)?"

    To je jednoduché (a v mém příspěvku jsem to také napsal) - buď udělat aktivnější proces přijímání nových developerů z řad uživatelů (což ovšem není nutné a mohlo by to být i kontraproduktivní), nebo založit něco na způsob Arch User Repository, který funguje velmi dobře. Jak jsem psal QA by v takovém případě nechybělo - byly by tam prostě 2 kategorie ebuildů - "unsupported" (za které by nikdo neručil, mohli by být vyprodukovány kýmkoliv) a ty by lidé ze skupiny Trusted Users mohli přijmout vždy pod svůj patronát, načež by se staly "supported" a následně se přesunuly do portage. Takovýto centralizovaný systém (který by si lidé mohli přímo přidat jako zdroj do portage) by byl rozhodně lepší než to když se hromada ebuildů povaluje po fórech a v bugzille. Bylo by to otevřenější komunitě a mohlo to urychlit cestu nových ebuildů do portage.
    Takovy "system" tu uz je. Predpokladam, ze i Arch to resi tak, ze aby ses mohl stat "Trusted Userem", musis neco delat, napriklad casto opravovat chyby v baliccich od jinejch lidi. Myslim, ze pokdu budes v Gentoo Bugzille dostatecne aktivni, dostanes commit access taky.

    BTW, co ti brani na mailu na gentoo-dev ML a navrhu, ze nejaky podobny "repozitar" udelas?
    11.6.2005 17:55 jm
    Rozbalit Rozbalit vše Re: ?
    To neni pravda. Proc by to melo trvat dele? Samozrejme musis hlasit bugreporty v rozumen podobe, ne "GNOME stopped working".
    No samozrejme, ze to je uplny nesmysl, od toho tam prece ty unstable verze jsou, aby se odladily chyby. :-)
    11.6.2005 14:58 jm
    Rozbalit Rozbalit vše Re: ?
    < Šlo o věci jako třeba Java 1.5 (od Sunu). Důvod proč byla (a možná ještě je) hard-masked sem si samozřejmě četl, ale zajímavé je, že v jiných distribucích (tedy tam kde Java vubec je ;-)) to nedělá problémy ;-))
    To bude asi tim, ze v jinych distribucich uzivatele proti te Jave nekompilujou balicky... :-P Co si treba projit bugzillu a zjistit, kolik veci se s tim neda zkompilovat nebo je jinak rozbitych?
    nebo založit něco na způsob Arch User Repository, který funguje velmi dobře.
    Uz jsem ti jednou psal, at si do overlay das, co uznas za vhodne. Existuje i nekolik predpripravenych jinymi lidmi, coz ovsem nebrani blbcum psat do Gentoo bugzilly, ze jim ty ebuildy buhviodkud nefungujou.
    Mikos avatar 12.6.2005 00:52 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: ?
    "Co si treba projit bugzillu a zjistit, kolik veci se s tim neda zkompilovat nebo je jinak rozbitych?"

    Jenze jsou take veci, ktere bez Javy 1.5 nefunguji. A v mnoha ohledech je Java 1.5 podstatne rychlejsi nez predchozi verze. Je to proste otazka priorit, co je dulezitejsi... z meho pohledu by bylo proste lepsi (a logictejsi) aby Java 1.5 byla pouzeble (a ne hard-masked).

    "Uz jsem ti jednou psal, at si do overlay das, co uznas za vhodne. Existuje i nekolik predpripravenych jinymi lidmi, coz ovsem nebrani blbcum psat do Gentoo bugzilly, ze jim ty ebuildy buhviodkud nefungujou."

    No a to je prave to co mi vadi - je v tom pak hrozna roztristenost a vyhledavat ruzne zdroje je obcas pekne zdrzujici. NAvic ma clovek v pripade veci z takovych zdroju nulovou podporu od Gentoo developeru. Proto rikam ze je mnohem lepsi system centralizovaneho (to slovo "centralizovaneho" je tu kliceve) komunitniho repozitare, kam by mohl ebuildy prispivat zcela kdokoliv a oni "Trusted Users" by nad tim dohlizeli. Zkratka po vzoru modelu Arch User Repository, ktery podle me funguje vyborne.
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    Mikos avatar 12.6.2005 00:55 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: ?
    Jen jeste dodak k te Jave - to byl pouze priklad, takovych veci je vice...

    Zkratka to shrnu tak, ze model jakym funguji repositare v Arch Linuxu (a jeho v tomto ohledu vetsi otevrenost komunite) je mi mnohem sympatictejsi, coz me take dovedlo k tomu, ze jsem z Gentoo na Arch presel. To je vse, o tom byl cely muj prisevek v blogu...
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    12.6.2005 16:59 jm
    Rozbalit Rozbalit vše Re: ?
    NAvic ma clovek v pripade veci z takovych zdroju nulovou podporu od Gentoo developeru. Proto rikam ze je mnohem lepsi system centralizovaneho (to slovo "centralizovaneho" je tu kliceve) komunitniho repozitare, kam by mohl ebuildy prispivat zcela kdokoliv a oni "Trusted Users" by nad tim dohlizeli.
    No tak nulovou podporu bys mel tak jako tak, jestli by to bylo uskladneno na jednom miste nebo na deseti. Ebuildy v pouzitelnem stavu se dostanou do portage, se zbytkem si porad, jak chces. Opravdu nemam pocit, ze by tam tech balicku bylo malo.
    11.6.2005 12:59 jm
    Rozbalit Rozbalit vše ??
    To všechno by ani nebyl až zas takový problém, ovšem poslední kapkou bylo, když jsem viděl jak se spousta ebuildů na novější verze či chybějící programy sice válí v bugzille, nicméně se tam válela již dosti dlouho a to že by byly přijaty do portage se jevilo v nedohlednu.
    Tak si udelej vlastni overlay a tam si je pridej a spravuj a uved je do takoveho stavu, aby se do portage dostaly. Naprosta vetsina tech, co v bugzille jsou, v takovem stavu bohuzel neni...
    11.6.2005 18:18 xkesh | skóre: 46 | blog: eXtempore
    Rozbalit Rozbalit vše kontrola nad systemem v AL je spis iluze
    Vždycky sem chtěl mít system co nejaktuálnější, ovšem nechtěl jsem nad ním ztrácet kontrolu.

    Tak jsem prave zjistil, ze na stroji, kam jsem si dal AL, nefunguje nejnovejsi nividia driver, protoze nvidia prestala jiste starsi karty podporovat.

    Nevadi, reknu si, udelam downgrade ... a asi hodinu uz hledam, jak je to jednoduse mozne. Asi neni. S touhle moznosti evidentne pacman nepocita, takze pokud si chci nainstalovat starsi verzi nvidia nez tu, ktera je momentalne v current, asi me ceka shaneni po vsech certech nebo si ze starych zdrojaku zkompilovat vlastni balicek.

    Dobra. Jen si tak nejak predstavuju "kontrolu nad systemem" ponekud jinak (napr. jako v Gentoo, ze napisu emerge =nividia-kernel-1.0.7104 a on se mi nainstaluje PRESNE tenhle).

    Prvni vec, kterou bych AL vytknul. Ze si neco musim zadat rucne do pacman.conf, to mi vubec nevadi. Ale vadi mi, kdyz nemuzu jednoduse udelat to, co udelat chci (napr. nainstalovat jednoduchym povelem zvolenou verzi balicku).

    Nebo jsem nekde prehledl snadne reseni?
    11.6.2005 20:35 Michal Karas | skóre: 45 | blog: /dev/random
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Zadat prikaz pacman -U /var/cache/pacman/pkg/nvidia-srara_verze.pkg.tar.gz a do /etc/pacman.conf pridat: IgnorePkg = nvidia?

    Takhle bych to teda asi resil ja.
    12.6.2005 13:38 xkesh | skóre: 46 | blog: eXtempore
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Zadat prikaz pacman -U /var/cache/pacman/pkg/nvidia-srara_verze.pkg.tar.gz
    Takhle bych to jiste resil, kdybych na zminenem miste starsi verzi mel, neboli kdyby neslo o prvni instalaci. Kdyz jsem psal, ze hodinu hledam, tak to nebyl jen recnicky obrat.
    12.6.2005 17:56 Michal Karas | skóre: 45 | blog: /dev/random
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    No tak v tom pripade aktualizovat ABS, upravit PKGBUILD na pozadovanou verzi a pustit makepkg, jak psal Mikos. Rekl bych, ze to je docela jednoduche.
    Mikos avatar 12.6.2005 00:25 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Bud to muzete resit zcela jednoduse tak, jak vam nize navrhuje Michal Karas, nebo proste a jednoduse pouzijte ABS, v PKGBUILDu pro nvidia drivery zmente cislo verze na starsi, pomoci makepkg ji zkompilujte, pomoci pacman -U nainstalujte a nasledne do pacman.conf pridejte radek IgnorePkg = nvidia. Nevim jak vam, ale me to slozite neprijde. Arch Linux se profiluje jako distribuce pro pokrocile uzivatele a tem by neco takoveho problemy myslim delat nemelo.

    "Jen si tak nejak predstavuju "kontrolu nad systemem" ponekud jinak (napr. jako v Gentoo, ze napisu emerge =nividia-kernel-1.0.7104 a on se mi nainstaluje PRESNE tenhle)."

    Zapominate na to, ze Arch je narozdil od Gentoo binarni distribuci. Skladovat binarni balicky pro vsechny mozne starsi verze by nebylo zrovna efektivni. Kdyz chcete jinou verzi nez je defaultne v Archu nabizena, tak od toho tu je Arch Build System, abyste si ji zkompiloval.
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    12.6.2005 15:59 jm
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Zapominate na to, ze Arch je narozdil od Gentoo binarni distribuci. Skladovat binarni balicky pro vsechny mozne starsi verze by nebylo zrovna efektivni.
    Huh? Eh? Souvislost? Unikla?
    Kdyz chcete jinou verzi nez je defaultne v Archu nabizena, tak od toho tu je Arch Build System, abyste si ji zkompiloval.
    Huh^2? Vy mate zdrojaky k tem nVidia ovladacum? :-)
    Mikos avatar 12.6.2005 16:27 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Pokud o tom nevite, tak k casti nvidia ovladacu opravdu zdrojaky mate a kompilujete si je :-) Ovsem jde jen o modul co se vklada do kernelu, ktery sam o sobe nic nedela, jen pouziva ony closed-source binarni ovladace
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    Mikos avatar 12.6.2005 16:30 Mikos | skóre: 34 | blog: Jaderný blog | Praha
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    "Huh? Eh? Souvislost? Unikla?"

    Souvislost je zcela jednoducha - jak by asi bylo mozne v repositari binarni distribuce skladovat balicky pro vsechny mozne starsi verze ruznych programu? To by zabiralo ponekud hodne mista... proto si logicky nemuzete dovolit to co v Gentoo, ze proste emergnete ebuild pro libovoulnou starsi verzi programu. Nicmene ekvivalent tu je - staci pouzit Arch Build System a v PKGBUILDu pro nvidia ovladace proste a jednoduse zmenit cislo verze na starsi a pomoci makepkg si nechat vytvorit balicek, ktery pak pacmanem nainstalujete.
    CETERUM CENSEO DRM ESSE DELENDAM Ostatně soudím, že DRM musí být zničeno!
    12.6.2005 16:42 jm
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Ano, pravda - skladovat balicek se zdrojaky nebo skladovat balicek s binarkami, to je ohromny rozdil! :-D
    12.6.2005 16:53 Jan Kundrát (jkt) | skóre: 27 | blog: jkt | Praha - Bohnice
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    No, to je, protoze binarky u Archu vytvari nejakej Arch-Linux team (aspon bych si tipnul), a tudiz je upstream neskladuje, zatimco u Gentoo mas zajem jenom o zdrojaky od upstreamu, ktery pravda Gentoo mirroruje. Jenomze je mirroruje jenom po omezenou dobu (v praxi to funguje asi tak, za kdyz se z Portage stromu odstrani ebuild, skript po nejake dobe smaze i tarball z mirroru). Cili u Gentoo mas sice moznost ziskat vsechny ebuildy az do soucasnosti (z CVS), ale stejne budes nekde potrebovat sehnat stare tarbally, a pokud je upstream po dvou letech smaze, mas smulu.

    U Archu je to asi jiny, protoze bude mit nejspis jenom jednu verzi od kazdeho baliku (nebo se pletu? ma jich vic?), zatimco Gentoo jich muze mit (a casto ma) vic, treba deset.
    12.6.2005 17:05 jm
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    Hmm, stale nechapu ten velky rozdil mezi skladovanim zdrojaku a binarek. Ja jsem snad nekde psal, ze by je meli skladovat vsechny? Ono by stacilo vic nez jednu, zejmena u ovladacu...

    Pokud je v Archu k dispozici jedna verze ovladacu pro ATI a jedna pro nVidii (nejlepe ta posledni s nejvice problemy), tak by se mel nad sebou nekdo zamyslet...
    13.6.2005 06:44 xkesh | skóre: 46 | blog: eXtempore
    Rozbalit Rozbalit vše Re: kontrola nad systemem v AL je spis iluze
    nebo proste a jednoduse pouzijte ABS, v PKGBUILDu pro nvidia drivery zmente cislo verze na starsi, pomoci makepkg ji zkompilujte, pomoci pacman -U nainstalujte a nasledne do pacman.conf pridejte radek IgnorePkg = nvidia. Nevim jak vam, ale me to slozite neprijde.
    Diky, vskutku to slozite nevypada. Pokus v praxi dneska rano ovsem nedopadl nejlip, tady jsem se o tom rozepsal. Ty uz jsi neco takhle downgradoval?

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.