ribwund a écrit 1439 commentaires

C'est pour l'avenir. En effet à partir de 2.6.19 c'est possible d'utiliser libata pour les disques IDE (pata), ces disques apparaitront sous la forme /dev/sd* à la place de /dev/hd*. Grace à l'utilisation des UUID le switch se font de façon transparente chez moi (j'utilise un 2.6.19-rcX-mm).

Apres c'est sur que des labels auraient été plus lisibles plutot que les UUID par contre je sais pas si tout les FS supportent les labels.

(vol_id donne le UUID d'un partition, sinon avec udev c'est dans /dev/disks/by-uuid/)

Pour l'url:

http://groups-beta.google.com/group/fa.linux.kernel/browse_t(...)

Voir le thread "[PATCH 2.6.18-mm2] acpi: add backlight support to the sony_acpi driver" sur la lkml.

Bof les personnes que ça embete c'est principalement les gens qui font des DRM, c'est quand même le cas le plus courant ou un utilisateur "malveillant" a un accès physique à la machine où la crypto se fait.

http://www.schneier.com/blog/archives/2006/11/new_timing_att(...)

Est ce que c'est prévu de le faire passer upstream ? Il me semble avoir vu des gens qui bossaient pour faire une classe lcd / hotkeys / ... générique à la place du bordel actuel ou chaque marque a son driver et son interface.

Bah nan, si tu fait du bash tu mets "#!/bin/bash" sinon tu fais du sh et tu mets "#!/bin/sh", la plupart des unix n'ont pas bash en /bin/sh.

Oui mais bon y'a que nvidia qui a les sources non obfuscated du driver, donc il reste non libre...

pour Kuhn: http://www.softwarefreedom.org/news/20061109a.html

Harald Welte (le type de gpl-violations.org) est impliqué dans le projet depuis un certain temps (il mentionnait regulierement dans son blog ses voyages à Taiwan pour un projet libre tenu secret).

Il est responsable de la partie systeme (kernel, drivers, gsm, ...)

les liens vers l'annonce sur son blog:
http://gnumonks.org/~laforge/weblog/2006/11/08/#20061108-my_(...)
http://gnumonks.org/~laforge/weblog/2006/11/08/#20061108-ope(...)

Donc si, ils possèdent une partie du copyright et en sont responsables juridiquement.

Pour samba c'est faux. Vu que samba fait partie du Sofware Freedom Conservancy [1], les questions juridiques sont gerées par cette organisation (qui protègent pas mal de projet visés par des brevets: Wine et Mercurial par exemple).
Et contrairement à Novell, SFC est très proche de la FSF (l'avocat de SFC est Eben Moglen, qui s'occupe du service juridique de la FSF)

[1] http://conservancy.softwarefreedom.org/

Tu peux aussi faire tourner ton ssh sur un port non standard, ca a résolu tout mes problemes de scans. (bon c'est toujours sur 22 en ipv6 mais c'est beaucoup plus galère pour le bot :)

Tout d'un coup ca explique pourquoi Oracle s'est offerte recement une jolie kernel team avec des anciens d'autres distros notamment Suse.

A noter que des patches basés sur Xen sont récemment apparus sur la mailing list du kernel proposant l'utilisation des instructions VT au niveau du kernel (sans hypervisor). Ca permet de faire tourner des "processus" completement séparés et completement virtualisés (comme windows).

euh le problème c'est surtout que nv n'est pas vraiment libre non plus.
A la base c'était la sortie d'un gcc -E... et je crois pas que ce soit la forme préferée pour faire des modifications.

http://airlied.livejournal.com/34017.html

C'est juste très diffférent avec la différence de taille:

Recently, the main server for Linux kernel source, kernel.org, suffered file system corruption from a failure at the RAID level. It took over a week for fsck to repair the (ext3) file system, when it would have taken far less time to restore from backup.

Le raid ne change rien, on veut un système de fichier qui gère le nombre croissant d'erreurs d'E/S et qui soit le plus tolerant aux fautes possible. Par exemple une certaine redondance au niveau du FS est utile, pour justement éviter que les données du secteur soit perdues.

A propos de file systems, j'avais trouvé l'article http://lwn.net/Articles/190222/ très interessant.

Il présente les contraintes qu'auront a faire face les nouveaux systèmes de fichiers (notamment en gestion des erreurs sur le disque qui deviennent plus courantes avec l'augmentation de la taille).

bzr est chapoté par Canonical
D'ailleurs pour contribuer à bzr il faut assigner son copyright à Canonical, et je sais pas pourquoi mais je pense que Canonical c'est pas la FSF, ils font pas ça pour passer le logiciel en GPLv3 par la suite... (surtout sachant que Launchpad est propriétaire et qu'ils cherchent à integrer Launchpad+bzr au maximum)

bien que certaines parties soient programmé en C contrairement à bzr
cElementTree (parsing de xml en C) est quand même fortement conseillé pour bzr :)

En comparaison, Mercurial ne sait pas maintenir une branche avec un fichier renommé, et ne gère pas, par exemple, un ajout de fichier dans un répertoire renommé.

ETA pour la feature dans mercurial: quelques semaines. En effet Matt Mackall (le créateur du projet) est payé par Sun pour l'implementer et il a une deadline.

Après, c'est clair qu'ils se sont concentrés sur les fonctionalités et non sur les perfs.
Pour moi ce qui ressortait de la discussion au sprint de Londres, c'est qu'ils ont fait des choix qui limiteront forcement la performance (notamment le choix d'un identifiant unique pour les fichiers) et que pour arriver au niveau de hg/git, bzr devra passer par (encore) un changement de format du repository.

tout est encore en python contrairement à Mercurial qui a déjà les parties critiques en performances optimisées en C, ...).
Une seule chose a été optimisé (et ca a été fait dès le début du projet) c'est les méthodes pour patcher/differ qui sont forcement critique. Ca semble la première chose à optimiser et je me demande pourquoi bzr ne le fait pas (le reste n'est pas encore optimiser pour que ce soit critique ?)

La question est plus de savoir où s'arrêteront les gains de performance, il y a de bonnes chances que ça se joue à quelques dizaines de pourcent près à terme (Darcs restera sans doute à la traine, puisqu'il est basé sur des concepts qui le rendent intrinsèquement plus lent, et déjà bien optimisé aujourd'hui).
Et si bzr était aussi intrinsequement plus lent ?

Mercurial est inspiré de git.

Je sais pas d'ou vient cette idée mais git et mercurial ont été commencé le même jour d'ailleurs mercurial a été utilisable avant git (cf les archives du kernel). Si un SCM a vaguement inspiré git et mercurial c'est monotone (la façon dont sont utilisés les hash).

Ca faisait longtemps que j'avais pas retesté bzr alors vu qu'ils font beaucoup de buzz par rapport aux performances j'ai fait un petit test (hg est également écrit en python):

cache chaud
nombres de fichiers: ~20k (kernel linux)
taille: 280M

temps pour ajouter + commiter les fichiers:
bzr: 5min 1s
hg: 1min 56s

temps pour faire un status:
bzr: 6.6s
hg: 1.3s

taille du repo:
bzr: 232M
hg: 126M

bzr est le logiciel de gestion de versions décentralisé libre regroupant le plus de fonctionnalités.
Ca me semble quand même un peu exagéré, et pas forcement respectueux des devs des autres systèmes (darcs, monotone, git, mercurial, ...)

En même temps, comme le note Adrian Bunk [1], il pourrait être possible pour un developpeur principal de Linux de changer la licence.


[1] http://lkml.org/lkml/2006/9/22/230

Mais est-ce que le proprio open source est acceptable ?
Si oui, alors je comprends qu'ils "hurlent" sur la gpl V3. Si le proprio open source n'est pas acceptable, pourquoi ? parce que l'open source n'est pas suffisant et qu'il faut aussi du libre ? CQFD.

Je pense que Linus et les autres kernel hackers qui ont signé le papier sont pour les logiciels libres, mais avant tout les logiciels.

Pour eux avoir une culture libre (pas de DRM) n'est pas de leur ressort, et plutot que lutter au niveau logiciel il faudrait lutter plus bas (licence art libre, etc). On peut considerer comme légitime la demande de l'industrie de la "culture" de faire valoir leurs droits. Si l'on n'est pas d'accord avec cette optique, c'est l'art copyleft qu'il faut developper en parallèle, plutot que des méthodes purement techniques.

Encore faut il détenir l'ensemble des copyrights sur le logiciel...

C'est également possible avec bash:
http://gentoo-wiki.com/TIP_Exit_Status_in_prompt