Sytoka Modon a écrit 4544 commentaires

Au boulot, j'achète plein de DELL sans OS. Et l'OS coute environ 100E (en fait 98 pour faire bien).

Donc le pipeau qui dis que MS paye pour être dans la machine, je n'y crois pas.

Après, faire payer plus cher Ubuntu, c'est effectivement avoir envie que l'opération soit un échec. C'est peut être voulu par DELL pour se débarraser de cette question des Linux pour le grand public.

Personnellement, je n'irais pas mettre un centime de plus pour un Linux pré-installé sachant que mon serveur FAI m'installe une debian sans que j'intervienne en moins de 15 mn ! Bref, monsieur DELL, vous vous fichez de nous.

Dans un fichier DNS, tu as des tabulations pour aligner et c'est bien pratique, par contre, il faut tous utiliser la même.

Sinon, je bannis les tabulations.

Pour être dans le troll, c'est quand que dans un Makefile, un '->' en début de ligne sera équivalent à une tabulation !

Je suis d'accord avec toi. Les CMS c'est bien mais tu es obligé de te mouler dans la structure du CMS et d'avoir du code dynamique avec aussi les problèmes qui vont avec (trou de sécurité, injection de code...)

Avec un bon site en page statique, tu fait ton site sur ton ordinateur et tu upload le tout. C'est facile, fonctionnel et cela marche très bien pour, par exemple plein d'association.

Ce qui prouve qu'il y a eu erreur de la part de Disruptive Innovations de refuser tout développement de la version 1. Les versions 2 sont souvent renvoyés aux oubliettes vu la somme de chose à faire. Je me souvient par exemple d'un anjusta jamais finit...

Bref, ce KompoZer mériterait d'avoir le nom nvu-1.7.10

> Dans la pratique, j'ai toujours perdu mes disques avant que SMART
> ne s'inquiète

Je suis un peu au même point, du coup, j'avoue que je ne regardes plus trop ce que me dit SMART et il m'arrive de ne plus l'installer sur les postes pour cette raison.

Car c'est bien d'avoir plein de chiffre et de pouvoir faire des graphes avec mais en pratique, si on n'a aucun critère pour remplacer un disque avant qu'il lache, cela ne sers pas à grand chose. A moins d'être suffisament riche pour remplacer les disques en n'ayant pas de critère obectif pour le faire...

Ah bon, je ne savais pas que l'objectif du projet OpenBSD était de faire du support aux entreprises ?

Le coup du CVS est intéressant parce que justement, avec Subversion, il y a vraiment une solution dans la continuité de CVS.

S'il manque un truc à Subversion qu'une boite a besoin et qui est dans CVS, qu'elle participe à Subversion me parait bien plus futé que de refaire un CVS.

Bref, je en suis pas pour casser la compatibilité tous les quatre matins mais de temps à autre, il faut savoir changer et ici Subversion est beaucoup plus agréable à utiliser que CVS.

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 ;-)