Pour launchpad, la partie client est libérée au fur et à mesure, selon le bon vouloir de Canonical. Vraisemblablement ils auraient déjà donné la partie gestion linguistique à Gnome...
A mon avis, faut pas trop compter sur une libération prochaine de la partie serveur, le but pour Canonical étant de centraliser les données, ils ne semblent pas pressés de voir émerger d'autres points de centralisation...
Je comparais ce qui est comparable: les ssi entre eux. La pagination distante n'est certes pas un nouveau sujet, ce qui est plus nouveau avec kerrighed, c'est une intégration de ce type de technologie au sein d'un ssi (ce qui est tout de même intéressant pour faciliter les migrations de threads et leur communication)
... il ne faut pas confondre les fonctionnalités qui sont dans les objectifs et celles qui sont implémentées à l'heure actuelle.
Par exemple, le système de fichiers distribué (et non centralisé) n'est pas encore de la partie.
Bref, il faut bien faire la distinction entre les objectifs et ce qui est déjà implémenté.
En dehors de ça, de par ses objectifs et les éléments déjà implémentés, kerrighed est de loin le projet le plus prometteur à l'heure actuelle pour la création de clusters de calcules: rien que la gestion au niveau thread plutôt qu'au niveau process représente une grande avancée. Le système de pagination distante de kerrighed est aussi un élément inédit (mais pas encore opérationnel).
... en tout cas pas avant de savoir si cette boîte supporte le NFS, protocole standard de NAS pour Linux... bon, il y a moyen aussi d'utiliser du cifs(smb) façon windows, mais c'est moins performant...
Mais s'il s'agit d'un protocole trafiqué, il faut mieux ne pas utiliser. En l'absence de documentation correcte sur le produit, un seul conseil: ne pas acheter.
T'as pas idee de la difference de vitesse entre le bus memoire d'un mainframe et le backend reseau d'un cluster distribue, ca n'a rien a voir, notamment niveau temps de latence.
Si si, je vois très bien l'abysse de performances entre l'interconnexion d'un mainframe et/ou d'un gros serveur unix genre superdome ou regata et une connexion 4 gigabit pour connecter un gros serveur x86...
Mais là où on a pas la bande passante brute et sans obstacles, on doit avoir une approche plus intelligente (dans le sens qu'on met une gestion des transferts plus structurée, plus proche de la logique applicative, qu'on adapte éventuellement celle-ci si c'est possible)...
Et puis, je parle pas non-plus de faire des clusters avec des petits pc's à base celeron... Pour 1/10è du prix d'un mainframe, on peut acheter une batterie de serveurs très conséquents (p-ex, gros opterons avec 8 dual-cores).
Peut-être google est-il un exemple pas très pertinent par rapport à la réalité d'un mainframe en millieu bancaire, mais d'un autre côté, il est difficile de prétendre que la piste ne mènerait à rien.
Si on regarde attentivement le fonctionnement des logiciels db modernes tournant sur des mini et des mainframes, de nombreux problèmes ont déjà été abordés et adressés: Toute la partie concurrence d'accès existe déjà (un serveur db tournant sur une machine regata est déjà, par la force des choses, obligé à gérer une concurrence d'accès tout en ayant une forte isolation des threads).
On peut aussi adresser la concurrence d'accès du stockage, grâce à des technologies comme lustre, gfs, ...
Un moteur de stockage db multithread intégré à un système de fichier distribué pourrait vraiment offrir des performances sérieuses, y compris pour le milieu bancaire (d'ailleurs les sociétés comme oracle et ibm bossent sérieusement sur ce genre de pistes)
La grosse base de google n'est pas en lecture seule, sinon il ne se mettrait pas à jour...
Maintenant, il est vrai que dans un contexte bancaire, il y a le problème de l'intégrité transactionnelle autrement plus compliqué que dans le cas d'indexation de sites web, mais ce problème n'est pas non-plus insoluble (sinon, on ne pourrait pas mettre de grosses db transactionnelles en clusters, hors je t'assure qu'on le fait)
Le vrai problème des architectures distribuées par rapport aux mainframes est qu'actuellement il n'y a pas de solution clefs-en-main suffisamment éprouvée, mais ça viendra... Kerrighed, par exemple, devient de plus en plus mature et offre des fonctionnalités SSI résolument orientées "mainframe distribué".
Il y a des problemes genre internet search qui s'adaptent tres bien a des clusters distribues du type de celui de Google, et il y a d'autres problemes pour lesquels un systeme distribue causerait un effondrement des performances.
Certainement, il y en a, mais penses-tu que le cas d'une banque soit fondamentalement différent au niveau i/o db qu'un gros système distribué comme google?
Un mainframe n'est _pas_ conçu pour faire du calcul mais de l'I/O
Absolument, je n'ai pas dit le contraire, en i/o pur, ils explosent pas mal de systèmes, mais ils ont aussi leurs limites.
Les paradigmes de stockage distribué comme poussent les possibilités i/o à un niveau supérieur.
En outre, si un mainframe était si génial question i/o/prix dans l'absolu, je pense que Google utiliserait des mainframes au lieu de stockage distribué.
Pour 1% du prix d'un mainframe, il y a déjà moyen de se composer un cluster de calcule assez solide... mais pas assez pour inquièter un gros S/390...
Mais bon, disons que pour 10% du prix d'un mainframe, on bat ce dernier à plates coutures, à condition bien entendu que le logiciel suive (et c'est là que ça devient plus problématique)
Les banques et assurances utilisent des mainframes souvent pour des raisons historiques (porter des millions de lignes en cobol, voir pl/1, vers d'autres langages, ça n'est pas trivial ou bon marché), et aussi parceque ça inspire confiance, que ça coûte très cher (et que donc c'est certainement très bon), que c'est clef en main, , ...
Mais le coût au mips d'un mainframe reste exorbitant et absolument pas compétitif par rapport à un cluster bien pensé.
Je rajouterais même que pour le prix d'un terminal (PC) tu as maintenant un serveur aussi puissant qu'un mainframe :)
Euh... euh... t'as pas du en voir récemment, des mainframes... c'est pas avec un serveur coûtant le prix d'un terminal pc que tu vas mettre la pâté à un mainframe... déjà rien qu'au niveau des vitesses de bus, les pc's n'ont rien de comparable à un mainframe moderne... tu aurais dit "mainframe des années 70", là j'aurais dit "sans problèmes, le pc gagne", mais là ... faut pas déconner.
sous quicktime, oui, sous vlc, non, sans-doutes le système de streaming ou l'encapsulation sont-ils incorrects... ça a pas l'air très pro comme boulot.
Pour l'usure, ça dépend de la fréquence de lecture de tes données...
- si ce sont des données auxquelles tu n'accèdes jamais, la défragmentation aura peu d'intérêt (de même que ça a peu d'intérêt de garder ces données sur le disque dur plutôt que de les archiver)
- si ce sont des données auxquelles tu accèdes fréquemment en lecture, il y a tout intérêt à défragmenter car le coût usure de la défragmentation sera vite compensé par la réduction du coût usure cumulé des accès.
Et puis bon, ça n'empêche pas de prendre des mesures préventives pour réduire la fragmentation.
On ne gère pas les choses correctement en les laissant pourrir ou en sur-réagissant.
bon choix, c'est une très bonne librairie pour faire cela...
une librairie permettant de gérer ce problème à un haut niveau est préférable, ça évite de devoir redévelopper par la suite des éléments tels que le support de proxy, la gestion des sessions, le ssl... et ça permet de se concentrer sur les traitements de l'info...
La fragmentation, ça use les disques plus vite et ça gaspille de l'énergie en augmentant les mouvements des têtes, ... donc il y a plus que des questions de perfs.
Yep, ils sont BEAUCOUP plus open source et BEAUCOUP plus libres que Novell... Autrefois au boulot, on utilisait SuSE, et à chaque fois qu'on demandait des informations de type pre-sales, ils essayaient de fourguer des solutions proprio là où du libre était pourtant possible et viable... D'un autre côté, ils venaient une fois tous les deux mois et offraient de la consultance grâcieusement... et avec redhat, on se sent beaucoup plus seul...
Oracle distribue une version identique à Redhat. Au mieux, les certifications sont transférées directement.
ça, c'est peu réaliste... il n'y a pas de transitivité directe, la certification concerne tant la distribution, c-à-d "ça marche sans problèmes dès maintenant", que la méthodologie de maintenance, c-à-d "ça marchera encore après les mises à jour".
Certains fournisseurs, à la lecture des intentions d'Oracle de faire l'impasse sur les backports de patches sécurité pour favorises les "versions suivantes officielles", ont d'entrée de jeu décidé que ça ne pouvait pas être supporté.
On ne peut certifier une plate-forme où la compatibilité de celle-ci n'est pas garantie sur la durée.
Enfin, j'attends avec impatience la clause "pas de benchmark" de la part d'oracle...
avec redhat 5, on a déjà pas mal d'options qui ont maintenant intégré la distribution et sont maintenant supportées, il y a eu évolution, pas sur le prix, mais sur ce qu'on a pour le prix...
Avant de céder à la panique et de se faire des films catastrophe, il faut bien se rendre compte que
- RedHat a une notoriété dans le monde Linux que Oracle n'a pas.
- RedHat a des certifications que la copie oracle n'a pas non-plus (très important pour les grandes entreprises)
- A court terme, je ne vois pas oracle offrir un support cohérent et suffisamment rassurant pour les entreprise (oracle est un débutant)
- Tant que le linux d'oracle est basé sur redhat, le linux d'oracle ne peut pas faire mieux que celui de redhat question patches, sous peine de s'engager dans des directions nécessitant de faire marche arrière par la suite sous peine de ne plus être compatible, ...
- RedHat est un gigantesque contributeur dans le monde linux, c'est un très gros avantage question maîtrise technologique.
Maintenant, je vais dire qu'en tant que client de redhat, je suis moyennement satisfait de la relation entre mon entreprise et redhat (au niveau technique, pas de reproches, mais au niveau général, c'est plutôt étrange)
Un revendeur qui vend un PC avec linux pré-installé est un concurrent commercial.
Pas forcément, tu peux aussi avoir une relation de partenariat entre le fournisseur hardware et le fournisseur software, c'est même extrêmement recommandé afin d'avoir l'expertise pour avoir la distribution supportant correctement le hardware.
Introduire un nouvel OS dans une offre hard+soft est un gros risque, et une manière de mitiger ce risque pour une boîte comme Dell, c'est justement la de sous-traiter le contrôle qualité, la validation et le support troisième ligne (voir même seconde ligne) chez le fournisseur de l'OS.
(note: je ne peux pas tester la vidéo du lien car je suis au boulot et le rtsp ne passe pas les firewalls externes)
Normalement, les vidéos quicktime diffusées par rtsp sont parfaitement lisibles avec vlc.
En tout cas, dans mon entreprise, on a 6000 postes de travail utilisant vlc pour consulter les vidéos diffusées via Darwin Streaming Server au format container:mp4;video:h264 AVC Main profile;audio:mp4-LC, et ça ne pose pas de problèmes...
C'est aussi pour ça qu'il faut prendre du logiciel libre :-)
Pour info, j'ai terminé les grandes lignes de mon script de téléchargement, il permet de télécharger tous les canaux rhn auquel un serveur rh5 est abonné, séquentiellement, avec contrôle des checksums (je vais envisager la vérification gpg), et sans retélécharger les fichiers déjà présents dans le miroir. Le script utilise les librairies de rhn et de yam.
Je vais en parler avec le tam de rh, et si ça ne pose pas problème, je le partagerai...
[^] # Re: Lunchpad
Posté par ragoutoutou . En réponse à la dépêche Ubuntu 7.04 : le faon est sur ses pattes. Évalué à 7.
A mon avis, faut pas trop compter sur une libération prochaine de la partie serveur, le but pour Canonical étant de centraliser les données, ils ne semblent pas pressés de voir émerger d'autres points de centralisation...
[^] # Re: Un projet prometteur, mais...
Posté par ragoutoutou . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 2.
# Un projet prometteur, mais...
Posté par ragoutoutou . En réponse à la dépêche Avec Kerrighed 2.0.0, Linux a les deux pieds dans le SMP. Évalué à 4.
Par exemple, le système de fichiers distribué (et non centralisé) n'est pas encore de la partie.
Bref, il faut bien faire la distinction entre les objectifs et ce qui est déjà implémenté.
En dehors de ça, de par ses objectifs et les éléments déjà implémentés, kerrighed est de loin le projet le plus prometteur à l'heure actuelle pour la création de clusters de calcules: rien que la gestion au niveau thread plutôt qu'au niveau process représente une grande avancée. Le système de pagination distante de kerrighed est aussi un élément inédit (mais pas encore opérationnel).
On voudrait presque être en décembre 2008...
# Perso, je prendrais pas...
Posté par ragoutoutou . En réponse au message disque dur externe. Évalué à 3.
Mais s'il s'agit d'un protocole trafiqué, il faut mieux ne pas utiliser. En l'absence de documentation correcte sur le produit, un seul conseil: ne pas acheter.
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 2.
Si si, je vois très bien l'abysse de performances entre l'interconnexion d'un mainframe et/ou d'un gros serveur unix genre superdome ou regata et une connexion 4 gigabit pour connecter un gros serveur x86...
Mais là où on a pas la bande passante brute et sans obstacles, on doit avoir une approche plus intelligente (dans le sens qu'on met une gestion des transferts plus structurée, plus proche de la logique applicative, qu'on adapte éventuellement celle-ci si c'est possible)...
Et puis, je parle pas non-plus de faire des clusters avec des petits pc's à base celeron... Pour 1/10è du prix d'un mainframe, on peut acheter une batterie de serveurs très conséquents (p-ex, gros opterons avec 8 dual-cores).
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 2.
Si on regarde attentivement le fonctionnement des logiciels db modernes tournant sur des mini et des mainframes, de nombreux problèmes ont déjà été abordés et adressés: Toute la partie concurrence d'accès existe déjà (un serveur db tournant sur une machine regata est déjà, par la force des choses, obligé à gérer une concurrence d'accès tout en ayant une forte isolation des threads).
On peut aussi adresser la concurrence d'accès du stockage, grâce à des technologies comme lustre, gfs, ...
Un moteur de stockage db multithread intégré à un système de fichier distribué pourrait vraiment offrir des performances sérieuses, y compris pour le milieu bancaire (d'ailleurs les sociétés comme oracle et ibm bossent sérieusement sur ce genre de pistes)
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 2.
Maintenant, il est vrai que dans un contexte bancaire, il y a le problème de l'intégrité transactionnelle autrement plus compliqué que dans le cas d'indexation de sites web, mais ce problème n'est pas non-plus insoluble (sinon, on ne pourrait pas mettre de grosses db transactionnelles en clusters, hors je t'assure qu'on le fait)
Le vrai problème des architectures distribuées par rapport aux mainframes est qu'actuellement il n'y a pas de solution clefs-en-main suffisamment éprouvée, mais ça viendra... Kerrighed, par exemple, devient de plus en plus mature et offre des fonctionnalités SSI résolument orientées "mainframe distribué".
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 1.
Certainement, il y en a, mais penses-tu que le cas d'une banque soit fondamentalement différent au niveau i/o db qu'un gros système distribué comme google?
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 0.
Absolument, je n'ai pas dit le contraire, en i/o pur, ils explosent pas mal de systèmes, mais ils ont aussi leurs limites.
Les paradigmes de stockage distribué comme poussent les possibilités i/o à un niveau supérieur.
En outre, si un mainframe était si génial question i/o/prix dans l'absolu, je pense que Google utiliserait des mainframes au lieu de stockage distribué.
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 3.
Mais bon, disons que pour 10% du prix d'un mainframe, on bat ce dernier à plates coutures, à condition bien entendu que le logiciel suive (et c'est là que ça devient plus problématique)
Les banques et assurances utilisent des mainframes souvent pour des raisons historiques (porter des millions de lignes en cobol, voir pl/1, vers d'autres langages, ça n'est pas trivial ou bon marché), et aussi parceque ça inspire confiance, que ça coûte très cher (et que donc c'est certainement très bon), que c'est clef en main, , ...
Mais le coût au mips d'un mainframe reste exorbitant et absolument pas compétitif par rapport à un cluster bien pensé.
[^] # Re: Témoignage
Posté par ragoutoutou . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 7.
Euh... euh... t'as pas du en voir récemment, des mainframes... c'est pas avec un serveur coûtant le prix d'un terminal pc que tu vas mettre la pâté à un mainframe... déjà rien qu'au niveau des vitesses de bus, les pc's n'ont rien de comparable à un mainframe moderne... tu aurais dit "mainframe des années 70", là j'aurais dit "sans problèmes, le pc gagne", mais là ... faut pas déconner.
# sleep
Posté par ragoutoutou . En réponse au message Script shell et timer. Évalué à 2.
sleep 3
ça fera faire une pause de 3 secondes à ton script
le tout dans une boucle, bien évidemment.
[^] # Re: VLC
Posté par ragoutoutou . En réponse au message Vidéo quicktime par rtsp://. Évalué à 2.
[^] # Re: Un peu vieux...
Posté par ragoutoutou . En réponse au message Obtenir le % de fragmentation d'une partoche ?. Évalué à 2.
- si ce sont des données auxquelles tu n'accèdes jamais, la défragmentation aura peu d'intérêt (de même que ça a peu d'intérêt de garder ces données sur le disque dur plutôt que de les archiver)
- si ce sont des données auxquelles tu accèdes fréquemment en lecture, il y a tout intérêt à défragmenter car le coût usure de la défragmentation sera vite compensé par la réduction du coût usure cumulé des accès.
Et puis bon, ça n'empêche pas de prendre des mesures préventives pour réduire la fragmentation.
On ne gère pas les choses correctement en les laissant pourrir ou en sur-réagissant.
# libcurl
Posté par ragoutoutou . En réponse au message Requêtes http dans un programme en C. Évalué à 5.
une librairie permettant de gérer ce problème à un haut niveau est préférable, ça évite de devoir redévelopper par la suite des éléments tels que le support de proxy, la gestion des sessions, le ssl... et ça permet de se concentrer sur les traitements de l'info...
[^] # Re: Un peu vieux...
Posté par ragoutoutou . En réponse au message Obtenir le % de fragmentation d'une partoche ?. Évalué à 3.
[^] # Re: Libre ?
Posté par ragoutoutou . En réponse à la dépêche Oracle souffle Yahoo à RedHat. Évalué à 3.
[^] # Re: Mauvaise nouvelle
Posté par ragoutoutou . En réponse à la dépêche Oracle souffle Yahoo à RedHat. Évalué à 3.
ça, c'est peu réaliste... il n'y a pas de transitivité directe, la certification concerne tant la distribution, c-à-d "ça marche sans problèmes dès maintenant", que la méthodologie de maintenance, c-à-d "ça marchera encore après les mises à jour".
Certains fournisseurs, à la lecture des intentions d'Oracle de faire l'impasse sur les backports de patches sécurité pour favorises les "versions suivantes officielles", ont d'entrée de jeu décidé que ça ne pouvait pas être supporté.
On ne peut certifier une plate-forme où la compatibilité de celle-ci n'est pas garantie sur la durée.
Enfin, j'attends avec impatience la clause "pas de benchmark" de la part d'oracle...
[^] # Re: Bof ...
Posté par ragoutoutou . En réponse à la dépêche Oracle souffle Yahoo à RedHat. Évalué à 3.
[^] # Re: Mauvaise nouvelle
Posté par ragoutoutou . En réponse à la dépêche Oracle souffle Yahoo à RedHat. Évalué à 6.
- RedHat a une notoriété dans le monde Linux que Oracle n'a pas.
- RedHat a des certifications que la copie oracle n'a pas non-plus (très important pour les grandes entreprises)
- A court terme, je ne vois pas oracle offrir un support cohérent et suffisamment rassurant pour les entreprise (oracle est un débutant)
- Tant que le linux d'oracle est basé sur redhat, le linux d'oracle ne peut pas faire mieux que celui de redhat question patches, sous peine de s'engager dans des directions nécessitant de faire marche arrière par la suite sous peine de ne plus être compatible, ...
- RedHat est un gigantesque contributeur dans le monde linux, c'est un très gros avantage question maîtrise technologique.
Maintenant, je vais dire qu'en tant que client de redhat, je suis moyennement satisfait de la relation entre mon entreprise et redhat (au niveau technique, pas de reproches, mais au niveau général, c'est plutôt étrange)
[^] # Re: A la conquete des Michu
Posté par ragoutoutou . En réponse à la dépêche Pré-installer Linux chez Dell (et ailleurs) : l'avis de Mark Shuttleworth d'Ubuntu. Évalué à 2.
Pas forcément, tu peux aussi avoir une relation de partenariat entre le fournisseur hardware et le fournisseur software, c'est même extrêmement recommandé afin d'avoir l'expertise pour avoir la distribution supportant correctement le hardware.
Introduire un nouvel OS dans une offre hard+soft est un gros risque, et une manière de mitiger ce risque pour une boîte comme Dell, c'est justement la de sous-traiter le contrôle qualité, la validation et le support troisième ligne (voir même seconde ligne) chez le fournisseur de l'OS.
# VLC
Posté par ragoutoutou . En réponse au message Vidéo quicktime par rtsp://. Évalué à 2.
Normalement, les vidéos quicktime diffusées par rtsp sont parfaitement lisibles avec vlc.
En tout cas, dans mon entreprise, on a 6000 postes de travail utilisant vlc pour consulter les vidéos diffusées via Darwin Streaming Server au format container:mp4;video:h264 AVC Main profile;audio:mp4-LC, et ça ne pose pas de problèmes...
mplayer est à oublier pour le rtsp.
[^] # Re: lsof
Posté par ragoutoutou . En réponse au message Surveiller quel prog accède à un fichier. Évalué à 2.
man auditctl
man ausearch
# lsof
Posté par ragoutoutou . En réponse au message Surveiller quel prog accède à un fichier. Évalué à 6.
[^] # Re: Mises à jour... Pire que Microsoft?
Posté par ragoutoutou . En réponse à la dépêche Red Hat lance RHEL 5. Évalué à 2.
Pour info, j'ai terminé les grandes lignes de mon script de téléchargement, il permet de télécharger tous les canaux rhn auquel un serveur rh5 est abonné, séquentiellement, avec contrôle des checksums (je vais envisager la vérification gpg), et sans retélécharger les fichiers déjà présents dans le miroir. Le script utilise les librairies de rhn et de yam.
Je vais en parler avec le tam de rh, et si ça ne pose pas problème, je le partagerai...