> mature : adj. (1945, "mûr", "posé, censé", v. 1240; lat. maturus "mûr")
Donc KDE 3.5 serait "posé, censé" et KDE 4 serait folle dingue.
Pourquoi s'obstiner à utilser "mature" alors qu'il y a d'autres mots en français, d'autres expressions, largement plus répendus et mieux compris.
- KDE 3.5 est plus abouti pour une majorité d'utilisateur.
- KDE 3.5 a la finition qu'attent une majorité d'utilisateur.
etc...
- Le jeune KDE 4 est prometteur mais aujourd'hui n'est pas assez abouti ou complet pour satisfaire une majorité d'utilisateur.
- Le jeunesse [*] de KDE 4 ne lui permet pas de prétendre à une large adoption par les utilisateurs.
[*] jeunesse c'est plus joli qu'immaturité. Il y a des adulte qui sont immatures, qui ont un comportement immature. Mature c'est pour les fruits et légumes.
KDE serait un fruit ou un légume ?
KDE 3.5 une patate bientôt pourri ?
Bref : Je ne supporte pas l'usage récent et débile de "mature" !
> Coder quelque chose sans garder en tête que des codeurs extérieurs pourront contribuer, ya mieux.
Je ne comprend pas bien.
Novell n'a pas l'habitude être très ouvert aux contributions externes si c'est ce que tu veux dire. M'enfin, mieux vaut ce driver en libre, même si développé de façon un peu fermé, que pas de driver libre.
> Mais tu ne réponds pas à mes autres remarques...
J'avoue que je n'ai pas tout lu la première fois :-)
J'en avait marre de des critiques à 2 sous.
Si tu veux dire que ça pourrait être mieux, je suis d'accord. AIGLX a ausi été créé car le comportenant de Novell avec GLX en avait énervé quelqu'uns.
M'enfin, radeonhd, c'est du code, c'est de la doc. Si Novell n'est pas plus "open", il y aura un fork. Et ATI ne va pas s'en plaindre.
On peut toujours chipoter, mais les faits sont là, on a un driver libre qui avance.
Je dis ça, je dis rien, mais je n'aime pas Novell (depuis l'accord avec MS, Icaza qui n'arrête pas de tailler des pipes à MS, etc).
Mais ce n'est pas une raison pour "cracher" sur le boulot fait sur radeonhd.
> De plus, yum peut simuler le comportement de apt en ne téléchargeant pas à chaque fois les metadonnées (Cf man yum, les options makecache et -C).
C'est beaucoup mieux que ça.
S'il n'y a pas "-C", yum vérifie seulement si le dépôt a été mis à jours (downloade d'un petit fichier de 2k). Il downloade plus de 2k que si c'est nécessaire. Il downloade filelists.xml.gz que si c'est nécessaire par exemple (quand une dépendance a par exemple "Require: /usr/bin/toto").
> Aujourd'hui, mon yum n'est pas tellement plus lent que apt/dpkg sur une Ubuntu.
Yum est lent ?
Dans l'absolu non. Relativement à apt et peut-être smart, yum est plus lent.
Mais yum marche superbement. C'est ce qui compte pour moi. Et en passant, rpm roxe aussi.
Juste quelques tests :
[root@trois big_fs]# yum update
fedora 100% |=========================| 2.1 kB 00:00
livna 100% |=========================| 2.1 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
Setting up Update Process
No Packages marked for Update NB: Au-dessus, yum a downloadé que repomd.xml (généralement moins de 2 ko). C'est repomd.xml qui lui indique si le cache est à jour. Ici le cache est à jour, il ne download rien d'autre.
Pour ce cas, si j'avais fait "yum -C update" ça n'aurait économisé que 6 ko ! Mais j'aurais perdu l'assurance d'être synchro avec le dépôt. L'intérêt est donc quasi nulle pour une utilisation classique. Ne pas utiliser "-C" coute peu et est plus fiable (si le dépôt est mise à jours et que ton cache n'est pas synchro avec le dépôt, il y a de grandes chances que ça plante).
real 0m11.170s user 0m6.932s
sys 0m0.864s
[root@trois big_fs]# yum clean all
Cleaning up Everything
[root@trois big_fs]# time yum update
fedora 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 5.8 MB 00:00
livna 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 173 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
primary.sqlite.bz2 100% |=========================| 1.8 MB 00:00
Setting up Update Process
No Packages marked for Update
real 0m3.854s user 0m2.904s
sys 0m0.291s Notons bien que "yum update" a moins downloadé que "yum makecache" qui renseigne totalement le cache de yum
[root@trois big_fs]#
C'est largement assez rapide pour moi.
Et notes bien comme Yum pour "yum update" n'a récupéré que le nécessaire pour son boulot.
> Au niveau des mises à jours, c'est non seulement plus rapide et plus économe en bande passante.
Si tu as une bonne bande passante, ce n'est pas plus rapide. Mais dans 99,99 % ça sera plus rapide (et dramatiquement plus rapide lorsque OOo est mise à jours :-)).
Autre aspect, yum-updatesd. yum-updatesd vérifie périodiquement s'il y a des mises à jours. Donc le cache est généralement déjà renseigné lorsque l'utilisateur lance yum ou autre qui utilise yum. La durée du cache est configurable. Option metadata_expire de /etc/yum.conf. Valeur à 1800 (c-à-d 30 minute) par défaut chez Fedora.
Exemple
[root@trois big_fs]# yum clean all
Cleaning up Everything
[root@trois big_fs]# yum update
fedora 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 5.8 MB 00:00
livna 100% |=========================| 2.1 kB 00:00
primary.sqlite.bz2 100% |=========================| 173 kB 00:00
updates 100% |=========================| 1.9 kB 00:00
primary.sqlite.bz2 100% |=========================| 1.8 MB 00:00
Setting up Update Process
No Packages marked for Update
[root@trois big_fs]# yum update Rien est downloadé
Setting up Update Process
No Packages marked for Update
[root@trois big_fs]#
Au second "yum update", rien est downloadé (le cache est considéré valide car j'ai (paramétrage par défaut de Fedora) "metadata_expire = 1800".
Bref, au-delà de la lenteur relative, yum roxe des ours, yum est particulièrement bien conçu.
PS : deb et apt roxent peut-être aussi (je n'en sais rien). Mais je ne vais pas vomir sur ces derniers car je trouves que rpm et yum roxent.
> Gstreamer devait resoudre tous les problemes de sons sous linux bon maintenant ca va etre pulseaudio et apres?
Gstreamer n'a jamais été un serveur de son. Gstreamer n'a jamais voulu être un serveur de son. Il y a toujours eu esd ou arts ou dmix etc avec Gstreamer. Aujourd'hui c'est Gstreamer avec Pulseaudio. Gstreamer ne remplacera jamais Pulseaudio et Pulseaudio ne remplacera jamais Gstreamer.
Gstreamer n'a jamais prétendu résoudre tous les problèmes. C'est une méthode de FUD classique que tu emplois. Tu dis qu'un projet promet beaucoup (ce qui est faut) et après tu affiches ta décèption car il ne fait pas ce que tu dit qu'il promet.
Soit "gentil", donne une page de la doc de gstreamer qui dit que gstreamer a pour objectif de faire aussi serveur de son. Tu ne trouveras pas.
C'est actuellement "seulement" plus 18 000 lignes de code. En C et vu la complexité, faire ça en 3 ou 4 mois c'est TRÈS BIEN.
Soit 300 lignes par jours ouvrés. Pas seulement des petits patchs de 4 lignes.
> N'est-il pas bien plus compliqué de coder ce qui reste à coder ?
Oui. D'ailleurs j'ai toujours dit que c'était une début et la route est longue. Mais pour 2009, ça sera un driver très intéressant et le libre aura fait un joli un pas en avant.
> Et pour la nommer 1.0 dès le départ faut faire du marketing.
Faut vraiment être un casse couille pour s'attarder sur ce détail.
OK, 1.0 c'est mal choisi. Mais les développeurs (ou l'équipe marketing qui n'existe pas) dit explicitement que c'est un début, qu'actuellement c'est principalement pour les développeurs/testerus.
M'enfin, t'as décidé de n'écouter que l'équipe marketing (qui n'existe pas).
> Et il confirme où que "2008 ne sera pas une grande année pour l'adoption de KDE" ?
Ne ne le confirme pas, c'est une de mes prédictions 2008. C'est en fin 2008 qu'on pourra le cnfirmer (et peut-être aussi se foutre de ma gueule :-)). http://linuxfr.org/~IsNotGood/25915.html
Il sortira quand ?
Dans 7 ou 9 mois probablement.
Sera-t-il dispo dans une KUbuntu ou Fedora ou ... de cette année ? Pas sûr, mais pas du tout impossible. Si KDE s'y prend bien, il sera dans la KUbuntu 08??, dans F10 et aussi OpenSuse ??.?. M'enfin, ces distributions sortiront en octobre-novembre. Il ne restera moins 25 % de l'année.
Présent.
J'ai dit que KDE 4.0 ne sortirait pas en 2007.
OK, j'ai eu de la chance.
Et que 2008 ne sera pas une grande année pour l'adoption de KDE même avec l'arrivée de KDE 4.0. Ce que confirme Aaron Seigo. Si je le dis, je suis linché, mais si c'est lui, ça roule. Va comprendre...
> il faut plusieurs becanes avec la bdd, et plusieurs machines qui livrent, et plusieurs machines qui traitent.
De façon général/idéal, c'est bien.
Mais maintenant on peut avoir des quadri-coeur pour pas cher et avec des performances redoutables...
On trouve même des quadri quatri-coeur AMD avec une tenue en charge fabuleuse.
Avec PostgreSQL qui tient bien la charge, pour le mettre à genoux il faut un gros gros succès. Cerise sur le gâteau, tu peux mettre ta base de donnée (du moins les parties les plus utilisées et qui n'ont pas besoin d'être conservée de façon permanente comme les donnés de session) en mémoire vive (tmpfs). Dans ce cas il faut vraiment un truc de malade pour mettre à genoux le serveur.
NB : un bon paramétrage de PosgreSQL peut être aussi efficace que l'utilisation de tmpfs.
Pour ce qui bouffe le plus de cpu, c'est-à-dire la génération des pages html, tu peux mettre en oeuvre plusieurs bécanes très facile si la base de donnée est commune. Le goulot d'étranglement est évidemment la base de donnée, mais tu as de la marge.
Ce que je veux dire, c'est qu'avec la méthode "traditionnelle" (un server de base de données commun et plusieurs serveurs pour les pages html dynamiques) tu couvres au moins 99,99 % des besoins.
Pour aller "s'emmerder" avec Ror, MemCache et tout ça, il faut avoir des besoins très très très spéciques.
> cf toute la litérature sur Internet et autre presse spécialisée 2006/2007
Je comprend que le buzz t'ait tapé sur le sysème :-)
Moi c'est le buzz autour de KDE 4 qui m'a tapé sur les nerfs :-)
> Encore une fois, sur le papier, c'est vraiment bien.
Mais ici on parle d'un truc concrêt, utilisé. Ce n'est pas du vaporware ou autre, ce n'est pas que sur le papier.
> Le VMotion de VMWare est un produitfantastique (migration de VM sans reboot/arrêt de service, volontaire ou en cas du panne du serveur physique, avec répartition en fonction de la charge du reste de ta ferme de serveurst).
Juste car on est sur linuxfr, je signale que Linux le fait aussi (probable que VMWare a deux ou trois trucs de plus).
> Maintenant, pour avoir éprouvé en production, que ce soit de la création de service directement sur une plateforme virtuelle, ou de la migration, il y a énormément de problèmes qui seront sans aucun doute réglé dans un futur proche.
Red Hat a fait une offre début 2007 seulement ! Ce n'est pas pour dire que Red Hat est génial, mais seulement qu'il propose une technologie que lorsqu'elle est prête pour la production. Et notons bien que Red Hat est un contributeur majeur à la virtualisation de Linux. Son expertise peut difficilement être remise en cause.
Red Hat a aussi sorti RHEL 5.1 vers novembre 2007 qui est une mise à jour (avec ajout de grosse fonctionnalité) majeur de la virtualisation de RHEL 5.
Tout ceci est donc très récent.
Il ne faut pas confondre ce que fait une distribution communautaire (par exemple Fedora). Fedora c'est excellent technologiquement. J'adore cette distribution, je l'utilise. Le boulot réalisé y est fabuleux. Mais si on veut quelque chose pour la production, pour un serveur critique, il faut prendre une RHEL (ou un clone gratuit pour ceux qui n'ont pas tune, ou n'importe quoi de "sérieux" et dédié entreprise).
Mon choix n'est pas définitif, mais je vais très probablement prendre du EC2. La distribution sera CentOS 5.1. Si ça roule, je passe à RHEL (l'offre commerciale spécifique EC2). Ceci histoire d'avoir l'esprit un peu plus tranquille et donner un peu de tune à Red Hat pour tout son excellent boulot dans le libre.
> Il y a des travaux en cours sur Smolt pour noter le hardware et y ajouter des commentaires.
Comme la fait remarquer GeneralZod, on peut déjà noter le hardware.
On peut aussi faire un commentaire. Il suffit d'aller sur la page de la machine. Pour chaque périphérique il y a une url vers un wiki. Si aucun commentaire n'a été fait, il suffit de créer la page du wiki.
Ou plus simplement récupérer le uuid dans /etc/sysconfig/hw-uuid et le rentrer dans http://smolts.org/ .
Ou encore faire : $ firefox "http://smolts.org/show?UUID=`cat /etc/sysconfig/hw-uuid`" &
> Il semblerait que ni PHP ni Ruby ni Python, out of the box ne permettent de batir des architectures scalables...
Mouaif...
Es-ce à php etc de le faire ?
Pour la tenue en charge, il suffit d'une base de donnée sur une bécane et plusieurs bécanes qui génèrent les pages html via php.
C'est très utilisé et ça marche très bien.
> Smolt permet déjà de noter son hardware, suffit d'aller sur la page perso de ta machine ;-)
Ben merde alors.
Voila qui est fait :-)
Pour trouver l'adresse de la page machine (et pas forcément perso car on peut avoir plusieurs machines :-)) il suffit d'installer smolt-gui puis lancer smoltGui. Il y a probablement d'autres méthodes, mais c'est ce que j'ai fait.
> Je sais que pas mal de contributeurs à d'autres distributions passent dans le coin, je voulais juste transmettre le message
Note les "petites" différences avec http://hardware4linux.info/ .
* Smolt utilise les infos fournies par HAL
* Smolt ne permet pas de noter le hardware
* Smolt s'utilise les doigts dans le nez
Il y a des travaux en cours sur Smolt pour noter le hardware et y ajouter des commentaires.
Le quel des deux est le meilleur ?
Pas évident.
Faites l'effort d'utiliser l'un ou l'autre et idéalement les deux.
> Mais t'as pas compris... Le serveur dédié c'est complètement has been....
Qui dit ça ?
Il a juste été dit que le prix des solutions qui utilisent la virtualisation est avantageux vu les prestations et que ça présente plus de souplesse (ce qui peut être très discutable au cas par cas).
> Maintenant, pour avoir mis en prod de la virtualisation (Xen ou VMWare, même combat)
Ben avec amazon EC2, tu ne mets pas en prod la virtualisation, c'est amazon qui s'en occupe. Toi tu utilises des machines "virtuelles".
> Pourquoi MySQL consomme 100% de CPU
> Sans compter les derniers exploits
Si tu veux du bétonné, tu peux prendre du RHEL qui a du support pour EC2 (avec le catalogue des plus de 2000 applis de RHEL certifié pour EC2, etc). Oui, il faut payer (autour de 20 $ / mois je crois).
Il est un peu stupide d'opposer virtualisation et serveur dédié. Je voulais un serveur dédié (c'est un petit site, assez peu de donné, mais j'ai besoin de beaucoup de souplesse entre autre dans ce que j'installe et configure).
Si t'es un adèpte des serveurs dédiés, tu seras quasiment dans ton jardin avec la virtualisation (et vice versa). La virtualisation de amazon EC2 doit être vue comme des serveurs dédiés (tu as ton cpu, ta mémoire, tes disques, ton OS, tes applis, etc) mais en host invité.
Le point faible de la virtualisation, c'est que tu dépends de celui qui l'a met en oeuvre. Si les serveurs amazon plantent, t'es dans la merde.
Il ne faut d'autant plus ne pas opposer les deux, que tu as été séduit par la virtualisation :-)
Mais t'as été déçu.
> je préfère attendre....
Notes bien que amazon EC2 et RHEL pour EC2 sont actuellement en "limited public beta".
> je préfère attendre.... et rester has been avec toi :)
Tu n'es pas un has been.
Éclate toi avec des serveurs dédiés.
Ça marche ? Tu obtiens ce que tu espères ? Le client est content ? Si c'est le cas, il n'y a rien à redire.
> C'est quand même plus sûr de faire des back-ups vers S3
D'autant que tu peux arrêter ton instance EC2 si tu n'en as pas besoin. Par exemple en phase de développement. Et à la création de l'instance tu récupères ce qui va bien sur S3.
> Mais c'est surtout avec un cluster que AWS prend tout son intérêt
Je n'ai pas l'intention de faire un cluster, mais c'est très intéressant même si on ne veut pas faire de cluster.
Pour les backups, direction S3. S3 fait la redondance et il y a une garantit. Si tu as 2 Go de backup (ce qui est raisonnable pour un petit site et bien supérieur à mes besoins) ça te coûte 3$ / mois.
Tu peux faire tes backups aussi régulièrement que tu veux, ça ne te coute rien (transfert gratuit entre EC2 et S3).
T'as vraiment le choix de l'OS (sauf Windows, mais qui ça dérange :-)), tu peux en changer sans risque (sans téléphoner au support s'il y a un pépin, ou te déplacer, etc). En gros tu crée une nouvelle instance, tu testes, et si ça marche tu détruis l'ancienne.
Si tu as un problème avec une instance (par exemple avec un disque dur ou des choses "bizarres"), tu l'as détruit et tu en crées une nouvelle.
Il y a un souplesse fabuleuse même si on ne veut pas faire de cluster. On peut trouver moins cher, mais ça sera moins souple. Le prix est donc très raisonnable.
J'ai deux petits repproches.
Je trouve l'instance EC2 de base luxueuse. 1,7 Go de mémoire vive (c'est énorme) et 160 Go d'espace disque. La très grande majorité des sites n'a pas besoin de ça.
Pour l'anectode, mon premier site web "professionnel" (dynamique, session, etc mais pas de payement) tournait sur une bécane avec 24 Mo !
EC2 c'est luxueux, mais on peut utiliser une instance EC2 pour y mettre plusieurs site web, un svn, etc. Je ne vais pas m'en priver.L'autre reproche, est qu'il n'y a pas de EC2 en Europe (alors qu'il y a S3 en Europe ; notons que les transfert entre EC2 et S3 Europe sont payants).
> Par défaut non, mais il y a toutes les solutions qui tu peux imaginer pour brancher un truc par le réseau: NFS, partition simulée qui enregistrent sur S3
Ne le prend pas de façon personnel, j'ai du mal a croire qu'un reboot (et pas seulement l'arrêt d'une instance de machine virtuelle) supprime toutes les données.
Red Hat, évidemment, est très soucieux de la sécurité (au moins pour son image ont va dire en étant mauvaise langue). Il est hors de question pour Red Hat de laisser un noyau avec un trou de sécurité (le noyau de la machine virtuelle est sujet aux trous de sécurité aussi). Donc il faut pouvoir rebooter. Mais si rebooter c'est perdre ses données (coordonnées clients, etc), la configuration, etc ce n'est obsolument pas cool. Et j'ai du mal à imaginer toutes les protestations que va recevoir Red Hat si par malheur un noyau reboote à cause d'un bug de Red Hat (ce qui peut arriver à tout le monde).
NB: je ne sais plus où j'ai lu ça, mais les images AMI de RHEL (qui sont payantes) utilisent le noyau RHEL et non celui d'amazon (qui doit être un 2.6.16 je crois).
De plus Red Hat va vendre des applis via rhn. Si à chaque reboot (plantage, mise à jour de sécurité, etc), il faut repasser par le case commande, etc...
Désolé, mais j'ai des difficultés à croire qu'un reboot supprime tout. Ceci dit, je n'apporte pas la preuve du contraire et si j'utilise EC2 que ferais très attention à ça.
> les données se trouvent sur un serveur de bases de données qui est distinct.
Juste. Mais une seconde machine pour la base de données, c'est luxueux dans certains cas. De plus, si on suit ton raisonnement, cette seconde machine ne peut-être une EC2 :-)
> Ne pas avoir de données stockées localement est de toutes façons nécessaire si on veut avoir un cluster de serveurs web.
Oui. Je ne suis pas dans ce cas.
> Pour ma part, j'ai pris une Dapper
Je vais aller vers RHEL ou Centos. Je fais (ou vais faire) un truc pour longtemps. Cool, il y a des images AMI Centos aussi.
> (*) J'oubliait, autre problème avec EC2: quand on lance une nouvelle machine, elle a une IP attribuée dynamiquement.
Ce qui me parait tout à fait normal.
En passant, c'est hyper intéressant Amazon Web Service. Je sens que je vais en devenir dingue.
[^] # Re: RRrrrrr
Posté par IsNotGood . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 2.
Donc KDE 3.5 serait "posé, censé" et KDE 4 serait folle dingue.
Pourquoi s'obstiner à utilser "mature" alors qu'il y a d'autres mots en français, d'autres expressions, largement plus répendus et mieux compris.
- KDE 3.5 est plus abouti pour une majorité d'utilisateur.
- KDE 3.5 a la finition qu'attent une majorité d'utilisateur.
etc...
- Le jeune KDE 4 est prometteur mais aujourd'hui n'est pas assez abouti ou complet pour satisfaire une majorité d'utilisateur.
- Le jeunesse [*] de KDE 4 ne lui permet pas de prétendre à une large adoption par les utilisateurs.
[*] jeunesse c'est plus joli qu'immaturité. Il y a des adulte qui sont immatures, qui ont un comportement immature. Mature c'est pour les fruits et légumes.
KDE serait un fruit ou un légume ?
KDE 3.5 une patate bientôt pourri ?
Bref : Je ne supporte pas l'usage récent et débile de "mature" !
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Pas à un des tiens sauf pour "J'en avait marre de des critiques à 2 sous.".
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Je ne comprend pas bien.
Novell n'a pas l'habitude être très ouvert aux contributions externes si c'est ce que tu veux dire. M'enfin, mieux vaut ce driver en libre, même si développé de façon un peu fermé, que pas de driver libre.
> Mais tu ne réponds pas à mes autres remarques...
J'avoue que je n'ai pas tout lu la première fois :-)
J'en avait marre de des critiques à 2 sous.
Si tu veux dire que ça pourrait être mieux, je suis d'accord. AIGLX a ausi été créé car le comportenant de Novell avec GLX en avait énervé quelqu'uns.
M'enfin, radeonhd, c'est du code, c'est de la doc. Si Novell n'est pas plus "open", il y aura un fork. Et ATI ne va pas s'en plaindre.
On peut toujours chipoter, mais les faits sont là, on a un driver libre qui avance.
Je dis ça, je dis rien, mais je n'aime pas Novell (depuis l'accord avec MS, Icaza qui n'arrête pas de tailler des pipes à MS, etc).
Mais ce n'est pas une raison pour "cracher" sur le boulot fait sur radeonhd.
[^] # Re: Fin du FUD deb/rpm
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
C'est beaucoup mieux que ça.
S'il n'y a pas "-C", yum vérifie seulement si le dépôt a été mis à jours (downloade d'un petit fichier de 2k). Il downloade plus de 2k que si c'est nécessaire. Il downloade filelists.xml.gz que si c'est nécessaire par exemple (quand une dépendance a par exemple "Require: /usr/bin/toto").
> Aujourd'hui, mon yum n'est pas tellement plus lent que apt/dpkg sur une Ubuntu.
Yum est lent ?
Dans l'absolu non. Relativement à apt et peut-être smart, yum est plus lent.
Mais yum marche superbement. C'est ce qui compte pour moi. Et en passant, rpm roxe aussi.
Juste quelques tests :
C'est largement assez rapide pour moi.
Et notes bien comme Yum pour "yum update" n'a récupéré que le nécessaire pour son boulot.
> Au niveau des mises à jours, c'est non seulement plus rapide et plus économe en bande passante.
Si tu as une bonne bande passante, ce n'est pas plus rapide. Mais dans 99,99 % ça sera plus rapide (et dramatiquement plus rapide lorsque OOo est mise à jours :-)).
Autre aspect, yum-updatesd. yum-updatesd vérifie périodiquement s'il y a des mises à jours. Donc le cache est généralement déjà renseigné lorsque l'utilisateur lance yum ou autre qui utilise yum. La durée du cache est configurable. Option metadata_expire de /etc/yum.conf. Valeur à 1800 (c-à-d 30 minute) par défaut chez Fedora.
Exemple
Au second "yum update", rien est downloadé (le cache est considéré valide car j'ai (paramétrage par défaut de Fedora) "metadata_expire = 1800".
Bref, au-delà de la lenteur relative, yum roxe des ours, yum est particulièrement bien conçu.
PS : deb et apt roxent peut-être aussi (je n'en sais rien). Mais je ne vais pas vomir sur ces derniers car je trouves que rpm et yum roxent.
[^] # Re: KDE4
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Gstreamer n'a jamais été un serveur de son. Gstreamer n'a jamais voulu être un serveur de son. Il y a toujours eu esd ou arts ou dmix etc avec Gstreamer. Aujourd'hui c'est Gstreamer avec Pulseaudio. Gstreamer ne remplacera jamais Pulseaudio et Pulseaudio ne remplacera jamais Gstreamer.
Gstreamer n'a jamais prétendu résoudre tous les problèmes. C'est une méthode de FUD classique que tu emplois. Tu dis qu'un projet promet beaucoup (ce qui est faut) et après tu affiches ta décèption car il ne fait pas ce que tu dit qu'il promet.
Soit "gentil", donne une page de la doc de gstreamer qui dit que gstreamer a pour objectif de faire aussi serveur de son. Tu ne trouveras pas.
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Soit 300 lignes par jours ouvrés. Pas seulement des petits patchs de 4 lignes.
> N'est-il pas bien plus compliqué de coder ce qui reste à coder ?
Oui. D'ailleurs j'ai toujours dit que c'était une début et la route est longue. Mais pour 2009, ça sera un driver très intéressant et le libre aura fait un joli un pas en avant.
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Pour info, le driver est développé par ATI et Novell (pas Fedora).
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Il a été ajouter à la version 1.1.0 qui est sortie il y a quelques jours.
Oui, c'est 1.1.0, et ce n'est pas complet. Fais ton caca.
Ne vous déplaisent, le développement du driver avance super vite.
[^] # Re: Bullshits !
Posté par IsNotGood . En réponse au journal Mes prédictions pour 2008. Évalué à 1.
Faut vraiment être un casse couille pour s'attarder sur ce détail.
OK, 1.0 c'est mal choisi. Mais les développeurs (ou l'équipe marketing qui n'existe pas) dit explicitement que c'est un début, qu'actuellement c'est principalement pour les développeurs/testerus.
M'enfin, t'as décidé de n'écouter que l'équipe marketing (qui n'existe pas).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Ne ne le confirme pas, c'est une de mes prédictions 2008. C'est en fin 2008 qu'on pourra le cnfirmer (et peut-être aussi se foutre de ma gueule :-)).
http://linuxfr.org/~IsNotGood/25915.html
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Il sortira quand ?
Dans 7 ou 9 mois probablement.
Sera-t-il dispo dans une KUbuntu ou Fedora ou ... de cette année ? Pas sûr, mais pas du tout impossible. Si KDE s'y prend bien, il sera dans la KUbuntu 08??, dans F10 et aussi OpenSuse ??.?. M'enfin, ces distributions sortiront en octobre-novembre. Il ne restera moins 25 % de l'année.
# Re:
Posté par IsNotGood . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Présent.
J'ai dit que KDE 4.0 ne sortirait pas en 2007.
OK, j'ai eu de la chance.
Et que 2008 ne sera pas une grande année pour l'adoption de KDE même avec l'arrivée de KDE 4.0. Ce que confirme Aaron Seigo. Si je le dis, je suis linché, mais si c'est lui, ça roule. Va comprendre...
# RRrrrrr
Posté par IsNotGood . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
> la branche KDE 4.0 n'est pas encore jugée assez stable ou mature
KDE 4.0 immature ?
Utilisez "abouti" ou "prêt' que "mature" venu d'un usage de l'anglais et qui est dans 99 % des cas mal utilisé.
"la branche KDE 4.0 n'est pas encore jugée assez aboutie/prête pour remplacer une installation KDE 3.5 'en production'.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
J'ai lu ça :
http://www.redhat.com/f/pdf/EC2GettingStarted.pdf
Ben pour changer de noyau, il faut une autre image AMI. Donc un reboot n'est pas suffisant.
La balle est au centre.
[^] # Re: Tenue en charge
Posté par IsNotGood . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 0.
De façon général/idéal, c'est bien.
Mais maintenant on peut avoir des quadri-coeur pour pas cher et avec des performances redoutables...
On trouve même des quadri quatri-coeur AMD avec une tenue en charge fabuleuse.
Avec PostgreSQL qui tient bien la charge, pour le mettre à genoux il faut un gros gros succès. Cerise sur le gâteau, tu peux mettre ta base de donnée (du moins les parties les plus utilisées et qui n'ont pas besoin d'être conservée de façon permanente comme les donnés de session) en mémoire vive (tmpfs). Dans ce cas il faut vraiment un truc de malade pour mettre à genoux le serveur.
NB : un bon paramétrage de PosgreSQL peut être aussi efficace que l'utilisation de tmpfs.
Pour ce qui bouffe le plus de cpu, c'est-à-dire la génération des pages html, tu peux mettre en oeuvre plusieurs bécanes très facile si la base de donnée est commune. Le goulot d'étranglement est évidemment la base de donnée, mais tu as de la marge.
Ce que je veux dire, c'est qu'avec la méthode "traditionnelle" (un server de base de données commun et plusieurs serveurs pour les pages html dynamiques) tu couvres au moins 99,99 % des besoins.
Pour aller "s'emmerder" avec Ror, MemCache et tout ça, il faut avoir des besoins très très très spéciques.
[^] # Re: présent !
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
Je comprend que le buzz t'ait tapé sur le sysème :-)
Moi c'est le buzz autour de KDE 4 qui m'a tapé sur les nerfs :-)
> Encore une fois, sur le papier, c'est vraiment bien.
Mais ici on parle d'un truc concrêt, utilisé. Ce n'est pas du vaporware ou autre, ce n'est pas que sur le papier.
> Le VMotion de VMWare est un produitfantastique (migration de VM sans reboot/arrêt de service, volontaire ou en cas du panne du serveur physique, avec répartition en fonction de la charge du reste de ta ferme de serveurst).
Juste car on est sur linuxfr, je signale que Linux le fait aussi (probable que VMWare a deux ou trois trucs de plus).
> Maintenant, pour avoir éprouvé en production, que ce soit de la création de service directement sur une plateforme virtuelle, ou de la migration, il y a énormément de problèmes qui seront sans aucun doute réglé dans un futur proche.
Red Hat a fait une offre début 2007 seulement ! Ce n'est pas pour dire que Red Hat est génial, mais seulement qu'il propose une technologie que lorsqu'elle est prête pour la production. Et notons bien que Red Hat est un contributeur majeur à la virtualisation de Linux. Son expertise peut difficilement être remise en cause.
Red Hat a aussi sorti RHEL 5.1 vers novembre 2007 qui est une mise à jour (avec ajout de grosse fonctionnalité) majeur de la virtualisation de RHEL 5.
Tout ceci est donc très récent.
Il ne faut pas confondre ce que fait une distribution communautaire (par exemple Fedora). Fedora c'est excellent technologiquement. J'adore cette distribution, je l'utilise. Le boulot réalisé y est fabuleux. Mais si on veut quelque chose pour la production, pour un serveur critique, il faut prendre une RHEL (ou un clone gratuit pour ceux qui n'ont pas tune, ou n'importe quoi de "sérieux" et dédié entreprise).
Mon choix n'est pas définitif, mais je vais très probablement prendre du EC2. La distribution sera CentOS 5.1. Si ça roule, je passe à RHEL (l'offre commerciale spécifique EC2). Ceci histoire d'avoir l'esprit un peu plus tranquille et donner un peu de tune à Red Hat pour tout son excellent boulot dans le libre.
[^] # Re: Join smolts.org
Posté par IsNotGood . En réponse au journal architectures et kernels sur hardware4linux.info. Évalué à 1.
Comme la fait remarquer GeneralZod, on peut déjà noter le hardware.
On peut aussi faire un commentaire. Il suffit d'aller sur la page de la machine. Pour chaque périphérique il y a une url vers un wiki. Si aucun commentaire n'a été fait, il suffit de créer la page du wiki.
[^] # Re: Join smolts.org
Posté par IsNotGood . En réponse au journal architectures et kernels sur hardware4linux.info. Évalué à 1.
Ou plus simplement récupérer le uuid dans /etc/sysconfig/hw-uuid et le rentrer dans http://smolts.org/ .
Ou encore faire :
$ firefox "http://smolts.org/show?UUID=`cat /etc/sysconfig/hw-uuid`" &
# Tenue en charge
Posté par IsNotGood . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 2.
Mouaif...
Es-ce à php etc de le faire ?
Pour la tenue en charge, il suffit d'une base de donnée sur une bécane et plusieurs bécanes qui génèrent les pages html via php.
C'est très utilisé et ça marche très bien.
[^] # Re: Join smolts.org
Posté par IsNotGood . En réponse au journal architectures et kernels sur hardware4linux.info. Évalué à 1.
Ben merde alors.
Voila qui est fait :-)
Pour trouver l'adresse de la page machine (et pas forcément perso car on peut avoir plusieurs machines :-)) il suffit d'installer smolt-gui puis lancer smoltGui. Il y a probablement d'autres méthodes, mais c'est ce que j'ai fait.
> Je sais que pas mal de contributeurs à d'autres distributions passent dans le coin, je voulais juste transmettre le message
Tu as bien fait.
[^] # Re: Join smolts.org
Posté par IsNotGood . En réponse au journal architectures et kernels sur hardware4linux.info. Évalué à 1.
* Smolt utilise les infos fournies par HAL
* Smolt ne permet pas de noter le hardware
* Smolt s'utilise les doigts dans le nez
Il y a des travaux en cours sur Smolt pour noter le hardware et y ajouter des commentaires.
Le quel des deux est le meilleur ?
Pas évident.
Faites l'effort d'utiliser l'un ou l'autre et idéalement les deux.
[^] # Re: présent !
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
Qui dit ça ?
Il a juste été dit que le prix des solutions qui utilisent la virtualisation est avantageux vu les prestations et que ça présente plus de souplesse (ce qui peut être très discutable au cas par cas).
> Maintenant, pour avoir mis en prod de la virtualisation (Xen ou VMWare, même combat)
Ben avec amazon EC2, tu ne mets pas en prod la virtualisation, c'est amazon qui s'en occupe. Toi tu utilises des machines "virtuelles".
> Pourquoi MySQL consomme 100% de CPU
> Sans compter les derniers exploits
Si tu veux du bétonné, tu peux prendre du RHEL qui a du support pour EC2 (avec le catalogue des plus de 2000 applis de RHEL certifié pour EC2, etc). Oui, il faut payer (autour de 20 $ / mois je crois).
Il est un peu stupide d'opposer virtualisation et serveur dédié. Je voulais un serveur dédié (c'est un petit site, assez peu de donné, mais j'ai besoin de beaucoup de souplesse entre autre dans ce que j'installe et configure).
Si t'es un adèpte des serveurs dédiés, tu seras quasiment dans ton jardin avec la virtualisation (et vice versa). La virtualisation de amazon EC2 doit être vue comme des serveurs dédiés (tu as ton cpu, ta mémoire, tes disques, ton OS, tes applis, etc) mais en host invité.
Le point faible de la virtualisation, c'est que tu dépends de celui qui l'a met en oeuvre. Si les serveurs amazon plantent, t'es dans la merde.
Il ne faut d'autant plus ne pas opposer les deux, que tu as été séduit par la virtualisation :-)
Mais t'as été déçu.
> je préfère attendre....
Notes bien que amazon EC2 et RHEL pour EC2 sont actuellement en "limited public beta".
> je préfère attendre.... et rester has been avec toi :)
Tu n'es pas un has been.
Éclate toi avec des serveurs dédiés.
Ça marche ? Tu obtiens ce que tu espères ? Le client est content ? Si c'est le cas, il n'y a rien à redire.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
D'autant que tu peux arrêter ton instance EC2 si tu n'en as pas besoin. Par exemple en phase de développement. Et à la création de l'instance tu récupères ce qui va bien sur S3.
> Mais c'est surtout avec un cluster que AWS prend tout son intérêt
Je n'ai pas l'intention de faire un cluster, mais c'est très intéressant même si on ne veut pas faire de cluster.
Pour les backups, direction S3. S3 fait la redondance et il y a une garantit. Si tu as 2 Go de backup (ce qui est raisonnable pour un petit site et bien supérieur à mes besoins) ça te coûte 3$ / mois.
Tu peux faire tes backups aussi régulièrement que tu veux, ça ne te coute rien (transfert gratuit entre EC2 et S3).
T'as vraiment le choix de l'OS (sauf Windows, mais qui ça dérange :-)), tu peux en changer sans risque (sans téléphoner au support s'il y a un pépin, ou te déplacer, etc). En gros tu crée une nouvelle instance, tu testes, et si ça marche tu détruis l'ancienne.
Si tu as un problème avec une instance (par exemple avec un disque dur ou des choses "bizarres"), tu l'as détruit et tu en crées une nouvelle.
Il y a un souplesse fabuleuse même si on ne veut pas faire de cluster. On peut trouver moins cher, mais ça sera moins souple. Le prix est donc très raisonnable.
J'ai deux petits repproches.
Je trouve l'instance EC2 de base luxueuse. 1,7 Go de mémoire vive (c'est énorme) et 160 Go d'espace disque. La très grande majorité des sites n'a pas besoin de ça.
Pour l'anectode, mon premier site web "professionnel" (dynamique, session, etc mais pas de payement) tournait sur une bécane avec 24 Mo !
EC2 c'est luxueux, mais on peut utiliser une instance EC2 pour y mettre plusieurs site web, un svn, etc. Je ne vais pas m'en priver.L'autre reproche, est qu'il n'y a pas de EC2 en Europe (alors qu'il y a S3 en Europe ; notons que les transfert entre EC2 et S3 Europe sont payants).
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
Pour information :
http://code.google.com/p/s3fs/ (GPL v2)
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Amazon EC2. Évalué à 1.
> Les deux, en fait.
Ne le prend pas de façon personnel, j'ai du mal a croire qu'un reboot (et pas seulement l'arrêt d'une instance de machine virtuelle) supprime toutes les données.
Par exemple Red Hat va proposer EC2 :
http://www.redhat.com/solutions/cloud/
Red Hat, évidemment, est très soucieux de la sécurité (au moins pour son image ont va dire en étant mauvaise langue). Il est hors de question pour Red Hat de laisser un noyau avec un trou de sécurité (le noyau de la machine virtuelle est sujet aux trous de sécurité aussi). Donc il faut pouvoir rebooter. Mais si rebooter c'est perdre ses données (coordonnées clients, etc), la configuration, etc ce n'est obsolument pas cool. Et j'ai du mal à imaginer toutes les protestations que va recevoir Red Hat si par malheur un noyau reboote à cause d'un bug de Red Hat (ce qui peut arriver à tout le monde).
NB: je ne sais plus où j'ai lu ça, mais les images AMI de RHEL (qui sont payantes) utilisent le noyau RHEL et non celui d'amazon (qui doit être un 2.6.16 je crois).
De plus Red Hat va vendre des applis via rhn. Si à chaque reboot (plantage, mise à jour de sécurité, etc), il faut repasser par le case commande, etc...
Désolé, mais j'ai des difficultés à croire qu'un reboot supprime tout. Ceci dit, je n'apporte pas la preuve du contraire et si j'utilise EC2 que ferais très attention à ça.
> les données se trouvent sur un serveur de bases de données qui est distinct.
Juste. Mais une seconde machine pour la base de données, c'est luxueux dans certains cas. De plus, si on suit ton raisonnement, cette seconde machine ne peut-être une EC2 :-)
> Ne pas avoir de données stockées localement est de toutes façons nécessaire si on veut avoir un cluster de serveurs web.
Oui. Je ne suis pas dans ce cas.
> Pour ma part, j'ai pris une Dapper
Je vais aller vers RHEL ou Centos. Je fais (ou vais faire) un truc pour longtemps. Cool, il y a des images AMI Centos aussi.
> (*) J'oubliait, autre problème avec EC2: quand on lance une nouvelle machine, elle a une IP attribuée dynamiquement.
Ce qui me parait tout à fait normal.
En passant, c'est hyper intéressant Amazon Web Service. Je sens que je vais en devenir dingue.