Sytoka Modon a écrit 4544 commentaires

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.

Enfin, si tu veux un VM performante, tout ne tourne pas en simple utilisateur, trap système, réseau, etc. Ce genre de chose sont parfois cachés dans des sudo ou des binaires suid...

Personnellement, j'aime bien pour les << serveurs >> la technique de Xen sur debian qui consiste à faire une partition LVM pour chaque partition partition de la machine virtuelle. Ainsi, il n'y a pas de MBR, de table de partition... Il est très facile de réparer une machine virtuelle sur le serveur central.

L'aléatoire du nombre Pie n'est pas verbeux. A partir du moment ou l'on est verbeux, on est dans un langage (verbe) donc avec des mots, des phonèmes. Les règles statistiques des langues montrent bien que les phonèmes ne sont pas égales et que certaines reviennent bien plus souvent.

Donc, à mon sens, je suis assez d'accord pour dire que si un langage est verbeux, il devrait pouvoir un taux de compression important.

Moi, au boulot, ce sont les photocopieurs qui scannent donc plus de scanner !

Je vois pas trop l'intérêt d'un << scanner professionnel >> sauf dans le cadre d'un atelier de reprographie.

Il est évident qu'en réactivant le développement de Perl5, il y avait un risque pour Perl6. Cependant, en pratique, Perl6 est un autre langage et la communauté est d'accord pour dire qu'il aurait du changer de nom.

Perl6 a tout de même pas mal d'avantage sur le papier, donc je suis persuadé qu'une fois la première version stable sortis, les applications vont suivre petit à petit. Il est clair que les gros environnement sous Catalyst ne vont pas migrer en premier ;-)

H264 est sortie pour la visio-conférence car il y avait un besoin qualité / bande passante que n'avait pas le H263.

Les tarifs des équipements de visio : terminaux et ponts ont permit a ces entreprise de développer le H264. Même si les tarifs ont baissé, il faut voir ce qu'ils étaient plus de 5 ans en arrière...

Il avance bien. Je crois qu'il passe déjà plus de 30000 tests et il est prévu pour la fin de l'année (au mieux).

Mais comme le projet Perl6 a pris beaucoup de temps, le développement de Perl5 est repartis de plus belle et pompant pas mal d'idée dans Perl6.

Bref, Perl est loin d'être mort et bouge pas mal de tous les cotés ;-)

D'ailleurs, je mettrais plutôt "cette entreprise" que "la société" ce qui éviterait une répétition ;-)