Liquid Prompt a longtemps eu ma préférence, déjà par son ancienneté et ensuite car du écrit en pure shell (bash ?).
Puis j'ai découvert byobu (https://www.byobu.org/), qui est un peu plus qu'un prompt, mais en reprend quand même selon moi des fonctionnalités.
C'est un frontend à tmux, et ça gère une barre d'état assez sympathique à votre terminal… et bien sûr des terminaux virtuels tmux.
ah ! ah !
Pas du tout d'accord : tu pars trop du postulat que tous les votants soient techniquement pertinents. Et je dirais même que les votants ayant un avis éclairé seraient même minoritaires.
La démocratie a aussi ses limites.
Je pense que dans tous les cas, la contextualisation de la faille est nécessaire, notamment par rapport aux fonctionnalités utilisées ou non d'un équipement.
Je vois dans mon entreprise, on s'alarme rapidement dès qu'il y a une CVE et avec un CVSS un peu élevé qui concerne un équipement réseau. Or celui-ci a généralement beaucoup de fonctionnalités, et la CVE ne concerne qu'une seule d'entre elles qu'on sait ne pas utiliser et donc avoir désactivé. Donc pas d'urgence à patcher et c'est des fois compliquer à faire comprendre !
Bref CVE/CVSS a l'avantage d'alerter, mais je pense qu'on ne coupe pas à devoir être un peu technique et à faire une analyse d'impact (ou non impact) de la faille dans son environnement.
A une époque où j'avais un ampli sans entrée hdmi, et où je souhaitais avec du son 5.1 pour des films lus avec xmbc (kodi) bien sûr ayant une piste ac3 ou dts, j'utilisais une carte son usb à pas cher (moins de 30€) avec sortie spdif et alsa en passthrough : c'était très satisfaisant pour les sources avec une piste ac3 ou dts…
Actuellement j'ai un AV avec HDMI qui supporte sans problème le PCM 5.1 (et même 7.1) et tous les formats existants (dolby atmos…) mais en video pas la 4K… ce qui fait que je préfère relier mon player directement à la TV. Celle-ci est reliée à l'ampli via un retour ARC sur de l'HDMI… ce qui me fait retomber dans le travers que ce mode de retour ne supporte en 5.1 que de l'ac3 ou du DTS.
La solution la plus simple pour moi est désormais que plutôt que d'essayer de faire de décodage / réencodage à la volée des sources 5.1 qui ne sont pas en ac3 ou dts, je rajoute ou substitue rapidement une piste ac3 5.1 avec ffmpeg à mon .mkv.
Cela donne par exemple la commande suivante : ffmpeg -nostdin -i mkv_source.mkv -strict -2 -c:v copy -c:a eac3 -b:a 640k -c:s copy -map 0 new_mkv_with_ac3.mkv
C'est un peu ironique, mais la méfiance qui visait Oracle aurait dû concerner aussi IBM.
Oracle, on est d'accord, a fait plein de coups plus ou moins pourris. Mais dans le cadre d'Oracle Linux, je trouve que depuis plus de 15 ans, ils font finalement un boulot plutôt pas mal… J'apprécie notamment leur kernels UEK, qui permet notamment :
- d'avoir un kernel plus récent que la distrib' RHEL initiale;
- un kernel signé compatible sans aucun effort avec secure boot;
- réintroduit des drivers supprimés par Red Hat en RHEL8 (je pense aux contrôleurs SAS Fusion MPT).
De loin proxmox ressemble à Esxi, mais pour une utilisation personnelle, je trouve proxmox très supérieure :
Déjà c'est une base debian, et on n'est pas obligé de partir de l'iso fournie par proxmox : on peut partir d'une debian et ajouter le dépot proxmox. Ou a l'inverse on peut partir de l'iso, et ajouter n'importe quel paquet de debian via apt (autant dire qu'on a du choix et que c'est bien supporté). Aussi, la machine n'est donc pas obligatoirement dédiée à faire de la virtualisation : on peut s'en servir en même temps comme workstation, NAS (merci le support natif de ZFS par le kernel fourni par proxmox), HTPC… sans bidouille infâme que certains font avec ESXi pour faire du passthrough du hardware à une VM.
Ensuite pour moi le gros intérêt de proxmox, c'est de ne pas se limiter à de la full virtualisation, mais surtout du conteneur (openVZ autrefois, LXC maintenant) : c'est beaucoup plus léger et ça tourne bien sur une petite machine (par exemple les fameux HP microserveur, donc aussi très bien en NAS et HTPC en rajoutant une carte video…)
gvim … + un gestionnaire de fenêtres bien configuré, etc…
Je ne suis non plus, pas prêt à changer.
Mais comme suggéré déjà dans un commentaire plus haut : c'est bien d'avoir l'embarras du choix, non ?
Alors à tester… quand ça sera packagé dans un dépôt de ma distrib' préférée ;-)
Il me semble que proxmox fait pareil : le module zfs.ko est distribué en binaire avec leur noyau pve-kernel. Le modinfo indique "author: OpenZFS on Linux" "License: CDDL"
[réaction primaire et troll inside]
Cette histoire de licence plus le mélange du fs avec des fonctions que je suis habitué à avoir par LVM et mdadm, ou le fait que zfs soit gourmand en ressources, le fait que certaines de ses fonctionnalités sont certes très intéressantes, mais que pour des usages spécifiques (qui a vraiment besoin de dédup' chez soi, vous hébergez des dizaines de VM ou des tonnes de choses redondantes ?…). Bref tout cela fait que je ne suis pas fan de ZFS.
[/réaction primaire et troll inside]
J'exprime juste mon avis par rapport à mes besoins et mes usages : je ne prétends pas avoir la vérité absolue et les défenseurs de ZFS ont surement de très bonnes raisons… pour eux ! ;-)
TP-Link WDR 3600 (cpu Atheros MIPS à 560 Mhz et 128 Mo RAM) ou TP-Link WR1043ND V2 (cpu Atheros à 720 Mhz et 64 Mo RAM).
Ok, pour les deux, il y a moins de RAM que ce que tu voudrais, mais pour le reste, ils sont au top pour openwrt : openwrt s'installe via l'interface web du firmware d'origine comme si tu faisais une upgrade de ce dernier. WIFI(s), USB, Gigabits sont bien supportés.
Et tu peux les trouver à environ 50€.
Après je ne sais pas si c'est beaucoup plus puissant que ta FON (Un Atheros autour de 400 Mhz et 64 Mo de RAM ?).
Personnellement, j'ai été TRES déçu par la GURU PLUG à base d'un Marvell Kirkwood 1,2 Ghz…
Alors que sur le papier ça semblait super (512 Mo RAM, 2 interfaces Gigabits), le produit était assez cher (> 120 €). Il s'est révélé tout simplement pas utilisable (instabilité à cause de surchauffe, même au repos), et en pratique peu performant. De plus bien sûr, pas de possibilité d'installer une distribution linux classique et sa version de debian modifiée n'a jamais eu de suivi…
Pour une micro-machine, je préfère de loin l'expérience du raspberry pi… et malgré les griefs souvent justifiés qui lui sont faits en terme cpu et IO, une sheevaplug ne fait pas mieux… Le rpi a l'avantage d'usage (on copie l'OS sur la SD via un simple dd), peu cher, bénéficie d'une grosse communauté et sa distribution linux raspbian est bien maintenue…
Précise de quelle(s) accélération(s) matérielle(s) tu parles.
J'ai un TP-link WDR4300 qui ne coûte qu'une 60taine d'€ pour du Gigabit Ethernet et 2 Wifi n simultanés (2,4 et 5 Ghz), 128 Mo de RAM…
Le chipset a effectivement une accélération matériel du NAT qui n'est volontairement pas supporté car implémenté dans le firmware d'origine via un mauvais hack de la pile réseau plus, je crois, un blob binaire. De plus il ne permet pas l'utilisation des vlan.
Le nat géré par le cpu via le kernel (comme sur un linux standard…) offre des performances moindre (ok, environ 2 fois), mais tout de même d'environ 300 Mbit/s : Test perfs WDR4300
Les 2 wifi sont gérés par un pilote entièrement libre, stable et performant.
Ah oui, en plus pour ce routeur, le firmware du constructeur a une grosse faille de sécurité, non corrigée depuis plus d'un an…
C'est à mon sens ce qui manque un peu à la dépêche : elle est centrée exclusivement sur ZFS, laissant un peu penser qu'il a tout inventé…
La plupart des fonctionnalités de ZFS sont déjà implantées via d'autres mécanismes sous linux (mdadm, lvm …).
L'article gagnerait (et ferait moins parti pris) à comparer les solutions.
J'ai lu rapidement la doc, mais sur ma centOS 6.5 en bash version 4.1.2, une fois que j'ai sourcé liquidprompt, mon prompt ressemble à ça (avec les guillemets "" pas beaux au début) :
""[rictus:~] $
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.
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.
# Un peu hors sujet, mais on peut aussi évoquer byobu
Posté par rictus (site web personnel) . En réponse à la dépêche Comparaison critique de systèmes d'invite de commande. Évalué à 1.
Liquid Prompt a longtemps eu ma préférence, déjà par son ancienneté et ensuite car du écrit en pure shell (bash ?).
Puis j'ai découvert byobu (https://www.byobu.org/), qui est un peu plus qu'un prompt, mais en reprend quand même selon moi des fonctionnalités.
C'est un frontend à tmux, et ça gère une barre d'état assez sympathique à votre terminal… et bien sûr des terminaux virtuels tmux.
[^] # Re: Typo dans les versions zfs
Posté par rictus (site web personnel) . En réponse à la dépêche Proxmox Virtual Environment 8.1 avec SDN et Secure Boot disponible . Évalué à 1.
Curieux donc de ne pas être passé à 2.2.1 d'autant que c'est une révision mineure ?
[^] # Re: Surtout ne pas réinventer la roue
Posté par rictus (site web personnel) . En réponse au journal En sécurité informatique, que valent les identificateurs CVE et les évaluations CVSS ?. Évalué à -1.
ah ! ah !
Pas du tout d'accord : tu pars trop du postulat que tous les votants soient techniquement pertinents. Et je dirais même que les votants ayant un avis éclairé seraient même minoritaires.
La démocratie a aussi ses limites.
[^] # Re: Utilisation pragmatique
Posté par rictus (site web personnel) . En réponse au journal En sécurité informatique, que valent les identificateurs CVE et les évaluations CVSS ?. Évalué à 2.
Je pense que dans tous les cas, la contextualisation de la faille est nécessaire, notamment par rapport aux fonctionnalités utilisées ou non d'un équipement.
Je vois dans mon entreprise, on s'alarme rapidement dès qu'il y a une CVE et avec un CVSS un peu élevé qui concerne un équipement réseau. Or celui-ci a généralement beaucoup de fonctionnalités, et la CVE ne concerne qu'une seule d'entre elles qu'on sait ne pas utiliser et donc avoir désactivé. Donc pas d'urgence à patcher et c'est des fois compliquer à faire comprendre !
Bref CVE/CVSS a l'avantage d'alerter, mais je pense qu'on ne coupe pas à devoir être un peu technique et à faire une analyse d'impact (ou non impact) de la faille dans son environnement.
# Passthrough => carte son usb avec sortie spdif
Posté par rictus (site web personnel) . En réponse au journal Obtenir un son numérique multicanal depuis son ordinateur. Évalué à 1.
A une époque où j'avais un ampli sans entrée hdmi, et où je souhaitais avec du son 5.1 pour des films lus avec xmbc (kodi) bien sûr ayant une piste ac3 ou dts, j'utilisais une carte son usb à pas cher (moins de 30€) avec sortie spdif et alsa en passthrough : c'était très satisfaisant pour les sources avec une piste ac3 ou dts…
Actuellement j'ai un AV avec HDMI qui supporte sans problème le PCM 5.1 (et même 7.1) et tous les formats existants (dolby atmos…) mais en video pas la 4K… ce qui fait que je préfère relier mon player directement à la TV. Celle-ci est reliée à l'ampli via un retour ARC sur de l'HDMI… ce qui me fait retomber dans le travers que ce mode de retour ne supporte en 5.1 que de l'ac3 ou du DTS.
La solution la plus simple pour moi est désormais que plutôt que d'essayer de faire de décodage / réencodage à la volée des sources 5.1 qui ne sont pas en ac3 ou dts, je rajoute ou substitue rapidement une piste ac3 5.1 avec ffmpeg à mon .mkv.
Cela donne par exemple la commande suivante :
ffmpeg -nostdin -i mkv_source.mkv -strict -2 -c:v copy -c:a eac3 -b:a 640k -c:s copy -map 0 new_mkv_with_ac3.mkv
# Oracle vs IBM
Posté par rictus (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 1.
C'est un peu ironique, mais la méfiance qui visait Oracle aurait dû concerner aussi IBM.
Oracle, on est d'accord, a fait plein de coups plus ou moins pourris. Mais dans le cadre d'Oracle Linux, je trouve que depuis plus de 15 ans, ils font finalement un boulot plutôt pas mal… J'apprécie notamment leur kernels UEK, qui permet notamment :
- d'avoir un kernel plus récent que la distrib' RHEL initiale;
- un kernel signé compatible sans aucun effort avec secure boot;
- réintroduit des drivers supprimés par Red Hat en RHEL8 (je pense aux contrôleurs SAS Fusion MPT).
[^] # Re: Ça serait bien sur le réseau câblé SFR / Numéricable
Posté par rictus (site web personnel) . En réponse à la dépêche Les Néerlandais peuvent choisir leurs modems et routeurs. Évalué à 2. Dernière modification le 16 septembre 2021 à 19:18.
Même en DOCSIS 3.0, on peut atteindre techniquement 200 Mb/s, mais commercialement on se retrouve bridé à 60 Mb/s…
[^] # Re: Ça serait bien sur le réseau câblé SFR / Numéricable
Posté par rictus (site web personnel) . En réponse à la dépêche Les Néerlandais peuvent choisir leurs modems et routeurs. Évalué à 2.
Je crois que les ONT sont en voie de disparition au profit d'un port SFP directement intégré dans les dernières box…
[^] # Re: Bon anniversaire!
Posté par rictus (site web personnel) . En réponse à la dépêche PROXMOX VE a 10 ans. Évalué à 6.
De loin proxmox ressemble à Esxi, mais pour une utilisation personnelle, je trouve proxmox très supérieure :
Déjà c'est une base debian, et on n'est pas obligé de partir de l'iso fournie par proxmox : on peut partir d'une debian et ajouter le dépot proxmox. Ou a l'inverse on peut partir de l'iso, et ajouter n'importe quel paquet de debian via apt (autant dire qu'on a du choix et que c'est bien supporté). Aussi, la machine n'est donc pas obligatoirement dédiée à faire de la virtualisation : on peut s'en servir en même temps comme workstation, NAS (merci le support natif de ZFS par le kernel fourni par proxmox), HTPC… sans bidouille infâme que certains font avec ESXi pour faire du passthrough du hardware à une VM.
Ensuite pour moi le gros intérêt de proxmox, c'est de ne pas se limiter à de la full virtualisation, mais surtout du conteneur (openVZ autrefois, LXC maintenant) : c'est beaucoup plus léger et ça tourne bien sur une petite machine (par exemple les fameux HP microserveur, donc aussi très bien en NAS et HTPC en rajoutant une carte video…)
[^] # Re: Donc en résumé
Posté par rictus (site web personnel) . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 3.
gvim … + un gestionnaire de fenêtres bien configuré, etc…
Je ne suis non plus, pas prêt à changer.
Mais comme suggéré déjà dans un commentaire plus haut : c'est bien d'avoir l'embarras du choix, non ?
Alors à tester… quand ça sera packagé dans un dépôt de ma distrib' préférée ;-)
# proxmox
Posté par rictus (site web personnel) . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 4.
Il me semble que proxmox fait pareil : le module zfs.ko est distribué en binaire avec leur noyau pve-kernel. Le modinfo indique "author: OpenZFS on Linux" "License: CDDL"
[réaction primaire et troll inside]
Cette histoire de licence plus le mélange du fs avec des fonctions que je suis habitué à avoir par LVM et mdadm, ou le fait que zfs soit gourmand en ressources, le fait que certaines de ses fonctionnalités sont certes très intéressantes, mais que pour des usages spécifiques (qui a vraiment besoin de dédup' chez soi, vous hébergez des dizaines de VM ou des tonnes de choses redondantes ?…). Bref tout cela fait que je ne suis pas fan de ZFS.
[/réaction primaire et troll inside]
J'exprime juste mon avis par rapport à mes besoins et mes usages : je ne prétends pas avoir la vérité absolue et les défenseurs de ZFS ont surement de très bonnes raisons… pour eux ! ;-)
[^] # Re: Red Hat
Posté par rictus (site web personnel) . En réponse au sondage En quelle année êtes-vous passé(e) à GNU/Linux (ou autre système libre) ?. Évalué à 1.
J'ai commencé également en 1994, mais cette réponse n'est pas possible dans le sondage : c'est soit AVANT 1994, soit à partir de 1995…
[^] # Re: Du matériel plus puissant qu'une FON et qui fasse tourner OpenWRT ?
Posté par rictus (site web personnel) . En réponse à la dépêche OpenWrt Barrier Breaker 14.07 guide vos routes. Évalué à 1.
TP-Link WDR 3600 (cpu Atheros MIPS à 560 Mhz et 128 Mo RAM) ou TP-Link WR1043ND V2 (cpu Atheros à 720 Mhz et 64 Mo RAM).
Ok, pour les deux, il y a moins de RAM que ce que tu voudrais, mais pour le reste, ils sont au top pour openwrt : openwrt s'installe via l'interface web du firmware d'origine comme si tu faisais une upgrade de ce dernier. WIFI(s), USB, Gigabits sont bien supportés.
Et tu peux les trouver à environ 50€.
Après je ne sais pas si c'est beaucoup plus puissant que ta FON (Un Atheros autour de 400 Mhz et 64 Mo de RAM ?).
[^] # Re: Du matériel plus puissant qu'une FON et qui fasse tourner OpenWRT ?
Posté par rictus (site web personnel) . En réponse à la dépêche OpenWrt Barrier Breaker 14.07 guide vos routes. Évalué à 3.
Personnellement, j'ai été TRES déçu par la GURU PLUG à base d'un Marvell Kirkwood 1,2 Ghz…
Alors que sur le papier ça semblait super (512 Mo RAM, 2 interfaces Gigabits), le produit était assez cher (> 120 €). Il s'est révélé tout simplement pas utilisable (instabilité à cause de surchauffe, même au repos), et en pratique peu performant. De plus bien sûr, pas de possibilité d'installer une distribution linux classique et sa version de debian modifiée n'a jamais eu de suivi…
Pour une micro-machine, je préfère de loin l'expérience du raspberry pi… et malgré les griefs souvent justifiés qui lui sont faits en terme cpu et IO, une sheevaplug ne fait pas mieux… Le rpi a l'avantage d'usage (on copie l'OS sur la SD via un simple dd), peu cher, bénéficie d'une grosse communauté et sa distribution linux raspbian est bien maintenue…
[^] # Re: Y'a-t-il du matériel vendu directement avec OpenWRT ?
Posté par rictus (site web personnel) . En réponse à la dépêche OpenWrt Barrier Breaker 14.07 guide vos routes. Évalué à 5.
Précise de quelle(s) accélération(s) matérielle(s) tu parles.
J'ai un TP-link WDR4300 qui ne coûte qu'une 60taine d'€ pour du Gigabit Ethernet et 2 Wifi n simultanés (2,4 et 5 Ghz), 128 Mo de RAM…
Le chipset a effectivement une accélération matériel du NAT qui n'est volontairement pas supporté car implémenté dans le firmware d'origine via un mauvais hack de la pile réseau plus, je crois, un blob binaire. De plus il ne permet pas l'utilisation des vlan.
Le nat géré par le cpu via le kernel (comme sur un linux standard…) offre des performances moindre (ok, environ 2 fois), mais tout de même d'environ 300 Mbit/s :
Test perfs WDR4300
Les 2 wifi sont gérés par un pilote entièrement libre, stable et performant.
Ah oui, en plus pour ce routeur, le firmware du constructeur a une grosse faille de sécurité, non corrigée depuis plus d'un an…
[^] # Re: Utilisation en production ?
Posté par rictus (site web personnel) . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à -1.
C'est à mon sens ce qui manque un peu à la dépêche : elle est centrée exclusivement sur ZFS, laissant un peu penser qu'il a tout inventé…
La plupart des fonctionnalités de ZFS sont déjà implantées via d'autres mécanismes sous linux (mdadm, lvm …).
L'article gagnerait (et ferait moins parti pris) à comparer les solutions.
[^] # Re: ça m'énerve...
Posté par rictus (site web personnel) . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 1.
C'est un bon workaround effectivement.
Merci !
# ça m'énerve...
Posté par rictus (site web personnel) . En réponse à la dépêche Liquidprompt version 1.7. Évalué à 1.
J'ai lu rapidement la doc, mais sur ma centOS 6.5 en bash version 4.1.2, une fois que j'ai sourcé liquidprompt, mon prompt ressemble à ça (avec les guillemets "" pas beaux au début) :
""[rictus:~] $
c'est quoi que j'ai manqué ? :(
[^] # Re: Troll
Posté par rictus (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 4.
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…
[^] # Re: Troll
Posté par rictus (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 6.5. Évalué à 2.
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.
# Intégration des backdoors de la NSA de SELinux ;
Posté par rictus (site web personnel) . En réponse à la dépêche Debian 7.2 et futur gel de Debian 8.0. Évalué à -5.
Euh, je ne comprends pas, on n'est pas le 1er avril ?
[^] # Re: quoi faire
Posté par rictus (site web personnel) . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 2.
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…
[^] # Re: EPEL
Posté par rictus (site web personnel) . En réponse à la dépêche Red Hat Software Collections 1.0 Beta. Évalué à 3.
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).
[^] # Re: Étrange
Posté par rictus (site web personnel) . En réponse à la dépêche Xen devient un projet de la fondation Linux. Évalué à 2.
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…
[^] # Re: C'est une très bonne chose ....
Posté par rictus (site web personnel) . En réponse à la dépêche Xen devient un projet de la fondation Linux. Évalué à 2.
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.