Colin Leroy a écrit 1205 commentaires

Ce que j'aurais trouve logique, c'est de refaire la fonctionnalite "peu sure" en "sure", tu ne crois pas?


C'est pile ce qu'ils ont fait. Limité l'accès à des fonctions dangereuses comme l'upgrade de firmware, ou d'autres trucs potentiellement plantogènes, à root.

Sinon, en vra:
- le setuid sur cdrecord ne suffit pas. il faut être root.
- l'emulation ide-scsi est inutile pour les clés usb. USB-storage suffit et scsi-generic suffisent.
- pour retrouver le fonctionnement d'avant,

--- drivers/block/scsi_ioctl.c 2004-10-27 14:14:05.000000000 +0200
+++ drivers/block/scsi_ioctl.c.new 2004-11-09 11:51:41.443373853 +0100
@@ -220,8 +220,6 @@
return -EINVAL;
if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))
return -EFAULT;
- if (verify_command(file, cmd))
- return -EPERM;

/*
* we'll do that later

mes correspondants utilisant Outlook se plaignent que mes mails apparaissent en piéces jointes dans Outlook quand je les signe avec GPG (j'utilise Sylpheed).

Dis-leur de pousser Microsoft au cul pour qu'ils supportent le format PGP/Mime, tel que décrit dans la RFC2015 depuis 8 ans. (tant qu'à faire ils pourront jeter un oeil sur la RFC3156 qui est une mise à jour de la 2015).

http://www.faqs.org/rfcs/rfc2015.html(...)
http://www.faqs.org/rfcs/rfc3156.html(...)

Sinon, tu peux aussi leur dire d'utiliser un vrai soft.

comme j'ai ajouté sur ton wiki:

cp uses the st_blksize field of the destination to determine 'optimal' block size:
from fileutils/src/copy.c line ~ 293:
if (fstat (dest_desc, &sb))
...
buf_size = ST_BLKSIZE (sb);

set it higher by hand, and cp will get faster with your USB key (and possibly your harddrive too).
The problem is that this would fix cp, but not other apps using st_blksize to determine such things.

the ioctl used by fstat to get this is BLKBSZGET, and is handled by drivers/block/ioctl.c.
Kernel hackers say it is not possible to set a logical block size higher than page_size (which is usually 4k).

PS : par contre un truc qui me dérange c'est qu'il ne se rend pas compte du branchement d'écouteurs sur la sortie audio, du coup j'ai toujours le son dans les hauts-parleurs alors que j'aimerais bien pouvoir les faire se taire quand les écouteurs sont branchés. Une idée ?

Sur mon iBook G4 ça marche (tout seul) avec un 2.6 et alsa + emul oss, pas avec 2.4 et OSS.

(en parlant de Apple, quelqu'un aurait un moyen de faire marcher la sortie video sous linux avec un ibook g4 14" de l'avant derniere série (i.e. avant octobre) ?)

ça marche "out of the box" en démarrant avec l'écran externe branché et l'ibook presque fermé. (non, c'est pas pratique, mais ça aide pour les présentations occasionnelles ;))

Sinon, y'a des xf86config qui trainent par ci par là, qui marchent avec l'écran branché dès le boot et des patches debian dans X.

Tu m'étonnes... Sans lui on n'aurait pas grand chose à se mettre sous la dent...

P.S. : d'ailleurs, il y a Colin qui a atrtapé la même maladie, depuis peu... ;-)

Oui, enfin pas encore au même niveau, hein :)

Faut dire que depuis 20 ans que ça existe... Ca supporte pas grand-chose quand même, hein. Partitions limitées à 2Go, etc.

De toutes façons, comme disait quelqu'un (désolé, j'ai oublié qui) sur la lkml:

On ne fait pas ça pour l'argent.
On fait ça pour les grosses voitures de sport et les belles nanas.


;-)

mon synaptics avec le 2.9.1-rc4

Wow! Et alors, le support pour les G7, c'est au point ? ;-)

Une des idées principale du Libre, est le libre accès aux connaissances. Cependant, à ce prix, "libre accès" n'est pas très approprié.

Ben, considère que GLMF n'est pas un magazine libre. Plus sérieusement, considère que les gens qui l'éditent ont sans doute besoin de vivre, que c'est leur métier et non pas leur hobby, et que le tirage du magazine ne permet certainement pas de le faire à moins cher...

Si.

ça ne suffit pas pour certaines choses - comme lire et écrire dans un fichier binaire que l'on veut cross-platform (c'est à dire 64bit-clean et endian-clean).

Et quand tu la retire...pouf! a pu l'icone. :)

... Ni les données ! (si tu as écrit dessus)
Il faut toujours démonter une clé usb avant de la sortir... (sous windows - systray - comme sous OS X - corbeille - comme sous Linux - clic droit)..

Où ça?

Il y a certain un /proc/config.gz, ou sinon il est sûrement dans /boot... Suffit de le copier vers .config dans le répertoire des sources du noyau avant de faire make oldconfig, et c'est bon :)

les pointeurs nuls ne causent pas de trous de sécurité en général. Un pointeur nul, c'est propre. ça segfaulte, et pouf. Libérer un pointeur null est ok avec la plupart des libcs, ça fait juste un no-op.
Les problèmes plus graves, sont par exemple les buffer overflows, où l'on va écrire trop long dans la mémoire (ie, 100 caractères dans un buffer fixe de 50) et donc écraser d'autres trucs. ça mène à un exploit si on peut écraser l'adresse de retour de la stack, en général. Les double-free() peuvent être assez méchants car eux aussi écrasent de la mémoire. Par exemple, on libère un pointeur vers une structure de 64 octets... On fait d'autres trucs, dont des allocations, qui pourront réutiliser ce bloc libéré... On se trompe et on re-libère le pointeur -> les nouveaux trucs alloués sont détruits.
C'est pourquoi
a) on initialise toujours ses pointeurs à NULL comme ça on plante proprement
b) on n'utilise pas de buffers statiques, où alors on vérifie toutes les longueurs sur les copies et écritures dedans. Mieux vaut utiliser des buffers dynamiques (et les allouer à la bonne taille, bien sûr)
c) quand on libère un pointeur, on le nullise après pour être sûr de pas pouvoir le réutiliser: free(stuff); stuff = NULL;

Une pleine page commence à 120.000$, d'après un commentaire sur slashdot. Ça peut aller jusqu'au triple, en fonction de l'endroit dans le journal.

La production n'est pas une "chose sérieuse" ?

C'est de ça dont je parle. T'es bouché, un peu, non?

Pour ton info, Linux 2.4 était la précédente branche stable. Donc avant, par rapport à 2.6, ce n'était pas comme maintenant.

Je pense à "avant" dans le sens < 2.6. Pour ton info, je suis au courant pour le 2.4. Je suis aussi au courant qu'avant encore il y avait le 2.2, etc.

Et puis je crois que recemment il y avait une fuite mémoire lors de la gravure d'un CD justement

Ça c'est ce qu'on appelle un gros bug, comme le coup du NFS qui a motivé la sortie du 2.6.8.1. Ça n'a rien à voir avec le "nouveau modèle de développement", c'est un bug qui serait arrivé de toutes façons...

Effectivement, ça ne va pas exploser à la figure à chaque branchement de périphérique USB. C'est aussi bien qu'un 2.5.

T'as pas dû essayer beaucoup de 2.5. C'est incomparable. Le 2.5.69 bootait avec 11472.3 jours d'uptime sur ppc, par exemple...

C'est bien qu'une machine en production ait les sécurités fix bien après les autres ?
C'est bien qu'une mise à jours (peut-être avec sécurité fix) soit incompatible avec la version production ?

C'est pour ça que les gens qui font des choses sérieuses utilisent le noyau de leur distribution. Ils font ça depuis très longtemps, entre nous. Depuis bien avant le "nouveau" modèle de développement qui n'est que l'officialisation de ce qui se passait déjà avant.

Le Linux vanilla n'est plus un noyau pour la production. Ou uniquement pour les personnes abonnées à la lkml et qui comprennent ce qui s'y dit.

Exagéré, pour le moins.

let the distributors do the final stabilization work. In his vision of the future, the kernel.org kernel will be the most featureful and fastest kernel out there, but it will not necessarily be the most stable.

Il faut lire stable au sens stabilité des interfaces, APIs et tout ça, pas au sens ça va m'exploser à la figure à chaque branchement de périphérique USB.

Sinon, j'attend toujours que ma carte graphique (une geforce2MX) supporte le frame-buffer :-(

man vi, man gcc :-)

Sérieusement, c'est un projet de quelques semaines pour un non-professionnel de la programmation noyau. La plupart du code est "facile" à écrire en prenant exemple sur un autre driver framebuffer et en dégottant les trucs spécifiques dans le driver nv de Xorg... (d'où rivafb vient tout droit, apparemment - d'après les commentaires dans drivers/video/riva/*c)

Le RFID ça va permettre de faire pleins de choses géniales, mais ça va aussi supprimer pleins d'emplois (entre autres, les caissières des supermarchés)

Ohh le même argument ressorti à chaque nouvelle technologie... Comme pour les robots de chaînes automobiles ou que sais-je encore.

Ce n'est pas la technologie le problème, c'est les applications qu'on peut en faire (comme le nucléaire). Ce n'est pas en essayant de freiner le progrès qu'on améliore le monde... C'est avec une éthique partagée; c'est ça le vrai problème. On peut très bien faire un état dictatorial et big-brotherien sans aide technologique.

Qu'en pensons-nous ?

Pense par toi-même, c'est mieux :)

Non, ils parlent de session au sens web, genre avec un session-id ou un cookie.