Patrick Lamaizière a écrit 300 commentaires

si le système de fichier ufs est lisible sous linux

Mais est-ce fiable ? D'après ce que j'ai compris c'est pas le pied pour le support d'UFS coté Linux, tout comme le support d'ext est foireux sous FreeBSD.

(j'utilise pas Linux alors je suis pas vraiment embêté...)

les pixels au peuple !

Jusqu'à présent, il n'existait pas de threads noyau sous FreeBSD ?

Le noyau est multi-threadé, mais l'implémentation d'un thread était plus proche d'un processus (noyau) que d'un thread.

les pixels au peuple !

La très attendue version 8.0-RELEASE de FreeBSD débarque enfin

Merci pour la dépèche mais, ben non elle n'est pas encore sortie, il n'y a pas eu d'annonce officielle. Les notes de versions ne sont pas à jour non plus. Il y a toujours un décalage de quelques jours pour permettre la diffusion sur les miroirs FTP.

avec plusieurs mois de retard.

Pas du tout :-) ça sort quand c'est prêt, à la Debian (mais en plus court quand même !)

Sinon des précisions :
ahci est marqué expérimental. Voir aussi : http://ivoras.sharanet.org/blog/tree/2009-11-17.trying-ahci-(...)

Le maillage wifi et la virtualisation de la couche réseau sont aussi expérimentaux.

Je crois que sous FreeBSD, Dtrace ne permet pas pour l'instant de tracer des utilitaires userland, que le noyau.

Oh je viens de remarquer la feuille de style ! C'est da BSD french page !

les pixels au peuple !

Moui, le coup du BSDiste qui a l'air sympathique moi j'y crois pas.
Un BSDiste, c'est aigri et ça mange les enfants. Tout le monde sait cela.

les pixels au peuple !

Sous OpenBSD je sais pas, j'utilise FreeBSD.

Tous les drivers pour les cartes de crypto sous FreeBSD ont été piqués chez OpenBSD.

Ça marche avec tout ce qui utilise le framework de crypto (IPsec, geli, un bout de kerberos) ou en userland via le device cryptodev (pour openssl par exemple).

les pixels au peuple !

Soit, mais dans mon exemple il s’agit bien d’un fichier « sans trou », que j’ai volontairement pas « hard linké ».

D'accord, mais la problématique est la même : tu n'as pas un 'filesystem full' tout de suite à la copie du fichier. Mais plus tard, à l'utilisation. Et oui ça pose problème.

Je ne connais pas de solution pour ça à part avoir de la place disque disponible. Mais est-ce un réel problème si d'un autre coté et statistiquement tu gagnes de la place de stockage ?

Tu peux avoir ce genre de gag avec des snapshots aussi, si tu modifies un fichier, il faut stocker les données d'origines dans le snapshot et les données écrites dans le fichier. Si tu n'as pas la place pour le faire ça ne marche pas, et la dessus df ne t'aidera pas plus.

Perso ça me choque pas plus que ça. J'ai toujours pensé que l'espace disque dispo est une approximation. D'ailleurs, qui n'est pas tombé comme un con en manque d'inode alors qu'il y a plein de place sur le disque ?

les pixels au peuple !

Y-a-t-il que moi qui soit choqué ?

Oui :-)
C'est pas nouveau ce genre de choses, sous Unix on utilise en général des fichiers « à trou ». Tu n'as pas la garantie qu'un fichier tienne sur le disque. Bien sûr cela peut poser des problèmes.

$ df -h
Filesystem Size Used Avail Capacity Mounted on
tank/home 24G 14G 11G 56% /home

$ dd if=/dev/zero of=big bs=1 count=0 seek=100G
$ ls -lah big
-rw-r--r-- 1 patrick patrick 100G 3 nov 14:08 big

$ df -h
Filesystem Size Used Avail Capacity Mounted on
tank/home 24G 14G 11G 56% /home

les pixels au peuple !

Tu as une mailing liste soekris assez vivante, ama tu devrais demander là bas.
http://lists.soekris.com/mailman/listinfo/soekris-tech

les pixels au peuple !

Je trouve vraiment dommage que ces histoires de licence fassent qu'aux final aucun de ces FS modernes et libres ne sera jamais commun à tout les OS libres.

Ce n'est malheureusement pas nouveau. Le support de ext est foireux dans FreeBSD et le support de ufs foireux dans Linux. Je ne suis même pas sûr que ce soit un problème de licence.

Heureusement qu'il nous reste le FAT et le ntfs.

les pixels au peuple !

Pourquoi dtrace nécessite une glue pour éviter de polluer le code BSD alors que ZFS ne nécessite pas cette glue ?

Pour DTrace il a fallu ajouter des trucs un peu partout dans le noyau (dans du code BSD existant donc) ce qui pose effectivement problème.

ZFS est autonome d'un point de vu code, c'est un simple module noyau qui est en CCDL.

les pixels au peuple !

Mais ça pourrait sentir le sapin, si bientot FreeBSD est seul avec ZFS... ? (sans vouloir vexer quiconque, juste est il déjà repris ? plutot)

Ça fait maintenant un moment qu'il est intégré au projet (début du port aout 2006). ZFS, ça commence à dater mine de rien. On peut supposer qu'il arrive à maturité.

C'est difficile de prévoir l'avenir en informatique. La seule chose sûre, c'est qu'en cas d'abandon ça grincera des dents dans les chaumières par ici.

Donc je pense que non, en plus le gars qui l'a porté (pjd) est vraiment une bête.

les pixels au peuple !

Ça sent le sapin pour ZFS

Bof, ZFS n'a jamais été intégré dans Mac OS X alors on ne peut pas dire que l'abandon soit une grosse perte pour ZFS. La perte d'une annonce ?

La bonne nouvelle pour ZFS c'est qu'il est marqué comme production ready sous FreeBSD 8.0 et ça va faire un paquet de gens à l'utiliser en plus, sur des machines sûrement plus stressées que le Mac de Madame Michu.

Concernant les éventuels problèmes juridiques on verra bien. Si ça se trouve y'a même du code SCO dedans...

Y'a aussi le fait que c'est vachement bien ce truc.

qui n'est pas, me semble-t-il, supporté par Linux non plus.

Jaloux :-)

les pixels au peuple !

on peut craindre une propriétérisation de GCC.

Il me semblait que justement la licence de Gcc plus la GPL V3 interdisaient ce risque de plugins proprio ?

les pixels au peuple !

j'aimerais bien ! : (17.7%)

Et ben viendez, c'est libre et gratuit !

Bon, Honnêtement si vous êtes content de votre Linux / Windows / MultiDeskOS et que vous n'avez pas envie de vous prendre la tête, restez sur votre OS favori.

Par contre si vous avez envie d'apprendre autre chose, j'ai énormément appris en utilisant des BSD (surtout FreeBSD). Evidement ça prend un peu de temps pour se familiariser avec mais ce n'est pas très compliqué comme système.

les pixels au peuple !

Quelqu'un connais un annuaire de texte édulcoré lisible facilement sur le net ?

http://bofh.ntk.net/Bastard.html

les pixels au peuple !

Pour les autres Macbook il y a des quirks pour faire en sorte que ça marche. Si le matériel est récent il se peut que ce ne soit pas encore intégré.

Fait une recherche sur les mailing liste de dev d'alsa avec l'ID PCI du chipset et tout.

Je ne connais pas Linux mais lors de mes recherches pour faire avoir du son sur mon Macbook pro j'avais trouvé :

http://www.alsa-project.org/main/index.php/Help_To_Debug_Int(...)

(Ils mentionnent un outil HDA-Analyzer et un autre outil http://helllabs.org/codecgraph)

Honnêtement j'en avais chié... Quel bonheur quand le son sort enfin :)

Bonne chance.

les pixels au peuple !

FreeBSD, NetBSD et OpenBSD incluent toutes des instructions sur l'obtention de programmes non-libres dans leur système de ports.

Oui et alors ? Les instructions (ie les ports) sont libres elles.
L'utilisateur est quand même libre d'installer des trucs propriétaires s'il en a envie. C'est même pire que ça, on émule un système libre (linux...) pour pouvoir faire tourner les trucs proprios.

De même, les noyeaux BSD incluent des pilotes contenant des firmwares non-libres.

C'est vrai pour FreeBSD, il y a un blob pour le pilote de réseau des chipset nforce et un blob pour le pilotes iwi. Je ne crois pas qu'OpenBSD en ait (ils ont aussi fait un pilote 100% libre pour les chipsets nforce).

Les firmwares non-libres sont appelés blobs dans Linux, mais dans le jargon de BSD, un blob a une signification différente.

Ah bon, quelle signification ?

les pixels au peuple !

pflogsumm ça ne te plait pas (à mettre dans un cron) ?

Grand Totals
------------
messages

470 received
483 delivered
0 forwarded
0 deferred
1 bounced
554 rejected (53%)
14 reject warnings
0 held
0 discarded (0%)

[...]
message deferral detail: none

message bounce detail (by relay)
--------------------------------
mail2.akka.fr[195.167.225.220]:25 (total: 1)
1 <> sender cannot be empty (in reply to MAIL FROM command)

les pixels au peuple !

nos améliorations ? Tu parles au nom de quel groupe de personnes ?

Du groupe de ceux qui bossent pour améliorer leur code au lieu de se plaindre qu'on leur vole leur code pour l'améliorer...

les pixels au peuple !

Pour en profiter il faut ajouter à ton ~/.bashrc ceci

Ce que je veux dire c'est que ce n'est pas dans OpenOffice, celui qu'on trouve sur OpenOffice.org.

Là c'est des patches qui viennent de go-oo.org visiblement et c'est spécifique à Debian et/ou go-oo.org

http://www.openoffice.org
http://www.go-oo.org

les pixels au peuple !

Ben en fait si, c'est le retour de openoffice.org-kde!

J'ai cherché dans le configure.in de OOo 3.1.1 et nul part il y a une option pour avoir KDE 4.

Vous êtes sûr d'utiliser le véritable OpenOffice et pas un Openssl^H^H^Hoffice patché ?

les pixels au peuple !

Pour finir je n'ai pas pulseaudio alors je ne peux pas comparer.

J'ai essayé avec jackd mais le son lague avec 16 mixages et ça a l'air bien bogué ici (plein de zombies...).

Avec pulseaudio, ça tient la route avec 16 mixages et même sans utiliser la prioritée temps réel (resample-method = src-sinc-best-quality)

CPU: 10.5% user, 0.0% nice, 9.0% system, 2.4% interrupt, 78.0% idle

les pixels au peuple !

En passant, combien consomme OSS pour mixer et avec quel algo ?
On ne sait toujours pas

Rapide essai sous FreeBSD à la louche (avec KDE et tout le toutim)
Matériel : un macbook pro, son HDA
CPU Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz

J'ai 16 'vchans' ie des canaux audio virtuels qui sont mixés.
16 instances de mpg123 qui jouent le même morceau.

- avec la qualité du feeder max (voir http://people.freebsd.org/~ariff/SOUND_4.TXT.html hw.snd.feeder_rate_quality=4)
CPU: 4.9% user, 0.0% nice, 4.5% system, 41.3% interrupt, 49.3% idle

- avec la qualité du feeder min (hw.snd.feeder_rate_quality=0)
CPU: 4.5% user, 0.0% nice, 0.9% system, 1.3% interrupt, 93.3% idle

Même chose, mais pour un seul morceau à la foi
- avec la qualité du feeder max
CPU: 1.3% user, 0.0% nice, 6.0% system, 2.8% interrupt, 89.8% idle

- qualité min:
CPU: 0.6% user, 0.0% nice, 0.6% system, 1.1% interrupt, 97.7% idle

Je ne suis pas expert en son, mais ce qui apparaît c'est que c'est plutôt la qualité du feeder qui influe plutôt que le mixage. Intéressant j'ai mis la qualité au max alors que j'entend pas de différence, je vais la réduire.

L'algo utilisé pour le feeder est décrit dans le lien plus haut (j'ai pas tout compris...)

Pour finir je n'ai pas pulseaudio alors je ne peux pas comparer.

les pixels au peuple !

D'un autre coté sous bsd c'est de l'oss ou ça y ressemble beaucoup (corrigez moi si je me trompe).

L'API est compatible OSS mais l'implémentation n'a rien à voir (sous FreeBSD, sais pas pour les autres)

les pixels au peuple !

Par contre, je n'arrive pas à comprendre la réticence de certaines personnes sur ce journal au fait que le mixage se fasse dans le kernel et pas en userspace.

Ben ici sous FreeBSD(*) ça ne choque personne, peut-être est -ce simplement pour le coté pratique même si c'est MAL. Et ça fait longtemps que ça existe, dans la 8.0 il y a même un equalizer.

(*) Mais bon ce sont des idiots incompétents qui jouent avec la VM.

les pixels au peuple !