rictus a écrit 390 commentaires

la commande aptitude est un bon frontal à apt-get et apt-cache :
aptitude update (~ yum check-update)
aptitude upgrade (~ yum upgrade)
aptitude install (etc…)
aptitude search…
aptitude était d'ailleurs préconisée au moins à partir de debian squeeze…

Grosso modo le plugin priorities de yum correspond au pinning de apt…
yum a bien rattrappé son retard par rapport à apt, ça me semblerait être du troll ou du vrai subjectif de dire que l'un est supérieur à l'autre… même si je suis sûr qu'on peut trouver des exemples de choses que fait l'un mais pas l'autre.
Subjectivement, je préfère apt, mais dans mon usage quotidien yum se comporte aussi bien.

Euh, je ne comprends pas, on n'est pas le 1er avril ?

A mon avis, retirer 20% des valeurs extrêmes (traduire bêtement les deux valeurs les plus basses et les deux les plus hautes sur 10 mesures), c'est juste un peu plus simple à implémenter qu'un calcul d'une médiane (même si c'est pas beaucoup plus compliqué), pour un résultat tout aussi pertinent…

Oui, mais on n'y trouve pas forcément des packages très à jours non plus… et quid du suivi de sécurité ?
Idem pour rpmforge que je préfère globalement à EPEL (pas de troll, j'assume que c'est subjectif).

Juste pour précision : dans ton cas avec une VM windows, oui tu as des pilotes virtio à installer pour profiter des accélérations de périphériques paravirtuels.
Pour un linux, ce sont des modules kernel inclus souvent de base dans les distributions pas trop vieilles (car modules libres). Donc rien à installer de plus pour en profiter.
Je crois que vmware esx a également des modules libres pour ses périphériques paravirtuels, donc également inclus de base…

KVM est certes une virtualisation complète, mais propose aussi des périphériques paravirtuels (controleur disque, réseau, video) pour les OS virtualisés le supportant, histoire de gagner en performance.

Personnellement, j'ai du mal à voir les avantages de xen, qui n'offre ni la souplesse (choix de l'OS ou du kernel) d'une virtualisation plus ou moins complète à la KVM, ni l'efficacité d'un système de conteneur à la openVZ.

Il serait intéressant de savoir si d'avoir choisi VDPAU est purement fortuit (seule API disponible au début du développement) ou s'il y a une véritable raison (bonne ou mauvaise)…
Mais ça me semble quand même dommage d'avoir 3 API (une soutenue par chaque constructeur) pour faire la même chose… le choix, c'est parfois bien, parfois non… et là je crois que c'est non.

Bon newbie que je suis en openVZ, je viens de découvrir les commandes vztop et vzps qui te permettent justement de faire le trie entre les process hôtes et ceux de tes conteneurs…
Donc voilà, c'est bien ça : il faut utiliser ces nouvelles commandes à la place des traditionnelles top et ps non prévues pour fonctionner sur un noyau openVZ.

Est-ce que quelqu'un sait ce que va faire proxmox avec la sortie prochaine (disons 1er semestre 2013) de debian wheezy ? Abandon de openVZ au profit de LXC ? Bascule sur wheezy avec toujours un noyau 2.6.32 ? Rien ?

Proxmox, ce n'est qu'une surcouche à KVM et OpenVZ, pour les "manager", ce n'est pas un système de virtualisation à proprement parler.

Pour l'exemple 1 : avec OpenVZ, c'est exactement pareil, tu vois sur l'hôte avec top ou ps les process de tes conteneurs, avec les propriétaires de l'hôte.
Je pense que c'est plus les commandes top ou ps qui ne sont adaptés à ce système de conteneur.

En général pourtant l'état de l'art veut justement que tu aies un "réseau" dédié de tes noeuds vers le stockage des VM : interfaces réseaux dédiées en NFS ou iscsi dans un plan d'adressage différent ou bien idéalement du SAN…

Mais sinon, c'est sûr que tu fais avec les moyens que tu peux avoir… et proxmox se débrouille assez bien avec de petits moyens.

Cette plate-forme est attrayante car sensiblement plus puissante que le Raspberry, mais aussi plus cher (tout en restant, je te l'accorde, très abordable).
Mais en ce qui concerne l'open source, de ce que j'en lis, je crois qu'elle a encore pas mal à prouver.
(Aucun support du GPU Mali pour Linux, semble plus orientée Android, sans pour autant être officiellement supporté par CyanogenMod…).

Aller, je ne vais pas voir le verre à moitié vide, mais pour l'instant : à suivre !

Je comprends les arguments et le fait que l'annonce de rpi fait buzz commercial.
Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.

Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbing sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".

Pour une carte graphique d'un PC, si je prends l'exemple de mon chipset avec une radeon HD4200, certes il y a un pilote complétement libre (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence), avec la possibilité pour qui voudrait d'améliorer ce qu'il souhaite… mais au final, les performances de ce pilote libre sont toujours très loin derrière celles du pilote proprio. Il faudrait que cela soit ce dernier qui soit libéré pour être 100% gagnant pour l'utilisateur finale. Donc je ne considère pas que amd fait mieux que broadcom par exemple.
Je ne lancerais pas de troll avec NVIDIA.

Le raspberry me semble donc être un des matériels les plus libres qui existent : je ne vous dis pas d'en être un fanatique extrémiste incapable d'aucun esprit critique. Mais avoir constamment l'esprit chagrin et dénigrer les bonnes volontés qui font avancer le shmilblik, ça n'est pas top non plus.

J'ai pas testé, c'est sûrement pas idéal, mais on trouve des adaptateurs ethernet usb pour une dizaine d'euros.

Ton truc ressemble fortement à une guruplug : http://www.globalscaletechnologies.com/t-guruplugdetails.asp(...)
Les performances du kirkwood 1,2 Ghz associé à de la DDR 2 16 bits ne sont tout de même pas extraordinaires, on peut trouver des bench openssl qui montrent qu'on atteint environ un PIII 800 Mhz. Bon, dans l'absolu, ça peut être largement suffisant pour de l'auto-hébergement, mais perso, je trouve ça trop cher pour ce que c'est.
Un "gadget" (sans mépris) de ce genre ne devrait pas coûter plus de 150 €.
En plus attention, le kernel utilisé est souvent un peu spécifique, du coup tu n'es pas en 100% debian, et les updates de sécurité ne sont pas toujours bien suivis.
Pour le même prix, voire un peu moins, tu peux avoir un mini pc ou un netbook à base d'Atom, permettant un usage beaucoup plus classique, avec une consommation électrique qui reste à mon avis raisonnable.

Difficile d'avoir un vrai recul sur l'état de santé des différents unix proprios, mais HP a sorti son HPUX 11iV3 il y a à peine 3 ans (ce qui est récent compte tenu des cycles de vie de ces OS, du temps mis par toutes les éditeurs tiers de certifier/adapter leur applis, et donc après des clients finaux de l'adopter...) et il apportait aussi pas mal de nouveautés par rapport à la V2...
Quant à Solaris, ça vivote toujours autour des évolutions d'opensolaris, non ?

Bref tu enterres un peu vite les autres, même si c'est dûr de savoir où chacun en est vraiment. Il y a des secteurs d'activités (banques, administrations...) où on ne jure que par AIX, mais d'autres où c'est HPUX (certaines industries...) et d'autres Solaris (bon, pour ce dernier, j'ai le sentiment que ça sent le sapin, mais je ne suis pas en contact avec tous les secteurs d'activités. J'avais une expérience d'il y a 7/8 ans où il était encore assez utilisé en CAO).

J'ai pas d'info par rapport à ZFS et à ce portage, mais tu peux très bien utiliser un module noyau non GPL, mais le kernel sera alors marqué tainted.
Si la licence n'a pas changé, ce portage ne sera donc jamais inclus directement dans les sources officielles du noyau, ce qui semble largement limiter son intérêt... mais bon, pourquoi pas. Ca va encore troller sur ZFS (fanboys et anti ou pro autre chose...). De toute façon vim ça roxor plus !

imho, mieux vaut éviter le RAID 1, mais plutôt monter un système de backup automatique (rsnapshot, rsync, backuppc...) d'un disque sur l'autre 1 fois par jour, si c'est juste pour s'affranchir de la mort d'un disque...

D'après http://rt2x00.serialmonkey.com/wiki/index.php/Hardware
Oui, la HWGUSB2-54, c'est un rt2570 (version USB du rt2500), comme le dongle nintendo cité ci-dessus.

Si c'est pour lenny donc sans troll inside, il te faut donc un dongle USB supporté sur un noyau 2.6.26 qui a plus de deux ans... il doit pas y avoir beaucoup de n ..., voire plus beaucoup de modèles encore commercialisés.

A voir dans les boutiques d'occasions, car justement plus commercialisé, le dongle usb wifi nintendo officiel fonctionne avec le module rt2x00 out of the box et sans firmware, en client et en AP, avec possibilités de forger des trames... bref accès complet.

Mais le mieux pour toi si tu veux rester en lenny, c'est sans doute de basculer vers un noyau 2.6.32 de backports.org qui lui te supportera comme suggéré la plupart des chipsets atheros, assez courant et avec firmware libre pour les plus récents (la plupart des n).

Le module e100 existe depuis très longtemps (à mon avis sur tous les 2.6.x, il existe au moins depuis 2.4). e100 et eepro100 existaient en parallèle, mais depuis déjà un moment plus c'était déjà e100 qui était recommandé. Tu ne pourrais pas voir si sur ton ancien kernel tu l'as et ou le compiler tout simplement ?

Pourquoi pas.
Pour les packages que tu souhaites mettre à jour, utiliser le dépot de dag/rpmforge ou EPEL. Mais choisir définitivement l'un ou l'autre, mélanger les dépots, c'est une mauvaise idée.
Soit en récupérant/installant les rpm à la main.
Soit en configurant yum sur ces dépots et en configurant yum d'une manière qui va bien.
Désolé, je n'ai plus d'exemple sous la main, mais de mémoire, il faut avoir un exclude=* (pour ne rien prendre par défaut) et derrière un include=liste des packages qu'on souhaite mettre à jour.

J'utilisais ça à une époque, et ça permet en effet de garder un environnement stable, nécessitant peu de maintenance et de faire évoluer juste quelques packages (n'ayant pas trop de dépendances, sinon, c'est une mauvaise idée).

Question subsidiaire : il y a-t-il une différence entre expressions rationnelles et expressions régulières ?

Oui, « expression régulière » est une traduction pas très heureuse de l'anglais « regular expression ». C'est plus correct en français d'utiliser « expression rationnelle ». Mais à part cela, c'est la même chose.

Oui, encore que sur cette somme, c'est à peu près juste si tu n'oublies pas la TVA. Tes 99 $ sont HT. Les 99 € sont TVA incluses (soit environ 20%) : 72,4 + 20% = 86,88 €. L(es) 'importateur(s) les achètent surement un peu en dessous de 99$ et se font surement plus que 13€ de marge (surement autour de 20 ou 25€), mais cela me semble tout à fait normal.