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 23:55 | IT novinky

Společnost StartCom oficiálně oznámila, že jako certifikační autorita končí. Od 1. ledna 2018 přestane vydávat nové certifikáty a následující 2 roky bude poskytovat OCSP a CRL. Počátkem roku 2020 budou všechny platné certifikáty zneplatněny.

Ladislav Hagara | Komentářů: 0
včera 22:00 | IT novinky

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 8 000 dolarů [reddit].

Ladislav Hagara | Komentářů: 0
včera 21:55 | Zajímavý software

Byla vydána verze 10.0 linuxové distribuce Raspberry Digital Signage. Jedná se o distribuci pro jednodeskové počítače Raspberry Pi určenou k prezentačním účelům (veletrhy, prodejny, ...). Po naběhnutí systému je spuštěn webový prohlížeč v režimu celé obrazovky a vybraná prezentace. Nejnovější Raspberry Digital Signage vychází z distribuce Raspbian Stretch.

Ladislav Hagara | Komentářů: 0
včera 13:33 | Zajímavý software

Společnost Google na svém blogu věnovaném open source představila container-diff, nástroj pro analýzu a porovnávání Docker kontejnerů. Zdrojové kódy jsou k dispozici pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Komunita

Flatpak Workshop proběhne ve středu 29. listopadu od 10:00 v Brně. V dopolední přednáškové části se účastníci seznámí s Flatpakem, se specifiky pro aplikace napsané v Qt a GTK+, portály, které integrují aplikace do systému, a na závěr, jak dostat aplikaci do Flathubu, což je momentálně největší centralizovaný repozitář Flatpaků. V odpolední části si pak mohou za pomoci lektorů zkusit nějakou aplikaci zabalit pro Flatpak. Workshop je určen pro 20 účastníků. Nutná je registrace.

Ladislav Hagara | Komentářů: 5
včera 07:00 | Zajímavý článek

Software Freedom Law Center a Software Freedom Conservancy jsou organizace zaměřené na podporu svobodných/open-source projektů: SFLC poskytuje právní konzultace, SFC mj. také zázemí. SFC upozornila, že ze strany SFLC vůči ní proběhly právní kroky směřující k odebrání obchodní známky. SFLC v reakci tvrdí, že se jedná o logický krok, protože obchodní známky jsou si podobné, a SFC dlouhodobě nekooperuje. Brian Lunduke situaci shrnuje včetně ohlasů Neila McGoverna a Matthewa Garretta. Podle nich je Eben Moglen ze SFLC v konfliktu se zájmy komunity.

Fluttershy, yay! | Komentářů: 2
včera 06:00 | Komunita

MariaDB Foundation, nadace stojící za vývojem open source relační databáze MariaDB, oznámila, že Microsoft se stal jejím členem a platinovým sponzorem. Cílem Microsoftu je optimalizace MariaDB pro cloudovou platformu Microsoft Azure.

Ladislav Hagara | Komentářů: 0
16.11. 23:44 | IT novinky

Společnosti Dell a Canonical společně představily 5 nových počítačů Dell Precision s předinstalovaným Ubuntu. Jedná se o 4 notebooky a 1 all-in-one počítač. Cena počítačů s Ubuntu je o 100 dolarů nižší než jejich cena s Windows 10.

Ladislav Hagara | Komentářů: 14
16.11. 22:55 | Nová verze

Po pěti měsících vývoje od vydání verze 4.8 byla vydána nová verze 4.9 svobodného open source redakčního systému WordPress. Kódové označením Tipton bylo vybráno na počest amerického jazzového muzikanta a kapelníka Billyho Tiptona.

Ladislav Hagara | Komentářů: 0
16.11. 22:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 146. brněnský sraz, který proběhne v pátek 17. listopadu od 18:00 hodin v restauraci Bogota na Nových Sadech.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (74%)
 (14%)
Celkem 699 hlasů
 Komentářů: 36, poslední 17.11. 18:43
    Rozcestník

    Pacman pro ArchLinux a co mi na něm vadí

    24.4.2007 16:12 | Přečteno: 2917× | Unix, Linux, ArchLinux | Výběrový blog

    Poslední dobou se zde na ABCLinuxu objevil druhý díl velmi zdařilého seriálu o balíčkovém systému ArchLinuxu. Přestože používám téměř výhradně ArchLinux, mám k jeho balíčkovému systému hned několik vážných výhrad. Také zde nastíním některé možnosti řešení těchto problémů, ač ne vždy realizovatelné.

    Trocha kritiky aneb Co se mi nelíbí

    Veškeré níže zmíněné problémy jsem již popisoval v diskusním příspěvku k prvnímu dílu seriálu. Dal jsem si na tom příspěvku záležet. (A přiznávám, že byl nepříjemně dlouhý.) Potom se ale ozvalo ŽUCH a můj příspěvek vzal za své. Proto jsem se rozhodl vše popsat ještě jednou a podrobněji.

    Nepřehlednost zdrojového kódu

    Zkuste si někdy jen tak pro zajímavost přečíst kousek zdrojového kódu pacmana. Je to zajímavý zážitek. Najdete tam na mnoha místech například čtyři úrovně vnořených for-cyklů. Kromě peprných poznámek o efektivitě takového řešení vás jistě napadne, zda by nebylo záhodno pomýšlet na trochu lepší dekompozici celého úkolu. V tomto názoru vás nejspíš utvrdí fakt, že některé funkce mají délku až 500 řádků - téměř bez jediného komentáře, který by nezúčastněnému čtenáři (programátorovi) dával smysl.

    Všechno má samozřejmě své příčiny. Pacman v raných verzích ArchLinuxu existoval ve formě sady skriptů pro bash a Perl. Většina systémových utilit existovala původně jen v této formě. Teprve potom vznikaly binární verze přepsáním některých skriptů do C. Bohužel toto řešení nebylo příliš šťastné, jak nastíním dále.

    Jistě je rozumné se domnívat, že by někdo chtěl v budoucnu pro pacman vyvinout například různá rozšíření či moduly a že taková rozšíření mohou být jednou potřebná. Při současném stavu zdrojových kódů však nelze na něco takového vůbec pomýšlet.

    Efektivita - ajéje!

    Ta je zkrátka a jednoduše bídná a těžko se pro to hledá omluva. Nejde tu totiž o nejlepší nebo nejsložitější balíčkový systém. Kromě již zmíněného nešťastného stylu zdrojového kódu, o jehož efektivitě lze silně pochybovat, je příčinou též samotný způsob uložení dat.

    Pacman ukládá svá data v podivné adresářové struktuře ve /var/lib/pacman. Možná nebudu daleko od pravdy, když vyslovím domněnku, že tato struktura je pozůstatkem z „období skriptů“, který byl zachován kvůli kompatibilitě. Manipulace s touto strukturou je extrémně neefektivní.

    Slyšel jsem i názory, že pacman bude fungovat lépe na ReiserFS, který rychleji manipuluje s malými soubory. Bohužel s tím nemohu souhlasit. Na mém stroji běží stejně bídně na ReiserFS i na ext3. Návrh na umístění databáze pacmana na loopback do souboru je taktéž zajímavý, ale nejde o řešení původního problému. V běžných souborových systémech je vždy první dotaz zoufale pomalý a teprve opakované dotazy, při kterých už se využívá disková cache, fungují obstojně.

    Velmi rád bych zdůraznil, že problém zdaleka není jen v pomalých diskových operacích. Na starém počítači (233 MHz, 256 MB RAM) trvala příprava k aktualizaci systému, tedy porovnání verzí a nalezení zastaralých balíčků, cca 45 minut, bez jakékoliv nadměrné diskové aktivity. Něco takového je (mírně řečeno) nepřijatelné.

    Možnosti a funkce

    Ani tady nelze říct, že by bylo vše v pořádku. Chybí mi především funkce pro kompilovaný update. Ten může být potřebný z několika důvodů.

    Pro kompilaci balíčku existuje adresářový strom ve /var/abs a shellový skript makepkg, který každý balíček vytvoří pomocí souboru PKGBUILD. Pro rekurzivní průchod stromem balíčků a kompilaci celého podstromu slouží skript makeworld.

    Tyto dvě možnosti ale zdaleka nejsou dostačující. Oddělená kompilace jednoho balíčku je sice dobrým řešením, pokud neexistuje jeho binární forma a je k dispozici jen PKGBUILD. V ostatních případech je ale poněkud samoúčelná, ne-li nevhodná, protože může nastat případ, že spolu s balíčkem nebudou aktualizovány balíčky, které na něm závisí. Jde-li o sdílenou knihovnu, u níž došlo ke změně API, dostaneme nekonzistentní stav.

    Kompilace celého podstromu balíčků je dobrá pouze a výhradně pro správce repository. V jiných případech nemá smysl, protože podstrom se samozřejmě nekryje s balíčky nainstalovanými v daném systému. Proto nejde o kompilovaný update. Napřed by člověk musel mít skript, který projde celý strom abs a smaže adresáře nepoužívaných balíčků.

    Zásadním problémem je správné dodržení závislostí při aktualizaci. Jakmile provádíme binární update, spoléháme na kompetentnost a odpovědnost správce repository. Kompilovaný update ovšem vyžaduje rekurzivní průchod stromem build-time závislostí. V drtivé většině případů se nemění API knihoven a je tedy málo pravděpodobné, že by došlo k potížím. Spokojíme-li se s tímto chabým ujištěním, lze dnes celý systém aktualizovat například takto:

    #!/bin/bash
    
    pacman -Sy
    abs
    
    TO_UPDATE=`{ pacman -Q; echo ---; pacman -Sl | cut -d' ' -f2,3; } | \
    awk '
    BEGIN { ORS = " "; }
    /^---$/ { all = 1; }
    {
            if ( all ) {
                    version = installedArray[ $1 ];
                    if ( version ) {
                            ( "vercmp " version " " $2 ) | getline result;
                            if ( result < 0 ) { print $1; }
                    }
            } else {
                    installedArray[ $1 ] = $2;
            }
    }'`
    
    cd /var/abs
    for NAME in $TO_UPDATE; do
            ( cd `find -name "$NAME"`; makepkg -bcr )
    done
    
    pacman -Scc
    makepkg -C
    cd /var/abs && rm -R *

    Je nutné mít správné nastavení v souborech /etc/abs/abs.conf a /etc/makepkg.conf. Tento skript aktualizované balíčky pouze zkompiluje a neinstaluje. Pro současnou instalaci stačí přidat -i do argumentů makepkg.

    Problém rozšiřitelnosti

    V současném stavu rozhodně není možné pomýšlet na různá rozšíření pro pacman. Jeho celková koncepce to zkrátka neumožňuje. Já si ovšem umím představit spoustu užitečných možností rozšíření, které by jistě vedly k lepší použitelnosti.

    Řečí plno - a jaké je řešení?

    Nápad, na kterém je postavený ArchLinux, se mi velmi zamlouvá. O jeho implementaci však bohužel nemůžu říct totéž. Proto bych rád v krátkosti shrnul svou představu o návrhu a fungování balíčkového systému. Každý problém, o kterém jsem dosud psal, jistě má své řešení. Otázkou však zůstává, jak velké úsilí by bylo nutné vynaložit.

    Modulární návrh a rozšiřitelnost

    Základní návrh by měl počítat s co největší modularitou při zachování rozumné efektivity. Měl by poskytovat jen nejzákladnější funkce. Na něj by bylo možné navázat mnohá další rozšíření. Následující výčet je sice jen čirá fantazie, ale s takovým uspořádáním by byl správce balíčků mnohem použitelnější.

    Zmíněný výčet samozřejmě není zdaleka přesný a kompletní. Chtěl jsem jen docílit co největšího kontrastu se současným (téměř) monolitickým návrhem. Šíření balíčků pomocí peer-to-peer sítí mi připadá jako velmi příjemná alternativa k centrálním repository.

    Přehlednost a jednoduchost

    Zdrojový kód by měl být výsledkem spolupráce a diskuse několika autorů. V současné situaci tomu tak není a výsledek tomu odpovídá. Tak složitý systém jako správce software by měl mít vlastní dobře udržovanou webovou stránku. Neuškodil by taktéž coding style a dobře udržovaný systém komentářů.

    Součásti implementované pouze jako skripty by měly být pokud možno eliminovány. Vše by mělo být konzistentní, zejména pokud jde o možnost sdílení modulů pro různé speciální funkce.

    Nejsem sice fanatikým OOPákem, který nosí v kapse seznam Design Patterns, ale myslím si, že základy software tohoto typu by měly být založené na objektovém návrhu. Totéž samozřejmě nelze tvrdit o různých backendech. Jinde by ale použití C++ skutečně neuškodilo, spíš naopak.

    Kdo by měl tohle všechno udělat?

    Jestli jste dočetli až sem, gratuluji. Nepočítal jsem s tím, že někdo tento můj výlev vydrží číst. Zásadním změnám k lepšímu, pokud jde o rozšiřitelnost a efektivitu pacmana, stojí v cestě důležitý fakt: Tvůrci distribuce by stěží připustili existenci alternativního správce balíčků a založení nové distribuce je velmi špatný nápad.

    Nabízí se tedy otázka, proč jsem celý tento blogpost napsal. Odpověď je snadná: Protože jsem už dlouho uvažoval o vytvoření nového balíčkového systému a protože mi trochu vadil poněkud nekritický přístpup některých uživatelů k pacmanovi.

    Tak velké softwarové dílo jako správce balíčků rozhodně není úkolem pro jednoho člověka. Kromě toho mám náročnou školu a asi bych neměl dost odvahy se do něčeho takového pustit zcela sám.

    Věřím však, že existuje spousta lidí, kteří se už podobnou myšlenkou zabývali a kteří by případně měli zájem na podobném projektu pracovat. Je-li tomu skutečně tak, rád a bez váhání bych se k této práci přidal.

           

    Hodnocení: 82 %

            špatnédobré        

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

    Komentáře

    Vložit další komentář

    cezz avatar 24.4.2007 16:31 cezz | skóre: 24 | blog: dm6 | Žilina
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    To peer-to-peer mi pripomenulo jeden moj starsi zapis o gentoorrent.. :)

    Nieco podobne ma napadlo aj nedavno, ked boli po release Ubuntu 7.04 nenormalne vytazene repository.
    Computers are not intelligent. They only think they are.
    24.4.2007 16:38 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Protože však kompilátor Intel není svobodný software, nelze balíčky jím kompilované volně zveřejnit.
    Myslím, že s takovými licenčními podmínkami by Intel nevydělal ani na suchý chleba :-D.
    When your hammer is C++, everything begins to look like a thumb.
    24.4.2007 17:23 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí

    Možná, ale neplacená verze kompilátoru je výhradně pro nekomerční použití. Proto si myslím, že není možné, aby například Novell bez následků vydal své SUSE s X-serverem zkompilovaným kompilátorem Intel. Musel by nejspíš zaplatit nemalé licenční poplatky.

    Pokud by nebyly podmínky tak přísné, proč už např. pro ArchLinux nikdo nevytvořil alternativní repository s balíčky kompilovanými kompilátorem Intel nebo Sun? Kromě toho se bohužel pořád ještě nedá zkompilovat samotný Linux ničím jiným než GCC, takže možnost alternativních kompilátorů je zatím ve hvězdách.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    24.4.2007 17:27 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    OK, ale o neplacené verzi icc v zápisku není ani slovo ;-)

    Navíc, těch pár set dolarů za linuxovou verzi překladače by takový Novell asi nezabilo. Spíš by mě zajímalo, jak takový Intel-optimized kód běží na procesorech AMD?
    When your hammer is C++, everything begins to look like a thumb.
    Max avatar 24.4.2007 18:15 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Spíš by mě zajímalo, jak takový Intel-optimized kód běží na procesorech AMD?

    Dobrej joke... :D
    Zdar Max
    Měl jsem sen ... :(
    24.4.2007 18:58 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí

    Firma AMD má samozřejmě možnost vytvořit a vydat svůj překladač, stejně jako to dělá Intel. Nevidím důvod, proč by měl kód z překladače Intel běžet dobře na AMD. Protože můj počítač má procesor Intel, zajímám se pochopitelně o Intel víc než o AMD a jejich kompilátor byl první z alternativ, která mě napadla.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    24.4.2007 17:56 Trained.Monkey | skóre: 12 | blog: monkey
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Pred par dny jsem presel na Ubuntu, jinak bych si mozna dal rict na prepsani pacmana :-)
    24.4.2007 18:59 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí

    No jo, já se asi jednou naštvu a přejdu na OpenSolaris... :-D

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    24.4.2007 18:26 Dunric | skóre: 21
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Administrativní nástroje by IMHO neměly být v nativním kódu. Přímá závislost na nainstalovaných systémových knihovnách a kontrola/udržba kódu v něčem jako je C je daleko náchylnější k problémům než když to poběží v shellu nebo třeba interpretru Pythonu. U těchto programů není prioritou rychlost, proto je vývoj v nízkoúrovňových jazycích zbytečná komplikace. Pokud něco trvá neúměrně dlouho, je většinou problém v použitém algoritmu nebo např. už zmíněném nevhodném způsobu ukládání dat a přístupu k nim.

    Výjimkou potvrzující pravidlo mohou být dpkg/APT z Debianu ;-)

    Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?

    In the garden sleeps a messenger ·
    24.4.2007 18:52 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Administrativní nástroje by IMHO neměly být v nativním kódu. Přímá závislost na nainstalovaných systémových knihovnách a kontrola/udržba kódu v něčem jako je C je daleko náchylnější k problémům než když to poběží v shellu nebo třeba interpretru Pythonu.
    Zavislost takoveho programu napsaneho v C je minimalni - typicky libc a a par dalsich knihoven. Program v perlu nebo pythonu zavisi na interpretu, (ktery sam je typicky napsany v C a ma tedy podobne zavislosti na systemovych knihovnach), na pouzivanych knihovnach a na bindings tech knihoven do interpretovaneho jazyka. Tedy zavislost v pripade interpretovaneho jazyka bude typicky vetsi.
    24.4.2007 19:51 Dunric | skóre: 21
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Myslel jsem přímou závislost. Takový bashový nebo pythonní skript je "odolnější" vůči updatům interpretrů než (g)libc nejenom v rámci major verzí, jinými slovy po upgradech pravděpodobněji poběží bez nutnoti změny kódu. Nemohu a IMHO to ani nelze dokázat, toliko moje osobní zkušenosti.
    In the garden sleeps a messenger ·
    24.4.2007 19:01 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Btw. dělá Pacman pořád tu prasárnu, že přepisuje po upgradu balíčků jejich konfigurační soubory, přestože jsou v nich provedené změny ? Musí se stále explicitně uvádět v pacman.conf aby se nepřepsaly ?

    Pokud je balíček správně nastaven, nemělo by se to stát a konfigurační soubory by se měly uložit s příponou .pacnew při aktualizace a .pacsave při odstranění. Jestliže však balíček tuto informaci v sobě nenese, ani nejlepší pacman to nezachrání.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    24.4.2007 18:36 pholie | skóre: 4 | Košice
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Umím si představit (navzdory velmi odmítavým stanoviskům autorů ArchLinuxu) grafického klienta pro pacman.
    to ja tiez. zopar ich existuje, ale tie iba parsuju textovy vystup pacmana. pacman 3 je uz rozdeleny na kniznicu a klienta, tak casom snad vzniknu nejake normalne graficke frontendy

    Co třeba získávat binární balíčky přes BitTorrent, když už musí být binární? Nebo přes jinou síť?
    vo verzii 3.1 vraj nieco take planuju. niekde v mailing liste to bolo

    inak so zvyskom clanku suhlasim
    25.4.2007 08:46 dvh
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Vdaka za tvoj podnetny blog, prave si pisem vlastny balickovaci system takze sa mi to zijde.
    vogo avatar 25.4.2007 09:38 vogo | skóre: 34 | blog: "Skládat papír" | Jihlava
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí

    To by bylo abych se nevyjádřil :), zdrojový kód pacmana myslím znám velmi dobře, jak verzí 2.9.x tak verzí 3.0.x. Vezmu to popořadě :)

    Nepřehlednost zdrojového kódu

    úplně první verze pacmana vyšla v roce 2002, a už tehdy byl pacman napsán v C (jinak když se lepil arch, tak to dělaly skripty v úplných začátcích). Přehlednost a jednoduchost, ovšem tehdy to byl jeden jediný céčkový zdroják + sada skriptů (makepkg a spol). Kvalita kódu není kdo ví jaká, ale trojka je o dost stravitelnější, ale hodně by se dalo zlepšit, velkoě prospělo oddělení backendu (libpacman), což umožňuje napsat alternativní frontendy. Co se týče komentářů v kódu, je to opravdu bída. Osobně nemám rád pluginovací systém, pokud něco chybí, měl by to nabízet nějaký skript, nebo by se to mělo doimplementovat do programu (viz pacman-color, jistě by to všechno šlo dělat důmyslným skriptem, nebo modulem, ale o dost jednodušší to bylo dodrátovat).

    Efektivita - ajéje!

    Efektivita se s přepsanou verzí zlepšila, ale vždy je co zlepšovat, hlavním cílem je jednoduchost, porovnejte si pacmanovský systém třeba s RPM (BTW podobné problémy s výkonem má třeba i portagetree). Jiank při přechodu na dvojkovou verzi se databáze konvertovala, a řekněme si na rovinu, kdyby byl velký tlak změnit systém ukládání informací, tak to byl ten pravý čas, nyní si musíme počkat, třeba na 4.0.0 :).

    Uložení dat má své pro i proti. Pokud se něco nepovede, mohu to vždycky dát dohromady ručně. Pokud by se tato struktura ukládala do databáze (opravdové), bylo by to o dost složitější (BTW podobně to má i gentoo - z toho vyplývá neefektivita). Tento problém s výkonem tohoto řešení má i gentoo, je to tam na jedno brdo.

    Možnosti a funkce

    Portovatelnost: tým archlinuxu není kdo ví jak veliký, ale jistě Vás uvítají, pokud se nabídnete jako správce nové platformy, či kompilovaných updatů, BTW srovnávat Gentoo s binárními distry není na místě.

    Vlastní nastavení kompilátoru: dost to souvisí s předchozím, jinak optimalizace jde nastavit v makepkg.conf. Nezapomínejte, že arch je binární, pokud chcete systém na míru je tu gentoo. BTW jak by jste chtěl tohle udělat třeba na manrdivě ;) nějak nechápu.

    Použití alternativního kompilátoru: sám jste si odpověděl:) ale nic nikomu nebrání, aby vše upravil pro použití jiného, než svobodného kompilátoru. Pokud něco chcete, tak to udělejte, ostatní taky dělají vše za darmo (nebo za mrzký peníz), takhle prostě funguje komunita, já něco napíšu, ty něco napíšeš. remcaly nikdo nemá rád.

    ABS

    ABS je něco navíc oproti binárním distribucím, rozhodně to není věc určená pro kompletní překompilování systému, to dělá leda masochista. Podívejte se na archovskou wiki, ABS je určen hlavně pro kompilaci jednotlivých balíčků, u kterých vám chybí nějaká funkcionalita, ať už chcete přidat nějaký patch atd., prostě je to strom PKGBUILDů z oficiálních repositářů, nic víc nic míň. Pokud chcete překompilovat celý systém, je to váš rybíz, a opět řeknu, tak použijte gentoo, arch je binární distribuce.

    Problém rozšiřitelnosti

    Viz výše, jinak si myslím že grafický frontend je pro archlinux zbytečný, tahle distribuce se snaží být bez balastu, odpovědí je libpacman. Úplně stranou zůstává to, že banda vývojářů je trochu zabedněná :) (trochu víc).

    Přehlednost a jednoduchost

    Navenek je pacman jednoduše ovladatelný a přehledný, k tomu jak vypadá kód jsem se vyjádřil.

    Kdo by měl tohle všechno udělat?

    Ten kdo kritizuje? No dobrá, ale nebylo by od věci ze zapojit do mailinglistu. A jen tak stranou, pacmana nedělá jeden člověk, už dávno ne. Pokud vás něco štve, tak to zkuste napravit, a patch poslat vývojářům, asi se hned nepostaví kladně, ale pokud splníte jejich připomínky, je tu šance na změnu, viz můj patch ;).

    Nejsem paranoidní, ale to ještě neznamená, že po mě nejdou.
    25.4.2007 17:52 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí

    Nepřehlednost zdrojového kódu

    Tak to je pozitivní zpráva, že dojde ke změnám. Kdysi jsem měl (nějakým zázrakem) trochu času a říkal jsem si, že bych třeba doplnil něco zajímavého do Pacmana. Nepočítal jsem s tím, že by to vývojáři ArchLinuxu přijali, ale prostě jsem si ho chtěl trochu vylepšit a dát to ostatním k posouzení. Bohužel k tomu nedošlo, protože pohled na zdroják mě vyděsil natolik, že jsem od svého záměru ustoupil. Možná se někdy vzchopím a pokusím se ho celý přečíst, ale nevím, kdy to bude. :-)

    Efektivita - ajéje!

    Tlak na změnu databáze jistě není, protože se dělají rychlejší procesory a rychlejší disky a nikoho to nezajímá. Ale elegance se vytrácí. Pokud jde o tu databázi, jistě by byla zranitelnější než ta současná, ale uživatel by třeba mohl mít možnost volby, kterou chce použít. Proto jsem tolik mlel o těch backendech a modulech.

    Možnosti a funkce

    Kdysi dávno jsem Mandrivu měl a i tam byla možnost stáhnout balíček se zdrojovým kódem a nechat ho zkompilovat. Ne že by to vždy fungovalo a ne že by to bylo snadné, ale šlo to, dokonce přímo přes ty jejich příkazy urpmX. Pokud jde o portovatelnost, to byla spíš moje snaha zdůvodnit, k čemu je dobrý kompilovaný update i pro binární distribuce. Pro Mandrivu by to jistě k ničemu nebylo, ale tohle je jiný případ - ArchLinux je přece jen nízkoúrovňová distribuce. S tou správou platformy je to těžké, protože vlastním dva Intely a jinak nic. Spíš jsem se snažil zdůvodnit, k čemu by případně mohl být dobrý kompilovaný update.

    Je mi jasné, že remcaly nikdo nemá rád, ale mým cílem nebylo remcat. Spíš jsem chtěl nenápadně pošťouchnout případné zájemce o tuhle problematiku a zjistit, zda by náhodou někdo neměl zájem spolupracovat na vytvoření nějakého balíčkového systému.

    ABS

    ABS je skvělý systém, který v podstatě každý týden používám na update systému pomocí skriptu, který jsem do blogpostu napsal. Pak mám ještě jiný, který do ABS nenápadně podstrčí moji vlastní konfiguraci kernelu, ale to už je zas jiná pohádka. Pro mě (a nejsem jistě sám) je ABS středobodem zájmu v této distribuci a rozhodně ho nepovažuji za okrajovou záležitost. Balíčky z AUR stahuji výhradně jako PKGBUILD, je-li dostupný.

    Samozřejmě nepochybuji o tom, že ArchLinux se profiluje jako binární distribuce a že tato filosofie má spoustu výhod. Jenže mnou navrhovaný balíčkový manažer by se nejspíš zdaleka neomezoval jen na ArchLinux a jen na binární distribuce. Zatím je to samozřejmě jen pohádka, ale taková byla idea. Proto považuji za zcela přirozené, že by se měl umět správně vypořádat i s kompilací, včetně kompilovaného updatu.

    Problém rozšiřitelnosti

    Abych řekl pravdu, názor, že ten nebo tamten frontend je zbytečný, mi připadá poněkud příliš ortodoxní. Neříkám, že by měli vývojáři ArchLinuxu něco takového vytvořit, ale mám za to, že by časem takový frontend vznikl a rozhodně by nebyl ke škodě. Dokonce nevylučuju, že i já bych ho používal, pokud by byl dobrý.

    Donedávna jsem byl odpůrcem grafických udělátek na instalaci software, ale vyzkoušení systému PC-BSD, který má krásného softwarového manažera integrovaného přímo do Ovládacího centra KDE mě přesvědčilo, že to může mít smysl a nemusí vždy jít o nefunkční klikátko pro lamy.

    Přehlednost a jednoduchost

    Jistě, ovládání pacmanu je jednoduché, ale pořád se mi zdá, že dělá příliš mnoho věcí naráz. Chápu, že na to máte jiný názor, ale pořád jsem přesvědčen, že by se mělo důsledně oddělit jádro se základní logikou od síťové komunikace, práce se soubory, ukládání metadat a frontendu. Protože jsem tento návrh neomezoval jen na ArchLinux, samozřejmě jsem počítal i se zakomponováním ABS do základní příkazové sady.

    Kdo by měl tohle všechno udělat?

    Pevně věřím, že se mi podaří najít čas na nějaké úpravy. Přesto si ale myslím, že nemá smysl se vrtat v kódu, s jehož návrhem od základu příliš nesouhlasím. Proto jsem spíš chtěl vyvolat debatu o návrhu možného univerzálního balíčkového systému, který by se podobal pacmanovi ve všem kromě návrhu.

    Pokud jde o posílání patchů vývojářům, kdysi dávno jsem poupravil spouštěcí skripty tak, aby přímo podporovaly WPA. Tenkrát šlo WPA v ArchLinuxu zprovoznit jen při současném použití síťových profilů, což mi nepřipadá rozumné, zejména vezmete-li v úvahu, koli věcí zvládá wpa_supplicant zcela automaticky. Proto jsem doplnil skript network tak, aby k podopoře WPA nebyly nutné síťové profily. Poslal jsem svůj návrh do některé z těch diskusí - už si nepamatuju, kam vlastně. Nesetkal jsem se s žádnou odezvou, takže jsem tu věc nechal plavat, zejména kvůli nedostatku času. Je taky dost dobře možné, že tohle už dávno bylo vyřešeno jinak.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    vogo avatar 25.4.2007 18:11 vogo | skóre: 34 | blog: "Skládat papír" | Jihlava
    Rozbalit Rozbalit vše Re: Pacman pro ArchLinux a co mi na něm vadí
    Nemám rád slovní spojení "univerzální balíčkovací systém", ale chápu, že zde se nejedná o balíčkovací systém, který by koexistoval vedle jiného v tomtéž distru ;).

    O zdrojovém kó

    oddělení jednotlivých funkcí, a rozdrobení je právě to co se mi nezamlouvá, například se mi nelíbí jak to funguje u debianu, ale netvrdím že je to spatné, každé řešení má své výhody

    absence frontendu mi taky nevadí, ale třeba existuje celkem povedený gtk frontend, ale už je to delší doba co jsem ho zkoušel

    takže vidím, že na některých věcech se shodneme :), klidně bych se na takové věci podílel, na něčem jako alternativní správce balíčků pro archlinux, který by používal stejnou databázi jako pacman, prostě něco za pacmana, ale stejně jednoduché, a klidně pluginovatelné, od rána jsem nad tím přemýšlel, a možná by to mělo do sebe ;) třeba plugin, který by tvořil balíčky z ABS, nebo by je rovnou hledal na AURu :) jojo, škoda, že teď nevím kam dřív skočit...
    Nejsem paranoidní, ale to ještě neznamená, že po mě nejdou.
    Kdyby to bylo dle mých představ, jede to v sqlite (přímo a bez možnosti jiných - to by zbytečně komplikovalo) a napsané to je v Pythonu. Ale spokojím se i s tím, když to bude v céčku a sqlite :-).

    Párkrát se to tam (v diskuzi na arch) řešilo, stanovisko bylo, že databáze by byla příliš složitá, zaváděla by závislosti a (prý) by to bylo pomalejší . Což je blbost (obzvláště u sqlite), na kterou si vzpomenu, kdykoliv čekám až pacman "dochroustá" a začne něco dělat. Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.

    Ty problémy s kódem, frontendy by snad měl pořešit 3.0 a libpacman. Arch je zamýšlen primárně jako binární, zkoušeli jste yaourt s možností "--aur"?
    vogo avatar 26.4.2007 10:25 vogo | skóre: 34 | blog: "Skládat papír" | Jihlava
    Rozbalit Rozbalit vše Re: sqlite
    na zvýšení výkonu existuje jeden hack :) už ho dost dlouho používám, a je to jak přesednout ze stodváci do ferrari
    Nejsem paranoidní, ale to ještě neznamená, že po mě nejdou.
    26.4.2007 10:34 hikite
    Rozbalit Rozbalit vše Re: sqlite
    Díky za tip, možná při volné nudné chvilce seberu náladu ozkoušet - ale ten problém (spousta malinkých soubůrků dat) ještě elegantněji vyřeší sqlite - a než závislost na reiserFS, to radši na opravdové databázi :-).
    26.4.2007 14:27 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: sqlite

    Já mám ReiserFS na rychlém stroji a ext3 na pomalém. Nerad to říkám, ale na tom ext3 to funguje stejně rychle... Takže je otázka, jestli zrovna pro tenhle druh nasazení je ReiserFS opravdu tak ideální.

    Ale je to samozřejmě individuální. Každý má jiný hardware a podobně. Nebo že by tomu ReiserFS nesvědčil anticipatory scheduler? No to je možné, ale CFQ scheduler zase nesvědčí mým empétrojkám, a to ani trochu, takže teď aby si člověk vybral, že ano...

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    26.4.2007 10:43 hikite
    Rozbalit Rozbalit vše Re: sqlite
    Cha, tak už se na to těším, místo Reiser (mám k němu tak nějak... odpor) totíž zkusím - pro mě dosud neznámý - Spad. Tak ještě jednou dík.
    26.4.2007 14:23 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: sqlite
    Přesně tohoto hacku docílí Linux de facto automaticky - přibližně při třetím dotazu je už pak další odezva poměrně slušná, neboť je všechno v diskové cache. To s tím loopbackem je samozřejmě skvělý nápad, ale je to spíš workaround než nějaké trvale únosné řešení.

    Já to dělám tak, že spustím pacman -Qe a jdu si nalít limonádu. Když se vrátím, je už celá „databáze“ nachroustaná v diskové cache a další dotazy už mi pak jdou pěkně. :-) (To ovšem platí bohužel jen pro dotazy, nikoliv pro zápis metadat při aktualizaci balíčků. Tam už je to zas tradičně bídné.)
    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    26.4.2007 14:17 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: sqlite
    Vůči tomuhle zpomalení tam doporučovali jakousi jednoduchou "defragmentaci" (snad něco smazat nebo kýho hroma co), ale já jsem tím dost otráven na to, abych to řešil.

    pacman-optimize

    Ale že by to nějak fungovalo, to se říct nedá. Zrychlilo mi to pacmana možná o třetinu a jen do doby, než jsem zase udělal pořádný update systému. Nejspíš to tu databázi jen zkomprimuje, smaže a znova zapíše, aby se případné fragmentované malé soubory zapsaly spojitě. Nebo to špatně chápu, to je taky možnost...

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ

    Založit nové vláknoNahoru

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