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í
×
dnes 06:00 | Nová verze

Po půl roce vývoje od vydání verze 1.13 byla vydána nová verze 1.14 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.

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

Mozilla na svém blogu oznámila, že dnešním dnem postupně zapíná uživatelům Firefoxu v USA DNS přes HTTPS (DoH). Jedná se o výchozí nastavení. Odpovědi na otázky v infografice.

Ladislav Hagara | Komentářů: 10
včera 21:33 | Komunita

Dalším open source projektem, který byl finančně podpořen z programu Epic MegaGrants společnosti Epic Games je 3D PBR software pro malování textur ArmorPaint (GitHub). Získal 25 000 dolarů.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Zajímavý projekt

Firma vyvíjející distribuci CoreOS/Container Linux byla před dvěma lety převzata Red Hatem, v jehož portfoliu vznikla redundance: Fedora CoreOS cílí na podobná nasazení. Krátce poté vznikl fork nazvaný Flatcar Container Linux. Aktuálně je ukončení podpory CoreOS/Container Linuxu plánováno na 26. května a odstranění instalačních obrazů z distribučních kanálů na 1. září. Firma Kinvolk udržující Flatcar Linux oznamuje, že se věnuje usnadnění přechodu stávajících uživatelů CoreOS.

Fluttershy, yay! | Komentářů: 0
včera 17:00 | Nová verze

Byla vydána verze 19.0 z Arch Linuxu vycházející linuxové distribuce Manjaro (Wikipedie). Její kódové jméno ne Kyria. Přehled novinek v oznámení v diskusním fóru. Manjaro je ke stažení v edicích XFCE, KDE Plasma a GNOME. K dispozici je také síťová instalace Architect. Vývoj Manjara lze podpořit také zakoupením počítače z předinstalovaným Manjarem.

Ladislav Hagara | Komentářů: 0
včera 12:22 | Zajímavý projekt

Dne 19. února 2020 pan Kyle Finlay zahájil na Kickstarteru kampaň s názvem GamePad, jejímž cílem je získat prostředky na zprovoznění nové open source platformy pro digitální distribuci her, čistě pro OS Linux. Nová herní platforma je inspirována GOG.com a autoři slibují plnou podporu her bez ohledu na konkrétní distribuci, ale hlavně bez DRM. GamePad by měl být plně otevřený, včetně API, takže bude možné upravovat klienta, nebo si vytvořit

… více »
D.A.Tiger | Komentářů: 2
včera 01:00 | Komunita

Luboš Kocman, Release Manager openSUSE Leap, oznámil, že verze 15.2 linuxové distribuce openSUSE Leap vstoupila do beta fáze. Připojit se lze k testování a hlásit chyby. Aktivní testeři mohou získat tričko. Finální vydání openSUSE Leap 15.2 je plánováno na 7. května 2020.

Ladislav Hagara | Komentářů: 30
24.2. 23:11 | Nová verze

Oficiálně byla vydána nová stabilní verze 2.10.18 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP. Přehled novinek i s náhledy a videi v oznámení o vydání a v souboru NEWS na GitLabu. Verze 2.10.16 nebyla kvůli vážné chybě oficiálně vydána.

Ladislav Hagara | Komentářů: 2
24.2. 22:55 | Nová verze

Balík Rakudo Star, tj. Rakudo včetně modulů a dokumentace, byl vydán ve verzi 2020.01. Rakudo je implementace programovacího jazyka Raku. Ten byl ještě nedávno znám pod názvem Perl 6.

Ladislav Hagara | Komentářů: 0
24.2. 20:00 | Komunita

Aaron Griffin, dosavadní vedoucí projektu Arch Linux, oficiálně oznámil výsledek volby nového vedoucího projektu Arch Linux. Novým vedoucím se stal Levente Polyak (anthraxx).

Ladislav Hagara | Komentářů: 0
Vydržela vám novoroční předsevzetí?
 (9%)
 (5%)
 (3%)
 (83%)
Celkem 198 hlasů
 Komentářů: 0
Rozcestník

www.AutoDoc.Cz


Vložit další komentář
cezz avatar 24.4.2007 16:31 cezz | skóre: 24 | blog: dm6
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: 47 | 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: 68 | 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: 47 | 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: 47 | 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: 47 | 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"
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: 47 | 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"
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"
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: 47 | 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: 47 | 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: 47 | 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

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

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