Amand Tihon a écrit 734 commentaires

Quelqu'un de doué pour dessiner ou adapter une affiche de propagande à l'ancienne avec le texte « When you use IE, you're helping communism » ?

Ça n'aura jamais été aussi vrai et ça fera peut-être migrer quelques Américains vers un navigateur alternatif :)

C'est juste l'inverse !

700 Mio = 734003200 octets = 734 Mo

1 Mio = 1024 Kio = 1048576 octets.
1 Mo = 1000 Ko = 1000000 octets.

Les "nouvelles" unités sont les unités binaires, qui comptent bien en exposant de 2.

Tu pensais plutôt à Clonezilla : http://clonezilla.org/ :)

J'utilise pas mal Clonezilla au boulot, mais lorsqu'il s'agit de faire du disaster recovery j'ai toujours tendance à privilégier Mondo Rescue : http://www.mondorescue.org/ (peut-être par habitude).

Les stations linux qu'on déploie ont un appel à mondo en crontab. Toutes les semaines, une ISO prête à être gravée est sauvée sur un point de montage NFS.

s/maintenir/manger la version carte perforées de/

Sans sel.

De toute façon, quelles que soient les permissions sur le .htaccess, toute personne ayant accès en écriture sur le répertoire peut effacer le fichier, éventuellement pour le remplacer par un autre.
Ce changement de droits est complètement inutile parce que justement, l'utilisateur du site, pour pouvoir uploader ses fichiers, a les droits en écriture sur le dossier.

Elle avait vraiment marqué les esprits à l'époque.

Il en existe même une version pour Commodore 64, assez incroyable : [http://www.youtube.com/watch?v=zVPW40ygds4] !
Par la suite, on a également vu apparaître une version "live", Real Reality: [http://www.youtube.com/watch?v=-Da6e-BjhWM].

C'est complètement arbitraire, parce que je n'ai plus de x86-32 sous la main pour tester¹. Et puis, quand on a un peu goûté à l'asm x86-64, on n'a plus trop envie de se replonger dans le 32, si limité en registres :)

Toute la logique du link est strictement identique en 32 et 64 bits, "seules" les structures de données diffèrent. Il n'est pas du tout exclu que bold supporte un jour le x86-32, voire même d'autres architectures (là je m'avance peut-être un peu, encore que...).

Certaines parties on un peu été codées à la Rache® et demanderont une réorganisation pour pouvoir gérer le 32 bits facilement.

Bon, je dois aussi admettre que l'esprit de la Demo, c'est un peu de faire ce que personne n'a fait avant et les intros pour x86_64 sont rares :)

¹) Comme je n'utilise pas du tout la libc, il faut faire appel aux syscalls, qui ne sont pas couverts par la couche de compatibilité 32 bits offerte par Linux. Cela dit, le runtime de bold n'en utilise qu'un : SYS_exit.

Merci pour tes deux liens.

Je ne me suis pas penché sur le problème du "sub-string collapsing" parce qu'en général, quand le binaire est limité en taille de cette manière, peu de bibliothèques sont utilisées (SDL et GL suffisent souvent). Les noms des bibliothèques étant les seules entrées de la strtab, les collisions sont virtuellement inexistantes.

En ce qui concerne la compression, bold ne fait rien lui-même. La solution retenue et communément acceptée est d'utiliser un dropper, une petite ligne de script shell insérée avant le fichier compressé.
#!/bin/sh
a=/tmp/I;tail -n+3 $0|zcat>$a;chmod +x $a;$a;rm $a;exit
[binaire compressé]


De cette manière, le décompresseur est très court. Ceux qui veulent jouer la sécurité peuvent se baser sur gzip, mais lzma commence à être de plus en plus présent et même à faire partie des paquets "obligatoires" des grandes distributions (j'ai déjà recensé debian, opensuse, mandriva, slackware, gentoo, arch, fedora, ubuntu). bzip2, lui, est rarement efficace sur des petits fichiers.

Il y a des gens qui retirent même le shebang du dropper, mais en pratique, je constate que ça pose quand même pas mal de problèmes.

J'utilise le twinview, kde4 et kwin, sur une Debian sid.

Pour autant que je sache, parce que c'est quelque chose que je désactive, n'y trouvant pas de réel avantage, les effets de bureau/composite fonctionnent.

Nous sommes plusieurs dans mon département à être passés au E6500. Les utilisateurs sont en majorité sous OpenSuse et Ubuntu.
La coque noire brossée fait très classe, et ses angles lui donnent un petit air de thinkpad de luxe :)
Nous avons le modèle avec écran 1920x1200, et la batterie étendue.
En utilisation, wifi allumé, l'autonomie atteint facilement 4 heures. Si tu ne l'utilises pas, et que le rétro-éclairage de l'écran se coupe, la bête tient aisément 5 heures.

Ce qui fonctionne :
Presque tout, en fait...
La carte intel, y compris en dual screen, avec ou sans le dock.
Le wifi, à condition d'accepter le firmware pas libre.
Le clavier est vraiment très agréable.
Le bluetooth.
Mise en veille, boutons spéciaux, etc. Je n'ai constaté aucun problème de ce coté.

Ne fonctionne pas :
Le lecteur de smartcard Broadcom. Si j'en crois le résultat de mes recherches, son firmware est tout foireux.

Pas testé :
La webcam, nos modèles n'en ont pas.

En bref, un excellent portable pour travailler. Il est cependant un peu lourd à mon goût pour être trimbalé toute la journée dans un sac à dos.

Ce que le module serial te retourne, ce sont des caractères, pas des valeurs.

Heureusement, il existe une fonction interne qui permet de récupérer le code d'un caractère : ord(). À toi d'utiliser hex() sur le résultat, ou d'afficher autrement.

>>> ord('\xFF')
255
>>> hex(ord('\xFF'))
'0xff'
>>> "%X" % ord('\xFF')
'FF'


(Les caractères "spéciaux" vont-ils passer correctement ? La prévisualisation les transforme en entités mais je tente quand même.)

Je dois bien admettre que cette construction qui utilise l'opérateur modulo est une petite merveille : tout à la fois concis et très pratique (quand on ne doit pas jouer avec des traductions qui changent l'ordre des arguments).

La réflexion d'un collègue découvrant une dizaine de lignes de python pour la première fois : « Ah, ils ont intégré le formatage à la printf directement dans le langage, ça c'est une bonne idée ! »

Enfin, heureusement, ça existe toujours dans la version 3.

J'aurais seulement une petite question à laquelle le (très intéressant) article ne répond pas.

Est-ce utilisable en production aujourd'hui ? Quelle version du noyau au minimum ?

Avant de l'utiliser sur un FS de quelques To, j'aimerais autant avoir l'un ou l'autre retour :-)

Et ces drivers sont libres ?

C'est GPL, il existe des paquets deb et rpm pour x86 32 et 64 bits, et les sources des pilotes (tant cupswrapper que brscan) sont disponibles sur [http://solutions.brother.com/linux/en_us/download_src.html].

Ça te convient, ou est-ce que tu trouves que Brother mérite une baffe parce qu'ils ne fournisse pas de paquets pour m64k, mips et arm ? :)

Pour ma part, j'apprécie quand un constructeur fait autant d'efforts. Ce qui est sûr, c'est que je remplacerai ma Brother actuelle par une autre Brother et que je continuerai à conseiller cette marque à tous les libristes.

Les gens qui achètent de l'eau en bouteille dépensent leur argent pour rien du tout. Ou plus exactement pour des illusions

Je voudrais quand même signaler que les bulles ne sont pas des illusions. Merci :)

Je pense qu'il ne faut pas tout mélanger ni l'accuser de tous les maux.

Ulrich peut être insultant et grossier, communique mal, se fout des architectures pseudo-exotiques, et gère mal le coté communautaire de "sa" libc, soit.

Est-ce que c'est une raison pour rejeter en vrac tous ses avis techniques ? Je ne pense pas. Son explication donnée dans le thread indiqué plus haut par suJeSelS me semble tout à fait pertinente. Il en va de même pour d'autres sujets qu'on a pu découvrir lors du buzz debian/eglibc. Il est peut-être sociopathe, mais certainement pas incompétent. Je continuerai à écouter ses avis techniques.

Debian n'a pas adopté eglibc parce que la glibc était mauvaise en elle-même, mais parce que le processus de développement, plus totalitaire que communautaire, et le comportement d'Ulrich Drepper leur demandait une importante surcharge de travail.

Dans les boites d'ouverture/sauvegarde de fichiers ?

Ma mémoire me trahit peut-être, mais il me semble que j'ai déjà vu un port série RJ45, probablement sur du Juniper.

« Clickety clickety clic » ?

Gnu tar est capable de faire de l'incrémental. Avec l'option -g (ou --listed-incremental dans sa version longue), je peux spécifier un fichier qui fait office de catalogue. Le principe n'est pas ici de remplacer le fichier dans l'archive, mais bien de générer une autre archive (de taille fortement réduite) qui ne contient que ce qui a changé. Suivant la manière dont on gère les catalogues, on peut faire de l'incrémental ou du différentiel.

Au passage, ça évite tous les problèmes de performances du fsck liés à l'utilisation abusive de liens durs (utilisation typique de rsync avec rotation).

En outre, c'est rapide. Un backup full (hebdo) de mon serveur met 25 minutes, les différentiels durent typiquement entre 2 et 4 minutes.

Ça permet aussi de faire du vrai différentiel quand tout ce qu'on a comme espace distant est un FTP à la connexion surchargée (OVH), sans possibilité de rsync. Les paquets différentiels à uploader sont généralement minuscules.

Il ne reste donc plus qu'à mettre à jour :)

Que find modifie le atime des répertoires, c'est logique : il doit bien les lister pour en connaître le contenu.

Mais qu'il modifie le atime des fichiers, ça me semble anormal. Le atime ne devrait être mis à jour que lorsqu'on accède au contenu d'un fichier. Une lecture de l'inode (suffisante pour déduire la taille des fichiers) ne devrait pas le modifier.

Si Mozilla ne sait pas, pose la question à l'équipe de Konqueror, ils savent très bien comment faire un navigateur réactif sous Linux :)

Tu peux sans doute également poser la question chez Opera.

Finalement, la question serait plutôt « Mais comment fait Mozilla pour avoir un navigateur aussi poussif sous Linux ? »

Une fois de plus, ça confirme mon impression : Ubuntu, c'est pas crédible.

Au boulot, la machine nagios a un module GSM connecté sur le port série et nous utilisons smslink (écrit par mon boss) [http://smslink.sourceforge.net/].

Ça a surtout le gros avantage de pouvoir nous prévenir même quand la connexion internet est down.