Les constructeurs ont qu'à filer les specs, le boulot sera fait pour eux (je n'ai pas la prétention d'en avoir les compétences, donc, je ne reprends pas ton "on") !
Que l'API du noyau soit gelée, pour faciliter le développement des drivers proprios ; et quand il faudra modifier l'API, a posteriori, pour cause d'imprévu de conception ? On fera quoi ? On retardera le développement du noyau (libre) et des pilotes (libres) qui y sont inclus, le temps que ce qui sera devenu une large majorité de drivers privatifs se soient préparés ?
Sans compter qu'on enverrait un signal excellent à ceux qui ne veulent pas donner de spécifications ; après tout, l'argument du "c'est proprio, c'est pas intégrable aux API qui changent tout le temps, donc, c'est ingérable" ne tiendrait plus... sauf que... si : il reviendrait sur le tapis, à la moindre modification requise, parce qu'il y en aura indubitablement. Et on revient à mon paragraphe du dessus, avec tout le monde qui trinque...
C'est bon, j'ai déjà donné : j'ai arrêté Gentoo quand (mais, pour être honnête quand même, pas seulement parce que) la majorité de la communauté d'utilisateurs s'est déclarée en faveur d'attendre que les drivers proprios soient prêts avant de dé-tilde-archer X.org (un plaisir à dé-tilde-archer à la mimine, X.org - autant compiler les sources de développement, ce dont je n'ai plus le temps) ; quand tu joues le jeu du libre, en n'ayant que du matos supporté librement, avec des drivers qui évoluent bien, et qu'on te demande d'attendre les traînards du proprio, ça fait 'achement plaisir...
Ne parlons même pas des batailles sur le caractère de programme dérivé d'un module pour un noyau GPL... Remarque que les constructeurs privateurs pourraient au moins se foutre de cet argument en allant mettre le souk dans les BSD (qu'ils y aillent, qu'ils y aillent).
> les développeurs de logiciels
Si ton soft est populaire d'autres se chargeront de les packager pour toi !
C'est quoi le problème ? Tu parles de gens comme Daniel J. Bernstein, qui refusent qu'on empaquette des versions modifiées de leurs softs, et qui exigent qu'on suive leur vision de la manière d'administrer une machine (pour résumer, avec du bout de troll dedans - je hais daemontools) ?
Ou des distributeurs de programmes proprios ? s'ils sont en position de demande d'utilisation de leur bousin, rien ne les empêche de faire du dépôt, comme Slim Devices, pour leur SqueezeCenter (mais ça demande moult travail, certes)... S'ils sont si géniaux et/ou indispensables que ça, des utilisateurs de chaque distro en viendront bien à s'y intéresser, et ils seront packagés (même par Debian - 'fin, au moins de quoi les télécharger et les installer où il faut). Maintenant, si la seule qualité de ton soft réalisé en deux heures, c'est le buzz éphémère qu'il va créer, pas sûr que s'en passer soit un inconvénient...
Ou des distributeurs de programmes non re-distribuables ? Bah, quand on veut intégrer son appli non-redistribuable dans des _distributions_, et qu'on se plaint que c'est trop compliqué de faire soit même ses paquets, laissant à l'utilisateur la charge de se démerder (même dans des cas aussi bêtes que la copie d'un firmware là où il faut), on cherche le bâton pour se faire battre... ou bien ?
Maintenant, je veux bien que les distros fassent un effort pour harmoniser les arborescences et cie (il y a quand même les FHS... maintenant, peu de distros les suivent, certes), mais ça ne se fait pas du jour au lendemain... et si tu pars sur la voie d'une synchronisation de toute l'administration, paquets, initialisation, gestion des droits, jusqu'à exiger d'avoir la même version de tout partout, tu t'assieds sur la manière dont le libre s'est développé, et sur une de ses forces (ainsi que faiblesse) : la diversité...
Et puis, si ton loisir préféré est de télécharger plein de trucs crados, pour les installer de manière crado, autant utiliser un OS bien connu qui est fait pour être administré sans gestionnaire de paquets, ie de manière crado : c'est ça aussi, la diversité (même si, là, on sort du libre)... Sinon, si tu veux faire ça sous Linux, bah : développe ton Linux crado, avec une base immuable, et sans paquets. Si c'est tout ce que les gens veulent, tu devrais te faire des poches sperminales en or, en le vendant...
Ce que je ne comprends pas, c'est cette lubie de vouloir que ce soit "l'année du desktop", là, maintenant, tout de suite. Le libre est puissant, mais pas encore assez pour être hégémonique : c'est un fait. Et alors ? D'une, je ne veux pas de l'hégémonie du libre (tant qu'il est possible de l'être, libre) plus que d'autre chose...
De deux, même avec des spécifications et/ou des pilotes, reste que c'est encore la merde pour le wifi libre, par exemple... X.org souffre encore beaucoup, quant à lui, de la période d'engoncement héritée de xfree86 (si le multi-board, ie 3 écrans avec deux GPU, est actuellement impossible avec des drivers libres, c'est parce que beaucoup de retard a été pris, et qu'il a fallu se taper la modularisation de X.org, et re-concevoir la manière de gérer le multi-écran avec RandR, chose qui est loin d'être finie, à mon grand dam)... sans compter le manque de GUI (pour l'utilisateur maniaque des clics), en reprenant ces exemples, pour le wifi (NetworkManager 0.7 commence tout juste à être assez bon pour couvrir des usages variés), ou pour affiner le multi-écran (URandR est embryonnaire). Ce dernier point me paraît ultra-important pour démocratiser le bousin, mais franchement, tu crois que c'est avec des constructeurs de matos à blob, ou des programmateurs proprios que ça va changer quoi que ce soit ?
Que tu le veuilles ou pas, le libre, c'est très bien (le seul blob que j'utilise, c'est le driver Broadcom, sous noyau 2.4, pour mes WRT... en attendant un b43 fiable sous 2.6, avec les Virtual Access Point, ce qui arrive tranquillement : tous le reste de ce qui tourne sur mes CPU, routeurs, serveurs, bureaux, est libre), mais sur plein de points, c'est jeune... ou immature... ou ce qu'on veut dans cet ordre d'idée. Mais pousser le zélotisme jusqu'à se voiler la face, ou, inversement, à tout sacrifier au proprio, ça mène à quoi ?
En attendant que plein de choses s'améliorent, laissons (faisons) venir : ce sera "l'année du desktop" quand ce sera "l'année du desktop". Et ça viendra quand ce sera prêt...
> la nature n'a jamais laissé mélanger deux organismes trop différents
Faux : c'est le principe même des rétrovirus, par exemple. Et d'une manière ou d'une autre, de toute façon, ça ne veut pas dire que la nature, tout aussi bien que les OGM, est toute bienveillante, ou toute malfaisante.
En revanche, pour les problèmes de stérilité de certains OGM, de contamination et d'interdiction de re-semer, pour cause de brevets, oui, là, je suis d'avis que c'est extrêmement problématique. Mais ça, ce sont sûrement davantage des problèmes à régler entre humains.
Les raccourcis web de Konqueror : dans la barre d'URL, si je préfixe ce que je recherche par "wp", il va directement chercher dans le moteur de recherche de Wikipedia, "deb", dans la liste des paquets Debian, "ggl", sur "google j'ai de la chance", "gg" sur la page de recherche de google... et c'est bien sûr personnalisable ; chez moi : "wpe", dans le Wikipedia anglophone, "amac", dans les CD d'amazon.fr, "amad", dans leurs DVD, "gen", sur Gentoo-portage, ... Je trouve ça tellement pratique ; tellement plus rapide qu'une barre de recherche ou un truc du genre.
Le fait qu'on ait aussi les kioslaves dans l'excellent sélecteur de fichiers... par exemple, quand je suis sur le Web, et que je veux enregistrer un fichier sur mon serveur chrooted-SFTP (seule manière d'y écrire des fichiers, chez moi, NFS étant en lecture seule), je préfixe l'emplacement d'enregistrement par "sftp://user@host:/répertoire" ("user" si l'utilisateur du serveur est différent de celui qu'on utilise sur le client pour faire ça, sinon, pas besoin), et zou (éventuellement après s'être authentifié, si je ne suis pas déjà connecté à ce serveur dans une autre appli).
En fonctionnalité (trollogène), il y a également le fait de ne pas devoir attendre des plombes que la fenêtre d'une application Qt se rafraîchisse quand le proc est surchargé, et qu'on ne se sert pas de compositage des fenêtres...
Sinon, en application qui tue tout, il y aurait déjà SMPlayer... à mon goût, le seul aussi bien est le mplayer-nogui (pour d'autres utilisations)... ce que je peux détester totem...
Bon, MythTV(-frontend) est également très bien...
... ou KMLDonkey, pour une GUI MLDonkey (mlgui est atroce et lent comme la mort... il y aurait bien sancho, bien fonctionnel, mais je ne suis pas fan des applis java, et, niveau bouffeur de ressources, il se pose là)...
... ou QtOctave (pas indispensable, mais ça peut être utile quand même, ne serait-ce que pour "évangéliser")...
A priori, rien à voir avec un rectum (et encore moins un électronique sous enrobage de formica, donc), puisque c'est justement l'abréviation de "I am not a lawyer", ie "je ne suis pas un juriste"...
> je devine que là où ça marchera pas, ils n'en mettront pas
Non, mais ce n'est pas le fonctionnement du radar, que je mets en doute... c'est ma compétence à être capable de mesurer des distances de sécurité précisément dans un tunnel mal éclairé.
Je ne pense pas commettre d'imprudence radicale quand j'en prends, mais après tout, je n'ai rien de propre pour mesurer ma distance aux autres... à mettre en relation avec les contrôles de vitesse, pour lesquels j'ai quand même le compteur de vitesse de ma voiture (gradué tous les 10km/h, et donc, avec une erreur de lecture de, mettons, +/-5km/h, lors même que les tolérances les plus basses sont de 3km/h en ville : ça va, j'ai un moyen pas trop dégueu de m'assurer que je ne fais pas de connerie).
D'ailleurs, c'est notamment parce que mon compteur de vitesse est imprécis, qu'il y a une "grosse" tolérance : j'ai tendance à avoir beaucoup plus confiance en la précision du radar (sauf installation à-la-rache, ce qui arrive pas mal, paraît-il, même si, preuve en est que je ne suis pas un fou du volant gueulant contre le tout-répressif, je suis un des rares que je connaisse à n'avoir encore jamais perdu de point sur mon permis) qu'en mon tableau de bord (même s'ils sont généralement conçus pour tendre vers une erreur systématique à l'avantage du conducteur).
> Les embouteillages sont facilement repérés, et le radar (ou l'émission du PV) en tiendra certainement compte
Et à partir de quelle vitesse ils vont considérer qu'on n'est plus dans un embouteillage ? 5km/h ? 10 ? 20 ? 30 ? Est-ce que le coup des deux secondes entre toi et l'autre véhicule est encore ce qu'il faut respecter, en ce cas (d'ailleurs, une seconde pour avoir le réflexe, et une pour freiner en pratique, ça peut être juste, hein - surtout en trafic dense ou on va avoir tendance à accélérer relativement "fort", pour redémarrer, et où il va falloir aller contre cette accélération pour s'arrêter à temps) ?
Je n'en sais rien : jusqu'ici, j'ai l'impression que tout le monde fait au piffomètre. S'il faut commencer à faire gaffe parce qu'on va être mesurés, je pense que le minimum, c'est que les véhicules soient équipés de quoi avertir le conducteur quant à ce qu'il en est.
Je n'ai rien contre le fait qu'on fasse gaffe aux distances de sécurité, mais déclarer du jour au lendemain qu'on va sévir sur un truc qu'on ne peut pas vraiment mesurer précisément quand on est au volant, ça me laisse vraiment perplexe... appelle ça de la (fausse ?) naïveté si tu veux, ça ne me fera pas m'arrêter de m'interroger sur la pertinence de la mesure...
Pour moi, c'est du même ordre que si seules les pervenches connaissaient l'heure qu'il est, mais qu'on te verbalisait quand même si tu dépassais le temps de stationnement pour lequel tu as payé. Je vois mal comment on ne peut pas craindre de se faire verbaliser en aveugle, avec ce genre de truc.
> j'ai toujours des scrupules à doubler par la droite vu que c'est un tantinet illégal dans les pays ou le volant est à gauche
Tu fais bien... on ne sait jamais : un connard qui se dit qu'il pourrait bien refaire son aile droite à tes frais si tu le doublais ; à être con à ce point, ceux qui font ça (il y en a) ne sont pas à ça près de faire ça sur l'autoroute, avec la vitesse que ça implique.
Personnellement, surtout depuis que j'habite à la cambrousse, mon permis m'est plus important que les conneries qui peuvent être amusantes (point ne sert de le nier : je n'ai pas toujours respecté les consignes telles que les limites de vitesse - bon, je dis que maintenant, je fais très attention : personne n'est à l'abri d'une petite connerie, genre 55km/h au lieu de 50km/h + 3km/h de tolérance). C'est le permis, ou 3 heures de bus pour 50km aller/retour jusqu'à la ville la plus proche : c'est vite vu. Et au fond, je ne m'en porte pas plus mal (même si ça ne m'empêche pas de pester contre les gens qui ralentissent exagérément 1km avant les radars, pour bourrer 100m après, ou qui se promènent à 60km/h sur les nationales).
> la distance de sécurité, tu peux la contrôler sans bandes blanches
Certes, mais dans un tunnel, déjà bien dangereux en soi, j'ai un peu autre chose à foutre (des tunnels bien éclairés et bien larges comme celui du lien de cykl, au-dessus, je n'en vois pas tous les jours) - évidemment, je fais gaffe à ne pas coller celui de devant au cul, mais je fais ça au piffomètre.
S'ils voulaient vraiment faire dans la mesure de sécurité, qu'ils commencent par exiger la présence d'un détecteur de proximité sur tout véhicule neuf... et une fois qu'une très large part du parc automobile serait équipée, il serait bien temps, et au passage, éventuellement légitime, de mettre des radars.
Qu'on fasse quelque chose pour les distances de sécurité, conceptuellement, je veux bien : surtout sur autoroute, où je ne compte plus les glandus qui collent au cul plusieurs bornes avant de se décider à faire leur excès de vitesse en me doublant...
... maintenant, sur autoroute, par exemple, les distances de sécurité, on peut très facilement les évaluer grâce aux bandes blanches sur les bas côtés - a priori, il en faut deux, sur ces voies.
Mais je connais plusieurs tunnels, notamment du genre à 4 voies (limitées à 50 quand même), où ces bandes, il n'y en a pas. Et puis, évaluer la distance de sécurité aux bandes, sous un éclairage comparable à celui qu'on trouve dans l'anus d'une taupe, c'est quand même douteux, comme mesure... Sans compter les embouteillages : dans ces cas, on se fait flasher quand même ? Alors, on fait comment, pour savoir si on respecte la loi ou pas ? On rachète une voiture neuve équipée de détecteurs de proximité ? On est excessivement prudent au risque de largement laisser la place aux gogols de s'insérer en faisant une queue de poisson, et de faire qu'on se fasse choper en même temps qu'eux ? Et la tolérance (qui n'est pas un "bon-vouloir de tolérer", mais une condition sine-qua-non à la validité d'une mesure), elle sera de combien ?
Bref, conceptuellement, je veux bien (commencer par faire de la prévention pourrait déjà être une bonne chose)... mais en pratique, ça me paraît quand même difficile, vu l'état actuel des véhicules, et les équipements dont ils disposent. C'est bien gentil de faire des lois, mais si on n'a pas de moyen clair et net de savoir si on les respecte, va falloir se lever tôt pour faire passer ça pour une mesure de sécurité...
Arf... tu me vois un peu embêté de t'avoir incité à te lancer sur un voie qui s'est révélée, pour l'instant, être une fausse joie (bon, j'ai quand même dit qu'il y avait de la rugosité, due à la jeunesse débianneuse du bousin)...
... sinon, essaye de voir du côté des .deb des kernels préparés chez OpenVZ même [1], en attendant...
Je ne les ai que peu testés, et donc, je ne sais pas vraiment à quel point ils diffèrent des kernel avec makefile de chez Debian, cela dit.
Ils n'auront qu'à mettre le préfet/député/maire/famille de... dans Edvige, et l'associer avec un avertissement promettant aux forces de l'ordre pire que de se retrouver à la circulation s'ils y touchent... et zou.
... tu leur installe des drivers proprios (pas avec des cochonneries-tronçonneuses comme "envy" et cie, quand même ?!?)...
... mais _quand_ ils deviennent fous, tu ne fais rien...
Personnellement, pour ne rien avoir à faire, tout en gardant ma conscience tranquille, je veux bien aider les gens tant qu'ils veulent à mettre en place leurs Linux, à la principale condition qu'on ne me fasse pas mettre les mains dans du driver proprio...
... et j'attends toujours de voir l'une des mes installations devenir folle.
Il me semble quand même qu'il y a une liberté que notre pré-bilan ne souhaite pas voir disparaître : celle de quitter la France si on ne l'aime pas, voire si elle ne nous aime pas...
Il y a juste un petit souci avec mon script : si on a changé les permissions et les propriétaires des nœuds de périphériques, ils seront réinitialisés...
... je n'ai pas encore fini de modifier le script pour prendre ça en compte, mais bon, au pire, ce n'est pas très compliqué comme modification : trivial dans le cas où le conteneur fonctionne, et au pire, ça peut se mettre dans un script d'init pour le cas où le conteneur est arrêté quand le périphérique est branché/débranché...
Ah oui, sinon, les noyaux binaires de Debian sont tout en modules, tant que possible, hein.
Sous Gentoo, j'aimais bien compiler les modules en dur : ça me permettait de virer le support pour le chargement des modules à chaud, et ça enorgueillissait le parano en moi...
... mais bon, arrivé un moment, surtout avec le wifi, et certains truc qui ne peuvent plus toujours être compilés autrement qu'en module... ça et la flemme, je me suis calmé.
C'est la branche Unstable, qui est toujours Sid. Et la branche Unstable reste toujours la branche Unstable. Ses paquets arrivent dans la branche Testing, mais elle, elle reste Unstable à jamais (ce qui fait qu'on ne peut pas vraiment passer de Unstable à Testing, lors même que l'inverse est facile).
La branche Testing s'appelle actuellement Lenny, et conservera son nom quand, comme chaque branche Testing, elle deviendra la branche Stable... ainsi qu'elle gardera son nom quand, comme chaque branche Stable, elle deviendra la branche Old-Stable. Elle gardera même son nom quand elle cessera d'être supportée (on ne va quand même pas se mettre à taguer les tombes, si ?).
Sinon, AR5007, c'est ath5k, le driver libre, normalement... je n'ai réussi à la faire marcher "correctement" qu'à partir d'un noyau 2.6.26, soit celui de Lenny... et encore, c'est seulement en client (pas de mode "point d'accès" avec ath5k pour l'heure), et il faut trifouiller un peu (j'avais d'ailleurs fait un journal [1] pour ça).
Et le fait que le driver ne soit pas encore parfait (le débit est un peu juste quand je mate la TV en direct via MythTV : systématiquement, quand il y a une dominante noire, genre un générique de fin, j'ai des saccades - pourquoi seulement lorsqu'il y a une dominante noire ? Je n'en sais rien, et ça me saoule...).
Autrement, dans quelques mois [2], Lenny devient la nouvelle Stable... et puisqu'elle est figée, on peut considérer qu'elle est dors-et-déjà à 99% stable. Bon, après, c'est à toi de voir : Etch sera supportée encore un an après que Lenny soit déclarée Stable.
Tu peux aussi tester un noyau AndAHalf [3], soit un 2.6.24 : ce n'est même pas du backport, ça fait partie de Etch.
Ou alors, un backport de 2.6.26 [4], moins officiel, mais inclus dans les dépôts quand même.
En ce qui concerne les périphériques branchables à chaud (je vais reprendre l'exemple du scanner), il peut y avoir un petit problème.
En cas de débranchement/rebranchement, sur l'hôte, le périphérique peut changer de numéros d'identification, au moins mineur.
Même si on utilise "--devnodes" au lieu de "--devices" avec vzctl, pour "démasquer" ce périphérique, si le nœud est déjà créé dans le conteneur, même en redémarrant ce dernier, il ne sera pas recréé... et puis, c'est moche de redémarrer un conteneur juste pour ça...
J'ai donc fait un petit script pour effacer les nœuds d'un conteneur, et les réassigner :
#!/bin/bash
#
# Script to remove DEVNODES from an OpenVZ VE and add them back then.
#
# Released under the WTFPL (http://sam.zoy.org/wtfpl/COPYING)
#
# Made to be run by a "+RUN" udev stanza on the HN ; let us call
# this a "hack-ish fractal udev for the VE, running on the HN" :p
#
# udev is generally ran as root, so the script should then have
# the permissions it needs
#
# It is a generic script : it picks the ID of the VE
# from its own name, ie "${ID}.dev"
#
# Particularly useful for hotplugable devices that may change of
# major/minor numbers on unplug/replug
#
# There is no need to restart the VE with this one
# This variable is going to be used in this script
# You should not use spaces in nodes names, as they are treated
# as separators... but you should not be able to do so in VE conf
# files anyway...
unset DEVNODES
# The ID of the VE, recovered from the name of this file
ID=`basename $0|cut -d. -f1`
# Checks the VE configuration, so to pick the DEVNODES variable
source /etc/vz/conf/${ID}.conf
# If there are DEVNODES, remove those from the VE's private directory
# and add them back
if [[ ! -z "${DEVNODES}" ]]
then
for i in "${DEVNODES}"
do
if [[ -e "/var/lib/vz/private/${ID}/dev/`echo $i|cut -d: -f1`" ]]
then
rm "/var/lib/vz/private/${ID}/dev/`echo $i|cut -d: -f1`"
vzctl set ${ID} --devnodes $i --save
fi
done
fi
Veillez juste à le rendre exécutable, et à lui donner un nom correspondant à l'ID du conteneur ; j'ai pris ".dev" pour l'extension, mais a priori, l'extension, le script s'en fout.
Ensuite, j'inclus ce script dans la règle udev qui me permet de donner un symlink constant à mon scanner, par exemple :
Et ainsi, si je débranche la bête, dès qu'elle est de nouveau détectée, le nœud matériel accessible au conteneur est mis à jour, que celui-ci soit en train de fonctionner ou pas (dans ce cas, le nœud est juste effacé, et sera rajouté au conteneur dès son prochain démarrage).
Sinon, dernière astuce, si vous voulez regrouper les périphériques pour les conteneurs dans un sous-répertoire particulier de "/dev", comme je le fais avec mon "/dev/containers_dev", sachez que ça ne suffira pas pour les logiciels comme "saned", qui recherchent "/dev/bus/usb", à moins de directement partager ce qu'il y a dans ce dernier, et pas un simple "symlink" (même en le spécifiant dans "/etc/saned/snapscan.conf", par exemple, dans mon cas).
Ainsi, sur l'hôte, si avec ma règle "udev", "/dev/containers_dev/epson_1670" n'est qu'un symlink vers, en ce moment (mais ça change au moindre débranchement/rebranchement), "/dev/bus/usb/003/017", en partageant "/dev/containers_dev/epson_1670", ie le "symlink", ça ne suffit pas au conteneur pour voir ce qu'il faut. Pas grave - dans le conteneur, il suffit de faire un :
en créant à la main le répertoire "/dev/bus/usb/001", et "saned" n'y verra que du feu (par contre, ça ne suffit pas à faire marcher "lsusb" : il lui faut le vrai "/dev/bus/usb/...", et pas un "symlink" avec des répertoires, dans le conteneur).
> Je n'ai donc pas le support des touches multimédias, pour la gestion de la luminosité je dois y aller à la main, idem pour la gestion d'énergie.
Les touches multimedia, je n'en sais rien, mais pour la gestion de la luminosité, sur mon laptop (Vaio), c'est inclus dans le noyau binaire (sonypy, ou quelque chose comme ça), et je gère ça via KPowerSave (et ça marche bien). Itout pour la gestion d'énergie.
Quand je suis passé de Gentoo à Etch, je compilais moi aussi mes noyaux aux oignons, mais finalement, j'en suis venu à utiliser les noyaux binaires de Debian, que je trouve personnellement très bien : je n'ai pas compilé un noyau depuis bien un an et demi (enfin, si, pour inclure des patches trouvés sur l'interface de bugreport de Debian, mais en ne changeant rien d'autre aux sources du paquet, car ça ne m'a jamais été nécessaire).
Je boote un peu plus lentement, à la limite... certes, certes. Mais c'est toujours ça de moins à maintenir moi-même.
> Sinon, je suis relativement un ancien-nouveau (!sic) sous Debian, j'aimerais en savoir un peu plus sur ce qu'implique d'utiliser une branche un peu plus "à jour" au quotidien.
Pour Testing, davantage de mises à jour (pas seulement des mises à jour de sécu - c'est du "rolling-release"... bon, vu qu'en ce moment elle est gelée pour devenir la prochaine Stable, c'est très calme), et quelques bugs (comme un grub qui ne démarre plus, ce qui a été le seul truc à vraiment m'ennuyer cette année, même si ça ne m'a pas ennuyé plus de 5 minutes, un grand merci au live-cd minimal de Gentoo, dont je fais toujours grand usage) en prime.
Pour Sid, pareil, sauf que plus vite, et avec plus de bugs, plus rapidement corrigés. Il y a un délai de quarantaine entre Sid et testing (de 2 à 10 jours, selon la gravité du bug - si vraiment ça prend trop de temps, tu peux toujours formuler une requête pour réduire le délai de quarantaine, en envoyant un mail au sujet du bug ; l'issue de la requête dépendra du mainteneur, comme partout).
Maintenant, si tu sais trifouiller, sauf exception, tu ne devrais pas avoir de problèmes à te sortir tout seul des quelques panades.
Pour les paquets d'Experimental, là, par contre, ça porte généralement très bien son nom... j'en utilise de temps en temps (surtout en ce moment, avec Sid qui se concentre avant tout à préparer les mises à jour pour Lenny), mais surtout pour voir à quoi va ressembler le proche avenir - ça reste souvent à la limite (pas forcément du bon côté) de l'utilisable.
En comparant avec des distros ultra-bleeding-edge (chut-chut, pas de nom), j'en suis venu à avoir une règle très personnelle (qui n'engage donc que moi) : si ça n'est pas dans Debian Sid, ce n'est pas vraiment prêt à être utilisé.
> Je ne veux pas être à "la page" nécessairement, mais j'aimerais juste avoir une chose fonctionnelle jusqu'aux ongles.
Ce qui serait possible avec une distro post-2.6.26.
Si Sid est très instable (plusieurs dizaines de mises à jour par jour est courant), et Testing beaucoup moins (quelques mises à jour quotidiennes seulement), je suis de ceux qui pensent que les deux sont très fonctionnelles ; et oui, j'irais jusqu'à dire jusqu'au bout des ongles (à condition de savoir reconfigurer un petit truc par-ci-par-là de temps en temps, surtout pour Sid - j'utilise deux Sid, Workstation et Laptop, et une Testing, HTPC... plus plein de serveurs en Stable, ou Testing, si elle est gelée).
Les deux sont en 2.6.26, pour l'instant. Quand Squeeze (la prochaine "testing", et donc, l'après-prochaine stable) émergera, je pense qu'on verra très vite 2.6.27 dans Sid (si ce n'est pas déjà fait d'ici là), et peu après, dans Squeeze.
Sinon, pour les branches :
- Experimental : ultra-bleeding-edge, en constante ébullition, pour préparer l'intégration dans Unstable (pas tout le temps) ;
- Unstable : passage obligé pour l'intégration aux branches moins instables (instable signifie que les paquets ne sont pas figés à leur version actuelle - ça peut être instable, et pour autant, fiable - comme ça peut ne pas l'être) ; elle s'appelle toujours Sid ;
- Testing : "rolling-release" vers la prochaine stable - figé toutes les quelques années pour donner la prochaine stable ; son nom est habituellement décidé par le dictateur bienveillant qui s'en va avant qu'elle ne sorte ; l'actuelle est Lenny, et la prochaine, Squeeze ;
- Stable : les versions des paquets ne bougent plus, sauf pour les mises à jour de sécurité, ce qui vient des dépôts tagués "versatile" (anti-virus et cie) et le AndAHalf (depuis Etch, pour un nouveau noyau, et des choses du genre, seulement si l'on en a besoin) ; l'actuelle est Etch, la prochaine Lenny (puis suivra Squeeze, un moment après qu'elle soit figée) ;
- Old stable : l'ancienne stable, supportée un an après la sortie de la stable actuelle ; l'actuelle est Sarge (plus supportée), la prochaine est Etch.
Sinon, c'est quoi, ta carte wifi, pour avoir besoin d'un >2.6.26 ? Une Atheros à ath9k ? Il me semble que ce soit le seul modèle à être entré si récemment dans Vanilla (à part peut-être pour la dernière série de chips Intel, que je n'ai jamais encore vu en vrai), mais je peux me tromper...
À noter que pour l'hébergement, il semble que Mike n'ait pas réitéré avec Skiplink (on le comprendra), mais se soit tourné vers une offre de Jeremy McSpaden, qui était actif sur l'ancien wiki.
Mike visait au moins de l'octocore, 16Go de RAM, 50Gio d'espace, et une connexion de 10Mb (1,5-2Mb en moyenne).
Il semble qu'il ait mis en place du serveur VMware.
- Hébergement (fait)
- Configuration du serveur (fait)
- Remise en ligne de Gentoo portage (fait)
- Mettre en place le logiciel du wiki (commencé aujourd'hui, normalement)
- Mettre en place les langages
- Désigner les admins
- Réécrire les plugins/bots
- Mettre en place la structure du site
- Première éditions
- Procédure de sauvegarde complète
- Restaurer les anciennes données
- Accès public
Mike pense utiliser Google Cache, Archive.org et les sauvegardes datant de mars dernier, pour restaurer les anciennes données.
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Aefron . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 2.
... à force de ne plus utiliser que ça, j'ai peine à penser que ça n'aille pas ensemble :p
[^] # Re: Faire payer... Ou proposer ce que les gens demandent.
Posté par Aefron . En réponse au journal Linux et le grand public il faut en finir avec la gratuité.. Évalué à 10.
Les constructeurs ont qu'à filer les specs, le boulot sera fait pour eux (je n'ai pas la prétention d'en avoir les compétences, donc, je ne reprends pas ton "on") !
Que l'API du noyau soit gelée, pour faciliter le développement des drivers proprios ; et quand il faudra modifier l'API, a posteriori, pour cause d'imprévu de conception ? On fera quoi ? On retardera le développement du noyau (libre) et des pilotes (libres) qui y sont inclus, le temps que ce qui sera devenu une large majorité de drivers privatifs se soient préparés ?
Sans compter qu'on enverrait un signal excellent à ceux qui ne veulent pas donner de spécifications ; après tout, l'argument du "c'est proprio, c'est pas intégrable aux API qui changent tout le temps, donc, c'est ingérable" ne tiendrait plus... sauf que... si : il reviendrait sur le tapis, à la moindre modification requise, parce qu'il y en aura indubitablement. Et on revient à mon paragraphe du dessus, avec tout le monde qui trinque...
C'est bon, j'ai déjà donné : j'ai arrêté Gentoo quand (mais, pour être honnête quand même, pas seulement parce que) la majorité de la communauté d'utilisateurs s'est déclarée en faveur d'attendre que les drivers proprios soient prêts avant de dé-tilde-archer X.org (un plaisir à dé-tilde-archer à la mimine, X.org - autant compiler les sources de développement, ce dont je n'ai plus le temps) ; quand tu joues le jeu du libre, en n'ayant que du matos supporté librement, avec des drivers qui évoluent bien, et qu'on te demande d'attendre les traînards du proprio, ça fait 'achement plaisir...
Ne parlons même pas des batailles sur le caractère de programme dérivé d'un module pour un noyau GPL... Remarque que les constructeurs privateurs pourraient au moins se foutre de cet argument en allant mettre le souk dans les BSD (qu'ils y aillent, qu'ils y aillent).
> les développeurs de logiciels
Si ton soft est populaire d'autres se chargeront de les packager pour toi !
C'est quoi le problème ? Tu parles de gens comme Daniel J. Bernstein, qui refusent qu'on empaquette des versions modifiées de leurs softs, et qui exigent qu'on suive leur vision de la manière d'administrer une machine (pour résumer, avec du bout de troll dedans - je hais daemontools) ?
Ou des distributeurs de programmes proprios ? s'ils sont en position de demande d'utilisation de leur bousin, rien ne les empêche de faire du dépôt, comme Slim Devices, pour leur SqueezeCenter (mais ça demande moult travail, certes)... S'ils sont si géniaux et/ou indispensables que ça, des utilisateurs de chaque distro en viendront bien à s'y intéresser, et ils seront packagés (même par Debian - 'fin, au moins de quoi les télécharger et les installer où il faut). Maintenant, si la seule qualité de ton soft réalisé en deux heures, c'est le buzz éphémère qu'il va créer, pas sûr que s'en passer soit un inconvénient...
Ou des distributeurs de programmes non re-distribuables ? Bah, quand on veut intégrer son appli non-redistribuable dans des _distributions_, et qu'on se plaint que c'est trop compliqué de faire soit même ses paquets, laissant à l'utilisateur la charge de se démerder (même dans des cas aussi bêtes que la copie d'un firmware là où il faut), on cherche le bâton pour se faire battre... ou bien ?
Maintenant, je veux bien que les distros fassent un effort pour harmoniser les arborescences et cie (il y a quand même les FHS... maintenant, peu de distros les suivent, certes), mais ça ne se fait pas du jour au lendemain... et si tu pars sur la voie d'une synchronisation de toute l'administration, paquets, initialisation, gestion des droits, jusqu'à exiger d'avoir la même version de tout partout, tu t'assieds sur la manière dont le libre s'est développé, et sur une de ses forces (ainsi que faiblesse) : la diversité...
Et puis, si ton loisir préféré est de télécharger plein de trucs crados, pour les installer de manière crado, autant utiliser un OS bien connu qui est fait pour être administré sans gestionnaire de paquets, ie de manière crado : c'est ça aussi, la diversité (même si, là, on sort du libre)... Sinon, si tu veux faire ça sous Linux, bah : développe ton Linux crado, avec une base immuable, et sans paquets. Si c'est tout ce que les gens veulent, tu devrais te faire des poches sperminales en or, en le vendant...
Ce que je ne comprends pas, c'est cette lubie de vouloir que ce soit "l'année du desktop", là, maintenant, tout de suite. Le libre est puissant, mais pas encore assez pour être hégémonique : c'est un fait. Et alors ? D'une, je ne veux pas de l'hégémonie du libre (tant qu'il est possible de l'être, libre) plus que d'autre chose...
De deux, même avec des spécifications et/ou des pilotes, reste que c'est encore la merde pour le wifi libre, par exemple... X.org souffre encore beaucoup, quant à lui, de la période d'engoncement héritée de xfree86 (si le multi-board, ie 3 écrans avec deux GPU, est actuellement impossible avec des drivers libres, c'est parce que beaucoup de retard a été pris, et qu'il a fallu se taper la modularisation de X.org, et re-concevoir la manière de gérer le multi-écran avec RandR, chose qui est loin d'être finie, à mon grand dam)... sans compter le manque de GUI (pour l'utilisateur maniaque des clics), en reprenant ces exemples, pour le wifi (NetworkManager 0.7 commence tout juste à être assez bon pour couvrir des usages variés), ou pour affiner le multi-écran (URandR est embryonnaire). Ce dernier point me paraît ultra-important pour démocratiser le bousin, mais franchement, tu crois que c'est avec des constructeurs de matos à blob, ou des programmateurs proprios que ça va changer quoi que ce soit ?
Que tu le veuilles ou pas, le libre, c'est très bien (le seul blob que j'utilise, c'est le driver Broadcom, sous noyau 2.4, pour mes WRT... en attendant un b43 fiable sous 2.6, avec les Virtual Access Point, ce qui arrive tranquillement : tous le reste de ce qui tourne sur mes CPU, routeurs, serveurs, bureaux, est libre), mais sur plein de points, c'est jeune... ou immature... ou ce qu'on veut dans cet ordre d'idée. Mais pousser le zélotisme jusqu'à se voiler la face, ou, inversement, à tout sacrifier au proprio, ça mène à quoi ?
En attendant que plein de choses s'améliorent, laissons (faisons) venir : ce sera "l'année du desktop" quand ce sera "l'année du desktop". Et ça viendra quand ce sera prêt...
[^] # Re: Quels dangers ?
Posté par Aefron . En réponse au journal Réunions secrètes au plus haut niveau pour imposer les OGM. Évalué à 3.
Faux : c'est le principe même des rétrovirus, par exemple. Et d'une manière ou d'une autre, de toute façon, ça ne veut pas dire que la nature, tout aussi bien que les OGM, est toute bienveillante, ou toute malfaisante.
En revanche, pour les problèmes de stérilité de certains OGM, de contamination et d'interdiction de re-semer, pour cause de brevets, oui, là, je suis d'avis que c'est extrêmement problématique. Mais ça, ce sont sûrement davantage des problèmes à régler entre humains.
[^] # Re: Ça ressemble à ce qu'on m'a dit
Posté par Aefron . En réponse au journal Les trolls numériques ne meurent jamais. Évalué à 4.
Le fait qu'on ait aussi les kioslaves dans l'excellent sélecteur de fichiers... par exemple, quand je suis sur le Web, et que je veux enregistrer un fichier sur mon serveur chrooted-SFTP (seule manière d'y écrire des fichiers, chez moi, NFS étant en lecture seule), je préfixe l'emplacement d'enregistrement par "sftp://user@host:/répertoire" ("user" si l'utilisateur du serveur est différent de celui qu'on utilise sur le client pour faire ça, sinon, pas besoin), et zou (éventuellement après s'être authentifié, si je ne suis pas déjà connecté à ce serveur dans une autre appli).
En fonctionnalité (trollogène), il y a également le fait de ne pas devoir attendre des plombes que la fenêtre d'une application Qt se rafraîchisse quand le proc est surchargé, et qu'on ne se sert pas de compositage des fenêtres...
Sinon, en application qui tue tout, il y aurait déjà SMPlayer... à mon goût, le seul aussi bien est le mplayer-nogui (pour d'autres utilisations)... ce que je peux détester totem...
Bon, MythTV(-frontend) est également très bien...
... ou KMLDonkey, pour une GUI MLDonkey (mlgui est atroce et lent comme la mort... il y aurait bien sancho, bien fonctionnel, mais je ne suis pas fan des applis java, et, niveau bouffeur de ressources, il se pose là)...
... ou QtOctave (pas indispensable, mais ça peut être utile quand même, ne serait-ce que pour "évangéliser")...
K3b et KMail sont également très bons...
[^] # Re: Signification ?
Posté par Aefron . En réponse au journal Les brevets logiciels auraient-ils pris une claque aux USA?. Évalué à 8.
[^] # Re: D'accord, mais...
Posté par Aefron . En réponse au journal Projet de radars automatiques aux feux (franchissement du feu rouge) et dans les tunnels ( distances de sécurité).. Évalué à 3.
Non, mais ce n'est pas le fonctionnement du radar, que je mets en doute... c'est ma compétence à être capable de mesurer des distances de sécurité précisément dans un tunnel mal éclairé.
Je ne pense pas commettre d'imprudence radicale quand j'en prends, mais après tout, je n'ai rien de propre pour mesurer ma distance aux autres... à mettre en relation avec les contrôles de vitesse, pour lesquels j'ai quand même le compteur de vitesse de ma voiture (gradué tous les 10km/h, et donc, avec une erreur de lecture de, mettons, +/-5km/h, lors même que les tolérances les plus basses sont de 3km/h en ville : ça va, j'ai un moyen pas trop dégueu de m'assurer que je ne fais pas de connerie).
D'ailleurs, c'est notamment parce que mon compteur de vitesse est imprécis, qu'il y a une "grosse" tolérance : j'ai tendance à avoir beaucoup plus confiance en la précision du radar (sauf installation à-la-rache, ce qui arrive pas mal, paraît-il, même si, preuve en est que je ne suis pas un fou du volant gueulant contre le tout-répressif, je suis un des rares que je connaisse à n'avoir encore jamais perdu de point sur mon permis) qu'en mon tableau de bord (même s'ils sont généralement conçus pour tendre vers une erreur systématique à l'avantage du conducteur).
> Les embouteillages sont facilement repérés, et le radar (ou l'émission du PV) en tiendra certainement compte
Et à partir de quelle vitesse ils vont considérer qu'on n'est plus dans un embouteillage ? 5km/h ? 10 ? 20 ? 30 ? Est-ce que le coup des deux secondes entre toi et l'autre véhicule est encore ce qu'il faut respecter, en ce cas (d'ailleurs, une seconde pour avoir le réflexe, et une pour freiner en pratique, ça peut être juste, hein - surtout en trafic dense ou on va avoir tendance à accélérer relativement "fort", pour redémarrer, et où il va falloir aller contre cette accélération pour s'arrêter à temps) ?
Je n'en sais rien : jusqu'ici, j'ai l'impression que tout le monde fait au piffomètre. S'il faut commencer à faire gaffe parce qu'on va être mesurés, je pense que le minimum, c'est que les véhicules soient équipés de quoi avertir le conducteur quant à ce qu'il en est.
Je n'ai rien contre le fait qu'on fasse gaffe aux distances de sécurité, mais déclarer du jour au lendemain qu'on va sévir sur un truc qu'on ne peut pas vraiment mesurer précisément quand on est au volant, ça me laisse vraiment perplexe... appelle ça de la (fausse ?) naïveté si tu veux, ça ne me fera pas m'arrêter de m'interroger sur la pertinence de la mesure...
Pour moi, c'est du même ordre que si seules les pervenches connaissaient l'heure qu'il est, mais qu'on te verbalisait quand même si tu dépassais le temps de stationnement pour lequel tu as payé. Je vois mal comment on ne peut pas craindre de se faire verbaliser en aveugle, avec ce genre de truc.
[^] # Re: D'accord, mais...
Posté par Aefron . En réponse au journal Projet de radars automatiques aux feux (franchissement du feu rouge) et dans les tunnels ( distances de sécurité).. Évalué à 4.
Tu fais bien... on ne sait jamais : un connard qui se dit qu'il pourrait bien refaire son aile droite à tes frais si tu le doublais ; à être con à ce point, ceux qui font ça (il y en a) ne sont pas à ça près de faire ça sur l'autoroute, avec la vitesse que ça implique.
Personnellement, surtout depuis que j'habite à la cambrousse, mon permis m'est plus important que les conneries qui peuvent être amusantes (point ne sert de le nier : je n'ai pas toujours respecté les consignes telles que les limites de vitesse - bon, je dis que maintenant, je fais très attention : personne n'est à l'abri d'une petite connerie, genre 55km/h au lieu de 50km/h + 3km/h de tolérance). C'est le permis, ou 3 heures de bus pour 50km aller/retour jusqu'à la ville la plus proche : c'est vite vu. Et au fond, je ne m'en porte pas plus mal (même si ça ne m'empêche pas de pester contre les gens qui ralentissent exagérément 1km avant les radars, pour bourrer 100m après, ou qui se promènent à 60km/h sur les nationales).
> la distance de sécurité, tu peux la contrôler sans bandes blanches
Certes, mais dans un tunnel, déjà bien dangereux en soi, j'ai un peu autre chose à foutre (des tunnels bien éclairés et bien larges comme celui du lien de cykl, au-dessus, je n'en vois pas tous les jours) - évidemment, je fais gaffe à ne pas coller celui de devant au cul, mais je fais ça au piffomètre.
S'ils voulaient vraiment faire dans la mesure de sécurité, qu'ils commencent par exiger la présence d'un détecteur de proximité sur tout véhicule neuf... et une fois qu'une très large part du parc automobile serait équipée, il serait bien temps, et au passage, éventuellement légitime, de mettre des radars.
Là...
# D'accord, mais...
Posté par Aefron . En réponse au journal Projet de radars automatiques aux feux (franchissement du feu rouge) et dans les tunnels ( distances de sécurité).. Évalué à 4.
... maintenant, sur autoroute, par exemple, les distances de sécurité, on peut très facilement les évaluer grâce aux bandes blanches sur les bas côtés - a priori, il en faut deux, sur ces voies.
Mais je connais plusieurs tunnels, notamment du genre à 4 voies (limitées à 50 quand même), où ces bandes, il n'y en a pas. Et puis, évaluer la distance de sécurité aux bandes, sous un éclairage comparable à celui qu'on trouve dans l'anus d'une taupe, c'est quand même douteux, comme mesure... Sans compter les embouteillages : dans ces cas, on se fait flasher quand même ? Alors, on fait comment, pour savoir si on respecte la loi ou pas ? On rachète une voiture neuve équipée de détecteurs de proximité ? On est excessivement prudent au risque de largement laisser la place aux gogols de s'insérer en faisant une queue de poisson, et de faire qu'on se fasse choper en même temps qu'eux ? Et la tolérance (qui n'est pas un "bon-vouloir de tolérer", mais une condition sine-qua-non à la validité d'une mesure), elle sera de combien ?
Bref, conceptuellement, je veux bien (commencer par faire de la prévention pourrait déjà être une bonne chose)... mais en pratique, ça me paraît quand même difficile, vu l'état actuel des véhicules, et les équipements dont ils disposent. C'est bien gentil de faire des lois, mais si on n'a pas de moyen clair et net de savoir si on les respecte, va falloir se lever tôt pour faire passer ça pour une mesure de sécurité...
[^] # Re: et Debian Lenny ?
Posté par Aefron . En réponse à la dépêche Ubuntu 8.10 : le bouquetin intrépide sort de son antre. Évalué à 7.
Non, eux, ils sont bleus... ce sont ceux d'opensuse, qui sont verts.
[^] # Re: Bugs chez Debian
Posté par Aefron . En réponse au message Plantage kernel OpenVZ. Évalué à 2.
... sinon, essaye de voir du côté des .deb des kernels préparés chez OpenVZ même [1], en attendant...
Je ne les ai que peu testés, et donc, je ne sais pas vraiment à quel point ils diffèrent des kernel avec makefile de chez Debian, cela dit.
[1] http://wiki.openvz.org/Installation_on_Debian#Repository_set(...)
[^] # Re: disponibles pour tous les OS ?
Posté par Aefron . En réponse au journal Albanel nous le fait à la Cindy Sanders?. Évalué à 5.
[^] # Re: reservation
Posté par Aefron . En réponse au journal L'espèce humaine est miséreuse. Évalué à 5.
Faut bien vivre avec son temps...
# Banlu Kemiyatorn...
Posté par Aefron . En réponse au journal Etes-vous d'accord avec cette liste de "grands noms" du logiciel libre ?. Évalué à 5.
... et, pourquoi pas ? Sam Hocevar, pour la version 2.
[^] # Re: Ma solution :
Posté par Aefron . En réponse au journal Vente liée n'est pas gage de qualité. Évalué à 4.
... tu leur installe des drivers proprios (pas avec des cochonneries-tronçonneuses comme "envy" et cie, quand même ?!?)...
... mais _quand_ ils deviennent fous, tu ne fais rien...
Personnellement, pour ne rien avoir à faire, tout en gardant ma conscience tranquille, je veux bien aider les gens tant qu'ils veulent à mettre en place leurs Linux, à la principale condition qu'on ne me fasse pas mettre les mains dans du driver proprio...
... et j'attends toujours de voir l'une des mes installations devenir folle.
[^] # Re: faut arrêter de se moquer du monde
Posté par Aefron . En réponse au journal Les fondements démographique de la crise financière. Évalué à 2.
[^] # Re: Bend dis donc!
Posté par Aefron . En réponse au journal Tiens ils nous refons le coup.... Évalué à 10.
Mazette ! Comme ça doit avoir de jolies couleurs !
[^] # Re: ah bon ???!
Posté par Aefron . En réponse au journal Jayce est de retour ! (Alléluia). Évalué à 2.
[^] # Re: wav?
Posté par Aefron . En réponse au journal De la musique expérimentale en ligne de commande. Évalué à 3.
[^] # Re: Petit complément
Posté par Aefron . En réponse au journal Debian, VServer & OpenVZ : les conteneurs. Évalué à 2.
... je n'ai pas encore fini de modifier le script pour prendre ça en compte, mais bon, au pire, ce n'est pas très compliqué comme modification : trivial dans le cas où le conteneur fonctionne, et au pire, ça peut se mettre dans un script d'init pour le cas où le conteneur est arrêté quand le périphérique est branché/débranché...
[^] # Re: Pour une version récente du noyau
Posté par Aefron . En réponse au message Utiliser /sys pour la gestion d'énergie/événement?. Évalué à 2.
Sous Gentoo, j'aimais bien compiler les modules en dur : ça me permettait de virer le support pour le chargement des modules à chaud, et ça enorgueillissait le parano en moi...
... mais bon, arrivé un moment, surtout avec le wifi, et certains truc qui ne peuvent plus toujours être compilés autrement qu'en module... ça et la flemme, je me suis calmé.
[^] # Re: Pour une version récente du noyau
Posté par Aefron . En réponse au message Utiliser /sys pour la gestion d'énergie/événement?. Évalué à 2.
La branche Testing s'appelle actuellement Lenny, et conservera son nom quand, comme chaque branche Testing, elle deviendra la branche Stable... ainsi qu'elle gardera son nom quand, comme chaque branche Stable, elle deviendra la branche Old-Stable. Elle gardera même son nom quand elle cessera d'être supportée (on ne va quand même pas se mettre à taguer les tombes, si ?).
Sinon, AR5007, c'est ath5k, le driver libre, normalement... je n'ai réussi à la faire marcher "correctement" qu'à partir d'un noyau 2.6.26, soit celui de Lenny... et encore, c'est seulement en client (pas de mode "point d'accès" avec ath5k pour l'heure), et il faut trifouiller un peu (j'avais d'ailleurs fait un journal [1] pour ça).
Et le fait que le driver ne soit pas encore parfait (le débit est un peu juste quand je mate la TV en direct via MythTV : systématiquement, quand il y a une dominante noire, genre un générique de fin, j'ai des saccades - pourquoi seulement lorsqu'il y a une dominante noire ? Je n'en sais rien, et ça me saoule...).
Autrement, dans quelques mois [2], Lenny devient la nouvelle Stable... et puisqu'elle est figée, on peut considérer qu'elle est dors-et-déjà à 99% stable. Bon, après, c'est à toi de voir : Etch sera supportée encore un an après que Lenny soit déclarée Stable.
Tu peux aussi tester un noyau AndAHalf [3], soit un 2.6.24 : ce n'est même pas du backport, ça fait partie de Etch.
Ou alors, un backport de 2.6.26 [4], moins officiel, mais inclus dans les dépôts quand même.
[1] http://linuxfr.org/~Aefron/27191.html
[2] http://linuxfr.org/poll/send,172.html
[3] http://packages.debian.org/search?suite=default§ion=(...)
[4] http://packages.debian.org/search?suite=etch-backports&a(...)
# Petit complément
Posté par Aefron . En réponse au journal Debian, VServer & OpenVZ : les conteneurs. Évalué à 2.
En cas de débranchement/rebranchement, sur l'hôte, le périphérique peut changer de numéros d'identification, au moins mineur.
Même si on utilise "--devnodes" au lieu de "--devices" avec vzctl, pour "démasquer" ce périphérique, si le nœud est déjà créé dans le conteneur, même en redémarrant ce dernier, il ne sera pas recréé... et puis, c'est moche de redémarrer un conteneur juste pour ça...
J'ai donc fait un petit script pour effacer les nœuds d'un conteneur, et les réassigner :
#!/bin/bash
#
# Script to remove DEVNODES from an OpenVZ VE and add them back then.
#
# Released under the WTFPL (http://sam.zoy.org/wtfpl/COPYING)
#
# Made to be run by a "+RUN" udev stanza on the HN ; let us call
# this a "hack-ish fractal udev for the VE, running on the HN" :p
#
# udev is generally ran as root, so the script should then have
# the permissions it needs
#
# It is a generic script : it picks the ID of the VE
# from its own name, ie "${ID}.dev"
#
# Particularly useful for hotplugable devices that may change of
# major/minor numbers on unplug/replug
#
# There is no need to restart the VE with this one
# This variable is going to be used in this script
# You should not use spaces in nodes names, as they are treated
# as separators... but you should not be able to do so in VE conf
# files anyway...
unset DEVNODES
# The ID of the VE, recovered from the name of this file
ID=`basename $0|cut -d. -f1`
# Checks the VE configuration, so to pick the DEVNODES variable
source /etc/vz/conf/${ID}.conf
# If there are DEVNODES, remove those from the VE's private directory
# and add them back
if [[ ! -z "${DEVNODES}" ]]
then
for i in "${DEVNODES}"
do
if [[ -e "/var/lib/vz/private/${ID}/dev/`echo $i|cut -d: -f1`" ]]
then
rm "/var/lib/vz/private/${ID}/dev/`echo $i|cut -d: -f1`"
vzctl set ${ID} --devnodes $i --save
fi
done
fi
Veillez juste à le rendre exécutable, et à lui donner un nom correspondant à l'ID du conteneur ; j'ai pris ".dev" pour l'extension, mais a priori, l'extension, le script s'en fout.
Ensuite, j'inclus ce script dans la règle udev qui me permet de donner un symlink constant à mon scanner, par exemple :
ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="011f", SYMLINK+="containers_dev/scanner_1670", RUN+="/etc/vz/conf/1500.dev"Et ainsi, si je débranche la bête, dès qu'elle est de nouveau détectée, le nœud matériel accessible au conteneur est mis à jour, que celui-ci soit en train de fonctionner ou pas (dans ce cas, le nœud est juste effacé, et sera rajouté au conteneur dès son prochain démarrage).
Sinon, dernière astuce, si vous voulez regrouper les périphériques pour les conteneurs dans un sous-répertoire particulier de "/dev", comme je le fais avec mon "/dev/containers_dev", sachez que ça ne suffira pas pour les logiciels comme "saned", qui recherchent "/dev/bus/usb", à moins de directement partager ce qu'il y a dans ce dernier, et pas un simple "symlink" (même en le spécifiant dans "/etc/saned/snapscan.conf", par exemple, dans mon cas).
Ainsi, sur l'hôte, si avec ma règle "udev", "/dev/containers_dev/epson_1670" n'est qu'un symlink vers, en ce moment (mais ça change au moindre débranchement/rebranchement), "/dev/bus/usb/003/017", en partageant "/dev/containers_dev/epson_1670", ie le "symlink", ça ne suffit pas au conteneur pour voir ce qu'il faut. Pas grave - dans le conteneur, il suffit de faire un :
ln -s /dev/containers_dev/epson_1670 /dev/bus/usb/001/001"en créant à la main le répertoire "/dev/bus/usb/001", et "saned" n'y verra que du feu (par contre, ça ne suffit pas à faire marcher "lsusb" : il lui faut le vrai "/dev/bus/usb/...", et pas un "symlink" avec des répertoires, dans le conteneur).
[^] # Re: Pour une version récente du noyau
Posté par Aefron . En réponse au message Utiliser /sys pour la gestion d'énergie/événement?. Évalué à 4.
Les touches multimedia, je n'en sais rien, mais pour la gestion de la luminosité, sur mon laptop (Vaio), c'est inclus dans le noyau binaire (sonypy, ou quelque chose comme ça), et je gère ça via KPowerSave (et ça marche bien). Itout pour la gestion d'énergie.
Quand je suis passé de Gentoo à Etch, je compilais moi aussi mes noyaux aux oignons, mais finalement, j'en suis venu à utiliser les noyaux binaires de Debian, que je trouve personnellement très bien : je n'ai pas compilé un noyau depuis bien un an et demi (enfin, si, pour inclure des patches trouvés sur l'interface de bugreport de Debian, mais en ne changeant rien d'autre aux sources du paquet, car ça ne m'a jamais été nécessaire).
Je boote un peu plus lentement, à la limite... certes, certes. Mais c'est toujours ça de moins à maintenir moi-même.
> Sinon, je suis relativement un ancien-nouveau (!sic) sous Debian, j'aimerais en savoir un peu plus sur ce qu'implique d'utiliser une branche un peu plus "à jour" au quotidien.
Pour Testing, davantage de mises à jour (pas seulement des mises à jour de sécu - c'est du "rolling-release"... bon, vu qu'en ce moment elle est gelée pour devenir la prochaine Stable, c'est très calme), et quelques bugs (comme un grub qui ne démarre plus, ce qui a été le seul truc à vraiment m'ennuyer cette année, même si ça ne m'a pas ennuyé plus de 5 minutes, un grand merci au live-cd minimal de Gentoo, dont je fais toujours grand usage) en prime.
Pour Sid, pareil, sauf que plus vite, et avec plus de bugs, plus rapidement corrigés. Il y a un délai de quarantaine entre Sid et testing (de 2 à 10 jours, selon la gravité du bug - si vraiment ça prend trop de temps, tu peux toujours formuler une requête pour réduire le délai de quarantaine, en envoyant un mail au sujet du bug ; l'issue de la requête dépendra du mainteneur, comme partout).
Maintenant, si tu sais trifouiller, sauf exception, tu ne devrais pas avoir de problèmes à te sortir tout seul des quelques panades.
Pour les paquets d'Experimental, là, par contre, ça porte généralement très bien son nom... j'en utilise de temps en temps (surtout en ce moment, avec Sid qui se concentre avant tout à préparer les mises à jour pour Lenny), mais surtout pour voir à quoi va ressembler le proche avenir - ça reste souvent à la limite (pas forcément du bon côté) de l'utilisable.
En comparant avec des distros ultra-bleeding-edge (chut-chut, pas de nom), j'en suis venu à avoir une règle très personnelle (qui n'engage donc que moi) : si ça n'est pas dans Debian Sid, ce n'est pas vraiment prêt à être utilisé.
> Je ne veux pas être à "la page" nécessairement, mais j'aimerais juste avoir une chose fonctionnelle jusqu'aux ongles.
Ce qui serait possible avec une distro post-2.6.26.
Si Sid est très instable (plusieurs dizaines de mises à jour par jour est courant), et Testing beaucoup moins (quelques mises à jour quotidiennes seulement), je suis de ceux qui pensent que les deux sont très fonctionnelles ; et oui, j'irais jusqu'à dire jusqu'au bout des ongles (à condition de savoir reconfigurer un petit truc par-ci-par-là de temps en temps, surtout pour Sid - j'utilise deux Sid, Workstation et Laptop, et une Testing, HTPC... plus plein de serveurs en Stable, ou Testing, si elle est gelée).
Les deux sont en 2.6.26, pour l'instant. Quand Squeeze (la prochaine "testing", et donc, l'après-prochaine stable) émergera, je pense qu'on verra très vite 2.6.27 dans Sid (si ce n'est pas déjà fait d'ici là), et peu après, dans Squeeze.
Sinon, pour les branches :
- Experimental : ultra-bleeding-edge, en constante ébullition, pour préparer l'intégration dans Unstable (pas tout le temps) ;
- Unstable : passage obligé pour l'intégration aux branches moins instables (instable signifie que les paquets ne sont pas figés à leur version actuelle - ça peut être instable, et pour autant, fiable - comme ça peut ne pas l'être) ; elle s'appelle toujours Sid ;
- Testing : "rolling-release" vers la prochaine stable - figé toutes les quelques années pour donner la prochaine stable ; son nom est habituellement décidé par le dictateur bienveillant qui s'en va avant qu'elle ne sorte ; l'actuelle est Lenny, et la prochaine, Squeeze ;
- Stable : les versions des paquets ne bougent plus, sauf pour les mises à jour de sécurité, ce qui vient des dépôts tagués "versatile" (anti-virus et cie) et le AndAHalf (depuis Etch, pour un nouveau noyau, et des choses du genre, seulement si l'on en a besoin) ; l'actuelle est Etch, la prochaine Lenny (puis suivra Squeeze, un moment après qu'elle soit figée) ;
- Old stable : l'ancienne stable, supportée un an après la sortie de la stable actuelle ; l'actuelle est Sarge (plus supportée), la prochaine est Etch.
Sinon, c'est quoi, ta carte wifi, pour avoir besoin d'un >2.6.26 ? Une Atheros à ath9k ? Il me semble que ce soit le seul modèle à être entré si récemment dans Vanilla (à part peut-être pour la dernière série de chips Intel, que je n'ai jamais encore vu en vrai), mais je peux me tromper...
[^] # Re: restoration du wiki
Posté par Aefron . En réponse au journal Gentoo-wiki, Gentoo-portage : du neuf. Évalué à 3.
Mike visait au moins de l'octocore, 16Go de RAM, 50Gio d'espace, et une connexion de 10Mb (1,5-2Mb en moyenne).
Il semble qu'il ait mis en place du serveur VMware.
[^] # Re: restoration du wiki
Posté par Aefron . En réponse au journal Gentoo-wiki, Gentoo-portage : du neuf. Évalué à 2.
- Hébergement (fait)
- Configuration du serveur (fait)
- Remise en ligne de Gentoo portage (fait)
- Mettre en place le logiciel du wiki (commencé aujourd'hui, normalement)
- Mettre en place les langages
- Désigner les admins
- Réécrire les plugins/bots
- Mettre en place la structure du site
- Première éditions
- Procédure de sauvegarde complète
- Restaurer les anciennes données
- Accès public
Mike pense utiliser Google Cache, Archive.org et les sauvegardes datant de mars dernier, pour restaurer les anciennes données.