Jean-Marc Saffroy a écrit 49 commentaires

Peut-être qu'Intel veut remplacer la disquette par des disques flash sur port USB ? Techniquement ce serait nettement mieux : stockage persistant, résistant beaucoup mieux aux chocs et aux champs magnétiques, accès plus rapide et débit plus élevé... Reste à surmonter le problème du prix (qui chutera probablement avec une production de masse) et des standards (a priori on devrait pouvoir s'en sortir avec des standards ouverts).

Question : pourquoi Intel voudrait supprimer la disquette ? Peut-être parce qu'ils ont à gagner en faisant la promotion de technologies dont ils ont une maîtrise technologique (ils ont "quelques" brevets bien sentis pour l'utilisation de disques sur flash).

J'ai un 2.2.19 tout tourne nickel. Je n'ai pas de raison de changer.

Tout pareil : "if it ain't broken, don't fix it" (si c'est pas cassé, faut pas le réparer). Le comble étant que j'ai des programmes qui fonctionnent nettement moins bien avec un 2.4.10 qu'avec un 2.2.19. :(

Ceci étant, j'aimerais bien avoir un module DRI qui marche en 2.2.19 avec mon XFree 4.1.0... Trop dur, j'ai un dual boot 2.2/2.4 pour jouer à Quake 3 ! :) Evidemment, ce n'est que mon cas particulier, le 2.4 a d'autres avantages.

D'après le site de France Info, un avion s'est écrasé *près* du Pentagone. Et les 2 avions envoyés sur le WTC étaient des gros jets civils détournés. Le FPLP (Palestine) aurait revendiqué l'attentat.

A mon avis, SGI sort une station à base d'IA64 pour faire comme tout le monde : les grands constructeurs font mine de suivre Intel sur le chemin de l'Itanium pour être à la page, mais ils vendent encore leurs machines habituelles, histoire d'avoir quand même des solutions éprouvées à proposer. L'IA64 a encore largement le temps de faire un flop mémorable, et ce n'est pas pour rien qu'Intel continue de développer les petits frères du P4, tandis qu'AMD fait la promo de son 64 bits compatible x86. Intel a provisoirement repoussé les limites d'adressage de ses processeurs 32 bits, mais le besoin d'un vrai processeur 64 bits se fait de plus en plus sentir et Intel ne peut pas se permettre de l'ignorer.

Tester sur une vieille machine, ça ne veut pas dire utiliser sur une vieille machine. L'intérêt c'est qu'on voit plus facilement qu'un programme est anormalement lent. Et le gain de performance qu'on obtient sur une vieille machine, on le retrouvera sur une neuve...

Par exemple, mettons qu'il faut 50Mo de RAM pour UN mozilla. Sur une station récente (mettons 128Mo de RAM), pas trop occupée, ça ira. Maintenant, si on voit un peu plus grand, et qu'on veut que 50 utilisateurs simultanés puissent le lancer depuis des terminaux X sur un serveur (ça fait de belles économies de matériel), on voit bien qu'il serait franchement intéressant de réduire l'occupation mémoire (2,5Go dans cet exemple, un peu moins en comptant les mappings partagés, mais l'idée est là).

On peut facilement appliquer le même exemple avec Nautilus, et il n'est certainement pas saugrenu d'envisager un /usr et un /home sur NFS dans ce genre d'environnement avec beaucoup d'utilisateurs. C'est en voyant LARGE qu'on se rend compte des gains qu'on peut obtenir en consacrant à l'optimisation un minimum du (soi-disant) précieux temps des développeurs, même pour des applications qu'on croit destinées uniquement à des utilisateurs individuels. Il faut bien comprendre que si le temps des développeurs est si précieux, c'est qu'il permet de très grosses économies à grande échelle... à condition que ce temps soit bien employé, évidemment (implémenter un cache de requêtes coûteuses est souvent plus utile qu'aligner les boutons sur un formulaire).

De toute façon, ils n'ont visiblement même pas pris la peine de faire l'analyse *basique* qu'a fait Cox (jouer avec strace c'est vraiment pas difficile). Donc faut pas s'attendre à des miracles... Garder de l'information dans un cache, c'est une des bases de la programmation système, et il faut croire que les développeurs de Nautilus savent essentiellement faire des interfaces, certes utiles, mais ce qu'il y a derrière n'est visiblement pas efficace d'un point de vue système.

Enfin, certains commentaires "avisés" ci-dessus montrent bien que l'économie de moyens n'est plus une valeur à la mode... Et celui qui parlait des développeurs à 35$/h qui n'ont pas de temps à perdre me fait doucement rigoler : à ce tarif-là, on a les moyens d'avoir une machine de compilation (puissante) *et* une machine de test, qu'on dimensionne comme on veut. L'idéal c'est de faire du développement threadé sur un vieux SMP : ça oblige à faire du soft efficace *et* thread safe. :-)

Question bête : est-ce que quelqu'un a déjà fait fonctionner ce driver avec un noyau 2.2 ? Je ne peux pas vraiment le faire, je n'ai pas encore la carte...

Bah s'ils ne donnent pas leur driver, ils devraient au moins donner des specs... C'est quand même malheureux de devoir renoncer à du bon matériel parce qu'on ne peut pas écrire de drivers pour. Grâce au driver dxr3, j'en aurai bientôt une dans mon PC (hors de question que j'achète du matériel dont je ne peux pas me servir sous Linux).

Ca me rappelle Matrox, qui refusait de donner les spécifications de ses cartes il y a environ 4 ans. Depuis ils ont changé leur fusil d'épaule, et même si leurs cartes ne sont plus les plus performantes du marché, elles sont probablement les mieux supportées par XFree. Et ce n'est pas le fait de livrer certaines de leurs spécifications qui leur a causé le moindre tort.

Le nom de la boîte parisienne qui fait un jeu en GPL, c'est Nevrax (des gens fort sympathiques au demeurant).

Effectivement, le pari qu'ils font de miser sur un modèle où le jeu est gratuit et où l'accès au monde en ligne est payant est assez osé. Mais je ne vois pas de bonne raison de le condamner aussi vite, d'autant que dans le cas d'un jeu sous licence libre, on peut envisager une évolution dans le temps, de la même façon qu'un Linux ou qu'un Apache évoluent, s'améliorent et s'enrichissent : cela a le potentiel d'allonger notablement la période d'exploitation du jeu, ce qui permet d'abaisser le coût de l'accès pour l'utilisateur, et donc d'augmenter les chances de succès du jeu (évidemment, il faut un bon jeu à la base).

Quand je parlais d'une compétence qui peut se monnayer, je n'envisageais pas de la vendre à l'utilisateur final, mais à ceux qui envisageraient de faire leur propre version du jeu à partir du moteur libre. Mettons que nos amis d'id diffusent librement les sources de Quake 3, mais sans documentation : on a beau avoir des gens compétents, la prise en main d'un logiciel de taille conséquente nécessite des ressources non négligeables (des gens qualifiés pendant plusieurs mois), alors qu'un contrat de support ("nous, fournisseurs, vous vendons toute l'assistance dont vous avez besoin pendant 6 mois") permet par exemple à une équipe de créatifs (scénaristes, graphistes, etc.) de faire leur propre jeu avec des compétences techniques limitées.

Peut-être que Nevrax se plantera, peut-être qu'id n'ouvrira jamais le code de ses jeux tant qu'ils seront exploitables commercialement (honnètement, je ne serais pas surpris que le développement de Q3 soit déjà largement amorti...), mais en tout cas, je crois qu'on peut compter sur des passionnés pour réussir à créer des jeux libres de qualité, tout comme on a vu naître des serveurs web et des systèmes d'exploitation de qualité suffisante pour concurrencer le monde propriétaire : si cela arrive, comment les développeurs de jeux propriétaires pourront-ils concurrencer des jeux qui ne passent plus leur temps à réinventer la roue, qui s'enrichissent constamment d'extensions écrites par quelques joueurs éclairés ? Je pense que le choc risque d'être rude pour ceux qui colleront au modèle actuel.

Ma conclusion est que quel que soit le modèle économique adopté par les boîtes de jeux dans les années avenir, il sera très probablement influencé par le monde du logiciel libre. Mais bon, il faut bien reconnaître que la question est largement ouverte, et qu'on peut débattre assez longtemps sur le sujet. :)

Premières remarques, sur la forme : en français, on utilise des caractères accentués, c'est peut-être un tout petit peu plus long à taper (et encore, avec de l'entraînement, la différence est vraiment minime), mais ça fait une différence au niveau du sens. On peut toujours arguer qu'on s'en sort toujours avec le contexte, le fait est que l'absence d'accents nuit à la lisibilité. Et c'est se payer la tête du lecteur que de faire celui qui s'excuse parce qu'il n'a pas pris la peine de faire un effort minimal pour être lisible. Mêmes remarques en ce qui concerne l'orthographe : d'abord on se relit, ensuite on fait relire par quelqu'un de plus calé, et ça filtre 99% des erreurs.

Maintenant sur le fond : cet article est un énorme retour en arrière. On se croirait revenu aux énormes doutes sur la viabilité des logiciels libres dans leur ensemble qu'exprimaient la plupart des gens il y a quelques années. Aujourd'hui, envers et contre tout, on trouve des logiciels libres de bonne qualité en position de sérieux concurrents de logiciels propriétaires (serveurs web, mail, bases de données, stockage, OS et développement embarqués, etc.). Et vu la complexité de ces logiciels, un marché s'est constitué permettant à ceux qui en ont la maîtrise de monnayer leurs compétences. Alors pourquoi ne pas envisager la même approche pour le domaine des jeux ? Evidemment, Rome ne s'est pas faite en un jour, il faut aussi bien changer les mentalités que valider ce modèle économique appliqué au monde du jeu, et les difficultés que rencontre Loki sont un avertissement à ne pas négliger. Mais annoncer un status quo est une attitude qui se révèle presque toujours fausse à moyen terme, surtout dans le monde de l'informatique, où l'évolution est permanente (même si elle ne se fait pas toujours à vitesse constante dans tous les secteurs).

Bref, il me paraîtrait beaucoup plus constructif de disserter sur les différentes façons dont les développeurs de jeux pourraient trouver avantage à passer certaines parties de leur code sous des licences libres, de la même façon que diverses entreprises trouvent leur intérêt à contribuer à des logiciels libres en rapport avec leur activité.

PS: ce commentaire a été relu. :p

Même si ce bouquin est excellent (je l'ai lu) c'est hors bcp trop cher (350F) et vu qu'on peu le télécharger et l'imprimer librement pourquoi s'en priver.

360F c'est cher ??? Faudrait voir à arrêter la moquette : déjà c'est tout à fait dans la moyenne des bons bouquins techniques, et surtout ce livre permet une économie de temps non négligeable, qui vaut largement plus que 360F !!

Et pourquoi se priver de l'acheter ? Ben pour faire vivre les auteurs et l'éditeur, histoire qu'ils continuent à nous faire d'aussi bons bouquins, tout simplement.

l'impression revient (pour la plupart d'entre nous) presque aussi cher que le bouquin lui meme. et la qualité n'est pas forcément la même... je préfère encore acheter.

Surtout que Linux Device Drivers 2nd ed. est le genre de livre qui mérite qu'on l'achète : le peu que j'en ai vu sur le web m'a paru très bien fait (quoi qu'un peu léger en ce qui concerne le debug du code noyau). Il suffit d'attendre qu'il soit disponible en France (le Monde en Tique l'annonce pour août à 360F).

La licence n'est pas la GPL, mais une licence spécifique RedHat/eCos, je crois que c'est plutôt un genre de mélange de GPL pour les principaux composants du noyau et de BSD pour les drivers.

Sinon je ne connais pas QNX ni Stinger, mais eCos est TRES loin d'un Unix ; c'est un OS temps réel pour l'embarqué, donc minimaliste, dont les points forts sont qu'il est configurable (ça peut aller très loin, on peut supprimer le support du réseau, de malloc, des systèmes de fichiers ou de la "compatibilité POSIX") et qu'il tourne sur un bon nombre de plates-formes embarquées.

Je suis sur que l'ISP, croulant sous les mails "Free Theo or die!", sera tres heureux de resoudre le probleme en un temps record, de doubler la bande passante de Theo en divisant sa facture par deux, sans oublier 100 balles et un Mars...

Tres franchement, ce ne sont pas des methodes : c'est le provider de Theo, c'est a lui de regler ce probleme. Et exploser la mailbox de l'ISP aura probablement un effet negatif sur son eventuelle bonne volonte.

Il ne faut pas oublier d'ajouter au prix des composants celui du congelateur dans lequel il faut mettre le PC : 2 Atlons, ca doit etre dur a ventiler correctement chez un particulier sans clim...

En meme temps, une mini-chaine a 400 balles, c'est fait pour Sky Rock ou Fun, pas pour ecouter de la musique.

</troll>

Au fait, y a-t-il des gens ici qui ont pu tester NetBSD (ou Linux, ou eCos) sur Dreamcast ?
Est-ce que ca marche bien (stabilite, support des periphs, etc.) ?

Le brevet sur les liens hypertexte, c'est BT (British Telecom) qui en a déposé un, et il me semble bien qu'ils ont (ou ont eu) l'intention de le faire valoir... chez les ISP.

Quant à déposer un brevet avant les autres, je ne crois pas que ce soit utile si on publie ses travaux, puisqu'alors on peut démontrer qu'on est à l'origine du concept. Evidemment, il faut jouer la carte de l'ouverture...

Oups, le lien sur LWN n'est pas le bon, c'est l'édition de la semaine précédente qu'il fallait lire : http://lwn.net/2001/0215/(...)

Ca a déjà été débattu il y a plusieurs mois dans LWN : http://lwn.net/2001/0222/(...)

De plus, l'idée d'un noyau généraliste tournant au-dessus d'un micro-noyau temps réel est bien antérieure au brevet de FSMLabs : MkLinux est un OS généraliste (Linux) tournant au-dessus d'un micro-noyau temps réel (Mach) ; un autre projet de l'OSF (Mk-PA, HP-UX sur Mach) a été réalisé précisément dans ce but (ie. faire du temps réel avec HP-UX) : http://www.opengroup.fr/os/hp-pa/(...)

Bref, IANAL mais j'ai dans l'idée que le brevet a des bases fragiles...

itanium vise d'abord le marche gros serveurs, auquel cas tout est en place pour que ca se passe tres bien pour lui (dispo d'OS + logiciels efficaces)

Ah, on m'aurait menti ? Intel serait *enfin* arrive a produire un compilateur performant pour l'IA64 ? Parce qu'il me semble bien qu'ils en sont encore loin, grace a leur "magnifique" approche EPIC/VLIW/machin qui laisse un gros boulot sur les epaules du compilateur.

Comme l'ont dit d'autres, c'est pas la hotline ici, allez plutot voir sur frta (fr.reseaux.telecoms.adsl) : des gens posent regulierement la question, des drivers sont en cours de developpement mais on n'en sait pas plus.

Au passage, il eut ete avise de verifier la marque et le modele du modem avant de l'acheter s'il etait prevu de l'utiliser sous Linux...

Si on est honnete, on n'a pas besoin de ce script, puisqu'il vaut mieux compresser directement en ogg a partir des originaux... :-)

Pourquoi est-ce que les patchs openwall n'apparaitraient pas avant le noyau 2.4.10 ? Pourquoi cette version-la plutot qu'une autre ?? Qu'on dise "quand ceci ou cela sera implemente", je veux bien, mais vu qu'a peu pres personne ne sait ce qui sera dans le 2.4.10, je trouve ce genre de formulation franchement idiot. Si c'est pour dire "quand le noyau sera assez stable", autant l'exprimer clairement.

oui oui je suis d'accord pour les applis, c'est pas tres dur a installer ... mais quand je pourrais profiter de mon modem adsl usb sans recompiler le kernel ? ... faudra que j'attende ma prochaine distrib qui aurra compiler le kernel comme je veux ? ... 6 mois, 10 mois ...

Pour l'Alcatel SpeedTouch USB, il suffit d'un noyau 2.2 récent avec support USB (2.2.18 ou ultérieur), et il n'y a aucunement besoin d'un noyau exotique : le driver qu'a écrit Benoit Papillault est 100% userspace, il n'a besoin que du support usbdevfs et de ppp. Et il marche très bien. :-))

http://benoit.papillault.free.fr/(...)

Va voir sur le site de ton distributeur Linux s'il n'a pas un paquetage avec un noyau récent comportant le support USB.