Ca me permet de jouer à NetHack pendant que ça compile \o/

Yeah, j'ai tout recompilé et le problème semble réglé, merci Sankukai
REste à savoir comment j'ai pu ne plus être en sync

Pour faire suite à l'histoire « FreeBSD isn't Free », il semble que le code acpica est en fait distribué sous triple licence : intel/BSD/GPLv2. Par défaut les en-têtes exposent la licence intel mais un outil délivré avec le tarball des sources (acpisrc) permet de convertir le code selon le style Linux et de convertir les en-têtes avec la bonne licence. Linux fait ce travail de formatage, par défaut FreeBSD ne le fait pas et les en-têtes ne sont pas modifiés.
http://www.listware.net/201010/freebsd-questions/19724-re-like-it-or-not-theo-has-a-point-freebsd-is-shipping-export-restricted-software-in-the-core.html

Sinon, je profite de ce message pour continuer mon journal de bord sous DragonFlyBSD. Après un peu plus de deux semaines d'utilisation je dois dire que je suis vraiment fan de HAMMER ! Je ne suis toujours pas un gourou de ce système de fichier mais j'ai pu expérimenter de choses sympathique, par exemple :
1- Faire un snapshot de mon /usr/pkg/
2- Tout péter avec pkgsrc (c'est pas très dur)
3- Faire un rollback gràce au snapshot et se retrouver avec un système parfaitement sain
Il y a beaucoup de possibilités de mirroring et de backup que malheureusement je n'ai pas encore pu tester.
J'ai aussi pu faire joujou avec un vkernel (pour l'instant juste de la conf. basique). C'est vraiment intéressant d'un point de vue développement (et ça le deviendra encore plus lorsque leur projet de porter valgrind pour monitorer les vkernels aboutira) mais ça peut aussi le devenir d'un point de vue utilisateur (cf. idée d'utiliser des checkpoints de vkernel pour reproduire une sorte de suspend/resume mais avec arrêt complet de la machine : http://leaf.dragonflybsd.org/mailarchive/kernel/2010-10/msg00011.html ).

Quelques points négatifs maintenant ! 
Tout d'abord, l'impression que j'avais d'un point de vue « extérieur » au projet s'est révélée exacte. dillon@ est à l'origine des 3/4 des commits importants. S'il vient à disparaître brutalement (prions pour ce que n'arrive pas) je me demande comment se relèvera le projet. J'ai aussi l'impression que les autres développeurs (hormis deux/trois — sans compter dillon@ — qui semblent extrêmement talentueux) sont principalement des étudiants. Je ne dis pas que les étudiants sont mauvais mais à côté des gourous OpenBSD par exemple qui semblent tous avoir beaucoup de bouteille, ces derniers font un peu pâle figure. Ça ne pourrait être qu'un a priori mal venu de ma part mais force est de constater que pour les parties que j'ai explorées la qualité de code est inférieure par rapport à de l'OpenBSD ou du NetBSD. Je ne suis pas développeur noyau mais, tout comme je sais apprécier un bon repas sans être chef cuisiner, je sais faire la différence entre du code beau et du code fouillis. Par exemple faisons un tour au pays de l'ATA. Pour la petite histoire, j'ai mis le doigt dans l'engrenage en voulant voir comment l'atactl(8) d'OpenBSD faisait pour récupérer les infos SMART et pourquoi ce n'était pas implémenté dans le natacontrol(8) de DragonFlyBSD. Comparez donc la tête des structures de données respectives utilisées pour construire des requêtes ata :
— struct ata_ioc_request pour DragonFlyBSD : http://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/sys/nata.h
— struct atareq pour OpenBSD : http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/ataio.h?rev=1.1.4.3;content-type=text%2Fplain

C'est assez parlant je trouve. Le code en tant que tel est du même tonneau. L'atactl va privilégier des pointeurs de fonctions pour appeler les fonctions relatives à la commande que l'on souhaite invoquer, le natacontrol va imbriquer cinquante case dans le main.
Bref le code est moins lisible, moins beau et ça m'embête un peu…

Penses tu que hammer soit backportable sur d'autre BSDs ?

Oui je le pense. Et je pense même que c'est faisable sans trop de souffrances (du moins beaucoup moins que le port de ZFS sous FreeBSD). Le code n'est pas énorme et est, pour le coup, très bien écrit : http://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/sys/vfs/hammer
À mon avis, il y a trois gros points à considérer pour un port :
— l'interaction avec le vfs ;
— l'interaction avec le buffer cache ;
— la gestion des threads (ne pas oublier que seul DragonFlyBSD utilise les lwkt)
Pour les deux premiers points, le code à l'air suffisamment bien segmenté pour que la grosse partie du code à toucher soit dans hammer_vfsops.c et hammer_io.c. Pour le dernier point, c'est plus fastidieux il faut passer un peu partout pour remplacer l'api lwkt par celle en vigueur sur l'os où l'on port hammer.
En ce qui concerne les travaux en cours, j'ai l'impression qu'il n'y en a pas vraiment. J'avais vu passé en 2008, sur une ml, un gars qui disait que ce serait vachement bien d'avoir ce fs sous NetBSD mais rien de neuf depuis. Et j'avais vu passé en 2009 un mail d'un gars qui parlait d'un port pour Linux via fuse mais je ne sais pas où ça en est aujourd'hui.

Vu a la vitesse a laquelle ca evolue, ce n'est peut etre pas le moment de faire un port.

On devrait renommer ce topic : "[Blabla] le /pub des BSDistes"

Salut les barbus

Can't install libiconv-1.13p2 because of libraries
|library c.57.0 not found
| /usr/lib/libc.so.53.1 (system): bad major
| /usr/lib/libc.so.56.0 (system): bad major

À priori les paquets pas synchrones avec le système de base, ça arrive si le miroir a synchronisé les snapshots de l'os mais pas encore tous les paquets (ou que ces derniers n'ont pas encore été recompilés), rien de bien méchant et donc hors de ton contrôle... Soit tu compiles toi même, soit tu fais un ln de la lib en espérant ne rien péter

Tu fais comme Dargor, tu mets à jour ton système en recompilant le tout.

Houlà je passe par les snapshots maintenant, à part si je dois tester un diff, et même là je ne compile souvent que le kernel

Sankukai > Merci pour le retour, c'était très intéressant J'attend tout particulièrement les premiers retours de la suppression du BKL, mais HAMMER est un excellent sujet de fantasmes aussi...

Ça parlait ici du fork d'openoffice il n'y a pas longtemps. On vient aujourd'hui de me pointer SoftMaker :
http://www.softmaker.com/english/ofc_en.htm

Sur le papier, ça a l'air assez intéressant.

Ubuntu 10.10 est sortie http://linux.slashdot.org/story/10/10/10/1253254/Ubuntu-1010-Maverick-Meerkat-Now-Available

Selexion => et alors ?

Chris => et alors ?

I.e. que je ne comprends pas trop le logiciel que tu nous montre. Il est fermé et payant (ce qui n'est pas grave en soi) et surtout il est destiné à une plateforme très particulière (windows CE, depuis ces dernières années c'est plus très courant).

Pourquoi dis-tu qu'il est intéressant ? J'ai raté quelque chose ?

dnob700 : aurais-tu raté le fait qu'il y ait une version native pour Linux ?

ouah! c'est courageux de se lancer en 2010 a la conquete de Microsoft Office avec une solution payante.

Richard_LeHap Je voulais partager cette joie avec vous.

Ce forum a changé, c'est fini l'époque où il y avait 45 topic pour la sortie d'une version d'ubuntu

C'est pas plus mal. De toute façon, il n'y a rien de très intelligent à dire sur cette nouvelle version j'ai l'impression (il faut voir ça comme un point positif, cette fois ils se sont enfin contenté de "juste" mettre à jour les paquets et de peaufiner quelques points mineurs).

Et puis d'un autre coté, cette version est sortie relativement tôt. Normalement c'est plutôt vers le 20-25 que ça arrive.

Oui ils l'ont sortit le 10/10/10 pour faire genre
C'est vrai qu'il ne semble n'y avoir rien de "vraiment" neuf pour cette mouture...

Mon cobureau vient de me faire remarquer cette subtilité pendant le repas, en effet… Maintenant, la question c'est : Oseront-ils retarder une version d'un mois l'an prochain pour s'offrir la 11.11 le 11/11/11 ?

C'est triste les antispam, fini les gulliver in my pants et autres le géant au meilleur prix le plaisir