Sébastien Koechlin a écrit 850 commentaires

PS: bon et puis comme on est quand même sur linuxfr ici, petite question finale: à quand les install party "dans le noir"??? ;-)

Avec un menu surprise ? Tiens, j'ai eu une Redflag Linux en xfs (c'était la semaine asiatique).

S'il y avait, ne serait-ce que les noms des fichiers, ça aiderait peut-être un peu.

Et imaginons qu'un gars réponde à ces critières, il faudrait que les poursuites à l'encontre de "DVD Jon" ne le décourage pas.

DVD Jon a fait de la publicité autour de son travail, mais avec les joies d'internet, rien n'interdit à quelqu'un de publier son travail anonymement.

Il y a quelques développeurs de drivers Linux (probablement pas aux USA) qui ont ouvert des serveurs FTP avec upload garanti "sans logs" dans lesquels ils trouvent de temps en temps des specs et des bouts de code qui sont arrivés là tout seul et qui documentent le fonctionnement de certains matériels dont la documentation n'est pas publique.

Avec Freenet, on peut faire la même chose facilement j'imagine.

Pareil, quelques commandes chez Houra, une chez Auchan direct, j'ai déjà eu un article abimé; mais remboursé sans soucis.

Une fois, le livreur qui avait oublié un carton, est même repassé le soir à la fin de sa tournée.

Visiblement les mousquetaires ne sont pas au niveau.

Voici quelques remarques:

Tu fais des tests avec -s pour savoir si le fichier existe. En général on utilise plutot le -r.

-s FILE True if file exists and is not empty.
-r FILE True if file is readable by you.

Si le fichier est vide, on s'en fiche un peu, ça n'empèche pas de le sourcer; par contre, s'il n'est pas lisible, ça va provoquer une erreur. Il est aussi possible de remonter une erreur si le fichier n'est pas lisible.

Tu retournes l'aide en exécutant pratiquement vingt fois la commande echo. Dans bash, c'est une commande interne qui ne fait peut-être pas un fork, mais avec d'autres shell, cela peut faire appel à une commande externe. Pour cela, on préfère généralement faire un seul echo, ou un cat

echo -e "Première ligne\\nSeconde ligne"

echo "Première ligne
Seconde ligne"

ou encore

cat << _VERSION_
Première ligne
Seconde ligne
_VERSION_


Si le wget retourne une erreur, tu ne testes rien, tu te contentes de regarder si quelque chose sort au bout de la chaine.
L'adresse IP du routeur est codée en dur à 192.168.1.1
wget utilise la version courte des paramêtres, rendant la relecture du script plus compliquée.
Il y a aussi une dépendance sur logger, je ne sais pas s'il est présent sur toutes les distribs, sous les BSD...

Voila, sinon c'est encourageant de voir qu'il y a encore des choses écrites proprement. Quand je vois ce pourquoi on paye au boulot...

Je pense que c'est le cas, au boulot on a des dizaines de serveurs avec des JVM sous tout un tas d'OS et clairement, Windows n'est pas favorisé par rapport à Linux.

Si je me souviens bien, les benchs faisaient resortir que les versions Sparc/Solaris étaient plutôt plus performantes, mais ça date de Java 1.2; je n'ai pas fait de bench sur des versions plus récentes pour voir la différence.

Sous windows y'a d'autres trucs à faire dans le panneau de configuration:
- Changer la langue du clavier
- Inverser les boutons de la souris
- Accélérer ou ralentir la souris au maximum
- Mettre le délai de répétition des touches au minimum

Ce sont aussi des choses que l'on peut faire sous X avec la commande xset.

La commande iptables permet de faire cela, et de manière bien plus fine, elle est également un peu plus pénible à utiliser parce qu'elle controle l'effective group id (egid). Voir le paragraphe sur le module "owner" de la page de manuel.

Il est possible de bloquer l'accès à certain site, à certains ports, à certaines heures, de laisser la résolution de nom (souvent utile)...

Excuse moi, j'ai lu trop vite la question.

Les interfaces réseaux ne sont pas dans /dev/ parce que les gens qui l'ont développé ont estimé que cela n'apportait rien. Le Linux Networking Howto dit http://www.tldp.org/HOWTO/NET3-4-HOWTO-5.html#ss5.3

In many Unix operating systems the network devices have appearances in the /dev directory. This is not so in Linux. In Linux the network devices are created dynamically in software and do not require device files to be present.

Les périphériques dans /dev/ ont deux analogies possibles:
- ceux en mode bloc, comme un disque dur, sur lequel on peut se positionner, lire et écrire à une position arbitraire
- ceux en mode caractère, comme un terminal, sur lequel on se contente de lire les octets dans l'ordre ou ils arrivent et ou aucun déplacement dans le flux n'est possible.

Une interface réseau ne présente aucune analogie ni avec le mode bloc ni avec le mode caractère. On pourrait éventuellement lui trouver une ressemblance avec le mode caractère dans le cas où l'on récupère tout ce qui passe sur le médium de transmission (première couche OSI http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI ), et écrire du code pour faire l'abstraction, mais
- la variété des supports rend cette analogie douteuse et sans grand intérêt (liaison série point à point, ethernet, carte réseau sans fil à sauts de fréquence...)
- cela n'est pas toujours disponible ou souhaitable pour des raisons de performance, les cartes tendent à gérer des choses de plus en plus haut niveau par elles même dans la couche OSI (Retransmission, checksums variés, ARP, découpage TCP... voir le Via Velocity VT6122 http://www.vntek.com/en/products/velocity/ qui est dans la Dedibox de Iliad)

Donc le noyau n'a pas de périphérique à présenter parce qu'il n'y aurait rien à faire dessus.

Au début, ça gène un peu l'utilisateur, un peu plus avec udev et consorts parce qu'on prends l'habitude de regarder dans /dev/ pour voir ce qui existe; et puis on s'y fait.

Est-ce que tu vois un usage des interfaces réseau dans /dev/ ?

/dev/ethX sont les noms habituels des périphériques ethernet. Le Wi-Fi est très éloigné d'ethernet, il n'y a pas vraiment de raison de lui donner ce nom, au contraire.

Par contre, je suis d'accord qu'un peu d'unité dans les noms des périphériques Wi-Fi ne ferait pas de mal.

Vous trouverez à l'adresse suivante

http://www.linux-watch.com/news/NS6755691725.html

un texte de Vaughan-Nichols's qui donne pas mal de précision sur le code de Devicescape

Le travail de Devicescape avec le kernel n'a pas commencé le 1er mai; et ils n'ont pas travaillé tous seuls dans leur coin, sans quoi il y aurait vraiment peu de chances que ce qu'ils ont produit soit intégré dans le kernel.

On peut voir en lisant http://lwn.net/Articles/179305/ qui a déjà été cité; que Devicescape a beaucoup travaillé avec les gens du noyau. Ils étaient présent au 2006 Wireless Networking Summit les 6 et 7 avril chez OSDL et sont des contributeurs majeurs. C'est ce qui donne de la valeur au don de code de Devicescape.

Cela ne change rien au fait que l'annonce a eu lieu le 1er mai et qu'avant, aucune annonce officielle n'avait été faite, ni de Devicescape, ni sur LinuxFR.

Encore faudrait-il qu'il dise ce que fait ce fameux logiciel.

C'est pas très clair votre histoire.

On ne sait pas trop quel couche se colle où, qu'est ce qu'il faut découper (et avec quoi ? Un cutter si c'est collé ?)

Qu'obtient-on au final ? Un tissus collé, un papier collé, comment est-ce que ça résiste aux lavages ?

Pas de problème, normalement ;-)

UTF-8 permet de représenter le code d'un caractère jusqu'à 21 bits, ces 21 bits sont répartis dans 4 octets.

Il serait possible d'étendre UTF-8 pour coder jusqu'à 31 bits, mais la norme d'aujourd'hui l'interdit (cela ferai 6 octets pour les caractères de code élevé).

En UTF-16, c'est plus compliqué, parce qu'on fait l'extension sur une plage de non-caractères (qui deviennent alors non-représentable, mais les utilise-t'on si ce sont des non-caractères), il est possible de représenter 20 bits, auquels viennent s'ajouter les 16 bits des caractères ordinaire (à l'exception de la plage des non-caractères).

En UCS-2, on peut représenter 16 bits

En UCS-4 on peut représenter 32 bits

En UTF-32, qui est un sous-ensemble de UCS-4, on peut représenter un peu moins de 21 bits, (de U+0 à U+10FFFF), parce que la norme interdit d'aller plus loin.

Finalement nous n'avons aucun mécanisme qui permettent de représenter un caractère de code arbitraire, quelque soit les extensions que nous feront à la norme Unicode si elle évolue encore.

Je ne connais pas la réponse à la question parce qu'il s'agit de détails d'implémentation, mais il y a trois solutions, ou familles de solution, plus ou moins couteuses:

* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.

* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.

* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.

Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.

PNG ne permet pas de représenter des animations, pour cela il faut utiliser le MNG dont l'implémentation est nettement moins universelle.

Concernant SVG, j'espère bien que l'on va y venir; mais aujourd'hui, les implémentations ne permettent pas vraiment de l'utiliser.

Les deux grandes implémentations à ma connaissance sont Mozilla Firefox sur des versions franchement récentes, et un plugin pour Internet Explorer. Qu'en est-il des autres navigateur. De plus, on parle ici d'animation, l'animation se fait par l'utilisation de javascript sur l'arbre XML du SVG, les résultats sont franchement déconcernants et les deux implémentations sont très divergentes.

J'ajoute une petite précision.

Unicode n'est pas un mécanisme de codage des caractères, c'est juste une norme qui attribue une valeur numérique (non bornée) à un symbole.

L'UTF-8, UTF-16 dont des mécanismes qui utilisent un codage des caractères unicode de taille variable comme cela a été dit.

Pour un programme, avoir une taille variable n'est vraiment pas pratique, il faut parcourir la chaine depuis le début pour interpréter les octets et retrouver les caractères. Les logiciels utilisent plutot une représentation en taille fixe.

La représentation en taille fixe la plus connue est ASCII, dont est dérivée toute la série des iso-8859-x célèbre, mais qui limitent toujours à 2^7 (127) les caractères en dehors de l'ASCII.

Pour représenter plus de caractère, les deux normes les plus utilisées sont
* UCS2 qui code les caractères sur 2 octets, cette norme ne permet d'utiliser que les caractères unicode dont le code est inférieur à 2^16
* UCS4 qui code les caractères sur 4 octets, limitant cette fois-ci les symboles aux 2^32 premiers. Comme il n'y a pour l'instant aucun caractères unicode au dela, cette norme est pour l'instant exhaustive.

UCS2 est la norme qui dont être utilisée en interne par Java.

Absolument pas.

Ta carte vidéo n'utilise pratiquement jamais les 64 Mo de mémoire dont elle dispose. Cette mémoire est utilisée par les moteurs 3D pour stocker les textures qui seront appliqués sur les triangles.

Lorsqu'on est en 2D classique, la mémoire occupée est au minimum de celle de l'affichage. Pour du 640x480 en 8 bits, il faut 1 octet par pixel, soit dans les 300 Ko de mémoire. Pour du 1280x2024 en 32 bits ça donne 5.2 Mo.

Selon la façon dont le serveur travail, il est possible d'avoir en fait deux fois écran (double buffering) mais le second n'est pas forcément mappé en mémoire (cette technique est une solution pour éviter les bavures lorsqu'on dessine sur l'écran en même temps que l'on affiche).

Certains serveurs X sont capable de récupérer le reste de la mémoire inutilisée (les 60 Mo) pour y stocker les polices de caractère pré-rendues. (sous réserve, c'était le cas il y a 10 ans, je ne sais pas comment cette fonctionnalité à évoluée depuis).

Donc le fait que X ne fasse pas plus de 64 Mo de résident ne veut absolument pas dire que cette mémoire ne contient pas la mémoire de la carte vidéo utilisée par X.

J'utilise joe en permanence; il est léger, se lance très vite, tourne partout.

La liste des commandes n'est pas astronomique, on y trouve juste ce dont on a besoin. Il est possible de redéfinir les touches, d'écrire des commandes, d'enregistrer et de jouer des macros, de passer un fichier ou des parties dans un filtre... très très très pratique.

Avec find on peut faire le rm peut-être plus simplement :

find . -size 0 -exec rm {} \;

Si on veut faire moins de fork et parce que rm supporte plusieurs fichiers en même temps, on peut faire

find . -size 0 -type f -print0 | xargs -0

Le -type f ne sélectionne que les fichiers, et le -print0/-0 permet de fonctionner avec des noms de fichier contenant des espaces.

Les claviers sont construits, comme tout le reste, à l'économie.

Comme prévoir des pattes et des liaisons dans un composant coute plus cher que de multiplier les transistors qu'il contient; les controleurs de clavier n'ont pas 110 ports; mais plutot dans les 20. Pour repérer une touche ordinaire, il suffit de détecter un contact à l'intersection de N ports.
Lorqu'on a une matrice, ça fonctionne encore correctement, mais quand on augmente le nombre de contact à détecter, on crée des zones d'ombre, et une touche pressée en masque d'autres.

Toute l'astuce est dans le calcul des zones d'ombre qui sont prévues pour éviter qu'une combinaison ne soit pas détectée.

Les touches modifiantes [Shift], [Control]... ont généralement une ligne dédiée quand même.

Vous pouvez lire un message de Linus à ce sujet qui date de 1997 http://www.uwsg.iu.edu/hypermail/linux/kernel/9708.1/0233.ht(...)

Personne n'a pensé qu'il serait peut-être utile de dire ce qu'est Wengo ? Si Firefox a eu suffisement de publicité pour que l'on puisse éventuellement s'en passer, ce n'est pas le cas de Wendo.

Si on ne veut pas que Linux reste un sujet réserver aux initiés, il faut éviter ce genre de message cryptique.

Je ne vois pas trop en quoi la syntaxe wiki est plus agréable. On pourrait faire exactement la même chose en utilisant des < et > plutot que des [ et ] avec l'avantage que ça ressemble un peu plus à du HTML.

En prime, la syntaxe wiki n'est pas très claire; comment fait-on pour mettre du texte entre crochets ? Pour représenter un < en html, on sait clairement ce qu'il faut faire.

Il y a déjà eu des fuites de parties du code source de Windows, et d'après ce que j'ai lu à ce sujet (de mémoire, c'était il y a longtemps), ceux qui ont observé le code l'ont trouvé de qualité tout à fait correct.

La seconde remarque est qu'il est truffé de code conditionnel afin d'émuler de nombreux bugs, soit de versions précédentes de windows, soit d'applications. Comme il est inacceptable que la nouvelle version de windows ne fonctionne pas avec tel soft populaire, il y a des hacks de contournement qui représentent un volume considérable de code.

Ce n'est pas parce que le code est correct que tout fonctionne bien; dans un projet de la taille de windows, il faut encore avoir une conception correct, un découpage bien fait, des API adaptés... Tout le boulot n'est pas dans l'implémentation.

Quand aux commentaires humoristiques, aux insultes et autres, (comme ceux du kernel Linux ou des sources de Netscape à sa publication); le source de Windows étant déjà distribué a plein de monde, le ménage a probablement déjà été fait.