Je voulais qqchose dans le genre, mais mon problème avec le us-intl c'est que ça transforme certaines touches en dead keys - e.g., les guillemets doubles deviennent une dead key par défaut, ce qui est horripilant pour coder.
Du coup je me suis fais mon propre layout, une modification minimale du US normal: http://pierre.palatin.fr/entries/us-custom
La seule différence avec un US normal, c'est que quand tu fais alt-fr- ça produit un accent - soit via une dead key, soit directement:
altgr-` : dead grave accent
altgr-' : dead acute accent
altgr-^ : dead circonflex accent
altgr-" : dead diaresis
altgr-a : à
altgr-e : é
altgr-c : ç
altgr-u : ù
In [13]: Plop().__class__
Out[13]: <class '__main__.Plop'>
In [14]: Plop.__class__
Out[14]: <type 'type'>
Toute (nouvelle) classe est sensée être déclarée comme hériter de 'object' (new style class). Une classe est donc également un objet.
Devoir 'object' manuellement est effectivement p-e pas très joli, mais cela a été fait pour garder la compatibilité avec les versions précédentes de python. Amha, le gain "garder compatibilité avec une legere surcharge syntaxique" est nettement plus intéressant que "avoir les classes comme des objets" qui en pratique est certe joli mais moins souvent utile que une bonne compatibilité ascendante.
Python 3k corrige cela, hériter de 'object' n'est plus nécessaire.
Ce n'est pas parce que l'url est accédée que ca veut dire que ce sera nécessairement rajouté dans l'index du moteur de recherche. Je ne sais pas ce qui est fait, mais on peut imaginer par exemple que ca accède à l'url pour vérifier que ce n'est pas un site de phishing ou avec des trucs tout pas beaux (i.e. virus et autre trojans) dedans, ou encore pour essayer de mettre des pubs plus ciblées...
Les IOIs, c'est vraiment un bon moment en tout cas... Coté "ambiance", c'est une semaine à cotoyer des gens de 200 pays, dans une atmosphère très sympa et à visiter les environs du lieu d'organisation. Chaque équipe a un guide local qui reste pendant toute la semaine avec l'équipe. Rien que ces trucs là, ça vaut le coup déjà :) .
Coté épreuves, bien que ce soit très fortement orienté algorithmie, le fait de limiter en ressources (mémoire & temps) donne un peu d'importance au coté "informatique" je trouve. Avant, c'était sous Dos et donc fallait faire avec 640ko, pas le choix (et pas de dos extender :). Je me souviens notamment d'un problème où il fallait trouver une zone ayant certaines caractéristiques sur une carte, mais la carte de pouvait pas rentrer complétement en mémoire. J'avais implementé un truc qui la compressait sommairement histoire que ça rentre (bon, dommage le reste était buggué, mais sinon ça aurait pu grapiller des points :) .
Et sinon pour la question des sujets en anglais, de mon temps c'était les accompagnateurs de chaque équipe qui , s'ils le désiraient, pouvaient traduire les sujets pendant la nuit avant l'épreuve. Chaque candidat recevait ensuite à la fois la version originale et la version traduite.
Non, en pratique ce qui est dit dans le thread c'est que le frontend C typiquement va compiler en dur le code. Ainsi par exemple, un sizeof(long) transformé par un llvm-gcc 64bits donnera '8' et un 32bits donnera '4' quelque soit l'interpreteur/JIT/compilo de représentation intermediaire utilisé (garanti testé à l'instant :). Donc le risque principal est un problème d'optimisation si jamais les plateformes sont trop différentes - mais probablement rien de trop violent souvent. Le code devrait continuer à fonctionner quelque soit l'host.
Après, effectivement, il est possible de faire des trucs gore en C/C++ et il est probablement possible d'introduire des bugs de cette manière; mais il s'agit de bugs du programme, qui seraient apparus de la même manière si le programme avait été recompilé "normalement" pour une autre archi.
(après je suis pas vraiment un utilisateur de LLVM autrement que pour des tests, donc je peux me tromper; mais c'est ce qui est dit dans le thread en question & les docs et c'est cohérent avec l'interpréteur que j'ai décortiqué)
Même si effectivement il y a toujours des bugs potentiels dans gcc et que donc c'est pas à exclure, amha considère que le problème est dans ton code, ce sera vrai dans 99% des cas...
Ce genre de comportement (bug avec certaines versions de gcc et pas d'autre et selon les options de compimation) est assez classique de problème de gestion de la mémoire. Donc à mon avis, la première chose à faire est de passer ton programme (avec infos de debug) à valgrind et de corriger *toutes* les erreurs que valgrind te dit.
Même remarque pour valgrind que pour gcc : souvent on se dit "ah ouais mais il a tort" - mais en pratique il se trompe très rarement, surtout sur du code pas trop tricky. La STL fait dire à valgrind des fois que il y a des leaks (pareil pour pthread) mais ce n'est pas les leaks qui sont probablématiques en l'occurrence :)
Un autre truc à tester, surtout si tu es friand de casts dans ton code, c'est de compiler avec du -fno-strict-aliasing ; les problèmes liés au strict aliasing représentent le bug le plus souvent signalé ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920 ), mais il ne s'agit *pas* d'un bug de gcc. Voir la page de man de gcc pour plus d'infos sur le pkoi du comment du strict-aliasing (en gros, une règle du C dit que deux pointeurs de type différent, par ex. int* et float*, pointent nécessairement sur des données différentes, ce qui permet à gcc de faire des optimisation plus agressives).
Je connais un seul vrai whiteboard partagé libre, c'est Coccinella : http://hem.fyristorg.com/matben/
Personnellement je le trouve pas très joli; je ne l'ai jamais beaucoup utilisé mais les qq retours que j'ai ne sont pas forcément très positifs. A tester néammoins.
Inkscape a un système pour travailler, via du jabber, à plusieurs sur un même dessin; je ne sais pas si c'est encore que dans le SVN, ou c'est déjà incorporé à une release.
Mais globalement, c'est quelque chose qui manque vraiment en libre (il existe plusieurs systèmes propriétaires), surtout que l'aspect libre permettrait l'emergeance de beaucoup de plugins & customisations indispensables pour ce genre de truc. J'imagine que c'est le même cas que toi à peu près, ici à l'inria ça nous servirait souvent :) Ca m'a traversé l'esprit plus d'une fois de commencer cela, mais le temps étant ce qu'il est, on fait avec les moyens du bord...
> ce qui signifie un overhead pour émuler le comportement de ces composants, alors que l'idéal serait d'exploiter le vrai matériel au plus près
Non, à partir du moment où tu dois émuler, tu n'as (quasiment) aucun interêt à suivre ce qu'il y dessous.
Une approche intéressante pour ce genre de problème est que l'émulateur fournisse un accès direct au matériel sous jacent. Cela est faisable en USB (qemu le fait, vmware également); cependant, en PCI, cela pose des problèmes de mapping mémoire et imposerait au mieux des drivers plus ou moins prévu pour (et c'est p-e même impossible dans certains cas). Je ne sais pas si les extensions VT & SVM apportent qqchose à ce niveau là (proxy de périphériques), mais je n'ai rien vu, donc je suis sceptique.
Pour le cas de l'opengl, un patch était passé sur la mailing list : http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg0014(...) . En gros, il s'agit d'un proxy opengl, qui fait passer les requêtes à l'host. Cela nécessite un support soft dans le client; je n'ai rien vu passer pour windows. Je crois que vmware le permet par contre.
Quand à écrire des pilotes pour, c'est effectivement pratique comme approche, mais manifestement ça n'a intéressé personne suffisament :) p-e voir ce qu'il y a dans virtualbox. Cependant et comme tu le fais remarquer, à partir du moment où c'est pour un OS libre, vaut mieux tout adapter pour faire de la paravirtualisation (à la xen donc). Cela dit, pour le cas de l'affichage, ça reste problèmatique, vu que tu as très peu de marge sur ce que tu peux faire pour des questions de performance.
Bon, pas mal des langages que tu cites sont impératifs, donc autant essayer d'aller voir un peu ce qu'il y a de vraiment différent; c'est toujours bon d'avoir du recul (ça permet de troller plus efficacement).
* Forth : ça c'est un langage qu'il est fun. Des règles de bases extremement simples qui permettent de construire des choses évoluées. Pas mal utilisé dans l'embarqué, puisque ça permet d'avoir un interpreteur built-in sur quasi n'importe quoi (genre un micro-controlleur) tout en permettant des manips subtiles (à vue de pif, le "bios" des motherboard à base de Niagara doivent en avoir par exemple). Les bases se voient rapidement avec un tutorial.
* Lisp : globalement, à chaque fois qu'un langage permet un nouveau moyen d'exprimer une concept ou une construction, tu auras toujours un lispeux qui te dira "ouais, on le fait déjà en lisp". Amha d'ailleurs c'est pas complètement faux, à partir du moment où tu ignores les supports syntaxique; perso "Syntax does matter", donc ... Ce qui fait à mes yeux la force de ce langage, c'est le fait de pouvoir facilement manipuler du code (représenté sous forme de liste) à partir d'un morceau de code (toi aussi résoud direct les problèmes d'introspection :) .
* Haskell : parce qu'il est bon de connaitre les langages fonctionnels. Haskell est connu pour être un peu plus "pur" (aheum) que OCaml niveau approche fonctionnelle et beaucoup d'articles de recherche sur les langages utilisent la notation Haskell pour présenter une sémantique. OCaml est aussi bon à connaitre, car il propose qqchose d'extremement réaliste pour un langage fonctionnel (d'aucun dirait "ouais, parce qu'il propose aussi de l'impératif" :) )
* Erlang : Non pas pour son aspect fonctionnel mais pour tout ses aspects redondance, failover, remplacement à chaud, qui donnent un très bonne idée de ce qui est possible de faire (et c'est impressionant) avec un bon support du langage. Pour te faire une idée, tu peux changer du code qui est en train de tourner sans interruption et si jamais la modif est invalide, Erlang repassera sur l'ancienne version sans interruption.
* Prolog : un peu comme pour Forth, l'approche de Prolog est vraiment différente des langages impératif et fonctionnel. C'est pas le langage le plus à la mode, mais il nécessite une manière de penser ses algos assez intéressante je trouve. Et comme toujours ça permet de voir qu'il n'y a pas qu'une seule approche pour exprimer un problème.
Sinon, pour rester dans les impératifs :
* Python, parce que je l'aime bien, qu'il est super clean & régulier
* Ada 95, qui malgré une image un peu vieillotte a un pouvoir d'expression assez peu commun et te fais comprendre des concepts qui restent implicites dans d'autres langages.
Et la lecture de http://lambda-the-ultimate.org/ t'intéressera si tu as envie de suivre un peu ce qui se fait au niveau des langages informatiques.
Sur mon amd64, je suis en cooker x86_64. Pour être tranquille, j'ai mis à la fois les media x86_64 et ceux i586, ce qui en pratique marche assez bien, il faut juste des fois faire un peu attention quand tu installes un nouveau soft (et encore).
En pratique ça donne:
* J'ai les libs 32 et 64 qui cohabitent nickel
* Pour les upgrades automatiques, j'ai mis "strict-arch: 1" dans le urpmi.cfg, comme ça, ça respecte mon choix 32 ou 64 pour chacun des packages
* Comme mes medias sont bien nommés, pour forcer l'installation d'un package en 32, il me suffit de faire : urpmi --media 32 coincoin
* J'ai un chti script pour vérifier les rares packages (hors bibliothèques) qui sont installé en i586, ça permet de suivre les boulettes :)
* Les seuls trucs en i586 que j'ai, c'est mplayer & codecs associés ainsi que opera
* Pour les plugins proprio, j'utilise opera
* Pour les trucs obscurs récalcitrants (très très rare), comme les libs i586 sont installées, une commande 'linux32' suffit.
Au final ça marche très bien, pas de problème particulier lié au 64bits pour la maintenance du système. Le seul risque est que des fois les versions des packages 64bits sont un chouille en retrait des packages i586 sur cooker (c'est rare), donc si jamais j'installe un nouveau package qui est dans ce cas, il voudra par défaut me mettre du i586, mais ça se voit vite :)
En fait, il est loin d'être évident que UML soit plus performant que du Qemu (avec du kqemu en mode kernel) ou du vmware, particulièrement dans le cas de code avec beaucoup de syscalls (typiquement, quand il y a des I/O à la pelle).
Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.
Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.
Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).
Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...
(et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)
Effectivement, j'ai le même genre de problèmes, puisque je veux pouvoir utiliser indifférement mes différentes machines (machine du taf, laptop, machine persos, ...).
Pour la messagerie instantanée, j'utilise Bitlbee, qui permet d'avoir de l'IM classique dans un client IRC. Comme j'utilise comme client IRC un irssi dans un screen, je peux récuperer mes sessions d'IM n'importe quand de n'importe où, très très pratique.
Pour l'email, même solution, serveur IMAP, avec tri (procmail) et indexation (mairix) sur le serveur.
Pour le web & les bookmarks, j'utilise en fait un wiki. Alors c'est pas tout à fait le même usage que des bookmarks, mais c'est bien pratique. En gros, j'ai une page 'Scratchpad' sur mon wiki, dans laquelle je mets en vrac les infos que je veux garder (url d'un site/article à voir, citation, commande intéressante, whatever). Relativement pratique à l'usage, mais ça mériterais une intégration plus poussées avec le reste du système.
Pour le calendrier, perso j'utilise WebCalendar ( http://www.k5n.us/webcalendar.php ). L'interface est pas très joli, mais je le trouve extremement pratique. Pour l'instant (version 1.0.X), tu peux avoir du iCal dans ton client lourd de calendrier que en lecture seule, mais la lecture ecriture est présente dans la version 1.1 en cours de développement. Il gère les calendriers multiples, les trucs publiques, etc ...
Pour les RSS, j'utilise une solution simple : mes flux RSS me sont envoyés par email, donc c'est mon IMAP qui se charge du lu/pas lu centralisé :) J'utilise rss2email pour cela, simple et efficace (un peu trop simple même - j'aimerais pouvoir régler le délai de fetch de chaque flux).
J'ajouterais également que avoir un Wiki (noter ses idées, liste de course, todo, whatever et un Subversion (sources, documents, ...) est réellement pratique pour plein de choses.
Un autre problème est pouvoir travailler en mode déconnecté (le laptop dans le train typiquement); là, il y a vraiment pas grand chose. Il y a l'imap déconnecté qui marchotte; j'aimerais aussi pouvoir avoir des copie de mon wiki (avec synchro au retour), mais il n'y a pas grand chose de satisfaisant pour le moment.
Tu as pensé à diminuer le MTU des machines sur ton réseau ? Chez mes parents il y avait aussi un routeur/wifi/adsl et qui faisait des symptomes bizarres (genre connexion très lente, impossibilité de faire certaines requetes en POST, etc ...).
Après avoir suspecté une surchauffe (c'est clair que fallait pas laisser les doigts sur le proc ...), ben on a pensé au MTU et depuis ça marche nickel.
Manifestement ça a l'air un défaut courant d'avoir une mauvaise fragmentation IP. Le MTU de ce genre de truc étant souvent autour de 1400/1450 et celui standard de 1500, ça peut faire ce genre de comportement. Le plus simple est de diminuer ton MTU vers 1400 pour tester. (Il existe plein de méthodes pour y déterminer automatiquement, notamment via 'ping', un passage sur ton moteur de recherche favori devrait te donner des infos).
Sous nux, pour changer le MTU d'une interface :
ifconfig eth0 mtu 1400
Bon par contre pour l'interface ça ne change rien et c'est clair que les procs sont dimensionnés vraiment limite (pour réduire les coûts).
Tu peux aussi demander à ce que te soit envoyé un mail à chaque fois qu'un message t'es laissé sur le répondeur (c'est une option à activer sur le site). Et il se trouve que ça envoie en pièce jointe un fichier "message.ra" qui est, je pense, le message en format Real Audio. J'ai pas vérifié si c'était bien ça vu que mon mplayer favori ne lit pas ce format là (et que j'ai la flemme d'installer le lecteur de Real), mais ça se tiendrait ...
Tu trouveras la toutes les docs & les détails sur ce qu'il faut savoir pour faire mumuse avec une machine quand tu es (vraiment) au niveau système (et donc notamment les infos sur partitions & filesystems).
Sous windows, pour pouvoir annoter sur tout et n'importe quoi, il y a une imprimante vers 'journal windows', un peu comme il y a une imprimante vers pdf. Le format 'journal' (.jnt) est un format de Microsoft, à vue de pif fermé (je n'ai pas cherché en détail), qui peut ensuite être ouvert avec l'utilitaire kivabien; on peut ainsi prendre des notes sur n'importe quoi. Très pratique pour corriger les rapports des étudiants par exemple :)
Sous linux, il n'y a pas grand chose pour pouvoir écrire sur n'importe quel document. Il y a 'gournal' qui existe, un utilitaire en perl de prise de note, mais ça reste assez basique, il a l'air d'avoir du mal à marcher (aucune icone qui apparaissent, etc.; ça doit être relativement simple à corriger mais bon ...). Mais surtout, ce n'est pas prévu pour l'écriture sur n'importe quel document, et cela manque vraiment.
Sur mon tabletPC (Acer c112), le support du stylet passe au poil (j'ai juste du faire un calibrage manuel), ça utilise le driver Wacom (libre).
Pour la reconaissance d'écriture, il n'existe pas grand chose. Il y a xstroke qui est quand même assez sympa; écriture grafitti sur tout l'écran, i.e. on peut tracer ses lettres n'importe où. Malheureusement ça rentre un peu en conflit avec des widgets genre les barres de scrolling de Qt; pas de problème avec GTK (les raisons sont expliqués dans les docs).
Niveau claviers virtuels, j'en ai essayé quelqu'uns (gtkeyboard entre autres), mais seul xvkbd me convient pour l'instant (ne pas prendre trop de place à l'écran, envoi direct des touches à l'application, etc). Après il y a un problème d'intégration, comme par exemple faire apparaitre xvkbd lors du xdm/gdm/kdm mais avec qq scripts ça ne devrait pas trop poser de problème.
Le plus gros problème reste la rotation de l'écran. Xorg (et Xfree86 je suppose) la supporte via le fichier de config pour le driver fbdev, mais cela impose de redémarrer X, ce qui n'est vraiment pas pratique (ou lancer plusieurs instances, ce qui revient un peu au même vu qu'il n'y a pas moyen simple de faire transiter une appli d'un serveur X à l'autre). J'ai un peu regardé pour y faire via du RandR, mais à l'heure actuelle aucun driver de Xorg n'implémente la rotation et le driver fbdev n'est pas prévu pour une réinitialisation de l'affichage à chaud (bref j'ai des bugs fun :)
Bon donc globalement il y a quasiment tout ce qu'il faut (à part la rotation mais vu comme ça bouge pas mal pour les serveurs X ces temps ci, j'ai bon espoir), mais chaque élèment est toujours un peu limite; et il faut avoir du temps pour y configurer.
Sinon il y a aussi tout les problèmes classiques des portables, le plus commun étant le suspend to ram / to disk, qui marche mal chez moi et c'est vraiment génant ça ...
(pour une vision à plus terme, travailler avec SPE peut être intéressant, puisque s'il marche bien, il pourrait être intégré à php ou au moins être dispo chez des hébergeurs... mais bon c'est sûr que pour le moment, ben faut faire avec l'existant ...)
ViewCVS (http://viewcvs.sourceforge.net/(...)) supporte également Subversion dans ses versions récentes.
Tu as aussi Trac (http://www.edgewall.com/trac/(...)) qui est un gestionnaire de projet mais qui a une partie pour visionner un repositery Subversion (assez joli à mon goût, mais très basic au niveau des fonctionnalités; il manque notamment des possibilités pour faire des diffs arbitraire).
Mais ceux là également ne fonctionnent que sur un repositery local, donc en accès via 'file:///', ce qui peut poser pas mal de problèmes; je ne connais pas d'interface web qui le permette.
Pour l'accès à du subversion, il y a une API php qui existe, par les créateurs de subversion : http://spe.tigris.org/(...)
Par contre, je sais pas trop si c'est utilisable en l'état actuel ...
Pour les protocoles, il en existe plusieurs; accès direct au repositery ou via "svnserve" ou via http.
"svnserve" utilise un protocole dédié. L'accès http utilise une extension normalisée pour avoir du versionning sur WebDAV, donc tu devrais trouver ton bonheur dans les RFCs. Pour plus de détails, le Subversion book : http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-8-sect-1.2(...)
A mon humble avis, il vaut mieux faire un binding vers l'API subversion, c'est plus propre & plus extensible (support des différents protocoles par exemple). Sauf si tu veux qqchose qui marche uniquement avec du php, sans extension, et sans la présence d'un client subversion, auquel cas il devient effectivement nécessaire de réimplementer le procotole en php.
Une des grandes forces de python est sa capacité d'instrospection, réflexivité et auto modification. Typiquement on peut tout à fait imaginer des variables dont le type dépende de données disponibles uniquement à l'exécution. Cela peut par exemple aider pour certaines partie d'un parseurs. Il y a aussi dans la même veine les 'metaclass' qui permettent de générer des classes à la volée. Les cas où c'est effectivement réellement utiles ne manquent pas, mais il faut avoir un peu d'habitude pour bien y saisir souvent ...
Bien sûr, tout cela est contournable et il possible de s'en passer (MetaOCaml par exemple doit implémenter des possibilités un peu similaires); mais ce qu'on gagne, dans un certain sens, en performance ou en 'sureté' (vaste problème...), on le perd également beaucoup en souplesse.
Si tu continue à faire du python, essaye d'exploiter à fond ses possibilités, ça change pas mal d'approches pour beaucoup de problèmes (ce qui est souvent appellé "the pythonic way"). On peut souvent exprimer un problème de manière bien plus concise (moins de redondance notamment) sans pour autant perdre trop en lisibilité. Un fil de news intéressant pour python : http://www.pythonware.com/daily/(...)
Pour ce qui concerne psyco je te conseille de lire un peu les articles donnés sur le site avant de chercher à faire un truc "plus intelligent"; tu verras, c'est déjà assez subtil :) (en plus tu verras d'autres raisons qui font que python n'est pas vraiment compilable au sens classique du terme).
Accessoirement, le typage statique semble faire couler pas mal d'encre dans la communauté python actuellement; car s'il est pas possible (en l'état actuel) de faire de l'inférence de type, il est pourrait être intéressant de spécifier à certains endroit explicitement le type, pour des question de clarté de code, de sureté ou d'optimisation.
Sous mandrake, tu as 2 commandes pour manipuler ça;
* 'service <programme> [start|stop|...]' pour manipuler les services tournants actuellement. Par exemple, pour arrêter apache, il faudrait faire : 'service httpd stop'. A noter que ça l'empêchera pas de redémarrer au prochain reboot
* 'chkconfig' pour lister / manipuler les services lancés au démarrage.
- Pour avoir la liste : 'chkconfig --list'
- Pour ne pas démarrer un service au démarrage : 'chkconfig <programme> off'; par exemple, pour ne pas démarrer apache : 'chkconfig httpd off'
(le tout en root)
Le mandrake control center permet aussi de faire cela.
Ces commandes sont spécifiques mandrake (et probablement Redhat/FC/Suse). Ce sont des raccourcis pour manipuler le 'SysVInit', système qui permet de gérer le démarrage de ta distrib. Ainsi, 'service' appelle les scripts de /etc/rc.d/init.d et 'chkconfig' manipule les liens symboliques de /etc/rc.d/rcX.d. Je te conseille http://lea-linux.org/admin/daemons.html(...) si tu veux comprendre le fonctionnement en détail.
# Layout custom
Posté par Pierre Palatin (site web personnel) . En réponse au journal Comment taper les accents sur un clavier QWERTY?. Évalué à 2.
Je voulais qqchose dans le genre, mais mon problème avec le us-intl c'est que ça transforme certaines touches en dead keys - e.g., les guillemets doubles deviennent une dead key par défaut, ce qui est horripilant pour coder.
Du coup je me suis fais mon propre layout, une modification minimale du US normal: http://pierre.palatin.fr/entries/us-custom
La seule différence avec un US normal, c'est que quand tu fais alt-fr- ça produit un accent - soit via une dead key, soit directement:
altgr-` : dead grave accent
altgr-' : dead acute accent
altgr-^ : dead circonflex accent
altgr-" : dead diaresis
altgr-a : à
altgr-e : é
altgr-c : ç
altgr-u : ù
[^] # Re: Python vs Ruby
Posté par Pierre Palatin (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 2.
In [12]: class Plop(object):
....: pass
....:
In [13]: Plop().__class__
Out[13]: <class '__main__.Plop'>
In [14]: Plop.__class__
Out[14]: <type 'type'>
Toute (nouvelle) classe est sensée être déclarée comme hériter de 'object' (new style class). Une classe est donc également un objet.
Devoir 'object' manuellement est effectivement p-e pas très joli, mais cela a été fait pour garder la compatibilité avec les versions précédentes de python. Amha, le gain "garder compatibilité avec une legere surcharge syntaxique" est nettement plus intéressant que "avoir les classes comme des objets" qui en pratique est certe joli mais moins souvent utile que une bonne compatibilité ascendante.
Python 3k corrige cela, hériter de 'object' n'est plus nécessaire.
# Accèder à la page ne veut pas dire mis dans l'index...
Posté par Pierre Palatin (site web personnel) . En réponse au journal Surveillance électronique (MSN, YIM). Évalué à -3.
# Les IOIs, c'est bien
Posté par Pierre Palatin (site web personnel) . En réponse à la dépêche 3 médailles françaises aux olympiades internationales d'informatique (ioi). Évalué à 2.
Les IOIs, c'est vraiment un bon moment en tout cas... Coté "ambiance", c'est une semaine à cotoyer des gens de 200 pays, dans une atmosphère très sympa et à visiter les environs du lieu d'organisation. Chaque équipe a un guide local qui reste pendant toute la semaine avec l'équipe. Rien que ces trucs là, ça vaut le coup déjà :) .
Coté épreuves, bien que ce soit très fortement orienté algorithmie, le fait de limiter en ressources (mémoire & temps) donne un peu d'importance au coté "informatique" je trouve. Avant, c'était sous Dos et donc fallait faire avec 640ko, pas le choix (et pas de dos extender :). Je me souviens notamment d'un problème où il fallait trouver une zone ayant certaines caractéristiques sur une carte, mais la carte de pouvait pas rentrer complétement en mémoire. J'avais implementé un truc qui la compressait sommairement histoire que ça rentre (bon, dommage le reste était buggué, mais sinon ça aurait pu grapiller des points :) .
Et sinon pour la question des sujets en anglais, de mon temps c'était les accompagnateurs de chaque équipe qui , s'ils le désiraient, pouvaient traduire les sujets pendant la nuit avant l'épreuve. Chaque candidat recevait ensuite à la fois la version originale et la version traduite.
[^] # Re: Petite explication ?
Posté par Pierre Palatin (site web personnel) . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 3.
Après, effectivement, il est possible de faire des trucs gore en C/C++ et il est probablement possible d'introduire des bugs de cette manière; mais il s'agit de bugs du programme, qui seraient apparus de la même manière si le programme avait été recompilé "normalement" pour une autre archi.
(après je suis pas vraiment un utilisateur de LLVM autrement que pour des tests, donc je peux me tromper; mais c'est ce qui est dit dans le thread en question & les docs et c'est cohérent avec l'interpréteur que j'ai décortiqué)
# Valgrind forever
Posté par Pierre Palatin (site web personnel) . En réponse au message Bugs dans g++ ?. Évalué à 4.
Ce genre de comportement (bug avec certaines versions de gcc et pas d'autre et selon les options de compimation) est assez classique de problème de gestion de la mémoire. Donc à mon avis, la première chose à faire est de passer ton programme (avec infos de debug) à valgrind et de corriger *toutes* les erreurs que valgrind te dit.
Même remarque pour valgrind que pour gcc : souvent on se dit "ah ouais mais il a tort" - mais en pratique il se trompe très rarement, surtout sur du code pas trop tricky. La STL fait dire à valgrind des fois que il y a des leaks (pareil pour pthread) mais ce n'est pas les leaks qui sont probablématiques en l'occurrence :)
Un autre truc à tester, surtout si tu es friand de casts dans ton code, c'est de compiler avec du -fno-strict-aliasing ; les problèmes liés au strict aliasing représentent le bug le plus souvent signalé ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920 ), mais il ne s'agit *pas* d'un bug de gcc. Voir la page de man de gcc pour plus d'infos sur le pkoi du comment du strict-aliasing (en gros, une règle du C dit que deux pointeurs de type différent, par ex. int* et float*, pointent nécessairement sur des données différentes, ce qui permet à gcc de faire des optimisation plus agressives).
# coccinella & inkscape
Posté par Pierre Palatin (site web personnel) . En réponse au message Tableau magique réseau. Évalué à 3.
Personnellement je le trouve pas très joli; je ne l'ai jamais beaucoup utilisé mais les qq retours que j'ai ne sont pas forcément très positifs. A tester néammoins.
Inkscape a un système pour travailler, via du jabber, à plusieurs sur un même dessin; je ne sais pas si c'est encore que dans le SVN, ou c'est déjà incorporé à une release.
Mais globalement, c'est quelque chose qui manque vraiment en libre (il existe plusieurs systèmes propriétaires), surtout que l'aspect libre permettrait l'emergeance de beaucoup de plugins & customisations indispensables pour ce genre de truc. J'imagine que c'est le même cas que toi à peu près, ici à l'inria ça nous servirait souvent :) Ca m'a traversé l'esprit plus d'une fois de commencer cela, mais le temps étant ce qu'il est, on fait avec les moyens du bord...
[^] # Re: Noyau Linux 2.6.20 et KVM
Posté par Pierre Palatin (site web personnel) . En réponse à la dépêche kqemu devient libre, qemu 0.9.0. Évalué à 4.
Non, à partir du moment où tu dois émuler, tu n'as (quasiment) aucun interêt à suivre ce qu'il y dessous.
Une approche intéressante pour ce genre de problème est que l'émulateur fournisse un accès direct au matériel sous jacent. Cela est faisable en USB (qemu le fait, vmware également); cependant, en PCI, cela pose des problèmes de mapping mémoire et imposerait au mieux des drivers plus ou moins prévu pour (et c'est p-e même impossible dans certains cas). Je ne sais pas si les extensions VT & SVM apportent qqchose à ce niveau là (proxy de périphériques), mais je n'ai rien vu, donc je suis sceptique.
Pour le cas de l'opengl, un patch était passé sur la mailing list : http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg0014(...) . En gros, il s'agit d'un proxy opengl, qui fait passer les requêtes à l'host. Cela nécessite un support soft dans le client; je n'ai rien vu passer pour windows. Je crois que vmware le permet par contre.
Quand à écrire des pilotes pour, c'est effectivement pratique comme approche, mais manifestement ça n'a intéressé personne suffisament :) p-e voir ce qu'il y a dans virtualbox. Cependant et comme tu le fais remarquer, à partir du moment où c'est pour un OS libre, vaut mieux tout adapter pour faire de la paravirtualisation (à la xen donc). Cela dit, pour le cas de l'affichage, ça reste problèmatique, vu que tu as très peu de marge sur ce que tu peux faire pour des questions de performance.
# Histoire de changer de l'impératif
Posté par Pierre Palatin (site web personnel) . En réponse au journal Quel langage pour s'amuser ?. Évalué à 10.
* Forth : ça c'est un langage qu'il est fun. Des règles de bases extremement simples qui permettent de construire des choses évoluées. Pas mal utilisé dans l'embarqué, puisque ça permet d'avoir un interpreteur built-in sur quasi n'importe quoi (genre un micro-controlleur) tout en permettant des manips subtiles (à vue de pif, le "bios" des motherboard à base de Niagara doivent en avoir par exemple). Les bases se voient rapidement avec un tutorial.
* Lisp : globalement, à chaque fois qu'un langage permet un nouveau moyen d'exprimer une concept ou une construction, tu auras toujours un lispeux qui te dira "ouais, on le fait déjà en lisp". Amha d'ailleurs c'est pas complètement faux, à partir du moment où tu ignores les supports syntaxique; perso "Syntax does matter", donc ... Ce qui fait à mes yeux la force de ce langage, c'est le fait de pouvoir facilement manipuler du code (représenté sous forme de liste) à partir d'un morceau de code (toi aussi résoud direct les problèmes d'introspection :) .
* Haskell : parce qu'il est bon de connaitre les langages fonctionnels. Haskell est connu pour être un peu plus "pur" (aheum) que OCaml niveau approche fonctionnelle et beaucoup d'articles de recherche sur les langages utilisent la notation Haskell pour présenter une sémantique. OCaml est aussi bon à connaitre, car il propose qqchose d'extremement réaliste pour un langage fonctionnel (d'aucun dirait "ouais, parce qu'il propose aussi de l'impératif" :) )
* Erlang : Non pas pour son aspect fonctionnel mais pour tout ses aspects redondance, failover, remplacement à chaud, qui donnent un très bonne idée de ce qui est possible de faire (et c'est impressionant) avec un bon support du langage. Pour te faire une idée, tu peux changer du code qui est en train de tourner sans interruption et si jamais la modif est invalide, Erlang repassera sur l'ancienne version sans interruption.
* Prolog : un peu comme pour Forth, l'approche de Prolog est vraiment différente des langages impératif et fonctionnel. C'est pas le langage le plus à la mode, mais il nécessite une manière de penser ses algos assez intéressante je trouve. Et comme toujours ça permet de voir qu'il n'y a pas qu'une seule approche pour exprimer un problème.
Sinon, pour rester dans les impératifs :
* Python, parce que je l'aime bien, qu'il est super clean & régulier
* Ada 95, qui malgré une image un peu vieillotte a un pouvoir d'expression assez peu commun et te fais comprendre des concepts qui restent implicites dans d'autres langages.
Et la lecture de http://lambda-the-ultimate.org/ t'intéressera si tu as envie de suivre un peu ce qui se fait au niveau des langages informatiques.
# Utilisation de media 32 *et* 64
Posté par Pierre Palatin (site web personnel) . En réponse au journal 64bits: prêt ou galère??. Évalué à 9.
En pratique ça donne:
* J'ai les libs 32 et 64 qui cohabitent nickel
* Pour les upgrades automatiques, j'ai mis "strict-arch: 1" dans le urpmi.cfg, comme ça, ça respecte mon choix 32 ou 64 pour chacun des packages
* Comme mes medias sont bien nommés, pour forcer l'installation d'un package en 32, il me suffit de faire : urpmi --media 32 coincoin
* J'ai un chti script pour vérifier les rares packages (hors bibliothèques) qui sont installé en i586, ça permet de suivre les boulettes :)
* Les seuls trucs en i586 que j'ai, c'est mplayer & codecs associés ainsi que opera
* Pour les plugins proprio, j'utilise opera
* Pour les trucs obscurs récalcitrants (très très rare), comme les libs i586 sont installées, une commande 'linux32' suffit.
Au final ça marche très bien, pas de problème particulier lié au 64bits pour la maintenance du système. Le seul risque est que des fois les versions des packages 64bits sont un chouille en retrait des packages i586 sur cooker (c'est rare), donc si jamais j'installe un nouveau package qui est dans ce cas, il voudra par défaut me mettre du i586, mais ça se voit vite :)
# Performances de UML
Posté par Pierre Palatin (site web personnel) . En réponse à la dépêche Virtualisation de Serveur : Linux sous Windows. Évalué à 7.
Clairement, ça reste moins performant que du Xen, cf les benchmarks (venant de l'équipe de xen certes) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.h(...)
Le problème est que pour pouvoir faire tourner du code non modifié, UML doit pouvoir émuler les syscalls en userland. Or pour cela, il n'y a pas énormement de solutions. En l'occurrence, UML surveille l'exécution via ptrace(). Donc à chaque syscall d'un processus guest, il va avoir un switch userland -> kernelland, le kernel s'aperçoit que y'a du ptrace(), retour en userland coté UML, UML fait disparaitre d'un coup de baguette magique le syscall original (et doit laisser probablement un syscall bidon s'exécuter, donc 2 switchs à nouveau), puis s'occupe d'émuler le syscall, ce qui signifie probablement souvent plusieurs syscalls et donc switch userland/kernelland. Et ensuite, 2 derniers switchs pour continuer l'exécution du processus guest.
Or le problème c'est que du switch kernelland/userland, c'est extrêmement lent (un long call c'est rien à coté), d'où des perfs qui s'écroulent des qu'il y a des I/O.
Xen, pour éviter cela, joue avec les ring 1/2 des x86 (chose qui existe sur peu d'autres processeurs, beaucoup n'ayant que 2 modes, kernel & user, contre 4 pour les x86).
Je ne prétends pas que qemu/kernelkqemu & vmware sont systématiquement plus rapides que UML, mais juste que les perfs d'UML ne sont certainement pas à rapprocher de Xen. J'aimerais bien mettre en place qq benchmarks, mais le temps n'étant pas extensible, c'est pas gagné ...
(et je soupçonne que CoLinux ai le même problème - mais là c'est de la pure spéculation :)
# Quelques solutions persos...
Posté par Pierre Palatin (site web personnel) . En réponse au journal Synchronisation entre différentes machines. Évalué à 4.
Pour la messagerie instantanée, j'utilise Bitlbee, qui permet d'avoir de l'IM classique dans un client IRC. Comme j'utilise comme client IRC un irssi dans un screen, je peux récuperer mes sessions d'IM n'importe quand de n'importe où, très très pratique.
Pour l'email, même solution, serveur IMAP, avec tri (procmail) et indexation (mairix) sur le serveur.
Pour le web & les bookmarks, j'utilise en fait un wiki. Alors c'est pas tout à fait le même usage que des bookmarks, mais c'est bien pratique. En gros, j'ai une page 'Scratchpad' sur mon wiki, dans laquelle je mets en vrac les infos que je veux garder (url d'un site/article à voir, citation, commande intéressante, whatever). Relativement pratique à l'usage, mais ça mériterais une intégration plus poussées avec le reste du système.
Pour le calendrier, perso j'utilise WebCalendar ( http://www.k5n.us/webcalendar.php ). L'interface est pas très joli, mais je le trouve extremement pratique. Pour l'instant (version 1.0.X), tu peux avoir du iCal dans ton client lourd de calendrier que en lecture seule, mais la lecture ecriture est présente dans la version 1.1 en cours de développement. Il gère les calendriers multiples, les trucs publiques, etc ...
Pour les RSS, j'utilise une solution simple : mes flux RSS me sont envoyés par email, donc c'est mon IMAP qui se charge du lu/pas lu centralisé :) J'utilise rss2email pour cela, simple et efficace (un peu trop simple même - j'aimerais pouvoir régler le délai de fetch de chaque flux).
J'ajouterais également que avoir un Wiki (noter ses idées, liste de course, todo, whatever et un Subversion (sources, documents, ...) est réellement pratique pour plein de choses.
Un autre problème est pouvoir travailler en mode déconnecté (le laptop dans le train typiquement); là, il y a vraiment pas grand chose. Il y a l'imap déconnecté qui marchotte; j'aimerais aussi pouvoir avoir des copie de mon wiki (avec synchro au retour), mais il n'y a pas grand chose de satisfaisant pour le moment.
# Réglage du mtu
Posté par Pierre Palatin (site web personnel) . En réponse au journal Coup de gueule: SMC barricade smc7404wbra == grosse merde. Évalué à 4.
Après avoir suspecté une surchauffe (c'est clair que fallait pas laisser les doigts sur le proc ...), ben on a pensé au MTU et depuis ça marche nickel.
Manifestement ça a l'air un défaut courant d'avoir une mauvaise fragmentation IP. Le MTU de ce genre de truc étant souvent autour de 1400/1450 et celui standard de 1500, ça peut faire ce genre de comportement. Le plus simple est de diminuer ton MTU vers 1400 pour tester. (Il existe plein de méthodes pour y déterminer automatiquement, notamment via 'ping', un passage sur ton moteur de recherche favori devrait te donner des infos).
Sous nux, pour changer le MTU d'une interface :
ifconfig eth0 mtu 1400
Bon par contre pour l'interface ça ne change rien et c'est clair que les procs sont dimensionnés vraiment limite (pour réduire les coûts).
# Envoi par mail
Posté par Pierre Palatin (site web personnel) . En réponse au message Linux + Ecoute de ses message sur le site d'Orange. Évalué à 2.
# Operating System Resource Center
Posté par Pierre Palatin (site web personnel) . En réponse au message Partitions. Évalué à 3.
Tu trouveras la toutes les docs & les détails sur ce qu'il faut savoir pour faire mumuse avec une machine quand tu es (vraiment) au niveau système (et donc notamment les infos sur partitions & filesystems).
# Tablet PC & linux ...
Posté par Pierre Palatin (site web personnel) . En réponse au journal Tablet PC. Évalué à 10.
Sous linux, il n'y a pas grand chose pour pouvoir écrire sur n'importe quel document. Il y a 'gournal' qui existe, un utilitaire en perl de prise de note, mais ça reste assez basique, il a l'air d'avoir du mal à marcher (aucune icone qui apparaissent, etc.; ça doit être relativement simple à corriger mais bon ...). Mais surtout, ce n'est pas prévu pour l'écriture sur n'importe quel document, et cela manque vraiment.
Sur mon tabletPC (Acer c112), le support du stylet passe au poil (j'ai juste du faire un calibrage manuel), ça utilise le driver Wacom (libre).
Pour la reconaissance d'écriture, il n'existe pas grand chose. Il y a xstroke qui est quand même assez sympa; écriture grafitti sur tout l'écran, i.e. on peut tracer ses lettres n'importe où. Malheureusement ça rentre un peu en conflit avec des widgets genre les barres de scrolling de Qt; pas de problème avec GTK (les raisons sont expliqués dans les docs).
Niveau claviers virtuels, j'en ai essayé quelqu'uns (gtkeyboard entre autres), mais seul xvkbd me convient pour l'instant (ne pas prendre trop de place à l'écran, envoi direct des touches à l'application, etc). Après il y a un problème d'intégration, comme par exemple faire apparaitre xvkbd lors du xdm/gdm/kdm mais avec qq scripts ça ne devrait pas trop poser de problème.
Le plus gros problème reste la rotation de l'écran. Xorg (et Xfree86 je suppose) la supporte via le fichier de config pour le driver fbdev, mais cela impose de redémarrer X, ce qui n'est vraiment pas pratique (ou lancer plusieurs instances, ce qui revient un peu au même vu qu'il n'y a pas moyen simple de faire transiter une appli d'un serveur X à l'autre). J'ai un peu regardé pour y faire via du RandR, mais à l'heure actuelle aucun driver de Xorg n'implémente la rotation et le driver fbdev n'est pas prévu pour une réinitialisation de l'affichage à chaud (bref j'ai des bugs fun :)
Bon donc globalement il y a quasiment tout ce qu'il faut (à part la rotation mais vu comme ça bouge pas mal pour les serveurs X ces temps ci, j'ai bon espoir), mais chaque élèment est toujours un peu limite; et il faut avoir du temps pour y configurer.
Sinon il y a aussi tout les problèmes classiques des portables, le plus commun étant le suspend to ram / to disk, qui marche mal chez moi et c'est vraiment génant ça ...
[^] # Re: subversion...
Posté par Pierre Palatin (site web personnel) . En réponse au message Protocole Subversion ? RFC? client web... Évalué à 1.
Donc subversion sur http utilise le protocole de la RFC 3253 (http://www.faqs.org/rfcs/rfc3253.html(...) , versionning sur webdav), qui précise tout ce dont il nécessaire pour implémenter un client (miam, vive les normes, bon courage).
(pour une vision à plus terme, travailler avec SPE peut être intéressant, puisque s'il marche bien, il pourrait être intégré à php ou au moins être dispo chez des hébergeurs... mais bon c'est sûr que pour le moment, ben faut faire avec l'existant ...)
# subversion...
Posté par Pierre Palatin (site web personnel) . En réponse au message Protocole Subversion ? RFC? client web... Évalué à 1.
Tu as aussi Trac (http://www.edgewall.com/trac/(...)) qui est un gestionnaire de projet mais qui a une partie pour visionner un repositery Subversion (assez joli à mon goût, mais très basic au niveau des fonctionnalités; il manque notamment des possibilités pour faire des diffs arbitraire).
Mais ceux là également ne fonctionnent que sur un repositery local, donc en accès via 'file:///', ce qui peut poser pas mal de problèmes; je ne connais pas d'interface web qui le permette.
Pour l'accès à du subversion, il y a une API php qui existe, par les créateurs de subversion : http://spe.tigris.org/(...)
Par contre, je sais pas trop si c'est utilisable en l'état actuel ...
Pour les protocoles, il en existe plusieurs; accès direct au repositery ou via "svnserve" ou via http.
"svnserve" utilise un protocole dédié. L'accès http utilise une extension normalisée pour avoir du versionning sur WebDAV, donc tu devrais trouver ton bonheur dans les RFCs. Pour plus de détails, le Subversion book : http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-8-sect-1.2(...)
A mon humble avis, il vaut mieux faire un binding vers l'API subversion, c'est plus propre & plus extensible (support des différents protocoles par exemple). Sauf si tu veux qqchose qui marche uniquement avec du php, sans extension, et sans la présence d'un client subversion, auquel cas il devient effectivement nécessaire de réimplementer le procotole en php.
# OCaml & python ont vraiment des approches et possibilités différentes...
Posté par Pierre Palatin (site web personnel) . En réponse au journal pas d'inference de type a la ocmal en python. Évalué à 7.
Bien sûr, tout cela est contournable et il possible de s'en passer (MetaOCaml par exemple doit implémenter des possibilités un peu similaires); mais ce qu'on gagne, dans un certain sens, en performance ou en 'sureté' (vaste problème...), on le perd également beaucoup en souplesse.
Si tu continue à faire du python, essaye d'exploiter à fond ses possibilités, ça change pas mal d'approches pour beaucoup de problèmes (ce qui est souvent appellé "the pythonic way"). On peut souvent exprimer un problème de manière bien plus concise (moins de redondance notamment) sans pour autant perdre trop en lisibilité. Un fil de news intéressant pour python : http://www.pythonware.com/daily/(...)
Pour ce qui concerne psyco je te conseille de lire un peu les articles donnés sur le site avant de chercher à faire un truc "plus intelligent"; tu verras, c'est déjà assez subtil :) (en plus tu verras d'autres raisons qui font que python n'est pas vraiment compilable au sens classique du terme).
Accessoirement, le typage statique semble faire couler pas mal d'encre dans la communauté python actuellement; car s'il est pas possible (en l'état actuel) de faire de l'inférence de type, il est pourrait être intéressant de spécifier à certains endroit explicitement le type, pour des question de clarté de code, de sureté ou d'optimisation.
# Sous mandrake ...
Posté par Pierre Palatin (site web personnel) . En réponse au message Voir programme au lancement. Évalué à 2.
* 'service <programme> [start|stop|...]' pour manipuler les services tournants actuellement. Par exemple, pour arrêter apache, il faudrait faire : 'service httpd stop'. A noter que ça l'empêchera pas de redémarrer au prochain reboot
* 'chkconfig' pour lister / manipuler les services lancés au démarrage.
- Pour avoir la liste : 'chkconfig --list'
- Pour ne pas démarrer un service au démarrage : 'chkconfig <programme> off'; par exemple, pour ne pas démarrer apache : 'chkconfig httpd off'
(le tout en root)
Le mandrake control center permet aussi de faire cela.
Ces commandes sont spécifiques mandrake (et probablement Redhat/FC/Suse). Ce sont des raccourcis pour manipuler le 'SysVInit', système qui permet de gérer le démarrage de ta distrib. Ainsi, 'service' appelle les scripts de /etc/rc.d/init.d et 'chkconfig' manipule les liens symboliques de /etc/rc.d/rcX.d. Je te conseille http://lea-linux.org/admin/daemons.html(...) si tu veux comprendre le fonctionnement en détail.