AT Blog

In het Debiankamp meldt Juliusz Chroboczek zijn bevindingen met systemd (link). Hij somt een hoop voordelen en nadelen op. Voordelen zijn; het werkt onder Debian, het is goed gedocumenteerd, steekt logisch in elkaar, begrijpt hoe services beheerd moeten worden, en het is makkelijk zelf services te maken. Nadelen zijn: systemd is groot en wil teveel, het interacteert veel met hoger niveau lagen, heeft speciale handelingen hard gecodeerd (in plaats van via een script), gebruikt geen shell meer om opstart scripts in te schrijven, en is Linux-specifiek. Oh ja, en hij vindt systemd's auteur irritant. De opgesomde nadelen worden al snel ontkracht en Lennart Poettering (systemd's auteur) vindt het maar FUD (link). Het grootste probleem dat men heeft met systemd is dat het Linux-specifiek is en het herschreven moet worden voor bijvoorbeeld kfreebsd. Het ziet er niet naar uit dat er al een duidelijke keuze is gemaakt of men het SysV init systeem zal vervangen door systemd. Wellicht toch overstappen op upstart of helemaal niet overstappen?

Moritz Mühlenhoff oppert om naast de installatie ISOs ook virtualistie images van Debian releases te leveren. Hij vraagt zich af welke virtualisatie platformen moeten worden ondersteund (link). Jon Dowland laat weten dat het probleem vooral zit in hoe de virtualisatie techniek een virtuele machine definieert. Bijvoorbeeld, Qemu doet alles via argumenten op de commando-regel, terwijl VMware hiervoor een XML bestand gebruikt (link). Ook wordt er gesproken over images voor cloud-diensten. Charles Plessy geeft aan dat hier al wat werk voor verricht is (link).

Bij Fedora wijst Itamar Reis Peixoto iedereen op een artikel over hoe MacOS X snel DHCP leases verkrijgt en vraagt zich af of het niet ook onder Fedora te implementeren is (link). NetworkManager bevat al veel optimalisaties. Waar nog wat te winnen valt is de situatie waarin de client nog een geldige lease heeft. Nu is het zo dat NetworkManager ook bij een nog geldige lease de DHCP server om bevestiging vraagt. In plaats van telkens een bevestiging te vragen zou de geldige lease meteen gebruikt kunnen worden.

Het standaard toevoegen van ~/.local/bin aan de PATH variabele voor alle gebruikers zorgt voor nogal wat discussie aangezien dit in Fedora Core 15 na de release is doorgevoerd. Sommige waren hierdoor een beetje verrast (link). De bedoeling van de ~/.local/bin directory is dat daar programma's kunnen worden geplaatst die door de gebruiker zelf worden geinstalleerd. Python maakt bijvoorbeeld al gebruik van de directories onder ~/.local (link). De directories onder de ~/.local directory zijn deels onderdeel van de XDG specificatie. De ~/.local/bin is echter nog geen onderdeel van deze specificatie. Men stelt voor om deze directory ook in de XDG specificatie te krijgen om zo meer draagvlak te krijgen voor het gebruik van ~/.local/bin.

Miloslav Trmac maakt bekend dat in Fedora Core 16 de gebruiker IDs zullen beginnen bij 1000 in plaats van 500 (link). Debian doet dit trouwens al veel langer.

Jason Baron werkt aan een grafische tool, genaamd cg-manager, om cgroups te kunnen beheren (link). Cgroups is een kernel eigenschap om het systeemgebruik te limiteren per groep processen. Hierbij moet je denken aan geheugen-, cpu-, en I/O gebruik, maar ook prioriteiten en isolatie van processen. Met Jason's tool wordt het voor de gebruiker makkelijker om hier inzicht in te krijgen en dit naar eigen inzichten aan te passen.

Neal Becker haalt een blog van Lennart Poettering aan waarin het gebruik van /etc/sysconfig (/etc/default op Debian) in de ban wordt gedaan (link). Het blijkt dat het gebruik van /etc/sysconfig ongewenst is en dat daemons die er van afhankelijk zijn moeten worden herschreven. De /etc/sysconfig directory is ooit in het leven geroepen om configuratie-parameters voor init-scripts te beheren. Volgens Lennart Poettering is dit niet meer nodig met systemd.

Matthew Garret vraagt zich af hoe men het beste Trusted Boot (TXT) via tboot in Fedora kan implementeren (link). Eric Paris legt uit dat de impact voor de distributie niet al te groot zou moeten zijn. Het enige wat tboot doet is een hash van de kernel en initrd maken en deze in het TPM laden voordat de kernel wordt ingeladen. Zo kan, nadat de kernel is opgestart, geverifieerd worden dat het systeem veilig is opgestart en dat (nog steeds) de juiste kernel draait. Hij ziet vooral problemen met betrekking tot hardware die claimt TXT te ondersteunen maar het eigenlijk niet doet. Hij stelt dan ook voor om het niet standaard te installeren. Er wordt ook veel gediscussieerd over de toepassingen van TPM. Eén van de toepassingen is namelijk Digital Rights Management en men is bang dat TPM gebruikt kan worden om de vrijheden van de gebruiker in te perken. Vooralsnog lijkt het dat tboot dit niet in de hand werkt.

Manuel Escudero maakt duidelijk dat het gebruik van BTRFS de performance van zijn systeem aanzienlijk verslechtert. Het gebruik van virtuele machines is helemaal niet te doen (link). BTRFS staat gepland om als standaard filesysteem in Fedora 16 te dienen. Josef Bacik legt uit dat er nogal wat problemen met BTRFS zijn. Voornamelijk heeft BTRFS problemen met kleine I/O opdrachten doordat het voor praktisch alles threads gebruikt. Elke keer als een proces een I/O opdracht doet wordt deze overgedragen aan een thread en wacht het proces totdat de thread wakker wordt om de opdracht te accepteren. Vervolgens zal wanneer de IO opdracht klaar is deze weer aan een thread worden gegeven. Dit zorgt voor nogal wat wachttijden. Bij grote IO opdrachten is dit niet echt merkbaar, maar bij kleine IO opdrachten juist te meer. Josef probeert dit probleem op te lossen en geeft aan dat BTRFS niet als standaard filesysteem zal worden opgenomen als het niet goed bruikbaar is (link en link).

Misha Shnurapet vraagt zich af of ondertekeningen van upstream tarballs worden gecontroleerd bij het packagen. Dit naar aanleiding van de achterdeur in vsftpd die recentelijk is ontdekt (link). Op dit moment is het de verantwoordelijkheid van de package maintainer om de ondertekening te controleren. Het mooist zou zijn als de rpmbuild tool automatisch een beschikbare ondertekening controleert. Een ander voorstel is om het te automatiseren via een auto-qa test.

Moderne versies van de vim editor kunnen omgaan met verschillende character encodings. Als de instellingen verkeerd staan kan dat onaangename verrassingen leveren.

Onlangs kreeg ik te maken met een werkplek/account waarop de default vim-settings waren ingesteld om files altijd te saven in utf-8 encoding. Maar ik moest een shell-script editen met daarin een sed-commando dat in zijn input-data een bepaalde Latin1 bytecode moest opsporen, om daarmee een of andere substitute te doen. Dat script deed al jaren netjes zijn werk, maar nadat ik met de betreffende vim een onschuldig stukje commentaar had gewijzigd was de werking van het script kapot. Het volgende bleek aan de hand.

Er zijn vim-settings voor drie achtereenvolgende stappen:

1) met welke ogen moet vim de file bekijken op het moment van inlezen. Er zijn ontzettend veel verschillende encodings, en veel daarvan zijn niet eenduidig te herkennen c.q. van elkaar te onderscheiden door alleen maar naar de binnenkomende databytes te kijken. Dus je kunt vim een lijstje encodings opgeven die hij (op volgorde) moet aftesten. Hij kiest de eerste uit dat lijstje die niet tegenstrijdig is met de ingelezen databytes.

2) tijdens de edit-sessie houdt vim een werkfile bij; pas bij een 'write'-opdracht wordt die over de originele datafile heen gesaved. Je kunt bepalen in welke encoding vim die werkfile moet bijhouden. Dit kan betekenen dat de datafile bij het inlezen een vertaling moet ondergaan, en bij saven misschien nog een keer. Vim gebruikt het commando iconv voor deze vertalingen.

3) je kunt bepalen in welke encoding de datafile wordt gesaved. Mijn script-probleem werd veroorzaakt doordat deze setting was vastgeprikt op utf-8. Dit moest dus veranderen in "save in dezelfde encoding als waarin je de file hebt zien binnenkomen".

In deze zelfde 1-2-3 stappenvolgorde kijken we nu naar de vim-settings die je in je .vimrc startup kunt zetten.

Stap 1) set fileencodings=utf-8,latin1
Dit zegt dus hoe vim bij het inlezen de file moet "doormeten" om de erin gebruikte encoding te herkennen. In West Europa dekt het genoemde rijtje 'utf-8,latin1' meestal de behoeften. ascii hoef je hier niet apart te noemen want een pure ascii-file is automatisch ook een correcte utf-8 file. Windows 1252 encoded files kun je in de praktijk ook nog tegenkomen. Win1252 een uitbreiding van latin1 die zodanig in elkaar zit dat het verschil op dit punt geen kwaad kan.
Als je ook datafiles in latin9 encoding wilt laten herkennen dan moet je de officiële naam daarvan gebruiken: iso-8859-15. De officiële naam van latin1 is iso-8859-1 en die namen mag je beide gebruiken. Het heeft geen zin om iso-8859-1 (latin1) en iso-8859-15 allebei in het rijtje te zetten. Want aan de binnenkomende data is het verschil tussen die twee niet te zien, dus de eerst genoemde uit het rijtje matcht altijd en de tweede speelt dus nooit een rol.
Dat kan betekenen dat je in je vim-sessie characters uit het rijtje €ŠšŽžŒœŸ ziet waar je het character van de overeenkomstige positie uit ¤¦¨´¸¼½¾ verwacht, of omgekeerd, want dit zijn precies de verschil-posities tussen latin1 en latin9.
De kans dat een latin1 of latin9 file per abuis als een utf-8 file wordt gezien (omdat utf-8 eerder in het rijtje staat) is heel erg klein. Voor zo'n uitglijder zouden latin1/9 characters in de file uitsluitend in paren moeten voorkomen, waarvan het eerste character altijd  of à is, en het tweede character een iets groter (maar nog steeds beperkt) aantal mogelijkheden heeft.

Stap 2) set encoding=utf-8
Dit zegt dus in welke encoding vim tijdens de sessie zijn workfile moet manipuleren. Om de interne representatie van de workfile in utf-8 te kiezen is eigenlijk een beslissing waaraan geen enkel nadeel kleeft.

Het is wel noodzakelijk dat je terminal-venster (bijv. gnome-term) tijdens de edit-sessie ook in utf-8 encoding staat. Want anders zie je wel foute characters, maar dat komt uitsluitend door de manier waarop het terminal-programma je databytes weergeeft, en niet omdat de databytes zelf een foute encoding hebben. Wanneer je vermoedt dat de terminal-instelling problemen veroorzaakt dan kun je het beste vim even verlaten, en met grep de problematische tekstregel uit je datafile vissen en naar een temporary file kopiëren.
Daarna bekijk je die tmp-file met het od -cx commando. Utf-8 encoding is te herkennen aan het feit dat een 'letter-met-accent' twee bytes kost (elk met de 8e bit aan, dus hex-waarde 0x80 of hoger), terwijl zo'n byte in latin1/9 maar één byte kost (eveneens met hex-waarde 0x80 of hoger). Laat je niet in de war brengen door het feit dat od -cx op Little Endian CPU's (zoals Intel) de bytes in de hexadecimale output paarsgewijs omgewisseld toont ten opzichte van de character-output. Met dit od-commando kun je met zekerheid vaststellen welke encoding je tekstregel heeft.
Daarna moet je de encoding van je gnome-term zodanig instellen dat met cat de tmp-file met die tekstregel correct wordt weergegeven, en pas daarna ga je weer verder worstelen met je vim-instellingen.

Een foute terminal-instelling kun je ook compenseren via de vim-instelling 'termencoding', maar gebruik daarvan betekent dat je het ene gat met het andere stopt. Daar krijg je later altijd nieuwe problemen van.

Stap 3) set fileencoding=
Dit zegt dus in welke encoding de workfile moet worden uitgeschreven naar de uiteindelijke resultaatfile (c.q. over de originele file heen). Merk op dat hier fileencoding in enkelvoud staat; stap 1 had fileencodings= in meervoud. Door hier een lege inhoud/waarde te kiezen zeg je: schrijf de file uit in dezelfde encoding als waarin je 'm hebt aangetroffen bij inlezen. Je kunt dit ook op utf-8 zetten als je in de loop der tijd al je files naar utf-8 vertaald wil hebben. Dat was de setting waar dit blog-verhaal mee begon.