Si on devait développer une autre migration, ce serait une migration depuis Ubuntu qui serait intéressante ! Bien sûr c'est sans tenir compte de la faisabilité !
L'avantage, c'est que les utilisateurs partiraient d'un système, par principe, assez aléatoire ;-)
Le problème ... pour toi ... pour moi le problème justement c'est de brasser de l'air sur un détail de vocabulaire plutôt que de s'interesser au sujet du journal/de la news.
Sur le fond. Tu as raison, c'est une erreur. Erreur qui reflète l'air du temps et la mentalité actuelle, même d'un public sensé être "averti". Si le but est de changer cette mentalité et d'éduquer la masse, c'est au mieux ... un bel exemple de technocratie. Internet, et le web par extension, c'est avant tout un outil que les gens utilisent et nomment comme ils le souhaitent. Ça n'est pas qu'un joujou pour technicien qui fait de l'auto-hébergement et avec qui il faut employer les bons mots pour pouvoir s'exprimer sans se faire reprendre à tout bout de champ.
Toi on voit que tu n'as pas vraiment besoin d'accéder à Internet en déplacement. Parce que la différence entre Internet et le web, elle se voit, quand on se retrouve limité au web…
Et alors ? C'est une tomber sur tout ceux qui font la faute ? C'est lourd..
De plus en plus de gens utilisent leur courriel par une interface web, ce qui rend l'utilisation de OpenPGP ¹ encore plus difficile, car cela nécessiterait des extensions au navigateurs.
Ceci d'autant plus que la seule extention pour firefox, n'est plus maintenue, et déconne semble il (tous les messages sont marqués comme n'ayant pas pu être identifés).
Mais, avec un peu de boulot, cela pourrait être facilement améliorer, de même que l'utilisabilité (insertion d'un lien dans les menus du webmail, ou detection par le webmail de l'extention et proposition d'un item de menu en plus)
Eh bien ce n'est pas plus mal. FTP est une merde sans nom, aujourd'hui inutile sauf pour une utilisation très précise. Tout le monde s'en portera mieux quand il aura disparu.
Je suis sûr que si tu avais designé le protocole, tu aurais fais mieux que John Postel.
On a beau être sur trollfr, je suis un peu choqué / étonné des commentaires et de leur ton.
Certes, ce que propose la FSFF n'est pas parfait, certes le mot SaaS est peut être mal choisi, mais en attendant, ils proposent gracieusement un service de VMs aux projets libres pour leurs besoins d'infrastructures. Combien d'entre vous peuvent en dire autant ?
Personnellement, j'utilise ce service pour les besoins d'un lug, et de projets associés. Ça juste marche. J'en suis très content, je les en remercie grandement et j'espère qu'ils pourront faire évoluer et grossir le truc pour permettre à d'autres d'en profiter.
Toi t'as jamais été voir freenet ... Toutes dérives du net, y compris celles sur lesquelles tu aurais aimé ne jamais tomber y sont représentées et y occupe une part non négligeable ..
Si l'espace de stockage n'est aujourd'hui plus un problème (pour 8To en raid5, le ticket d'entrée est aujourd'hui de l'ordre de 500 €), augmenter les volumes n'est pas sans poser de problèmes, notamment pour le temps de reconstruction en cas de panne.
La dé-duplication est aussi utile pour le cache.
Typiquement, si tu utilises de la virtualisation par conteneur (lxc, openvz, vserver), c'est dommage de mettre 25x syslogd en cache. (Vserver intègre un hack à coup de liens physiques et d'attributs posix pour ça)
Typiquement aussi, un hébergeur web. Combien tu penses avoir de copie identiques de wordpress-v-current.php ?
Typiquement aussi, un fournisseur de mail, où les utilisateurs sont abonnés aux mêmes ML (de mémoire cyrus a un mécanisme interne pour ça) et vont donc pontiellement recevoir souvent les mêmes mails
Je comprends bien le problème, mais je trouve ça débile. Je ne vois pas pourquoi Firefox a un comportement différent, si à la première connexion je valide le certificat, il n'y a plus à me poser la question ou à rechigner de l'accepter. Je ne comprends vraiment pas où ils veulent en venir comme ça.
When connecting to a Known HSTS Host, the UA MUST terminate the connection with no user recourse if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport.
Autant ça peut faire sens pour un site ayant un besoin extreme de sécurité (banque etc), autant pour les sites ou c'est juste "bonus" (wikipedia, linuxfr..) , c'est peut être un peu trop strict.
Dans le cas d'une crise ou de bidouille comme le décrit Thomas, ça ne me paraît pas tellement plus compliqué, non. Faut juste écrire le fichier de description du conteneur, on le fait une fois et c'est marre.
Et configurer un bridge/nat, et et et et et...
C'est vrai, j'ai pas trouvé comment faire. Mais la méthode actuelle (un système minimal pour faire tourner le démon) n'est en fait pas très complexe.
C'est simple, il faut s'abstraire des outils tout fait qui masquent la complexité de la chose. Un LXC c'est juste une arborescence + quelques fichiers de conf. Si tu génère tout automatiquement ça donne l'impression d'être simple, pourtant ça l'est pas vraiment.. la preuve tu n'as pas pensé à contourner ces outils ou à regarder comment ils marchaient/ce qu'ils faisaient...
Et ça ne demande pas de bidouille à la OpenVZ ou Vserver (pas de patch noyau, etc).
Huhu. en l'occurrence aucun de ces 2 là ne va crasher l'hôte à cause d'un while (1) malloc(beaucoup). Tu me prêtes un shell et on essai sur tes LXC ? :)
chroot=truc; for x in /proc /sys /run; do mount -o bind $x $chroot/$x; done ; chroot $chroot
Tu es vraiment sûr que c'est plus simple ? Et si jamais tu veux faire un conteneur leger avec juste un deamon c'est toujours plus simple ? (lxc le permet mais ne fournit aucun script-kikoolol-qui-fait-tout-pour-toi-et-te-donne-l-impression-que-c-est-simple dans ce cas).
et les choses crades qui écrivent dans /etc (d'ailleurs, je n'ai pas d'exemple en tête de scripts au démarrage qui font ceci... tu as un coupable en tête ?).
n'importe quel client dhcp: il modifiera le /etc/resolv.conf voir nsswitch (debian ne fait rien pour ça)
Que veut dire cette phrase ? Un outil utilisé pour contribuer à la sécurité d'un système est un "élément de sécurité", qu'il aie été conçu pour cela ou non.
Chroot entre dans la composition des "Linux containers" ( http://lxc.sourceforge.net/ ) qui peuvent être utilisés pour sécuriser un système. Doit-on reduire chroot et LXC à des softs de sécu ? Sans doutes pas.
Ces logiciels apportent-ils des fonctionnalités de sécurité ? On aurait du mal à en douter.
Sauf qu'un chroot seul, n'apporte aucune sécurité. Il apporte au mieux une illusion de sécurité. Illusion que n'importe quel kiddie sachant taper "chroot exploit" dans google pourra remettre en question.
Qu'il soit utilisé par LXC où autre ne change pas grand chose. Je suis sûr que LXC utilise printf aussi, c'est par pour autant que c'est un logiciel de sécurité. Et heuresement qu'LXC n'utilise pas que chroot ;)
N'y aurait-il pas déjà un embryon d'implémentation de certaines capacités dans Linux ? Pour faire des trucs comme écouter sur un port réseau privilégié ?
Posté par geb .
En réponse au journal OpenVZ & LXC.
Évalué à 2.
Je regarde tout ça d'un oeuil intéressé mais pas expert. Pourquoi tu ne peux pas utiliser les quotas classiques ? Tout les processus ont le même utilisateur ?
Non, mais tu peux avoir plusieurs utilisateurs ayant le même uid sur les différentes VMs.
Par contre, le fonctionnement de ces quotas par VM est fortement inspiré du fonctionnement des quotas classiques, avec des IDs rajoutés en plus (voir http://linux-vserver.org/Paper#Filesystem_XID_Tagging pour vserver, cela doit être semblable avec openvz).
Il y a pas moyen de corriger ça avec un LSM style AppArmor ou SELinux ?
Honnêtement, je ne sais pas. Par contre:
cela ne semble par être le "coeur de métier" de ces outils. Je ne suis pas du tout sûr qu'ils proposent de quoi faire des quotas.
il est possible que certaines choses rentrent en conflits. Typiquement pour utiliser openvz ou vserver, il faut avoir désactivé SELinux. A priori, seul grsecurity est utilisable avec lxc et vserver (mais pas openvz), et il ne permet pas ce genre de choses.
Posté par geb .
En réponse au journal OpenVZ & LXC.
Évalué à 1.
Pardon pour le ton c'était pas volontaire.
Mais justement, pour moi, c'est pas aussi bien, le hack à coup de LVM (que tu peux utiliser avec openvz et vserver). Par contre, si il y a moyen de passer outre, et d'avoir le même genre de comportement qu'avec vserver ou openvz, je suis vraiment curieux de savoir comment :-)
Il y a clairement des manques dans les cgroups. Par exemple au niveau de la limitation de la mémoire:
Avec vserver, il y a moyen de limiter la mémoire en terme de mémoire virtuelle (mem + swap). C'est le kernel qui globalement, décidera si cela vaut le coup de swapper ou non. Et, si tu dépasses le quota, tu ne peux plus allouer de mémoire (logique non?)
Avec les cgroups, tu dois configurer une limite en terme de mémoire + une limite en terme de swap. Cela pose un premier problème, cela force à swapper, quand l'hôte à encore de la mémoire disponible ! De plus, et c'est là le plus drôle, l'allocation n'est pas bloquée. Donc un process essayant d'allouer plus que son quota va pouvoir allouer (dans le swap), mais va se faire killé par l'oomkiller. Donc, il va écrire dans le swap, puis le kernel va vider le swap. Imagines que cela arrive à un processus apache (+ mod_php), aussitôt killé, le master va chercher à le relancer. Cela fait une très jolie forkbomb qui en plus va faire plein d'aller et retour dans le swap et peut finir facilement par écrouler l'hôte. L'oom-killer de la version 2.6.37 devrait diminuer un peu le problème, mais ... avoir une vrai limite en terme de mémoire virtuelle, et des allocations bloquées quand le quota est dépassé serait un poil mieux.
Bref, les cgroups c'est pas encore ça. Vserver permet de les utiliser, mais, je suis en train de voir comment repasser sur l'ancien comportement, lui au moins ne faisait pas monter le load de la machine à 500.
Posté par geb .
En réponse au journal OpenVZ & LXC.
Évalué à 4.
Ah oui pour les quotas disques, là aussi il y a un remplacement très efficace et mainline, utiliser lvm pour des partitions à la demande, avec le cow (copy on write) y a même manière d'instancier beaucoup de vm en un minimum de temps...
Je suis curieux de savoir comment tu fais ton cow.
Et dans tous les cas ça n'est pas la même chose. Avec vserver et openvz, tu peux donner des quotas sur une partition. Avec LXC tu es obligé de creer une partition. La différence pourra paraitre minime, mais un exemple simple illustrera la différence.
Prends un disque de 500 Go. Mets 50 VMs dessus.
Si tu dois creer des partions pour chaque VM, tu peux leur donner 10Go max.
Si tu peux partager la même partition. Rien n'empêche de donner un peu plus , en gageant sur le faite que tout le monde n'utilisera pas ses 15 ou 20Go.
C'est d'ailleurs exactement la même différence entre la gestion de la mémoire avec lxc,vserver, openvz et kvm,qemu,xen:
Dans un cas tu peux légèrement surbooker: Si tu as une VM a qui tu alloues 256mo mais qui en utilise 128mo, le kernel verra une utilisation de 128mo.
Dans l'autre si tu alloues 256mo à une VM, tu vas utiliser 256mo.
(A titre d'exercice je te laisse le soin de trouver à quelle technologie correspond quel comportement :) )
Posté par geb .
En réponse au journal OpenVZ & LXC.
Évalué à 2.
Il faut dire qu'il y a 4 ans LXC n'existait pas (ou en était à ses prémices), je ne connais pas les dates exactes.
Openvz a toujours eu du mal à suivre les différentes versions de linux. Cela tient sans doute un peu au code, mais aussi sans à la volonté des développeurs de faire un produit entreprise, et donc de se concentrer sur le support des kernels LTS, typiquement ceux utilisés par red hat.
[^] # Re: Bande de pervers
Posté par geb . En réponse à la dépêche Entretien avec des développeurs francophones d'OpenBSD - Partie 1. Évalué à 4.
Si tu as des machines antédiluvienne, c'est normal de devoir utiliser un Os antédiluvien pour qu'il marche dessus :)
[^] # Re: Migration
Posté par geb . En réponse à la dépêche Sortie de Mageia 1. Évalué à 5.
L'avantage, c'est que les utilisateurs partiraient d'un système, par principe, assez aléatoire ;-)
[^] # Re: Heu...
Posté par geb . En réponse au journal Windows 8 is Awesome (tiling wm). Évalué à 1.
[^] # Re: Web != Internet
Posté par geb . En réponse au journal Site facebook != Site Internet. Évalué à -2.
Le problème ... pour toi ... pour moi le problème justement c'est de brasser de l'air sur un détail de vocabulaire plutôt que de s'interesser au sujet du journal/de la news.
Sur le fond. Tu as raison, c'est une erreur. Erreur qui reflète l'air du temps et la mentalité actuelle, même d'un public sensé être "averti". Si le but est de changer cette mentalité et d'éduquer la masse, c'est au mieux ... un bel exemple de technocratie. Internet, et le web par extension, c'est avant tout un outil que les gens utilisent et nomment comme ils le souhaitent. Ça n'est pas qu'un joujou pour technicien qui fait de l'auto-hébergement et avec qui il faut employer les bons mots pour pouvoir s'exprimer sans se faire reprendre à tout bout de champ.
[^] # Re: Web != Internet
Posté par geb . En réponse au journal Site facebook != Site Internet. Évalué à -1.
Et alors ? C'est une tomber sur tout ceux qui font la faute ? C'est lourd..
[^] # Re: courrier web
Posté par geb . En réponse au journal [GPG pour les nuls] C'est pour quand ?. Évalué à 3.
Ceci d'autant plus que la seule extention pour firefox, n'est plus maintenue, et déconne semble il (tous les messages sont marqués comme n'ayant pas pu être identifés).
Mais, avec un peu de boulot, cela pourrait être facilement améliorer, de même que l'utilisabilité (insertion d'un lien dans les menus du webmail, ou detection par le webmail de l'extention et proposition d'un item de menu en plus)
[^] # Re: Cela sert-il encore à quelque chose... ?
Posté par geb . En réponse à la dépêche Sortie de BlueGriffon 1.0. Évalué à 5.
Je suis sûr que si tu avais designé le protocole, tu aurais fais mieux que John Postel.
# Réponses
Posté par geb . En réponse au journal La FSF France propose une alternative au SaaS propriétaire. Évalué à 4.
On a beau être sur trollfr, je suis un peu choqué / étonné des commentaires et de leur ton.
Certes, ce que propose la FSFF n'est pas parfait, certes le mot SaaS est peut être mal choisi, mais en attendant, ils proposent gracieusement un service de VMs aux projets libres pour leurs besoins d'infrastructures. Combien d'entre vous peuvent en dire autant ?
Personnellement, j'utilise ce service pour les besoins d'un lug, et de projets associés. Ça juste marche. J'en suis très content, je les en remercie grandement et j'espère qu'ils pourront faire évoluer et grossir le truc pour permettre à d'autres d'en profiter.
[^] # Re: mais enfin, Freenet c'est le mal, non?
Posté par geb . En réponse au journal Des nouvelles de Freenet…. Évalué à 4.
Toi t'as jamais été voir freenet ... Toutes dérives du net, y compris celles sur lesquelles tu aurais aimé ne jamais tomber y sont représentées et y occupe une part non négligeable ..
[^] # Re: Système de fichiers et déduplication
Posté par geb . En réponse à la dépêche Sortie de DragonFly BSD 2.10. Évalué à 4.
La dé-duplication est aussi utile pour le cache.
Typiquement, si tu utilises de la virtualisation par conteneur (lxc, openvz, vserver), c'est dommage de mettre 25x syslogd en cache. (Vserver intègre un hack à coup de liens physiques et d'attributs posix pour ça)
Typiquement aussi, un hébergeur web. Combien tu penses avoir de copie identiques de wordpress-v-current.php ?
Typiquement aussi, un fournisseur de mail, où les utilisateurs sont abonnés aux mêmes ML (de mémoire cyrus a un mécanisme interne pour ça) et vont donc pontiellement recevoir souvent les mêmes mails
etc..
[^] # Re: Entrée dans le suivi
Posté par geb . En réponse à la dépêche HTTP Strict Transport Security. Évalué à 3.
Je pense qu'il voulait juste dire que par défaut firefox ne reconnait pas cacert comme authorité de certification. À la demande des gens de ce cacert de mémoire ( https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 ).
# C'est bien joli tout ça, mais...
Posté par geb . En réponse à la dépêche HTTP Strict Transport Security. Évalué à 4.
Autant ça peut faire sens pour un site ayant un besoin extreme de sécurité (banque etc), autant pour les sites ou c'est juste "bonus" (wikipedia, linuxfr..) , c'est peut être un peu trop strict.
# C'est un peu tard..
Posté par geb . En réponse au journal GNOME 3. Évalué à 4.
Encore une fois, ils ont pas tenus leurs délais, ils ont 5 jours de retard ;)
[^] # Re: Libre ?
Posté par geb . En réponse au journal un mois avec Chrome. Évalué à 3.
Cool, par contre, va falloir combien de forks pour arriver à un truc utilisable autant techniquement que moralement ? :)
[^] # Re: for i in [...] mount [...] chroot
Posté par geb . En réponse à la dépêche /run or not /run. Évalué à 4.
Et configurer un bridge/nat, et et et et et...
C'est simple, il faut s'abstraire des outils tout fait qui masquent la complexité de la chose. Un LXC c'est juste une arborescence + quelques fichiers de conf. Si tu génère tout automatiquement ça donne l'impression d'être simple, pourtant ça l'est pas vraiment.. la preuve tu n'as pas pensé à contourner ces outils ou à regarder comment ils marchaient/ce qu'ils faisaient...
Huhu. en l'occurrence aucun de ces 2 là ne va crasher l'hôte à cause d'un while (1) malloc(beaucoup). Tu me prêtes un shell et on essai sur tes LXC ? :)
[^] # Re: for i in [...] mount [...] chroot
Posté par geb . En réponse à la dépêche /run or not /run. Évalué à 2.
Tu es vraiment sûr que c'est plus simple ? Et si jamais tu veux faire un conteneur leger avec juste un deamon c'est toujours plus simple ? (lxc le permet mais ne fournit aucun script-kikoolol-qui-fait-tout-pour-toi-et-te-donne-l-impression-que-c-est-simple dans ce cas).
[^] # Re: Et les autres?
Posté par geb . En réponse à la dépêche /run or not /run. Évalué à 5.
n'importe quel client dhcp: il modifiera le /etc/resolv.conf voir nsswitch (debian ne fait rien pour ça)
resolvconf (idem)
(liste non exhaustive)
# \o/
Posté par geb . En réponse au journal Merci wanda. Évalué à 3.
\o/
[^] # Re: Relativisons
Posté par geb . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 3.
Sauf qu'un chroot seul, n'apporte aucune sécurité. Il apporte au mieux une illusion de sécurité. Illusion que n'importe quel kiddie sachant taper "chroot exploit" dans google pourra remettre en question.
Qu'il soit utilisé par LXC où autre ne change pas grand chose. Je suis sûr que LXC utilise printf aussi, c'est par pour autant que c'est un logiciel de sécurité. Et heuresement qu'LXC n'utilise pas que chroot ;)
[^] # Re: Proto-implémentation
Posté par geb . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 8.
Genre les capacités posix ?
http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt
http://www.gentoo.org/proj/en/hardened/capabilities.xml
(CAP_NET_BIND_SERVICE pour celui que tu cherche).
(http://linux-vserver.org/Paper et http://linux-vserver.org/Capabilities_and_Flags pour un exemple d'utilisation).
[^] # Re: c'est passé ya quelques jours
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 2.
Non, mais tu peux avoir plusieurs utilisateurs ayant le même uid sur les différentes VMs.
Par contre, le fonctionnement de ces quotas par VM est fortement inspiré du fonctionnement des quotas classiques, avec des IDs rajoutés en plus (voir http://linux-vserver.org/Paper#Filesystem_XID_Tagging pour vserver, cela doit être semblable avec openvz).
Honnêtement, je ne sais pas. Par contre:
cela ne semble par être le "coeur de métier" de ces outils. Je ne suis pas du tout sûr qu'ils proposent de quoi faire des quotas.
il est possible que certaines choses rentrent en conflits. Typiquement pour utiliser openvz ou vserver, il faut avoir désactivé SELinux. A priori, seul grsecurity est utilisable avec lxc et vserver (mais pas openvz), et il ne permet pas ce genre de choses.
[^] # Re: c'est passé ya quelques jours
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 1.
Pardon pour le ton c'était pas volontaire.
Mais justement, pour moi, c'est pas aussi bien, le hack à coup de LVM (que tu peux utiliser avec openvz et vserver). Par contre, si il y a moyen de passer outre, et d'avoir le même genre de comportement qu'avec vserver ou openvz, je suis vraiment curieux de savoir comment :-)
[^] # Re: Manque de doc...
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 3.
J'avais commencé à troller sur https://linuxfr.org/users/jyes/journaux/mauvaise-surprise-virtuelle%E2%80%A6 mais le journal commençant à mourir, je n'ai pas continué :)
Il y a clairement des manques dans les cgroups. Par exemple au niveau de la limitation de la mémoire:
Avec vserver, il y a moyen de limiter la mémoire en terme de mémoire virtuelle (mem + swap). C'est le kernel qui globalement, décidera si cela vaut le coup de swapper ou non. Et, si tu dépasses le quota, tu ne peux plus allouer de mémoire (logique non?)
Avec les cgroups, tu dois configurer une limite en terme de mémoire + une limite en terme de swap. Cela pose un premier problème, cela force à swapper, quand l'hôte à encore de la mémoire disponible ! De plus, et c'est là le plus drôle, l'allocation n'est pas bloquée. Donc un process essayant d'allouer plus que son quota va pouvoir allouer (dans le swap), mais va se faire killé par l'oomkiller. Donc, il va écrire dans le swap, puis le kernel va vider le swap. Imagines que cela arrive à un processus apache (+ mod_php), aussitôt killé, le master va chercher à le relancer. Cela fait une très jolie forkbomb qui en plus va faire plein d'aller et retour dans le swap et peut finir facilement par écrouler l'hôte. L'oom-killer de la version 2.6.37 devrait diminuer un peu le problème, mais ... avoir une vrai limite en terme de mémoire virtuelle, et des allocations bloquées quand le quota est dépassé serait un poil mieux.
Bref, les cgroups c'est pas encore ça. Vserver permet de les utiliser, mais, je suis en train de voir comment repasser sur l'ancien comportement, lui au moins ne faisait pas monter le load de la machine à 500.
[^] # Re: c'est passé ya quelques jours
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 4.
Je suis curieux de savoir comment tu fais ton cow.
Et dans tous les cas ça n'est pas la même chose. Avec vserver et openvz, tu peux donner des quotas sur une partition. Avec LXC tu es obligé de creer une partition. La différence pourra paraitre minime, mais un exemple simple illustrera la différence.
Prends un disque de 500 Go. Mets 50 VMs dessus.
Si tu dois creer des partions pour chaque VM, tu peux leur donner 10Go max.
Si tu peux partager la même partition. Rien n'empêche de donner un peu plus , en gageant sur le faite que tout le monde n'utilisera pas ses 15 ou 20Go.
C'est d'ailleurs exactement la même différence entre la gestion de la mémoire avec lxc,vserver, openvz et kvm,qemu,xen:
Dans un cas tu peux légèrement surbooker: Si tu as une VM a qui tu alloues 256mo mais qui en utilise 128mo, le kernel verra une utilisation de 128mo.
Dans l'autre si tu alloues 256mo à une VM, tu vas utiliser 256mo.
(A titre d'exercice je te laisse le soin de trouver à quelle technologie correspond quel comportement :) )
[^] # Re: c'est passé ya quelques jours
Posté par geb . En réponse au journal OpenVZ & LXC. Évalué à 2.
Il faut dire qu'il y a 4 ans LXC n'existait pas (ou en était à ses prémices), je ne connais pas les dates exactes.
Openvz a toujours eu du mal à suivre les différentes versions de linux. Cela tient sans doute un peu au code, mais aussi sans à la volonté des développeurs de faire un produit entreprise, et donc de se concentrer sur le support des kernels LTS, typiquement ceux utilisés par red hat.