rogo a écrit 282 commentaires

Voilà comment je comprends ces chiffres :

• Les 29 % d'économie annoncés dans le graphique, c'est sur le total des 5 premières années de fonctionnement.
• À partir de la 3e année, ils espèrent stabiliser les gains à 50-55 % par rapport à du pur Microsoft.
• Les 71 % de gain sont une limite théorique sur un poste client, ils n'intègrent pas les surcoût d'infrastrucure, de formation, etc. Ce taux ne tient pas compte non plus que certains postes resteront sous Windows. Dans la pratique, ils visent donc plutôt 55 %.

 
Au final, l'expérimentation est très marginale : 150 postes sur 50000, soit 0,3 %.

Je ne connais pas BCDI, mais vu son nom, il doit être ciblé sur les CDI et donc probablement plus simple que les concurrents que tu cites.
PMB (Pour Ma Bibliothèque) est un logiciel libre mais piloté par une boîte française qui le garde jalousement captif (je me base sur une expérience d'AO complétée par des infos de seconde main). Personnellement, je suis plutôt réticent, mais je n'ai pas suivi son évolution récente.
Koha est très puissant, mais très complexe, tant dans son installation que son fonctionnement au quotidien (et je ne parle pas de son code !). Je n'en connais que des instances en université (Lyon, Grenoble, etc), et je doute franchement qu'un CDI ait les moyens de s'investir dedans. A son crédit, Koha dispose d'une vraie communauté d'utilisateurs et de développeurs, en France et à l'international.

Je n'ai pas la prétention de dresser un tour d'horizon d'un sujet que je suis loin de maîtriser, je me borne à donner quelques mots-clés et pointeurs.

MongoDB est une base de donnée orientée document dans le courant NOSQL.
Le principal concurrent est CouchDB. Il y a une comparaison sur le site de Mongo. Elle est plutôt équilibrée à mon avis, mais je connais beaucoup moins CouchDB. On trouve aussi des tas de comparaisons sur Internet, ainsi que d'autres SGBDD de même type (orienté document) mais moins répandus.

La notion même de point fort/faible est variable selon le projet et l'observateur. Par exemple, CouchDB est écrit en Erlang et MongoDB en C++. Pour moi qui connaît le C++ mais pas Erlang, un léger avantage va à Mongo. Le fait que CouchDB conserve toutes les anciennes versions des documents peut être utile ou pas suivant l'application. Pour la recherche en texte intégral, CouchDB a une avance indiscutable sur son rival. Sur un autre critère important à mes yeux, lancer une recherche est plus souple et plus facile avec Mongo : tous deux disposent de map/reduce, mais les views de Couch semblent souvent un carcan face à l'API de recherche de Mongo.

Mea culpa. Je n'avais que ce full-text search en tête. Encore une preuve de l'influence pernicieuse de l'anglais sur ma pratique du français.

Pour poursuivre mon auto-critique :
s/fait effectivement/font effectivement/
s/n'y travaillais pas/n'y travaillait pas/

Cf le ticket "ARM support" pour MongoDB: plusieurs variantes non-officielles de la v1.8 sont proposées pour ARM. Par exemple, celle-ci https://github.com/skrabban/mongo-nonx86

Je suis un râleur. J'assume.

Critique de la dépêche

Je ne suis pas un spécialiste de MongoDB, mais je l'utilise régulièrement, et la dépêche me semble pour le moins imprécise.
Tout d'abord, j'aurais ajouté dans la liste principale que les performances ont été améliorées pour plusieurs opérations (map-reduce, journalisation, index, concurrence).

Ensuite, la dépêche a raison : l'écriture en RAM et la possibilité de perte de données en cas de crash d'une instance unique de MondogDB pendant l'écriture fait effectivement partie des principes de conception de ce SGBD. Par contre, elle ne précise pas que MongoDB propose depuis bien lontemps des remèdes : soit on force le client à attendre que l'écriture soit effective, soit on écrit sur plusieurs instances. La première solution est bien sûr beaucoup plus lente. La documentation officielle rappelle que toute application sérieuse doit utiliser des replica sets et forcer les écritures à se faire sur plusieurs nœuds. On n'est pas obligé d'apprécier ce mode de fonctionnement, mais cette information est essentielle pour comprendre MongoDB.

• Journalisation
  Il faut rappeler que la journalisation existe dans MongoDB depuis la version 1.8. Le principal changement de la journalisation dans la future v2.0 est son activation par défaut pour les machines 64 bits, mais on y trouvera aussi des améliorations mineures (compression, configuration plus fine).
• Réplication
  L'écriture sur N répliques est apparue en v1.6, alors que la dépêche laisse entendre que c'est une nouveauté de cette RC. Le texte insinue aussi que les termes "réplica" et "slaves" sont équivalents en MongoDB. Ce n'est pas le cas. Si on utilise la technique master/slave, on ne peut pas écrire sur le slave.
• Data centers
  La réplication me semble être le domaine où la v2.0 apportera le plus de nouveautés, mais l'une seule est décrite par les release notes comme spécialement destinée aux data centers. AMHA, cette "awareness" n'est qu'un élément mineur de la gestion plus fine de la réplication.

Critique de MongoDB

A titre tout à fait personnel, je trouve que la grosse lacune de MongoDB est l'absence de recherche en plein texte. La doc officielle en propose un ersatz peu satisfaisant (construire des listes indexées de mots). Donc quand on a besoin de cette fonctionnalité, il faut utiliser un outil externe, que ce soit Sphinx Search, Elastic Search ou Solr. Ou Xapian si on ne veut pas de serveur pour cela. Mais dans tous les cas, si les données ne sont pas statiques, alors il faut synchroniser le moteur de recherche plein texte avec MongoDB, et c'est un travail long et pénible. C'est frustrant de ne pas pouvoir utiliser les points forts de Mongo, comme sa syntaxe de recherche. Comme de plus on a besoin des attributs pour les recherches (par exemple, texte_contient: "mise en examen" ", date>{timestamp}, type: 3), il faut recopier la plupart des données de Mongo, et donc sa valeur ajoutée par rapport à son complément s'amenuise. Par exemple Elastic Search a pas mal de points communs avec MongoDB, et c'est frustrant d'utiliser simultanément deux outils qui dédoublent autant de fonctionnalités.

Il y a depuis des années un ticket de MongoDB sur la recherche plein texte. Certains ont dit avoir une implémentation presque fonctionnelle, basée sur Lucene (enfin, sa variante récrite en C++). Mais rien de public, pas d'évolution depuis des années. C'est vraiment ce que j'attendais de la version 2.0 et j'ai été désolé de voir que la branche de développement (v1.9.X) n'y travaillais pas. Dommage.

Je dirais même plus : le statut de "RC" devrait figurer dans le titre de la dépêche, sinon l'effet est trompeur.
Au moment où j'écris ce commentaire, le statut est mentionné dans une note du modérateur en fin de texte.

Dans le domaine de la gestion et la surveillance, bien sûr qu'il existe des normes.
Le Cirque utilisait beaucoup les taupes, les lampistes, les chasseurs de scalps et les traîne-patins, avec comme protocole de communication les microfilms ou la valise diplomatique. Mais avec la montée en puissance des Cousins et la fin du Centre et de Karla, les vielles pratiques disparaissent.

Je n'ai pas connu Matahari -- même s'il y avait paraît-il beaucoup de plaisir à faire sa connaissance -- mais j'ai exploré avec délices la veine de "L'espion qui venait du froid", suivie d'autres réussites comme "La taupe" ou "La jeune fille au tambour".

Plus sérieusement, la norme QMF qu'utilise Matahari pour ses objets existe déjà, je crois qu'elle est gérée par la fondation Apache. Idem pour Qpid, utilisé en message bus. Donc l'application utilise largement l'existant. Sur la présentation que j'en avais vu, il y avait un fort accent porté sur la surveillance des machines virtuelles.

Pour le risque de casser ce qui marche, c'est surtout lié à la jeunesse de systemd et des procédés de migrations prévus par les distributions. Personnellement, j'ai testé le passage à systemd sur un portable Debian il y a quelques mois. A l'époque, après migration mon eth0 n'était pas initialisé, il avait fallu corriger ça à la main. Le bug est bien sûr corrigé depuis. En dehors de ceci, tout a fonctionné très bien et l'accélération du démarrage est spectaculaire : grosso modo, je suis passé de 30 s. à 5. (*)

Sinon l'article précise bien que le temps de démarrage n'est pas le seul atout de systemd. L'outil est surtout prévu pour améliorer la gestion des services, ce qui est particulièrement utile pour les serveurs. Par exemple, la mise à jour d'un démon, et donc son redémarrage, sans interruption du service. Ou encore le suivi des processus orphelins grâce aux cgroups.

(*) Ce portable pas récent a une carte Nvidia. Plus de driver nv pour Xorg, donc le choix doit se faire entre Nouveau et le driver proprio. Le premier fait planter l'hibernation (plus précisément, la reprise). Le second refuse de dialoguer avec un vidéoprojecteur. Résultat, j'utilise Nouveau mais le temps de démarrage est crucial, faute d'hibernation.

• La phrase "Actuellement deux étudiants..." devrait être placée après la liste des nouveautés, sinon le texte "Les principales nouveautés sont :" tombe à plat.
• s/en sous-projet/en sous-projets/
• s/sont possible /sont possibles /
• s/n'apparait/n'apparaît/

Opa, camarades, Opa, camarades, Opa Opa Opa.

Unity est un énorme bon en avant pour la facilité d'utilisation de linux par des personnes n'étant franchement pas habile avec un pc.

A ma connaissance, le seul test à ce sujet prouve plutôt le contraire. Cf le compte-rendu sur LWN.
Certes, le test est très incomplet, il ne porte que sur 12 personnes et sur une beta d'Unity, et il est réalisé par du personnel de Canonical.

Par exemple, quand on leur demande de supprimer un document, seuls 5/10 y parviennent. Encore plus grave, 2 des 5 qui avaient réussi croyaient avoir échoué !

Ce test montre aussi quelques erreurs flagrantes d'interface utilisateur :

• Nobody seemed to understand what the Ubuntu button was for, or the
  distinction between the Dash main screen and the Applications
  screen.

• P1 and P12 both clicked in the Dash search field several times, but
  both concluded that the field could not be typed in (probably
  because the caret didn't blink and the hint text didn't disappear).

Pour ceux qui ne connaissent pas ou qui en sont resté au langage d'il y a 10 ans, il y a beaucoup de clichés attachés à Perl. Quelques précisions en vrac :

• Perl gère parfaitement l'UTF-8, ce qui n'est pas le cas de tout le monde. Non, je ne citerai personne !
• Il y a un courant nommé "Modern Perl" qui a fait évoluer le langage. Un livre homonyme est disponible sous Creative Commons.
• Par exemple, Perl permet d'écrire du code objet propre, avec (Moose)http://search.cpan.org/~doy/Moose-2.0001/lib/Moose.pm.
• A mon avis, CPAN n'a toujours pas d'équivalent de qualité égale dans d'autres langages
• De mémoire : "Le language ne devrait pas obliger à « penser bien ». On ne peut pas imposer la moralité par la syntaxe." Larry Wall.

 
On n'est pas obligé d'apprécier le principe TIMTOWTDI (There Is More Than One Way To Do It), mais rien n'oblige à écrire du code sale en Perl, pas plus qu'en C ou en Haskell.
Comme toujours, il faut choisir un langage selon le contexte (projet, goûts personnels, documentation, bibliothèques...). Il m'arrive de pester contre Perl (c'est gonflant, ces déréférencements avec accolades), mais pas plus qu'en Ruby (REXML, c'est de la daube), en PHP (qui m'a pondu une cochonnerie pareille ?), en C++ (oh, la jolie fuite mémoire) ou en Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?). Et je ne parle même pas de Java, car je n'aime pas programmer en XML.

Au temps pour moi. J'avais lu "ré-écriture d'URL" en supposant que comme d'habitude il s'agissait de traitement des requêtes, et non de la réponse.

A mon avis, c'est possible avec nginx, mais je n'ai jamais pratiqué ça.
Il faudrait essayer les modules sub, voire substitutions, qui permet de filtrer la réponse (que l'on soit en reverse-proxy ou pas).

Extrait de la doc nginx sur le module proxy : http://wiki.nginx.org/HttpProxyModule

location  /name/ {
  rewrite      /name/([^/] +)  /users?name=$1  break;
  proxy_pass   http://127.0.0.1;
}

mplayer a la capacité de les battre tous, avec ses 11 ans de développement sans arriver à une 1.0.
Surtout qu'il est en Release Candidate depuis bientôt 5 ans.

Merci beaucoup pour les liens.
Avec le premier, j'ai pu replacer la couche 2D et ses mots-clés. Si j'ai bien compris : X > XRender > (EXA | UXA) > pilote
Quant au dernier, son schéma m'a enfin éclairé sur le rôle des principaux composants graphiques. J'ai encore un doute sur DRM, que je placerais dans le noyau, au côté de DRI, mais l'essentiel est en place. Merci.

L'expresssion state tracker revient fréquemment dans la dépêche, sans être définie.
Une petite recherche sur le web m'indique que c'est un composant qui fait le lien entre 2 parties, par exemple Mesa et Gallium 3D.
C'est ça ?

Si la dépêche comportait un lien vers une page expliquant comment s'organisent les principaux composants graphiques (actuels et futurs), ce serait un énorme plus.
Mais peut-être qu'une telle page (avec un schéma !) n'existe pas.

Sinon, ça me fait plaisir de voir que ça bouge, mais avec mon côté un peu grognon, j'ai l'impression que la plupart de ces évolutions auront peu d'impact pour l'utilisateur lambda. La performance est utile à une minorité (d'ailleurs, les gros jeux 3D ne sont pas légion sous X), et le multi-GPU et le calcul intensif sont incompréhensibles au linusien moyen.
Il me semble bien plus important pour le grand public d'avoir des fonctionnalités comme le décodage vidéo accéléré. Personnellement, j'ai testé Nouveau avec enthousiasme. Même s'il me faisait planter l'hibernation, j'étais prêt à en assumer l'inconfort. Mais quand j'ai réalisé que je ne pouvais plus lire les vidéos h264 (mon CPU n'est pas très puissant), j'ai dû revenir au Nvidia proprio. En fait, des 14 points de l'article, je ne me sens concerné que par 2 :

• le décodeur VP8 : inutile pour le moment, mais peut-être que dans un an ou deux, je tomberai sur des vidéos de ce type.
• Wayland : ah, si je pouvais virer X, ça allégerait un peu ma RAM et mon CPU. Sauf qu'il faudra sans doute charger Wayland et X, donc pas de gain attendu avant des années. Raaah, faut que j'arrête mon pessimisme !

Je ne me mêle pas du troll "PostGreSQL est plus propre sur lui que MySQL". Concernant les variantes de MySQL :

• MariaDB est une alternative complète à MySQL. Il est parfaitement compatible (un client MySQL peut dialoguer avec un serveur MariaDB). MariaDB intègre tous les développements du MySQL d'Oracle pour un même numéro de version. On y retrouve aussi XtraDB, la variante d'InnoDB développée par Percona. MyISAM y est remplacé par AriaDB. On y trouve aussi SphinxSE pour remplacer la (médiocre) recherche plein-texte de MyISAM.
• Drizzle est plus léger, orienté web. Il n'est pas encore stable. Il n'est pas compatible avec les clients MySQL.
• Percona diffuse son serveur avec le moteur XTraDB, dérivé d'InnoDB.

 
Il y a aussi des patchsets connus pour MySQL, mais qui ne sont pas diffusés sous forme de serveurs autonomes. Ils sont plus ou moins intégrés dans les versions ci-dessus :

• patch Google
• patch Facebook

Désolé d'intervenir purement sur la forme, mais la dépêche commence par une faute (sournoise) de français. L'erreur est due aux deux verbes qu'il faudrait traiter différemment : « Bien que cela fasse 2 ans déjà que la série 4 de KDE soit lancée » deviendrait « Bien que cela fasse 2 ans déjà que la série 4 de KDE est lancée ». L'indicatif me semble nécessaire, car le subjonctif marque ici l'opposition, et celle-ci réside dans le premier terme, la date. Sinon on sous-entend une incertitude sur ce lancement de KDE4.
En fait, j'opterais plutôt pour une formulation moins poussive : « Bien que la série 4 de KDE soit lancée depuis 2 ans déjà ».

Sur le fond, rien à dire. D'ailleurs j'utilise presque exclusivement XFCE. KDE se restreint pour moi à Tellico.

Comme l'annonce y invitait, j'ai voulu signaler les bugs. Rien que sur la page d'accueil, j'en compte 6 évidents dans mon navigateur usuel (c'est un constat, pas une critique). Je passe donc dans le suivi de bugs de Github, mais pas moyen d'obtenir la liste des erreurs de CSS déjà signalées : github permet de filtrer par statut ("open", "unread"...) ou par étiquette ("HTML CSS"...), mais impossible de combiner 2 critères. Une recherche par "label" n'affiche que des bugs ouverts.

En plus la page qui liste les bugs "unread" met une bonne douzaine de secondes pour s'afficher, même quand on revient par l'historique de navigation. C'est vite insupportable. Un exemple d'utilisation totalement ratée d'AJAX.

Je ne voudrais pas que mon commentaire se réduise à un "Github sucks" mais en tout cas il m'a clairement découragé.

Les langages sont fondamentalement amoraux. La langue n'est pas le niveau auquel on devrait obliger à "penser bien", si l'on veut un langage utile. On ne peut garantir la moralité par la syntaxe.
Larry Wall, créateur de Perl.

Si on veut que les gens expérimentés programment tous de la même façon, alors il faut définir un "coding standard". Sinon, que ce soit Perl, Ruby, C ou PHP, chaque développeur fera sa propre cuisine. A une moindre échelle, même en Java ou C#, langages bien plus contraignants, si personne n'impose de conventions, c'est le bazar.

A propos de l'acronyme "Pathologically Eclectic Rubbish Lister", il est de Larry Wall lui-même. C'est amusant de voir cette auto-dérision utilisée à charge.

Si vous avez essayé Perl sans rien en ressortir de positif, c'est bien dommage. Je comprends qu'on n'apprécie pas sa syntaxe, mais il y a plein de principes intéressants qui ont très fortement influencé d'autres langages. Personnellement, je recommande souvent Perl et un langage Lisp ou Haskell pour encourager à voir la programmation autrement.

Sinon, je suis étonné que l'importance de l'objectif n'aie pas encore été mentionnée. Pour de l'admin sys, je n'ai rien trouvé qui vaille Perl. Mais Ruby, Haskell, PHP ou C++/Qt ont leurs points forts dans d'autres domaines. Même Java, paraît-il ;-)

> Il n'aurait pas été possible d'avoir un mode de compatibilité ruby (ie juste une nouvelle vm pour l'existant ruby) ?

Ça existe déjà. Par exemple, jruby tourne sur la JVM et c'est un projet stable et bien avancé (compatibilité Ruby 1.8.7).

Loin de moi l'idée de critiquer, mais je n'ai pas vu le lien entre la liste des critères et la description du processus qui a mené à RoR.

J'ai plutôt l'impression que les critères furent :
1. Se faire plaisir avec une techo que j'aime bien.
2. Pas partir dans du folklo complet (choisir des outils qui tiennent au moins 5 ans).
C'est tout à fait honorable quand on est seul à développer.

Sinon, pour les critères annoncés, les 1, 2 et 3 ne me semblaient pas déterminants :

1. La charge.
Si j'en crois mon expérience, un système de cache (soit interne à l'appli, soit au niveau du serveur web) nivellera les performances. RoR a plutôt la réputation d'être lourd, en particulier avec son ORM/ODM, et Ruby 1.8 est franchement lent (Ror/1.9 est instable, non ?), mais ça ne devrait pas être bien important par rapport au cache.

2. Les fonctionnalités
Il faut de toutes façons les coder. Avec un CMS, certaines peuvent être fournies d'entrée, mais il faut forcément compléter.

3. La popularité et la longévité.
Django, Drupal, Symfony, ZendFramework, Ror. Tout ça garantissait 5 ans de suivi. Pour attirer des développeurs, AMHA, un framework/CMS PHP attirait 10x plus de développeurs qu'un produit Python, lui même attirant 2x plus de monde que du Ruby.

4. Le plaisir perso.
Le goût pour Ruby est respectable. D'où le choix de RoR et Ruby.

Le mode de fonctionnement recommandé est d'utiliser des clones. Mercurial est conçu pour faciliter ça. On travaille donc sur un dépôt local plus que sur une branche locale. Comme ce sont des "cheap copies" (qui utilisent des "hard links" au lieu de copier les fichiers), les clones sont en général rapides à réaliser.

Mais dans certains cas, une branche locale est plus pratique. Il faut alors installer une extension non-officielle dans Mercurial :
http://mercurial.selenic.com/wiki/LocalbranchExtension

Désolé pour les anglicismes, même si au fond j'assume ce jargon technique non traduit.