Je ne comprend pas l'arguments de la segmentation que tu donnes à l'encontre du propriétaire...
Au premier contact, jabber est beaucoup plus segmenté (puisque tout un tas de serveurs indépendants) que n'importe quel MSN/ICQ (pour ne nommer que ceux que j'ai expérimenté dans mes années pré-libristes).
Ou alors je n'ai pas compris le sens que tu voulais donner à ce mot...
Il me semble que tu n'as pas saisi le pourquoi de mon commentaire :) .
Je l'ai titré "humeur", ce qui selon moi veut dire qu'il s'agit d'un sentiment global face à un sujet.
Une analyse avec "état de l'art" des systèmes de fichiers me semble tout à fait nécessaire. Mais pour moi il manque (mais je n'ai pas assisté ni lu quoi que ce soit hormis cet - excelent - article sur cette réunion) quelque chose de fondamental : la définition des éléments nécessaires à manipuler pour pouvoir utiliser des périphériques de stockage.
Pour moi, ils se limitent strictement à :
-volume : représente une suite de disques ayant un point commun (appartenir à un même groupe défini par raid/lvm/...)
-disque : une suite finie de secteurs (malheureusement on ne peut pas descendre plus bas que le secteur, et on ne peut rien changer à ce niveau puisqu'un disque est physique - oui, ça surprend comme affirmation :) )
-fichier : regroupement de données ayant un point commun (appartenir à un même groupe défini par le fichier)
Donc, quelle est la différence entre une partition et un fichier ?
Quelle est la différence entre un système de partitionnement et un système de fichiers ?
Quelle est la différence entre un groupe de disques et un fichier ?
Bien entendu je ne parle pas des limitations que l'on doit aux implémentations actuelles, mais sur le principe de fonctionnement.
Pour moi il n'est pas bon d'ajouter "encore un niveau", mais plutôt d'unifier les niveaux existants, et on en sortira avec un système potentiellement récursif - donc scalable - restant facile à parcourir de par sont homogénéité en restant configurable : utiliser un groupe de disques comme un seul fichier, ou un disque comme une arborescence de morceaux indépendants inclus les uns dans les autres sur un disque.
Mais bon, quand bien même ça se trouverai être une bonne idée, quand bien même quelqu'un l'implémenterai, qui veut d'un système "révolutionnaire" quand le système habituel "marche". (clin d'oeil à hurd, et je --->[] )
J'aimerai bien qu'on m'explique ce que la fragmentation a de si lumineux. Si c'est la réponse à un besoin de scalabilité, c'est vraiment pas terrible.
Pour rappel, voilà les "chunks" déjà existants :
le bit (à mon avis, on ne peut rien faire à ce niveau)
l'octet (tiens, au fait, pourquoi 8 bits ?)
le secteur (512 octets sur un disque dur, 1024 parait-il sur un cd, ...)
la tête de lecture
le cylindre
(ces deux dernières notions semblent enfin tomber en décrépitude, mais sont toujours présentes)
le bloc vu par le système de fichier (un groupe de secteurs, taille variable suivant le système de fichier)
la partition (taille variable, avec une géométrie soumise à moultes contraintes, dures ou souples, comme la nécessité de contenir un nombre entier de secteurs, de commencer au début d'un cylindre, de finir à la fin d'un cylindre,...), avec un système de partitionnement qui peut lui même définir une avalanche de blocs imbriqués, cf. les partitions étendues
le disque
Voila tout ce qu'il faut déjà connaitre pour un système d'exploitation voulant accéder à un élément unique d'information.
Ensuite, il devra probablement le stocker en mémoire, dans le bon segment et la bonne page, nécessitant pour l'accès de grouper l'adresse physique en plusieurs (2 ?) paquets à envoyer successivement pour enfin accéder à un bloc de donnée de la taille du bus mémoire, etc...
L'informatique, ce yaourt avec d'authentiques morceaux de morceaux dedans. Et avec un êtit arière-goût de gachis de cycles machine et de bande passante, qu'on oublie quand tout marche.
Bon, je vous laisse, je vais développer à coups de caractères dans des lignes dans des fichiers dans des modules dans des projets dans des...
Je ne vois pas en quoi le chiffrement du flux en soit est un problème.
Les utilisateurs de SSH aussi changeraient de crèmerie si le flux de données devenait clair.
Ce qui peut devenir intéressant est de savoir si l'algorithme de chiffrement est libre, et son degré de parenté avec un DRM.
Dans le cas de la livebox de wanadoo par exemple, le flux vidéo n'est pas lisible (en tout cas je n'ai trouvé nulle part comment arriver au bout) en forçant une IP et une MAC (ça j'ai trouvé... une fois. J'ai pas remis la main dessus la deuxième fois) sur le récepteur et en utilisant un format vidéo non encore identifé.
J'ajouterai une info que j'avais bien apprécié sur les DRM : leurs promoteurs auraient fini par "avouer" que l'objectif final des DRM est d'empêcher un "utilisateur avancé" de tirer plein parti du matériel, c'est à dire de l'utiliser de façon non prévue dans le logiciel fourni par défaut. Effectivement ça me semble une bonne définition des DRM, préserver un marché pour la version n+1 sans que la version n modifiée n'entre en concurrence, sans avoir à redévelopper un matériel.
Donc longue vie aux firmwares alternatifs, openwrt, openslug, ipodlinux, freebios, openbios, openfreebox et j'en oublie. C'est en lui montrant qu'il est possible de tirer un meilleur parti d'un matériel que ce qui est concédé par le constructeur que le consommateur découvrira ce que je considère comme la face la plus hideuse des DRM.
J'espère que nVidia ne va pas arrêter pour autant son driver.
On peut dire ce qu'on veut, un driver propriétaire qui fonctionne ça reste mieux qu'un driver libre qui ne fonctionne pas.
je n'en souhaite pas moins une bonne persévérance à tous les contributeurs de cet ambitieux projet.
Non, les lois ne sont pas rétroactives pour autant que je sache.
Et au passage, rapellons quand même que le principe de base de l'informatique qui est que "cloner ne coute rien" : un bit reste identique après duplication, et le bit issu de la duplication est identique à l'original.
Donc tout ce qui tentera d'empêcher la copie sur un système reposant sur le principe de la copie sans dégradation est voué à l'échec.
Je voudrais citer un EDI ayant une approche de ce style (qui tient en un inspecteur d'objet plus complet que la moyenne, pour ce que j'en ai vu) pour ce qui est du dessin des interfaces graphiques :
Borland [Delphi|C++ Builder|Kylix]
Sorti du saimal saipalibreu, je ne vois (-yais) rien à reprocher à cet EDI. Je l'ai utilisé dans mes années pré-linux, et j'ai vraiment adoré. J'ai ensuite trouvé très domage que Kylix ait eu un écho aussi ténu, y compris la version gratuite autorisant la distribution GPL (à vérifier, je n'y ai pas remis les mirettes depuis un moment) des applications resultantes accompagnées les librairies Borland.
Je trouve que "bibliothèque" est plus adapté :
Une librairie, on y va pour acheter quelque chose.
Une bibliothèque, on emprunte.
Et les normes sont faites pour être suivies, pour moi le vocabulaire ne fait pas exception.
Disons que c'était un français transitionnel (transitoire ?) 1.0 : tout le monde comprend et - éventuellement - utilise, mais ça passe pas au validateur strict.
Bon, il est temps que j'arrête le langage de balises hyper-texte moi...
On peut en dire autant du paquet crystalspace (moteur de planeshift), presque autant de scummvm et wesnoth...
C'est comme une librairie (au sens de .so, librairie de fonctions), c'est inutile tant que personne ne s'en sert ( (c) Lapalice ).
Conaissant le renom de ce moteur, je pense que les dérivés vont fleurir. Et il me semble plus judicieux qu'ils utilisent tous la même version du moteur plutôt que de faire chacun sa modif dans son coin.
Donc le packager indépendament du contenu me parait une bonne idée, si ça peut permettre de centraliser les améliorations du moteur.
Pour debian, cf. popcon.debian.org .
En sid (installateur mettant grub par défaut depuis une dizaine de mois) :
lilo -> 3268
grub -> 4112
Donc grub gagne d'une courte tête le nombre d'installations.
Ensuite, savoir quel a été l'impact du choix par défaut, de l'habitude des utilisateurs, de l'échantillon d'utilisateurs utilisant le paquet popcon...
En fait, lilo stocke une position absolue sur le disque courant pour la position de son "stage2" (ou la liste des blocs qui le contiennent). Donc il est moins sensible aux modifications dans l'ordre des disques.
Mais ça le rend très chatouilleux si on change ledit stage2 de place...
Grub (1 & 2) "comprend" le système de fichiers, et est donc insensible au déplacement physique du fichier. Mais il en devient sensible au renommage et au changement dans le numéro de disque & partition.
Grub 2 corrige ce problème en permettant d'accéder très tôt à une console minimale, supportant le chargement de modules, le parcours des partitions et le parcours de système de fichiers.
Ces 2 derniers sont en fait des modules eux-mêmes, qu'il est possible d'intégrer en "dur" dans le code qui est installé dans le MBR (et ses alentours).
Sur x86 par exemple, on poura inclure pc.mod (module de lecture de la table de partitions DOS) et ext2.mod (pour lire... le système de fichiers ext2). Il faudra alors que les modules soient sur un disque avec une table de partition DOS (ou au pire sur une disquette) et dans une partition en ext2, et grub pourra alors tout charger.
Il reste la limitation de l'espace libre à proximité du MBR, limitation propre aux PC et qui empêche d'intégrer la reconnaissance de tous les systèmes de fichiers... Mais je ne pense pas que l'on y puisse grand chose.
D'un autre côté, qui a vérifié ligne par ligne que le code SELinux n'avait pas de backdoor ? Ou que tout est bien loggé ?
Pour moi la première faille d'un système informatique est la confiance de l'homme dans la machine, logiciel inclu.
La différence entre un logiciel opensource et un logiciel closedsource, c'est que la lecture du premier est plus aisée que la lecture du second. Mais cela n'implique pas que la tâche soit à échelle humaine.
Le tout est de savoir trouver la limite entre paranoïa, laxisme et ignorance.
J'irais même plus loin que ça contre son argument "les sociétés ne peuvent pas suivre" :
Si une boite copiait un gros projet, avec beaucoup de contributeurs, là oui ils ne pourraient probablement pas suivre. Mais je ne vois pas beaucoup de projets vraiment énormes sous GPL : le kernel, gcc et les outils gnu en général...
Par contre, un projet de l'envergure d'un lecteur multimédia ou d'un émulateur powerpc (au hasard :) ) ont vraiment besoin d'être protégés. Car quoi que fassent les bénévoles, s'ils sont peu nombreux et que le code reste somme toute à échelle humaine, ils ne pourront pas lutter contre une équipe de devs payés pour bosser dessus à plein temps.
D'autant plus que ce merveilleux système de diff (utilisé par CVS, SVN & co, mais ausi applicable à la main) leur permetrait de suivre l'évolution du logiciel sans avoir à relire toutes les sources à chaque release : ils n'ont donc plus qu'à intégrer ce travail déjà fait, certainement à un coût moindre que le développement de ces modifications.
Pour moi, oui, la protection légale qu'offre la GPL reste nécessaire.
Et pourtant, en tant que contributeur à grub 2 et donc ayant signé un contrat avec la FSF, je me rend compte à quel point il est dur de faire un logiciel libre dans le sens strict du terme : tout le code que je fournis (et dont le copyright va à la FSF) doit être de moi ou à la rigueur issu d'un autre projet de la FSF. Ce qui fait que le projet ne peut avancer aussi vite que l'on souhaiterai (il y a en ce moment une [1]discussion sur un problème dans le code de grub 2 pour la prise en charge d'un contrôleur clavier exotique qui montre cet aspect).
> je ne pense pas que l'aspect purement algorithmique y soit prépondérant
Pour avoir épluché des [1]graphes de "scalabilité" (lien posté dans un récent sondage), je dirais que le noyau linux 2.6 n'a plus grand chose à améliorer du point de vue algorythmique : une écrasante majorité des comportements testés se comportent en O(1).
Par contre, les applications - multimédia en tête - en profiteront certainement.
C'est vrai que les commandes ne m'ont pas paru intuitives : il y en a beaucoup, et ce n'est pas très "discoverable" (une idée de traduction ?). Je ne pense pas que Metisse puisse vraiment être utilisé en l'état.
(bon, je sens que mon taux de crédibilité descend là :) )
Je considère Metisse comme un bazar : plein d'idées mises en pratique, mais pas forcément bien intégrées ni sélectionnées. Je l'ai installé, j'ai joué avec, j'ai trouvé des idées drôlement bonnes, mais je suis retourné vers xfce4 pour ce qui est de mon utilisation quotidienne. Je ne me suis pas bagaré avec la config, donc il y a peut être des choses intéressantes de ce côté.
Si Exa implémente et intègre des fonctionnalités choisies de Metisse, j'y passerai certainement.
Il faut l'essayer pour comprendre.
Et il faut distinguer beautée d'ergonomie.
La rotation selon la normale à l'écran : déjà expliquée, pour les écrans à l'horizontale, pour agir comme s'il s'agissant de véritables documents, pour les montrer à des personnes qui seraient face à l'utilisateur de l'écran. Application limitée certes.
Rotation sur l'axe vertical et l'axe horizontal, zoom : permet de réduire la place prise par les fenêtres à l'écran, tout en pouvant surveiller l'activité. De plus, l'échelle d'une fenêtre peut varier lorsque la souris passe dessus ou lorsqu'elle reçoit le focus, pas besoin d'en changer manuellement.
Rognage des bords : bon, je ne suis pas convaincu, l'espace ainsi libéré n'est pas vraiment exploitable.
La transparece : permet d'empiler des fenêtres touten pouvant distinguer le contenu de fenêtres qui seraient ordinairement cachées.
Lorsqu'il nous a fait le cours, Nicolas Roussel a surtout insisté sur l'image du bureau. Un [vrai] bureau est toujours en bordel : une pile de papier là, on soulève le coin d'une page pour voir en dessous sans avoir à la déplacer, etc. Et il tente d'appliquer les opérations que l'on fait naturellement "physiquement" avec des feuilles de papier sur un bureau à des fenêtres de programmes dans un écran. Si toutes ces opérations ne sont pas un succès, elles ont au moins le mérite d'avoir été tentées, et je crois en ce genre de recherche fondamentale.
Pour paraphraser "The Art of Unix Programming" : ne pas refuser un moyen d'interraction avant de l'avoir réellement testé (l'idée original dans ce livre est "ne pas optimiser avant d'avoir éprouvé le bénéfice de l'optimisation par la pratique").
Si dans une équipe de 7 personnes - volontaires devant bien se connaitre pour se faire mutuellement confiance afin de faire bien leur boulot de publicateurs de patches de sécurité - une personne partvers une autre distribution, je pense que ça doit être relevé.
Il y a déjà assez de bonnes raisons pour un contributeur de passer innactif sans même parler de changement de distribution.
Ce genre d'évènement peut arriver à n'importe quelle distribution. De là à prophétiser la mort de debian en tant que distribution (là je me demande ce que Debian est si ce n'est une distribution, et donc ce qu'il en resterai si elle ne devait plus l'être), il y a de la marge.
> Debian n'est pas fiable !
Don't feed the troll.
Aparement celui-ci fait doublon avec celui sur la mailing list citée ci-dessus (peut-être es-ce un rejeton, les trolls trop nourris auraient tendance à se dupliquer).
> Sans Ubuntu je serais toujours avec une Mandrake
Oh, un deuxième !
Pauvre Mandr[ake|iva], quelle réputation elle a.
> mes contribs actuelles n'iraient pas davantage à Debian
Intéressant. Chacun ne contribuerai donc que pour sa paroisse ?
Désolé, mes contributions vont indifféremment à toutes les distributions. Si quelqu'un a remarqué que maintenant les sous-titres dans les applications utilisant libxine ne changent pas de taille suivant la longueur de la ligne, c'est une de mes contributions. Et il est hors de question que cette contribution n'aille qu'à Debian pour la seule raison que c'est la distribution que j'utilise.
J'utilise Debien pour 2 raisons principales :
-J'y suis habitué : un ami m'a aidé à installer une woody il y a 2 ans, et depuis je continue sur cette lancée.
-Elle fait partie des distributions qui mettent en valeur l'aspect libre des logiciels.
En tant que contributeur convaincu des bienfaits du libre, il est hors de question pour moi de limiter le champ de mes contributions en fonction de ma distribution : je les fait toutes "upstream", directement avec l'équipe du projet auquel je souhaite contribuer.
Je n'ai pas de temps à perdre à faire des mesquineries de contributeur atitré.
Je ne pense pas qu'un bureau rendu en OpenGL soit aussi avare en ressources qu'un jeu ou autre application de modélisation ou de rendu.
Par contre j'y vois de bonnes améliorations eye-candy et sur l'ergonomie du bureau. Voir par exemple [1]metisse, qui s'il est plus proche d'un statut d'expérimental reste néamoins une implémentation OpenGL avec des "modes d'interaction avec les fenêtres" qui vont avec :
-"peeling"
-rotation sur les 3 axes
-mise à l'échelle (permet entre autres de faire une "iconification" en réduisant la fenêtre à la taille d'une icône)
-véritable transparence, et sans avoir à faire d'opérations couteuses en temps CPU, le GPU sait faire ça.
Une chose à propos de la rotation sur 3 axes des fenêtres :
Les développeurs de ce logiciel font des recherches en ergonomie et l'un d'eux (que j'ai eu comme prof une partie du semestre dernier) nous a parlé d'un écran qui serait la surface d'une table. La rotation selon la normale à l'écran est à mon avis destinée à cette application.
Et un petit [2]screenshot pour la route. Il est à noter que toutes les applications sont bien fonctionelles (juste un petit bug avec les menus de firefox qui aparaissaient toujours verticaux). Je n'ai pas senti de ralentissement par rapport à un bureau "normal". Ah, et le fond d'écran est une image par défaut ;) .
Il en va de même pour les specs. J'ai cherché sur le site de Sun les specs d'une carte framebuffer Creator 3D (une mémé qui doit avoir dans les 6 ans) et j'en suis revenu bredouille. J'ai juste pu trouver un schéma montrant la position approximative des composants sur une carte de la même famille.
Ah oui, je n'ai pas commencé par le commencement. Pourquoi chercher les specs de cette carte ? Eh bien comme me le dit mon kernel favori :
config DRM_FFB
tristate "Creator/Creator3D"
depends on DRM && BROKEN
Il en va de même pour la carte son intégrée à mon Ultra10, qui est gérée par le module snd-sun-cs4231 mais qui présente de gros glitches (ou peut être viens-ce du bus "EBUS" sur lequelle elle est connectée ? etc...).
Et pourtant je n'ai pas l'impression que Sun fasse preuve de mauvaise volontée quand au support de ses ancienes bécanes.
C'est un exemple parmis d'autres des problèmes que posent les vieilles archis, et heureusement que je ne suis pas en charge du service qualité d'une distro, sinon je crois que je ferais ce genre de découverte très souvent.
[^] # Re: Jabber-only
Posté par Vincent Pelletier . En réponse au sondage Quel client Jabber/XMPP j'utilise tous les jours ?. Évalué à 3.
Au premier contact, jabber est beaucoup plus segmenté (puisque tout un tas de serveurs indépendants) que n'importe quel MSN/ICQ (pour ne nommer que ceux que j'ai expérimenté dans mes années pré-libristes).
Ou alors je n'ai pas compris le sens que tu voulais donner à ce mot...
[^] # Re: Humeur
Posté par Vincent Pelletier . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 1.
Je l'ai titré "humeur", ce qui selon moi veut dire qu'il s'agit d'un sentiment global face à un sujet.
Une analyse avec "état de l'art" des systèmes de fichiers me semble tout à fait nécessaire. Mais pour moi il manque (mais je n'ai pas assisté ni lu quoi que ce soit hormis cet - excelent - article sur cette réunion) quelque chose de fondamental : la définition des éléments nécessaires à manipuler pour pouvoir utiliser des périphériques de stockage.
Pour moi, ils se limitent strictement à :
-volume : représente une suite de disques ayant un point commun (appartenir à un même groupe défini par raid/lvm/...)
-disque : une suite finie de secteurs (malheureusement on ne peut pas descendre plus bas que le secteur, et on ne peut rien changer à ce niveau puisqu'un disque est physique - oui, ça surprend comme affirmation :) )
-fichier : regroupement de données ayant un point commun (appartenir à un même groupe défini par le fichier)
Donc, quelle est la différence entre une partition et un fichier ?
Quelle est la différence entre un système de partitionnement et un système de fichiers ?
Quelle est la différence entre un groupe de disques et un fichier ?
Bien entendu je ne parle pas des limitations que l'on doit aux implémentations actuelles, mais sur le principe de fonctionnement.
Pour moi il n'est pas bon d'ajouter "encore un niveau", mais plutôt d'unifier les niveaux existants, et on en sortira avec un système potentiellement récursif - donc scalable - restant facile à parcourir de par sont homogénéité en restant configurable : utiliser un groupe de disques comme un seul fichier, ou un disque comme une arborescence de morceaux indépendants inclus les uns dans les autres sur un disque.
Mais bon, quand bien même ça se trouverai être une bonne idée, quand bien même quelqu'un l'implémenterai, qui veut d'un système "révolutionnaire" quand le système habituel "marche". (clin d'oeil à hurd, et je --->[] )
# Humeur
Posté par Vincent Pelletier . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 2.
Pour rappel, voilà les "chunks" déjà existants :
le bit (à mon avis, on ne peut rien faire à ce niveau)
l'octet (tiens, au fait, pourquoi 8 bits ?)
le secteur (512 octets sur un disque dur, 1024 parait-il sur un cd, ...)
la tête de lecture
le cylindre
(ces deux dernières notions semblent enfin tomber en décrépitude, mais sont toujours présentes)
le bloc vu par le système de fichier (un groupe de secteurs, taille variable suivant le système de fichier)
la partition (taille variable, avec une géométrie soumise à moultes contraintes, dures ou souples, comme la nécessité de contenir un nombre entier de secteurs, de commencer au début d'un cylindre, de finir à la fin d'un cylindre,...), avec un système de partitionnement qui peut lui même définir une avalanche de blocs imbriqués, cf. les partitions étendues
le disque
Voila tout ce qu'il faut déjà connaitre pour un système d'exploitation voulant accéder à un élément unique d'information.
Ensuite, il devra probablement le stocker en mémoire, dans le bon segment et la bonne page, nécessitant pour l'accès de grouper l'adresse physique en plusieurs (2 ?) paquets à envoyer successivement pour enfin accéder à un bloc de donnée de la taille du bus mémoire, etc...
L'informatique, ce yaourt avec d'authentiques morceaux de morceaux dedans. Et avec un êtit arière-goût de gachis de cycles machine et de bande passante, qu'on oublie quand tout marche.
Bon, je vous laisse, je vais développer à coups de caractères dans des lignes dans des fichiers dans des modules dans des projets dans des...
[^] # Re: Interet de la chose ?
Posté par Vincent Pelletier . En réponse à la dépêche Modifier le firmware d'une Freebox grâce à OpenFreeBox. Évalué à 10.
Les utilisateurs de SSH aussi changeraient de crèmerie si le flux de données devenait clair.
Ce qui peut devenir intéressant est de savoir si l'algorithme de chiffrement est libre, et son degré de parenté avec un DRM.
Dans le cas de la livebox de wanadoo par exemple, le flux vidéo n'est pas lisible (en tout cas je n'ai trouvé nulle part comment arriver au bout) en forçant une IP et une MAC (ça j'ai trouvé... une fois. J'ai pas remis la main dessus la deuxième fois) sur le récepteur et en utilisant un format vidéo non encore identifé.
J'ajouterai une info que j'avais bien apprécié sur les DRM : leurs promoteurs auraient fini par "avouer" que l'objectif final des DRM est d'empêcher un "utilisateur avancé" de tirer plein parti du matériel, c'est à dire de l'utiliser de façon non prévue dans le logiciel fourni par défaut. Effectivement ça me semble une bonne définition des DRM, préserver un marché pour la version n+1 sans que la version n modifiée n'entre en concurrence, sans avoir à redévelopper un matériel.
Donc longue vie aux firmwares alternatifs, openwrt, openslug, ipodlinux, freebios, openbios, openfreebox et j'en oublie. C'est en lui montrant qu'il est possible de tirer un meilleur parti d'un matériel que ce qui est concédé par le constructeur que le consommateur découvrira ce que je considère comme la face la plus hideuse des DRM.
# J'espère que...
Posté par Vincent Pelletier . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à -2.
On peut dire ce qu'on veut, un driver propriétaire qui fonctionne ça reste mieux qu'un driver libre qui ne fonctionne pas.
je n'en souhaite pas moins une bonne persévérance à tous les contributeurs de cet ambitieux projet.
[^] # Re: confusion...
Posté par Vincent Pelletier . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 5.
Par exemple... SPARCv9 qui date de 1995 et qui est à l'origine des processeurs UltraSPARC de Sun (64 bits bien entendu).
[^] # Re: Protégeons VRAIMENT les oeuvres
Posté par Vincent Pelletier . En réponse à la dépêche Projet de loi DADVSI: EUCD.INFO publie un dossier d'information complet et un appel. Évalué à 2.
Et au passage, rapellons quand même que le principe de base de l'informatique qui est que "cloner ne coute rien" : un bit reste identique après duplication, et le bit issu de la duplication est identique à l'original.
Donc tout ce qui tentera d'empêcher la copie sur un système reposant sur le principe de la copie sans dégradation est voué à l'échec.
# approche radicalement différente
Posté par Vincent Pelletier . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 2.
Borland [Delphi|C++ Builder|Kylix]
Sorti du saimal saipalibreu, je ne vois (-yais) rien à reprocher à cet EDI. Je l'ai utilisé dans mes années pré-linux, et j'ai vraiment adoré. J'ai ensuite trouvé très domage que Kylix ait eu un écho aussi ténu, y compris la version gratuite autorisant la distribution GPL (à vérifier, je n'y ai pas remis les mirettes depuis un moment) des applications resultantes accompagnées les librairies Borland.
# [X] Je viens de me faire embaucher
Posté par Vincent Pelletier . En réponse au sondage Mon emploi actuel. Évalué à 2.
[^] # Re: 1st post
Posté par Vincent Pelletier . En réponse à la dépêche Le moteur du jeu Quake 3 en GPL. Évalué à 3.
Une librairie, on y va pour acheter quelque chose.
Une bibliothèque, on emprunte.
Et les normes sont faites pour être suivies, pour moi le vocabulaire ne fait pas exception.
Disons que c'était un français transitionnel (transitoire ?) 1.0 : tout le monde comprend et - éventuellement - utilise, mais ça passe pas au validateur strict.
Bon, il est temps que j'arrête le langage de balises hyper-texte moi...
[^] # Re: 1st post
Posté par Vincent Pelletier . En réponse à la dépêche Le moteur du jeu Quake 3 en GPL. Évalué à 7.
C'est comme une librairie (au sens de .so, librairie de fonctions), c'est inutile tant que personne ne s'en sert ( (c) Lapalice ).
Conaissant le renom de ce moteur, je pense que les dérivés vont fleurir. Et il me semble plus judicieux qu'ils utilisent tous la même version du moteur plutôt que de faire chacun sa modif dans son coin.
Donc le packager indépendament du contenu me parait une bonne idée, si ça peut permettre de centraliser les améliorations du moteur.
[^] # Re: lilo ou grub
Posté par Vincent Pelletier . En réponse au journal Sortie de Grub 1.90. Évalué à 2.
En sid (installateur mettant grub par défaut depuis une dizaine de mois) :
lilo -> 3268
grub -> 4112
Donc grub gagne d'une courte tête le nombre d'installations.
Ensuite, savoir quel a été l'impact du choix par défaut, de l'habitude des utilisateurs, de l'échantillon d'utilisateurs utilisant le paquet popcon...
[^] # Re: lilo ou grub
Posté par Vincent Pelletier . En réponse au journal Sortie de Grub 1.90. Évalué à 4.
Mais ça le rend très chatouilleux si on change ledit stage2 de place...
Grub (1 & 2) "comprend" le système de fichiers, et est donc insensible au déplacement physique du fichier. Mais il en devient sensible au renommage et au changement dans le numéro de disque & partition.
Grub 2 corrige ce problème en permettant d'accéder très tôt à une console minimale, supportant le chargement de modules, le parcours des partitions et le parcours de système de fichiers.
Ces 2 derniers sont en fait des modules eux-mêmes, qu'il est possible d'intégrer en "dur" dans le code qui est installé dans le MBR (et ses alentours).
Sur x86 par exemple, on poura inclure pc.mod (module de lecture de la table de partitions DOS) et ext2.mod (pour lire... le système de fichiers ext2). Il faudra alors que les modules soient sur un disque avec une table de partition DOS (ou au pire sur une disquette) et dans une partition en ext2, et grub pourra alors tout charger.
Il reste la limitation de l'espace libre à proximité du MBR, limitation propre aux PC et qui empêche d'intégrer la reconnaissance de tous les systèmes de fichiers... Mais je ne pense pas que l'on y puisse grand chose.
[^] # Re: Se battre contre les boites noires ( le droit au bug )
Posté par Vincent Pelletier . En réponse au journal Cisco voit rouge.. Évalué à 1.
Pour moi la première faille d'un système informatique est la confiance de l'homme dans la machine, logiciel inclu.
La différence entre un logiciel opensource et un logiciel closedsource, c'est que la lecture du premier est plus aisée que la lecture du second. Mais cela n'implique pas que la tâche soit à échelle humaine.
Le tout est de savoir trouver la limite entre paranoïa, laxisme et ignorance.
[^] # Re: Allo ?
Posté par Vincent Pelletier . En réponse à la dépêche Les navigateurs Web, Firefox et les parts de marchés en Europe. Évalué à 1.
Et même un feu troll, vu qu'il a été assasiné par la FAQ citée plus bas par netsurfeur.
[^] # Re: Mais nous on aime la GPL
Posté par Vincent Pelletier . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 10.
Si une boite copiait un gros projet, avec beaucoup de contributeurs, là oui ils ne pourraient probablement pas suivre. Mais je ne vois pas beaucoup de projets vraiment énormes sous GPL : le kernel, gcc et les outils gnu en général...
Par contre, un projet de l'envergure d'un lecteur multimédia ou d'un émulateur powerpc (au hasard :) ) ont vraiment besoin d'être protégés. Car quoi que fassent les bénévoles, s'ils sont peu nombreux et que le code reste somme toute à échelle humaine, ils ne pourront pas lutter contre une équipe de devs payés pour bosser dessus à plein temps.
D'autant plus que ce merveilleux système de diff (utilisé par CVS, SVN & co, mais ausi applicable à la main) leur permetrait de suivre l'évolution du logiciel sans avoir à relire toutes les sources à chaque release : ils n'ont donc plus qu'à intégrer ce travail déjà fait, certainement à un coût moindre que le développement de ces modifications.
Pour moi, oui, la protection légale qu'offre la GPL reste nécessaire.
Et pourtant, en tant que contributeur à grub 2 et donc ayant signé un contrat avec la FSF, je me rend compte à quel point il est dur de faire un logiciel libre dans le sens strict du terme : tout le code que je fournis (et dont le copyright va à la FSF) doit être de moi ou à la rigueur issu d'un autre projet de la FSF. Ce qui fait que le projet ne peut avancer aussi vite que l'on souhaiterai (il y a en ce moment une [1]discussion sur un problème dans le code de grub 2 pour la prise en charge d'un contrôleur clavier exotique qui montre cet aspect).
[1] http://lists.gnu.org/archive/html/grub-devel/2005-07/threads.html(...) titre : "Broken A20 gate handling", lire notament les réponses de Y. K. Okuji
[^] # Re: Des algos spécifiques pourraient en tirer parti?
Posté par Vincent Pelletier . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 4.
Pour avoir épluché des [1]graphes de "scalabilité" (lien posté dans un récent sondage), je dirais que le noyau linux 2.6 n'a plus grand chose à améliorer du point de vue algorythmique : une écrasante majorité des comportements testés se comportent en O(1).
Par contre, les applications - multimédia en tête - en profiteront certainement.
[1] http://bulk.fefe.de/scalability/(...)
# Brevets logiciels, saimal
Posté par Vincent Pelletier . En réponse à la dépêche Manifestation contre les brevets logiciels au Parlement Européen à Strasbourg. Évalué à 10.
Quand on vous dit que les brevets logiciels c'est mal :).
Désolé, j'ai pas pû me retenir.
Je ->[] de ce pas. En plus y'a peut être déjà mes résultats à la fac, je rentabiliserai la sortie.
[^] # Re: Serveur X sur OpenGL ?
Posté par Vincent Pelletier . En réponse à la dépêche Exa, une nouvelle architecture accélérée pour les drivers Xorg. Évalué à 3.
http://insitu.lri.fr/~chapuis/metisse/running.html(...)
C'est vrai que les commandes ne m'ont pas paru intuitives : il y en a beaucoup, et ce n'est pas très "discoverable" (une idée de traduction ?). Je ne pense pas que Metisse puisse vraiment être utilisé en l'état.
(bon, je sens que mon taux de crédibilité descend là :) )
Je considère Metisse comme un bazar : plein d'idées mises en pratique, mais pas forcément bien intégrées ni sélectionnées. Je l'ai installé, j'ai joué avec, j'ai trouvé des idées drôlement bonnes, mais je suis retourné vers xfce4 pour ce qui est de mon utilisation quotidienne. Je ne me suis pas bagaré avec la config, donc il y a peut être des choses intéressantes de ce côté.
Si Exa implémente et intègre des fonctionnalités choisies de Metisse, j'y passerai certainement.
[^] # Re: Serveur X sur OpenGL ?
Posté par Vincent Pelletier . En réponse à la dépêche Exa, une nouvelle architecture accélérée pour les drivers Xorg. Évalué à 3.
Et il faut distinguer beautée d'ergonomie.
La rotation selon la normale à l'écran : déjà expliquée, pour les écrans à l'horizontale, pour agir comme s'il s'agissant de véritables documents, pour les montrer à des personnes qui seraient face à l'utilisateur de l'écran. Application limitée certes.
Rotation sur l'axe vertical et l'axe horizontal, zoom : permet de réduire la place prise par les fenêtres à l'écran, tout en pouvant surveiller l'activité. De plus, l'échelle d'une fenêtre peut varier lorsque la souris passe dessus ou lorsqu'elle reçoit le focus, pas besoin d'en changer manuellement.
Rognage des bords : bon, je ne suis pas convaincu, l'espace ainsi libéré n'est pas vraiment exploitable.
La transparece : permet d'empiler des fenêtres touten pouvant distinguer le contenu de fenêtres qui seraient ordinairement cachées.
Lorsqu'il nous a fait le cours, Nicolas Roussel a surtout insisté sur l'image du bureau. Un [vrai] bureau est toujours en bordel : une pile de papier là, on soulève le coin d'une page pour voir en dessous sans avoir à la déplacer, etc. Et il tente d'appliquer les opérations que l'on fait naturellement "physiquement" avec des feuilles de papier sur un bureau à des fenêtres de programmes dans un écran. Si toutes ces opérations ne sont pas un succès, elles ont au moins le mérite d'avoir été tentées, et je crois en ce genre de recherche fondamentale.
Pour paraphraser "The Art of Unix Programming" : ne pas refuser un moyen d'interraction avant de l'avoir réellement testé (l'idée original dans ce livre est "ne pas optimiser avant d'avoir éprouvé le bénéfice de l'optimisation par la pratique").
[^] # Re: le vilain méchant Ubuntu
Posté par Vincent Pelletier . En réponse à la dépêche Debian Sarge a des problèmes sérieux de gestion de la sécurité. Évalué à 7.
Il y a déjà assez de bonnes raisons pour un contributeur de passer innactif sans même parler de changement de distribution.
Ce genre d'évènement peut arriver à n'importe quelle distribution. De là à prophétiser la mort de debian en tant que distribution (là je me demande ce que Debian est si ce n'est une distribution, et donc ce qu'il en resterai si elle ne devait plus l'être), il y a de la marge.
> Debian n'est pas fiable !
Don't feed the troll.
Aparement celui-ci fait doublon avec celui sur la mailing list citée ci-dessus (peut-être es-ce un rejeton, les trolls trop nourris auraient tendance à se dupliquer).
> Sans Ubuntu je serais toujours avec une Mandrake
Oh, un deuxième !
Pauvre Mandr[ake|iva], quelle réputation elle a.
> mes contribs actuelles n'iraient pas davantage à Debian
Intéressant. Chacun ne contribuerai donc que pour sa paroisse ?
Désolé, mes contributions vont indifféremment à toutes les distributions. Si quelqu'un a remarqué que maintenant les sous-titres dans les applications utilisant libxine ne changent pas de taille suivant la longueur de la ligne, c'est une de mes contributions. Et il est hors de question que cette contribution n'aille qu'à Debian pour la seule raison que c'est la distribution que j'utilise.
J'utilise Debien pour 2 raisons principales :
-J'y suis habitué : un ami m'a aidé à installer une woody il y a 2 ans, et depuis je continue sur cette lancée.
-Elle fait partie des distributions qui mettent en valeur l'aspect libre des logiciels.
En tant que contributeur convaincu des bienfaits du libre, il est hors de question pour moi de limiter le champ de mes contributions en fonction de ma distribution : je les fait toutes "upstream", directement avec l'équipe du projet auquel je souhaite contribuer.
Je n'ai pas de temps à perdre à faire des mesquineries de contributeur atitré.
[^] # Re: Serveur X sur OpenGL ?
Posté par Vincent Pelletier . En réponse à la dépêche Exa, une nouvelle architecture accélérée pour les drivers Xorg. Évalué à 8.
Par contre j'y vois de bonnes améliorations eye-candy et sur l'ergonomie du bureau. Voir par exemple [1]metisse, qui s'il est plus proche d'un statut d'expérimental reste néamoins une implémentation OpenGL avec des "modes d'interaction avec les fenêtres" qui vont avec :
-"peeling"
-rotation sur les 3 axes
-mise à l'échelle (permet entre autres de faire une "iconification" en réduisant la fenêtre à la taille d'une icône)
-véritable transparence, et sans avoir à faire d'opérations couteuses en temps CPU, le GPU sait faire ça.
Une chose à propos de la rotation sur 3 axes des fenêtres :
Les développeurs de ce logiciel font des recherches en ergonomie et l'un d'eux (que j'ai eu comme prof une partie du semestre dernier) nous a parlé d'un écran qui serait la surface d'une table. La rotation selon la normale à l'écran est à mon avis destinée à cette application.
Et un petit [2]screenshot pour la route. Il est à noter que toutes les applications sont bien fonctionelles (juste un petit bug avec les menus de firefox qui aparaissaient toujours verticaux). Je n'ai pas senti de ralentissement par rapport à un bureau "normal". Ah, et le fond d'écran est une image par défaut ;) .
[1] http://insitu.lri.fr/~chapuis/metisse/(...)
[2] http://moule.org/screenshots/metista.jpg(...)
[^] # Re: demain j'arrête...
Posté par Vincent Pelletier . En réponse au sondage Promis, demain je teste. Évalué à 2.
Mes 2 yens avant que je ->[]...
[^] # Re: Et la liberté d'expression?
Posté par Vincent Pelletier . En réponse à la dépêche Un enseignant d'une université espagnole censuré pour avoir défendu les réseaux P2P. Évalué à 6.
Et comme toutes les apogées, on ne veut pas en redescendre quand on y est.
[^] # Re: Tirer les bonnes conséquences !
Posté par Vincent Pelletier . En réponse au sondage Sarge is out. Évalué à 1.
Ah oui, je n'ai pas commencé par le commencement. Pourquoi chercher les specs de cette carte ? Eh bien comme me le dit mon kernel favori :
config DRM_FFB
tristate "Creator/Creator3D"
depends on DRM && BROKEN
Il en va de même pour la carte son intégrée à mon Ultra10, qui est gérée par le module snd-sun-cs4231 mais qui présente de gros glitches (ou peut être viens-ce du bus "EBUS" sur lequelle elle est connectée ? etc...).
Et pourtant je n'ai pas l'impression que Sun fasse preuve de mauvaise volontée quand au support de ses ancienes bécanes.
C'est un exemple parmis d'autres des problèmes que posent les vieilles archis, et heureusement que je ne suis pas en charge du service qualité d'une distro, sinon je crois que je ferais ce genre de découverte très souvent.