gouttegd a écrit 1805 commentaires

Les SlackBuilds sont écrits par les slackeux avant tout pour eux-mêmes, donc la seule existence d’un SlackBuild pour PulseAudio témoigne que si, au moins un slackeux avait besoin de PulseAudio. Tant pis si ça t’empêche de mettre tous les slackeux dans la même case.

Je conçois que ça puisse faire un choc à ceux qui croyaient dur comme fer que les slackeux étaient tous des ultra-conservateurs passant leurs temps dans une console (ou à la rigueur dans twm), refusant tout code postérieur à l’an 2000 et n’utilisant que des périphériques sur port parallèle…

C’est vrai qu’un slackeux moderne, c’est comme un Parisien sympathique ou un Marseillais modeste : ça ne correspond pas à l’image qu’on en a.

Merci de ne pas me faire dire ce que je n’ai pas dit. Je ne me suis pas prononcé sur la qualité de PulseAudio, que je n’ai jamais utilisé (jamais eu besoin, tout comme je n’ai d’ailleurs jamais eu besoin de aRts ou de esd). Et j’ai bien explicitement écrit « tant mieux si ça répond à des besoins des utilisateurs » (même si lesdits besoins me paraissent légèrement exotiques et assez éloignée de l’utilisation classique d’un « desktop »).

Libre à toi d’en conclure que je pense que c’est pourri, mais ce n’est pas en déformant mes propos que tu me convaincras de l’essayer. J’utiliserai PulseAudio le jour où j’en aurais besoin, si ce jour arrive, et pas avant.

alsa ne permet pas d'utiliser plusieurs cartes sons en redirigeant dynamiquement certains flux sur une carte et d'autres sur l'autre

Euh, il y a vraiment des gens qui utilisent plus d’une carte son simultanément ? Je conçois bien qu’un PC puisse avoir plus d’une carte son (un chipset intégré à la carte mère et une carte PCI par exemple), mais comment peut-on avoir besoin d’utiliser les deux en même temps ?

Si des utilisateurs ont ce genre de besoin et que PulseAudio y répond, tant mieux pour eux. Pour ma part, je n’ai jamais ressenti un quelconque besoin que seul PulseAudio pourrait satisfaire. ALSA me convient parfaitement pour mon utilisation quotidienne, et pour les besoins très spécifiques de la MAO à laquelle je m’adonne de temps en temps, j’ai Jack.

Hélas, sans résultat. J'en viens à la conclusion suivante: pour NetBSD, l'utf8 c'est hype, et iso8859-1 aussi! J'ose espérer que c'est plutôt moi qui n'ai rien compris.

Suggestion con : puisque le programme d’installation est « parfaitement francisé », tu as essayé de regarder comment il se débrouillait pour afficher des caractères accentués ?

Mais si ni NetBSD ni Plan9 ne sont propres, simples, épurés et diaphanes, qui le sera?

Slackware ? Elle n’échappe pas à /tous/ les travers des autres distributions GNU/Linux, certes (les pages de manuel par exemple sont bien évidemment les mêmes que sous n’importe quelle autre distribution), mais elle en évite tout de même quelques-uns :
– un système d’init simple et assez proche de ce que tu décris pour NetBSD ;
– une certaine résistance aux surcouches et composants jugés inutiles (pas de PAM, pas de PulseAudio, pas de upstart/systemd/whatever, pas de GNOME…) ;
– pas de gestion automatique(ment foireuse) des dépendances de paquet ;
– …

Mais du coup, il faut que mon ordinateur devine sur quel réseau il est. Alors, à votre avis, comment on peut faire ça facilement ?

J’utilise /etc/dhcpcd.exit-hook pour ça (cf. dhcpcd-run-hooks(8) pour les détails).

Tous les réseaux auxquels je suis amené à me connecter ont un serveur DHCP, et ces serveurs envoient généralement, en même temps que l’adresse IP allouée, plus ou moins d’informations permettant la plupart du temps d’identifier assez certainement le réseau sur lequel je me trouve.

Ça donne à peu près ça :

if [ x$reason = xBOUND ]; then
    case "$new_domain_name" in
        ujf.grenoble.fr)
            # réseau de l’université Grenoble I
            ;;
        fleming.local)
            # réseau de l’Institut Fleming
            ;;
        ici.local)
            # un autre réseau ici
            ;;
        ailleurs.internal)
            # un autre réseau ailleurs
            ;;
        *)
            # réseau inconnu
            ;;   
    esac
fi

Ici, new_domain_name est le nom de domaine par défaut indiqué par le serveur DHCP. C’est je pense l’option la plus simple pour identifier le réseau auquel on vient de se connecter (malheureusement tous les serveurs DHCP ne renvoient pas nécessairement cette information — elle est optionnelle, d’après la RFC 2132, §3.17). Les autres informations possiblement utilisables, à défaut, incluent l’adresse du serveur DHCP qui vient de répondre (new_dhcp_server_identifier), l’adresse des serveurs DNS (new_domain_name_servers), le SSID dans le cas d’une connexion Wi-Fi (new_ssid), la passerelle (new_routers), etc…

comment kernel + udev font pour faire la relation périphérique / module

Une explication est disponible dans la documentation d’OpenSUSE.

En gros, chaque module indique quels périphériques il peut supporter. Les identifiants des périphériques supportés par un module permettent de construire un ou plusieurs « alias » pour ce module. depmod compile une liste de correspondance « alias de périphérique ⇔ module » (dans /lib/modules/VERSION/modules.alias).

Quand le noyau détecte un périphérique, il construit un alias à partir de identifiants de ce périphérique et l’envoie à udev ; udev appelle modprobe avec l’alias spécifié et modprobe retrouve, gràce à la liste préalablement compilée par depmod, le module à charger.

pourquoi j'ai le package discover installé sur Debian Squeeze si elle utilise udev ?

Je serais bien incapable de dire pourquoi Debian fait tout ce qu’elle fait (je n’ai toujours pas compris pourquoi elle s’est immiscée dans le fonctionnement d’un générateur de nombres aléatoires, par exemple¹), mais la documentation de discover peut apporter un éclairage :

We must take a moment to explain what Discover is not: Discover is not a
replacement for the service - usually provided by the underlying operating
system kernel or a user-space program that interfaces with it - of simply
translating bus-specific vendor and model identifiers to human-readable
names. Discover performs its own translations of this data as a
convenience for generating human-readable reports, but it does not attempt
to enumerate all hardware devices that exist for a particular bus
architecture. Rather, Discover is intended only to catalog data for which
there is some useful information to impart regarding software interfaces.
Facilities already exist in modern operating systems for answering the
questions "What is the name of this device?" and "Who manufactured it?"
Discover's role is to answer questions like "What Linux kernel module do I
need to load for this device to work?" More importantly, Discover will
enable you to provide answers in the future to questions you don't even
expect to ask today.

En gros, discover n’est pas une alternative à udev, même s’il peut faire une partie de son travail. discover est par ailleurs censé être portable (et non spécifique au noyau Linux), ce qui j’imagine doit être intéressant pour Debian et ses versions Hurd ou kFreeBSD.

---

¹ Je sais, c’est mesquin de ressortir les vieux dossiers… ;)

s/pallier aux déficiences/pallier les déficiences/

(Honte sur moi — mais quand même, il a trop raison ce mec.)

Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre. Il y a des bidouilles pour simuler cela (par exemple http://freecode.com/projects/libetc que je n'ai pas eu le courage de tester, par peur de tout casser), mais il faudrait peut-être le faire de manière plus systématique et par défaut sur toutes les distributions.

Amen sur ce point, mais ce n’est pas aux distrbutions d’y faire quelque chose… Une convention a été proposée, c’est aux développeurs upstream de l’implémenter dans leurs logiciels.

libetc est une bidouille, le jour où les distributions auront recours à ce genre de choses pour pallier aux déficiences des logiciels on sera arrivé au niveau de Microsoft, qui virtualise le système de fichiers ou la base de registre pour permettre à des applications codées avec les pieds (par des développeurs qui se croient encore sous Windows 9x, et qui cherchent à stocker les préférences directement dans C:\Program Files au lieu de %HOME% par exemple) de fonctionner à peu près correctement.

Tant qu’à faire à militer pour le respect des RFCs, autant mentionner celles qui sont concernées ici :

– RFC 2142 pour les adresses e-mail standards ;
– RFC 2606 pour les noms de domaines à utiliser comme exemple ;
– RFC 5737 et RFC 3849 pour les adresses IPv4 et IPv6 réservées à la documentation.

Mais bon après ça doit être dur de se regarder dans la glace et de se dire qu'on s'était engagé à aider quelqu'un mais que finalement on n'est pas allé jusqu'au bout.

D’autant plus que dans les jours précédant le prélèvement, le futur receveur subit un traitement visant à détruire complètement sa propre moelle osseuse. Changer d’avis au dernier moment, après cette étape, revient pratiquement à condamner à mort le receveur.

gnu make : bien évidemment le moteur GNU make pour exécuter le makefile résultant.

Non, à ma connaissance automake génère des Makefile n’utilisant aucune extension propre à GNU make, et qui devraient être utilisables avec à peu près n’importe quel make en circulation (sauf sans doute nmake sous Windows).

J'ai l'impression que la LGPL pourrait être la licence rêvée des dévs BSD aigris (mais qui n'aiment pas la GPL) !

Hum, il me semble qu’une des premières critiques à l’encontre de la GPL, avant même son caractère viral ou prophylactique, c’est sa longueur et sa complexité.

Si c’est effectivement le cas, je ne suis pas sûr que l’idée de remplacer la 3BSD par la LGPL séduise beaucoup de monde :

$ wc -l 3bsd.txt
24 3bsd.txt
$ wc -l gpl-2.0.txt
339 gpl-2.0.txt
$ wc -l lgpl-2.1.txt
504 lgpl-2.1.txt

réduits maintenant à utiliser un ô combien disgracieux head -n 1

Meuh non, il y a aussi sed 1q, c’est tout de suite beaucoup plus joli.

Alors que souvent quand on regarde sur le net les explications sur la licence, en gros ils disent "Avec un code BSD on peut faire ce qu'on veut tant qu'on n'embête pas l'auteur..."

C’est un peu trop simpliste comme explication. Une meilleure explication serait plutôt qu’on peut faire ce qu’on veut tant qu’on respecte les conditions de la licence. Le fait est que les conditions demandées par la 3-BSD autorisent à peu près tout dès lors que la licence est reproduite dans les sources, le binaire ou la documentation qui va avec.

Et je préfèrerais qu'on puisse modifier ce p'tit bout de code sans forcément avoir besoin de le redistribuer

Tu n’es absolument pas obligé de redistribuer le code :

Redistribution and use in source and binary forms, with or without modification, are permitted [...]

La redistribution du code est permise, pas exigée.

Redistributions of source code must retain the above copyright notice [...]

Si tu choisis de distribuer le code de ton logiciel (sous quelque licence que ce soit, libre, non-libre, « shared-source »…), alors tu dois aussi redistribuer le code BSD que tu as ré-utilisé (ce que tu ferais de toute façon, puisqu’il fait partie intégrante de ton logiciel) en laissant intacte la licence BSD qu’il comporte.

Redistributions in binary form must reproduce the above copyright notice [...]

Si tu choisis de distribuer le binaire (là non plus, tu n’es pas obligé de la faire, même si ne pas le faire risquerait de réduire l’intérêt de ton logiciel…), alors tu dois reproduire sa licence partout où c’est approprié. C’est tout. Il n’y a aucune obligation de distribuer le code avec le binaire, ou de t’engager à fournir le code si celui à qui tu as donné le binaire te le demande.

Du coup ça veut dire que le p'tit bout de code en BSD reste open source non ?

Oui, bien sûr. Mais dans le cas d’un logiciel propriétaire dont l’éditeur ne distribue que le binaire, ça fait une belle jambe à l’utilisateur…

Ce que je ne comprend pas, c'est cette 2ème clause. Si la redistribution de binaires doit reproduire cette licence, ça veut dire qu'un logiciel propriétaire qui inclue un bout de code BSD devient BSD aussi???

Non, ce que je comprends, c’est que partout où est affiché le contrat de licence propriétaire du logiciel (dans la documentation, dans la boîte de dialogue « À propos de ce logiciel » si elle existe, etc.), il faut afficher en plus la licence BSD du code réutilisé sous cette licence.

Mais les conditions BSD continuent à ne s’appliquer qu’au code qui a été réutilisé, elles ne s’étendent pas au reste du programme qui reste donc propriétaire et ne devient pas automatiquement un code libre sous licence BSD.

Ça donnerait probablement quelque chose comme ça :

Logiciel Propriétaire v3.7
© 2011 Éditeur. Tous droits réservés.

CONTRAT DE LICENCE UTILISATEUR FINAL

(Ici un gros pavé indiquant tout ce que l’utilisateur n’a pas le
droit de faire.)

Ce logiciel comporte du code publié sous licence BSD, redistribué sous
les conditions suivantes :

Composant Libre 2.5
© 2009,2011 Original developers

Redistribution and use in source and binary forms, with or without
modifications, are permitted provided that the following conditions
are met:
(Le reste de la licence BSD, y compris l’avertissement concernant
l’absence de garantie).

(Je me souviens vaguement avoir vu ce genre de mention par exemple dans Adobe InDesign, qui ré-utilisait le parseur XML Xerces de la fondation Apache.)

Par chez moi, DM ça voulait dire « devoir à la maison » (à rendre pour une date donnée, et noté), par opposition au DS, le « devoir en salle » (ou « surveillé »). Les deux pouvant bien sûr concerner n’importe quelle discipline.

C’est bien ce que j’essayais de dire. La différence entre le langage XSLT et expp est du même genre que la différence entre le langage awk et le processeur de macro m4.

On ne fait pas que du remplacement de texte avec awk (même si on peut le faire occasionnellement, m4 ou cpp seront plus appropriés) tout comme on ne fait pas que du remplacement de nœuds XML avec XSLT (même si on peut le faire).

Si je devais essayer une comparaison avec les outils classiques manipulant du texte brut, je dirais que XSLT est une sorte de awk tandis que expp est plutôt assimilable à m4. Les cas d’utilisations des deux outils peuvent se chevaucher partiellement mais leurs tâches de prédilection ne sont pas les mêmes (a priori on n’utilisera pas awk pour faire du remplacement intensif de macros ni m4 pour traiter des lignes de texte).

Le pdf ne m'intéresse pas en imprimante, mais en export natif. C'est une demande pour le service qualité.

L’exportation PDF à partir de MediaWiki, avec l’extension mwlib.rl, fonctionne très bien (un tout petit peu fastidieux à mettre en place, peut-être, mais sinon une fois installée RAS) et donne un très joli résultat.

Je ne suis pas sûr que MediaWiki puisse satisfaire tous les autres critères, cependant (notamment ce qui concerne la « modération »)…

Pour le matériel grand public, c'est effectivement un problème, pour le matériel pro, c'est le problème de ton fournisseur.

Donc pour moi, c’est un problème, et largement suffisant pour discréditer les solutions matérielles à mes yeux, peu importe les merveilles que peuvent me faire miroiter leurs constructeurs. Les « pros » peuvent certainement se permettre de passer par un intermédiaire à qui ils pourront dire « c’est votre problème, débrouillez-vous je veux que ce soit résolu pour avant-hier matin », moi pas.

En cas de de crash électrique, je suis certain que les données ayant été signifiées comme écrites sur disque le sont sont bien physiquement, même en cas de cache menteur sur les disques.

Un problème qui n’existerait pas si le contrôleur disque se contentait de faire son boulot (écrire les requêtes dans l’ordre où l’ordonnanceur du système les lui envoie, et répondre qu’elles ont été écrites une fois que c’est réellement fait) au lieu de jouer au plus malin…

Devoir rajouter un contrôleur RAID pour s’assurer que le contrôleur disque a bien fait son job, j’ai du mal à voir ça comme une bonne idée. Pourquoi pas un contrôleur de contrôleur RAID aussi, pour s’assurer que quand le contrôleur RAID prétend au système que le contrôleur disque prétend avoir écrit les données, elles ont bien été écrites ?

Faut dire qu'il y a les "bons" contrôleurs RAID matériel et les "mauvais" contrôleurs RAID matériel, les bons sont ceux qui ... (je m'égare)

Le mauvais contrôleur RAID, il voit une donnée, bam il la recopie, alors que le bon contrôleur, il voit une donnée… bon ben il la recopie, mais c’est un bon contrôleur.

Blague à part, quand je me suis renseigné sur la question j’ai trouvé que les constructeurs étaient assez avares en informations. Comment sait-on quels sont les contrôleurs compatibles entre eux ? Le seul conseil que j’ai trouvé est de prendre des contrôleurs du même constructeur et « d’à peu près le même modèle »… Je ne trouve pas ça très engageant. Si j’achète un contrôleur RAID aujourd’hui, que demain le constructeur arrête de produire ce modèle et qu’après-demain il tombe en panne (apparemment, ça arrive), je fais quoi ?

Je pense que je préfère faire confiance aux développeurs de la couche RAID du noyau Linux (ou de la couche équivalente sur les autres systèmes).

je pense à la batterie intégrée au contrôleur par exemple.

Euh, elle peut servir à quoi ? (C’est une vraie question.)

btrfs ne t'empêche pas d'utiliser le RAID logiciel et/ou LVM2.

Bien sûr, et je compte bien là-dessus.

Par ailleurs, quitte à faire du RAID, autant que ce soit du RAID matériel

Bof, je n’ai jamais été convaincu par le RAID matériel.

Les contrôleurs RAID matériels ne sont pas forcément compatibles entre eux, un disque membre d’une matrice gérée par un contrôleur A peut ne pas être utilisable avec un contrôleur B ; le jour où il faut remplacer le contrôleur A, ou le jour où je veux transférer les disques sur une autre machine équipée du contrôleur B, je fais quoi ? Le RAID logiciel apporte une appréciable indépendance vis-à-vis du matériel, au prix certes d’une dépendance au système mais pour moi c’est un moindre mal — je ne sais pas si j’aurais dans cinq ans le même matériel qu’aujourd’hui, mais je sais que j’utiliserai encore GNU/Linux.

personnellement, j'estime que ce sont des fonctionnalités qui ont vocation à être intégré dans le système de fichiers, pour diverses raisons:

Faudrait savoir, je croyais que ça devait se situer au niveau du matériel ?

interopérabilité: chaque OS développe sa couche de gestion de volumes logiques et se débrouille pour qu'elles soient toutes incompatibles entre elles.

Et en quoi intégrer ces fonctionnalités dans un nouveau système de fichiers dans notre coin change cette situation ? Btrfs est compatible avec les autres systèmes de fichiers qui adoptent la même approche dans leur coin, comme ZFS ?

btrfs réponds à 95% des besoins des utilisateurs plus ou moins avancés en étant plus fiable, plus performant et plus simple, pour les 5% restant, LVM2 et mdam sont toujours là.

Je dois donc faire partie des 5 % des utilisateurs plus avancés qui ne peuvent être satisfaits par Btrfs. C’est bizarre, je n’avais pas réalisé à quel point mes besoins sortaient de l’ordinaire.

Je ne suis pas sûr que ça me plaise, ça…

Je trouve bien pratique que les fonctionnalités de type RAID et la gestion des « volumes logiques » soient indépendantes du système de fichier. Je ne vois pas trop ce qu’on gagne à intégrer ça dans le système de fichier lui-même.

Par exemple, sur une de mes machines j’ai la configuration suivante : deux disques formant un volume RAID 1, lui-même chiffré par dm-crypt, le volume chiffré servant à son tour de volume physique LVM2 contenant tous les volumes logiques dont j’ai besoin (/, /home, swap, etc.). Si Btrfs remplace à la fois la couche RAID et la couche LVM2, comment intercaler la couche de chiffrement entre les deux ? Si on chiffre en-dessous de Btrfs, alors pour un miroir à deux disques on se retrouve à chiffrer deux fois chaque donnée. Si on chiffre au-dessus de Btrfs, alors il faudra un volume dm-crypt par « volume logique ».

Et quid de la partition de swap ? Dans mon installation actuelle, elle est redondée et chiffrée comme tous les autres volumes logiques. Comment fait-on ça si la redondance est implémentée au niveau du système de fichier et non dans une couche indépendante ?

A priori (mais j’admet ne pas m’être encore renseigné en détail sur Btrfs), il me semble qu’on perd en souplesse par rapport au modèle actuel.