Guillaume Knispel a écrit 2474 commentaires

C'est une grosse simplification tout ça.

Disons histoire d'être un chouilla plus précis que l'on peut effectuer des modifications sous GPL à un code BSD ce qui lorsqu'elles sont en volume suffisant revient de facto à relicensier le résultat en GPL only, mais étant donné un fichier sous BSD non modifié ou avec des modifications triviales il est hors de question de s'amuser à remplacer la licence BSD par une GPL.

Et il faut de toute manière conserver la notice BSD dans tous les cas, ce qui ne veut pas forcement dire que le module entier modifié reste forcement sous licence BSD, on peut par exemple écrire :

Notice GPL
Ce fichier contient entre autres des parties de trucmuche qui sont sous licence BSD :
Notice BSD.

Nan je pense que c'est la bonne déf.
Ça fait longteeeeeemps que j'ai pas fait de chimie, et j'ai pas une très bonne mémoire.

A tient c'est marrant je pensais que ça pouvait aussi désigner les molécules qui contiennent de l'oxygène.
J'ai appris un truc :)

L'argent initial est propre, ton bilan est propre, mais les sous dans ta poche sont sales.

C'est donc du salissement d'argent propre.

Et alors ?

T'as *plein* d'outils probabilstes et statistiques partout, y compris en crypto où ta clef privée est *probablement* un nombre premier. Et pourtant, on est bien heureux d'avoir ces probables garanties.

Argument particulièrement moisi.
(je passe sur le fait que ta clef privée n'est PAS un nombre premier)

Les algorithmes de test de primalité probabiliste permettent d'obtenir une probabilité aussi bonne que l'on souhaite à priori. On est de plus dans un domaine totalement abstrait. Ce n'est pas le cas des détecteurs de mensonges, qui ont en outre un historique de performance particulièrement mauvais quelque soit la technologie employée (et c'est intrinsèque parce qu'on ne mesure de toute manière jamais directement un "indicateur" de mensonge mais toujours un indicateur de "symptome", et corrélation n'est pas causalité).

Hm "STLS2F01 Loongson 2F: MIPS® High performance 64-bit superscalar microprocessor - Preliminary Data" c'est surtout le datasheet du processeur, tous les vendeurs de processeurs les diffusent publiquement (sauf les TRÈS méchants pas gentils mais ceux-là sont tellement pas gentils qu'il faut les oublier à jamais).

Je voulais plutôt du code VHDL ou l'équivalent moi :p

Si c'est pas un hydrocarbure, c'est quoi ? De l'uranium enrichi ? ;)

Toute ton énergie finira invariablement en chaleur, donc non le rendement n'est pas supérieur avec un chauffage électrique (par contre il se peut que la répartition de la chaleur soit mauvaise, mais un peu de ventilation y remédiera). Il faut utiliser une pompe à chaleur pour obtenir des rendements supérieurs.

Tu ne devrais pas non plus la payer si tu fais marcher ta chaudière d'habitation au biocarburant.

euh, pourquoi ?

j'ai envie de troller alors j'espère que le matos MIPS qui fera tourner gNewSense est fourni avec tous les plans de toutes les puces, sous licence libre. (et tant qu'à faire toutes les documentations de conception).

Je vois pas en quoi supprimer les partitions avec fdisk est moins bien qu'avec autre chose. C'est pas particulièrement compliqué pour quelqu'un qui sait lire... c'est le genre de truc pour lequel une GUI n'apporte pas grand chose.

Mais bien sûr que si que c'est un problème de dépot stable / instable (j'avais pas pris en compte plus haut que c'était sur un dépot instable, je croyais que c'était plus grave que ça). Le système des dépots à plusieurs niveau de stabilité fait parti intégrante du processus de qualité des distributions, et le fait que le problème ait été détecté sur un dépôt instable au lieu d'exploser à la gueule de tout le monde montre que le processus fonctionne. L'existence même du dépôt instable est en partie due à la nécessité de tester en public et de limiter l'impact des erreurs qui auraient pu ne pas être remarquées par les mainteneurs et autres personnes intéressées par la modification pendant leur tests persos (qui eux aussi sont généralement en partie public avec un dialogue généralement basé sur une ML publique ou un tracker public, etc.)

À noter finalement qu'il ne faut pas comprendre de travers le sens des mots stables / instables qui désigne en priorité le rythme des modifications dans ce cas, et non de manière directe la propension à crasher / tout casser / etc. (bien de manière indirecte et même voulu une distribution stable, ayant vu un effort de qualité supérieur, présente moins de risque de problème qu'une instable pris au pif et freezée).

Le problème c'est qu'il a probablement commencé par être simple (j'ai pas vraiment suivi ses débuts, mais au vu du résultat je pense que c'est le scénario le plus probable) puis qu'il a suivi une croissance organique bancale - sans les révisions d'architecture nécessaires. Du coup rien que le scénario extrêmement banal suivant a nécessité à un collègue de nombreuses heures de prise de tête pour que ça "marchote" (c'était pas destiné à un produit, donc pas de test de robustesse, etc...)

Un disque externe USB qu'on peut brancher / débrancher à l'envie.
Il a un nom fixé (inféré à partir de son numéro de série) dans /dev/
Il se monte tout seul quand on le branche sur un point de montage qui lui est dédié.
Son contenu est exporté en NFS via le point de montage (il y en a qu'un) quand il est branché.
L'export est terminé et le point de montage est nettoyé quand il est débranché.

(y a du udev en jeu mais aussi pleins d'autres trucs, et malgré qu'on soit sur le même système personne ne couche correctement avec son voisin sans l'aide d'un gourou ayant de nombreuses années d'expériences)

De plus l'idée de parser les conf udev et de les générer en script shell est vraiment délirante (faudra que je vérifie s'ils sont pas en train de revenir à la raison dans les dernières versions).

Je ne suis pas à priori contre l'intégration de tas de petits outils simples si leur périmètres sont définis correctement, et que l'intégration est soignée. Sauf que ça fait belle lurette que j'ai pas vu ces conditions remplies dans le monde GNU/Linux couches basses userspace ; exemple à la con illustrant les limites du bazar perpétuel : ifplugd + des vlans et un mélange de dhcp et confs statiques. Vous m'en direz des nouvelles. Où encore les workarounds délirants à base de pause de X secondes au démarrage des machines parce que le démon XYZ se met en background très tôt et que la suite du boot dépend du fait qu'il ait fait un peu de taf, et qu'on prie pour que X secondes soit ok pour qu'il ait fait un tel taf (et que les ressources dont il dépend pour faire ce raf soient OK...)

Tout ça marchotte. Des fois. D'autres fois ça augmente le coût d'utilisation de GNU/Linux d'une manière absurde. Bref c'est très bancal.

En résumé ça fait longtemps qu'on aurait du mettre l'architecture à base de sysvinit, de /etc/init.d simpliste et de culte irrationnel du script shell (enfin des petites scripts simples why not, des programmes de plusieurs milliers de lignes, ... no comment) à la poubelle pour obtenir un système solide, et malheureusement bien que udev soit assez récent mon opinion est qu'il est tombé (comme des tonnes d'autres outils) en plein dans les travers du culte d'unix tel qu'il était dans les années 70-80.

Si c'est l'hiver, que ça ne te gène pas pour une autre raison, et que tu te chauffe à l'électricité, tu as tout intérêt à laisser tes machines allumées.

D'implémenter n'importe comment des parsers et générateurs de conf en script shell (configuration qui d'ailleurs ressemble à du code, mais version spaghetti -- alors quand on sait que des scripts shell la lisent et l'écrivent on atteint un optimum local d'horreur) et d'ajouter un caillou de plus posé en équilibre sur le mur instable de la plomberie irrationnelle des couches basses de configuration des systèmes GNU/Linux, plomberie construite au nom des principes Unix mais dévoyés, invoqués à mauvais escient, et invoqués probablement avec la croyance absurde qu'une telle architecture diminue l'effort en intégration alors qu'il devrait être augmenté pour obtenir un résultat vaguement fonctionnel (et bien évidemment l'effort effectif est ridiculement bas).

À mon goût tout ça va beaucoup trop loin dans le "worse is better".

Le résultat est la diaspora des systèmes GNU/Linux dans ce plan (couches basses userspace en général), qui je pense va plutôt avoir tendance à continuer à s'intensifier. C'est à mon avis particulièrement mauvais car cela entraîne la dilution des efforts qui implique dans énormément de cas des implémentations de mauvaise qualité qui s'effondrent lamentablement à la première apparition d'un besoin fonctionnel non rencontré par l'auteur d'un composant qui ne devrait pas impacter si l'architecture avait été pensée. La modularité tant saluée n'est en fait que réservée pour les développeurs (et à la condition supplémentaire qu'ils aient beaucoup de temps libre pour mettre suffisamment de scotch afin de faire disparaître la partie visible du symptôme), les simples utilisateurs en étant privé car n'ayant pas les moyens de faire tomber en marche la conjonction des fonctionnalités qu'ils souhaitent.

Le seul moyen de faire pire serait d'introduire de l'XML et du Java dans tout ce bordel (pour le XML, certains ont malheureusement déjà commencé, j'imagine que le Java arrivera dans quelques années).

En même temps difficile de faire mieux sans alourdir par avance toutes les structures du système pour quelque chose que finalement peu de monde utilisera (qu'elle est la proportion des machines ne pouvant tolérer un reboot ? -- j'espère faible car que ce passerait-il en cas de défaillance de telles machines...)

Le cloud computing c'est surtout un mot de business loto web 3.14 pour désigner quelque chose qui existe depuis des décennies, et qui a besoin d'une nouvelle désignation pour ne pas faire has been - et même pour faire "in" parmi les décidors praissés.

Ce qui ne remet pas en cause son intérêt intrinsèque quand employé (le concept, pas forcement le mot) par des gens équipés de cerveau ayant un but rationnel (ouai bon ok ça fait beaucoup de conditions tout ça ;)

Et t'as besoin de ça pour être rassuré ? ;)

Ce genre de personne est en fait très utile. Leur discours permet au candidat de dire au revoir, de se lever et de partir, et évite donc de perdre du temps.

J'espère qu'elle a rendu les CD, et dans le cas contraire je me demande si ça peut être assimilé à du vol.

Ça c'est faux et bien avant le siècle dernier... (bon je ne retrouve plus la référence à l'époque de Napoléon...)

Ça n'a rien de faux. Ça ne signifie simplement pas ce qu'on pourrait naïvement croire.

Hm j'ai une trop bonne mémoire c'est pas si récent que ça en fait (24 novembre) :P

http://lwn.net/Articles/308409/

C'est assez cinglé comme technique mais les trucs cinglés dans les noyaux ne m'étonnent plus trop -- je me souviens par contre de l'époque où j'avais eu un choc en découvrant le hotpatching supprimant les spinlock sur monoprocesseur ;).

Ceci étant, avis à toutes les fashions victimes, prière de réserver le hotpatching aux cas où c'est vraiment absolument indispensable.

Comment peut-on aimer udev ?

S'il a choisi de s'enfermer sur un repository spécifique, c'est un peu son problème...