Amand Tihon a écrit 734 commentaires

En plus, tu en parles toi-même sans avoir l'air de le remarquer.

On a déjà deux excellents moteurs de rendu HTML : Gecko et khtml.
On a déjà deux moteurs 3D (et même bien plus que deux).
On a déjà deux toolkits graphiques.
La liste est longue.

Parce qu'à ce train là, il va arriver ce qui va arriver, on va se retrouver avec KDE/QT only (ou Gnome/GTk only).

Ça me semble vraiment peu probable. À mon avis, tout ce petit monde va sagement (ou moins sagement) continuer à évoluer, parfois en se rapprochant, parfois en s'éloignant.

Et c'est dommage, parce qu'on perd une certaine part d'innovation.

Là je ne comprends pas du tout. Si j'ai un jour une idée que je pense être géniale, pour un browser. Un truc qui enlargerait ma web-experience d'une manière folle. Je serai très content d'avoir de solides bases sur lesquelles m'appuyer (gecko ou khtml, suivant mes préférences personnelles). Résultat des courses, c'aura été plus facile d'innover que s'il avait fallu repartir de zéro !

Enfin, je pense que les grands projets ne commencent pas toujours par être des grands projets. Mon message aux développeurs, fortement inspiré d'un certain Newton :

Voyez loin en vous posant sur les épaules des nombreux géants qui sont à votre disposition.

Mitigé, parce que depuis sa version 3.1, je suis un KDEiste convaincu. Certains me considèrent comme power-user, alors que j'aime la simplicité de KDE. Si, si :)

Disclaimer : je n'utilise plus d'applications Gnome depuis un certain temps. Corrigez-moi si j'exagère :)

Mon père, utilisateur de base, aime bien aussi KDE. La raison en est simple : le degré d'intégration fait que quand il se dit qu'il devrait faire un truc, c'est possible simplement.
Exemple d'il y a deux jours : convertir ses fichiers RAW Minolta vers du PNG : clic droit dans Konqueror, Action, Convert To, PNG. Certains adeptes de la simplification diront que c'est deux sous-menus en trop, ce en quoi ils n'ont peut-être pas tort. Je ne me prononce pas. La sur-simplification de Gnome fait que ce genre de chose (même si cet exemple est mal choisi, je ne sais pas) est habituellement plus complexe à réaliser.

Le gros reproche que je fais à Gnome, même si je ne l'ai plus essayé en profondeur depuis quelques temps, c'est ce manque de possibilités, de facilités, pour des tâches qui soient presque de tous les jours pour seulement une partie des utilisateurs. Ce manque d'intégration.

KDE a fait, ces dernières années, de formidables bonds en avant, alors que Gnome me semble avoir le cul entre deux chaises, à chercher sa place entre une ergonomie à la NeXT et une histoire unixienne, sans être capable de décider de la direction à prendre.

Et c'est là que je veux en venir : si Novell décide de bosser sur Gnome, je pense que c'est très bien, pas pour les raisons qui les ont dirigés vers ce choix, mais parce que pour moi c'est celui des deux environnement en vue qui en a le plus besoin, tout troll à part. KDE et Gnome ont tous deux les moyens de mettre en place des intégrations dans tous les sens, mais un des deux bureaux en tire réellement parti. Cette intégration fait que KDE peut régulièrement faire d'énormes avancées, chose que je n'ai jamais constaté dans Gnome, ce que dans un sens, je regrette. La diversité a du bon, et avoir deux bureaux interchangeables en termes de fonctionnalités, mais pas en termes de « prise en main » serait un indéniable plus.

Alors qu'ils travaillent bien sur Gnome, ce ne sera pas perdu. Une saine émulation entre deux projets de cette envergure ne sera jamais que bénéfique.

Si maintenant, tout ce qu'ils veulent, c'est proposer Gnome aux utilisateurs sans même leur offrir le choix de KDE, ni participer à l'amélioration de Gnome, c'est une autre histoire...

Si des sous-domaines non-existants renvoient une réponse, tu dois avoir un wildcard (*) dans ta config. Il faudrait sans doute un peu plus d'informations pour déterminer la cause exacte des problèmes.

Pour frimouvy, le problème est ailleurs : un de tes NS semble avoir des ennuis.

Voyons d'abord quels sont ses NS :

allergy@hali:~$ host -t ns frimouvy.org
frimouvy.org name server ns30318.ovh.net.
frimouvy.org name server ns3.everydns.net.

Testons le premier :

allergy@hali:~$ host -t ns frimouvy.org ns30318.ovh.net.
Using domain server:
Name: ns30318.ovh.net.
Address: 213.186.45.152#53
Aliases:

frimouvy.org name server ns30318.ovh.net.
frimouvy.org name server ns3.everydns.net.

Jusqu'ici, pas de problème.

Testons le second :

allergy@hali:~$ host -a frimouvy.org ns3.everydns.net.
Trying "frimouvy.org"
Using domain server:
Name: ns3.everydns.net.
Address: 80.84.249.169#53
Aliases:

Host frimouvy.org not found: 3(NXDOMAIN)
Received 93 bytes from 80.84.249.169#53 in 51 ms

Et voilà. ns3.everydns.net n'a pas le domaine frimouvy.org

Enfin, mail.frimouvy.org ne fonctionne pas toujours non plus (quand on tombe sur everydns pour la résolution). Comme des domaines du genre ablablaplio.frimouvy.org fonctionnent en utilisant le dns d'ovh, je présume que tu as également un wildcard pour le domaine frimouvy.

Alors regarder dans les logs.

Garde un "tail -f /var/log/daemon.log" ouvert pendant que tu fais ton "/etc/init.d/proftpd restart" suivi d'une tentative de connexion.

Ça devrait te donner au moins une piste, peut-être même une autoroute :)

Si ça ne donne toujours rien, tu peux le stopper, puis le lancer à la main avec les options de debug :

/usr/sbin/proftpd -n -d 9

Retirer (ou commenter) son entrée de la configuration de inetd, et relancer ce dernier ?

Ce qui est très bien, tant que Google définit "evil" de la même manière que toi... Rien n'est tout noir ni tout blanc, comme on dit.

Personnellement, j'utilise « geda and friends. » Même si geda lui-même (le gestionnaire de projets) est vachement limité, il permet au moins d'avoir devant les yeux les différents fichiers du projet.

J'ai un tout petit peu essayé Eagle pour les schémas, mais je suis très vite revenu à gschem : ses raccourcis clavier, surprenants au début, sont vraiment pratiques à l'usage.

Pour le PCB, j'utilise... PCB, eh oui :)

Ce qui m'a le plus posé de problème, surtout au début, ce sont les liens entre symboles et footprints des composants. Impossible de trouver une liste claire de ce qui est disponible comme footprints, certains composants n'ont pas de footprint par défaut, etc... C'est à mon avis le pros gros inconvénient, mais qui disparait à mesure qu'on crée ses propres symboles et empreintes avec des valeurs par défaut qui nous conviennent.

Et alors avec une tablette graphique, leur utilisation devient vraiment très agréable, mais je présume que c'est valable pour tous les softs d'EDA :)

C'est peut-êt'e pa'ce qu'on leu' a app'is qu'il ne fallait pas di'e « un nèg'e » mais « un oiseau de couleu' » ?

- -
Politiquement incorrectement vôtre :)

Crossover étant une couche d'émulation Windows pour Linux, ton argument ne tient plus des masses.

Et si c'est vraiment l'accès aux informations sur l'API qui sont importantes, pourquoi FireFox est il si monstrueusement lent à se lancer sous Linux (environ 10 secondes avant de voir apparaître sa fenêtre sur mon athlon 64, parfois plus de 15 secondes) ?

Évidemment, Firefox fait plus de choses que IE, il est basé sur une architecture complètement différente qui offre des myriades de possibilités (XUL, toussa), mais cela entraîne un coût non négligeable à mes yeux.

OOo (du moins la version que j'utilise) a exactement le même genre de problème : le splash screen d'OOo-writer s'affiche 5 secondes après le lancement, et il faut encore attendre 8 secondes pour avoir l'application. À comparer aux 2 secondes que met KWord à s'ouvrir.

Que sont ces 15 secondes, face au temps qu'on va passer à rédiger son document ou à surfer ? Presque rien en temps, mais énormément en sentiment de lourdeur et de lenteur. C'est idiot, mais c'est comme ça.

Va voir chez Brother, je ne suis pas le seul à être très content de la mienne.

Je conçois bien que le « /etc/rcrunlevel.d/[SK]??name » puisse porter à confusion, mais je persiste dans ce que j'affirme :

Un seul lien présent dans n'importe quel runlevel, à n'importe quel niveau de priorité, que ce soit pour l'arrêt ou le démarrage, suffit pour qu'update-rc.d ne fasse rien.

Un exemple :
Au runlevel 3, samba doit être démarré...
hali:/etc/rc3.d# ls -l *samba*
lrwxrwxrwx 1 root root 15 2005-10-16 12:20 S20samba -> ../init.d/samba

Si je n'en veux plus :
hali:/etc/rc3.d# rm S20samba

Imaginons qu'un script de mise à jour relance update-rc.d :
hali:/etc/rc3.d# update-rc.d samba defaults 20
System startup links for /etc/init.d/samba already exist.

Résultat :
hali:/etc/rc3.d# ls -l S20samba
ls: S20samba: Aucun fichier ou répertoire de ce type


La configuration n'a pas été modifiée.
Comme dit juste au dessus, il suffit généralement de retirer le lien de rc2.d et il ne reviendra pas.

... mais pas tous !

Normalement, si tu retires les liens pour les runlevels 0, 1, 2, 6 et S, tu devrais être tranquille. Si j'ai bonne mémoire, la prochaine mise à jour du paquet ne touchera à rien tant qu'il restera encore au moins un lien.

Extrait du man:

Quand des fichiers /etc/rcrunlevel.d/[SK]??name existent déjà, update-rc.d ne fait rien. C'est ainsi pour que l'administrateur système puisse réarranger les liens -- à condition qu'il en reste au moins un -- sans que sa configuration ne soit réécrite.

Si un paquet ignore tes modifications alors que tu as respecté la petite règle ci-dessus, c'est un bug qui mérite d'être signalé.

mais :
>>> print 19.90 * 100
1990.0

:)

3 sous-menus planqués ?

Moi, quand je regarde http://static.flickr.com/21/28987272_e7f4ed3f6f_o.png(...) je vois juste une grosse icône « Do nothing » et une case à cocher pour qu'il ne le redemande plus la prochaine fois...

Je n'ai pas la moindre idée de la manière dont ça fonctionne sous Windows, mais je suis certain que mon père sera très content d'avoir cette fonctionnalité.

Tu veux peut-être parler de /usr/share/apps/ksmserver/pics/shutdownkonq.png ?

C'est du moins là que l'image se trouve sur ma debian, il faut voir si l'emplacement est le même chez toi.

Te viendrait-il à l'idée d'appeler ton programme 'cd' ou 'rm' ?

Depuis zsh :
allergy@hali:~$ which test
test: shell built-in command


Depuis bash :
allergy@hali:~$ which test
/usr/bin/test

Simplement avec la commande suivante :

echo "mon_paquet hold" | dpkg --set-selections

Autre chose très intéressante aussi (peut-être que Gnome le fait également, je n'en sais rien) : je peux prendre un fichier ou un lien HTML depuis Konqueror, et le glisser-déposer dans une Konsole. Une fois lâché, un petit menu me propose de choisir entre coller, cp, ln, mv, ...

Comme j'ai en permanence une Konsole ouverte juste à coté de mon Konqueror, je l'utilise très souvent.

Deux précisions : l'ampoule ne doit même pas être fonctionnelle, et elle peut être déposée en dehors du verre d'eau.

Les micro-ondes vont chauffer le filament (ou les bouts de filament si l'ampoule est naze), exactement comme le courant le faisait. Bon, le principe n'est peut-être pas le même, mais le résultat bien :)

Le verre d'eau sert à absorber les micro-ondes, pour éviter qu'elles rebondissent sans cesse dans le four et l'abîment.

xmms-crossfade est disponible depuis longtemps (même en woody, c'est dire...).

Bon, ce n'est "que" la 0.3.5, et pas la 0.3.8, mais je l'utilise depuis longtemps sans problème.

apt-get install xmms-crossfade

Et avec l'option -c ? Ok, il ne faut garder que la dernière ligne, mais c'est pas bien difficile...

tiens, je me réponds à moi-même pour signaler qu'on peut remplacer le test de la première ligne par le même genre de « -n » que dans la fonction precmd().

if [ -n "$KONSOLE_DCOP_SESSION" ]; then

...je n'utilise ni xterm, ni sawfish. Cependant, ça m'a donné des idées :) J'utilise Konsole, et savoir en un clin d'oeil ce qui tourne dans les différents onglets me sera d'une grand utilité. Donc, voila ce que je viens de pondre, en espérant que ça profite à d'autres...

if [ "$KONSOLE_DCOP_SESSION" != "" ]; then

    precmd() {
        if [ -n "$OLD_SESSION_NAME" ]
        then
            dcop $KONSOLE_DCOP_SESSION renameSession "$OLD_SESSION_NAME"
            unset OLD_SESSION_NAME
        fi
    }

    preexec() {
        NEWNAME=`print -P "%20>..>$1"`
        export OLD_SESSION_NAME="`dcop $KONSOLE_DCOP_SESSION sessionName`"
        dcop $KONSOLE_DCOP_SESSION renameSession "$NEWNAME"
    }
fi

Merci beaucoup pour l'idée !

Bon, je réponds ici pour tout ce qui précède.

Désolé si ma réponse a pu paraître un peu sèche. Je ne faisais pas de reproches, je donnais des informations :)

Le BTS est souvent (ok, pas toujours...) un outil formidable pour résoudre les problèmes. Il y a presque immanquablement quelqu'un qui s'est penché sur le problème et a déjà trouvé un moyen de tout réparer. C'est pas toujours propre, c'est parfois un pis-aller, mais au moins ça permet de continuer à utiliser son système.

Quand aux mailing-list, elles sont une très bonne source d'informations aussi, et elles sont toutes archivées sur http://lists.debian.org/(...)
Comme le problème était relatif à KDE, et manifestement tout récent, un des réflexes serait d'aller voir sur http://lists.debian.org/debian-qt-kde/(...) et de regarder si, parmi les mails d'août 2005, il n'en est pas fait mention.

Déjà signalé au moins trois fois sur le BTS (Bug Tracking System), sans compter les très nombreuses questions sur différentes mailing-lists debian.

Voir les bugs "Serious" sur http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kdelibs-data(...) pour plus d'infos. Une solution possible est de réinstaller la version 3.3.2-6.1 de ce paquet.

Au passage, il existe apt-listbugs qui est vraiment très pratique.