🚲 Tanguy Ortolo a écrit 12091 commentaires

Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc !

Non. Un périphérique bloc peut avoir des blocs de taille différente.

J'ai vu une clef USB avec des blocs de 2 ko, qui fonctionnait à merveille sous Linux, qu'on pouvait partitionner avec Parted et tout. Comme c'était une clef de promotion Microsoft, je pense qu'elle devait être bien prise en charge également sous Windows.

Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.

Tel que je vois les choses, un SSD, une clef USB ou n'importe quel medium de stockage par blocs devrait exposer une taille de bloc optimale pour son travail. Si ma clef USB expose des blocs de 512 octets, et que ses eraseblocs font 4 ko, c'est le problème de son fabricant qui est un tocard, et ce n'est certainement par le du système de fichiers, de la couche d'accès blocs ou du système d'exploitation. Donc pas au système de se préoccuper de ça : utilisons les blocs fournis par les périphériques.

<img src="…"></img> ?

Ça fait franchement extra-terrestre… :-)

Je sais pas si il existe déjà quelque chose qui va dans ce sens sous Linux.

Sous Linux, non, mais sous Unix, oui, depuis le début. Il me semble que /bin et /usr/bin sont distincts pour pouvoir mettre /bin (qui sert plus souvent) sur un tambour magnétique plus rapide que le reste.

Bon à savoir, ça. Ils utilisent aussi le Debian-installer, au fait : Ubuntu peut donc être installé tout comme Debian, depuis un disque optique minimal, un jeu de disques optiques, une clef USB, un noyau et un initrd chargés par PXE…

Un truc marrant, au passage : essayez l'installateur Debian graphique pour Ubuntu : c'est un logo Debian, en haut ! :-)

Tu mets donc une balise à contenu (fut-il distant) en auto-fermant... Bien bien bien...

Tu utilises souvent des <img></img> ?

Pas mal de media Flash sont amovibles, donc vous allez être confrontés à un problème courant : un ami m'a passé une clef USB, mais il est 1001 alors que je suis 1000, donc je ne peux pas modifier les fichiers.

En clair : les permissions Unix, c'est cool… sauf sur les périphériques qui servent pour échanger des documents, où c'est franchement nuisible.

Donc, s'il vous plaît, dans ce système de fichiers du futur, pourriez-vous, au choix :
- rendre optionnelle la prise en charge des UID, et en faire une option du système de fichiers ;
- proposer un mécanisme de mapping d'UID, en option de montage ?

Non, pas disque dur, justement ! Lecteur, périphérique, tout ce que vous voulez, mais pas disque dur. :-)

D'ailleurs, le mot « drive » est déjà présent dans le sigle SSD, donc parler de lecteur SSD, c'est comme parler de disque CD…

Donc XHTML 1.0 Transitional ovni, certainement pas, mais Strict et 1.1 oui.

Ben évidemment, vu que Strict 1.1, ça doit être servi en application/xhtml+xml, et ça, c'est refusé par le sous-navigateur, malheureusement encore très utilisé.

XHTML est une belle plantade en matière de norme, 70% du web est encore en HTML 4 quand au xhtml déclaré proprement avec version xml et encoding il fait figure d'ovni.

http://fr.wikipedia.org/, http://www.ibm.com/, http://www.ubuntu.com/ …

Je continue ?
http://www.lemonde.fr/, http://www.france-info.com, http://www.lefigaro.fr/

D'autres ?
http://www.microsoft.com/

XHTML, OVNI ? J'ai des doutes, là. Bien sûr, tout ça est servi en tant que HTML (text/html), parce que sinon, ce serait inaccessible sous le navigateur à la masse. Mais XHTML est certainement utilisé. Si demain, je veux faire un site Web, j'ai le choix entre HTML 4 et XHTML : franchement, qui hésiterait une seconde ?

Désolé pour la multiplicité des commentaires : je ne veux pas mettre des trucs qui n'ont rien à voir dans un seul commentaire.

En passant, je serais curieux de connaître la procédure officielle des gens de ubuntu/canonical pour générer les ISO officielles...

Ça, c'est à mon avis la grande différence entre Ubuntu et Debian. :-)

Canonical a fait des live-CD à l'ancienne, ça a titillé Debian, qui a ainsi produit live-helper, un outil permettant de générer des live-{CD, DVD, clef USB} personnalisés, pour 13 architectures. Merci Ubuntu d'avoir montré la voie, merci Debian d'avoir fait ce grand travail (dont Ubuntu peut maintenant profité, et qui sera peut-être mis à profit par Canonical).

Un truc présent sur les live-CD officiels d'Ubuntu, et pas sur ceux générés par live-helper (je crois) : l'installateur graphique d'Ubuntu.

Est-il disponible sous la forme d'un paquet, qu'il suffirait d'installer dans le système cible live-helper, pour qu'il soit présent dans le système live ?

Inutile de passer par unetbootin, si c'est pour faire une clef USB démarrable :

$ lh_config -b usb-hdd


Dans ce cas, Qemu avec kqemu !

Jamais vu de </script> dans la norme... Et je vois pas trop l'intérêt non plus.

Je parle de <script/>, pas de </script>. :-)
Intérêt ? Éviter une absurdité du genre : <script src="pouet.js"></script>, qu'on remplace alors par une auto-fermante : <script src="pouet.js"/>.

GNI ? C'est pas parce que le mime type est fixé sur text/html que ca gène en quoi que ce soit le parcours ou l'édition du DOM.

Tu as essayé ? Moi, oui. J'avais un site servi en application/xhtml+xml pour tout le monde, sauf bien sûr pour Explorer, pour lequel je déclarais du text/html. Je voulais, depuis une page, en télécharger une autre (avec XmlHttpRequest) pour l'anayser. Et bien, l'analyse marchait partout, sauf dans Explorer, tout simplement parce que du text/html, ben ce n'est pas du XML.

IE connait parfaitement le XHTML/XML, le connait depuis 1999 (depuis les premiers drafts), le connaissait avant Netscape.

Oui mais non. Il l'accepte quand on le déclare comme du HTML, ce qui :
- est anormal (c'est du XHTML, pas du HTML !) ;
- empêche d'utiliser certaines possibilités du XHTML (des <script /> plutôt que <script></script>) ;
- empêche d'avoir un vrai DOM XML sur les pages ainsi servies.

C'est logique, qu'il faille être root : il y a des trucs à monter en loopback, et du chroot à faire.

Oups, pardon, le coup est parti trop vite.


$ kvm -cdrom ubuntu.iso


Toute petite remarque, pour tester, il y a plus simple que VirtualBox (clic, nouvelle machine virtuelle, clic, nouveau répertoire, clic, utiliser l'image ISO, clic, démarrer) : KVM/Qemu.


$ kvm ubuntu.iso


On peut difficilement imaginer plus simple, non ?

Si SVG n'a aucun succes, c'est parce qu'il n'a aucun tool d'edition, principalement.

Hein ? Inkscape, non ?

Debian a créé un outil pour personnaliser à fond ses live-{cd, clef USB, netboot PXE} : live-helper. C'est lui qui permet de créer les media Debian-live officiels.

Il est dommage, pour une distribution basée sur Debian, de devoir trifouiller seul pour contourner les limites d'un système qui n'est pas fait pour être personnalisé. Live-helper doit bien être disponible pour Ubuntu, non ?

On parle d'Explorer toutes versions, pas seulement le 6. Aucune version d'Explorer n'accepte le XHTML.

Du vrai XHTML, c'est plus strict donc plus rapide à parser, et ça donne accès au DOM XML, autant que je sache.

Super, c'est une obligation maintenant de supporter tous les standards existants ?

Les standards du Web depuis 8 ans, ouais. Sinon, ça s'appelle être à la rue, tout simplement.

Windows 1252 est standardise : http://www.iana.org/assignments/charset-reg/windows-1252

Oui, il est standardisé. Mais si tu me relis, c'est ça dont je me plains :

Content-Type: text/plain; charset=latin-1

[des trucs en Windows-1252]


Sender ID est un standard experimental au meme titre que SPF, partant de la, qui te dit que c'est pas SPF qui est incompatible avec Sender ID ?

Oui, mais la différence, c'est que Sender ID a plein de problèmes, notamment de propriété intellectuelle, et par conséquence ne pourra jamais passer à l'état de standard. En plus, Sender ID utilise les enregistrements DNS définis pour SPF, de façon incompatible avec ce dernier. Et enfin, il est ambigu sur le domaine à vérifier (MAIL FROM: ou PRA ?), là où SPF est univoque.

C'est ironique ? L'OASIS, l'IETF et le W3C seraient contents de se faire traiter de hippies…

Non, juste du fait que, quand on regarde, dans un logiciel, les exceptions prévues pour pallier aux défauts de certaines implémentations, on a plus d'une chance sur deux de tomber sur un truc du style :

# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0