ookaze a écrit 271 commentaires

Je suis dans le même cas que toi, mais je ne mets pas cela sur le dos de la "médiocrité de la presse Linux". Je trouve que LM et Login: sont restés très corrects. En ce qui me concerne, c'est simplement qu'avec l'ADSL, je n'ai plus l'utilité de ces magazines.
Mais, hier, j'ai été interpellé par ce qui était présent en kiosque, et en lisant la revue de presse aujourd'hui, je ne vois pas moins de 3 mags que je vais sans doute acheter.
Comme quoi, il y a encore du bon dans la presse Linux, voire du très bon.
Notamment, le mag avec la Knoppix et le didactiviel m'intéresse beaucoup. J'avais l'intention de faire à peu près le même genre de sujets sur une page Web, mais quand c'est dans un mag, c'est plus facile pour présenter le Libre à des débutants.
Je trouve ce mois très productif :)

Manque de pot, pour le japonais, c'est une "science exacte" (en fait, cela n'a rien d'une science).
Les règles sont bien établies, même pour la France.
Retrabscrire le japonais, qui a moins de syllabes que le français, ne pose aucun problème.

Tu sais, les 101 Dalmatiens était un de mes films préférés de Dysney, parmi le peu que j'ai pu supporté.
Pour le Livre de la Jungle et Blanche-Neige, je suis d'accord, ils sont bien réalisés pour l'époque. Mais les deux autres sont très mauvais niveau réalisation. Quant à la musique, elle est en fait très mauvaise pour l'ambiance. On a plus l'impression de voir des comédies musicales, zéro ambiance (bizarrement, pour Blanche Neige, ça colle).
Si tu veux dire que tu aimes bien les chansons, c'est plus du domaine de l'appréciation.
Le pire choc pour moi, a été de revoir les 101 Dalmatiens : j'ai pas pu aller au bout tellement c'est horrible :(

> Mais ce qui est dommage, c'est que la signification "stable" se soit un peu édulcolorée avec le temps

Je ne suis pas d'accord, elle est toujours la même. Stable signifie que les API ne doivent pas bouger. Et donc, si tu compiles quelque chose dépendant du kernel 2.6.0, cela doit toujours fonctionner avec le 2.6.x, x quelconque.
Cela ne veut pas dire que ça ne crashera chez personne, j'ai l'impression que c'est ce que tu comprends. Stable se réfère aux API, pas au nombre de bugs potentiels dans le kernel. Mais bizarrement, c'est ce que tu expliques ensuite dans ton post ...

L'incident de gestion de la VM était dans le 2.4 il me semble.
A moins de rechercher un bon uptime, et donc, rebooter le moins possible, je ne pense pas que lancer un 2.6 lors d'un reboot fasse grand mal. On teste, si c'est pas bon, on peut toujours revenir en 2.4. Surtout si c'est pour des choses comme la gestion du son.

Apparemment, les problèmes ne sont pas tant liés à la stabilité, pour le 2.6, qu'à un manque de familiarité avec celui-ci.
En effet, je vois surtout des problèmes de souris qui fonctionne plus comme avant, ou d'émulation SCSI pour l'IDE déconseillée, mais tout de même utilisée (comme chez moi, et j'ai eu des méchants plantages à cause de ça, avec le 2.6.3 et le 2.6.4, mais j'utilise supermount alors bon), des gens qui bootent et n'ont pas de console, ...
Niveau stabilité au sens de l'OS, jusqu'à présent, cela me paraît équivalent au 2.4.

Désolé de te contredire, mais, en tout cas, dans l'explorateur de NT4 (et dans mon souvenir, celui de 98 et de XP), il n'y a pas de contexte. Je viens juste de le vérifier.
Il y en a un (incomplet d'après les tests que je viens de faire) dans le mode spatial accessible à partir du Poste de Travail, mais pas dans l'explorateur (le truc avec l'arbre sur le côté).
Si j'affiche les détails dans C:, que je vais ailleurs, que j'affiche en icônes, et que je reviens dans C:, je suis en icones, et plus en détails -> pas de contexte.

Bizarre, ça ne fonctionne pas sur le NT4 ici après un simple délogge/relogge, et ça marche pas non plus sur mon portable avec XP (mais ça, c'est ptet juste quand il plante, je sais plus, ça fait longtemps que j'ai pas utilisé le XP).
En fait, le NT4 ici ne garde pas non plus la position dans la fenêtre, même si l'on se contente de fermer et de rouvrir un répertoire. Mais peut-être que Gnome 2.6 non plus, je sais pas, ça m'a pas choqué à la maison, faudra que je teste.

Mais on ne peut pas nier que NT4 a au moins essayé d'être spatial (au cas où il ne le serait pas). Ca dépend peut-être aussi du niveau de patch du NT4, c'est peut-être ce qui fausse les perceptions.

Ah bon ?
Je suis sur un NT 4 là, juste en ce moment, et j'ai beau avoir essayé trois fois, y a déjà deux choses qui passent pas :
- Ca garde aucune info entre deux déconnexions.
- Ca garde pas l'emplacement où tu te trouvais dans la fenêtre (quand il y a beaucoup de fichiers et que tu dois utiliser la scrollbar)

Sinon, c'est un comportement identique, sauf que la première fonctionnalité en moins, ça fait mal, quand même. Et ça signifie que c'est déjà moins spatial que Gnome (si NT4 est spatial). Mais Gnome est plus jeune (et gère un système plus complexe).

Enfin bon, moi, je dis ça pour comprendre si NT4 est spatial ou pas, tant que j'en ai un sous la main (ça durera pas).

C'est marrant ce que tu dis.
L'utilisateur, il s'y connaît assez pour dire "je veux pas utiliser KDE ou GNOME", mais pas assez pour pas savoir trouver sa disquette en dehors de ces environnements ?
Franchement, c'est pas sérieux.
De toutes façons, PAM, ça sert au contrôle d'accès (authentification et cie), pas à monter des devices n'importe où.
Il y a le projet Utopia pour ça (udev, hal, dbus, gnome-volume-manager ou autre), et il ne sera pas question de monter des devices ailleurs que dans /dev ou le répertoire assigné à udev.
Ta solution c'est tout sauf une solution.

GNOME et KDE t'offrent l'accès simple à la disquette, et toi, ta solution, c'est pourquoi faire simple quand on peut faire compliqué ? C'est pas sérieux ...

Et puis, pour les posts grands parents, je ne comprends pas en quoi ça gêne, le "Poste de Travail". La vérité, c'est que je ne l'ai jamais vu, car lorsque je me relogge (rarement, même quand je mets GNOME à jour, sauf quand il commence à se mélanger les pinceaux), mon Nautilus revient comme il était avant la déconnexion. Celui du bureau est caché par mes fenêtres, faudra que je regarde un jour sous mes fenêtres ;)

Enfin, le travail des développeurs GNOME est impressionnant. Le Gnome 2.6 est vraiment bien, mais il y a toujours quelques memory leak (mais ça peut être dû aux drivers NVidia qui clashent avec Metacity).

Ton problème, ça ressemble effectivement à une appli fournissant un service essentiel à ton environnement, et qui est configuré pour passer par le réseau.
Je pense au serveur de fontes, ou encore à un service utilisant le réseau déclaré dans le nsswitch.conf (du genre, un serveur LDAP).
Ca peut aussi être un serveur pour le son genre esd.
Mais bon, que ce genre de choses soit dans une config standard Mandrake, ça m'impressionnerait quand même.

Un logiciel de montage vidéo pour le DV, le plus proche possible de ce que livre Pinnacle avec ses cartes.
J'ai déjà tanné Pinnacle pour avoir une appli Linux aussi sur leur CD, mais c'est purement pour dire que j'ai gueulé, je ne m'attends pas à grand chose.
Le plus proche est Kino, mais il manque plein de transitions.
Comme le montage vidéo et les drivers systématiques n'étaient pas dans le sondage, j'ai mis que j'étais comblé.

Mes jeux préférés sont tous des jeux console (surtout des RPG), ou dispo sous Linux par émulateur (ou encore natifs Linux, comme Wesnoth), donc ce n'est pas un problème pour moi.

Bizarre, il m'avait semblé que ça avait toujours été ce type de fonctionnement. C'est en tout cas le fonctionnement normal pour configure et ses options. C'est-à-dire que l'on met le préfixe d'installation en général (donc /usr pour zlib normalement).

Ca dépend pour quoi ...
En accessibilité et internationalisation, Qt est largement en retard (même s'il en a rattrappé pas mal dans la version 3.3).
Oui, je sais, c'était un troll ...

De toutes façons, il est clairement établi que le RVB ne peut pas reproduire toutes les couleurs visibles : il en manque une bonne partie. Il est possible de retrouver ces infos sur le net, je les avais moi-même récupéré dans un dossier d'un magazine dédié à l'image et l'informatique très technique (sait plus le nom).
Donc ce que disait le post grand-parent est tout à fait vrai.
Et cela concernait les écrans CRT utilisant le RVB. Pour les TFT, c'est encore pire, ils ne peuvent même pas représenter toutes les couleurs du RVB.

Pour XAML j'ai une petite idée (indice : c'est basé sur XML).
Pour C#, je sus surpris. Si c'est ISO, c'est tout simplement parce que c'est pas MS qui l'a inventé, comme beaucoup de gens le croient.
C'est juste qu'ils ont engagés le développeur/auteur principal de C#.
Ca doit être pour ça que tout le monde croit que C# a été inventé par MS.
En tout cas, il est clair que l'auteur principal de C# n'avait pas l'intention de détruire son langage. En effet, un langage qui ne devient pas un standard (donc avec des specs claires et ouvertes) est pratiquement voué à l'échec. Enfin, c'est ce que montre l'expérience.

Etant donné que :
- en général, si on met des modules, c'est pas pour tout charger au démarrage
- dans le 2.6, le déchargement des modules est déconseillé, même si c'est possible

C'est donc un gros moins pour udev.
Car effectivement, à quoi ça sert d'avoir des modules dans ce cas ?
Y a-t-il une solution élégante à ce problème ?

Pas la peine de prendre les autres pour des abrutis.
En plus, le monsieur là-haut, il a raison.
Développons :

udev gère la création des devices à chaud comme il faut, oui. Pour peu qu'il soit configurer, et seulement avec l'aide de hotplug (ou murasaki, c'est ce que j'utilise).

Ce qui est bien, certes, c'est que l'on peut mettre les devices où l'on veut, et dans le filesystem que l'on veut. Perso, j'utilise tmpfs, et toujours /udev (parce que ça marche pas encore bien), mais chacun fait comme il veut.

Certes, ça prend pas plus de place qu'un /dev sans devfs.

Mais oui, c'est lent. Pour peupler le /udev, il met plusieurs secondes sur mon bi-pro. Le procédé consiste à lancer un process udev par device à créer (arggg), et ceci est fait par le script. C'est extrêmement lent par rapport à devfs.

Et en plus, c'est pas foutu de créer tous les devices. Votre système fonctionne bien ? C'est que vous ne devez pas utiliser lvm alors. Pour LVM, c'est une catastrophe : udev ignore tout simplement les devices dm. Le résultat, c'est qu'il est plus compliqué de tester un système avec LVM et udev sans se jeter à l'eau en mettant /udev sur /dev (j'ai commencé à tester avec un chroot, mais bon ...). Et je ne parle même pas du besoin d'avoir un /dev minimal au boot, qui n'était pas nécessaire avec devfs.

Enfin, bon, udev, c'est quand même vachement mieux. C'est juste que sauter le pas devfs -> udev pour les gens comme moi qui font leur propre distrib Linux et qui font leurs propres Live CD, c'est un cap assez irritant à passer.
Y a des CDRW qui vont s'user ...

C'est sûr ça ?
Parce que j'ai utilisé qc-usb en module en version CVS (sinon, ça compilait pas) avec des 2.4.2x et 2.6.x et ça fonctionne nickel, sans commande à lancer.
Ca le fait peut-être que sur certains modèles.

Les outils que tu cites sont surtout utilisés pour les fansubs.
Et je ne suis pas trop d'accord avec tout ça.

- Le port de VirtualDub(Mod) est inutile. Avidemux et DVDRip sont largement suffisants. Ce qu'il faudrait porter, ce sont quelques filtres intéressants de sous-titrage, mais la majorité n'est pas OpenSource, et souvent, même les binaires ne sont pas trouvables.

- AviSynth ne sert à rien non plus. Ca permet surtout de scripter les opérations, et de contourner certaines limitations de l'AVI. On peut déjà tout scripter sous Linux avec mencoder. La mjorité des "scripts de fou" ne servent à rien (sauf besoin TRES spécifique). Gstreamer devrait permettre d'implémenter un truc équivalent cependant.

- Un logiciel comme SSA manque beaucoup effectivement. Pas eu le temps d'en faire un en GTK, et il tourne pas sous mon Wine. C'est une des choses qui m'oblige encore à garder un Windows. Je pense que gstreamer serait aussi nécessaire pour un tel logiciel.

- Les filtres WarpSharp et cie bousillent l'image. Les teams préfèrent éviter ce genre de choses, et se concentrer sur le codec et ses options, et sur la source. On a eu les félicitations de pas mal de gens pour notre film de Maison Ikkoku : ils n'avaient jamais vu une telle qualité pour un film d'animation, et on a utilisé aucun filtre de ce genre (beurk !). Bon, certes, on avait un DVD japonais.

Il a fait une erreur dans son exemple, il faut inverser les noms de liens. Et ne me dites pas que ça ne peut pas arriver.
Et je ne parle même pas de la gestion de ces liens et des numéros.
Tout cela (et les autres problèmes) est clairement expliqué sur la page de simpleinit-msb, pourquoi le répéter ici ?

Il est inutile d'exprimer de si forts sentiments envers l'auteur de simpleinit-msb, surtout lorsque l'on ne le connaît pas en plus !
Pour info, l'auteur de LFS voulait l'inclure dans sa distrib, et l'auteur de simpleinit-msb a dit qu'il ne préférait pas imposer son simpleinit-msb a tout le monde, car il estimait que ceux qui l'installerait le feraient en connaissance de cause.
Vu ce bug, il n'a pas eu tort.

C'est ce que l'on appelle un "Tactics RPG" (quoi que là, pas trop RPG) dans le jargon du joueur de RPG japonais.
Il y avait un jeu sur la SNES, exactement du même genre (X's Odyssey, me rappelle plus le nom exact correspondant à X).
Ce jeu est extrêmement prenant, j'ai perdu d'innombrables heures dessus ;)
Perdu, parce que les sauvegardes des anciennes versions sont incompatibles avec les dernières versions.
Difficulté bien réglée, et éditeur de scénario : un must !

simpleinit-msb est beaucoup plus simple que sysvinit. Il n'y a aucun lien à créer partout par exemple.
De plus, il gère les dépendances, et lance le plus de scripts possible en parallèle.
Il y a une explication de tous les avantages de simpleinit-msb sur le site ...
Il y avait eu un thread l'année dernière sur un remplacement de sysvinit, et simpleinit-msb réglait TOUS les problèmes que les gens ont évoqués. Mais apparemment, personne ne veut l'utiliser, car il y a des "features" non standards (j'avais entendu : pas de reboot avec "telinit 6", alors que c'est tout à fait implémentable).
Et apparemment, peu de gens ont compris que là, il ne s'agissait pas vraiment d'une faille, mais d'un bug qui empêchait de lancer l'OS si l'on utilisait cet init.
Je suis assez content que lfr ait fait cette news, car j'utilise simpleinit-msb sur mes machines, et au prochain reboot : blam !
Et j'aurai pu passer un moment avant de trouver la cause.
Donc merci Linux FR.

Il faut suivre ce qu'il y a dans le whatsnew.txt (je crois) qui se trouve dans le répertoire Documentation du noyau.
Ca indique entre autre qu'il faut installer module-init-tools.
Ca parle aussi du problème de console vide.
Enfin bref, c'est pas bien compliqué, sauf si tu utilises LVM comme moi.
Là, tout de suite, c'est une autre histoire.
M'enfin, j'ai tout automatisé pour nALFS.
J'ai fait les fichiers XML qui vont bien pour nALFS.

Il a toutes les chances d'avoir un écran vide au reboot.
C'est un symptôme systématique apparemment, lorsque l'on procède ainsi.
A moins qu'il ait rajouté les options qu'il faut.
Ces options concernent la gestion du TTY.
La console nécessite désormais 2 ou 3 options à cocher pour fonctionner.

Mauvaise analogie s'il en est, puisqu'il faudrait écrire :
"Moi, je duplique des voitures, j'efface leur existence et de temps en temps, ...".
Tout de suite, ça fait plus ridicule ...