ribwund a écrit 1439 commentaires

Il est très précoce si il a à peine 16 ans, vu qu'il dit commencer l'internat de médecine (perso je préfèrerais pas tomber sur lui à l'hôpital).

Et 17 ans plus tard, on ne l'entend toujours pas critiquer Windows (Hurd SVN ou gnome par contre oui, mais c'est une autre histoire) et encore moins Mac qu'il utilise.

Il utilise des Macs, mais pas MacOS, ça fait quand même une diff...

C'est juste une histoire de mettre les bons labels SELinux non ?

Surtout que les rayons CD de la Fnac rétrecissent d'une façon impressionant, dès qu'on veut sortir des chemins battus ça sert à rien, autant commander direct en ligne.

Après renseignement les deux marchent :)

cmason: I say butterfs
cmason: but, lots of people say betterfs which is fine too

C'est quoi et ça en est où btrfs ? Comment ça se prononce?

Si je me souviens bien c'est "better FS".

Si tu lis la suite du thread tu verras qu'il y a un mode spécial pour SSD dans btrfs, et donc ce n'est pas juste qu'il accepte le SSD. Par exemple pour le wear leveling, d'après ce que j'ai compris, le fait de repartir et de dupliquer les superblocs aide beaucoup.

A priori pas de problèmes pour btrfs:
http://oss.oracle.com/pipermail/btrfs-devel/2008-February/00(...)

Autant la loi est dangereuse (privation de liberté sans passage devant l'autorité judiciaire), autant je vois pas en quoi c'est une attaque envers les logiciels libres, et à mon avis ils ont bien fait attention pour pas qu'on puisse les attaquer sous cette angle (si ils ont retenu l'experience de la DADVSI).

Il peut donc ne rien faire et considérer les noms de fichiers comme une suite de bytes, comme tout les programmes UNIX.

D'où le "par exemple" dans ma phrase, après quelques litres de bières, j'ai déjà eu du mal à retrouver le bug ;)

C'était du au passage à GIO et c'est corrigé, voir par exemple:

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/222150

Par contre y'a une loi qui interdit à Barroso d'y répondre favorablement:
The members of the Commission shall be chosen on the ground of their general competence and European commitment from persons whose independence is beyond doubt.

In carrying out its responsibilities, the Commission shall be completely independent. Without prejudice to Article 18(2), the members of the Commission shall neither seek nor take instructions from any Government or other institution, body, office or entity. They shall refrain from any action incompatible with their duties or the performance of their tasks.

(désolé c'est en anglais mais http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:C:2(...) marche pas en ce moment)

Conformément à l'article 250 §1 du traité CE, le Conseil statue à la majorité qualifiée avec l'accord de la Commission. En revanche, s'il s'écarte de la position de la Commission, il lui faut réunir l'unanimité.

http://ec.europa.eu/codecision/stepbystep/text/index2_fr.htm(...)

Après j'ai pu mal interpréter, c'est tellement compliqué le processus décisionnaire européen :/

À mon avis c'était l'ultime manoeuvre de Sarkozy pour sauver les meubles, et c'était un peu désespéré.
Si la Commission ne rejette pas l'amendement il faut l'unanimité au Conseil pour qu'il soit retiré (autrement il aurait fallu un majorité c'est déja plus faisable), donc c'est foutu. Donc on fait n'importe quoi, Vivianne Redding ne veut pas le retirer (elle commence sa campagne pour sa réelection, donc elle veut pas se mettre le Parlement à dos), alors Sarkozy décide de passer à l'échelon supérieur et envoie une lettre à Barroso, avec le résultat que l'on sait.

Sinon c'est pas vraiment régulier pour un chef d'état d'essayer de forcer la main de la Commission, il est pas loin de franchir la ligne sur ce point.

Finalement Barroso aime pas trop les procédés de Sarkozy:
http://www.macplus.net/magplus/depeche-19759-riposte-graduee(...)

Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...

Même chaque fichier, un cas très courant c'est 2 utilisateurs sur un même filsystem avec des locales différentes.

Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?

Sauf que dans ce cas c'est POSIX qu'il faut changer (rendre unicode obligatoire pour les noms de fichiers, et changer les systèmes de fichiers en conséquence), pour unix les noms de fichiers sont des octets.

Sinon à mon avis il faudrait unifier les deux API (win et linux) et par exemple toujours convertir les chaînes unicode en UTF-8 sous windows quand on utilise l'API bytes, ainsi le code pour open() sous windows décoderait à partir de l'utf-8 quand on lui passe des bytes.

On peut remercier RedHat/Fedora pour ça. Ça apporte le partage du réseau (par NAT), un bout de support IPv6 et le support des téléphones mobiles.

En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup. Sur mercurial les chemins de fichiers ne sont limités que par les limitations de unix (ou de la plateforme pour le checkout, on peut enregistrer des fichiers qui ne peuvent être checkouté que sous ext3).

Je pense quand même que le coup des bytes est par forcement une amélioration (surtout le fait de passer la gestion de fichier en unicode, je vois pas comment ça peut marcher sous Unix, sauf si on décide que tout le monde utilise UTF-8 en locale, et même comme ça ça doit être possible de créer un fichier qui fera planter python, ou mal fonctionner un programme parce que le dev aura pas pensé à ce cas particulier et utilisera l'API unicode), en pratique ça complique beaucoup le code pour nous (j'espere juste que ça s'améliorera).

Merci pour tes patches et ta volonté de faire avancer python sur ce problème.

J'étais encore mitigé sur python 3.0, mais après avoir testé les bytes/string/unicode pour voir si c'était possible de porter mercurial, je suis relativement déçu.

En effet c'est un énorme merdier la gestion des noms de fichiers. Étant donné que sous linux c'est fondamentalement des bytes, pourtant la plupart des fonctions os renvoient des strings (donc unicode). En fait actuellement c'est encore plus le bordel vu que ça peut renvoyer un mélange de bytes et de str. Par contre sous windows c'est de l'unicode derriere.

Franchement je vois pas quelle solution peut marcher, pour mercurial on a besoin d'avoir des listes de fichiers de façon indépendante de l'OS et du charset, c'est pas trop possible...

Voir http://bugs.python.org/issue3187 pour le bugreport.

Le kernel peut tout faire, sous windows ou sous linux, si du code dans le kernel veut flinguer un périphérique il peut le faire.

C'est pas la critique de GregKH en tout cas :)
J'ai l'impression que le problème est plus philosophique, alors que dans certaines distros le but c'est de porter le moins de patch par rapport à upstream (exemple le kernel dans fedora), ça ne dérange pas ubuntu d'avoir des hacks même si ce n'est qu'une solution à court terme.

Et aussi c'est pas parce qu'on critique ubuntu que c'est pas une distro qu'utilise et qu'on apprécie par ailleurs (c'est mon cas). Pourquoi vouloir toujours défendre Canonical ? Tu crois pas que certaines critiques sont fondées ? Est ce que pour 10 personnes embauchées pour faire du support ils pourraient embaucher un dev qui fait du travail 100% upstream ?

Mais non, les "anti-ubuntu" se sont focalisés sur Launchpad (va savoir pourquoi) qui doit ABSOLUMENT être libre selon eux.

Ça peut être compréhensible quand on sait que pour Shuttleworth c'est la plateforme ultime pour les bugs, le code, etc. qui devrait être utilisée par tout le monde.

C'est uniquement les bugreports, ça compte pas les patches contenus dans le paquet ubuntu sans qu'une solution propre soit recherchée upstream (et perso c'est ça que je reproche, idéalement les seuls patches dans les paquets ubuntu ça devrait être du branding).