🚲 Tanguy Ortolo a écrit 12224 commentaires

GNU/Linux != Ubuntu !LTS.

#aptitude install ubuntu-lts
# aptitude install debian

Au fait, préinstallé, le Windows en question ? Parce que va installer toi-même Windows XP : pas d'accélération graphique, pas de réseau filaire, pas de réseau sans fil.

Essaie DebianEeePC. Je l'ai installée sur Mon 901 : tout marche.

J'ai pensé la même chose en lisant la première phrase, Asus comme tous les autres constructeurs ne devraient pas avoir une "obligation" de neutralité vis à vis de l'OS?

Un obligation de quoi ?

ASUS recommande Windows Vista® Edition Familiale Premium

le menu de gnome est aussi efficace (plus ?) que le menu démarrer de windows

Plus : c'est un fait objectif. Le menu FreeDesktop.org a été bien conçu, pour être fédéré, modulaire et localisable. Le résultat est évident : c'est mieux, clairement mieux.

Bravo pBpG, tu va finir par me faire croire que ma grand-mère et mes parents sont des super geeks.

Oui, ils sont sous Debian. Mais de là à être des geeks… Je leur ai justement installé Debian parce que c'était plus simple pour eux.

j'adore Battle of Wesnoth

For. La bataille pour Wesnoth.

*Box ?

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