Sytoka Modon a écrit 4551 commentaires

Très bien, je ne connais pas à vrai dire ces produits. Pour écrire la nouvelle, j'ai fait une petite recherche et j'étais tombé la dessus

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/p(...)

Du coup, je me suis dis que c'était aussi intéressant de replacer Open vSwitch dans ce contexte de << bataille >> vmware / cisco.

> On espère également une meilleure rapidité de rendu, la lenteur étant l'un des principaux
> reproches fait à Joomla!

Je n'utilise pas Joomla mais un des reproches principals que je lui ferait c'est qu'il est percé très régulièrement. Je reçois les avis du CERT et Joomla apparaît régulièrement, tout comme il est aussi très souvent sur les sites pris en défaut sur Renater (à lire la lettre du CERT Renater) alors que SPIP, par exemple, y apparaît bien moins souvent.

Je ne connais pas le taux de pénétration de Joomal par rapport aux autres CMS mais je dois dire que ce point là ne donne pas très envie d'aller y mettre ses billes.

> C'est un peu le but, en même temps, non ?

Dans un post plus haut, il est dis par baud : << unstable aka sid est tout de même un peu comme Cooker [...] Cela signifie des mises à jour agressives où l'utilisateur est prêt à se poser des questions et s'adapter. >>

Au final, il me semble qu'on est bien dans une philosophie proche de la SID qui signifie Still In Development, terme très proche de Rolling Release mais qui a quelques années de plus ;-)

Le terme unstable n'est qu'un lien qui n'est pas forcément bien choisie. Surtout qu'il y a en amont les branches experimentales (je parle au pluriel exprès car en pratique, on ne prends pas tout expérimental mais seulement des bouts pour les plus motivés).

Sinon, je dois dire que ce concept d'équilibre permanent de la distribution est assez intéressant dans le concept. La seule chose qui me dérange, mais c'est un peu général à l'informatique d'aujourd'hui, c'est de mélanger ajout de fonctionnalité, correction de bogue et qu'il en devient donc normal de mettre à jour tous les quatre matins car les logiciels sont complètement bogués.

L'autre chose qui me dérange n'a rien à voir, c'est que les environnements de bureau dépendent de plus en plus de daemons locaux : gconf, dbus, udev... Les souhaits sont que les modifications soient pris en compte immédiatement pour toutes les applications. Cela me fait fortement à la programmation par variable globale et me semble très peu sécuritaire.

J'aimais bien le concept UNIX d'être simple avec des variables d'environnement et d'être obligé de relancé l'application en cas de changement des préférences. Au final, on ne change pas ses préférences si souvent que cela. Mais comme les applications confondent parfois préférences et variables internes, c'est tout mis en vrac.

Premier exemple que je prends au hasard sur ma machine : .gconf/apps/evince/%gconf.xml

<entry name="show_sidebar" mtime="1179553875" type="bool" value="false">
<entry name="sidebar_size" mtime="1233943050" type="int" value="132">

Ce n'est pas ce que j'appelle des préférences ;-)

Une mise à jour de la glic n'est pas quelque chose d'anodin, quelque soit la distribution ;-)

Dans ma ville, ce sont des lunettes polarisantes, rien d'actif ;-(

C'est effectivement mieux que le rouge et vert mais cela n'est pas non plus si éloigné. Je ne savais pas que des cinémas avaient des lunettes actives, tant mieux ;-)

Merci.

Je n'ai pas de télé ni de mobile et la 3D avec lunette me gonfle, cela me rappelle << les dents de la mer >> ... tout un programme, surtout si ce sont des lunettes rouges et vertes !

D'un point de vue technique, seule les lunettes électroniques synchronisées sur le projecteur me semble correcte techniquement mais je crois que c'est pas pour demain dans un cinéma (mais chez soit, c'est plus envisageable).

Sinon, je suis d'accord avec toi. Ces films de la fondation blender, c'est une espèce de pub. Il faut donc savoir surfer sur la vague afin d'aller plus loin et plus vite. Je trouverais tout à fait intéressant qu'ils sortent une version 3D de leur nouveau cours métrage.

Moi j'aime bien ces corrections en direct pour deux raisons :

- je vois qu'il y a pas que moi qui fait des fotes ;-)

- je lis et j'apprends en voyant les corrections proposées

Bref, tout cela est très pédagogique et très communautaire.

Je ne vais quasiment plus au cinéma (manque de temps) et j'ai une vie sociale bien remplis ;-)

Un abonnement LWN ne suffit pas à écrire de bonnes dépêches sur DLFP ;-)

> mais dans les faits, ces distributions sont celles qui posent le plus de problèmes dans le
> monde de l'entre prise

Normal, les entreprises ne testent leur produit et ne supporte que sur Red-Hat et sur Novel !

Heureusement qu'il y a d'autres distributions populaires pour éviter la mainmise totale de ces deux boites sur le monde GNU/Linux.

Coté calcul, Fluent, Matlab, Comsol... marchent très bien sous base debian même si officiellement, cela n'est pas écrit.

Par contre, du coté des ex onduleurs MGE, maintenant Eaton, il y a bien un logo debian sur leurs boites mais leur logiciel est une vrai daube et en plus, il faut réussir à trouver une version qui marchent !

Comme quoi, les logos et les couleurs ;-)

On trouve toujours un client par base : phpmyadmin, phppgadmin, mysql-query-browser, sqlitebrowser...

Pourquoi à chaque fois une nouvelle application pour permettre l'édition de base de données et non pas une application plus générique ?

J'ai l'impression que ce que je fais avec ce genre d'application est générique les rares fois ou je m'en sers.

Pourquoi ne pas développer sous forme de greffon les parties qui ne le seraient pas ? Par exemple, dans un programme Perl, j'utilise toujours DBI qui est générique et jamais une interface dédiée. D'ou vient ce besoin de lier un client sur une base donnée ?

Je me rappelle de la secrétaire que nous avions il y a 12 ans qui utilisait WordPerfect (et trouvait cela très bien - il faut dire qu'il était effectivement bien) et qui avait été forcé de passer à MS Word (merci le ministère) qu'elle trouvait plus que limité et compliqué. Un jour, suite à une phrase malheureuse dans un contrat de thèse, elle a du se taper la frappe d'une thèse sous LaTeX alors qu'elle n'en avait jamais fait (oui, il y a des thésards qui sont pas ch...). Au bout d'un mois, je me souviendrais toujours de sa remarque : << Au final, c'est vachement plus simple que Word ! >>

Bref, c'est pas pour mettre LaTeX partout mais par exemple pour les équations, le Wysiwyg est une catastrophe. Ne parlons pas du MathML non plus qui en ait une autre ;-)

Sinon, la force des wikis est d'avoir généralisé une syntaxe plus naturelle que le HTML. Globalement, cela a bien marché vu le nombre de page wiki sur la toile ;-) Un des soucis est le nombre de syntaxe wiki différente mais comme MA syntaxe est mieux que celle du VOISIN, c'est pas près de bouger.

Quitte à faire du wiki Wysiwyg, autant alors revenir dans les sources à une syntaxe XML plutôt que wiki.

C'est vrai que mon post n'est pas très gentil mais Mandriva aimerait depuis des années jouer dans la cours des grands sans vraiment décoller. Et nous avons droit ici à des post parfois pas très objectifs.

Cela dis, je parle de debian parce que c'est ce que j'utilise sur des dizaines de machines et non parce que debian serait mieux que les autres. J'ai un grand respect pour ce que fait Red-Hat même si je n'accroche pas. J'aime aussi la voie de Gentoo. Etc.

Malheureusement, l'enthousiasme de certain pour Mandriva me laisse de marbre car je ne doute pas qu'il y ai de bonne chose dedans mais on ne les retrouve pas sur les autres distributions. Je ne veux pas me faire enfermer dans un système qui ne serait pas un temps soit peu communautaire.

Si Mandriva ferme ses portes, tu sera alors peut être dans la mouise ;-(

Quand on fait une distribution et qu'on veut jouer dans la cours des grands, on se doit d'être irréprochable. Donc oui, faire du libre sans livrer de SVN, c'est complètement nul. Il faut replacer les choses dans leur contexte.

Sinon, mon argumentaire ne cherche pas à me plaindre, il vise surtout à montrer que l'éco-système Mandriva n'interagie que très peu avec les autres distributions, à mon sens. Je suis cependant tout ouie pour écouter le contraire.

Cette interaction faible me fait dire que la mort de Mandriva serait un épiphénomène sans réelle conséquence.

Il ne faut pas se tromper, il me semble qu'en plus de 14 ans, je n'ai jamais utilisé un seul outil Mandriva et cela ne m'a jamais manqué. Je me fiche personnellement éperdument de Mandriva. Mon argumentaire cherche donc uniquement a essayé de pointer les défauts de Mandriva depuis ses origines, défauts qui risquent à terme de voir disparaître cette distribution.

Si Mandriva veut que son annuaire soit plus utilisé pour par exemple faire du service dessus, elle aurait peut être tout intérêt à pousser son intégration dans toutes les grandes distributions.

Si le pro-Mandriva ne souhaitent n'entendre aucune critique, qu'ils continuent comme cela. Cependant, il y a un risque non négligeable que quasiment tout cela finissent dans /dev/null, ce serait quand même dommage ?

Il n'y a rien chez debian, tu peux t'amuser à chercher MDS, MANDRIVA, DRAKE ou PULSE2 sur http://packages.debian.org/. Si jamais il y a quelques choses, je suis preneur.

Les bons outils peuvent intégrer les autres distributions. Il y a plein de trucs développé par Red-Hat qui sont dans les dépôts debian. A ma connaissance, il n'y a aucun outil Mandriva dans les dépôts debian.

Si Mandriva meurs, tout sera perdus et cela ne changera rien sauf pour le pouième qui utilise Mandriva...

Mais aussi pourquoi utiliser les outils Mandriva puisque l'expérience à montré qu'on les retrouve jamais dans les dépôts officiels des autres distributions. Qu'en est-il alors de la version n+1 de sa distribution dans ses conditions.

Les pro-Mandriva nous bassinent à longueur d'année par cette distribution qui au final n'apporte pas grand chose sauf aux utilisateurs de celle-ci. Ils nous bassinent aussi par l'aspect Français du développement. Je répète que je pense qu'il y a plus de développeur debian en France que de développeur Mandriva et surtout, que j'en ai marre de ce chanvinisme Français qui n'a plus lieu d'être, nous sommes en Europe et aujourd'hui, il n'y a plus que cela qui compte réellement !

> En effet, pas de SVN, mais bon c'est pas non plus un truc qu'on trouve dans beaucoup
> d'entreprises

Alors là, je dis que c'est du foutage de gueule ! Pas de SVN chez mandriva ? On parle pas de n'importe quelle boite mais d'un entreprise qui fait du GNU/Linux et développe une distribution. C'est donc une boite très compétente sur les systèmes de gestion de code et ne pas le mettre à disposition est un signe évident de ne pas vouloir diffuser ses outils dans les autres distributions au delà d'une imite très restreinte.

D'ailleurs, quel outil réalisé par Mandriva a réellement été ré-utilisé ailleurs ? Même urpmi qui était un vrai plus à un moment pour les distributions à base de rpm n'a pas pris !

Les sources sont libre mais comme il est dis plus loin, pas de SVN...

Il y a bien des paquets pour d'autres distribution mais mon apt-get ne me dis rien ! Je ne base pas le coeur de mon architecture d'authentification sur un paquet qui n'est pas intégré dans ma distribution.

Et puis, c'est comme les autres outils de Mandriva, à mettre son nom partout, c'est diffusé nulle pars ! Je regrette personnellement, surtout pour "pulse" qui me semble être le seul outil réellement intéressant.

Tu investies dans une entreprise et tu deviens majoritaire mais le fondateur n'a pas les mêmes opinions que toi sur la marche à suivre. Il y a alors deux solutions : partir et revendre tes actions en laissant couler la boite (et perdre un paquet d'argent) ou virer le fondateur.

Une fondateur qui vend sa boite, s'il veut rester, doit savoir être à l'écoute de ses employés mais aussi des actionnaires.

Linagora s'en sors très bien sans Mandriva, je ne vois pas l'intérêt pour eux de mettre des fonds dans cette boite... a pars récupérer des employés compétents. Ce n'est pas en rachetant Mandriva que d'un seul coup, on va revendre de cette distribution.

Mandriva aurait du prendre le virage debian il y a longtemps mais l'a raté. J'ai jamais utilisé un seul outil Mandriva et je ne suis pas le seul. Je ne dis pas qu'ils sont mauvais mais les drakemachins n'ont jamais percé ailleurs que sur leur distribution. Bilan : si la distribution perds des << pars de marché >>, l'arrêt de la distribution passe quasiment pour un non événement.

Je pense qu'il y a plus de développeurs debian que Mandriva en France. Je n'irais personnellement pas mettre un copec dans l'aventure Mandriva, il y a de meilleur placement à mon sens ;-)

Et ou je rajoute export LANG=C dans ton fichier .desktop ?

Le problème est que tu perds toute souplesse car ton fichier .desktop ne permet de résoudre qu'un problème de dimension fini connu à l'avance. Or, l'expérience montre qu'on se retrouve toujours un jour ou l'autre devant un cas non prévu et c'est la qu'il faut alors de la souplesse.

Je me méfie beaucoup des "On crois", avant de tirer un vu sur un système qui a fait ses preuves question maintenance, je voudrais savoir de manière chiffré le vrai temps perdu par ces fork.

Si ces fork prenait réellement un temps fou, je préférerais alors adopter un langage de script plutôt que de basculer en C et rendre encore un peu plus le système obscure.

Justement, si le tout binaire est mauvais, le tout script n'est pas mieux. Il faut simplement trouver un juste équilibre et mettre de la souplesse au bon endroit et non partout.

Le paradigme objet n'est pas universel à tous les langages... Le moteur objet n'est pas le même (compatible) dans tous les langages...

Parfois aussi, une structure d'arbre de classe trop imbriquée avec l'héritage multiple donne une rigidité donc une difficulté à faire évolué l'arbre de classe au cours du temps plus grande que ce que l'on espérait : la souplesse de ré-utilisation ! Je trouve par exemple qu'Eiffel est tombé dans ce travers.

Qui n'a jamais mis un LANG=C en début de script pour éviter les messages en Francais... Qui n'a jamais bidouillé les dépendances... Qui n'a jamais lu un script pour comprendre comment ce p... de service fonctionnait. Un exemple rapide qui me vient en tête, l'option --ghost de l'automonteur AutoFs ne fonctionne pas de la même manière sous debian et sous Suse, la version debian se règle par table d'automount alors que celle de Suse est globale (donc inutilisable). Seule la lecture des script d'init m'a permit de comprendre cela facilement. La lecture du code C est bien moins évidente pour certains administrateurs systèmes (dont moi).

Avoir des fichiers en scripts permet de savoir exactement comment sont lancés les services et d'en faire soit même en quelques instant. Je doute que le gain soit aussi important que cela (sauf sur les équipements de type téléphone portable mais la problématique n'est pas tout à fait la même).

Un des problèmes des scripts en bash peut être effectivement le nombre de sous processus, alors pourquoi ne pas les écrire en Perl6 avec mise en cache en bytecode parrot ;-)

Ca c'est idiot car on retrouve dans la position de Windows avec des trucs binaires dont personne ou presque ne comprends rien au fonctionnement.

La force d'UNIX est aussi d'avoir des parties importantes en script facilement modifiable et modelable.

Si ce sont des serveurs, normalement avec IPMI, on les réveille proprement à distance.

Sinon, pour votre problématique, vous pourriez avoir un dom0 Xen par machine physique, mettre en pause le domU celle concernant votre appli lors des gros calculs sur un autre domU et si un dom0 n'a plus de domU d'actif de l'arrêter.

Vous auriez une machine maitre qui réveillerait tout cela par IMPI puis via les dom0, vous prendriez le controle des appli à la carte.