décidement ces développeurs, toujours en avance sur leur temps
Histoire d'enfoncer un peu les portes ouvertes ...
Le plus difficile dans des projets de cette envergure, c'est la conception d'architecture. Or, comme les changements d'architecture doivent se faire en douceur, sous peine d'incompatibilités majeures, Firefox 2.0 ne peut pas apporter de gros changements.
De même pour le développement de Linux : il ne se passe "rien" entre 2 versions majeures (c'est moins vrai actuellement), juste des ajouts mineurs, quelques évolutions. Mais en période "instable", le noyau subit des changements complets d'architecture.
Donc cette avance sur les versions est nécessaire, puisque la version 2.0 sera une sorte de suite logique, déjà figée, et la 3.0 doit se concevoir maintenant, avant que la 2.0 ne conditionne les évolutions de la 3.0.
... elle met le chocolat dans le papier d'alu, bien sûr !
Sisi, j'ai vu faire, j'ai reproduit, j'ai testé, et ça marche !
Le pire, c'est que ça ne marche qu'en LVM (grâce à la fonction snapshot).
Faire une image de machine en dur, pas possible, car la copie type dd n'est pas atomique : si les données changent un peu partout en même temps, on obtient une image disque qui représente différents instants : problème !
En revanche, la magie du LVM permet de faire des clichés instantanés (atomiques) par des "bidouilles" plutôt ingénieuses (détournement des zones d'écriture sur le disque, pour conserver toutes les anciennes données intactes). On peut alors faire une image qui représente parfaitement un instant T.
Reste un petit souci pour cette méthode : lors de la restauration, on se retrouve avec une machine qui aurait rebooté "à la brute". En effet, le temps s'arrête au moment du snapshot et reprend au moment du boot de l'image restaurée. Mais avec un bon système de fichiers journalisé sur le LVM (ext3, ReiserFS, XFS, ... Reiser4 : ne trollez pas maintenant, SVP), aucun problème majeur observé à ce jour.
Les binaires ne sont pas si "instables" sous linux. Ce n'est pas spécialement contre ce post que je dirige cette remarque, mais contre l'ambiance générale de ce fil : sous linux, comme on recompile tout systématiquement, on a l'impression qu'un binaire est spécifique à telle ou telle distrib.
Une telle attitude, c'est renier l'excellent travail fourni sur le format ELF (rappelez-vous le douloureux passage de a.out à ELF). Les liaisons dynamiques sont nickel (mieux qu'une DLL), tout roule à merveille. Les dépendances ? Aucun problème ! Un binaire ELF compilé en statique est certainement beaucoup plus portable que les "Portable Executable" de crosoft. Il suffit alors de mettre tout ça dans un "/opt" adéquat (fait pour ça en plus !) et tout va bien.
Lors du bidouillage de ma version d'un LiveCD minimal, je compilais sur ma machine, puis copiais "à la bourrin" les binaires. Un binaire, s'il trouve ses biblis, est content. Alors les vendeurs n'ont qu'à fournir la glibc, un binaire statique avec un lien dynamique vers ALSA, OpenGL ou SDL et c'est tout bon.
Quant-à DirectX, je trouve que SDL fait du bon boulot, mais manque un peu de drivers accélérés (le driver 2D X11 est assez pitoyable, le son est limite, l'interface OpenGL est pas mal). Regardez le travail magnifique de Loki pour le portage de Unreal Tournament.
Et voici un exemple de ce que peut faire le libre lorsqu'il est bien employé.
Qu'y a-t-il de si extraordinaire ? On peut utiliser autre chose que VLC si on le souhaite, tous les protocoles depuis le PC jusqu'à l'écran de TV sont parfaitement connus, Free joue la transparence sur le logiciel ...
N'empèche que si tous les FAI étaient aussi transparents au sujet de leurs bidouilles (pppoe/pppoa, plaques ECI/Alcatel, ...), ça irait mieux. Bon, d'accord, ça s'améliore mais bon ...
Dommage que je soie trop loin du répartiteur pour en profiter.
Oui, ça va peut-être aussi faire entrer autre chose dans les moeurs : le choix de l'OS (ou des OS).
L'utilisateur lambda va être confronté au choix sur x86, et donc va choisir l'OS qui lui semble le mieux. Le problème, c'est qu'il choisira en fonction du marketing, et pas en fonction des qualités de l'OS (je ne parle même pas des avantages du "tout libre", qui passent à des années lumière des préoccupations de l'utilisateur-lambda).
Le problème, c'est qu'il y aura vraiement 3 types de raisonnements :
- Je veux faire du MSN et des jeux : Windows
- Je veux faire branché avec mes super effets et mes fenetres sans barre de menu : MacOSX
- Je veux utiliser ma machine a fond sans sacrifier la stabilité : GNU/Linux
Et sans compter les petits malins qui voudront les 3.
Par contre, peut-être que ça ouvrira les portes aux 2 aspirations les plus immédiates de certains linuxiens : avoir des drivers corrects (de la part des constructeurs, les programmeurs open source font deja de leur mieux) et pouvoir acheter des PC sans OS (ou avec un OS libre).
... ou au moins une utilisation conviviale. La GUI peut se faire en dialog (je suis fan de ce procédé). En revanche, l'utilisation est liée au programme.
Loin de moi l'idée de critiquer nos chers logiciels libres (je n'ai qu'à contribuer :), mais Qemu n'est pas de tout repos à utiliser. Notamment la partie réseau, qui manque singulièrement de simplicité.
C'est justement là que je pense que Linux a un petit défaut :
Il n'y a aucun compromis entre le mode user (les applis normales) et le mode kernel (cette zone magique et obscure).
Peut-être manque-t-il une couche "driver" au kernel, avec une gestion limitée des droits d'accès au matos, vérifiée au moment du chargement du driver. Un truc du style "c'est un driver graphique, on n'a accès qu'à la carte graphique".
Cette couche doit avoir une API stable.
Après tout, comment font-ils sous Windows ? (je ne connais pas la réponse)
J'ai fait aussi mes benchmarks à 0.02 EUR, je confirme que java se rapproche de C++ en vitesse d'exécution. Des benchmarks "prouvent" que java va plus vite, mais bon ...
Mais comme il s'agit d'une réflexion sur les langages, il serait intéressant de comparer les résultats d'un gcj réellement efficace à une jvm afin de comparer la perte (ou le gain ?) de performance induite par la jvm.
Car, après tout, il serait intéressant de connaitre la véritable efficacité des programmes java, et non l'efficacité de la jvm, du garbage collector, et du bytecode intermédiaire.
Je pense qu'encourager gcj est fondamental, car le langage java me plait, mais pas la jvm (ou plutot la réputation de la jvm). En plus, gcj est libre, ce qui est fondamental pour un compilo.
D'après les benchmarks favorisant java par rapport à C++, le garbage collector serait plutôt favorable à la localité des données. Idem pour la compilation dynamique lorsqu'elle est stabilisée (lorsque la jvm est "chaude").
<mode wish>A quand une possibilité de faire du java sérieusement en utilisant exclusivement du libre, avec toute l'API et les dernières fonctionnalités en date ?</mode>
... En parlant de traditions,
il semblerait que OOo utilise des fonctionnalités mal (pas du tout ?) documentées (besoin de confirmer).
Si c'est bien le cas, on peut toujours attendre que GCJ fasse son travail correctement (ce ne sera pas la faute de GCJ)
Tiens, ca me rappelle une autre API ... Ah non, dans l'autre, ce sont les bugs qui sont documentés.
D'après un post d'une dépèche précédente, Apple rembourserait 50 euros si on renvoie l'OS 1 semaine après l'achat d'un Mac. Pas terrible, illégal, mais toujours mieux que rien ...
NON, et encore NON à la vente liée. Plus on le dira, mieux cela sera.
La loi est la même pour tous, faisons en sorte de l'appliquer.
Heureux possesseur d'un ordinateur portable Acer acheté en février 2004, je me suis vu refuser le remboursement de mes logiciels (XP, word, norton ...). En effet, je n'ai jamais utilisé Windows XP, et les CD de pilotes sont encore sous leur blister.
Même si le prix des OEM est faible, cela me fait mal d'avoir généré une vente de Microsoft, dont je n'admire que le génie commercial.
Car il est évident qu'aujourd'hui, Windows ne représente plus l'unique solution viable en matière d'OS pour PC, contrairement à une certaine époque (quoique l'argument ait une légitimité discutable ...).
Ce qui me met le plus en boule, c'est encore que les gens racontent qu'un ordinateur a besoin d'un OS pour fonctionner : faux et archi-faux : on peut très bien se contenter du CMOS (le menu du BIOS) pour faire des formatages de bas niveau (utilité discutable) ou imaginer avoir un CD auto-bootable pour chaque programme (comme dans les années 85-93, avec les fameux Atari ST/Commodore Amiga, ou encore les consoles de jeux). Je rappelle qu'au départ, les drivers sont censés être tous dans le BIOS et non dans l' "OS".
Quelqu'un peut-il confirmer mon impression : Windows est en train de basculer de la suprématie à un quasi-monopole.
Pas moins fructueuses qu'un autre type de "party" (install party, bug squashing, coding, ...) et très passionnantes, les traduc parties devraient se généraliser.
Pour un "petit traducteur", il est parfois difficile de se lancer, surtout lorsqu'on est acueilli froidement au sein du projet. Les traduc parties sont un bon moyen d'entrer dans le monde merveilleux de la traduction, et de ses passionnants problèmes (essayez de traduire plug-in, bookmark, proxy, string, ou même quit précisément et de manière compacte ...). Parfois, quelques habituels trolls squatent les débats, mais en général, l'ambiance des mailing lists de traduc est pas mal.
Encourageons donc ce genre d'initiatives. Le jour où il y aura des traduc, des install et des coding parties autant que des LAN parties, ... (faut pas rêver non plus).
Il y a DSL (Damn Small Linux) qui est en 2.4, qui ne fait que 50 Mo (et qui tient donc sur un CD buisnesscard), mais dont les fichiers de /var/lib/dpkg/info sont récupérables depuis internet. Je crois même qu'il y a une commande depuis la distrib pour le faire.
A noter que la distrib tourne sur des 486 avec 16mo de RAM et qu'elle peut, comme beaucoup d'autres, se charger entièrement en RAM.
Apparamment, Debian sort "quand elle est prête". Ce que je trouve bien, c'est qu'ils ne travaillent justement pas en fonction des dates, comme tu l'annonce (evidemment ton post était du second degré plus que bienvenu) mais en fonction du nombre de bugs.
En effet, je trouve louable qu'une distrib se tienne à une politique "0 défaut connu", bien plus louable qu'une politique "bleeding edge" (magnifiquement représentée par la branche experimental).
J'ai une question, qu'en est-il des rumeurs selon lesquelles quelques paquets seraient écartés au dernier moment pour accélérer la sortie ?
Si par dvdrip, tu entends dvd::rip, DCC live n'est pas utile.
dvd::rip (en fait, transcode, le backend en ligne de commande) gère les "clusters" tout seul en faisant encoder la moitié du film sur chaque machine.
DCC live est une solution de clustering généraliste, et sera moins performante que le système spécialisé.
[^] # Re: Firefox 3 ?
Posté par chaperon . En réponse à la dépêche Sortie de XulRunner 1.8.0.1. Évalué à 3.
Histoire d'enfoncer un peu les portes ouvertes ...
Le plus difficile dans des projets de cette envergure, c'est la conception d'architecture. Or, comme les changements d'architecture doivent se faire en douceur, sous peine d'incompatibilités majeures, Firefox 2.0 ne peut pas apporter de gros changements.
De même pour le développement de Linux : il ne se passe "rien" entre 2 versions majeures (c'est moins vrai actuellement), juste des ajouts mineurs, quelques évolutions. Mais en période "instable", le noyau subit des changements complets d'architecture.
Donc cette avance sur les versions est nécessaire, puisque la version 2.0 sera une sorte de suite logique, déjà figée, et la 3.0 doit se concevoir maintenant, avant que la 2.0 ne conditionne les évolutions de la 3.0.
[^] # Re: LRS sans ajout de serveur tiers ???
Posté par chaperon . En réponse à la dépêche LRS : support optimisé de LVM pour la sauvegarde système. Évalué à 5.
Sisi, j'ai vu faire, j'ai reproduit, j'ai testé, et ça marche !
Le pire, c'est que ça ne marche qu'en LVM (grâce à la fonction snapshot).
Faire une image de machine en dur, pas possible, car la copie type dd n'est pas atomique : si les données changent un peu partout en même temps, on obtient une image disque qui représente différents instants : problème !
En revanche, la magie du LVM permet de faire des clichés instantanés (atomiques) par des "bidouilles" plutôt ingénieuses (détournement des zones d'écriture sur le disque, pour conserver toutes les anciennes données intactes). On peut alors faire une image qui représente parfaitement un instant T.
Reste un petit souci pour cette méthode : lors de la restauration, on se retrouve avec une machine qui aurait rebooté "à la brute". En effet, le temps s'arrête au moment du snapshot et reprend au moment du boot de l'image restaurée. Mais avec un bon système de fichiers journalisé sur le LVM (ext3, ReiserFS, XFS, ... Reiser4 : ne trollez pas maintenant, SVP), aucun problème majeur observé à ce jour.
[^] # Re: Tout est clair
Posté par chaperon . En réponse au sondage La sécurité de mon WLAN. Évalué à 2.
diffusion SSID, pas de filtrage d'aucune sorte, pas de firewall (juste de la NAT), NFS, SAMBA, DHCP ...
Par contre, je me réserve le droit d'utiliser la machine de quiconque se conecte chez moi à mes fins personnelles.
Je pense que je vais mettre le symbole "wifi ouvert" en bas de chez moi :
)(
[^] # Re: Angoisse, Multivers et autres absurdités.
Posté par chaperon . En réponse à la dépêche La liberté, la face méconnue de l'informatique. Évalué à 2.
Voilà qu ferait une excellente signature :)
[^] # Re: Félicitations
Posté par chaperon . En réponse à la dépêche Le Ministère de l'Agriculture migre ses serveurs NT4 sous Linux. Évalué à 10.
Une telle attitude, c'est renier l'excellent travail fourni sur le format ELF (rappelez-vous le douloureux passage de a.out à ELF). Les liaisons dynamiques sont nickel (mieux qu'une DLL), tout roule à merveille. Les dépendances ? Aucun problème ! Un binaire ELF compilé en statique est certainement beaucoup plus portable que les "Portable Executable" de crosoft. Il suffit alors de mettre tout ça dans un "/opt" adéquat (fait pour ça en plus !) et tout va bien.
Lors du bidouillage de ma version d'un LiveCD minimal, je compilais sur ma machine, puis copiais "à la bourrin" les binaires. Un binaire, s'il trouve ses biblis, est content. Alors les vendeurs n'ont qu'à fournir la glibc, un binaire statique avec un lien dynamique vers ALSA, OpenGL ou SDL et c'est tout bon.
Quant-à DirectX, je trouve que SDL fait du bon boulot, mais manque un peu de drivers accélérés (le driver 2D X11 est assez pitoyable, le son est limite, l'interface OpenGL est pas mal). Regardez le travail magnifique de Loki pour le portage de Unreal Tournament.
[^] # Re: GPL-like vs BSD-like
Posté par chaperon . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 3.
Je plusse, je plusse. Il n'y a rien à rajouter.
# La magie du libre
Posté par chaperon . En réponse à la dépêche La FreeBox devient un media center grâce à VLC. Évalué à 4.
Qu'y a-t-il de si extraordinaire ? On peut utiliser autre chose que VLC si on le souhaite, tous les protocoles depuis le PC jusqu'à l'écran de TV sont parfaitement connus, Free joue la transparence sur le logiciel ...
N'empèche que si tous les FAI étaient aussi transparents au sujet de leurs bidouilles (pppoe/pppoa, plaques ECI/Alcatel, ...), ça irait mieux. Bon, d'accord, ça s'améliore mais bon ...
Dommage que je soie trop loin du répartiteur pour en profiter.
[^] # Re: Trouver un exemple concret
Posté par chaperon . En réponse à la dépêche L'ADULLACT prend position sur les brevets logiciels en Europe. Évalué à 1.
Les barres de progression (comme cité plus haut)
Les liens hypertexte (obligatoires) !
J'en passe, et je ne les connais pas tous ...
[^] # Re: Pas très étonnant
Posté par chaperon . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 3.
L'utilisateur lambda va être confronté au choix sur x86, et donc va choisir l'OS qui lui semble le mieux. Le problème, c'est qu'il choisira en fonction du marketing, et pas en fonction des qualités de l'OS (je ne parle même pas des avantages du "tout libre", qui passent à des années lumière des préoccupations de l'utilisateur-lambda).
Le problème, c'est qu'il y aura vraiement 3 types de raisonnements :
- Je veux faire du MSN et des jeux : Windows
- Je veux faire branché avec mes super effets et mes fenetres sans barre de menu : MacOSX
- Je veux utiliser ma machine a fond sans sacrifier la stabilité : GNU/Linux
Et sans compter les petits malins qui voudront les 3.
Par contre, peut-être que ça ouvrira les portes aux 2 aspirations les plus immédiates de certains linuxiens : avoir des drivers corrects (de la part des constructeurs, les programmeurs open source font deja de leur mieux) et pouvoir acheter des PC sans OS (ou avec un OS libre).
[^] # Re: Une joli GUI
Posté par chaperon . En réponse à la dépêche Sortie de l'émulateur Qemu 0.7.0. Évalué à 1.
Loin de moi l'idée de critiquer nos chers logiciels libres (je n'ai qu'à contribuer :), mais Qemu n'est pas de tout repos à utiliser. Notamment la partie réseau, qui manque singulièrement de simplicité.
[^] # Re: Juste une question
Posté par chaperon . En réponse à la dépêche Nouveau rebondissement dans l'affaire du pilote PWC. Évalué à 4.
Il n'y a aucun compromis entre le mode user (les applis normales) et le mode kernel (cette zone magique et obscure).
Peut-être manque-t-il une couche "driver" au kernel, avec une gestion limitée des droits d'accès au matos, vérifiée au moment du chargement du driver. Un truc du style "c'est un driver graphique, on n'a accès qu'à la carte graphique".
Cette couche doit avoir une API stable.
Après tout, comment font-ils sous Windows ? (je ne connais pas la réponse)
[^] # Re: bidon
Posté par chaperon . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Mais comme il s'agit d'une réflexion sur les langages, il serait intéressant de comparer les résultats d'un gcj réellement efficace à une jvm afin de comparer la perte (ou le gain ?) de performance induite par la jvm.
Car, après tout, il serait intéressant de connaitre la véritable efficacité des programmes java, et non l'efficacité de la jvm, du garbage collector, et du bytecode intermédiaire.
Je pense qu'encourager gcj est fondamental, car le langage java me plait, mais pas la jvm (ou plutot la réputation de la jvm). En plus, gcj est libre, ce qui est fondamental pour un compilo.
D'après les benchmarks favorisant java par rapport à C++, le garbage collector serait plutôt favorable à la localité des données. Idem pour la compilation dynamique lorsqu'elle est stabilisée (lorsque la jvm est "chaude").
<mode wish>A quand une possibilité de faire du java sérieusement en utilisant exclusivement du libre, avec toute l'API et les dernières fonctionnalités en date ?</mode>
[^] # Re: Les vieilles traditions
Posté par chaperon . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
il semblerait que OOo utilise des fonctionnalités mal (pas du tout ?) documentées (besoin de confirmer).
Si c'est bien le cas, on peut toujours attendre que GCJ fasse son travail correctement (ce ne sera pas la faute de GCJ)
Tiens, ca me rappelle une autre API ... Ah non, dans l'autre, ce sont les bugs qui sont documentés.
[^] # Apple rembourse(-t-il ?)
Posté par chaperon . En réponse à la dépêche Quatre actions contre la vente liée. Évalué à 2.
[^] # Re: Démagogie
Posté par chaperon . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à -1.
Utilisez WebCore plutot que KHTML pour que vous nous débuggiez gratis le code pourri qu'on a pondu.
# NON, et encore NON
Posté par chaperon . En réponse à la dépêche Quatre actions contre la vente liée. Évalué à 10.
La loi est la même pour tous, faisons en sorte de l'appliquer.
Heureux possesseur d'un ordinateur portable Acer acheté en février 2004, je me suis vu refuser le remboursement de mes logiciels (XP, word, norton ...). En effet, je n'ai jamais utilisé Windows XP, et les CD de pilotes sont encore sous leur blister.
Même si le prix des OEM est faible, cela me fait mal d'avoir généré une vente de Microsoft, dont je n'admire que le génie commercial.
Car il est évident qu'aujourd'hui, Windows ne représente plus l'unique solution viable en matière d'OS pour PC, contrairement à une certaine époque (quoique l'argument ait une légitimité discutable ...).
Ce qui me met le plus en boule, c'est encore que les gens racontent qu'un ordinateur a besoin d'un OS pour fonctionner : faux et archi-faux : on peut très bien se contenter du CMOS (le menu du BIOS) pour faire des formatages de bas niveau (utilité discutable) ou imaginer avoir un CD auto-bootable pour chaque programme (comme dans les années 85-93, avec les fameux Atari ST/Commodore Amiga, ou encore les consoles de jeux). Je rappelle qu'au départ, les drivers sont censés être tous dans le BIOS et non dans l' "OS".
Quelqu'un peut-il confirmer mon impression : Windows est en train de basculer de la suprématie à un quasi-monopole.
# Bonne initiative
Posté par chaperon . En réponse à la dépêche Traduc Party le 21 mai 2005 à la Cité des sciences. Évalué à 5.
Pour un "petit traducteur", il est parfois difficile de se lancer, surtout lorsqu'on est acueilli froidement au sein du projet. Les traduc parties sont un bon moyen d'entrer dans le monde merveilleux de la traduction, et de ses passionnants problèmes (essayez de traduire plug-in, bookmark, proxy, string, ou même quit précisément et de manière compacte ...). Parfois, quelques habituels trolls squatent les débats, mais en général, l'ambiance des mailing lists de traduc est pas mal.
Encourageons donc ce genre d'initiatives. Le jour où il y aura des traduc, des install et des coding parties autant que des LAN parties, ... (faut pas rêver non plus).
[^] # Re: Sur MiniCD
Posté par chaperon . En réponse à la dépêche Kaella 2.0 dans les bacs. Évalué à 2.
A noter que la distrib tourne sur des 486 avec 16mo de RAM et qu'elle peut, comme beaucoup d'autres, se charger entièrement en RAM.
http://www.damnsmalllinux.org
[^] # Re: C'est peut-être un peu faible pour une première page....
Posté par chaperon . En réponse à la dépêche Debian : Sarge prévue pour la fin du mois, chasse aux bogues, AMD64. Évalué à 3.
Apparamment, Debian sort "quand elle est prête". Ce que je trouve bien, c'est qu'ils ne travaillent justement pas en fonction des dates, comme tu l'annonce (evidemment ton post était du second degré plus que bienvenu) mais en fonction du nombre de bugs.
En effet, je trouve louable qu'une distrib se tienne à une politique "0 défaut connu", bien plus louable qu'une politique "bleeding edge" (magnifiquement représentée par la branche experimental).
J'ai une question, qu'en est-il des rumeurs selon lesquelles quelques paquets seraient écartés au dernier moment pour accélérer la sortie ?
[^] # Re: LiveCd et dvdrip
Posté par chaperon . En réponse à la dépêche DCC en LiveCD. Évalué à 4.
dvd::rip (en fait, transcode, le backend en ligne de commande) gère les "clusters" tout seul en faisant encoder la moitié du film sur chaque machine.
DCC live est une solution de clustering généraliste, et sera moins performante que le système spécialisé.