nud a écrit 896 commentaires

• Systemd incompatible with mounted /usr
• Booting Without /usr is Broken

Je n'ai pas d'opinion forgée sur le sujet, mais je suppose que c'est la raison pour laquelle Lennart est pour la fusion de /bin et /usr/bin.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ?

Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?

Sauf pour systemd qui fout ses trucs dans /bin au lieu de /sbin

$ ls -l /etc/mtab 
lrwxrwxrwx 1 root root 17 Apr  5  2011 /etc/mtab -> /proc/self/mounts

Le plus parlant est udev, qui est démarré très tôt (typiquement tu n'as que la partition root qui est montée), et qui, avant l'invention de /run, mettait ses données "runtime" dans /etc/.udev, ce qui n'était pas très propre.

Il y a d'autres services qui faisaient de même à divers endroits, et, bien évidemment, rien de standardisé ou prédictible.

Donc je trouve que /run est plutôt bien venu, même s'il n'était pas utile du temps où le FHS a été créé, le temps béni du mknod.

Ceci dit, dans les voitures modernes (pour l'instant en option, mais probablement bientôt de série) tu as:

• les boites (semi-)automatiques, moins polluantes mais déroutantes pour un européen, et qui risquent de devenir obligatoires;
• les freins à main électroniques
• les systèmes start/stop
• la foultitude d'éléments automatiques (phares, essuie-glaces, etc)
• les systèmes de verrouillage centralisé automatique (anti-car-jacking)
• les systèmes d'aide au démarrage en côte
• sans doute plein d'autres

Changer le volant, c'est comme changer la façon primaire d'interagir avec la machine. Personne ne l'a fait en automobile parce qu'on a pas encore trouvé de meilleure solution.

Mais les systèmes périphériques (mais quand même importants) cités ci-dessus sont amenés à changer inéluctablement parce que l'alternative apporte un '+'. Et certains prennent les bonnes décisions à ta place sans te demander ton avis, et ne sont même pas débrayables (je pense aux aides au démarrage, ou à la boite de vitesse).

Quant tout cela sera généralisé, tu devras changer tes habitudes. Tu seras alors toujours libre de ne pas passer aux nouveaux systèmes, mais alors tu devras:

• prendre une voiture d'occasion
• prendre une voiture "bas de gamme" genre Dacia, Tata...
• ne plus conduire.

Chacune de ces alternatives apporte son lot de points négatifs.

Mais après, moi, je vais te dire autre chose. La dernière fois que tu as changé de voiture, tu as peut-être changé de marque de voiture. Et tu as été dérouté quelques jours par le fait que pas deux marques n'ont des contrôles identiques au niveau des sticks près du volant (phares, essuie-glaces, etc). Et tu t'y es habitué.

C'est un peu bête de dupliquer les efforts sur toutes les applis alors que seuls les éléments du bureau sont intéressants à maintenir dans cette optique... et peuvent être portés sur Qt4.

Y'a un peu des deux. Le minimum vital a quand même dû être implémenté, et des rustines ont été placées par la suite.

Les gens qui ont implémenté clutter (et donc mutter) ont pris le pari de ne pas mettre de rustine et d'obliger à la correction des drivers, ce qui fait que dans un premier temps, ben ça marche pas fort pour les drivers buggés.

D'ailleurs kwin a aussi implémenté quelques rustines (bien que sans doute beaucoup moins que compiz, soyons sérieux), car je me souviens de la râlerie qui avait suivi la correction de je-ne-sais-plus quel bug dans un driver, qui du coup faisait bugger kwin...

Une distribution Linux : je n'ai rien contre les BSDs mais le support matériel est bien meilleur sous une distribution Linux. Pourquoi, il y a des distributions optimisée pour Mutter ou GNOME 3 ?

Non mais y'a tout simplement des distributions qui fournissent des drivers plus à jour. Si gnome-shell ne fonctionne pas c'est peut-être tout simplement que ta carte (ou plus vraisemblablement que ton driver) ne supporte pas une API OpenGL particulière utilisée par mutter mais pas par compiz.

Si tu te souviens de l'époque où compiz a fait son apparition, le support était à peu près aussi catastrophique, mais les gens ont corrigé les drivers vidéo pour que compiz puisse fonctionner. Le même se passe avec gnome-shell. Ce n'est pas que une question de vieillesse de la carte graphique.

Asterisk est réputé pour la mauvaise qualité du logiciel, principalement au niveau de la stabilité, à cause d'un manque criant de tests et d'utilisation du produit par les développeurs principaux.

Ici, professionnnellement, nous utilisons (entre autres) Asterisk, mais nous en sommes toujours à la version 1.4, car les versions 1.6 et 1.8 sont tout simplement inutilisables: pour peu qu'on fasse quelque chose d'un peu compliqué, ça crashe. ET même dans la branche 1.4 il a fallu attendre 1.4.22 pour avoir quelque chose de stable (en passant sous silence certaines des dernières versions qui deadlockaient très vite).

J'espère qu'ils ont redressé la barre pour la (1.)10

Ben il faut que tu fasses tourner tcpdump sur le pc avec les trois cartes réseau et que tu reproduises ton problème. Tu devrais assez vite voir ce qu'il se passe et où disparaissent tes paquets.

# tcpdump -i any -s 1024

On le faisait en 320x200, en 640x480 si tu avais de la chance, en 8 ou 16 bits, en 15 images/secondes, et le rendu se faisait pixel par pixel directement sur le hardware.

Maintenant on voit les choses en grand (le lien du journal parle de 2048x1152), en 24 bits, et on veut du 30 voire du 60 images par secondes. Aussi l'écran est partagé entre plusieurs fenêtres indépendantes, qui veulent pouvoir gérer des zones semi-transparentes, etc. En plus on a une pile d'indirections et de copies intermédiaires dans les pattes (à commencer par X11).

C'est comparer des pommes et des poires.

Y'a EDS, mais il y avait des bruits de couloirs qui parlaient d'utiliser Akonadi également.

Il n'y a pas besoin de faire un fork de tout, il aurait suffi de se proposer pour maintenir tout ce qu'il faut, au sein de gnome ou ailleurs.

Sawfish est toujours maintenu par exemple.

C'est un peu comme les poudres à lessiver, aussi.

À moins que tu ne parles de tâche ?

J'ai trouvé ceci en belgique:

http://www.gdb.be/FR/bureaux/stations-de-travail/table-assis-debout.htm
C'est une table réglable en hauteur électriquement.

Malheureusement le site en question est plutôt orienté entreprises et je n'ai pas trouvé de prix.

Déjà c'est mal parti, les référendums sont illégaux dans plusieurs pays de la zone euro, à commencer par la Belgique.

Potentiellement ces outils d'installation propres à chaque langage devraient être capable de produire directement un paquet pour chaque distribution, qui un deb, qui un rpm, etc. Il suffirait qu'un ou quelques courageux s'y colle! (Comme toujours, vous me direz!)

Oui, le problème conceptuel étant la séparation entre packaging et code. Si tu avais lu les liens du post avant, tu aurais vu que le problème réside dans le fait que "gems" est intrusif (les gens utilisent l'api gem directement dans le code) ce qui fait que le code en question ne peut plus être installé indépendamment de gems. Comme je le disais, le même problème s'est posé avec setuptools. Sans cela, pas besoin de gems, donc pas de problèmes de packaging.

L'autre problème qui fait qu'un paquet debian (ou redhat, ou arch, ou n'importe quelle autre distro) ne peut pas fournir directement un fichier gem est que les gestionnaires de paquets des distributions sont faits spécifiquement pour éviter l'installation de plusieurs versions mineures successives de la même lib car cela ne sert à rien et est contre-productif. À l'opposé, les gems obligent à l'installation de versions mineures différentes dans des dossiers différents, en fonction de ce qui est demandé par les applications.

(bon, à strictement parler, on pourrait s'amuser à travailler comme pour le noyau linux avec des paquets libfoo-ruby-2.2.3, libfoo-ruby-2.2.6, etc, mais avouez quand même que sailamert)

C'est justement tout le noeud du problème. La guéguerre qui a opposé Debian et les rubyistes, c'est un conflit entre administrateurs et développeurs.

En l'occurence, le système des gems ont été faites par des développeurs, pour des développeurs, et lesdits développeurs n'ont rien à caler du fait que d'autres non-développeurs ou d'autres non-rubyistes essaient d'utiliser le code. Ceux qui veulent utiliser un projet ruby n'ont qu'à apprendre à se servir de ruby et de son écosystème.

De l'autre côté, APT a été fait par et pour des administrateurs systèmes, qui veulent pouvoir utiliser $project sans se soucier du langage avec lequel il est programmé. Après tout c'est un détail d'implémentation, et je ne vois pas pourquoi je devrais apprendre tout ce qui a trait à ruby, gems ou whatever juste pour utiliser, par exemple, redmine ou tracks. apt-get install redmine tracks devrait suffire.

Le pire est que les deux points de vue ne sont pas forcément incompatibles: une histoire similaire a eu lieu dans le monde python avec setuptools et les "eggs", qui, comme les gems, sont très intrusifs même au niveau du code et ne sont pas "compatibles" avec une distribution des packages ala APT. Le problème a été résolu avec l'évolution vers "pip".

En fait, en lisant la page du wiki de Debian à propos de RubyGems il semblerait qu'il soit en fait possible pour les rubyistes de rendre leur code packageable avec un peu d'attention, un peu comme la dualité distutils/setuptools de python.

La teneur de ma question était donc: 'est-ce que la communauté ruby a gagné en maturité ou est-ce que ce dernier changement consiste encore à montrer le mauvais doigt aux distributions?'

Voilà qui va ravir toutes les distributions... Est-ce que les problèmes inhérents aux Gems ont été corrigés ?

En l'occurence, c'est un comportement erroné de la glibc, sauf si on considère que toutes les variables pouvant être touchées par des threads devraient être marquées comme volatile (ce qui niquerait quasi toutes les optimisations alors qu'il est plus simple de juste bloquer ces optimisations au niveau des mutex).

Ce n'est pas vraiment un effet de bord, il n'y a aucun effet sur le code appelant ou sur l'extérieur. Et la définition d'une fonction pure est respectée dans le cas de la mémoisation: la valeur retournée ne dépend que des arguments.

Oui c'est aussi pour ça que je n'ai pas cité printf dans mes exemples.

Je soupçonne que le patch de la libc a été fait automatiquement par un script quelconque et printf n'a pas vraiment d'argument callback défini, c'est dans le vararg.

Dans tous les cas je pense que quel que soit l'ordre dans lequel tu appelles la fonction sinus, le résultat sera le même. De toute façon, la seule contrainte d'après la documentation est que la fonction ne doit pas retaper dans l'unité de compilation courante pendant son exécution (c'est pourquoi cet attribut a été appliqué à toutes les fonctions de la glibc qui n'utilisent pas de callback).

Calls to external functions with this attribute must return to the current compilation unit only by return or by exception handling. In particular, leaf functions are not allowed to call callback function passed to it from the current compilation unit or directly call functions exported by the unit or longjmp into the unit. Leaf function might still call functions from other compilation units and thus they are not necessarily leaf in the sense that they contain no function calls at all.

Le problème avec les fonctions pthread étant que, justement, elles peuvent, indirectement, retaper dans l'unité de compilation courante, même sans callback.

Ça implique aussi que toutes les fonctions mathématiques sont "leaf", car elles sont "pure" (la sortie ne dépend que des arguments et il n'y a pas d'effet de bord visible, les opérations de cache interne, etc ne comptant pas). C'est aussi le cas de strlen que je citais précédemment.

Many functions have no effects except the return value and their return value depends only on the parameters and/or global variables. Such a function can be subject to common subexpression elimination and loop optimization just as an arithmetic operator would be.

Par contre, des fonctions qui ne dépendent que de leurs arguments mais qui ont un effet de bord (comme fputs et consorts) ou qui conservent un cache interne (comme strtok) sont "leaf" mais ne sont pas "pure".