A la recherche d'un logiciel métier spécifique, je contacte un petit éditeur français d'une solution serveur intéressante développée en .Net . Discussion classique sur le produit puis:
Moi> le problème, c'est que votre solution tourne uniquement sous windows et mes serveurs sont en linux. Ca m'ennuie.
Lui> Pas de problème. Avec Linux Il y a mono.
Moi> (naif) Ah oui c'est vrai...
1 semaine plus tard :
Moi> (vicieux) Ok pour tester votre solution mais sous linux
Lui> Ah oui, euh, euh... c'est à dire que ... on va certifier la prochaine version, mais actuellement c'est pas le cas. Vous voulez pas essayer en windows?
Finalement, j'ai acheté le produit parce qu'il m'intéressait et j'ai installé un serveur windows (bouh!!!) . Depuis on a essuyé quelques platres et particulièrement des problèmes de perfs. (pas directement liés à .Net). Discussion avec un des développeurs de la société éditrice :
Lui> il faudrait upgrader la version de la librairie AJAX utilisée avec .Net car il y a des bugs et des fuites mémoire. Mais le directeur a les boules car la société créatrice de la librairie en question a augmenté ses tarifs par 3. Et puis, y a pas longtemps on a racheté 10 licences visual studio et c'est pas franchement donné.
Moralité :
1. les grosses applis développées .net ne tournent pas sous mono
2. Mono est utilisé comme argument marketing pour vendre des produits microsoft.
3. L'écosystème .Net est majoritairement closed source et payant
Ma question : les développeurs de mono ont-ils conscience de se faire manipuler par Microsoft ?
Vu que ZFS a été porté sur les noyaux BSD et Mac OS X, ne faudrait-il pas plutôt se poser en sens inverse : pourquoi la license GPL est-elle si stricte qu'il est impossible d'incorporer du code dans le noyau linux alors que c'est possible dans d'autres projets identiques?
Autant je suis assez convaincu des compétences des mathématiciens de la NSA pour trouver des techniques de cryptage/décryptages très performantes, autant je n'ai aucune confiance en eux pour les dévoiler publiquement, car la raison d'être de la NSA est l'espionnage sous toutes ses formes. Dans ce contexte je ne comprends pas comment un organisme internationnal indépendant puisse accepter la sousmission de normes/techniques émanant de la NSA. Par principe, les dés sont pipés.
Evidemment, comme indiqué dans le lien, la dette et les coûts de l'infrastructure ferroviaire ont été transférés à la RFF par un tour de passe-passe. Globalement, l'économie du train est en plein déconfiture. Si chaque client devait assumer le cout réel de son billet, le prix de celui-ci augmenterait d'un facteur 5.
Linux.fr n'est malheureusement plus un espace de dialogue ou de débats. Dès qu'un personne ose émettre une critique (même courtoise ou humoristique) sur la SNCF ou la fonction publique, elle se fait moinser furieusement. Quelle mesquinerie et quel manque de courage faut-il avoir dans ses propres idées pour en arriver là!
... soutenez les personnels en grêve : ils se battent pour que vous puissiez continuer à jouir d'un des meilleurs transports ferroviaires au monde,
Faut arréter d'être naif ou de faire sembant. Les cheminots se battent pour conserver leurs privilèges. (C'est d'ailleurs assez humain). Evidemment pour le grand public, ils préfèrent avancer d'autres arguments.
D'autre part, sur le réseau transilien (où il y a le plus de problème), les infrastructures sont mal (pas) entretenues (c'est RFF qui gère les infrastructures). Et c'est souvent à cause du mauvais état des infrastructures que les retards ont lieu (ou alors à cause d'actes de malveillances). Bref, parmis tous les trains en retard, très peu sont directement imputables à la sncf.
C'est vai. La SNCF loue à la RFF l'usage des voies ferrées mais en revanche effectue leur entretien qui est refacturé à la RFF. Petite originalité du montage: la facturation de l'entretien est supérieur au coût de la location.
Imaginez un proprio qui vous loue un appart moins cher que les charges de fonctionnement qu'il doit payer à la copro. C'est pas beau la vie!
et _PhiX_ , faudrait peut être que tu fasses un tour à Cuba pour découvrir ton paradis. En ce qui me concerne, j'y suis déja allé et je te livre ci-dessous qq conseils et informations.
Avant de partir, pense à prendre quelques Dollars US car c'est la monaie locale... Pour le shopping, sache que même si le choix n'est pas trés large, à la Havane, tu trouveras sans problème la dernière paire de Nike et de téléphone portable motorola. Si tu loues une voiture, je te conseille une Peugeot 307, en revanche n'oublie pas ton GPS car la plupart des panneaux signalétiques ont été enlevés... (en cas de guerre).
N'oublie pas également d'emporter quelques médicaments (antibio, etc.), car par manque de moyen le système de santé est à l'agonie. Cependant si tu as les poches remplies de $$ tu trouveras de bons médecins et des médicaments directement importés des usines US.
Pour accéder l'information, tu ne pourras manquer de lire Granma, l'organe du PC Cubain et l'un des seuls journaux autorisés (le hasard fait bien les choses, non?). Si cette lecture t'ennuie, n'hésite pas à te rabattre sur Juventud Rebelde, le journal de la jeunesse communiste. Rassure-toi, ces journaux ne commettent pas le pêché mortel de critiquer Castro.
Evite de parler de politique au Cubain de la rue, car c'est un être particulièrement timide sur ce sujet. Bois plutot un bon verre de rhum tout en discutant des derniers exploits de son équipe de base ball.
Si tu sens perdu dans la ville, n'hésite pas à frapper à la porte du commissaire politique (il y une maison indiquée dans chaque quartier) pour avoir des renseignements. Ces gens sont trés aimables et particulièrement bien informés de la vie de leurs concitoyens.
Bref, Cuba est le Paradis sur terre. Une dernière preuve: Castro s'y sent tellement bien qu'il garde le pouvoir depuis plus de 45 ans...
...et je rajoute qu'OpenSolaris est bien disponible sous une licence libre CDDL (d'ailleurs partiellement dérivée de la licence MPL). Il s'agit bien d'une licence libre (au sens de la FSF) mais incompatible avec la GPL comme le sont également les licences Apache ou NPL (celle de firexfox) par exemple.
Pour plus d'infomations vous pouvez consulter, sur le site de la FSF, la page trés instructive sur les licences : http://www.fsf.org/licensing/licenses/index_html
Xcircuit est un projet toujours trés actif bien que sa page sur sourceforge date quelque peu. La dernière vesrion est sortie le 10 mars 2006. => http://opencircuitdesign.com/xcircuit/
Il me semble que les processeurs massivement multi-core représentent une alternative trés intéressante à l'offre actuelle. Je les vois bien s'imposer pour les prochaines années dans un certains nombre de domaines (Bases de Données, serveur d'applications, serveur Web, fermes de calculs). Actuellement seul SUN possède une offre (quoique que limitée aux applications peu gourmandes en calcul flottant) dans ce secteur, mais il est trés probable que les "majors" s'y mettent trés rapidement.
Posté par Cook Captain .
En réponse au journal ZFS.
Évalué à 1.
A la demande générale (!), je vais apporter plus de précisions à ma réponse à la question de Brice "pourquoi les développeurs de ZFS n'ont il pas utilisé un lvm -gestionnaire de volume - traditionnel en le séparant du FS". (comme c'est la cas actuellement dans toutes les architectures).
La réponse brève est : parce ce que n'était pas possible (en pratique).
Juste en préambule, il faut savoir que le volume (géré par le LVM - Logical Volume Manager) est une interface entre le FS et le(s) disque(s). A ce titre, le FS ne sait pas, et n' a pas à savoir, si il attaque un volume logique ou une partition physique du disque. De son coté le volume ne connait rien de la manière dont le FS gére ses données. Il s'assure juste de transmettre les données au disque. L'intéret d'un gestionnaire volume est qu'il permet à un FS de s'étendre sur plusieurs disques (pour effectuer par ex. de la concaténation, du stripe ou du raid).
Prenons qq fonctionnalittés offertes par ZFS.
1. Pool de stockage. Avec un LVM classique, c'est impossible à effectuer. En effet le LVM classique impose une relation 1 FS pour 1 volume. Si on souhaite ajouter de l'espace disque pour deux FS, il devient alors nécessaire de partionner le disque supplémentaire et d'affecter ces partitions à chacun des volumes. C'est ni trés pratique ni trés souple (réservation d'espace statique), mais c'est surtout trés mauvais pour les perfs. (cf. 2). ZFS n'a pas ces contraintes car un volume ZFS peut gérer plusieurs FS peut être assigné à un volume.
2. Performance : Le principe pour avoir de bonne perf sur des IO est relativement simple. Eviter que le disque ne passe son temps à se balader d'un bout à l'autre d'un cylindre. Pour cela, il est nécessaire de réordonner et de cacher les ordres de lecture/écriture de manière intelligente. Dans un système classique, quand vous avez 2 FS qui partage un même disque, vous êtes mort (les caches des FS ne sont pas commun et les io ne peuvent pas être réordonner sur la globalité du disque). Le LVM ne peut en rien améliorer les choses car il doit forcément écrire de manière synchrone sur le disque et n' a évidement pas avoir accès aux structures interne de chaque FS). ZFS est quand à lui est capable de traiter les IO de manière globale pour tout le disque, ce qui lui permet d'optimiser les entrés sorties, car son gestionnaire de volume a accès à toutes les structures du FS.
3. Sécurité en raid soft. Deux disques, c'est mieux qu'un. Et effectuer un checksum sur les blocs permet de sécuriser les données en cas d'erreur sur un disque. Un FS classique associé à un LVM pour le RAID est tout fait capable d'effectuer un tel traitement. Malgré cela, si un FS détecte une erreur de checksum, le FS est incapable de la corriger et renvoie juste une erreur, car le LVM se contente de retourner le bloc qui arrivent en premier d'un des 2 disques (sans savoir que la données est erronée). Pire, en fonction du disque, la donnée pourra être exacte ou erronée et le FS semblera renvoyer de manière quasi aléatoire une erreur. Pour corriger cela il faudrait que le LVM connaisse ... la structure du FS. Ce qui est le cas pour ZFS et qui lui permet de détecter l'erreur mais ausi de la corriger sur le disque défaillant!
Bref, pour générer des perfs max, une sécurité max et une grande souplesse, on s'apercoit rapidement que LVM et FS doivent être fortement imbriqués, car il est nécessaire que toute la structure des données (cache, layout, etc.) soit connu tout du long de la chaine d'entrée/sortie. Il n'y a alors pas bcp d'autre choix que de lier le FS et le LVM en un seul module. (peut-on d'ailleurs encore parler de LVM et de FS?). Ce qui n'exclut en rien les autres FS car ceux-ci peuvent à leur tour être encapsulé dans ce nouveau système (un peu comme IP dans ATM!) à travers une couche de compatibilité.
ZFS n'aurait-il donc que des qualités ? Non : à mon avis, il a un gros défaut : sa jeunesse, j'attendrai au moins un an (voir 2) avant de mettre en prod un système critique avec ce filesystem. Mais, il est tout de même trés prometteur.
Posté par Cook Captain .
En réponse au journal ZFS.
Évalué à 6.
Mais j'ai l'impression qu'elle est mauvaise..... j'aimerais une argumentation rationelle .... mais que je n'aime pas le design.
Ou sont tes arguments rationnels dans tes explications?
>Ce projet a déja nécessité 5 ans de développement
Comme beaucoup d'autres...
Comme tu parlais de "quick & dirty", il me semblait que c'etait tout de même un argument rationnel.
A partir du moment ou l'intégration du FS+LVM est capable de donner plus pour le même prix, je ne vois pas le pb. Il me semble que Linus T. partage la même opinion (Linux Kernel vs micro noyau). Je ne dis pas que c'est mal du faire du micro noyau, ni des sytèmes modulaires, (c'est même généralement une bonne solution), mais ce n'est pas sytématiquement la panacée. (perte de performance et de flexibilité.)
Maintenant si tu connais un seul système FS+LVM capable de donner autant, cite le moi. Le seul produit qui s'en rapproche amha est veritas LVM/FS ou WAFL et ni l'un ni l'autre ne propose autant de fonctionnalités (sans compter leur complexité -veritas- et leurs prix - les 2).
... "quick and dirty", lourd à maintenir
Si tu lis les manpages et les docs, ce n'est absolument pas l'impression que cela donne. J'ai personnellement jamais vu un fs aussi complet et autorisant une gestion aussi fine (et pourtant j'ai administré pendant qq années des systèmes NetApp, IBM et Linux)
Au sujet de sharenfs, lis les docs (au moins le lien PDF) et tu verras que l'on peut créer autant de point montage souhaités en dessous de home et leur affecter leurs propres propriétés avec une notion d'héritage. C'est au contraire ultra propre et puissant.
"The very surprising (for me) thing to note is that the Fast MD5 implementation outperforms the native "md5sum" (textutils-2.0.14-2.i386.rpm ) binary even when the native methods aren't used"
D'autre part, il existe plusieurs implémentations libres de Java basées sur le projet classpath. http://www.classpath.org. Et il semblerait (j'ai pas testé) que gcj permet de faire tourner open office. Pour info, gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage.
Et j'ai peur que maintenant, ça se dégrade à cause de java
A la différence de la presse magazine, la presse quotidienne utilisent encore bcp de solutions propriétaires qui ne tourne ni avec InDesign, ni avec Quark. En revanche, le PDF se généralise à vitesse grand V (verra-t-on un jour un rip SVG), ce qui n'est pas sans poser certains problèmes. (Les anciens standards étaient TIFF et TIFF/IT).
vas payer un sous-traitant de ta poche
Rien ne devrait t'empêcher de pouvoir confier ta ligne (dernier km) à l'opérateur de ton choix (à l'heure actuelle ce n'est pas possible).
Autre ânerie du même goût : comparer le service public à un monopole, Le service public n'a aucun sens s'il est soumis à la concurrence,...
Dans le cas de FT, il s'agissait clairement d'un monopole public : la preuve FT a été privatisé et la plupart de ses clients ne s'en portent pas plus mal. D'ailleurs, quand Jospin était au pouvoir, il ne s'est pas précipité pour renationnalisé FT.
mais cela me fait bondir de voir qu'on peut balayer aussi facilement des pièce aussi fondamentales dans notre société.
L'erreur fondamentale, c'est quand l'Etat sort de ses fonctions régaliennes pour assurer, sous des prétextes fallacieux, des opérations normalement destinées à être gérées par des sociétés privées.
# Mon experience .Net
Posté par Cook Captain . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 9.
Moi> le problème, c'est que votre solution tourne uniquement sous windows et mes serveurs sont en linux. Ca m'ennuie.
Lui> Pas de problème. Avec Linux Il y a mono.
Moi> (naif) Ah oui c'est vrai...
1 semaine plus tard :
Moi> (vicieux) Ok pour tester votre solution mais sous linux
Lui> Ah oui, euh, euh... c'est à dire que ... on va certifier la prochaine version, mais actuellement c'est pas le cas. Vous voulez pas essayer en windows?
Finalement, j'ai acheté le produit parce qu'il m'intéressait et j'ai installé un serveur windows (bouh!!!) . Depuis on a essuyé quelques platres et particulièrement des problèmes de perfs. (pas directement liés à .Net). Discussion avec un des développeurs de la société éditrice :
Lui> il faudrait upgrader la version de la librairie AJAX utilisée avec .Net car il y a des bugs et des fuites mémoire. Mais le directeur a les boules car la société créatrice de la librairie en question a augmenté ses tarifs par 3. Et puis, y a pas longtemps on a racheté 10 licences visual studio et c'est pas franchement donné.
Moralité :
1. les grosses applis développées .net ne tournent pas sous mono
2. Mono est utilisé comme argument marketing pour vendre des produits microsoft.
3. L'écosystème .Net est majoritairement closed source et payant
Ma question : les développeurs de mono ont-ils conscience de se faire manipuler par Microsoft ?
[^] # Re: ZFS ?
Posté par Cook Captain . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 1.
[^] # Re: ca n'est pas nouveau
Posté par Cook Captain . En réponse au journal La NSA prise la main dans le sac ?. Évalué à 5.
[^] # Re: Le Canada ?
Posté par Cook Captain . En réponse au journal demain greve :). Évalué à -1.
[^] # Re: Excellent
Posté par Cook Captain . En réponse au journal RATP = Moyen de transport fiable. Évalué à 3.
[^] # Re: Le Canada ?
Posté par Cook Captain . En réponse au journal demain greve :). Évalué à -3.
a) puiser dans les bas de laine de ceux qui auront bossé 40 ans
b) faire bosser ta progéniture
c) crever de faim
[^] # Re: Le Canada ?
Posté par Cook Captain . En réponse au journal demain greve :). Évalué à 1.
Faut arréter d'être naif ou de faire sembant. Les cheminots se battent pour conserver leurs privilèges. (C'est d'ailleurs assez humain). Evidemment pour le grand public, ils préfèrent avancer d'autres arguments.
[^] # Re: et dire qu'ici nous osons nous plaindre
Posté par Cook Captain . En réponse au journal demain greve :). Évalué à 1.
C'est vai. La SNCF loue à la RFF l'usage des voies ferrées mais en revanche effectue leur entretien qui est refacturé à la RFF. Petite originalité du montage: la facturation de l'entretien est supérieur au coût de la location.
Imaginez un proprio qui vous loue un appart moins cher que les charges de fonctionnement qu'il doit payer à la copro. C'est pas beau la vie!
[^] # Re: Excellent
Posté par Cook Captain . En réponse au journal RATP = Moyen de transport fiable. Évalué à -2.
Tu préfererais payer l'intégralité des retraites des cheminots dans tes impôts ?
[^] # Re: 7 commentaires et pas un...
Posté par Cook Captain . En réponse à la dépêche Le Venezuela s'immisce dans le marché du PC et de Linux. Évalué à 5.
Avant de partir, pense à prendre quelques Dollars US car c'est la monaie locale... Pour le shopping, sache que même si le choix n'est pas trés large, à la Havane, tu trouveras sans problème la dernière paire de Nike et de téléphone portable motorola. Si tu loues une voiture, je te conseille une Peugeot 307, en revanche n'oublie pas ton GPS car la plupart des panneaux signalétiques ont été enlevés... (en cas de guerre).
N'oublie pas également d'emporter quelques médicaments (antibio, etc.), car par manque de moyen le système de santé est à l'agonie. Cependant si tu as les poches remplies de $$ tu trouveras de bons médecins et des médicaments directement importés des usines US.
Pour accéder l'information, tu ne pourras manquer de lire Granma, l'organe du PC Cubain et l'un des seuls journaux autorisés (le hasard fait bien les choses, non?). Si cette lecture t'ennuie, n'hésite pas à te rabattre sur Juventud Rebelde, le journal de la jeunesse communiste. Rassure-toi, ces journaux ne commettent pas le pêché mortel de critiquer Castro.
Evite de parler de politique au Cubain de la rue, car c'est un être particulièrement timide sur ce sujet. Bois plutot un bon verre de rhum tout en discutant des derniers exploits de son équipe de base ball.
Si tu sens perdu dans la ville, n'hésite pas à frapper à la porte du commissaire politique (il y une maison indiquée dans chaque quartier) pour avoir des renseignements. Ces gens sont trés aimables et particulièrement bien informés de la vie de leurs concitoyens.
Bref, Cuba est le Paradis sur terre. Une dernière preuve: Castro s'y sent tellement bien qu'il garde le pouvoir depuis plus de 45 ans...
# Changer la n eme lettre d'une ligne.
Posté par Cook Captain . En réponse au message Changer la n eme lettre d'une ligne.. Évalué à 2.
[^] # Re: En perl
Posté par Cook Captain . En réponse au message Remplacement de chaine connues par leur position. Évalué à 1.
[^] # Re: java = langage d'esclavagistes et/ou de conspirateurs
Posté par Cook Captain . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 3.
(cf. http://sourceforge.net/top/topalltime.php?type=downloads )
Pour les développeurs : Netbeans, Eclipse. jEdit
Coté serveur : JBoss, Tomcat, Hibernate, etc...
[^] # Re: pourquoi libérer le studio de developpement maintenant?
Posté par Cook Captain . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 1.
Pour plus d'infomations vous pouvez consulter, sur le site de la FSF, la page trés instructive sur les licences : http://www.fsf.org/licensing/licenses/index_html
[^] # Re: Electronique & Micro-electronique sous linux , un secteur vacant
Posté par Cook Captain . En réponse à la dépêche KTechlab 0.3 et Qucs 0.0.8. Évalué à 5.
[^] # Re: besoin ?
Posté par Cook Captain . En réponse au journal Et le 64bits ??. Évalué à 1.
[^] # Re: ...
Posté par Cook Captain . En réponse au journal LDLC : retour de baton. Évalué à 1.
J'adorerais voir ce cas d'école exposé dans des revues informatiques sérieuses... à coté d'une bonne pub Microsoft.
[^] # Re: belle mentalité
Posté par Cook Captain . En réponse au journal Délirant. Évalué à 2.
[^] # Re: A coté de la plaque.
Posté par Cook Captain . En réponse au journal ZFS. Évalué à 1.
La réponse brève est : parce ce que n'était pas possible (en pratique).
Juste en préambule, il faut savoir que le volume (géré par le LVM - Logical Volume Manager) est une interface entre le FS et le(s) disque(s). A ce titre, le FS ne sait pas, et n' a pas à savoir, si il attaque un volume logique ou une partition physique du disque. De son coté le volume ne connait rien de la manière dont le FS gére ses données. Il s'assure juste de transmettre les données au disque. L'intéret d'un gestionnaire volume est qu'il permet à un FS de s'étendre sur plusieurs disques (pour effectuer par ex. de la concaténation, du stripe ou du raid).
Prenons qq fonctionnalittés offertes par ZFS.
1. Pool de stockage. Avec un LVM classique, c'est impossible à effectuer. En effet le LVM classique impose une relation 1 FS pour 1 volume. Si on souhaite ajouter de l'espace disque pour deux FS, il devient alors nécessaire de partionner le disque supplémentaire et d'affecter ces partitions à chacun des volumes. C'est ni trés pratique ni trés souple (réservation d'espace statique), mais c'est surtout trés mauvais pour les perfs. (cf. 2). ZFS n'a pas ces contraintes car un volume ZFS peut gérer plusieurs FS peut être assigné à un volume.
2. Performance : Le principe pour avoir de bonne perf sur des IO est relativement simple. Eviter que le disque ne passe son temps à se balader d'un bout à l'autre d'un cylindre. Pour cela, il est nécessaire de réordonner et de cacher les ordres de lecture/écriture de manière intelligente. Dans un système classique, quand vous avez 2 FS qui partage un même disque, vous êtes mort (les caches des FS ne sont pas commun et les io ne peuvent pas être réordonner sur la globalité du disque). Le LVM ne peut en rien améliorer les choses car il doit forcément écrire de manière synchrone sur le disque et n' a évidement pas avoir accès aux structures interne de chaque FS). ZFS est quand à lui est capable de traiter les IO de manière globale pour tout le disque, ce qui lui permet d'optimiser les entrés sorties, car son gestionnaire de volume a accès à toutes les structures du FS.
3. Sécurité en raid soft. Deux disques, c'est mieux qu'un. Et effectuer un checksum sur les blocs permet de sécuriser les données en cas d'erreur sur un disque. Un FS classique associé à un LVM pour le RAID est tout fait capable d'effectuer un tel traitement. Malgré cela, si un FS détecte une erreur de checksum, le FS est incapable de la corriger et renvoie juste une erreur, car le LVM se contente de retourner le bloc qui arrivent en premier d'un des 2 disques (sans savoir que la données est erronée). Pire, en fonction du disque, la donnée pourra être exacte ou erronée et le FS semblera renvoyer de manière quasi aléatoire une erreur. Pour corriger cela il faudrait que le LVM connaisse ... la structure du FS. Ce qui est le cas pour ZFS et qui lui permet de détecter l'erreur mais ausi de la corriger sur le disque défaillant!
Bref, pour générer des perfs max, une sécurité max et une grande souplesse, on s'apercoit rapidement que LVM et FS doivent être fortement imbriqués, car il est nécessaire que toute la structure des données (cache, layout, etc.) soit connu tout du long de la chaine d'entrée/sortie. Il n'y a alors pas bcp d'autre choix que de lier le FS et le LVM en un seul module. (peut-on d'ailleurs encore parler de LVM et de FS?). Ce qui n'exclut en rien les autres FS car ceux-ci peuvent à leur tour être encapsulé dans ce nouveau système (un peu comme IP dans ATM!) à travers une couche de compatibilité.
ZFS n'aurait-il donc que des qualités ? Non : à mon avis, il a un gros défaut : sa jeunesse, j'attendrai au moins un an (voir 2) avant de mettre en prod un système critique avec ce filesystem. Mais, il est tout de même trés prometteur.
[^] # Re: A coté de la plaque.
Posté par Cook Captain . En réponse au journal ZFS. Évalué à 6.
Ou sont tes arguments rationnels dans tes explications?
>Ce projet a déja nécessité 5 ans de développement
Comme beaucoup d'autres...
Comme tu parlais de "quick & dirty", il me semblait que c'etait tout de même un argument rationnel.
A partir du moment ou l'intégration du FS+LVM est capable de donner plus pour le même prix, je ne vois pas le pb. Il me semble que Linus T. partage la même opinion (Linux Kernel vs micro noyau). Je ne dis pas que c'est mal du faire du micro noyau, ni des sytèmes modulaires, (c'est même généralement une bonne solution), mais ce n'est pas sytématiquement la panacée. (perte de performance et de flexibilité.)
Maintenant si tu connais un seul système FS+LVM capable de donner autant, cite le moi. Le seul produit qui s'en rapproche amha est veritas LVM/FS ou WAFL et ni l'un ni l'autre ne propose autant de fonctionnalités (sans compter leur complexité -veritas- et leurs prix - les 2).
[^] # Re: Je sais pas si c'est propre
Posté par Cook Captain . En réponse au journal ZFS. Évalué à 7.
... "quick and dirty", lourd à maintenir
Si tu lis les manpages et les docs, ce n'est absolument pas l'impression que cela donne. J'ai personnellement jamais vu un fs aussi complet et autorisant une gestion aussi fine (et pourtant j'ai administré pendant qq années des systèmes NetApp, IBM et Linux)
Au sujet de sharenfs, lis les docs (au moins le lien PDF) et tu verras que l'on peut créer autant de point montage souhaités en dessous de home et leur affecter leurs propres propriétés avec une notion d'héritage. C'est au contraire ultra propre et puissant.
[^] # Re: Sauf que ...
Posté par Cook Captain . En réponse à la dépêche Wine débarque bientôt. Évalué à 2.
http://www.twmacinta.com/myjava/fast_md5.php
"The very surprising (for me) thing to note is that the Fast MD5 implementation outperforms the native "md5sum" (textutils-2.0.14-2.i386.rpm ) binary even when the native methods aren't used"
[^] # Re: Il manque des trucs tout de même
Posté par Cook Captain . En réponse à la dépêche OpenOffice 2.0. Évalué à 1.
C'est bien malheureux de lire sur ce site des commentaires d'un autre age. cf. http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
D'autre part, il existe plusieurs implémentations libres de Java basées sur le projet classpath. http://www.classpath.org. Et il semblerait (j'ai pas testé) que gcj permet de faire tourner open office. Pour info, gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage.
Et j'ai peur que maintenant, ça se dégrade à cause de java
FUD typique.
[^] # Re: beta ou rc ?
Posté par Cook Captain . En réponse à la dépêche Revue de Presse - Octobre 2005. Évalué à 1.
[^] # Re: Pourquoi six mois ?
Posté par Cook Captain . En réponse au journal Changement des conditions générales de vente de France Telecom. Évalué à 1.
Rien ne devrait t'empêcher de pouvoir confier ta ligne (dernier km) à l'opérateur de ton choix (à l'heure actuelle ce n'est pas possible).
Autre ânerie du même goût : comparer le service public à un monopole, Le service public n'a aucun sens s'il est soumis à la concurrence,...
Dans le cas de FT, il s'agissait clairement d'un monopole public : la preuve FT a été privatisé et la plupart de ses clients ne s'en portent pas plus mal. D'ailleurs, quand Jospin était au pouvoir, il ne s'est pas précipité pour renationnalisé FT.
mais cela me fait bondir de voir qu'on peut balayer aussi facilement des pièce aussi fondamentales dans notre société.
L'erreur fondamentale, c'est quand l'Etat sort de ses fonctions régaliennes pour assurer, sous des prétextes fallacieux, des opérations normalement destinées à être gérées par des sociétés privées.