Je n'ai jamais parlé de Etch-and-a-half.
T'as remarqué ?
J'ai uniquement parlé de Lenny-and-a-half et principalement du noyau.
T'as remarqué ?
En passant le noyau supporté par Etch est et reste le 2.6.18 (le 2.6.24 n'a pas Xen par exemple).
Pour Lenny ce n'est pas ce qui a été dit (je n'ai pas envis de fouiller les archives).
Lenny-and-a-half sera probablement Debian 5.1 (Lenny + 1 sera Debian 6.0). Etch-and-a-half est "seulement" 4.0-r4 (si j'ai bonne mémoire).
- [...] 2.6.24 kernel, nor that all software included in etch will work correctly with the newer kernel.
- Not all features of the etch 2.6.18 kernel are available in the 2.6.24 images, this includes the Xen and linux virtual server flavors.
[...]
- Out-of-tree kernel module source packages that were provided in etch are not guaranteed to function properly with the 2.6.24 kernel.
Ce 2.6.24 est vraiment optionnel... On ne peut parler de mise à jour.
Celui de Lenny ne le sera pas. C'est ce que j'ai lu.
> > Mais t'as superbement fuder
>
> Pas à un seul moment.
Rires.
> 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).
Admettons. Il n'empêche que t'es complètement à côté de la plaque.
Tu peux faire le "mignon" avec tes "Debian est infiniment moins buggé", mais c'est le moins qu'on puisse demander à Debian.
Idem, RHEL est moins buggué que Fedora. Mais c'est le moins qu'on puisse demander à RHEL. Et si RHEL est moins buggé, c'est grace à Fedora.
En phase de développement, Fedora prend ce qui merde encore et *DOIT* être corrigé/développé car c'est l'avenir (au lieu d'attendre d'indéfininement que d'autres le fassent). RHEL et Debian prend ce qui marche et corrige les deux ou trucs qui restent à corriger. La démarche n'a rien à voir.
Ce n'est pas l'un est mieux et l'autre est mal, c'est complémentaire, les deux ont raisons, les deux sont des compromis différents.
> 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...
Mais oui...
Regarde les forums Debian, on ne compte pas les "ça merde avec SID" et les "on t'avait prévenu"...
> Fedora et Experimental se valent
Il y a tous les derniers patch pour KVM (par exemple pour avoir Dom0 de Xen mais sans Xen) dans Experimental ?
Est-ce que Xenner est fonctionnel dans Experimental de Debian ? En tout cas il l'est dans F10.
Il y a un support correcte de SeLinux dans Experimental et pas seulement un "CONFIG_SECURITY_SELINUX=y" dans /boot/config ?
Pourtant ça fait des plombes que Debian bosse sur Selinux...
Si tu prends la branche de développement de Fedora (Rawhide), c'est beaucoup plus expérimental que Experimental de Debian.
Dans Rawhide ext4 est par défaut ? Est-ce le cas de Experimental de Debian ?
Biensûr que non.
Il y a maintenant gcc 4.4 dans Rawhide et tout va être recompiler avec ce dernier dans la semaine à venir. Quand Debian fera ça ? Quand Fedora et gcc aura bien débuggué gcc...
Etc.
> soit tu ne l'as jamais utilisée
Je ne l'ai jamais utilisée et n'est jamais dit le contraire.
> soit tu FUDes.
Je n'ai pas dit que l'un était pire que l'autre (par contre toi tu le dis) mais que le compromis est différent (Fedora est plus agressif et notamment pour Rawhide si tu veux comparer à Sid). Après à chaqu'un de voir ce qui lui convient.
J'ai Fedora chez moi, pourfois ça merde, mais globalement j'aime le compromis.
En passant, j'utilise ext4 (il est proposé à l'installation dans F10). Quel est le niveau de support d'ext4 dans Debian ? Probablement pas du niveau de Fedora. Normal, Debian est plus "frileux" que Fedora. A tord à raison ? Je m'en torche le fions.
> Évidemment, je connais ton passif, et ta manière de défendre ta chapelle, qu'on l'attaque ou pas
Toi on n'attaque pas ta chapelle et tu te répands en connerie et mensonges.
> je me permets très clairement d'affirmer que
Je me permet d'affirmer que t'es un con. Relis ce que j'ai écrit.
Donc ils vont supporter deux noyaux pour une version...
On croit rèver. Ça sera peut-être fait temporairement (le temps que les gens s'y préparent).
Le "Lenny et demi" (avec Linux 2.6.30 (ou plus)) est justement car le team noyau ne pourra pas supporter longtemps le 2.6.26.
J'ai vu ça dans une discussion "2.6.26 vs 2.6.27" sur debian-kernel pour Lenny. En effet, le 2.6.27 sera supporté plus longtemps par l'upstream contrairement au 2.6.26. Le problème était de savoir s'il fallait prendre un 2.6.26 ou 2.6.27. Il a été dit qu'il n'y avait pas de problème avec le 2.6.26 car Lenny passera à un 2.6.30 (ou plus).
Notons que c'est quelque chose que Debian fait pour Linux (et Debian a raison de le faire) mais n'envisage pas de faire pour Firefox... D'un côté on cherche des solutions, de l'autre s'il y a des problèmes on s'en frotte les mains et on ne rate pas l'occasion de dire qu'il y a problème.
Ben c'est grosso-modo la position de Linux...
Dans Linux les patch soit-disant uniquement de sécurité ne sont pas indiqués précisement et c'est presque fait exprès. En effet, Linux (ses développeurs) trouvent qu'il est insuffisant de ne prendre que les patchs de sécurité et qu'il faut tout prendre.
> Par exemple, pour le noyau, la mise à jour de sécu consiste en un commit git qu'il suffit de backporter.
Erreur. Parfois ça marche, parfois pas, parfois c'est pire.
> Sid est loin d'être aussi bleeding-edge que la dernière Fedora [...] ... elle est aussi infiniment moins buguée.
Gardons l'idée globale et oublions le "infiniment".
T'as raison. C'est un compromis, Fedora en est un autre.
Je n'ai pas dit que Debian testing/unstable était mauvais pour Grégory SCHMITT, mais qu'il ne faut réver. Il n'y aura jamais de bleeding-edge avec peu de bug.
A lui de tester et voir si ça lui convient.
> mais c'est plus une vitrine qu'autre chose
La "vitrine" je l'utilise tous les jours et depuis FC1. C'est plus qu'une vitrine. Sinon je vais aussi dire que testing/unstable est une vitrine.
> C'est "mignon" de FUDer
Mais t'as superbement fuder. Quelques échantillons :
- "elle[debian] est aussi infiniment moins buguée."
- "Au pire, en utilisant Sid, tu auras toujours bien moins de problèmes que sous Fedora"
- "mais c'est [fedora] plus une vitrine qu'autre chose"
- "Fedora (à la limite de l'utilisable, et pas souvent du bon côté)."
Malheureusement, la règle de sécurité des développeurs amont est de demander aux utilisateurs de mettre à jour avec les nouvelles versions amont, ce qui entre en conflit avec la règle de Debian de ne pas fournir de changements fonctionnels importants dans les mises à jour de sécurité.
Idem pour OOo, Linux, etc.
Attardons nous sur Linux. Par "chance", pour Etch Linux 2.4 est livré mais non supporté... Donc Debian peut livrer quelque chose et ne pas le supporter. Par chance encore, Etch a été fournit avec Linux 2.6.18 et Red Hat y fait le gros de la maintenance (ce noyau n'étant plus supporté par l'upstream). Novell fait le gros de la maintenant pour 2.6.9 je crois.
Ici le projet upstream Linux fait comme Mozilla. Mais pas un mot ni de caca nerveux de la part de Debian...
Lenny sort avec un 2.6.24. Est-il supporté par upstream ? Peut-être aujourd'hui mais pas pour longtemps. Il y a-t-il d'autres distributions majeures qui utilisent un 2.6.24 afin que Lenny s'y appuit ? Je ne crois pas.
Debian pourra-t-il supporter un 2.6.24 pour 3 ans (grosso-modo la durée de vie d'une Debian). J'en doute et pas un mot dans la note de mise à jour.
Est-ce que KDE va supporter la branche 3.5 pour encore 3 ans ? J'en doute grave. Il me semble que KDE 3.5.10 est la dernière version 3.5.
Nous ne pouvons pas le prédire aujourd'hui, mais il se peut que pendant la durée de vie d'lenny, l'équipe de sécurité de Debian arrive à un point où la prise en charge des produits Mozilla ne soit plus possible et qu'elle annonce alors la fin de la prise en charge de sécurité pour les produits Mozilla.
Marrant, il avait été dit que Debian virait les marques afin de pouvoir sortir des correctifs de sécurité...
Vous devriez prendre cela en compte lors du déploiement de Mozilla et considérer des alternatives dans Debian si l'absence de prise en charge de sécurité vous poserait problème.
Idem pour d'autres projets.
Notons que Debian préfère ne plus fournir Firefox/etc au-lieux de fournir une mise à jour. Ce qui va arriver, est que beaucoup d'utilisateur de FirefoxIceweasel vont utiliser une version avec des failles de sécurité sans que Debian se sorte les doigts du cul.
En fait, pensez à changer de distribution pour une qui assume (et ne laisse pas ses utilisateurs avec un navigateur buggué) et ne s'en prend pas bêtement par rancoeur à Mozilla.
> faut lui adjoindre un paquet de trucs en plus quand même.
Mouaif. Si c'est seulement pour faire des couches au-dessus d'autres couches.
Une bonne librairie C++ (par exemple pour accéder à une base de donnée) doit être utilisable avec Qt ou Gtk+. Si ce n'est pas le cas, alors il y a un truc qui sucks (et c'est peut-être la librairie graphique...).
En passant, c'est aussi ce que j'aime dans gtkmm. Il y n'a pas gtkmm-xml, on utilise libxml, etc.
> Tout dépend de l'ambition de ton programme.
Rien à voir. Firefox utilise Gtk. Serait-il mieux avec Qt ? Rien ne le dit. Rien ne dit le contraire non plus.
> J'ai l'impression Python + Qt4 c'est un peu la solution choisie par beaucoup de gens en ce moment.
Mouaif. On peut dire de même pour Python + Gtk+.
En passant, j'ai programmé en Qt (C++). Excellent.
Dernièrement pour un projet je ne pouvais pas utiliser Qt (alors que c'est à lui que j'ai pensé en premier). J'ai regardé du côté de Gtkmm et ce dernier n'a pratiquement rien à envier à Qt et est même plus élégant/propre pour certains aspects.
Qt a pratiquement toujours été la référence pour développer en C++. Mais c'est à réviser car gtkmm est vraiment bon (NB: je ne dis pas meilleur !).
Si je dois utiliser python, j'y regarderai à deux fois avant de choisir entre Qt ou Gtk comme toolkit graphique.
> La particularité de VB était d'embarquer un interface de construction d'interface
Pas vraiment. L'intégration de VB dans les outils de développement est bien foutu (grace à la technologie en dessous (activeX)).
Il y a VB le language et VB l'IDE. Les deux ont le même nom.
On peut aussi construire graphiquement des interfaces avec python (du moins avec un bon IDE).
Si on met de côté la qualité des languages, l'intégration de VB est bien meilleur.
Il n'empêche que Python est très utilisé. De plus, c'est un assez vieux language et donc il a passé les effets de mode. Niveau utilisation "sérieuse", Python ne doit pas dépasser C/C++ et ces derniers restent les préférés des (vrais) hackers. Python est le "Visual Basic" de GNU/Linux :-)
> Donc la volonté d'un gouvernement de s'affranchir de logiciels privateurs étrangers est une mesure nationaliste.
Quand il n'y avait que Red Hat aux USA, c'était une distribution avec des visées nationalistes ?
Imaginons que c'est cas, ça change quoi ?
Prendre du logiciel libre pour faire une politique nationnalisme n'est pas pratique.
La nationalisme c'est surtout croire en sa propre nation et considérer les autres comme ennemies. Si les Russes étaient vraiment nationnalistes dans ce domaine, ils feraient tout eux même au lieux de prendre un produit "mondial" (fait par d'autres nations ennemies). Croire en un produit mondial n'est vraiment pas du nationalisme. Accèpter l'échange que permet le logiciel libre n'est vraiment pas du nationalisme. etc.
KVM est trop récent pour avoir du support, certification, etc.
Mais il y a un gros boulot sur KVM actuellement pour l'amener au niveau de Xen et évidemment le dépasser (sinon pourquoi passer à KVM).
Qui fournit du support pour Xen ?
- Xensource
- Red Hat
- Novell
- etc
Presque tout le monde en fait.
Pour KVM rien ou presque. Mais comme Red Hat abandonne Xen, il faudra bien que Red Hat supporte KVM rapidement. Puis, ou en même temps, Novell, IBM, etc.
Maintenant ce n'est presque qu'une question de temps.
Presque rien à voir pour moi par rapport aux commentaires précédents. Mes besoins sont faibles.
J'utilise la virtualisation pour le développement. Pour la production c'est "remonté" sur EC2 d'Amazon. Une CentOS et une Fedora actuellement.
Par contre, je ne fais pas une machine virtuelle par service. Si tout tient sur un serveur et que c'est cohérent, je n'utilise qu'un serveur. Sur un serveur il peut y avoir (et il y a) web, base de donnée, DNS, mail, etc. Nb: SeLinux est activé sur mes machines virtuelles ce qui limite les risques lorsqu'on a plusieurs services sur une même machine. Les backups sont sur S3 d'amazon (qui offre une (haute) garantit de service ; idem pour EC2 depuis quelques semaines).
Notons que sur EC2 on paye par machine virtuelle. C'est aussi pour ça que je ne multiple pas les machines virtuelles. La creation d'une machine virtuelle plus la restauration des données se fait en 1 heure environ. On a donc une très bonne disponibilité. Si un serveur plante (à cause des disques ; nb: on peut faire du raid) l'indisponibilité n'est que d'une heure.
L'intérêt :
- souplesse (on peut créer autant de machines qu'on veut dans la minute)
- la puissance de calcul fournie n'est pas partagée (donc le service n'est pas ralentit par d'autres machines virtuelles).
- l'administration. On peut presque dire qu'il n'y en a pas. Pas besoin d'acheter un serveur, des disques, de trouver de la place, de s'occuper du réseau, etc.
Je ne dis pas que c'est mieux, mais c'est une autre approche qui a ses atouts. En fait ici on se fout de la virtualisation :-) On a un service.
Pour info, EC2 utilise Xen.
S'il faut chercher un point faible, c'est l'installation de l'OS. En effet, on ne peut pas installer l'OS sur EC2. C'est un petit problème. Je l'installe sur une machine virtuelle de ma bécane de développement puis je remonte sur EC2.
EC2 est beaucoup utilisé en cluster (montée en charge) et c'est surtout son domaine d'utilisation.
Fedora a décidé d'abondonné Xen depuis assez longtemps : http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Xen aurait dû être viré pour F9, mais KVM n'était pas encore satisfaisant pour le remplacer et donc Xen était encore dans F9. Mais maintenant il n'est pas dans F10 et ne sera pas dans les distributions suivantes.
Concertant RHEL/CentOS, la prochaine RHEL (la 6) n'aura pas Xen.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -1.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Parfois c'est le cas. Mais ce n'est pas toujours le cas et c'est fait exprès.
> concernant une mise à jour de sécurité (1.0.4 -> 1.0.5) :
Arrêtes les conneries, Mozilla a aussi un cvs et le passage de 1.0.4 à 1.0.5 n'a pas été fait avec un commit.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 2.
s/5.1/5.0.1
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 2.
T'as remarqué ?
J'ai uniquement parlé de Lenny-and-a-half et principalement du noyau.
T'as remarqué ?
En passant le noyau supporté par Etch est et reste le 2.6.18 (le 2.6.24 n'a pas Xen par exemple).
Pour Lenny ce n'est pas ce qui a été dit (je n'ai pas envis de fouiller les archives).
Lenny-and-a-half sera probablement Debian 5.1 (Lenny + 1 sera Debian 6.0). Etch-and-a-half est "seulement" 4.0-r4 (si j'ai bonne mémoire).
> http://www.debian.org/releases/etch/etchnhalf
- [...] 2.6.24 kernel, nor that all software included in etch will work correctly with the newer kernel.
- Not all features of the etch 2.6.18 kernel are available in the 2.6.24 images, this includes the Xen and linux virtual server flavors.
[...]
- Out-of-tree kernel module source packages that were provided in etch are not guaranteed to function properly with the 2.6.24 kernel.
Ce 2.6.24 est vraiment optionnel... On ne peut parler de mise à jour.
Celui de Lenny ne le sera pas. C'est ce que j'ai lu.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -7.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -3.
>
> Pas à un seul moment.
Rires.
> 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).
Admettons. Il n'empêche que t'es complètement à côté de la plaque.
Tu peux faire le "mignon" avec tes "Debian est infiniment moins buggé", mais c'est le moins qu'on puisse demander à Debian.
Idem, RHEL est moins buggué que Fedora. Mais c'est le moins qu'on puisse demander à RHEL. Et si RHEL est moins buggé, c'est grace à Fedora.
En phase de développement, Fedora prend ce qui merde encore et *DOIT* être corrigé/développé car c'est l'avenir (au lieu d'attendre d'indéfininement que d'autres le fassent). RHEL et Debian prend ce qui marche et corrige les deux ou trucs qui restent à corriger. La démarche n'a rien à voir.
Ce n'est pas l'un est mieux et l'autre est mal, c'est complémentaire, les deux ont raisons, les deux sont des compromis différents.
> 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...
Mais oui...
Regarde les forums Debian, on ne compte pas les "ça merde avec SID" et les "on t'avait prévenu"...
> Fedora et Experimental se valent
Il y a tous les derniers patch pour KVM (par exemple pour avoir Dom0 de Xen mais sans Xen) dans Experimental ?
Est-ce que Xenner est fonctionnel dans Experimental de Debian ? En tout cas il l'est dans F10.
Il y a un support correcte de SeLinux dans Experimental et pas seulement un "CONFIG_SECURITY_SELINUX=y" dans /boot/config ?
Pourtant ça fait des plombes que Debian bosse sur Selinux...
Si tu prends la branche de développement de Fedora (Rawhide), c'est beaucoup plus expérimental que Experimental de Debian.
Dans Rawhide ext4 est par défaut ? Est-ce le cas de Experimental de Debian ?
Biensûr que non.
Il y a maintenant gcc 4.4 dans Rawhide et tout va être recompiler avec ce dernier dans la semaine à venir. Quand Debian fera ça ? Quand Fedora et gcc aura bien débuggué gcc...
Etc.
> soit tu ne l'as jamais utilisée
Je ne l'ai jamais utilisée et n'est jamais dit le contraire.
> soit tu FUDes.
Je n'ai pas dit que l'un était pire que l'autre (par contre toi tu le dis) mais que le compromis est différent (Fedora est plus agressif et notamment pour Rawhide si tu veux comparer à Sid). Après à chaqu'un de voir ce qui lui convient.
J'ai Fedora chez moi, pourfois ça merde, mais globalement j'aime le compromis.
En passant, j'utilise ext4 (il est proposé à l'installation dans F10). Quel est le niveau de support d'ext4 dans Debian ? Probablement pas du niveau de Fedora. Normal, Debian est plus "frileux" que Fedora. A tord à raison ? Je m'en torche le fions.
> Évidemment, je connais ton passif, et ta manière de défendre ta chapelle, qu'on l'attaque ou pas
Toi on n'attaque pas ta chapelle et tu te répands en connerie et mensonges.
> je me permets très clairement d'affirmer que
Je me permet d'affirmer que t'es un con. Relis ce que j'ai écrit.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 0.
On croit rèver. Ça sera peut-être fait temporairement (le temps que les gens s'y préparent).
Le "Lenny et demi" (avec Linux 2.6.30 (ou plus)) est justement car le team noyau ne pourra pas supporter longtemps le 2.6.26.
J'ai vu ça dans une discussion "2.6.26 vs 2.6.27" sur debian-kernel pour Lenny. En effet, le 2.6.27 sera supporté plus longtemps par l'upstream contrairement au 2.6.26. Le problème était de savoir s'il fallait prendre un 2.6.26 ou 2.6.27. Il a été dit qu'il n'y avait pas de problème avec le 2.6.26 car Lenny passera à un 2.6.30 (ou plus).
Notons que c'est quelque chose que Debian fait pour Linux (et Debian a raison de le faire) mais n'envisage pas de faire pour Firefox... D'un côté on cherche des solutions, de l'autre s'il y a des problèmes on s'en frotte les mains et on ne rate pas l'occasion de dire qu'il y a problème.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 1.
Dans Linux les patch soit-disant uniquement de sécurité ne sont pas indiqués précisement et c'est presque fait exprès. En effet, Linux (ses développeurs) trouvent qu'il est insuffisant de ne prendre que les patchs de sécurité et qu'il faut tout prendre.
> Par exemple, pour le noyau, la mise à jour de sécu consiste en un commit git qu'il suffit de backporter.
Erreur. Parfois ça marche, parfois pas, parfois c'est pire.
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 0.
> * Pour Ooo l'upstream collabore avec Debian pour les mises à jour de sécurité (si si).
Le monde est sauvé. Red Hat et Novell n'arrivent pas à le faire (ils montent en version) mais Debian y arrive...
[^] # Re: Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -6.
Pourquoi tant de panique ?
J'oubliais, Debian à une image de pure et dure à défendre.
Sinon t'as raison, je me suis trompé (pour ce point).
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 7.
Gardons l'idée globale et oublions le "infiniment".
T'as raison. C'est un compromis, Fedora en est un autre.
Je n'ai pas dit que Debian testing/unstable était mauvais pour Grégory SCHMITT, mais qu'il ne faut réver. Il n'y aura jamais de bleeding-edge avec peu de bug.
A lui de tester et voir si ça lui convient.
> mais c'est plus une vitrine qu'autre chose
La "vitrine" je l'utilise tous les jours et depuis FC1. C'est plus qu'une vitrine. Sinon je vais aussi dire que testing/unstable est une vitrine.
> C'est "mignon" de FUDer
Mais t'as superbement fuder. Quelques échantillons :
- "elle[debian] est aussi infiniment moins buguée."
- "Au pire, en utilisant Sid, tu auras toujours bien moins de problèmes que sous Fedora"
- "mais c'est [fedora] plus une vitrine qu'autre chose"
- "Fedora (à la limite de l'utilisable, et pas souvent du bon côté)."
Bravo. J'ai du boulot pour te concurrencer.
[^] # Re: Je me lance ou pas? (et ce n'est pas un troll)
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 0.
Ben oui. Et il y a maintenant FF 3, OOo 3, les derniers drivers Wifi, etc dans la 5.3.
RHEL 6 pourrait sortir en 2010.
> oui, PulseAudio, je pense à toi
PulseAudio doit être dans Lenny, si je ne me trompe pas.
> Est-ce que je peux intégrer des technologies instables issues de Sid dans Lenny sans me casser la figure à chaque fois?
Tu auras au moins autant de problème que sous Fedora...
A toi de voir.
# Note de mise à jour un peu dégueulasse avec Mozilla
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à -10.
Malheureusement, la règle de sécurité des développeurs amont est de demander aux utilisateurs de mettre à jour avec les nouvelles versions amont, ce qui entre en conflit avec la règle de Debian de ne pas fournir de changements fonctionnels importants dans les mises à jour de sécurité.
Idem pour OOo, Linux, etc.
Attardons nous sur Linux. Par "chance", pour Etch Linux 2.4 est livré mais non supporté... Donc Debian peut livrer quelque chose et ne pas le supporter. Par chance encore, Etch a été fournit avec Linux 2.6.18 et Red Hat y fait le gros de la maintenance (ce noyau n'étant plus supporté par l'upstream). Novell fait le gros de la maintenant pour 2.6.9 je crois.
Ici le projet upstream Linux fait comme Mozilla. Mais pas un mot ni de caca nerveux de la part de Debian...
Lenny sort avec un 2.6.24. Est-il supporté par upstream ? Peut-être aujourd'hui mais pas pour longtemps. Il y a-t-il d'autres distributions majeures qui utilisent un 2.6.24 afin que Lenny s'y appuit ? Je ne crois pas.
Debian pourra-t-il supporter un 2.6.24 pour 3 ans (grosso-modo la durée de vie d'une Debian). J'en doute et pas un mot dans la note de mise à jour.
Est-ce que KDE va supporter la branche 3.5 pour encore 3 ans ? J'en doute grave. Il me semble que KDE 3.5.10 est la dernière version 3.5.
Nous ne pouvons pas le prédire aujourd'hui, mais il se peut que pendant la durée de vie d'lenny, l'équipe de sécurité de Debian arrive à un point où la prise en charge des produits Mozilla ne soit plus possible et qu'elle annonce alors la fin de la prise en charge de sécurité pour les produits Mozilla.
Marrant, il avait été dit que Debian virait les marques afin de pouvoir sortir des correctifs de sécurité...
Vous devriez prendre cela en compte lors du déploiement de Mozilla et considérer des alternatives dans Debian si l'absence de prise en charge de sécurité vous poserait problème.
Idem pour d'autres projets.
Notons que Debian préfère ne plus fournir Firefox/etc au-lieux de fournir une mise à jour. Ce qui va arriver, est que beaucoup d'utilisateur de FirefoxIceweasel vont utiliser une version avec des failles de sécurité sans que Debian se sorte les doigts du cul.
En fait, pensez à changer de distribution pour une qui assume (et ne laisse pas ses utilisateurs avec un navigateur buggué) et ne s'en prend pas bêtement par rancoeur à Mozilla.
[^] # Re: ENFIN ...
Posté par IsNotGood . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 10.
[^] # Re: pourquoi j'ai choisi python...
Posté par IsNotGood . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 3.
Mouaif. Si c'est seulement pour faire des couches au-dessus d'autres couches.
Une bonne librairie C++ (par exemple pour accéder à une base de donnée) doit être utilisable avec Qt ou Gtk+. Si ce n'est pas le cas, alors il y a un truc qui sucks (et c'est peut-être la librairie graphique...).
En passant, c'est aussi ce que j'aime dans gtkmm. Il y n'a pas gtkmm-xml, on utilise libxml, etc.
> Tout dépend de l'ambition de ton programme.
Rien à voir. Firefox utilise Gtk. Serait-il mieux avec Qt ? Rien ne le dit. Rien ne dit le contraire non plus.
[^] # Re: pourquoi j'ai choisi python...
Posté par IsNotGood . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à -1.
Mouaif. On peut dire de même pour Python + Gtk+.
En passant, j'ai programmé en Qt (C++). Excellent.
Dernièrement pour un projet je ne pouvais pas utiliser Qt (alors que c'est à lui que j'ai pensé en premier). J'ai regardé du côté de Gtkmm et ce dernier n'a pratiquement rien à envier à Qt et est même plus élégant/propre pour certains aspects.
Qt a pratiquement toujours été la référence pour développer en C++. Mais c'est à réviser car gtkmm est vraiment bon (NB: je ne dis pas meilleur !).
Si je dois utiliser python, j'y regarderai à deux fois avant de choisir entre Qt ou Gtk comme toolkit graphique.
[^] # Re: bonheur
Posté par IsNotGood . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 3.
T'as raison.
> La particularité de VB était d'embarquer un interface de construction d'interface
Pas vraiment. L'intégration de VB dans les outils de développement est bien foutu (grace à la technologie en dessous (activeX)).
Il y a VB le language et VB l'IDE. Les deux ont le même nom.
On peut aussi construire graphiquement des interfaces avec python (du moins avec un bon IDE).
Si on met de côté la qualité des languages, l'intégration de VB est bien meilleur.
[^] # Re: Sécurité
Posté par IsNotGood . En réponse au journal Debian Lenny 5.0 is out !. Évalué à 10.
J'aimerais que tu m'expliques le problème...
[^] # Re: bonheur
Posté par IsNotGood . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 1.
Pour le "Visual", un exemple pour python est Glade.
[^] # Re: bonheur
Posté par IsNotGood . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 2.
Sinon tu as raison, ce journal est naze.
PS: je n'utilise pas Python.
[^] # Re: grrrr
Posté par IsNotGood . En réponse au journal concours de spots publicitaires pour linux. Évalué à 1.
- Gentoo - 4 Go - PIV 3 Ghz - 2.6.26.6-mm-rc3
[^] # Re: Pas que ça me dérange ...
Posté par IsNotGood . En réponse au journal L'OS national russe pourrait être basé sur Fedora. Évalué à 2.
Quand il n'y avait que Red Hat aux USA, c'était une distribution avec des visées nationalistes ?
Imaginons que c'est cas, ça change quoi ?
Prendre du logiciel libre pour faire une politique nationnalisme n'est pas pratique.
La nationalisme c'est surtout croire en sa propre nation et considérer les autres comme ennemies. Si les Russes étaient vraiment nationnalistes dans ce domaine, ils feraient tout eux même au lieux de prendre un produit "mondial" (fait par d'autres nations ennemies). Croire en un produit mondial n'est vraiment pas du nationalisme. Accèpter l'échange que permet le logiciel libre n'est vraiment pas du nationalisme. etc.
# Re:
Posté par IsNotGood . En réponse au journal concours de spots publicitaires pour linux. Évalué à 2.
L'autre jour je dis à quelqu'un :
- Je suis Linux.
- Donnez moi un Vista. Vite !
[^] # Re: plop
Posté par IsNotGood . En réponse au journal La virtualisation en production. Évalué à 3.
Mais il y a un gros boulot sur KVM actuellement pour l'amener au niveau de Xen et évidemment le dépasser (sinon pourquoi passer à KVM).
Qui fournit du support pour Xen ?
- Xensource
- Red Hat
- Novell
- etc
Presque tout le monde en fait.
Pour KVM rien ou presque. Mais comme Red Hat abandonne Xen, il faudra bien que Red Hat supporte KVM rapidement. Puis, ou en même temps, Novell, IBM, etc.
Maintenant ce n'est presque qu'une question de temps.
> On ne peut pas dire "VMWare" c'est proprio
On peut le dire. VMWare est proprio.
# Presque rien à voir
Posté par IsNotGood . En réponse au journal La virtualisation en production. Évalué à 3.
J'utilise la virtualisation pour le développement. Pour la production c'est "remonté" sur EC2 d'Amazon. Une CentOS et une Fedora actuellement.
Par contre, je ne fais pas une machine virtuelle par service. Si tout tient sur un serveur et que c'est cohérent, je n'utilise qu'un serveur. Sur un serveur il peut y avoir (et il y a) web, base de donnée, DNS, mail, etc. Nb: SeLinux est activé sur mes machines virtuelles ce qui limite les risques lorsqu'on a plusieurs services sur une même machine. Les backups sont sur S3 d'amazon (qui offre une (haute) garantit de service ; idem pour EC2 depuis quelques semaines).
Notons que sur EC2 on paye par machine virtuelle. C'est aussi pour ça que je ne multiple pas les machines virtuelles. La creation d'une machine virtuelle plus la restauration des données se fait en 1 heure environ. On a donc une très bonne disponibilité. Si un serveur plante (à cause des disques ; nb: on peut faire du raid) l'indisponibilité n'est que d'une heure.
L'intérêt :
- souplesse (on peut créer autant de machines qu'on veut dans la minute)
- la puissance de calcul fournie n'est pas partagée (donc le service n'est pas ralentit par d'autres machines virtuelles).
- l'administration. On peut presque dire qu'il n'y en a pas. Pas besoin d'acheter un serveur, des disques, de trouver de la place, de s'occuper du réseau, etc.
Je ne dis pas que c'est mieux, mais c'est une autre approche qui a ses atouts. En fait ici on se fout de la virtualisation :-) On a un service.
Pour info, EC2 utilise Xen.
S'il faut chercher un point faible, c'est l'installation de l'OS. En effet, on ne peut pas installer l'OS sur EC2. C'est un petit problème. Je l'installe sur une machine virtuelle de ma bécane de développement puis je remonte sur EC2.
EC2 est beaucoup utilisé en cluster (montée en charge) et c'est surtout son domaine d'utilisation.
[^] # Re: Université Rennes 2
Posté par IsNotGood . En réponse au journal La virtualisation en production. Évalué à 3.
Fedora a décidé d'abondonné Xen depuis assez longtemps :
http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Xen aurait dû être viré pour F9, mais KVM n'était pas encore satisfaisant pour le remplacer et donc Xen était encore dans F9. Mais maintenant il n'est pas dans F10 et ne sera pas dans les distributions suivantes.
Concertant RHEL/CentOS, la prochaine RHEL (la 6) n'aura pas Xen.