> AES128-CBC, ce qui est très sécurisé (et non, ça n'a rien à voir avec une protection de session par mot de passe de n'importe quel OS, c'est beaucoup plus sécurisé)
Oui, et non...
La clé qui dé/chiffre la partition aura beau être de l'AES, avec LUKS, elle est située sur le support lui-même, puis, chiffrée avec un mot de passe (le truc de 15 caractères de Mammnon)...
Aussi, rien n'empêche de brute-forcer le mot de passe (même si 15 caractères complexes, ce n'est déjà pas ce qu'il y a de plus simple)...
Cela dit, c'est ce qui permet de changer la clé que l'on est censé saisir, sans changer la clé de chiffrement de la partition elle-même (ce qui supposerait un reformatage)...
Si tu veux avoir quelque chose de plus robuste, niveau sécurité, un gros mot de passe (genre un truc de la même taille que la clé de chiffrement de la partition, généré à partir de /dev/random, comme le suggère raboliot en dessous), sur un support externe, et pourquoi pas elle-même chiffrée par un mot de passe humainement tapable au clavier, c'est beaucoup mieux...
Parce qu'avec LUKS, quoi que tu fasses, la clé est sur la serrure, et elle est souvent protégée par un mot de passe beaucoup plus faible qu'elle...
> En passant il y a t-il d'autres trucs que tu apprécies dans openvz et qui ne sont pas dans vserver ?
Au niveau de la configuration réseau, OpenVZ est très puissant : soit on laisse l'hôte gérer le réseau des VM en leur donnant un périph virtuel venet (~analogue à VServer)...
... soit on donne à la VM une interface réseau plus avancée (veth), permettant de lui déléguer la conf réseau (conf classique, iptables, routes, ...).
J'avoue ne pas avoir cherché plus loin que ça si c'était possible dans VServer, cela dit.
Il y a aussi que le partage de périphs entre l'hôte et la VM se fait dans le fichier de conf, plutôt qu'en faisant un "cp -a" de ce qu'il y a dans le "/dev" : je trouve ça plus propre (même s'il peut y avoir des problèmes avec udev, comme avec mon imprimante laser et mon scanner qui ont besoin de charger un firmware - m'enfin, ça se règle avec de petits scripts udev sur l'hôte, et c'est la même chose, que ce soit avec VServer ou OpenVZ).
Par contre, niveau doc, OpenVZ poutre vraiment bien : le manuel officiel est un gros PDF bien touffu, et plutôt exhaustif.
À côté, la "flower page" et le wiki de VServer sont plutôt légers, m'est avis... et ça pèse pas mal dans la balance, en ce qui me concerne.
Si ça t'intéresse, voilà le lien vers le journal que j'avais fait : http://linuxfr.org/~Aefron/27379.html ... même si c'est long, ça n'a pas pour but d'être exhaustif, mais juste d'être un retour d'expérience (et une anti-sèche occasionnelle :p), de la part d'un non-professionnel.
Cela dit, je le répète, j'utilise VServer depuis ~1,5 ans, et même si j'ai une petite préférence pour OpenVZ, les deux sont vraiment très bien ;)
D'ailleurs, vu la jeunesse d'OpenVZ sous Debian (ma distro préférée), si je devais en choisir un pour quelque chose de vraiment sérieux, ce serait probablement VServer.
Quoi qu'il en soit, pour moi qui n'ai d'instructions de virtualisation que sur mes desktops (mes serveurs sont mes vieux desktops d'il y a pas mal d'années ; et j'espère qu'ils continueront à me servir encore plein de temps), les conteneurs sont une solution bien plus praticable que la virtualisation complète, forme de solution que je pense continuer à utiliser, même quand il faudra changer les serveurs : et pour ça, je suis reconnaissant aussi bien envers une solution que l'autre.
> Sinon, pourquoi diantre, passer de vserver à openvz
Comme je l'ai dit, je préfère la manière de gérer le réseau à-la-OpenVZ... Je suis aussi sous VServer depuis Etch, et je n'ai pas trop aimé le fait qu'il n'y ait techniquement pas de loopback dans celui(ci (même si on m'a dit qu'il y était dans la version plus récente de Lenny).
Il y aussi la gestion plus rigoureuse des ressources (pas moyen d'espérer faire tourner OpenVZ en spécifiant globalement plus de ressources qu'il n'y en a dans la machine - il faut faire ça avec un strict minimum d'application) : du coup, ça force à être rigoureux, ce que j'aime bien.
Mais malgré tout, je ne dis pas que VServer est mauvais, bien au contraire : les deux sont très bien, et VServer est sans aucun doute plus éprouvé et utilisé qu'OpenVZ ;)
Certes ; mais la constante de gros bugs insupportables dans Fedora est toujours positive (et pas qu'un peu)... il ne peut pas y avoir moins de bugs inchiables qu'aucun...
> il est prévu un changement de noyau pour Lenny (vers 2.6.30)
Lenny et demi : rien d'obligatoire... d'ailleurs, pour avoir ce nouveau noyau (dont le but est de supporter plus de matos et de fonctions : ni plus, ni moins - bien évidemment, le 2.6.26 restera supporté, et mis à jour quand il faudra le faire) il faudra installer _manuellement_ le _nouveau_ (nouveau dans le sens "en plus", pas "à la place de") paquet, quand il sera dispo...
Sur ce qui fait trébucher tout le monde, soit ce n'est pas encore packagé dans Sid (KDE4, packagekit, NM 0.7, ...), soit ce n'est pas utilisé par défaut (PulseAudio : il est même dans Etch, tu sais - mais personnellement, je ne l'ai jamais installé, sous Debian, et j'ai du son, sans le moindre problème).
Ainsi, Sid n'a aucun des bugs qui rendent souvent l'utilisation de Fedora ultra-désagréable. Zéro fois les bugs les plus chiants : je ne pense pas exagérer en disant que, du point de vue de l'utilisateur, c'est infiniment moins bugué (constante/0=+-infini).
Pour le "bien moins de problèmes", je reste dessus : la dernière fois que j'ai installé une Fedora ailleurs que dans une machine virtuelle, en moins de 24h :
- packagekit qui tombe en carafe, sans le moindre espoir de pouvoir fonctionner de nouveau ;
- du son, puis plus de son, puis du son, puis plus de son (pulseaudio ? j'avoue ne plus me rappeler s'il était déjà là, mais j'imagine que ça doit être ça) ;
- quelques hardlocks de la machine ;
- l'OS s'éteint, mais la machine ne s'arrête plus ;
- KDE 4.0 (no comment) ;
Je n'ai jamais, jamais, jamais, mais alors vraiment jamais, eu autant d'emmerdes en 2 ans de Sid qu'en 24h (même si je l'ai gardée un peu plus longtemps : j'en ai eu plus que marre au bout d'une semaine, quand même) de Fedora...
Quelque chose qu'on peut regarder, mais qui est tellement fragile qu'il ne vaut mieux pas y toucher, de peur que tout s'écroule (même si ça s'écroule quand même)... euh... bon, d'accord : ce n'est pas une vitrine - c'est ce qu'on met généralement dedans... m'enfin...
Pour tester assez souvent Fedora dans une VM, et pour utiliser de temps en temps des paquets de Debian Experimental, je l'affirme : Fedora et Experimental se valent, quand au bleeding-edge et aux plantages/incongruités à répétition. Par contre, pour comparer ça à Sid, de deux choses l'une : soit tu ne l'as jamais utilisée, soit tu FUDes.
Évidemment, je connais ton passif, et ta manière de défendre ta chapelle, qu'on l'attaque ou pas : ce pourquoi je me permets très clairement d'affirmer que, au strict minimum, tu FUDes, que tu aies jamais testé Sid, ou pas.
> Tu auras au moins autant de problème que sous Fedora
Sid est loin d'être aussi bleeding-edge que la dernière Fedora (surtout en ce moment ; mais bon : freeze oblige ; ça va très bientôt dégeler)...
... elle est aussi infiniment moins buguée.
Au pire, en utilisant Sid, tu auras toujours bien moins de problèmes que sous Fedora (et je le précise : je n'ai rien contre Fedora - elle est très utile pour le développement du libre ; mais c'est plus une vitrine qu'autre chose).
Si tu veux chercher quelque chose d'aussi bleeding-edge, dans la famille Debian, c'est du côté des paquets d'Experimental, qu'il faut regarder et comparer - là, je ne dis pas : le standard de qualité est peu ou prou le même que celui de Fedora (à la limite de l'utilisable, et pas souvent du bon côté).
C'est "mignon" de FUDer, mais quand on compare, tes allégations ne tiennent pas un demi-instant.
> si vous avez besoin d'un ordinateur pour faire de la bureautique oubliez openoffice 3
Je n'ai pas essayé la version 3, mais j'ai un peu touché les précédentes, et, franchement, je n'aime pas du tout : c'est moins bugué que KOffice (mais bugué, et pas très productif, quand même)... par contre, c'est lent et moche (au moins, là-dessus, il y a quelque chose à tirer de KOffice)...
Bref, m'est avis que la bureautique-clickouille libre, ça viendra (je n'en doute pas), mais ce n'est tout simplement pas encore ça, quoi qu'on utilise : ni plus, ni moins.
Quant à firefox, je ne vois pas bien le rapport avec la bureautique... par contre, en effet, je ne trouve pas que c'est une bonne appli du tout, et je ne vois pas l'intérêt de l'utiliser sous Linux. Ça n'engage que moi, cela dit.
Et pour ce qui est de l'OS "universel", pour ma part, hors routeurs (OpenWRT), je n'utilise que Debian, et ce, pour faire plein de trucs... dans mon cas (et dans celui de plein de gens qui ont une utilisation plus "commune" de leurs machines, et à qui j'en ai installé), ça marche donc plutôt bien...
... après, si le but est de retrouver exactement les mêmes softs libres que beaucoup utilisent sous OS redmondien (VLC, firefox, OOo, ...), et bien, je ne suis pas convaincu du bienfondé de la démarche : si ces applis sont peut-être très bien sous ces OS, sur la banquise, je n'ai pour ma part jamais eu que des problèmes avec (et pas que sous Debian, que j'utilise depuis moins de temps que je n'ai utilisé Slack et Gentoo)... et il y a m'est avis (à part pour OOo, comme je l'ai dit au-dessus) de biens meilleurs remplacements libres (SMPlayer ou Konqueror, par exemple).
Maintenant, si des applis souffrent de tares, plus ou moins solvables, et bien, tant pis : le but de Debian n'est pas de faire comme si elles n'en avaient pas, en collant un coup de vernis à-la-rache, ou en packageant des trucs tout sauf près à être utilisés (pour dire "ça merde, mais c'est le dernier top à la mode, 'mmm, voyez"), comme d'autres distros peuvent le faire.
En outre, si tu n'es pas satisfait par ce qu'offre Stable (que je n'utilise en tant que clickodrome que sur le PC que j'ai installé à ma mère, qui est tout sauf douée en info... et que je n'utilise que très peu comme LAMP, puisqu'il y a beaucoup d'autres serveurs dont j'ai besoin, et que Debian me permet de les avoir), il y a les backports, Testing, Unstable, Experimental, Debian-Multimedia, l'huile de coude, d'autres distros, ...
Si Stable est, je veux bien le reconnaître, limitante en desktop, c'est peut-être parce tout est loin d'être prêt pour "l'année de Linux sur le desktop de Mme Michu " (?)... J'imagine qu'un jour, je concevrai parfaitement d'installer Stable ou une autre distro du genre sur la plupart de mes clickodromes, mais en attendant, je ne fais pas comme si tout était au top dans les bureaux libres, quels qu'ils soient.
En même temps, si je me souviens bien, le freeze a commencé en juillet/août dernier, et aucun nouveau paquet ne rentre plus depuis novembre... et OOo 3 est sorti mi octobre...
... et puis, niveau maintenabilité, je n'ai pas souvenir qu'OOo soit un exemple - même si ça date des 1.x/2.x, il y a quelques années, sous Gentoo, outre le temps à y passer, rien ne garantissait que l'ebuild fut ne serait-ce que compilable (s'il y avait une version source et une version binaire, ce n'était pas seulement parce que ça mettait des plombes à compiler - c'était aussi à cause de toutes les emmerdes qu'il y avait si on essayait de le faire soi-même).
Bref, trop tard, trop gros, tant pis.
Même si, dans mon activité, je n'ai pas spécialement besoin d'OOo, dans ce genre d'appli, j'attends bien plus de KOffice ; et ce sera prêt quand ce sera prêt.
Et puis, il y a pire : genre iceweasel et icedove - les notes sur la sortie de Lenny précisent qu'il y a un risque de voir le support de sécu pour ces applis abandonné, au bout d'un certain temps, vu que les développeurs originels n'en ont rien à foutre.
Plutôt que de pleurer là-dessus, ça fait un moment que j'ai remis en question la seule utilisation de ces machins, et que j'ai fini par ne plus les installer du tout ('puis bon : linux et la mofoco... un récent article sur Tuxradar [1] montre que la banquise est loin d'être une de leurs priorités ; d'ailleurs ces applis n'ont pas toujours été simplement compilables sans problème non plus - j'avais aussi des tonnes de problèmes à l'époque 1.x, sous Gentoo, si j'essayais de les compiler)...
Bref, ce n'est pas parce que c'est connu que ce sont des exemples à suivre...
> Est-ce que l'approche « un serveur par service » n'est pas un peu lourde à administrer ?
Oui, et non : d'un côté, si je mets, par exemple, MythTV et SqueezeCenter sur la même "machine", ils vont se partager MySQL, et il y aura plus de risques que tout tombe si l'un des deux borke la base de données... Trop de bordel, ce n'est pas forcément souhaitable...
... après, certes, au final, ça multiplie pas mal le nombre de machines, et donc, ça multiplie la charge d'administration.
D'ailleurs, en ce moment, je suis en train de rationaliser tout ça, en me servant de CFEngine : idéalement, j'aimerais stocker les classes et des variables dans un LDAP, pour tout éditer à partir d'une même interface. Pour les mises à jours, je suis aussi en train de trifouiller des scripts qui font une simulation d'un "aptitude full-upgrade", qui m'envoient le résultat par mail (chiffré), auquel je réponds par un autre, signé - si la signature est bonne, le full-upgrade se fait sans mon intervention (ça marche pas mal, mais c'est encore un peu rugueux).
Après, ça dépend de ce qu'on veut faire : pour MythTV et SqueezeCenter, comme je le disais, ils ont chacun leur MySQL... Pour OpenLDAP, je compte juste en avoir un que j'édite, plus un autre en esclave (je ne suis pas chaud du tout pour mettre un annuaire, même partiel, dans chaque conteneur qui en aura besoin - même si, a mon grand dam, je n'arrive pas à trouver de serveur DNS qui va chercher ses infos dans LDAP, et qui me satisfasse : PowerDNS n'accepte l'authentification à l'annuaire que par mot de passe, et DLZ-Bind, même s'il accepte Kerberos, que je n'aime pas tellement, ne gère pas l'authentification sur un certificat - j'en suis donc à me dire que le plus propre serait peut-être d'avoir une réplique partielle de mon annuaire, juste pour les noms d'hôtes, dans un conteneur, avec DLZ-Bind)...
Cela dit, les possibilités offertes sont telles que c'est justement l'occasion d'organiser son réseau comme on le souhaite. Tout dépend des compromis que l'on cherche...
Avec l'extension du nombre d'années de cotisation nécessaires, j'imagine que je serai mort bien avant de pouvoir prétendre à une retraite ne serait-ce que vaguement suffisante...
En effet, le principe des conteneurs (jail BSD, OpenVZ, VServer) est d'avoir des sortes de super-chroots, qui utilisent tous le même kernel (en fait, ils n'ont pas accès à toutes les fonctions de celui-ci : par exemple, pour accéder à des périphs ou à l'interface réseau de l'hôte, il faut leur donner accès à des capacités spéciales du kernel), tout en étant isolés les uns des autres.
Après, est-ce que c'est moins consommateur d'énergie ? Je ne sais pas : peut-être un peu moins, vu que les instructions de virtualisation ne sont pas sollicitées. Mais à mon avis, l'avantage est surtout en ce que, n'ayant pas besoin de ces instructions, peu ou prou n'importe quel proc (x86 ou AMD64 - ça reste des patchs maintenus en dehors de Vanilla, même si, aussi bien pour VServer qu'OpenVZ, il y a pas mal de contribution au kernel de base, pour en venir un jour à supporter les conteneurs nativement) peut faire l'affaire, pourvu qu'il y ait assez de RAM sur la bête (en modifiant un poil le debootstrap de base, ie en n'utilisant syslog-ng au lieu de rsyslog, j'arrive à faire tourner des VM qui n'allouent pas plus de 5Mio de RAM... évidemment, ça gonfle selon les services utilisés).
Après, il y a sans doute un peu d'overhead, dû à la séparation, mais, c'est peu ou prou invisible, même sur mes vieilles machines.
Sinon, pour l'installation des softs, je me méfie comme la peste du contrôle de la VM directement à partir du shell de l'hôte (il peut y avoir des problèmes d'inaccessibilité des VT et cie... et c'est très chiant)... Par contre, une fois dans le conteneur (par SSH, par exemple, ou, sous OpenVZ, en faisant "vzctl enter ID_DE_LA_MACHINE, ce qui lance un sous-shell de l'invité sur l'hôte), pas de problème : au /dev (atrophié et statique : ce que je trouve très bien), et aux capacités du noyau près (ce qui inclue le réseau, sauf si, sous OpenVZ, on donne accès à la conf réseau en utilisant une interface virtuelle plus avancée), ça fonctionne exactement comme une machine courante. L'un de mes conteneurs est d'ailleurs un approx qui sert de cache/miroir deb local à toutes mes machines (oui, je suis très Debian) - on installe ce qu'on veut, il y a un init tout ce qu'il y a de plus classique, ... c'est transparent.
> un autre aspect [...] est celui de la visualisation des données
Ouais : jusqu'à ce qu'on ait des implants qui nous permettent d'accéder au données numériques en se branchant le support électronique directement dans les synapses :p
Comme je l'avais écrit dans un nourjal, je suis sous OpenVZ et VServer.
* Nombres d'utilisateurs ?
Très peu : c'est pour chez moi... outre l'accès à quelques fichiers via le conteneur SFTP, il n'y a pour ainsi dire que moi...
* Combien de DomU ?
"Conteneurs"... :p ... sinon, entre 20 et 30 (pour l'instant... mes plans de scientifique fou en prévoient entre 50 et 60).
* Quelles fonctions des DomU ?
Un service, un conteneur (sauf pour des trucs comme le MySQL de MythTV ou celui de SqueezeCenter, qui sont posés dans le même conteneur que l'appli qui les utilise)... en vrac, SMTP-auth, IMAPS, SFTP, MlDonkey, Tor, CUPS, SANE, NFS, NUT, MythTV, SqueezeCenter, DNS, CFEngine, LDAP (en cours), et j'en passe une bonne racée... plein, plein, plein de choses.
* Combien de serveurs ont été remplacés par la virtualisation ?
* Combien de serveurs utilisés pour la virtualisation ?
Aucun... ou tous... au choix. Avant, je chrootais à la mimine tout ce qui était destiné à être accessible en public, sur une machine, et je laissais le reste sous une même arborescence, sur une autre machine... c'était chiant, et sale.
Maintenant, mes deux serveurs sont devenus des routeurs/étagères à conteneurs... et c'est merveilleux.
* Méthode d'intégration à l'existant ?
Test dans un Qemu/Virtualbox, puis, basculage sauvage avec réinstallation (je ne suis sous Linux "que" depuis ~5 ans... aussi, avant mon utilisation des conteneurs, mes serveurs souffraient d'erreurs de ma jeunesse sur la banquise - j'en profite pour repartir sur des bases saines).
* Choix de la solution logiciel ?
OpenVZ/Vserver, comme je l'ai dit. J'ai tendance à préférer OpenVZ (plus drastique sur la gestion du matos, je préfère la syntaxe de "vzctl" que celle de "vserver", routage plutôt que des "liens" IP).
Toujours pas eu le courage de basculer le VServer vers OpenVZ... peut-être après la sortie de Lenny :D
* Choix de la solution matériel ?
C'est ça, qui est bien : de vieilles babasses, à base d'Athlon XP (2Gio et 3Gio de RAM... et j'ai moult marge). Pas d'instruction de virtualisation, pas de RAM bouffée par plein de noyals, accès très simple au périphs (deux imprimantes, un scanner, quatre cartes DVB-T) : nickel.
* Est-ce stable en production ?
Très (pour OpenVZ, il y a eu des problèmes il y a quelques mois ; pas directement à cause du patch OpenVZ, mais plutôt à cause de Linux Vanilla - ce que le patch OpenVZ mettait en évidence en hardlockant la machine - mais bon, c'est réglé depuis un moment, et puis, Lenny ne sort officiellement que demain, a priori).
* Délai d'étude et de mise en production ?
Vu que c'est pour chez moi (pas spécialement de lien à l'informatique dans mon boulot : en ce moment, je gratte même tellement d'équations sur le papier que je ne prends même pas le temps d'allumer l'ordi au boulot), à mon rythme.
Si tu avais un SSH d'ouvert vers elle, ou quelque chose du genre, tu risques de perdre la connexion, mais le temps que les réglages soient appliqués, tu peux de nouveau y accéder (et par les deux adresses).
Tu ne peux pas changer la conf réseau d'une VM qui utilise les venet, dans cette VM : ces interfaces virtuelles doivent être gérées par l'hôte, et configurées en passant par lui (si tu veux que l'invité puisse gérer sa conf réseau, avec firewall, routes et cie, il faut prendre du veth - mais ça a surtout un intérêt si tu veux mettre un VPN ou assimilé dans la VM ; sinon, le venet suffit a priori)...
Si tu veux simplement assigner deux IP à une VM, tu as juste à faire (avec les droits root, bien sûr - et dans l'hôte, évidemment) : "vzctl set ${ID} --ipadd 91.xx.xx.11 --ipadd 91.xx.xx.22 --save" ... Ce sera l'hôte OpenVZ qui s'occupera des routes (rien à spécifier manuellement ; à part éventuellement sur les routeurs en amont, si tu fais des choses un poil exotiques, avec plusieurs réseaux disjoints... m'enfin).
Ton conteneur se retrouvera alors avec les deux adresses spécifiées...
... bon, si il a déjà "91.xx.xx.11", vzctl va te dire qu'il a déjà cette adresse et qu'il ne la rajoute pas (il rajoutera quand même celle qui manque).
Sinon, si tu veux repartir de zéro, tu fais "vzctl set ${ID} --ipdel all --save", puis, tu rajoutes les deux, comme j'ai écrit au-dessus.
Il y a aussi les dossiers de calques... C'est ce que je préfère dans Krita : plutôt que de te retrouver avec un bordel de calques, qui nécessite une dizaine de clics pour en masquer autant, tu mets tes calques dans un dossier, et tu masques juste le dossier...
Sur ce point, Gimp est vraiment lourdingue...
Un bon point est aussi qu'il est en QT, et donc, qu'il ne met pas trois plombes à rafraîchir la GUI quand la machine est bien sollicitée...
Pour ce que je reproche à Krita (pas encore testé la 2.0) : moins de plugins (en même temps, ce n'est pas comme si ceux de Gimp étaient toujours maintenus, comme mon préféré, "Flammes", qui segfaulte depuis des années dès qu'on essaye de l'appliquer sur une trop grosse résolution ; et c'est loin d'être le seul), et pas toujours compatible avec les .xcf travaillés sous Gimp ('peut pas ouvrir mes plus gros projets Gimp avec Krita 1.x :( )...
[^] # Re: concurrence
Posté par Aefron . En réponse au journal Franck Riester : "L’interopérabilité n’est pas nécessaire pour les consommateurs". Évalué à 3.
[^] # Re: LVM ? Ou plutôt dm-crypt ?
Posté par Aefron . En réponse au message LVM chiffré, quelle sécurité?. Évalué à 2.
Oui, et non...
La clé qui dé/chiffre la partition aura beau être de l'AES, avec LUKS, elle est située sur le support lui-même, puis, chiffrée avec un mot de passe (le truc de 15 caractères de Mammnon)...
Aussi, rien n'empêche de brute-forcer le mot de passe (même si 15 caractères complexes, ce n'est déjà pas ce qu'il y a de plus simple)...
Cela dit, c'est ce qui permet de changer la clé que l'on est censé saisir, sans changer la clé de chiffrement de la partition elle-même (ce qui supposerait un reformatage)...
Si tu veux avoir quelque chose de plus robuste, niveau sécurité, un gros mot de passe (genre un truc de la même taille que la clé de chiffrement de la partition, généré à partir de /dev/random, comme le suggère raboliot en dessous), sur un support externe, et pourquoi pas elle-même chiffrée par un mot de passe humainement tapable au clavier, c'est beaucoup mieux...
Parce qu'avec LUKS, quoi que tu fasses, la clé est sur la serrure, et elle est souvent protégée par un mot de passe beaucoup plus faible qu'elle...
[^] # Re: Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 3.
C'est ce que je faisais ;)
> En passant il y a t-il d'autres trucs que tu apprécies dans openvz et qui ne sont pas dans vserver ?
Au niveau de la configuration réseau, OpenVZ est très puissant : soit on laisse l'hôte gérer le réseau des VM en leur donnant un périph virtuel venet (~analogue à VServer)...
... soit on donne à la VM une interface réseau plus avancée (veth), permettant de lui déléguer la conf réseau (conf classique, iptables, routes, ...).
J'avoue ne pas avoir cherché plus loin que ça si c'était possible dans VServer, cela dit.
Il y a aussi que le partage de périphs entre l'hôte et la VM se fait dans le fichier de conf, plutôt qu'en faisant un "cp -a" de ce qu'il y a dans le "/dev" : je trouve ça plus propre (même s'il peut y avoir des problèmes avec udev, comme avec mon imprimante laser et mon scanner qui ont besoin de charger un firmware - m'enfin, ça se règle avec de petits scripts udev sur l'hôte, et c'est la même chose, que ce soit avec VServer ou OpenVZ).
Par contre, niveau doc, OpenVZ poutre vraiment bien : le manuel officiel est un gros PDF bien touffu, et plutôt exhaustif.
À côté, la "flower page" et le wiki de VServer sont plutôt légers, m'est avis... et ça pèse pas mal dans la balance, en ce qui me concerne.
Si ça t'intéresse, voilà le lien vers le journal que j'avais fait : http://linuxfr.org/~Aefron/27379.html ... même si c'est long, ça n'a pas pour but d'être exhaustif, mais juste d'être un retour d'expérience (et une anti-sèche occasionnelle :p), de la part d'un non-professionnel.
Cela dit, je le répète, j'utilise VServer depuis ~1,5 ans, et même si j'ai une petite préférence pour OpenVZ, les deux sont vraiment très bien ;)
D'ailleurs, vu la jeunesse d'OpenVZ sous Debian (ma distro préférée), si je devais en choisir un pour quelque chose de vraiment sérieux, ce serait probablement VServer.
Quoi qu'il en soit, pour moi qui n'ai d'instructions de virtualisation que sur mes desktops (mes serveurs sont mes vieux desktops d'il y a pas mal d'années ; et j'espère qu'ils continueront à me servir encore plein de temps), les conteneurs sont une solution bien plus praticable que la virtualisation complète, forme de solution que je pense continuer à utiliser, même quand il faudra changer les serveurs : et pour ça, je suis reconnaissant aussi bien envers une solution que l'autre.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Aefron . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 0.
Par contre, tu te permets de dire que tu as ne serait-ce que la moindre idée du rapport de problèmes entre Fedora et Sid...
Et bien entendu, ce n'est pas du FUD : oh, non, quiconque l'affirme est un con... pauvre type.
[^] # Re: Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 2.
Comme je l'ai dit, je préfère la manière de gérer le réseau à-la-OpenVZ... Je suis aussi sous VServer depuis Etch, et je n'ai pas trop aimé le fait qu'il n'y ait techniquement pas de loopback dans celui(ci (même si on m'a dit qu'il y était dans la version plus récente de Lenny).
Il y aussi la gestion plus rigoureuse des ressources (pas moyen d'espérer faire tourner OpenVZ en spécifiant globalement plus de ressources qu'il n'y en a dans la machine - il faut faire ça avec un strict minimum d'application) : du coup, ça force à être rigoureux, ce que j'aime bien.
Mais malgré tout, je ne dis pas que VServer est mauvais, bien au contraire : les deux sont très bien, et VServer est sans aucun doute plus éprouvé et utilisé qu'OpenVZ ;)
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Aefron . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 1.
Et hop : +infini.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par Aefron . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 2.
Lenny et demi : rien d'obligatoire... d'ailleurs, pour avoir ce nouveau noyau (dont le but est de supporter plus de matos et de fonctions : ni plus, ni moins - bien évidemment, le 2.6.26 restera supporté, et mis à jour quand il faudra le faire) il faudra installer _manuellement_ le _nouveau_ (nouveau dans le sens "en plus", pas "à la place de") paquet, quand il sera dispo...
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Aefron . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 3.
Pas à un seul moment.
Sur ce qui fait trébucher tout le monde, soit ce n'est pas encore packagé dans Sid (KDE4, packagekit, NM 0.7, ...), soit ce n'est pas utilisé par défaut (PulseAudio : il est même dans Etch, tu sais - mais personnellement, je ne l'ai jamais installé, sous Debian, et j'ai du son, sans le moindre problème).
Ainsi, Sid n'a aucun des bugs qui rendent souvent l'utilisation de Fedora ultra-désagréable. Zéro fois les bugs les plus chiants : je ne pense pas exagérer en disant que, du point de vue de l'utilisateur, c'est infiniment moins bugué (constante/0=+-infini).
Pour le "bien moins de problèmes", je reste dessus : la dernière fois que j'ai installé une Fedora ailleurs que dans une machine virtuelle, en moins de 24h :
- packagekit qui tombe en carafe, sans le moindre espoir de pouvoir fonctionner de nouveau ;
- du son, puis plus de son, puis du son, puis plus de son (pulseaudio ? j'avoue ne plus me rappeler s'il était déjà là, mais j'imagine que ça doit être ça) ;
- quelques hardlocks de la machine ;
- l'OS s'éteint, mais la machine ne s'arrête plus ;
- KDE 4.0 (no comment) ;
Je n'ai jamais, jamais, jamais, mais alors vraiment jamais, eu autant d'emmerdes en 2 ans de Sid qu'en 24h (même si je l'ai gardée un peu plus longtemps : j'en ai eu plus que marre au bout d'une semaine, quand même) de Fedora...
Quelque chose qu'on peut regarder, mais qui est tellement fragile qu'il ne vaut mieux pas y toucher, de peur que tout s'écroule (même si ça s'écroule quand même)... euh... bon, d'accord : ce n'est pas une vitrine - c'est ce qu'on met généralement dedans... m'enfin...
Pour tester assez souvent Fedora dans une VM, et pour utiliser de temps en temps des paquets de Debian Experimental, je l'affirme : Fedora et Experimental se valent, quand au bleeding-edge et aux plantages/incongruités à répétition. Par contre, pour comparer ça à Sid, de deux choses l'une : soit tu ne l'as jamais utilisée, soit tu FUDes.
Évidemment, je connais ton passif, et ta manière de défendre ta chapelle, qu'on l'attaque ou pas : ce pourquoi je me permets très clairement d'affirmer que, au strict minimum, tu FUDes, que tu aies jamais testé Sid, ou pas.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par Aefron . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 7.
Sid est loin d'être aussi bleeding-edge que la dernière Fedora (surtout en ce moment ; mais bon : freeze oblige ; ça va très bientôt dégeler)...
... elle est aussi infiniment moins buguée.
Au pire, en utilisant Sid, tu auras toujours bien moins de problèmes que sous Fedora (et je le précise : je n'ai rien contre Fedora - elle est très utile pour le développement du libre ; mais c'est plus une vitrine qu'autre chose).
Si tu veux chercher quelque chose d'aussi bleeding-edge, dans la famille Debian, c'est du côté des paquets d'Experimental, qu'il faut regarder et comparer - là, je ne dis pas : le standard de qualité est peu ou prou le même que celui de Fedora (à la limite de l'utilisable, et pas souvent du bon côté).
C'est "mignon" de FUDer, mais quand on compare, tes allégations ne tiennent pas un demi-instant.
[^] # Re: Au top de la modernitude !
Posté par Aefron . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 2.
Ouais : entre autres...
[^] # Re: Au top de la modernitude !
Posté par Aefron . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 4.
Je n'ai pas essayé la version 3, mais j'ai un peu touché les précédentes, et, franchement, je n'aime pas du tout : c'est moins bugué que KOffice (mais bugué, et pas très productif, quand même)... par contre, c'est lent et moche (au moins, là-dessus, il y a quelque chose à tirer de KOffice)...
Bref, m'est avis que la bureautique-clickouille libre, ça viendra (je n'en doute pas), mais ce n'est tout simplement pas encore ça, quoi qu'on utilise : ni plus, ni moins.
Quant à firefox, je ne vois pas bien le rapport avec la bureautique... par contre, en effet, je ne trouve pas que c'est une bonne appli du tout, et je ne vois pas l'intérêt de l'utiliser sous Linux. Ça n'engage que moi, cela dit.
Et pour ce qui est de l'OS "universel", pour ma part, hors routeurs (OpenWRT), je n'utilise que Debian, et ce, pour faire plein de trucs... dans mon cas (et dans celui de plein de gens qui ont une utilisation plus "commune" de leurs machines, et à qui j'en ai installé), ça marche donc plutôt bien...
... après, si le but est de retrouver exactement les mêmes softs libres que beaucoup utilisent sous OS redmondien (VLC, firefox, OOo, ...), et bien, je ne suis pas convaincu du bienfondé de la démarche : si ces applis sont peut-être très bien sous ces OS, sur la banquise, je n'ai pour ma part jamais eu que des problèmes avec (et pas que sous Debian, que j'utilise depuis moins de temps que je n'ai utilisé Slack et Gentoo)... et il y a m'est avis (à part pour OOo, comme je l'ai dit au-dessus) de biens meilleurs remplacements libres (SMPlayer ou Konqueror, par exemple).
Maintenant, si des applis souffrent de tares, plus ou moins solvables, et bien, tant pis : le but de Debian n'est pas de faire comme si elles n'en avaient pas, en collant un coup de vernis à-la-rache, ou en packageant des trucs tout sauf près à être utilisés (pour dire "ça merde, mais c'est le dernier top à la mode, 'mmm, voyez"), comme d'autres distros peuvent le faire.
En outre, si tu n'es pas satisfait par ce qu'offre Stable (que je n'utilise en tant que clickodrome que sur le PC que j'ai installé à ma mère, qui est tout sauf douée en info... et que je n'utilise que très peu comme LAMP, puisqu'il y a beaucoup d'autres serveurs dont j'ai besoin, et que Debian me permet de les avoir), il y a les backports, Testing, Unstable, Experimental, Debian-Multimedia, l'huile de coude, d'autres distros, ...
Si Stable est, je veux bien le reconnaître, limitante en desktop, c'est peut-être parce tout est loin d'être prêt pour "l'année de Linux sur le desktop de Mme Michu " (?)... J'imagine qu'un jour, je concevrai parfaitement d'installer Stable ou une autre distro du genre sur la plupart de mes clickodromes, mais en attendant, je ne fais pas comme si tout était au top dans les bureaux libres, quels qu'ils soient.
[^] # Re: Au top de la modernitude !
Posté par Aefron . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 0.
... ou attendez que Debian Testing gagne un support de sécurité (ce qui ne devrait pas "trop" tarder)...
... ou utilisez quelque chose dont les mainteneurs ne se foutent pas de ce qui a été mis en circulation par le passé...
... ou utilisez les machins de la mofoco sous un OS redmondien : après tout, c'est fait pour ça.
[^] # Re: Au top de la modernitude !
Posté par Aefron . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 7.
... et puis, niveau maintenabilité, je n'ai pas souvenir qu'OOo soit un exemple - même si ça date des 1.x/2.x, il y a quelques années, sous Gentoo, outre le temps à y passer, rien ne garantissait que l'ebuild fut ne serait-ce que compilable (s'il y avait une version source et une version binaire, ce n'était pas seulement parce que ça mettait des plombes à compiler - c'était aussi à cause de toutes les emmerdes qu'il y avait si on essayait de le faire soi-même).
Bref, trop tard, trop gros, tant pis.
Même si, dans mon activité, je n'ai pas spécialement besoin d'OOo, dans ce genre d'appli, j'attends bien plus de KOffice ; et ce sera prêt quand ce sera prêt.
Et puis, il y a pire : genre iceweasel et icedove - les notes sur la sortie de Lenny précisent qu'il y a un risque de voir le support de sécu pour ces applis abandonné, au bout d'un certain temps, vu que les développeurs originels n'en ont rien à foutre.
Plutôt que de pleurer là-dessus, ça fait un moment que j'ai remis en question la seule utilisation de ces machins, et que j'ai fini par ne plus les installer du tout ('puis bon : linux et la mofoco... un récent article sur Tuxradar [1] montre que la banquise est loin d'être une de leurs priorités ; d'ailleurs ces applis n'ont pas toujours été simplement compilables sans problème non plus - j'avais aussi des tonnes de problèmes à l'époque 1.x, sous Gentoo, si j'essayais de les compiler)...
Bref, ce n'est pas parce que c'est connu que ce sont des exemples à suivre...
[1] http://www.tuxradar.com/content/benchmarked-firefox-javascri(...)
[^] # Re: Sur le même sujet que l'article Original
Posté par Aefron . En réponse au journal « Ordinateurs : attention au trou de mémoire ». Évalué à 1.
Non : je préfère jouer aux heureux-millions (2€ par semaine... je joue aussi au Super Loto, 2€, quand il y en a un)...
... je fais plus confiance à ça qu'à une, encore plus hypothétique, retraite :p
[^] # Re: Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 3.
Oui, et non : d'un côté, si je mets, par exemple, MythTV et SqueezeCenter sur la même "machine", ils vont se partager MySQL, et il y aura plus de risques que tout tombe si l'un des deux borke la base de données... Trop de bordel, ce n'est pas forcément souhaitable...
... après, certes, au final, ça multiplie pas mal le nombre de machines, et donc, ça multiplie la charge d'administration.
D'ailleurs, en ce moment, je suis en train de rationaliser tout ça, en me servant de CFEngine : idéalement, j'aimerais stocker les classes et des variables dans un LDAP, pour tout éditer à partir d'une même interface. Pour les mises à jours, je suis aussi en train de trifouiller des scripts qui font une simulation d'un "aptitude full-upgrade", qui m'envoient le résultat par mail (chiffré), auquel je réponds par un autre, signé - si la signature est bonne, le full-upgrade se fait sans mon intervention (ça marche pas mal, mais c'est encore un peu rugueux).
Après, ça dépend de ce qu'on veut faire : pour MythTV et SqueezeCenter, comme je le disais, ils ont chacun leur MySQL... Pour OpenLDAP, je compte juste en avoir un que j'édite, plus un autre en esclave (je ne suis pas chaud du tout pour mettre un annuaire, même partiel, dans chaque conteneur qui en aura besoin - même si, a mon grand dam, je n'arrive pas à trouver de serveur DNS qui va chercher ses infos dans LDAP, et qui me satisfasse : PowerDNS n'accepte l'authentification à l'annuaire que par mot de passe, et DLZ-Bind, même s'il accepte Kerberos, que je n'aime pas tellement, ne gère pas l'authentification sur un certificat - j'en suis donc à me dire que le plus propre serait peut-être d'avoir une réplique partielle de mon annuaire, juste pour les noms d'hôtes, dans un conteneur, avec DLZ-Bind)...
Cela dit, les possibilités offertes sont telles que c'est justement l'occasion d'organiser son réseau comme on le souhaite. Tout dépend des compromis que l'on cherche...
[^] # Re: Sur le même sujet que l'article Original
Posté par Aefron . En réponse au journal « Ordinateurs : attention au trou de mémoire ». Évalué à 2.
Avec l'extension du nombre d'années de cotisation nécessaires, j'imagine que je serai mort bien avant de pouvoir prétendre à une retraite ne serait-ce que vaguement suffisante...
... alors, les fiches de paye...
[^] # Re: Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 5.
Après, est-ce que c'est moins consommateur d'énergie ? Je ne sais pas : peut-être un peu moins, vu que les instructions de virtualisation ne sont pas sollicitées. Mais à mon avis, l'avantage est surtout en ce que, n'ayant pas besoin de ces instructions, peu ou prou n'importe quel proc (x86 ou AMD64 - ça reste des patchs maintenus en dehors de Vanilla, même si, aussi bien pour VServer qu'OpenVZ, il y a pas mal de contribution au kernel de base, pour en venir un jour à supporter les conteneurs nativement) peut faire l'affaire, pourvu qu'il y ait assez de RAM sur la bête (en modifiant un poil le debootstrap de base, ie en n'utilisant syslog-ng au lieu de rsyslog, j'arrive à faire tourner des VM qui n'allouent pas plus de 5Mio de RAM... évidemment, ça gonfle selon les services utilisés).
Après, il y a sans doute un peu d'overhead, dû à la séparation, mais, c'est peu ou prou invisible, même sur mes vieilles machines.
Sinon, pour l'installation des softs, je me méfie comme la peste du contrôle de la VM directement à partir du shell de l'hôte (il peut y avoir des problèmes d'inaccessibilité des VT et cie... et c'est très chiant)... Par contre, une fois dans le conteneur (par SSH, par exemple, ou, sous OpenVZ, en faisant "vzctl enter ID_DE_LA_MACHINE, ce qui lance un sous-shell de l'invité sur l'hôte), pas de problème : au /dev (atrophié et statique : ce que je trouve très bien), et aux capacités du noyau près (ce qui inclue le réseau, sauf si, sous OpenVZ, on donne accès à la conf réseau en utilisant une interface virtuelle plus avancée), ça fonctionne exactement comme une machine courante. L'un de mes conteneurs est d'ailleurs un approx qui sert de cache/miroir deb local à toutes mes machines (oui, je suis très Debian) - on installe ce qu'on veut, il y a un init tout ce qu'il y a de plus classique, ... c'est transparent.
[^] # Re: Sur le même sujet que l'article Original
Posté par Aefron . En réponse au journal « Ordinateurs : attention au trou de mémoire ». Évalué à 1.
Ouais : jusqu'à ce qu'on ait des implants qui nous permettent d'accéder au données numériques en se branchant le support électronique directement dans les synapses :p
# Conteneurs
Posté par Aefron . En réponse au journal La virtualisation en production. Évalué à 4.
* Nombres d'utilisateurs ?
Très peu : c'est pour chez moi... outre l'accès à quelques fichiers via le conteneur SFTP, il n'y a pour ainsi dire que moi...
* Combien de DomU ?
"Conteneurs"... :p ... sinon, entre 20 et 30 (pour l'instant... mes plans de scientifique fou en prévoient entre 50 et 60).
* Quelles fonctions des DomU ?
Un service, un conteneur (sauf pour des trucs comme le MySQL de MythTV ou celui de SqueezeCenter, qui sont posés dans le même conteneur que l'appli qui les utilise)... en vrac, SMTP-auth, IMAPS, SFTP, MlDonkey, Tor, CUPS, SANE, NFS, NUT, MythTV, SqueezeCenter, DNS, CFEngine, LDAP (en cours), et j'en passe une bonne racée... plein, plein, plein de choses.
* Combien de serveurs ont été remplacés par la virtualisation ?
* Combien de serveurs utilisés pour la virtualisation ?
Aucun... ou tous... au choix. Avant, je chrootais à la mimine tout ce qui était destiné à être accessible en public, sur une machine, et je laissais le reste sous une même arborescence, sur une autre machine... c'était chiant, et sale.
Maintenant, mes deux serveurs sont devenus des routeurs/étagères à conteneurs... et c'est merveilleux.
* Méthode d'intégration à l'existant ?
Test dans un Qemu/Virtualbox, puis, basculage sauvage avec réinstallation (je ne suis sous Linux "que" depuis ~5 ans... aussi, avant mon utilisation des conteneurs, mes serveurs souffraient d'erreurs de ma jeunesse sur la banquise - j'en profite pour repartir sur des bases saines).
* Choix de la solution logiciel ?
OpenVZ/Vserver, comme je l'ai dit. J'ai tendance à préférer OpenVZ (plus drastique sur la gestion du matos, je préfère la syntaxe de "vzctl" que celle de "vserver", routage plutôt que des "liens" IP).
Toujours pas eu le courage de basculer le VServer vers OpenVZ... peut-être après la sortie de Lenny :D
* Choix de la solution matériel ?
C'est ça, qui est bien : de vieilles babasses, à base d'Athlon XP (2Gio et 3Gio de RAM... et j'ai moult marge). Pas d'instruction de virtualisation, pas de RAM bouffée par plein de noyals, accès très simple au périphs (deux imprimantes, un scanner, quatre cartes DVB-T) : nickel.
* Est-ce stable en production ?
Très (pour OpenVZ, il y a eu des problèmes il y a quelques mois ; pas directement à cause du patch OpenVZ, mais plutôt à cause de Linux Vanilla - ce que le patch OpenVZ mettait en évidence en hardlockant la machine - mais bon, c'est réglé depuis un moment, et puis, Lenny ne sort officiellement que demain, a priori).
* Délai d'étude et de mise en production ?
Vu que c'est pour chez moi (pas spécialement de lien à l'informatique dans mon boulot : en ce moment, je gratte même tellement d'équations sur le papier que je ne prends même pas le temps d'allumer l'ordi au boulot), à mon rythme.
Mais c'est quand même 'achement accessible.
Bref : vivent les conteneurs (aussi) !
# Nova
Posté par Aefron . En réponse au journal Cuba se tourne vers les logiciels libres. Évalué à 7.
[^] # Re: venet vs veth
Posté par Aefron . En réponse au message OpenVz : Plusieurs IP Failovers pour une même machine virtuelle. Évalué à 2.
Si tu avais un SSH d'ouvert vers elle, ou quelque chose du genre, tu risques de perdre la connexion, mais le temps que les réglages soient appliqués, tu peux de nouveau y accéder (et par les deux adresses).
[^] # Re: -host ?
Posté par Aefron . En réponse au message OpenVz : Plusieurs IP Failovers pour une même machine virtuelle. Évalué à 2.
Donc, pas de netmask avec les VM qui utilisent ces interfaces virtuelles ;)
# venet vs veth
Posté par Aefron . En réponse au message OpenVz : Plusieurs IP Failovers pour une même machine virtuelle. Évalué à 6.
Si tu veux simplement assigner deux IP à une VM, tu as juste à faire (avec les droits root, bien sûr - et dans l'hôte, évidemment) : "vzctl set ${ID} --ipadd 91.xx.xx.11 --ipadd 91.xx.xx.22 --save" ... Ce sera l'hôte OpenVZ qui s'occupera des routes (rien à spécifier manuellement ; à part éventuellement sur les routeurs en amont, si tu fais des choses un poil exotiques, avec plusieurs réseaux disjoints... m'enfin).
Ton conteneur se retrouvera alors avec les deux adresses spécifiées...
... bon, si il a déjà "91.xx.xx.11", vzctl va te dire qu'il a déjà cette adresse et qu'il ne la rajoute pas (il rajoutera quand même celle qui manque).
Sinon, si tu veux repartir de zéro, tu fais "vzctl set ${ID} --ipdel all --save", puis, tu rajoutes les deux, comme j'ai écrit au-dessus.
[^] # Re: Krita vs Gimp
Posté par Aefron . En réponse à la dépêche Krita 2.0 aura besoin de tests. Évalué à 5.
Sur ce point, Gimp est vraiment lourdingue...
Un bon point est aussi qu'il est en QT, et donc, qu'il ne met pas trois plombes à rafraîchir la GUI quand la machine est bien sollicitée...
Pour ce que je reproche à Krita (pas encore testé la 2.0) : moins de plugins (en même temps, ce n'est pas comme si ceux de Gimp étaient toujours maintenus, comme mon préféré, "Flammes", qui segfaulte depuis des années dès qu'on essaye de l'appliquer sur une trop grosse résolution ; et c'est loin d'être le seul), et pas toujours compatible avec les .xcf travaillés sous Gimp ('peut pas ouvrir mes plus gros projets Gimp avec Krita 1.x :( )...
[^] # Re: Concurrence
Posté par Aefron . En réponse à la dépêche Qui a intérêt à transformer Internet en Minitel ?. Évalué à 3.
Ah si, il faut... des miracles en matière d'ineptie, mais des miracles quand même : http://www.liberation.fr/terre/0101317403-la-gauche-au-secou(...)