... et en évitant d'en mettre des tartines, ou de vouloir en lire, ça passe nickel pour moi : pour ce qui est du texte, j'y affiche un surveillant système avec la température de 4 cores, le début du nom de quelques trucs dans une barre à tâches verticale, l'heure, et la date... et dans le bon sens, en plus - le tout sur 72 pixels de large.
Je parlais plus des machines... et de leur environnement.
Mes serveurs sont des Athlon XP, en tours... ça marche nickel, mais, par exemple, l'été, ça chauffe dru (surtout si je lance un transcodage en masse de plusieurs jours sur le Q6600 qui est juste à côté). J'ai un onduleur, mais pas d'alims redondées, en outre...
... même si on n'est jamais à l'abri de rien, je n'ai pas trop de peine à imaginer que des machines soient mieux à l'abri dans un datacenter que dans mon bureau...
Sinon, pour le réseau, regarde ce que j'ai écrit sur l'upload, le reverse et l'IPv6 juste au-dessus... on est d'accord sur ce point : les FAI ne voient ostensiblement pas d'intérêt à faciliter l'auto-hébergement.
D'un autre côté, pour un blog, ce n'est pas forcément un mal d'avoir un truc un peu plus costaud que de l'hébergé chez soi...
Si tu postes un article qui va être repris sur des flux RSS (genre un planet, ou quelque chose du genre), il peut être avantageux d'avoir un hébergement "robuste", pour la disponibilité de l'article...
Ça n'enlève pas l'intérêt de faire tourner des choses chez soi : en ce qui me concerne, un dovecot en IMAPS (avec un fetchmail derrière, pour centraliser), un exim4 en relai STMP-AUTH (pour mon laptop, essentiellement), un chrooted-SFTP (pour mes données), et j'en passe quelques uns... pour ça, un nom de domaine m'est vraiment utile (et puis, tant qu'à faire, un pas moche... même si je passe par un CNAME vers no-IP, vu que je ne suis pas en IP fixe)...
Bon, après, j'ai du 16MBps/880kBps (réels... pas si mal, en cambrousse)... mais à choisir, je préfèrerais avoir du symétrique et moins de download... et puis, la gestion du reverse DNS, je ne cracherais pas dessus non plus. Tout comme de l'IPv6 natif (pour éviter d'avoir à me faire chier avec du NAT, entre autres)...
Donc, bon, selon les usages, on peut avoir des raisons d'utiliser du service externe (qui pourrait tout aussi bien être un serveur sur lequel on a la main, dédié ou pas), et vouloir auto-héberger d'autres choses... et à ce sujet, moult est fait pour nous en dissuader.
... pour moi, le plus ergonomique, ce sont les barres (pas qu'à tâches - d'ailleurs, celles-là, je ne les aimes pas trop ; je préfère une miniatures des bureaux) sur les côtés.
Les écrans étant généralement plus larges que hauts (4:3 ; 16:9 ; 16:10 ; ...), ça évite de perdre de la place dans la direction où il y en a le moins, et ça permet d'y mettre des choses vraiment utiles.
> Si tu veux avoir des mises à jours de l'équipe de sécurité prend stable ou testing.
Oula... 'ttention, quand même... Squeeze (la prochaine Testing, puis Stable) va certes gagner un support de sécurité : certes ; mais ce n'est pas encore fait, et ça ne sera pas fait tout de suite.
> Sinon prend sid.
D'un autre côté, les mises à jours atteignent Sid avant tout le reste...
Certes, le support de la sécurité dans Sid n'est pas officiel... n'en reste pas moins que c'est elle qui voit les nouveau paquets en premier, donc, elle n'est pas forcément en reste pour le code débarassé de bugs sécuritaires.
> si tu utilises Debian Sid, et que tu as un problème (genre tu ne peux plus utiliser vlc ou un autre logiciel courant)
... euh... dans les faits, ces dernières années, ce qu'il s'est surtout passé, c'est que VLC a dégagé de Testing (alors qu'il était toujours dans Stable et Unstable)...
Maintenant, je ne dis pas qu'il n'y avait pas de bug dans la version Sid - en fait, je n'en sais rien : je n'utilise pas VLC, avec lequel j'ai toujours eu des tonnes de problèmes... mais quand une appli disparaît de Testing :
- elle est généralement toujours dispo dans Sid,
- c'est en général parce beaucoup de gens ont beaucoup de problèmes avec (pour VLC, je me rappelle d'histoires de problèmes de sécu, de gros bugs et de dépendances non présentes dans Testing), et, personnellement, ça m'incite à ne surtout pas toucher à cette appli.
VLC a peut-être la cote sur les plate-formes redmondiennes, n'en reste pas moins qu'à chaque fois que j'y ai touché sur la banquise, j'ai eu de gros problèmes (sous-titres, blocs de pixels corrompus, plantages [et pas que sous Debian - aussi sous Gentoo, Arch, et la fois où j'ai testé Fedora], tearing, multi-écran foireux, ...)... et ça fait bien longtemps que je ne le considère plus comme un logiciel courant, ni même une appli recommandable...
Bref, VLC est tout sauf un cas général... et pour Debian, à vrai dire, en deux ans (~ depuis Etch... avant, j'étais Gentooiste), je ne me rappelle pas avoir eu le moindre problème particulier sous Sid... ah, si ! Une mise à jour foireuse de grub qui plantait le MBR - corrigée dans la journée (et détectée via apt-listbugs, quand même bien utile).
Bon, en fait, c'est plus profond - je ne dis pas que c'est possible, pour le bind de PowerDNS au serveur LDAP via un certificat client... juste que je ne peux même pas tester avec Debian Lenny...
... en fait, il semble que pour s'authentifier à OpenLDAP, via un certificat client, il faut utiliser SASL/EXTERNAL... ... or, OpenLDAP ne supporte pas SASL/EXTERNAL avec la libgnutls : il faut donc aussi avoir un OpenLDAP compilé avec la libssl comme dépendance...
... sauf que dans Lenny, Debian compile OpenLDAP (slapd aussi bien que ldap-utils) avec le support de la libgnutls à la place (alors que je ne vois pas trop le problème entre l'OpenLDAP Public Licence et la OpenSSL Licence, vu que la première n'interdit pas de rajouter la, certes infâme, clause publicitaire, exigée par la seconde... m'enfin, c'est juste infâme, pas incompatible)...
Bref, apparemment, pas de support du bind à de l'OpenLDAP via du certificat client dans Lenny (même ldapsearch se viande avec un truc du genre "TLS : mécanisme non supporté")... c'est la loose... :(
Par contre, pas d'exemple de TLS avec un certificat pour le client... mais moi qui découvre un peu LDAP ces temps-ci, j'ai un peu l'impression que l'authentification du client sur la base de donnée via un certificat client n'est pas chose si répandue que ça (genre, avec PowerDNS, ça n'a pas l'air d'être possible... même si je n'arrive de toute façon pas encore à lui faire vérifier le certificat du serveur :p ... enfin, ce serait dommage : avec tinyca2, je trouve plus simple de générer un certificat signé par un CA maison que de générer du mot de passe texte... à creuser, ce où j'en suis en ce moment).
Cela dit, pas besoin de ça pour avoir une connexion chiffrée (ça, j'y arrive bien avec du ldapsearch, et un ldap.conf qui va bien) - un certificat pour le serveur LDAP suffit : basiquement, tu signes le certificat de ton serveur [avec un autre certificat, ou pas, selon comme tu veux faire], et tu mets le certificat du CA sur le client (le CA est le couple clés privée/certificat, autosigné pour un CA maison, dont la clé privée t'a servi à signer le certificat de ton serveur - évidemment, la clé privée du CA, moins tu l'exposes, mieux c'est)... et ça roule.
Bon, je vais te répondre ici, dyno partouzeur de drouate (j'imagine que ton message dans le fil du dessus est une erreur de postage)...
... si les bugs sont critiques pour la sortie ("release-critical"), et bien, la règle est de les corriger pour officialiser la sortie (c'est le principe :p)... quant aux bugs corrigés, critiques ou pas, s'ils sont corrigés, euh... la question est donc bien celle des bugs non-critiques, et non-corrigés (ce qui n'est pas _une_ double négation, mais _deux_ négations en parallèle : nuance).
Maintenant, il y a des choses qui sont encore à la bourre... et qui ne sont pas encore intégrées à Lenny du tout, ce qui peut impliquer la disparition du paquet de Lenny (temporaire... ou pas), et sa présence uniquement dans Etch (vieille version) et Sid (version sur laquelle les intégrateurs travaillent, et qui rejoindra Lenny en temps utile, si elle finit par le faire, post-r0). Ça peut impliquer aussi le déclassement d'un bug comme étant "release-critical" vers un état moins grave (par exemple "can-defer", ie "peut attendre")...
L'intérêt ? Ne pas rajouter de bugs "release-critical", ni s'en encombrer, pour quelques trucs qui sont à la bourre, ce qui pénaliserait tout le monde à cause d'une minorité.
Exemple ? Mondo Rescue/Mindi [1]... Plein de problèmes dans la version de Sid, et, il me semble, comme l'un des devs du projet est mainteneur Debian, il a l'air d'avoir envie d'attendre un peu avant d'uploader la nouvelle version dans Lenny... surtout que, sur la page du projet, dans les dernières nouvelles [2], on peut voir qu'il y a eu du boulot sur Mindi spécifiquement (entre autres) pour Lenny. Bref, ce serait dommage de rester sur l'ancienne version, tout autant que mettre un truc pas prêt dans Lenny.
Autre exemple ? Le support du client NFS dans les conteneurs OpenVZ [3] ... le mainteneur explique clairement que le patch upstream le permettant étant clairement un casseur d'ABI, ce patch ne pourra être intégré que dans la version r1, le temps d'être sûr que, quitte à les casser, qu'il n'y ait au moins pas à le faire 36 fois, mais seulement quand le noyau de Lenny est bien défini.
Et puis, n'oublie pas : tu as un an de support de Etch, à compter de la sortie de Lenny... Ça va : il n'y a pas le feu au lac qui te force à migrer, là, dans 10 jours, hein...
Évidemment, tout ne sera pas parfait à la sortie : il restera des trucs pas finis, et de toute façon, on découvrira de nouveaux bugs au fur et à mesure du temps. Maintenant, j'ai signalé assez tôt ce qui me gênait le plus pour Lenny, et pour le reste, et bien je ferai avec (ne pas oublier non plus que, quelque temps après la sortie de Lenny, Testing, qui sera alors Squeeze, viendra à gagner un support de sécurité, et pourrait devenir raisonnablement utilisable dans des cas où Testing ne l'était pas, avant).
Bref, vivement le dégel : ça fait ~6 mois que ça a freezé... Sid est freezée... c'est nécessaire, mais point trop n'en faut non plus. Il est temps de s'agenouiller devant la nouvelle Debian (et que j'arrête de me prendre le choux avec le X.org d'Experimental, pour avoir de nouveau une Sid plutôt à jour, sans être cassée) :p
Ça, faut l'avouer, ce n'est pas le point fort de MythTV, même si c'est l'application HTPC plein écran que j'utilise...
... la navigation dans la musique est plutôt chiante (uniquement par artistes... ou playlist...)... il y a beaucoup à améliorer de ce côté.
Par contre, globalement, c'est une très bonne GUI plein écran (par contre, préférer un MPlayer que le lecteur interne, pour tout ce qui est H.264 : clairement à l'encontre de la recommandation officielle, mais fait est que...).
Moult fonctions : archi multi-clients/multi-serveurs, bibliothèque centralisée (MySQL), video, son, TV (avec cartes TV sur le serveur, et distribution du flux par le réseau), infos, émulation, interface web (par exemple pour programmer des enregistrements)... grave-puissant - j'aurais du mal à m'en passer, maintenant que ça fait quelques années que je l'utilise (un backend dans un conteneur OpenVZ, et trois clients : HTPC, workstation, laptop).
D'ailleurs, la prochaine version (0.22) apportera une belle GUI en QT4, du plus bel effet, de ce que j'ai testé du SVN.
Et évidemment, ça s'installe en tant que "simple" appli sur toute bonne distro (perso, je les prends chez Marillat, pour Debian).
> Ce n' est pas parcequ' il est aisé de booter sur un support amovible pour récupérer des données que l' authenfication de connection devrait être négliger.
Certes non... maintenant, il faut relativiser aussi. Si quelqu'un a un accès physique à une machine non chiffrée, il pourra trifouiller ce qu'il veut dans le /etc/shadow", voire, dans le "/etc/pam.d"... et donc, s'installer la serrure qui ira avec la clé qu'il voudra...
... voire récupérer les mots de passe qui vont bien (à la base, par exemple, pam_unix ne hashe le mot de passe qu'en MD5... c'est léger, très léger... bon, ça encore, ça peut être consolidé avec pam_unix2, en utilisant blowfish à la place de MD5, ou en exigeant une smartcard/clé privée pour accéder au compte...).
Reste le problème de l"intrusion en tant que root, en rebootant sur l'OS que le nuisible aura choisi... et ça, c'est autrement plus grave qu'un autologin en tant qu'utilisateur aux droits limités. Pleurer sur l'autologin quand on utilise de toute façon une machine ouverte à tous vents...
Ça fait déjà un moment que je n'entrepose plus de données personnelles sur la plupart de mes machine-clients (les données, j'y accède par le réseau, ou je me passe de facilités comme kwallet, jusqu'à trouver une solution qui me satisfasse, et donc, n'implique pas d'avoir les données en local)... et j'ai jusqu'ici surtout fait du chiffrement des espaces temporaires ("/tmp", "/var/tmp" et "swap" - essentiellement par inquiétude de fuites d'informations, par ailleurs, plutôt en "sécurité", sur mes serveurs, et donc, de discrétion paranoïaque - je pense en outre à chiffrer toutes les partitions, pour être sûr de l'intégrité des binaires, et m'assurer qu'ils ne pourront pas facilement être trifouillés par n'importe qui), avec de la clé générée aléatoirement au boot, via /dev/random...
... mais, clairement, quand je fais beaucoup d'accès disque (lecture de fichiers en passant par le kioslave sftp sur un réseau GBps [ce qui fait transiter via "/var/tmp"], retouche d'images un peu grosses [qui finissent par appeler le swap], ...), mon Centrino 1,7GHz en prend plein les dents... Bon, le Q6600 a moins de mal (voire pas du tout), mais ça n'empêche pas mon surveillant système de me montrer qu'il y a du core qui travaille, en ce genre de cas... et les disques durs bossent aussi moult, avec ça...
Après, avec une puce spécialisée dans le chiffrement (il me semble que des mobos Via ont de ça), je ne dis pas (et heureusement, vu le peu qu'ont les Via dans le ventre) - mais ce n'est pas ce qu'il y a de plus courant, comme matos... pour la plupart du matos, ça induit quand même pas mal de travail en plus à faire, pour gérer le chiffrement.
Si je veux bien admettre la seconde partie de ton commentaire, pour la première, que j'ai citée, j'ai plus de doutes...
Pour avoir eu l'occasion de chercher de la batterie de remplacement plusieurs fois, sur plusieurs modèles de téléphones, le modèle vendu avec celui-ci était systématiquement celui avec le moins de mAh...
... et forcément, ça en vient beaucoup plus vite à ne plus avoir assez de jus... et ça incite à changer de téléphone... en renouvelant par la même son contrat, tant qu'à faire...
Honnêtement, je n'ai pas l'impression que les opérateurs, qui me semblent être les premiers vendeurs pour la plupart des gens (je n'ai pas de chiffre - c'est juste une impression), aient vraiment envie que les gens aient des téléphones dont les batteries durent longtemps.
Juste pour dire... je me suis rendu compte de ce qui se passait en faisant un "gg:quelquechose" (et ça aurait été pareil si j'avais tapé linuxfr, et non le FQDN linufr.org, puisqu'en ce cas, Konqueror passe par le moteur de recherche par défaut, si défini, ie "google, j'ai de la chance", soit "ggl:machin", chez moi) ... :p
... et bien qu'utilisant ce même navigateur que je préfère à tous les autres (et bien qu'il me semble que les "raccourcis web" de Konqueror soient aussi dans Iceweasel [:p]), j'ai été touché quand même...
Donc, là, ce n'est pas tant une question de navigateur que de tout simplement utiliser google...
> C'est là qu'on se rend compte, qu'on utilise google toutes les 3 mn...
Clairement... bon, juste après, je suis allé dans mes bookmarks, et je me suis rendu compte que c'était une bonne occasion d'en profiter pour en trier un peu :)
Ça ira... tu saigneras peut-être un peu au début (pas autant qu'en cas de morsure de XML, généralement aux yeux, en plus), mais ce n'est pas venimeux ;)
KDE 4.2 a commencé à rentrer dans Experimental dimanche (ce qui fait qu'il y a de bonnes chances qu'Experimental soit cassée ces jours-ci) ;)
... mais il est possible qu'il y ait une suite à kde42.debian.net (dépôt temporaire)...
Testing a encore 99 bugs critiques, dont 49 n'ont pas encore de solution directe en vue [1]... Bref, Lenny n'est pas encore sortie, et Sid, pas encore dégelée...
Du coup, je vais sûrement me réinstaller une petite ArchLinux en double boot, pour tester KDE 4.2 plus avant, et dans de meilleures conditions (utiliser X.org 7.3 est un peu limitant pour moi, et c'est autrement plus difficile de le faire venir d'Experimental que KDE) ; ça faisait longtemps (Damnaide ! Le maigafrise m'a tuer ! :p).
> Que contient le /etc/network/interfaces dans Debian ?
Des choses analogues à ce qu'il y a, par exemple, dans les "/etc/sysconfig/network-scripts" pour les distros style RedHat (seulement, en effet, ça varie d'une distro à l'autre)...
Ça te permet de spécifier manuellement la configuration du réseau que tu veux... par exemple, pour du DHCP sur l'interface wlan0 en WPA, on y mettrait (ça pourrait être beaucoup plus compliqué, selon ce qu'on veut faire) :
... c'est ce que j'ai fait chez le pote en question (et ce que je fais sur toutes mes machines, généralement pour des IP fixes, mais y compris pour le laptop, afind'utiliser des pre/post-up/down, avec du guessnet et cie, pour gérer des choses différentes selon le réseau sur lequel je me trouve, comme le montage de certains partage, l'activation de certains services, ou simplement, retomber sur du DHCP par défaut, s'il ne connaît pas le réseau... on verra si NM arrive à remplacer cette tambouille avantageusement un jour), et ça a marché tout de suite (au WPA près : il tient à son WEP), contrairement à NM (avec ce dernier, un iwconfig montrait bien que la connexion à l'AP était faite, et que la clé de chiffrement bonne, mais ça coinçait après ça - pas moyen d'obtenir une adresse : timeout du DHCP, qui marchait pourtant en filaire, et en wifi avec un OS redmondien, ainsi qu'avec mon laptop).
> Comment lister les bornes Wifi
"iwlist wlan0 scan" (on peut rajouter des options selon qu'on veut scanner un canal particulier, etc...)...
> et les utiliser avec un simple ifup wlan0 (il ne doit pas y avoir ça sous Debian) ?
Bah, si : "ifup wlan0", ça marche sous Debian (si la carte n'était pas active, ou qu'elle avait été désactivée avec "ifdown wlan0"... sinon, au plus simple : "invoke-rc.d networking restart").
Remarque, le DHCP de cette box (les anciennes versions), via la carte wifi qu'on insère dedans, j'ai aussi eu des problèmes avec...
... via NetworkManager (sur une Lenny, fin décembre 2008) : l'authentification (WEP, chez un pote qui ne veut entendre parler de rien d'autre) fonctionnait nickel, mais le DHCP faisait un timeout 9 fois sur 10 (ça a marché une ou deux fois... la box a aussi craqué un PPP avec obligation de hard-reboot au cours des tentatives)... les IP statiques marchaient nickel, par contre.
Bon, en revanche, ça a marché direct avec le DHCP dans /etc/network/interfaces... j'ai renoncé à chercher à comprendre...
J'ai la même carte wifi que le pote en question, je l'ai vue sur d'autres machines (Atheros sur ath5k), et ces cartes me semblent maintenant fonctionner correctement (seul "hack" éventuellement nécessaire : désactiver l'autonégociation du taux de transfert, en le spécifiant manuellement)...
J'ai une confiance limitée en NM, mais normalement, le DHCP, ça fonctionne correctement, avec (en tout cas, toutes les autres fois où j'ai essayé, pour NM pré-0.7 ; ce qui est bien mon problème : chez moi, DHCP, c'est uniquement pour les invités, sur une portion très limitée du réseau, sur laquelle je ne branche presque jamais mon laptop)...
J'ai vu ça sur un OS non-redmondien...
Maintenant, la freebox (un ancien modèle... je ne sais pas si ça change quelque chose ; en tout cas, ça ne faisait ça qu'avec la carte wifi, et NM, alors que ça passait à la mano, et sous l'OS redmondien en double-boot) est le seul routeur sur lequel j'ai vu ça... j'en ai en tout cas déduit qu'il y avait quelque chose de spécial avec elle (et NM), ostensiblement.
Et puis, ça me fait une raison de plus pour vouloir utiliser mes _routeurs_, sur lesquels j'ai _ma_ main, et un modem séparé, qui ne fait _que modem_ (et quitte à me monter un serveur SIP, à base de compte style-OVH - ce qui est de toute façon sur ma liste de choses à faire)...
Mais si ça peut te rassurer (ou pas), KDE4 n'est pas non plus dans Testing (Lenny), ni dans Unstable (Sid)... par contre, c'est dans Experimental (4.1) et dans du dépôt spécial (snapshots de 4.2).
Bah oui : Debian est freezée depuis l'été dernier, et donc, tout l'est, y compris jusqu'à Unstable, peu ou prou... Pour peu que ça dure, KDE 4.3 pourrait rentrer dans Sid à l'été (au dégel :)...
[^] # Re: Gnome et innovation : une mauvaise blague!
Posté par Aefron . En réponse au journal KDE4 ressemble trop à windows seven. Évalué à 2.
... et en évitant d'en mettre des tartines, ou de vouloir en lire, ça passe nickel pour moi : pour ce qui est du texte, j'y affiche un surveillant système avec la température de 4 cores, le début du nom de quelques trucs dans une barre à tâches verticale, l'heure, et la date... et dans le bon sens, en plus - le tout sur 72 pixels de large.
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 3.
Mes serveurs sont des Athlon XP, en tours... ça marche nickel, mais, par exemple, l'été, ça chauffe dru (surtout si je lance un transcodage en masse de plusieurs jours sur le Q6600 qui est juste à côté). J'ai un onduleur, mais pas d'alims redondées, en outre...
... même si on n'est jamais à l'abri de rien, je n'ai pas trop de peine à imaginer que des machines soient mieux à l'abri dans un datacenter que dans mon bureau...
Sinon, pour le réseau, regarde ce que j'ai écrit sur l'upload, le reverse et l'IPv6 juste au-dessus... on est d'accord sur ce point : les FAI ne voient ostensiblement pas d'intérêt à faciliter l'auto-hébergement.
[^] # Re: Auto hébergement
Posté par Aefron . En réponse au journal Tout le monde a intérêt à transformer Internet en Minitel. Évalué à 5.
Si tu postes un article qui va être repris sur des flux RSS (genre un planet, ou quelque chose du genre), il peut être avantageux d'avoir un hébergement "robuste", pour la disponibilité de l'article...
Ça n'enlève pas l'intérêt de faire tourner des choses chez soi : en ce qui me concerne, un dovecot en IMAPS (avec un fetchmail derrière, pour centraliser), un exim4 en relai STMP-AUTH (pour mon laptop, essentiellement), un chrooted-SFTP (pour mes données), et j'en passe quelques uns... pour ça, un nom de domaine m'est vraiment utile (et puis, tant qu'à faire, un pas moche... même si je passe par un CNAME vers no-IP, vu que je ne suis pas en IP fixe)...
Bon, après, j'ai du 16MBps/880kBps (réels... pas si mal, en cambrousse)... mais à choisir, je préfèrerais avoir du symétrique et moins de download... et puis, la gestion du reverse DNS, je ne cracherais pas dessus non plus. Tout comme de l'IPv6 natif (pour éviter d'avoir à me faire chier avec du NAT, entre autres)...
Donc, bon, selon les usages, on peut avoir des raisons d'utiliser du service externe (qui pourrait tout aussi bien être un serveur sur lequel on a la main, dédié ou pas), et vouloir auto-héberger d'autres choses... et à ce sujet, moult est fait pour nous en dissuader.
[^] # Re: Gnome et innovation : une mauvaise blague!
Posté par Aefron . En réponse au journal KDE4 ressemble trop à windows seven. Évalué à 3.
... pour moi, le plus ergonomique, ce sont les barres (pas qu'à tâches - d'ailleurs, celles-là, je ne les aimes pas trop ; je préfère une miniatures des bureaux) sur les côtés.
Les écrans étant généralement plus larges que hauts (4:3 ; 16:9 ; 16:10 ; ...), ça évite de perdre de la place dans la direction où il y en a le moins, et ça permet d'y mettre des choses vraiment utiles.
[^] # Re: L'info à la source
Posté par Aefron . En réponse au message Testing ou unstable. Évalué à 4.
Oula... 'ttention, quand même... Squeeze (la prochaine Testing, puis Stable) va certes gagner un support de sécurité : certes ; mais ce n'est pas encore fait, et ça ne sera pas fait tout de suite.
> Sinon prend sid.
D'un autre côté, les mises à jours atteignent Sid avant tout le reste...
Certes, le support de la sécurité dans Sid n'est pas officiel... n'en reste pas moins que c'est elle qui voit les nouveau paquets en premier, donc, elle n'est pas forcément en reste pour le code débarassé de bugs sécuritaires.
[^] # Re: debian pour le desktop ?
Posté par Aefron . En réponse au message Testing ou unstable. Évalué à 2.
... euh... dans les faits, ces dernières années, ce qu'il s'est surtout passé, c'est que VLC a dégagé de Testing (alors qu'il était toujours dans Stable et Unstable)...
Maintenant, je ne dis pas qu'il n'y avait pas de bug dans la version Sid - en fait, je n'en sais rien : je n'utilise pas VLC, avec lequel j'ai toujours eu des tonnes de problèmes... mais quand une appli disparaît de Testing :
- elle est généralement toujours dispo dans Sid,
- c'est en général parce beaucoup de gens ont beaucoup de problèmes avec (pour VLC, je me rappelle d'histoires de problèmes de sécu, de gros bugs et de dépendances non présentes dans Testing), et, personnellement, ça m'incite à ne surtout pas toucher à cette appli.
VLC a peut-être la cote sur les plate-formes redmondiennes, n'en reste pas moins qu'à chaque fois que j'y ai touché sur la banquise, j'ai eu de gros problèmes (sous-titres, blocs de pixels corrompus, plantages [et pas que sous Debian - aussi sous Gentoo, Arch, et la fois où j'ai testé Fedora], tearing, multi-écran foireux, ...)... et ça fait bien longtemps que je ne le considère plus comme un logiciel courant, ni même une appli recommandable...
Bref, VLC est tout sauf un cas général... et pour Debian, à vrai dire, en deux ans (~ depuis Etch... avant, j'étais Gentooiste), je ne me rappelle pas avoir eu le moindre problème particulier sous Sid... ah, si ! Une mise à jour foireuse de grub qui plantait le MBR - corrigée dans la journée (et détectée via apt-listbugs, quand même bien utile).
[^] # Re: En anglais...
Posté par Aefron . En réponse au message Client sur OpenLdap+SSL. Évalué à 2.
... en fait, il semble que pour s'authentifier à OpenLDAP, via un certificat client, il faut utiliser SASL/EXTERNAL... ... or, OpenLDAP ne supporte pas SASL/EXTERNAL avec la libgnutls : il faut donc aussi avoir un OpenLDAP compilé avec la libssl comme dépendance...
... sauf que dans Lenny, Debian compile OpenLDAP (slapd aussi bien que ldap-utils) avec le support de la libgnutls à la place (alors que je ne vois pas trop le problème entre l'OpenLDAP Public Licence et la OpenSSL Licence, vu que la première n'interdit pas de rajouter la, certes infâme, clause publicitaire, exigée par la seconde... m'enfin, c'est juste infâme, pas incompatible)...
Bref, apparemment, pas de support du bind à de l'OpenLDAP via du certificat client dans Lenny (même ldapsearch se viande avec un truc du genre "TLS : mécanisme non supporté")... c'est la loose... :(
[^] # Re: Enfin de la vente sur bahn.de ?
Posté par Aefron . En réponse au journal Amende de 5 millions d'euros pour la SNCF. Évalué à 9.
[^] # Re: .
Posté par Aefron . En réponse au journal Logiciel "privateur" Vs "propriétaire". Évalué à 3.
# En anglais...
Posté par Aefron . En réponse au message Client sur OpenLdap+SSL. Évalué à 2.
Par contre, pas d'exemple de TLS avec un certificat pour le client... mais moi qui découvre un peu LDAP ces temps-ci, j'ai un peu l'impression que l'authentification du client sur la base de donnée via un certificat client n'est pas chose si répandue que ça (genre, avec PowerDNS, ça n'a pas l'air d'être possible... même si je n'arrive de toute façon pas encore à lui faire vérifier le certificat du serveur :p ... enfin, ce serait dommage : avec tinyca2, je trouve plus simple de générer un certificat signé par un CA maison que de générer du mot de passe texte... à creuser, ce où j'en suis en ce moment).
Cela dit, pas besoin de ça pour avoir une connexion chiffrée (ça, j'y arrive bien avec du ldapsearch, et un ldap.conf qui va bien) - un certificat pour le serveur LDAP suffit : basiquement, tu signes le certificat de ton serveur [avec un autre certificat, ou pas, selon comme tu veux faire], et tu mets le certificat du CA sur le client (le CA est le couple clés privée/certificat, autosigné pour un CA maison, dont la clé privée t'a servi à signer le certificat de ton serveur - évidemment, la clé privée du CA, moins tu l'exposes, mieux c'est)... et ça roule.
Sinon, il y a aussi pas mal d'infos utiles et de recettes dans le tuto de YoLinux : http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP.html ...
[^] # Re: Seuls les bogues critiques seront corrigés
Posté par Aefron . En réponse au journal Debian GNU/Linux 5.0 "Lenny" annoncé pour la Saint-Valentin !. Évalué à 10.
... si les bugs sont critiques pour la sortie ("release-critical"), et bien, la règle est de les corriger pour officialiser la sortie (c'est le principe :p)... quant aux bugs corrigés, critiques ou pas, s'ils sont corrigés, euh... la question est donc bien celle des bugs non-critiques, et non-corrigés (ce qui n'est pas _une_ double négation, mais _deux_ négations en parallèle : nuance).
Maintenant, il y a des choses qui sont encore à la bourre... et qui ne sont pas encore intégrées à Lenny du tout, ce qui peut impliquer la disparition du paquet de Lenny (temporaire... ou pas), et sa présence uniquement dans Etch (vieille version) et Sid (version sur laquelle les intégrateurs travaillent, et qui rejoindra Lenny en temps utile, si elle finit par le faire, post-r0). Ça peut impliquer aussi le déclassement d'un bug comme étant "release-critical" vers un état moins grave (par exemple "can-defer", ie "peut attendre")...
L'intérêt ? Ne pas rajouter de bugs "release-critical", ni s'en encombrer, pour quelques trucs qui sont à la bourre, ce qui pénaliserait tout le monde à cause d'une minorité.
Exemple ? Mondo Rescue/Mindi [1]... Plein de problèmes dans la version de Sid, et, il me semble, comme l'un des devs du projet est mainteneur Debian, il a l'air d'avoir envie d'attendre un peu avant d'uploader la nouvelle version dans Lenny... surtout que, sur la page du projet, dans les dernières nouvelles [2], on peut voir qu'il y a eu du boulot sur Mindi spécifiquement (entre autres) pour Lenny. Bref, ce serait dommage de rester sur l'ancienne version, tout autant que mettre un truc pas prêt dans Lenny.
Autre exemple ? Le support du client NFS dans les conteneurs OpenVZ [3] ... le mainteneur explique clairement que le patch upstream le permettant étant clairement un casseur d'ABI, ce patch ne pourra être intégré que dans la version r1, le temps d'être sûr que, quitte à les casser, qu'il n'y ait au moins pas à le faire 36 fois, mais seulement quand le noyau de Lenny est bien défini.
Et puis, n'oublie pas : tu as un an de support de Etch, à compter de la sortie de Lenny... Ça va : il n'y a pas le feu au lac qui te force à migrer, là, dans 10 jours, hein...
Évidemment, tout ne sera pas parfait à la sortie : il restera des trucs pas finis, et de toute façon, on découvrira de nouveaux bugs au fur et à mesure du temps. Maintenant, j'ai signalé assez tôt ce qui me gênait le plus pour Lenny, et pour le reste, et bien je ferai avec (ne pas oublier non plus que, quelque temps après la sortie de Lenny, Testing, qui sera alors Squeeze, viendra à gagner un support de sécurité, et pourrait devenir raisonnablement utilisable dans des cas où Testing ne l'était pas, avant).
Bref, vivement le dégel : ça fait ~6 mois que ça a freezé... Sid est freezée... c'est nécessaire, mais point trop n'en faut non plus. Il est temps de s'agenouiller devant la nouvelle Debian (et que j'arrête de me prendre le choux avec le X.org d'Experimental, pour avoir de nouveau une Sid plutôt à jour, sans être cassée) :p
[1] http://packages.debian.org/search?keywords=mondo
[2] http://www.mondorescue.org/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501985
[^] # Re: Seuls les bogues critiques seront corrigés
Posté par Aefron . En réponse au journal Debian GNU/Linux 5.0 "Lenny" annoncé pour la Saint-Valentin !. Évalué à 4.
[^] # Re: En executable standard
Posté par Aefron . En réponse à la dépêche Sortie de la GeeXboX 1.2. Évalué à 2.
Ça, faut l'avouer, ce n'est pas le point fort de MythTV, même si c'est l'application HTPC plein écran que j'utilise...
... la navigation dans la musique est plutôt chiante (uniquement par artistes... ou playlist...)... il y a beaucoup à améliorer de ce côté.
Par contre, globalement, c'est une très bonne GUI plein écran (par contre, préférer un MPlayer que le lecteur interne, pour tout ce qui est H.264 : clairement à l'encontre de la recommandation officielle, mais fait est que...).
Moult fonctions : archi multi-clients/multi-serveurs, bibliothèque centralisée (MySQL), video, son, TV (avec cartes TV sur le serveur, et distribution du flux par le réseau), infos, émulation, interface web (par exemple pour programmer des enregistrements)... grave-puissant - j'aurais du mal à m'en passer, maintenant que ça fait quelques années que je l'utilise (un backend dans un conteneur OpenVZ, et trois clients : HTPC, workstation, laptop).
D'ailleurs, la prochaine version (0.22) apportera une belle GUI en QT4, du plus bel effet, de ce que j'ai testé du SVN.
Et évidemment, ça s'installe en tant que "simple" appli sur toute bonne distro (perso, je les prends chez Marillat, pour Debian).
[^] # Re: Mouarf
Posté par Aefron . En réponse au journal Troll : Ubuntu vs other AND KDE vs Gnome réuni !. Évalué à 3.
Là [1], il n'y en a qu'un, de Blu-ray... et c'est logique : à l'heure actuelle, Lenny tient sur ~4,3DVD (~19Gio)...
[1] http://cdimage.debian.org/cdimage/lenny_di_rc2/i386/jigdo-bd(...)
[^] # Re: "Données sensibles sur mon ordinateur"
Posté par Aefron . En réponse au journal Sortie Moblin-Alpha 1. Évalué à 3.
Certes non... maintenant, il faut relativiser aussi. Si quelqu'un a un accès physique à une machine non chiffrée, il pourra trifouiller ce qu'il veut dans le /etc/shadow", voire, dans le "/etc/pam.d"... et donc, s'installer la serrure qui ira avec la clé qu'il voudra...
... voire récupérer les mots de passe qui vont bien (à la base, par exemple, pam_unix ne hashe le mot de passe qu'en MD5... c'est léger, très léger... bon, ça encore, ça peut être consolidé avec pam_unix2, en utilisant blowfish à la place de MD5, ou en exigeant une smartcard/clé privée pour accéder au compte...).
Reste le problème de l"intrusion en tant que root, en rebootant sur l'OS que le nuisible aura choisi... et ça, c'est autrement plus grave qu'un autologin en tant qu'utilisateur aux droits limités. Pleurer sur l'autologin quand on utilise de toute façon une machine ouverte à tous vents...
[^] # Re: "Données sensibles sur mon ordinateur"
Posté par Aefron . En réponse au journal Sortie Moblin-Alpha 1. Évalué à 2.
... mais, clairement, quand je fais beaucoup d'accès disque (lecture de fichiers en passant par le kioslave sftp sur un réseau GBps [ce qui fait transiter via "/var/tmp"], retouche d'images un peu grosses [qui finissent par appeler le swap], ...), mon Centrino 1,7GHz en prend plein les dents... Bon, le Q6600 a moins de mal (voire pas du tout), mais ça n'empêche pas mon surveillant système de me montrer qu'il y a du core qui travaille, en ce genre de cas... et les disques durs bossent aussi moult, avec ça...
Après, avec une puce spécialisée dans le chiffrement (il me semble que des mobos Via ont de ça), je ne dis pas (et heureusement, vu le peu qu'ont les Via dans le ventre) - mais ce n'est pas ce qu'il y a de plus courant, comme matos... pour la plupart du matos, ça induit quand même pas mal de travail en plus à faire, pour gérer le chiffrement.
[^] # Re: Tout simple…
Posté par Aefron . En réponse au sondage Mon téléphone mobile. Évalué à 2.
Si je veux bien admettre la seconde partie de ton commentaire, pour la première, que j'ai citée, j'ai plus de doutes...
Pour avoir eu l'occasion de chercher de la batterie de remplacement plusieurs fois, sur plusieurs modèles de téléphones, le modèle vendu avec celui-ci était systématiquement celui avec le moins de mAh...
... et forcément, ça en vient beaucoup plus vite à ne plus avoir assez de jus... et ça incite à changer de téléphone... en renouvelant par la même son contrat, tant qu'à faire...
Honnêtement, je n'ai pas l'impression que les opérateurs, qui me semblent être les premiers vendeurs pour la plupart des gens (je n'ai pas de chiffre - c'est juste une impression), aient vraiment envie que les gens aient des téléphones dont les batteries durent longtemps.
[^] # Re: un gros bug...
Posté par Aefron . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 3.
... et bien qu'utilisant ce même navigateur que je préfère à tous les autres (et bien qu'il me semble que les "raccourcis web" de Konqueror soient aussi dans Iceweasel [:p]), j'ai été touché quand même...
Donc, là, ce n'est pas tant une question de navigateur que de tout simplement utiliser google...
[^] # Re: un gros bug...
Posté par Aefron . En réponse au journal [HS] Attention, internet peut endomager votre ordinateur. Évalué à 4.
Clairement... bon, juste après, je suis allé dans mes bookmarks, et je me suis rendu compte que c'était une bonne occasion d'en profiter pour en trier un peu :)
[^] # Re: Sympa la comparaison...
Posté par Aefron . En réponse au journal Nicholas Negroponte et le projet OLPC. Évalué à 6.
Ah non ! Pluto, c'est le chien de Mickey. L'ami de Mickey, c'est Dingo...
[^] # Re: J'hésite...
Posté par Aefron . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
[^] # Re: Debian
Posté par Aefron . En réponse au journal Linus Torvalds est décu.... Évalué à 3.
... mais il est possible qu'il y ait une suite à kde42.debian.net (dépôt temporaire)...
Testing a encore 99 bugs critiques, dont 49 n'ont pas encore de solution directe en vue [1]... Bref, Lenny n'est pas encore sortie, et Sid, pas encore dégelée...
Du coup, je vais sûrement me réinstaller une petite ArchLinux en double boot, pour tester KDE 4.2 plus avant, et dans de meilleures conditions (utiliser X.org 7.3 est un peu limitant pour moi, et c'est autrement plus difficile de le faire venir d'Experimental que KDE) ; ça faisait longtemps (Damnaide ! Le maigafrise m'a tuer ! :p).
[1] http://lists.debian.org/debian-news/2009/msg00000.html
[^] # Re: Euh...
Posté par Aefron . En réponse au journal Mon coup de gueule du jour. Évalué à 2.
Des choses analogues à ce qu'il y a, par exemple, dans les "/etc/sysconfig/network-scripts" pour les distros style RedHat (seulement, en effet, ça varie d'une distro à l'autre)...
Ça te permet de spécifier manuellement la configuration du réseau que tu veux... par exemple, pour du DHCP sur l'interface wlan0 en WPA, on y mettrait (ça pourrait être beaucoup plus compliqué, selon ce qu'on veut faire) :
"auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid monssid
wpa-psk blabla_secret"
... c'est ce que j'ai fait chez le pote en question (et ce que je fais sur toutes mes machines, généralement pour des IP fixes, mais y compris pour le laptop, afind'utiliser des pre/post-up/down, avec du guessnet et cie, pour gérer des choses différentes selon le réseau sur lequel je me trouve, comme le montage de certains partage, l'activation de certains services, ou simplement, retomber sur du DHCP par défaut, s'il ne connaît pas le réseau... on verra si NM arrive à remplacer cette tambouille avantageusement un jour), et ça a marché tout de suite (au WPA près : il tient à son WEP), contrairement à NM (avec ce dernier, un iwconfig montrait bien que la connexion à l'AP était faite, et que la clé de chiffrement bonne, mais ça coinçait après ça - pas moyen d'obtenir une adresse : timeout du DHCP, qui marchait pourtant en filaire, et en wifi avec un OS redmondien, ainsi qu'avec mon laptop).
> Comment lister les bornes Wifi
"iwlist wlan0 scan" (on peut rajouter des options selon qu'on veut scanner un canal particulier, etc...)...
> et les utiliser avec un simple ifup wlan0 (il ne doit pas y avoir ça sous Debian) ?
Bah, si : "ifup wlan0", ça marche sous Debian (si la carte n'était pas active, ou qu'elle avait été désactivée avec "ifdown wlan0"... sinon, au plus simple : "invoke-rc.d networking restart").
[^] # Re: Euh...
Posté par Aefron . En réponse au journal Mon coup de gueule du jour. Évalué à 2.
... via NetworkManager (sur une Lenny, fin décembre 2008) : l'authentification (WEP, chez un pote qui ne veut entendre parler de rien d'autre) fonctionnait nickel, mais le DHCP faisait un timeout 9 fois sur 10 (ça a marché une ou deux fois... la box a aussi craqué un PPP avec obligation de hard-reboot au cours des tentatives)... les IP statiques marchaient nickel, par contre.
Bon, en revanche, ça a marché direct avec le DHCP dans /etc/network/interfaces... j'ai renoncé à chercher à comprendre...
J'ai la même carte wifi que le pote en question, je l'ai vue sur d'autres machines (Atheros sur ath5k), et ces cartes me semblent maintenant fonctionner correctement (seul "hack" éventuellement nécessaire : désactiver l'autonégociation du taux de transfert, en le spécifiant manuellement)...
J'ai une confiance limitée en NM, mais normalement, le DHCP, ça fonctionne correctement, avec (en tout cas, toutes les autres fois où j'ai essayé, pour NM pré-0.7 ; ce qui est bien mon problème : chez moi, DHCP, c'est uniquement pour les invités, sur une portion très limitée du réseau, sur laquelle je ne branche presque jamais mon laptop)...
J'ai vu ça sur un OS non-redmondien...
Maintenant, la freebox (un ancien modèle... je ne sais pas si ça change quelque chose ; en tout cas, ça ne faisait ça qu'avec la carte wifi, et NM, alors que ça passait à la mano, et sous l'OS redmondien en double-boot) est le seul routeur sur lequel j'ai vu ça... j'en ai en tout cas déduit qu'il y avait quelque chose de spécial avec elle (et NM), ostensiblement.
Et puis, ça me fait une raison de plus pour vouloir utiliser mes _routeurs_, sur lesquels j'ai _ma_ main, et un modem séparé, qui ne fait _que modem_ (et quitte à me monter un serveur SIP, à base de compte style-OVH - ce qui est de toute façon sur ma liste de choses à faire)...
[^] # Re: Un troll peut en cacher un autre :-)
Posté par Aefron . En réponse au journal et un euro de plus dans la machine à troll. Évalué à 3.
Mais si ça peut te rassurer (ou pas), KDE4 n'est pas non plus dans Testing (Lenny), ni dans Unstable (Sid)... par contre, c'est dans Experimental (4.1) et dans du dépôt spécial (snapshots de 4.2).
Bah oui : Debian est freezée depuis l'été dernier, et donc, tout l'est, y compris jusqu'à Unstable, peu ou prou... Pour peu que ça dure, KDE 4.3 pourrait rentrer dans Sid à l'été (au dégel :)...