PLF project termination

Guillaume Rousse has just announced that the PLF project is being terminated.
PLF stands for Penguin Liberation Front and was providing Mandrake/Mandriva binary packages of software with either a problematic license or encumbered with patents so much that the official distro couldn't afford to ship them directly.

So long and thanks for all the fish!

OS upgrade

Over the weekend I've migrated to Fedora 15. I've briefly considered going back to Mandriva, but since Mageia forked off it, bot distros are weaker than the original one. Of course Fedora is not a miracle either, it's nowhere near the level of comfort I was used to from Mandriva and I've already been hit by a bug in the kernel, but at least I can expect every possible piece of software to be available with decent stability.

Mandriva is dying

Over the past few days I've seen too many "I'm leaving" messages on the Cooker mailing list. salem, caio, olavo, blino, dams, teuf, helio, arthur, boiko, fcrozat, pterjan and now neoclust. As Fabrice Facorat put it:

- install team : empty
- kde team : empty
- gnome team : nearly
- mandriva tools : ??? cut at least by half

Sorry, except if Mandriva is just willing to be a repackaging distro,
Mandriva as a true distro is dead !

It's quite sad to see the best KDE distro vanishing ...


UPDATE: See bug #60936 - Too many people leaving. In comment #11 there's a statement from the management. But I'm quite sceptical, really. You cannot restart a distro without the people...

HowTo switch from Cooker to Mandriva 2010 Spring

The release of Mandriva Linux 2010.1 is just behind the corner. I switched from MDV 2010 to Cooker (the development branch) a month ago, since it was already quite stable.
But as soon as 2010.1 is released, Cooker will reopen and become unstable again. So I'll have to return to the stable branch again.
How to do that? Fortunately other people asked that question, and here's the digest:

Once 2010.1 is official, open your Mandriva Control Center > 'Configure media sources...' and remove all from the list.
Then go to http://easyurpmi.zarb.org and add media '2010.1'. It'll generate a script that handles it all*. It might take zarb a few days before 2010.1 is listed there.

Due to bug #39975 you'll have to run:
urpmi.update -a --force-key
to avoid invalid signing key errors after the rpms are resigned with stable keys.



*or in the command line simply:
urpmi.addmedia --distrib --mirrorlist 'http://api.mandriva.com/mirrors/basic.2010.1.i586.list'
for x86 or:
urpmi.addmedia --distrib --mirrorlist 'http://api.mandriva.com/mirrors/basic.2010.0.x86_64.list'
for x64

Upgrading Mandriva to Cooker

I was needing some fresher system libraries and since the release of the next stable Mandriva Linux will be in just a few days, switching to Cooker (the development branch of Mandriva) was the easier option.
Here are the steps to switch Mandriva Linux to Cooker, taken from the Mandriva wiki:

1. First, remove media for the stable release : urpmi.removemedia -a
2. Add the required media for Cooker : urpmi.addmedia --distrib --mirrorlist 'http://api.mandriva.com/mirrors/basic.cooker.$ARCH.list'
3. Update all installed packages : urpmi --auto-update

I had to repeat the 3rd step several times, partly due to lagging mirrors. 

So far, I haven't noticed a bug, it seems 2010.1 will be one of the best releases ever.

Unbelievable became reality

In Mandriva, the packages in the official stable repositories only receive updates  for bug fixes. In addition to that, there is an extra repository called backports which contains latest versions of some packages. However these packages are completely unsupported.

As a completely retar^Wbizarre design decision, rpmdrake (the Mandriva package management tool) used to treat the backports repository as a source of updates, even when the user specifically disabled it. So you can imagine the mess it had beed causing.

Unfortunately the rpmdrake developer stood quite firm in his position and only a few days ago another Mandriva guy João Victor Duarte Martins submitted a patch that was just accepted.

After almost two years, one hundred comments, twenty-three votes and eight duplicates, the infamous Mandriva Linux bug #40556 (rpmdrake lists packages from disabled media source) has been fixed today.

There is still some hope in the world.

Thanks João!

rpmsync

rpmsync je bezvadná věc, používám ho na stahování aktualizací pro Mandrivu 2007 a pro udržování zrcadla Mandriva Cookeru (vývojové větve Mandrivy).




Funguje to tak, že si nejdřív stáhne seznam souborů na serveru a podle nich pak přejmenuje místní soubory. A potom nad tím spustí klasický rsync.
Tj. například rpmsync-1.6-1mdv2007.0.noarch.rpm (který mám na disku), přejmenuje na rpmsync-1.7-1mdv2007.0.noarch.rpm (který je na serveru) a pak už stahuje jen části, v nichž se tyto soubory liší.
Dvakrát denně cronem spouštím

rpmsync --delete-limit -vH --exclude-from=/home/hajma/exclude.lst \
rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/cooker/i586/ \
/dokumenty/Mandrivalinux-devel/cooker/i586/

--delete-limit je moje vlastní úprava, inspirovaná smazáním celého zrcadla při změně adresářové struktury. Zas až tak rychlé připojení nemám, tak mě to docela mrzelo.


--exclude-from obsahuje seznam souborů, které aktualizovat nechci, protože vím 100%, že je nepotřebuji a zbytečně zdržují. Obsahuje věci jako

*-l10n-fr-*
*-l10n-ja-*
...
*openoffice*

Na závěr vyplivne rpmsync (resp. rsync, že) zprávu:

Number of files: 15425
Number of files transferred: 153
Total file size: 15648376564 bytes
Total transferred file size: 304897518 bytes
Literal data: 203004952 bytes
Matched data: 101915361 bytes
File list size: 820591
File list generation time: 6.755 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 241216
Total bytes received: 191504554
sent 241216 bytes  received 191504554 bytes  80077.58 bytes/sec
total size is 15648376564  speedup is 81.61

to znamená, že místo 290 MB jsem stahoval pouze 183 MB a navíc získal asi 20 minut, a to se vyplatí.
Kdyby se to podařilo nějak přiohnout, aby se stahovaly jen soubory, které jsou potřeba, dala by se tak i nahradit absence deltarpm, které se v Mandrivě chvíli ohřálo a nejspíš tam ještě nějakou dobu nebude.

renouveau

Už několikrát se ve zprávičkách objevila zmínka o projektu nouveau - open source ovladači grafických karet nvidia s podporou 3D akcelerace. Jednou z možností jak pomoci jeho autorům je použít renouveau - program, který provádí jednoduché opengl testy a sleduje, jak se jejich provádění projevuje ve změnách registrů karty. Před pár dny se mi ho podařilo prosadit do Mandrivy. Uživatelé verze 2007.0 ho najdou v médiu contrib/backports, v cookeru je již přímo v contribu. Jak se s ním pracuje?


Je potřeba mít kartu od nvidie a mít nainstalované jejich proprietární ovladače. Někde si vytvořte adresář a jako normální uživatel v něm spusťte příkaz "renouveau". Objeví se okno, ve kterém několik minut probíhají testy - nepřejíždějte přes něj myší, neposunujte jej, nesmí se spustit spořič obrazovky. Až to skončí, bude adresář plný souborů. Zkomprimujte je a pošlete na renouveau (tečka) dumps (åt) gmail.com

pro přidání contrib/backports napište jako root (na jednom řádku):

urpmi.addmedia contrib_backports ftp://ftp.mandrivauser.cz/Mandrivalinux/official/2007.0/i586/media/contrib/backports with media_info/synthesis.hdlist.cz

mix No. 3

Dva kiksy a jedno pozitivum:



Napsat do /etc/ssh/sshd_config

DenyUsers All
AllowUsers hajma

je kravina:

For instance, if you denied logins to all accounts beginning with the letter "j" (ie. the pattern "j*"), yet had an AllowUsers statement for the user "jim", you might be tempted to think that jim would be accessible because it is the more specific pattern. This is not the case; logins are allowed only if there are no restrictions against the username. In this case, the restriction is against "j*" and thus jim would be denied.

Taky se mi dneska nějak popletly mnemotechnický pomůcky. V /var/log/security jsem si přečetl hlášení msecu o world writable souborech v mém $HOME a rozhodl se s tím něco dělat. Nějak jsem si ale vsugeroval, že pořadí není user, group, others anébrž owner, group, all a z toho odpovídající zkratky oga místo ugo. Takže jsem v $HOME s klidem spustil chmod -R a-w ./ ... a pak jsem se divil, že kmail nechce startovat ...

A pozitivní zpráva. Zašel jsem do CZC koupit flasku a byl jsem příjemně překvapen uvedením Linuxu na jejím obalu.

Je lepší Novell+KDE nebo Mandriva+Gnome?

Příznivci Linuxu jako jednu z jeho předností uvádějí rychlost s jakou jsou opravovány chyby. Protože mě začala frustrovat doba, po kterou teď už stovky mnou nahlášených nebo komentovaných bugů hnijí v bugzillách, rozhodl jsem se tuto legendu podrobit věděckému zkoumání, konkrétně tedy v případě Mandrivy, Novellu, RedHatu, Gentoo, Gnome a KDE.



Metodika:

1. Půl roku je dost dlouhá doba, bugy opravené po této době se nepočítají.

2. Z bugzilly příslušné distribuce se získá seznam chyb nahlášených v období od 1.1.2006 do 30.6.2006, včetně data nahlášení a data opravení a jejich aktuálního stavu.

3. Ze souboru se odstraní bugy vyřešené jako např. jako DUPLICATE (duplicitní), INVALID/NOTABUG (neplatné), WORKSFORME (vývojář nedokáže chybu reprodukovat), WONTFIX/CANTFIX (vývojář chybu neopraví, protože by třeba znamenala zásadní změnu koncepce programu), REPORTEDUPSTREAM (nahlášeno přímo autorovi programu) - ale jen ty, které takto byly zatříděny do 183 dnů.

4. Jako opravené se počítají chyby se statusem FIXED (nebo jejich ekvivalentem - viz např. RedHat)

5. Podle času, který trvala oprava se provede rozdělení na chyby opravené do 1,0 dne včetně, během 1,0-7,0 dnů včetně, během 7,0-14,0 dnů včetně, během 14,0-30,0 dnů včetně, během 30,0-61,0 dnů včetně, během 61,0-183,0 dnů včetně. Bugy opravené později než po 183,0 dnech se počítají jako neopravené.


(Tady je trochu zádrhel, protože údaje z KDE a RedHatu obsahují pouze informace o datu, nikoliv o čase, takže mohou být trochu v nevýhodě v případě chyb opravených do 1 dne, ale snad to tolik nevadí.)

No a konečně výsledky (dle abecedy):


Gentoo
Celkový počet chyb: 21313

Z nich nás ale zajímá jen: 14235

(Protože nepočítáme 4360 DUPLICATE, 666 WORKSFORME, 1486 INVALID a 566 WONTFIX)

Neopraveno zůstalo: 4964

Opraveno bylo: 9271

Celkem bugů opravených do 1 dne: 2317

Celkem bugů opravených do 7 dnů: 2119

Celkem bugů opravených do 14 dnů: 902

Celkem bugů opravených do 30 dnů: 1045

Celkem bugů opravených do 61 dnů: 1064

Celkem bugů opravených do 183 dnů: 1824

Mandriva

Celkový počet chyb: 2788

Z nich nás ale zajímá jen: 2221

(Protože nepočítáme 227 DUPLICATE, 48 WORKSFORME, 182 INVALID, 75 WONTFIX a 35 REPORTEDUPSTREAM)

Neopraveno zůstalo: 1108

Opraveno bylo: 1113

Celkem bugů opravených do 1 dne: 235

Celkem bugů opravených do 7 dnů: 218

Celkem bugů opravených do 14 dnů: 92

Celkem bugů opravených do 30 dnů: 121

Celkem bugů opravených do 61 dnů: 130

Celkem bugů opravených do 183 dnů: 317


Novell

Celkový počet chyb: 9745

Z nich nás ale zajímá jen: 6844

(Protože nepočítáme 1156 DUPLICATE, 293 WORKSFORME, 868 INVALID a 584 WONTFIX)

Neopraveno zůstalo: 2982

Opraveno bylo: 3862

Celkem bugů opravených do 1 dne: 526

Celkem bugů opravených do 7 dnů: 813

Celkem bugů opravených do 14 dnů: 400

Celkem bugů opravených do 30 dnů: 538

Celkem bugů opravených do 61 dnů: 461

Celkem bugů opravených do 183 dnů: 1124


RedHat

Celkový počet chyb: 15361

Z nich nás ale zajímá jen: 10819

(Protože nepočítáme 1894 DUPLICATE, 227 WORKSFORME, 1596 NOTABUG, 530 WONTFIX/CANTFIX a 295 REPORTEDUPSTREAM)

Neopraveno zůstalo: 5711

Opraveno bylo: 5108

Celkem bugů opravených do 1 dne: 687

Celkem bugů opravených do 7 dnů: 802

Celkem bugů opravených do 14 dnů: 607

Celkem bugů opravených do 30 dnů: 663

Celkem bugů opravených do 61 dnů: 725

Celkem bugů opravených do 183 dnů: 1624


Gnome

Celkový počet chyb: 20901

Z nich nás ale zajímá jen: 14908

(Protože nepočítáme 3933 DUPLICATE, 0 WORKSFORME, 446 INVALID, 757 NOTABUG, 509 NOTGNOME, 0 NOTXIMIAN a 348 WONTFIX)

Neopraveno zůstalo: 7347

Opraveno bylo: 7561

Celkem bugů opravených do 1 dne: 1887

Celkem bugů opravených do 7 dnů: 1761

Celkem bugů opravených do 14 dnů: 764

Celkem bugů opravených do 30 dnů: 905

Celkem bugů opravených do 61 dnů: 842

Celkem bugů opravených do 183 dnů: 1402


KDE

Celkový počet chyb: 10762

Z nich nás ale zajímá jen: 7105

(Protože nepočítáme 1312 DUPLICATE, 963 WORKSFORME, 1124 INVALID a 258 WONTFIX)

Neopraveno zůstalo: 5002

Opraveno bylo: 2103

Celkem bugů opravených do 1 dne: 474

Celkem bugů opravených do 7 dnů: 329

Celkem bugů opravených do 14 dnů: 145

Celkem bugů opravených do 30 dnů: 218

Celkem bugů opravených do 61 dnů: 288

Celkem bugů opravených do 183 dnů: 649


Jeden graf vydá za tisíc slov:

Vítěznou kombinací pro člověka, který nechce na vyřešení problémů čekat, je tedy Gentoo s Gnome. Naopak Nejhůře na tom bude ten, kdo si vybere RedHat a KDE.






FAQ:


Proč tam není Debian? Protože nepoužívá Bugzillu.


Proč ne XYZ? Neměl jsem čas. Nic ti nebrání zpracovat data XYZ a doplnit je.


Použitá data


English version:

Bug solving speed: Novell or Mandriva, Gnome or KDE?

link

Linux promoters use to give as one of its advantages the speed with which the bugs are solved. Because many of the (now hundreds) bugs I submitted or commented are still rotting in various bugzillas, I decided to scientifically inspect this legend, more specifically in the case of
Mandriva, Novell, RedHat, Gentoo, Gnome and KDE.


Methodology:

1. Half year is a timeframe big enough, bugs fixed after that are considered to be not fixed

2. From the pertinent bugzilla a list of bugs filed between 1.1.2006 and 30.6.2006 is retrieved, including the opening date, date of last change (should be +- the same as date of fixing for most) and their current status.

3. From the list must be removed bugs resolved as e.g. DUPLICATE, INVALID/NOTABUG, WORKSFORME, WONTFIX/CANTFIX, REPORTEDUPSTREAM - but only those that were classified this way during the 6 months period (183 days).

4. Bugs are counted as fixed if their status is FIXED (or equivalent - see e.g. RedHat)

5. The fixed bugs are then divided into categories based on the time it took to fix them - bugs fixed within 1,0 day, during 1,0-7,0 days, during 7,0-14,0 days, during 14,0-30,0 days, during 30,0-61,0 dnů, during 61,0-183,0 days. Bugs fixed later than 183 days after opening are considered as not fixed.


(A slight problem is that dumps from KDE and RedHat bugzillas contain only information about date, not about time, so they have a slight disadvantage as regards the 1 day fixes)

And the results:


Gentoo
Total bugs: 21313

But we are only interested in: 14235

(Because we do not count 4360 DUPLICATE, 666 WORKSFORME, 1486 INVALID and 566 WONTFIX)

Not fixed: 4964

Fixed: 9271

Total bugs fixed during 1 day: 2317

Total bugs fixed during 7 days: 2119

Total bugs fixed during 14 days: 902

Total bugs fixed during 30 days: 1045

Total bugs fixed during 61 days: 1064

Total bugs fixed during 183 days: 1824

Mandriva

Total bugs: 2788

But we are only interested in: 2221

(Because we do not count 227 DUPLICATE, 48 WORKSFORME, 182 INVALID, 75 WONTFIX and 35 REPORTEDUPSTREAM)

Not fixed: 1108

Fixed: 1113

Total bugs fixed during 1 day: 235

Total bugs fixed during 7 days: 218

Total bugs fixed during 14 days: 92

Total bugs fixed during 30 days: 121

Total bugs fixed during 61 days: 130

Total bugs fixed during 183 days: 317


Novell

Total bugs: 9745

But we are only interested in: 6844

(Because we do not count 1156 DUPLICATE, 293 WORKSFORME, 868 INVALID and 584 WONTFIX)

Not fixed: 2982

Fixed: 3862

Total bugs fixed during 1 day: 526

Total bugs fixed during 7 days: 813

Total bugs fixed during 14 days: 400

Total bugs fixed during 30 days: 538

Total bugs fixed during 61 days: 461

Total bugs fixed during 183 days: 1124


RedHat

Total bugs: 15361

But we are only interested in: 10819

(Because we do not count 1894 DUPLICATE, 227 WORKSFORME, 1596 NOTABUG, 530 WONTFIX/CANTFIX and 295 REPORTEDUPSTREAM)

Not fixed: 5711

Fixed: 5108

Total bugs fixed during 1 day: 687

Total bugs fixed during 7 days: 802

Total bugs fixed during 14 days: 607

Total bugs fixed during 30 days: 663

Total bugs fixed during 61 days: 725

Total bugs fixed during 183 days: 1624


Gnome

Total bugs: 20901

But we are only interested in: 14908

(Because we do not count 3933 DUPLICATE, 0 WORKSFORME, 446 INVALID, 757 NOTABUG, 509 NOTGNOME, 0 NOTXIMIAN and 348 WONTFIX)

Not fixed: 7347

Fixed: 7561

Total bugs fixed during 1 day: 1887

Total bugs fixed during 7 days: 1761

Total bugs fixed during 14 days: 764

Total bugs fixed during 30 days: 905

Total bugs fixed during 61 days: 842

Total bugs fixed during 183 days: 1402


KDE

Total bugs: 10762

But we are only interested in: 7105

(Because we do not count 1312 DUPLICATE, 963 WORKSFORME, 1124 INVALID and 258 WONTFIX)

Not fixed: 5002

Fixed: 2103

Total bugs fixed during 1 day: 474

Total bugs fixed during 7 days: 329

Total bugs fixed during 14 days: 145

Total bugs fixed during 30 days: 218

Total bugs fixed during 61 days: 288

Total bugs fixed during 183 days: 649


One graph is worth thousands words:

I did some comments on the results in the original, but as many people pointed out in the comments, the approach of every project is different, so use your brain and your knowledge/experience to figure out.


And remember: "the only statistics you can trust are those you falsified yourself" Winston Churchill.






FAQ:


Why is Debian/Ubuntu not included? Because the do not use bugzilla and I was not able to dump their data easily.


Why is XYZ not included? I do have only a finite amount of time available. You can do it yourself and let me know.


Used data and scripts

Mix No. 2

Věděli jste, že když ve Windows vytvoříte adresář s mezerou na konci, tak Windows tu mezeru na konci odstraněj? Úžasně praktický, zvlášť když má člověk rozbalovat tarball se stovkama souborů v desítkách takovejch adresářů.




Warly konečně udělal něco s Mandriví bugzillou, bohužel se zatím zdá, že původní bugy, které tím padly byly více než úspěšně nahrazeny bugy novými. Nadále se tak potvrzuje, že nejzabugovanějším nástrojem je bugzilla, aneb kovářova atd.



Louskám se pravidly pro tvorbu rpm modle mandriví kultury, abych mohl man-pages-cs uploadnout přímo do mandrivy - zjistil jsem, že moje jméno je z neznámýho důvodu mezi contributors v /usr/share/doc/mandriva-release-2007.0 i 2007.1, takže by mi to mohlo projít.
Před několika dny byly navíc opraveny dva bugy v manu, které jsem předtím složitě obcházel, takže teď to půjde sice jednodušejc, ale zase se v tom budu muset vrtat.

Mandriva a xgl

V cookeru se za posledních 24 hodin prakticky nepohnul ani bit, což znamená, že Mandriva 2007 je za rohem. Protože jsem měl, stejně jako spousta ostatních, se svou geforce4 problémy ještě v RC2, xgl jsem zatím v akci viděl jenom na videu.

Chyba byla opravena předevčírem, takže dneska se mi to konečně podařilo nastavit. Je to moc hezký, okna lítaj jako blázen, až se mi z toho vlnění dělá šoufl. Jediná, ale jak už to bývá zásadní, chyba je, že díky tomu nefunguje klasický přepínač ploch v KDE, což je prý dáno už podstatou compizu. Takže si s tím chvilku pohraju a pak to asi vypnu. Jinak 2007 vypadá hodně dobře, rozhodně je v lepší kondici než byla při vypuštění 2006.
Pár vizuálních mušek zůstává v rpmdrake, ale když si člověk vezme, že byl začátkem prázdnin úplně nefunkční a maintainer se k němu vrátil před 14 dny ... Taky podpora bezdrátových sítí v net_appletu by mohla být lepší, ale koneckonců doteď tam nebyla žádná.

Moje bugy v Mandrivě/Mandraku

Za poslední rok jsem v Mandrivě (jak v stable tak devel verzi) nahlásil 77 chyb.Jedna byla chyba moje, dvě se vývojářům nepodařilo u sebe zopakovat, čtyři už nahlásil někdo přede mnou. Pět chyb odmítli opravit - většinou s tím, že je to problém vývojářů postižené aplikace. 28 chyb bylo opraveno. 24 chyb zůstává ve stavu nepotvrzeno. 13 chyb je označeno jako skutečné, ale nejsou odstraněny.

K3B

Jak už jsem psal, K3B nedokáže ověřit zapsaná data, pokud názvy souborů/adresářů obsahují mezinárodní znaky. To je hodně špatný a podle tohoto nového komentáře k bugu se to zřejmě lepšit nebude:

------- Additional Comment #3 From Sebastian Trueg 2005-12-06 20:35 -------
I am only one man on all this and verification does not interest me that much.
That's why I keep moving this bug down the todo list... but I will do it
soon. I promise. :) please close the duplicate bug reports.

Nechtělo se mi tomu věřit, tak jsem se podíval na homepage a skutečně, vývojový tým zásadní aplikace tvoří jenom jeden člověk!




Nenajde se někdo, kdo by to dokázal spravit, vždyť jde jen o to, aby se správně převáděly znaky mezi 2 kódováními, nebo se pletu?




Nabízím 100 Kč formou zaslání na účet tomu, kdo tu chybu opraví.

Mandriva 2006 - rozdíl mezi Community a Official

Abych to příště nemusel hledat

Subject: Re: [Expert] Online sources for 2006
Date: středa 30 listopad 2005 20:50
From: Thomas Backlund tmb@mandriva.org
To: expert@mandrivalinux.org
Anne Wilson wrote:
* On Wednesday 30 Nov 2005 14:24, Gary Montalbine wrote:
** Is 2006 community a newer version of 2006 official? As I understand
** the above discussion community can safely be used as an update source
** for 2006 official. Correct?
*
* As I understand it, 2006 Official is the download/CD/DVD version, fully
* supported by Mandriva.  2006 Community has, I believe, updates and
* other packages supported only by the packager - not Mandriva.
2006.0 Official tree (official/2006.0/) is the "Frozen Cooker" from
where the Official ISO's get built.
- the media/main is the only supported part (besides the installer stuff)
- there are more packages here than fits on the DVD's (both in
media/main and even more media/contrib)
2006.0 Official Updates Tree gets the Security Updates for 2006.0
Official Main as per
2006.0 Community tree (devel/12006.0) is 2006.0 Official + 2006.0
Official Updates + ...
- this tree acts as a "Stable tree" for Products to come based on 2006.0
- this also gets other updates/bugfixes that are considered too simple
to go out as a Security Update
- newer versions of some programs are also allowed here as long as _they
don't break_ anything
- here you wont see any packages uploaded that would require many other
packages to be rebuilt,
so for example you wont see the new Firefox 1.5 here, or any of the
libs that is used in half the distro...
- This is the only place (besides Club and Offsite Repos such as SoS,
Thac) where Contributors
can upload bugfixes & security updates for Contrib packages in
media/contrib
* If that is not the case, someone will correct me.  If I am right, then
* it is slightly more risky than Official but a lot less risky than
* Cooker.
*
* Ann
Actually I would say this is the best Release to use as it will provide
a better testbase if more people use it.
And it's not risky, and bugzilla accepts bugreports against if if you
find any, and it will probably be fixed...
--
Regards
Thomas

Víc bajtů za stejný peníze (a vice versa)

V Mandrivě 2006 už má prý fungovat deltarpm ze SUSE - tj. stahovat se budou moct diffy balíčků, takže úspory objemu stažených dat budou aspoň 50 %. Ale šetřit se dá už teď.


Na desktopu mi běží Cooker, který se mi aktualizuje pomocí rsync v cronu (mám na disku mirror). Když jsem začal používat rsync, všiml jsem si, že některé soubory se stahují jakoby rychleji, např takový hdlist.cz kolikrát i megabajty za sekundu, přestože moje připojení je řádově jinde. Je to tím, že rsync umožňuje v rámci možností přenášet změny mezi souborem lokálním a souborem na serveru (pokud to server podporuje).

Normálně toho při stahování balíčků nevyužijete, protože se názvy souborů liší jiným číslem verze. Proto jsem si napsal skriptík, který zjistí, které balíčky byly updatovány. Tyto balíčky (ty staré) přejmenuje, dá jim název aktuální verze balíčku. A potom teprve se spustí mirrorování.

Dneska jsem provedl srovnávací pokus. Nejprve jsem vyrobil kopii adresáře, ve kterém je mirror Cookeru. Potom jsem nad originálem spustil klasický úplný mirroring (vynechal jsem soubory končící na .cz, u nich se rozdíly stahují i tak) a poté nad kopií svůj přejmenovávací skript:


klasika:

sent 21 997 bytes received 173 203 233 bytes 37 401.54 bytes/sec



s přejmenováním:

sent 364 139 bytes received 127 506 709 bytes 37 882.05 bytes/sec


1/3 úspora zdarma!




Toto je onen testovací skript, je v něm samozřejmě ještě pár nadbytečnejch věcí, ale jako proof of concept to snad stačí.

#!/bin/bash
root_path="/mnt/mdk/Mandrakelinux-devel/cooker2"
/usr/bin/rsync -avvn --delete-after mandrake.contactel.cz::Mandrakelinux-devel/cooker/i586/ $root_path | grep -v "is uptodate" | grep .rpm$ > seznamrpm
for deleted in $(grep deleting seznamrpm)
do
if [ "$deleted" != "deleting" ]
then
stary_soubor=$root_path/$deleted
deleted_base=`/bin/basename "$deleted"`
deleted_dir=`/usr/bin/dirname "$deleted"`
package_name=`echo $deleted_base | awk 'BEGIN { FS = "-[^-]+-[^-]+rpm$" } ; { print $1 }'`
novy_soubor=$root_path/`grep -v deleting seznamrpm | grep "$deleted_dir/$package_name-[^-]\+-[^-]\+rpm$"`
echo $stary_soubor
echo $novy_soubor
mv -f $stary_soubor $novy_soubor
fi
done
/usr/bin/rsync -avv --delete-after --progress --partial --exclude='*.cz' mandrake.contactel.cz::Mandrakelinux-devel/cooker/i586/ $root_path > log

a pro úplnost klasický rsync, který jsem používal doteď:

/usr/bin/rsync -avv --progress --delete-after --partial --exclude='*.cz' mandrake.contactel.cz::Mandrakelinux-devel/cooker/i586/ /mnt/mdk/Mandrakelinux-devel/cooker >> log

Cooker@official - Tlustý klient hautů

Občas mám doma pracovní notebook a hraju si na něm s linuxem. Asi nejvíc používám live distribuci Slax (upravená 4.2, pětka má bohužel mouchy). Teď se mi navíc povedlo rozchodit bootování ze sítě, a tak už nejsem omezený na live distra. Zkouším si novinky v Cookeru, zatímco na hlavním stroji brouzdá žena po netu v MDK 10.1 (a na harddisku notebooku nebyl změněn jediný bit).




Tlustý klient?
Tlustý klient bootuje ze serveru a data má na serveru uskladněná, ale výpočetní sílu používá svoji.
Narozdíl od tenkého klienta, který v podstatě jen zobrazuje to, co mu server posílá.
Jelikož oba stroje mají srovnatelný výkon (Athlon 1800, 512 RAM x Celeron 1700, 256 RAM), připadlo mi použití tenkého klienta jako plýtvání zdroji.




Jak na to?
Nejprve jsem zkoušel použít průvodce drakTermServ od Mandraku, ale ten předpokládá, že se nasdílí celý / serveru, kam se pomocí ClusterNFS dá i zapisovat. To se mi podařilo celkem bez problémů zprovoznit, ale jen do chvíle, kdy jsem chtěl i na klientovi zprovoznit 3D akceleraci grafiky a totálně se v tom zamotal (nVidia server x ATI klient). Navíc jsem chtěl vyzkoušet i jinou distribuci. Proto jsem drakTermServ spolu s ClusterNFS zavrhl a zkoušel to jinak.

Na opuštěný oddíl hda6 (který se od nějaké doby mountuje jako /mnt/gentoo ;-)) jsem nainstaloval Mandriva Cooker. V něm jsem nainstaloval drakTermServ a nechal jsem vytvořit obraz pro bootování ze sítě. V adresáři /var/lib/tftpboot se tedy vytvořily soubory boot-3c59x.2.6.11-6mdk.nbi a initrd-3c59x.2.6.11-6mdk.img. Ale nefungovaly - z několika důvodů.

Protože síťová karta v notebooku je od firmy 3COM a poněkud nekompatibilní, bylo potřeba upravit zaváděcí obraz utilitou imggen:


cd /var/lib/tftpboot/

mv boot-3c59x.2.6.11-6mdk.nbi boot-3c59x.2.6.11-6mdk.nbi.new

./imggen -a boot-3c59x.2.6.11-6mdk.nbi.new boot-3c59x.2.6.11-6mdk.nbi

rm -f boot-3c59x.2.6.11-6mdk.nbi.new
Další problém byl s initrd. Předně neobsahoval modul mii, na kterém je závislý modul 3c59x a potom předpokládá, že NFS server poskytuje adresář /. Určitě by bylo lepší upravit jen initrd, každopádně já jsem postupoval cestou poněkud jinou. Věděl jsem, že drakTermServ volá příkaz


mknbi-set -v -k /boot/vmlinuz-2.6.11-6mdk -r 3c59x
mknbi-set jsem našel v /usr/bin a zjistil, že je to ve skutečnosti skript, který zase v jednom místě volá další skript mkinitrd-net. A ten jsem upravil k obrazu svému - přidal modul mii:


# seems we've moved nfs into the kernel now

if [ -d "/lib/modules/$kernel_ver/kernel/fs/nfs" ]; then

modules="mii $modules sunrpc lockd nfs" # Always require nfs for nfs mount

fi

Potom jsem ještě zašel do /usr/lib/mkinitrd-net/initrd-skel/, kde se nachází vzorové soubory pro tvorbu initrd a změnil v souboru udhcpc-post natvrdo adresář pro mount NFS na /mnt/gentoo.
Teď jsem tedy znovu spustil příkaz



mknbi-set -v -k /boot/vmlinuz-2.6.11-6mdk -r 3c59x

a Cookera vypnul a nabootoval zpět do Official. Tam jsem překopíroval boot a initrd z /mnt/mdk/var/lib/tftpboot do /var/lib/tftpboot.

Od předchozího pokusu mi v systému zůstal nakonfigurovaný tftp, dhcp a NFS server, v jejichž konfigurácích stačilo udělat drobné změny, aby si odpovídaly verze kernelu a tak podobně.
Jako poslední jsem upravil soubor /etc/fstab u klienta (ve skutečnosti tedy /mnt/gentoo/etc/fstab):


192.168.1.1:/mnt/gentoo / nfs rsize=1024,wsize=1024,noac,nolock,intr 0 0
Teď už jen připojit notebook kabelem, v biosu upřednostnit boot ze sítě et voila!
Mandriva sice při detekci nového hardwaru chvilku přemýšlela, ale všechno si bez problému našla a za chvilku jsem byl v KDE.

Jediné, co mi ještě chybělo byl swap, protože 256 MB RAM opravdu není mnoho. Swapovat přes NFS je prý nebezpečná záležitost, takže jsem použil NBD (Network Block Device) od Pavla Machka.
Vytvořil jsem soubor do kterého bude klient swapovat:


dd if=/dev/zero of=ntbswapfile bs=1048576 count=512

su

mkswap ntbswapfile
Stáhnul jsem a zkompiloval zdrojáky a na serveru spustil server:


nbd-server 9000 /home/hajma/ntbswapfile
(zvláštní je, že dokumentace uvádí volbu -l soubor, kde v souboru je seznam IP, ze kterých lze přistupovat na server, ale při použití této volby program zdechne)
a na klientovi klienta:


modprobe nbd

nbd-client 192.168.1.1 9000 /dev/nbd0
(klient má ještě volbu -swap, která je vyloženě dělaná na swapování, ovšem vyžaduje úpravu jádra. S tím si budu hrát jindy, zatím se mi to nehryže)
A zapnul swapování:



swapon /dev/nbd0
Teď jenom nastavit, aby se síťovka odpojovala až po odpojení fs a nastavit přístup na web a je to.

Update: Stačilo z /etc/rc.d/rc0.d (potažmo rc6.d) vyhodit linky K..nfslock, K..netfs a K..network

deltarpm

Posledních pár dní jsem přemýšlel nad vytvářením diffů mezi jednotlivými rpm balíčky pro případ updatů a hrál jsem si s bdiff a bsdiff.
Najednou koukám, že v MDK Cookeru už to je.
Snad se to uchytí a místo 150MB updatů KDE budu stahovat třeba jenom 1/3...



Dobrá práce, MDK!

GPRS přes IrDA na MDK 10.1, Alcatel OT535 a Asus A7V8X

Od lamy pro lamy. Jak jsem to zprovoznil s Oskarem.



Motherboard A7V8X vlastní konektor na IrDA, takže si šikovnější kutil může za pár korun IrDA port vyrobit - viz zde:
http://www.infraredport.com


Funkčnost zapojení se dá zjistit i bez jakéhokoliv softwaru, stačí se na čočky portu dívat při startování počítače přes displej digitálního foťáku - ten infračervené světlo vidí:


Mandrake je na všechno v podstatě připravenej, takže není potřeba kompilovat kernely a tak, ale stačí si nainstalovat irda-utils. V souboru

/etc/sysconfig/irda

jsem ještě musel změnit port, na kterém očekává systém infra zařízení

IRDA=yes
DEVICE=/dev/ttyS1
#DONGLE=actisys+
DISCOVERY=yes

Potom už stačilo spustit IrDA

# /etc/init.d/irda start

a když jsem spustil

# irdadump

, tak jsem viděl, jak si spolu telefon a PC krásně povídají.

22:20:45.039136 xid:cmd 7fc4a198 > ffffffff S=6 s=5 (14)
22:20:45.129124 xid:cmd 7fc4a198 > ffffffff S=6 s=* hajma hint=0400 [ Computer ] (21)
22:20:47.588754 xid:cmd 7fc4a198 > ffffffff S=6 s=0 (14)
22:20:47.678734 xid:cmd 7fc4a198 > ffffffff S=6 s=1 (14)
22:20:47.768727 xid:cmd 7fc4a198 > ffffffff S=6 s=2 (14)
22:20:47.858708 xid:cmd 7fc4a198 > ffffffff S=6 s=3 (14)
22:20:47.948693 xid:cmd 7fc4a198 > ffffffff S=6 s=4 (14)
22:20:48.038680 xid:cmd 7fc4a198 > ffffffff S=6 s=5 (14)
22:20:48.127169 xid:rsp 7fc4a198 < bde98e7c S=6 s=5 ALCATEL OT535 hint=b125 [ PnP Modem Fax Telephony IrCOMM IrOBEX ] (30)
22:20:48.128666 xid:cmd 7fc4a198 > ffffffff S=6 s=* hajma hint=0400 [ Computer ] (21)

Potom ještě nahrát pár modulů (jsou potřeba, nezkoumám proč...):

# modprobe ircomm
# modprobe ircomm-tty

a jdeme nastavit kppp:

Zařízení mám nastavený jako /dev/ircomm1, řízení toku žádné, ukončení řádky CR, rychlost spojení 57600 (asi by bylo lepší nastavit 115200)

V záložce modem mám vypnuto čekání na vyzváněcí tón a jako příkazy modemu toto:

jinak všechno na defaultních hodnotách.
Vytáčené telefonní číslo je

*99***1#

a ověření je nastaveno jako "Pomocí skriptu".
Telefon musí bejt samozřejmě taky nastavenej, ale to se u Oskara dá udělat posláním SMS z jejich webu.
Snad jsem na nic nezapomněl, mě to funguje...