Sytoka Modon a écrit 4538 commentaires

Je propose le schéma suivant :

nom de naissance coupé à 6 lettres + chiffre aléatoire de 0 à 9 + première lettre du prénom

Le risque d'homonymie est alors très faible car il en faut 10 dans la même boite avant que cela arrive.

Le problème de l'homonymie est surtout critique pour le courriel or dans ce cas là, l'adresse doit être facile à retenir et je en vois pas d'autre solution que le basique :

Prenom.Nom2@domaine.com

Avec un incrément 1, 2, 3 ... pour chaque homonyme.

De temps en temps, je me dis que les personnes des BSD ont vraiment du temps à perdre... Il y a tellement de choses à faire ! Par exemple, malgré tout ce que j'ai lu, je ne vois toujours pas le moindre intérêt à ré-écrire CVS.

Tu parles beaucoup des retours de bout de code de boites privé dans BSD mais as t'on une idée du nombre de ligne provenant de boite privé dans BSD et dans Linux pour comparer ? Parce que je en serais pas étonné que Linux en ai plus ce qui rend une partie de ton arguentation caduque.

As t'on une idée du nombre de ligne dans BSD provenant directement d'une boite privé et du nombre de ligne provenant de Linux via la double licence (en ne comptant que les lignes ou le développeur fait du code pour Linux principalement mais est d'accord pour le mettre par principe sous licence BSD) ?

Bref, les *BSD passerait tous sous GPL qu'il n'y aurait à mon avis plus de problèmes. Les boites privés n'ayant pas les moyens de déveloper leur propre OS (en tout cas de moins en moins), on serait assurer face au succès des *BSD et de Linux d'avoir un support matériel ouvert.

Je voulais te proposer qcad mais cela n'a pas l'air de te convenir alors je te rabat vers xfig qui permet de grouper les objets pour les déplacer ensemble et de faire des angles au dégré près. Bref, j'utilise xfig pour tous mes crobards car je ne trouve pas qu'inkscape le remplace pour le moment mais plutôt qu'il le complète dans un style de dessin ou xfig n'était pas bon.

Idem pour les processuers MIPS qui ont disparus des stations alors qu'il avait plus de puissance pour une même frequence que les x86 (mais moins de puissance en absolue).

Pour battre le x86 sur les PC, il faut être plus puissant et moins cher. Je ne pense pas qu'un petit gain de consommation puisse jouer sur l'architecture PC.

Tu peux faire un script qui se lance avant le reboot automatiquement et qui te vire ton module.

Le PowerPC n'a pas percé car il est trop chère. Je ne vois pas l'intérêt de changer de processeur s'il y a pas un réel plus. Or malgré la comm faites sur le PowerPC, je n'ai jamais vu un réel plus par rapport à la plateforme x86.

J'avoue que je ne boote plus en secours sur sur des live CD (type System Rescue CD) et donc je n'ai pas de problème d'USB et de noyau minimal.

Cela fait des années que je n'est pas booté en single user.

En fait, ce qu'il faudrait, c'est un ZODBFS ! Pouvoir monter la ZODB comme un système de fichier. D'ailleurs, cela devrait être souvent un principe de départ de pas mal de projet de pouvoir monter les données et ainsi, s'intégrer dans la philosophie UNIX au plus proche.

C'est d'ailleurs un peu ce qui me plait dans le gestionnaire de fichier que j'utilise : wmii. C'est un système client serveur et tu peux monter la configuration et ainsi agir sur le gestionaire de fenêtre avec les outils standard. Je trouve cela plus futé sur le principe de gconfd.

Si, je me suis mélangé, mon PoE voulait en pratique dire les équipements Coraid en AoE ;-)

Effectivement, zope3 a l'air bien mieux mais si j'ai bien compris, plone3 est encore basé sur zope2 ?

C'est plus l'intégration de plone dans zope qui me posait des soucis car tout était mélangé et il fallait faire des choses dans la ZMI et d'autre dans plone avec une logique qui nécessitait du temps pour la comprendre. Et comme dans ces versions là, on n'a pas accès à de vrais fichiers, mais qu'on passe son temps à faire du click, je n'ai jamais réussi à trouver le temps.

Juste pour dire que le BUS écran n'est pas un bus lent mais plutôt rapide et qu'il faut un câble de type ethernet pour faire passer la vidéo dessus. Et encore, elle ne passe pas en trame ethernet dessus donc ne peut être commutée par un switch du commerce.

Je suis d'accord pour dire que le PS2 est trivial et un dérivée du RS232.

Cela n'empêche qu'avoir tous les composants en USB simplifie pas mal les choses. On peut brancher sa souris sur un hub USB...

En pratique, cela signifie 2 prises USB de plus à l'arrière du PC et non deux prises USB de moins. Voila pourquoi je n'étais pas d'accord avec le premier argumentaire.

Au niveau matériel, même si le PS2 est trivial, il faut continuer à avoir des périphériques parlant le PS2. Alors qu'avec l'effet de volume, avoir un composant parlant USB n'est pas beaucoup plus cher et permet d'unifier tout cela.

C'est comme ethernet comme bus rapide qui est en train de bouffer petit à petit les autres. Je trouve cela bien. Cela limite le nombre de câble. Par exemple, on a pour le stockage l'iSCSI ou le PoE et de plus en plus de caméra rapide sont connecté en ethernet et plus en firewire. Ne plus avoir de câble SCSI ne me dérange pas, au contraire. Avoir du RJ45 à la place du firewire non plus.

Cette simplification me semble une bonne chose.

Enfin, on sait tous que les services packs de Microsoft, c'est très lourd et super lent.

Pour information, j'ai mis à jour un machine de debian sarge vers debian etch avant hier. Cela m'a pris moins de 15 mn entre le début et la fin de l'opération, reboot compris (changement de noyau).

Pour le moment, Microsoft ne m'a pas montré qu'il était capable de faire cela. Il a déjà fallu un temps fou à Microsoft pour unifier les mises à jour de tout ses produits dans WindowsUpdate, et encore, je ne crois pas qu'ils y soient tous. Et même s'il y sont, tout cela est très très lent.

Je suis parfaitement d'accord avec toi et c'est ce que je dis plus bas. Les templates actifs sont une horreur. Avec AxKit, mes templates n'avaient plus une ligne de Perl mais que du XML passif avec des balises qui étaient ensuite transformé en XHTML via le pipeline d'AxKit.

C'est un peu lourd au début pour un petit site mais cela devient vite très puissant et réutilisable. Cela doit être pour cela que je fait des blocages lorsque je vois le code source de pas mal de projet web, tout est mélangé en vrac.

> Le langage de templating de Zope n'est pas plus difficile, et est plus
> propre et plus puissant

Je veux bien le croire mais dans Zope, il y a trop de chose dans la ZODB et c'est cela qui est insuportable. Pas possible de faire de find, grep et autre commande la dessus... C'est l'environnement qui est pénible pour le développeur que je suis.

Avec spip, au moins, les fichiers templates et le moteur sont sous forme de fichier. Je préfère mais c'est un point de vue personnel.

Je me souvient de mes sites que je faisais en AxKit, c'était génial. Une arborescence en pure Perl de fichiers pour la partie moteur des pages (formulaire...), une arborescence en XML pour les templates, une arborescence pour les fichiers XML statique, une base de données pour les données variables et toute la logique séparée dans des modules Perl bien propre. Bref, c'était clair et relativement sécurisé de part ces différentes arborescences ayant des droits sur des fichiers différents.

Certes, le développement du site n'était pas WebCollaboratif mais fait en s'appuyant sur des outils comme subversion, nedit... comme n'importe quel autre code développé.

J'ai essayé et je suis passé sous spip...

Le plus inquiétant avec plone, ce sont les mises à jours. Comme avec zope, il y en a partout et surtout dans cette ZODB. Bref, si on n'est pas tous les jours dessus, très rapidement, on est complètement perdus. D'ailleurs, la boite qui nous a fait la première configuration m'a bien dis, tant que cela marche, ne touchez à rien au niveau mise à jour logicielle !

Sinon, l'interface d'administration était franchement bordélique entre la ZMI et la partie plone + des fichiers du site au milieu de tout cela avec la seule interface web pour manager tout cela. J'ai trouvé cela insuportable.

D'un point de vue utilisateurs, l'interface intégré, cela parait bien au début mais les menus (verts) qui apparaissent sont suchargés et parfois peu compréhensible pour l'utilisateur lambda. Du coup, on passe son temps à expliquer l'interface aux personnes qui ne font pas du plone tous les jours...

Bref, nous sommes passé à SPIP, plus léger, moins de fonctionalité mais au moins, le personnel l'utilise.

Je ne conseille pas Plone si on n'a pas assez de personnel pour s'en occuper.

On peut considérer que si la souris et le clavier sont USB, il y a plus de port USB sur la machine.

Je suis pour le clavier et la souris USB, cela simplifie la machine qui ne parle que USB et plus le PS2. Je ne vois pas l'intérêt du PS2 alors que l'USB fait la même chose. C'est même moins cher de ne faire que de l'USB car tu n'as qu'un jeu de composant électronique et qu'une pile logiciel (USB) à gérer.

Bref, vive l'USB, je trouve que DELL à raison d'avoir supprimer le PS2.

blabla d'économiste... Les économistes ont besoin de faire croire à toute une science exacte alors 10%, cela fait bien.

Apple a bien moins que 10% du marché depuis des années mais la boite existe toujours...

Bref, des théories pour le FMI et la banque mondiale ;-)

Moi ce qui m'inquiète dans le monde professionnel, c'est le nombre de serveur apache jamais mis à jour sous Windows... Du coup, je crois que je préfère un IIS à jour automatiquement sous Windows qu'un apache qui n'évolue jamais.

Cela-dis, j'ai très très peu de serveurs sous Windows, il sont quasiment tous sous GNU/Linux.

Ah bon, je croyais que c'était mort depuis que HP s'était retiré du projet.

En tout cas, Kerrighed tourne sur un noyau 2.6.20 et si mes souvenirs sont bons, ils essayent d'avoir un patch peu intrusif. Le principal problème de Kerrighed pour le moment est qu'il ne supporte pas l'ajout et le retrait de noeud à chaud.

Il existe kerrighed, c'est je pense la dernière alternative encore viable.

Ou que les mecs qui font du python n'ont rien à foutre que de trainer sur dlfp alors que les perliens bossent encore ;-)

J'ai commencé chez Apple il y a très longtemps (le mac n'était pas encore là) mais dès que j'ai découvert Linux en 96, j'ai sans hésité quitté le monde mac sans état d'âme, pour ne plus y revenir.

Apple a bâti sa réussite (ben oui, atari, amiga sont mort, tout est mort de nos jours sauf Windows et heureusement notre pingouin) sur un ecosystème fermé et ne joue le libre que quand cela les arrange. Cela a toujours été comme cela par le passé et je pense que c'est inscrit dans la culture de cette entreprise.

Enfin, ces sites sont pour les Windowsiens de base. Un bon debianeux ne prends des paquets que de debian ou des développeurs debian et lorsque je doit installer un truc sous Windows, je passe toujours par framasoft !