Harvard Business School of Echec

Aller au contenu | Aller au menu | Aller à la recherche

mardi, avril 22 2008

ABI vs. API compatibility

glibtop_get_proc_mem

libgtop has a function glibtop_get_proc_mem to retrieve basic memory usage of a process. It fills a struct glibtop_proc_mem which looks like:

struct _glibtop_proc_mem
{
	guint64	flags;
	guint64 size;	
	guint64 vsize;
	guint64 resident;
	guint64 share;
	guint64 rss;
	guint64 rss_rlim;
};

Yes, size/vsize and resident/rss look like duplicate. At least on the linux implementation, even if size/vsize and resident/rss come from /proc/self/stat and /proc/self/statm, you can see in linux/fs/proc/{array,task_mmu}.c that they have the same values. So, it seems to me that the only unique members of struct glibtop_proc_mem are size, resident and share (ok there are also flags which flags which members are filled and rss_lim).

linux proportional set size

Linux 2.6.25 comes with a new stat in /proc/self/smaps called pss which is even smarter/accurate than private_dirty. There's glibtop_get_proc_map which currently have all the smaps member but not this new pss. So what is the smarter way to get this new pss in libgtop without breaking everything ?

- break the ABI ?

I could simply extend struct glibtop_proc_map. That would break the ABI, which i'm allowed to because libgtop is desktop. But that's bad practice since packagers have to rebuild everything. That's a painful migration that may delay the adoption of newer versions of the library.

- break the API ?

What about cleaning up the glibtop_proc_mem duplicate members, mark unused some of them and rename rss to pss while keeping it binary compatible ? That would make the API a bit more sensible. I've scanned the Debian/unstable archive and that would break the build 3-6 packages but i would be able to submit trivial patches to fix glibtop_get_proc_mem usage. (And also add glibtop_init(); which are missing everywhere).

- hide pss inside rss ?


So what's best ?

lundi, avril 21 2008

Quelques minutes avec Fedora

Au travail, la distribution GNU/Linux validée est RHEL 4.5 sur les serveurs et les postes de travail. C'est un peu vieux (Linux 2.6.9, avec un GNOME 2.6 - 2.7), mais ça fonctionne sans problème (j'ai même était surpris que le branchement de clef USB à chaud fonctionne). À mes débuts, vers 2000, j'utilisais RedHat et Mandrake, mais depuis que j'ai découvert Debian, je n'avais jamais ré-utilisé ce type de système.

Donc je me suis dit que j'allais tester Fedora 8, j'ai téléchargé le DVD pour installer ça sur une machine de récupération. L'installation est facile, elle est graphique et ça tient même dans du 800x600, et j'ai choisi un mode minimal (823 paquets quand même): par défaut, le partitionnement utilise LVM et SELinux est en mode strict, tout ça me plaît bien. Il y aussi icedtea dans le tas, c'est sympathique. Quelques minutes plus tard, j'arrive sur mon bureau GNOME 2.20. C'est mignon et très standard. Je veux rajouter un disque dur pour étendre mon / mais je n'arrive pas à trouver d'outils dans le menu, je finis donc par un petit pvcreate/vgextend/lvextend/resize2fs, rien de bien sorcier.

En passant, il n'y a pas de sudo configuré par défaut, on tape donc le mot de passe root pour les gestes d'admin.

Ensuite je me mets en tête de tester frysk et systemtap puisque qu'apparemment c'est installé: impossible de mettre la main dessus. Rien dans mon PATH, les paquets sont bien installés, je lis le man, fais un gros find /, mais impossible de trouver comment les lancer. Je me dis bon je vais déinstaller/supprimer frysk au cas où: yum remove frysk fonctionne très bien, par contre yum install frysk ne connaît pas frysk, le mode search ne trouve rien. Au passage, il n'y a pas de complétion bash pour yum. Je laisse tomber puisque je vois qu'il y a une entrée dans le menu Applications pour ajouter/supprimer des logiciels.

J'ai déménagé deux fois en un mois, je n'ai pas récupéré d'accès à Internet, et quand je lance ce gestionnaire de paquets graphique, il n'arrive logiquement pas à récupérer la liste des paquets: il y a bien un bouton "Annuler" mais il ne fonctionne pas. Quand la MAJ échoue enfin, j'ai le choix entre quitter ou voir l'éditeur de la liste des dépôts. Là c'est la première farce: si je clique sur "Fermer" sans avoir fait de modification, ça quitte le gestionnaire de paquets. Après plusieurs essais, je le comprends, et je ne laisse activer que le dépôt "Install media" qui doit correspondre à mon DVD (même si les détails du dépôt sont entièrement vide). La liste des paquets est enfin disponible. Je suis déjà un peu méfiant, puisque qu'en somme le gestionnaire de paquets n'est pas (trivialement) utilisable si on est pas connecté à Internet. Très mauvais point.

J'arrive ensuite sur une liste de méta-paquets répartis en catégories. Ce sont des gros méta-paquets, il y en a peut-être une vingtaine, avec des noms simples tels que "Environnement GNOME", "Développement GNOME", etc. Impossible de savoir ce qu'il y a dedans, par contre, on peut savoir en cliquant sur le bouton "Paquets additionnels" ce qu'il n'y pas dedans. Je sélectionne donc "Développement GNOME", j'installe, c'est un ensemble de paquets très utiles, genre tous les -devel sauf que ça n'a installé aucun outil de développement un peu utile genre style gcc. Ça m'a quand même installé rcs... J'y retourne pour installer "Outils de développement". Je me promène dans les autres catégories pour personnaliser tout ça : au revoir le "Serveur web" (toujours impossible de savoir ce que ça contient), je désélectionne aussi "Bureautique/Productivité" (sic) qui selon sa description doit contenir des afficheurs PDF, etc.

Erreur monumentale.

D'abord les descriptions sont inexactes voire fausses. Ensuite, il n'y pas de gestion de dépendances entre les méta-paquets : en cliquant à droite à gauche pour alléger mon système, ça a un peu déselectionner par hasard "Environnement de bureau GNOME", sans me le dire bien sur... moi je suis un luser de base, quand on me présente une liste illisible de noms de RPM dans une petite fenêtre, je fais "Appliquer". Et là je vois l'installateur de paquets afficher des mise à jour (???), et j'aperçois des trucs importants passer à la trappe: nautilus, gnome-volume-manager, etc. Bref il est trop tard. Les applets plantent en rafale. Je me retrouve à la porte, je retombe sur GDM et tente de retourner dans ma session ... xterm. On m'avait pas le coup depuis 10 ans.

Magnifique: en quelques minutes, j'ai flingué mon système en voulant juste supprimer "Sons et vidéos", "Graphismes", "Internet basé sur texte" (sic) et quelques trucs comme ça. J'insiste, je n'ai pas fait n'importe quoi. Seulement les dépendances et RPM, même 10 ans après, ça ressemble toujours à de l'escroquerie. Une distribution avec des gestionnaires de paquets aussi défectueux, ça me paraît inutilisable (et pour cause j'ai détruit mon système) qu'on soit utilisateur de base ou ingénieur de métier. Mais qui utilise ça !?

Le DVD finira son weekend à la poubelle. Mes Debian/Sid n'ont pas à s'en faire. Une distribution, c'est des paquets, et Fedora j'ai vu. Pour bien m'assurer du problème, j'ai fait 2 fois l'installation et la manipulation. La première fois, j'ai même eu droit à un plantage du gestionnaire de paquets. Peut-être que Fedora a par ailleurs de bons outils de configuration système (j'ai regardé un peu l'intégration NIS/LDAP/Kerberos ça m'a plu), mais si le plus important est (toujours) défaillant, ça fait fuire.

Allez pour la route, une petite capture d'écran pour que vous faire une idée du niveau de crédibilité de la gestion des paquets sous Fedora 8:

armenie

(Vous pouvez aussi en déduire que personne n'utilise Fedora, en français du moins, sinon ce genre de bourdes aurait était détecté)

samedi, avril 5 2008

Unix 64bits fun

I used to work within a team of windows admins. I saw them strugling with applications requiring too much memory for Windows 32bits. Maybe some people run Windows 64bits, but i've never seen that: applications comes from everywhere and are 32bits only. Moreover, the kernel/user split is 2G/2G and that's pretty small for a Java process. Most servers i've seen have 4GB of memory (usually only 3GB are managed on common^Wbroken configs) and are dedicated to a small set of applications, so there's really no point in adding more memory. Oh, and yes, we run hundreds of Windows servers, not for fun.

But i've switched back to the bright side and left that windows world: i now play with unix servers, big filers and tape libraries. I've just realized that most of the linux workstations are 64bits and have at least 8GB of RAM. Yup, that's twice more than the biggest Windows servers we run...

This week, we had to recover a somehow low-end server and install RHEL on it. When i say 'low-end', i mean an old Dell or HP server garbage-collected to set-up some test environment, nothing valuable to the company. The server booted, and damn, the RAM-check took 40s ... 49152MB. Yes, 24 x 2GB on a 'low-end' server. So i asked my workmate why there were so much RAM on a simple server:

We don't tune applications, we add more memory. he said.

That's true unix speech :)

vendredi, mars 28 2008

There and back again

For more than a year, i've been the NetApp NetCache (proxies) worldwide guru at some very big company in Pau.
But on the first week-end of March, i moved from Pau (South West) to Clermont-Ferrand (Center) (that's 600km away) to start a new position as a Unix admin (mostly AIX servers). But i ended up doing uninteresting things (to me), i felt sick, i couldn't stand the job and I was very disapointed. Today i've accepted a real Unix admin job back in Pau ...
I'm really sad because most of my friends are in Clermont-Ferrand. It kills me to say so, but i need a not-awfull job to be happy, even if i have lots of friends around. Being in Clermont-Ferrand was like starting a new life. Friends are everyting.
On Tuesday i'll be back in Pau and hope to stabilize a bit (at least for a full month ;).

mardi, mars 18 2008

WTF

system-monitor is getting famous !
(This is bug#418652.)

jeudi, février 21 2008

Power management failure

Tonight i was hacking on my ibook on my sofa watching Extreme Makeover. Then "peeeeeeeeeeeewwwwwwwwwwwww". No more battery.
I haven't received any warning at all. Maybe gnome-power-manager is a bit broken currently on Debian/sid because of hal/s2ram/whatever on ppc. I mean s2ram and hal works, but no the way gpm likes them too (i have to manually run s2ram to suspend). But at least , I would have expected gpm to warn me, and then shutdown my laptop. Yep, i've checked, when the battery level becomes critical, it should have poweroff. But that did not happen.
Now i only trust the battery gauge LEDs.
Happy End: thanks to reiserfs and emacs, i haven't lost a single line of code :)

jeudi, décembre 27 2007

Empoisonnement

Vivement l'interdiction de fumer dans les bars et partout. J'ai vraiment été stupide d'y retourner hier soir.
En attendant 2008, fumeurs, je vous gerbe à la gueule.
(C'est réciproquement l'effet que me fait votre merde, mes fringues sont pourries, j'ai les yeux explosés, etc).

lundi, décembre 10 2007

GNOME system monitor team

Bienvenue Karl !

samedi, novembre 24 2007

bootparam mem=128M

Emmanuel is right. A lot of people in the world, our users, have computers with 128MiB. I can't believe it's possible to run GNOME with that few memory. At least you have to kill a couple of applets and disable all python plugins.
So on 12/8 i will boot my laptop with boot=128M for one day, to see what it feels like. If you want to follow me...

jeudi, octobre 18 2007

Bonne fête Luc !

Je que l'homme de la situation !

mercredi, octobre 10 2007

ur doin it wrong

How does a Windows developer send a patch ? He opens Beyond&Compare (GUI Tool), prints the screen into a PDF and emails it.

Internet Explorer sucks

Today, I'm working on setting up a new HTTP 403 error page on a web proxy: this is what the user gets when access is denied by ACL. I've improved the error page to display URL, date, username, etc so i can get more meaningful messages from the helpdesk. Users are running Windows XP SP2.
Here's a silly IE6 bug:

  • when the URL is HTTP and is blocked by the proxy, the proxy sends a 403 with an error page. The page is correctly displayed.
  • but when the URL is HTTP tunnel (=https://), the proxy still sends the 403 error page but IE6 truncates the display to the first 1024 bytes...


So get and of course run .

mercredi, septembre 19 2007

IPv6 or NAT

I know the various issues about IPv6. Many people suggest that NAT is part of the solution, at least for company networks. But where i work, NAT is not : we're running out RFC1918 addresses...

lundi, septembre 10 2007

loc-srv

So this weekend, i used a DSL without any NAT, so my laptop was assigned a public IP by DHCP. My ulog log was spitting a lot, mainly on tcp port loc-srv / 135. Instead of sending REJECT, i opened my iptables and started the following ruby program to actually open all these connections. When someone sends me a SYN, I reply politely.

require 'socket'
require 'etc'

nobody = Etc.getpwnam('nobody')
loc_srv = Socket::getservbyname('loc-srv')

Dir.chroot('/var/run/empty')
Dir.chdir('/')

server = TCPServer.new(loc_srv)

Process::UID.change_privilege(nobody.uid)

print <<"EOF"
uid/euid #{Process.uid}/#{Process.euid}                                                                                                        
chrooted in #{Dir.pwd}                                                                                                                         
listening on address #{server.addr.inspect}                                                                                                    
EOF

clients = []

loop do
  begin
    client = server.accept_nonblock
  rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR
    IO.select([server])
    next
  end

  # remember client so the connection stays opened                                                                                             
  clients << client
  print "#{client.peeraddr.inspect} connected
"
end

This script needs to be started with some privileges in order to bind on 135, but then it drops its priv and chroot to somewhere safe. That was very instructive, after ~10minutes, ss | grep -c loc-srv was reporting more than 280 connections from ~80 differents hosts.

What a storm. I'm definitely safe under my GNU+Linux umbrella :)

And Ruby is fun :)

mercredi, septembre 5 2007

JhAutobuild

JhAutobuild provides jhbuild logs on Debian Etch amd64. That's pretty useful :)

vendredi, août 10 2007

redundant UI

I don't think i have a bad memory, but even if i had memory like a goldfish, i would still be able to use pidgin :

pidgin chat

jeudi, juin 28 2007

Filesystem ACL

If you're looking for a good tutorial about ACL, this one is pretty good.
Nautilus doesn't support this yet (gnome-vfs provides support for it), but this looks just like what i'd like to get.

desklets

I can see more and more screenshots about moonlight-based desklets.
Hey guys, gdesklets has been around since Fall 2003 !

jeudi, juin 21 2007

we need distributed control system

I have a commit access to GNOME svn, so i'm able to do whatever i want with my code, and then commit it. My main free software contribution has been GNOME for a long time.
I've recently started to hack on awffull (log analyser, it's a webalizer fork, but webalizer is dead). I keep submitting patches on the mailing lists, i'm mainly interested in memory usage, which is a real issue with huge logs, and even more on 32bits (allocating more than 2GiB is risky). One of my patch provides a 7% memory usage improvement by using flexible arrays : this saves millions of malloc calls so heap admin / malloc overhead is much lower.

But, even if Steve (upstream) and the mailing list people are great and very responsive, my patches have not been merged yet. I totally understand why they are not already merged, but i have no way to provide my branch to other awffull fans. So i started stacking everything in a local git repository. But now I need again and again to resplit the patches because upstream just can't merge my changes. I now realize how much we need distributed control system (git, monotone, etc). Without it, patches get lost on mailing lists, they get obsolete, they don't apply anymore ... a big waste of work.

With a distributed control system, upstream is able to pull from contributors, merge or cherrypick.

I'm frustrated about awffull, i now better understand how people could be frustrated about GNOME.
I am sorry for everyone (hackers, packagers, etc) who work hard on free software but are unable to (easily) get their job upstream because of the stupid VCS we are still using.

mercredi, juin 13 2007

Indiana patches

Dear Sun Microsystems, I think your patches are bullshit. Please drop them or as already suggested, do fork.
As the maintainer of system-monitor and libgtop, i have already rejected stupid patches from you. They contain unkown API changes and a lot of dead code. The libgtop patch is the most scary. Here's a tip: libgtop code is OS specific (linux, bsd, solaris, etc have their own separate implementation) so copying linux code to solaris is obviously NOT going to work.
I can see that some of your patches are actually OK, but your people don't seem to understand how we work.
This reminds me of that private mail where you asked me to re-license libgtop to LGPL because you had some kind of packaging issues ... because you wanted to install libgtop in /foo/bar and instead of /foo/baz. Bad for you.

- page 2 de 4 -