Michal Čihař - Blog Archives for Linux

Minulý týden jsem potřeboval zpřístupnit tun device pro uživatele. Všechno vypadalo jednoduše - přidal jsem pravidlo pro udev, aby bylo zařízení přístupné pro nějakou skupinu. Rebootovat nebylo potřeba, po nahrání modulu se vše tvářilo v pohodě.

Na víkend jsem vypnul počítač a nějak se nezadařilo nabootovaní. udev nevytvořil skoro žádná zařízení a pořád vypisoval cosi o tom, že nemůže něco přejmenovat na net/tun . První myšlenka byla, že se mi tam asi dostal nějaký rozbitý udev, takže jsem nabootoval z CD a dal tam nějaký starší.

Pořád ten samý problém. Další krok mě napadlo znovu nainstalovat udev s distribuční konfigurací. Při té příležitosti jsem si již všiml, že tam je jakýsi vlastní konfigurák a po nahlédnutí do něj, mi bylo jasné o co jde :-).

Pokud chci změnit práva pro nějaký device, rozhodně není správná cesta všem zařízením přidělit toto jméno a práva:

 NAME="net/tun", GROUP="net"

Ale spíš nejdřív zkontrolovat, jestli to je ten správný a pak teprve měnit práva:

  KERNEL=="net/tun", GROUP="net"
 

Chybami se člověk učí, ale hlavně je potřeba je nejdřív hledat u sebe :-).

Why the hell do wakeup devices for ACPI need that cryptic names? I'd like to enable wakeup on keyboard, however I have no idea whether my notebook supports is or not. And the names don't help much:

$ cat /proc/acpi/wakeup
Device  Sleep state     Status
USB1       3            disabled
USB2       3            disabled
USB4       3            disabled
 LAN       4            disabled
MPC0       3            disabled
MPC1       3            disabled
VIY0       3            disabled
AMDM       3            disabled
 LID       4            * enabled
PWRB       4            * enabled

Už jsem ani nevěřil, že bude rozhození framebufferu po suspendu do paměti někdy opraveno, ale zdá se, že poslední ovladače to opravují. Takže konečně můžu po obnovení pracovat i na konzoli.

A nějak nechápu proč s touto verzí mají lidi tolik problémů, kromě fungující konzole jsem si žádné změny nevšiml. Teď jenom doufám, že nechválím nvidii zbytečně a oprava není způsobena přechodem na kernel 2.6.16 :-). No co hlavně že to je opraveno.

Tak už zase začínám řešit, jaký RCS používat. Jak se před pár dny ukázalo, nejsem jediný , kdo tu takový problém řeší. Tak třeba mi víc názorů pomůže :-).

Dosud používám Bazaar (na nové projekty), CVS (phpMyAdmin, práce a některé starší projekty) a příležitostně subversion (toho se v dohledné době asi dočká phpMyAdmin). Protože Bazaar je v dosavadní podobě mrtvý (a má pár nepříjemných chyb, které mi otravují život), potřebuju svoje projekty přesunout jinam. Při té příležitosti chci do stejného systému zmigrovat i CVS a zveřejnit tak některé věci, které se pravděpodobně oficiálního releasu nedočkají (viz další díl miniseriálu o mých programech).

Co rozhodně požaduji je distribuovaný RCS, bez toho už si život neumím představit (no dobře život ano, ale programování ne). Přechod z Bazaaru a CVS na něco jiného by neměl být zásadní problém díky tailorovi , který umí snad všechno o čem bych mohl uvažovat.

Tím se bohužel výběr příliš neomezuje a ve hře zůstává dostatek kandidátů a přichází nutnost dodat další omezení. Tady ale aby se z člověka stal detektiv a pečlivě pročítal dokumentaci, protože různá srovnání co jsem objevil jsou značně nekompletní a neaktuální. Protože na detektiva jsem moc líný, tak se zeptám tady :-). Chci aby RCS zvládalo následující body. znáte někdo takový?

• Distribuovaný, atomické commity a podobné základní věci, které má dnes skoro všechno
• Převoditelnost z Bazaaru a CVS
• Podepisování changesetů pomocí GPG
• Rozumná podpora pro přejmenování souboru
• Bez nutnosti mít server, možnost publikovat přes HTTP
• Musí se vyrovnat s unicode
• Webové prohlížítko
• Podpora pro Windows

Zatím tak nějak vyhrává Bazaar-NG, i když moc objektivních důvodů pro to nemám, prostě se mi líbí :-).

Zase jsem se rozhodl vyzkoušet jak funguje OpenOBEX s mým (dnes už postarším) telefonem Alcatel 535 . Neočekával jsem žádné zázraky, protože to dlouho nefugovalo (přestože oficiální aplikace výrobce pro Windows používá OpenOBEX). Moje překvapení proto bylo neuvěřitelné, když tentokrát to bez jakéhokoliv přesvědčování zafungovalo.

 $ obexftp -i  -l
No custom transport
Connecting...done
Receiving "(null)"...\<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
<folder name="User Data" size="1093840" modified="20000829T125420Z" user-perm="R"/>
</folder-listing>
done
Disconnecting...done
$ obexftp -i  -l 'User Data'
No custom transport
Connecting...done
Receiving "User Data"...\<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<folder-listing version="1.0">
<parent-folder />
<folder name="Sound" size="1093840" modified="20000829T125420Z" user-perm="RW"/>
<folder name="Photo" size="1093840" modified="20000829T125420Z" user-perm="RW"/>
</folder-listing>
done
Disconnecting...done

Teď ještě rozchodit nějaký pěkný filesystém (nejspíš přes FUSE), který mi umožní s daty rozumně pracovat. Znáte něco?

Dnes jsem se opět podíval na rozdíly mezi Sylpheed-Claws a jeho otcem Sylpeedem. Sylpheed-Claws používám a snažím se být v obraze jakým směrem se vyvíjí jeho „otec“. Protože mi oba dva celkem vyhovují, tak o aktuálním používaném favoritovi rozhodují detaily. Vždycky mi však připadá divné, že tyto projekty jsou již samostatné a kromě společného předka moc nesdílejí.

To že se vývojáři nejsou schopní dohodnout znám velmi dobře z případu Gammu a Gnokii, ale pokaždé mne takovéto tříštění sil zklame. To jsou opravdu neshody tak zásadní, že se nejde domluvit? Sylpeed a Sylpheed-Claws se zatím vyvíjejí velmi podobným směrem, ale už je vidět, že každý klade důraz na jiné věci. Povětšinou se dokonce jedná o změny v jiných částech, takže by asi mohly žít společně a těžit z většího počtu vývojářů…

Rozdílnost klávesových map pro xka a konzoli mě již dlouho štvala (a určitě nejsem sám, i jistý místní slavný blogger si na to stěžoval). Teď to vypadá, že to konečně někoho naštvalo natolik aby vytvořil řešení tohoto problému. Ten někdo se jmenuje Anton Zinoviev a pro Debian vytvořil balíček console-setup .

Ten umožňuje jednak snadné nastavení fontů, ale hlavně použití Xkových klávesnic v konzoli. Takže stačí zkopírovat nastavení z xorg.conf do /etc/default/console-setup a klávesnice je stejná. Nastavení klávesnice pak může vypadat třeba takto:

 XKBMODEL="pc104"
XKBLAYOUT="us,cz_qwerty"
XKBVARIANT=""
XKBOPTIONS="grp:alt_shift_toggle"

O tom že je rozumné psát komentáře do zdrojových kódů snad nikdo nepochybuje. Statistiky různých sprostých slov jsou již dlouho známé, ale přesto občas při opravování cizího kódu člověk narazí na zajímavé perly, které opravdu pomou k pochopení kódu.

Třeba po přečtení následujícího vysvětlení v gcc je hned jasné na co že se tato hodnota používá:

 // ??? Completely unknown what this field is supposed to be for.
          // ??? Need to cache TType encoding base for call_unexpected.
          xh->catchTemp = landing_pad;

Přece není možné, aby programátoři nevěděli co píší. Ale když už se v tom gcc hrabu, tak grep na tři otazníky najde další zajímavé komentáře:

 /* ??? When is this needed?  */
  saved_function = current_function_decl;

 /* If we are supposed to return TEMP, do so as long as it isn't a MEM.
     ??? The latter test doesn't seem to make sense.  */
  else if (dont_return_target && GET_CODE (temp) != MEM)
    return temp;

Nejdůležitější je ale stejně sebereflexe a schopnost zhodnotit kód:

 /* ??? this interface is stupid - why require a pointer?  */
              result = gen_reg_rtx (Pmode);

Taky tvoříte takovéto komentáře?

Vypadá to že kernel 2.6 se opravdu vylepšuje, dnes mám na notebooku uptime 50 dní a pořád v pohodě funguje :-). Dříve neustále ubývala paměť nebo byly jiné problémy, ale 2.6.14 zatím drží. Ještě tak by mě zajímalo jak zjistit jakou dobu počítač skutečně běžel a nespal v paměti, ale to asi nejde…

Už jsem tu jednou řešil výběr mailového klientu. Doba už pokročila (a moje požadavky se trochu změnily) a najednou mi připadalo, že je čas na změnu.

No vlastně nějak z požadavků nezůstal kámen na kameni, protože se poněkud změnilo moje používání emailu a souvisejících služeb. Už nepožaduji newsy, protože se nedají rozumně používat z více počítačů najednou (tak aby se přenášel stav co je přečtené a co není).

V rámci poslední čistky jsem zrušil většinu dalších emailových kont, takže si už postačím s jednou identitou na účet.

Takže aktuální požadavky:

1. Rychlost a neblokující operace. Nesnáším když ověřování PGP podpisu zablokuje celý program.
2. Podpora IMAPu, pokud možno s offline prací.
3. PGP (spolupráce s GnuPG a gpg-agentem)
4. Možnost konfigurace klávesových zkratek.
5. Práce s mailing listy (přímá odpověď na list)
6. Snadná práce se složkami
7. Gtk/Gnome rozhraní (hlavně ne KDE, ze kterých nic nepoužívám a nechci spousty kde procesů).

KMail

Dosud jsem ho používal. S ním se mi v počítači usídlila půlka KDE, občas je neuvěřitelně pomalý, PGP blokuje celý program. Má pár bugů, které mi vadí a nikdo se nemá k jejich opravení a mě se do toho moc nechce.

Sylpheed-claws

Několik lidí mi už Sylpheed doporučovalo, vlastnostmi se mi více líbila odnož/fork claws, tak jsem začal zkoušet a zatím úspěšně používám. Sice mi vadilo pár věcí, ale do CVS už se začínají dostávat opravy :-).

Evolution

Pořád mi připadá jako nějaká obluda, kterou nevyužiji. Má naprosto příšerné klávesové zkratky, které se nedají měnit. Informace o PGP podpisu jsou schované kdesi dole.

Thunderbird

Pořád neumí mailing listy…