L'interview couvre un grand nombre de sujets, souvent peu ou pas traités dans d'autres interviews. Ainsi, l'interview permet de revenir sur les débuts de RMS avec les ordinateurs, sur son travail au Al Lab, sur Hurd, sur Emacs, sur le code qu'écrit RMS actuellement. Des sujets plus classiques comme les Logiciels Libres, les logiciels propriétaires, SCO, GNU/Linux sont également abordés.
Aller plus loin
- Interview (35 clics)
- KernelTrap (10 clics)
- DLFP: interview récente avec Federico Biancuzzi surlinuxdevcenter.com (6 clics)
# GNU slash Linux
Posté par gc (site web personnel) . Évalué à 9.
[^] # Re: GNU slash Linux
Posté par peco . Évalué à 5.
Pourquoi ne pas dire aussi "mon pc tourne avec un système KDE ou GNOME". Au fond, c'est ce qui a le plus d'impact, sur l'utilisateur gamma.
[^] # Re: GNU slash Linux
Posté par Mathieu Pillard (site web personnel) . Évalué à 9.
[^] # Re: GNU slash Linux
Posté par galactikboulay . Évalué à 6.
Dire "GNU+Linux", je trouve ça vraiment abusif, comme si il n'y avait que les outils GNU et le noyau Linux, et c'est tout.
[^] # Re: GNU slash Linux
Posté par Philippe F (site web personnel) . Évalué à 2.
Meme si ce n'est pas exact de substituer le mot linux a la distribution ou au systeme Gnu + Linux + X11 + KDE + Gnome, je pense que ca reste le moyen le plus simple et le plus efficace pour faire passer le message philosophique car on se reccroche a quelque chose que les gens connaissent un peu ou dont ils ont entendu parle.
[^] # Re: GNU slash Linux
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Re: GNU slash Linux
Posté par rhizome . Évalué à 3.
Pas vraiment quand même. Le kernel, c'est ce qui fait marcher les périphériques, et l'utilisateur, faire marcher ses pérhiphéques, c'est généralement quelque chose qui l'intéresse. L'autre chose qui l'intéresse, c'est de faire tourner des applications. Personnellement, c'est à cause de ces deux raisons que j'utilise Linux et pas un *BSD en desktop.
Les logiciels GNU sont très présents aux côtés des *BSD également, GNU n'est donc pas en ce qui me concerne un terme pertinant pour identifier l'OS que j'utilise.
[^] # Re: GNU slash Linux
Posté par totof2000 . Évalué à 2.
Quels sont tes besoins pour le desktop?
[^] # Re: GNU slash Linux
Posté par rhizome . Évalué à 1.
Sinon j'ai utilisé un FreeBSD pendant un an et demi comme workstation sans rencontrer de lacune majeure.
[^] # Re: GNU slash Linux
Posté par Jerome Herman . Évalué à -1.
De moins en moins. Entre la philosophie GNU d'un coté et RMS de l'autre un certains nombres d'acteurs de BSD ont décidés de tout recoder en license BSD pure. Il ne reste guerre plus que les compilos qui soient encore en GPL dans une install OpenBSD ou FreeBSD récente (pour NetBSD je ne connais pas, donc je ne dis rien).
[^] # Re: GNU slash Linux
Posté par ufoot (site web personnel) . Évalué à 2.
En même temps c'est justement ce qui me refroidit d'utiliser ce type de système. Concrètement j'ai fait un tour du côté de FreeBSD mais au bout d'un moment je finis avec un système patché de A à Z avec bash et tous les outils GNU donc. Du coup l'intérêt d'avoir un tel système est (pour moi) assez léger, vu que je ne peux pas l'utiliser "clé en main" dans la config par défaut. C'est peut-être parce que je suis trop habitué aux outils GNU mais bon j'ai un peu pas le courage de reprendre de nouvelles habitudes "juste comme ça pour voir".
[^] # Re: GNU slash Linux
Posté par rhizome . Évalué à 2.
Comme beaucoup d'utilisateurs de certains OS propriétaires ;)
[^] # Re: GNU slash Linux
Posté par gc (site web personnel) . Évalué à 4.
[^] # Re: GNU slash Linux
Posté par rhizome . Évalué à 1.
[^] # Re: GNU slash Linux
Posté par rhizome . Évalué à 3.
Mais pour revenir au sujet qui m'avait fait réagir, les différences entre le ls BSD ou le GNU ls ou encore entre le make BSD et le GNU make m'affectent peu. Les différences entre les noyaux m'importent beaucoup plus. Je continuerais donc à dire Linux, Open, Net ou Fribi qui sont des discriminant plus porteurs de sens dans le cadre de l'utilisation que j'en fais que GNU ou pas GNU. Ce qui m'importe aussi bien évidemment c'est la gestion des paquetages et le système de démarrage, là encore, GNU n'y est pas pour grand chose.
[^] # Re: GNU slash Linux
Posté par Brice Carpentier . Évalué à 10.
Just my 2¢
[^] # Re: GNU slash Linux
Posté par Beretta_Vexee . Évalué à -6.
[^] # Re: GNU slash Linux
Posté par pikapika . Évalué à 1.
et pour la carte, tu voulais peut être parler d'une partie de belote ?
[^] # Re: GNU slash Linux
Posté par Bloodshed . Évalué à 1.
mais sinon je dis le nom de la distrib (Debian testing :))
[^] # Re: GNU slash Linux
Posté par ElVirolo (site web personnel) . Évalué à 3.
In talking about GNU Linux...
Richard Stallman: I prefer to pronounce it GNU-slash-Linux, or GNU-plus-Linux. The reason is that when you say GNU-Linux it is very much prone to suggest a misleading interpretation. After all, we have GNU Emacs which is the version of Emacs which was developed for GNU. If you say "GNU Linux", people will think it means a version of Linux that was developed for GNU. Which is not the fact.
[^] # Re: GNU slash Linux
Posté par Bloodshed . Évalué à 1.
Moi ma formulation exacte est :
Debian GNU/Linux/Mozilla/Ion
[^] # Re: GNU slash Linux
Posté par Pooly (site web personnel) . Évalué à 2.
Tu va êtrebon pour un Debian GNu+Linux/Freebird/Ion
[^] # Re: GNU slash Linux
Posté par Olivier Samyn (site web personnel) . Évalué à 10.
En effet, dans la pratique personne n'utilisera "GNU plus Linux"...
Mais je crois qu'en tant de défenseur du logiciel libre, RMS se doit de mettre en avant cette distinction GNU et Linux. Et il le fait d'une manière très simple: en jouant sur le nom.
Souvent les déclaration d'RMS sont un peu "extrémistes", mais si RMS lui-même commençait à mettre certains principes des logiciels libres en veilleuse, les principes eux-même perdraient de leur crédibilité.
[^] # Re: GNU slash Linux
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Par contre en quelques minutes, je peux parler des 4 libertés du logiciel libre que chacun peut comprendre car il s'agit d'une démarche philosophique et d'un discours sur la liberté.
Richard pense qu'une différence de culture nous rend plus sensibles sur le sujet que de l'autre côté de l'océan atlantique.
Pour étayer mes propos, pensez à tous ces néophytes qui utilsent le système Word ou vont lire leurs mails avec Windows. Je n'exagère même pas... Je ne vois pas comment expliquer à ces gens il faut dire GNU/Linux alors que pour eux Linux désigne une distribution complète ou est dans le meilleur des cas un synonyme de "Ensemble des Logiciels Libres".
Je crois donc, qu'il est bien préférable de commencer par expliquer ce que sont les logiciels libres en utilisant les 4 libertés.
Ce n'est qu'après que je leur montre http://pjarillon.free.fr/docs/conferences/def-distro.png(...)
[^] # Re: GNU slash Linux
Posté par Antoine . Évalué à 2.
Souvent les déclaration d'RMS sont un peu "extrémistes", mais si RMS lui-même commençait à mettre certains principes des logiciels libres en veilleuse, les principes eux-même perdraient de leur crédibilité.
Je ne savais pas que dire GNU/bidule faisait partie des principes du logiciel libre...
Antoine Pitrou/Fournier.
[^] # Re: GNU slash Linux
Posté par gaaaaaAab . Évalué à 3.
[^] # Re: GNU slash Linux
Posté par chx dein . Évalué à 6.
Monologue du noob
Tiens donc... GNU/Linux... C'est quoi ça GNU ? Je pensais que ça s'appellait seulement Linux ! Je vais recherche sur Google... (http://www.google.fr/search?hl=fr&q=GNU&btnG=Rechercher&(...) )
Essayons le premier lien : http://www.gnu.org/home.fr.html(...)
Exactement ce que je me demandais : Pourquoi GNU/Linux ?
http://www.gnu.org/gnu/linux-and-gnu.fr.html(...)
Marrant ! C'est quoi un logiciel libre ?
http://www.gnu.org/gnu/linux-and-gnu.fr.html(...)
Et ainsi de suite...
[^] # Re: GNU slash Linux
Posté par galactikboulay . Évalué à 5.
[^] # Re: GNU slash Linux
Posté par gaaaaaAab . Évalué à 2.
[^] # Re: GNU slash Linux
Posté par I P . Évalué à 7.
[^] # Re: GNU slash Linux
Posté par Star_Dust . Évalué à 1.
[^] # Re: GNU slash Linux
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 4.
Mais il est vrai que je pourrais dire que j'utilise une Debian GNU/Linux Sarge GNOME/XFCE Gecko. Là, ce serait de l'abus, mais ça aurait le mérite d'être assez complet ;)
[^] # Re: GNU slash Linux
Posté par XHTML/CSS inside (site web personnel) . Évalué à -5.
GNU's not Linux => GNU's not Linux slash Linux !
Et si on fait l'acronyme récursif : (je remplace GNU par sa signification)
...GNU's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux's not Linux slash Linux !
C'est pas du Linux, mais pourquoi ça le répête autant ? :->
[^] # Re: GNU slash Linux
Posté par lorill (site web personnel) . Évalué à 2.
faut se relire de temps en temps :-)
[^] # Re: GNU slash Linux
Posté par XHTML/CSS inside (site web personnel) . Évalué à -1.
GNU's not Unix => GNU's not Unix slash Linux !
Et si on fait l'acronyme récursif : (je remplace GNU par sa signification)
...GNU's not Unix's not Unix's not Unix's not Unix slash Linux !
Bref, ===>[]
[^] # Re: GNU slash Linux
Posté par Bloodshed . Évalué à 2.
[^] # Re: GNU slash Linux
Posté par totof2000 . Évalué à 1.
GNU's Not Linux !!!
En plus c'est encore plus compliqué a prononcer :
"Ah moi j'utilise pas window, j'utilmise GNL"
" Hein, qu'est-ce qu'il y a, t'es malade ???"
[^] # Re: GNU slash Linux
Posté par kra . Évalué à 1.
GNU/LNG
GNU's not unix/Linux's not GNU
bien ca, comme ca au moins on tire les chose au clair, pas d'ambiguite possible!!!
[^] # Re: GNU slash Linux
Posté par table_volante . Évalué à -1.
RMS est décidément très dogmatique dans son approche. Ca transparaît de manière troublante jusque dans ses formulations :
"It's the GNU operating system, and the Hurd is its kernel"
Ca sonne vraiment comme "Il n'y a de Dieu qu'Allah, et Mahomet est son prophète", vous ne trouvez pas ?
[^] # Re: GNU slash Linux
Posté par Jiel (site web personnel) . Évalué à 1.
Non.
[^] # Re: GNU slash Linux
Posté par Raphaël G. (site web personnel) . Évalué à 1.
D'abord y a que linux comme messie...
Le reste c'est une blaque de Gnou...
# quelqu'un ?
Posté par skasowac . Évalué à 4.
là en anglais je nage.
merci !
[^] # Re: quelqu'un ?
Posté par plagiats . Évalué à 1.
"Suivi de l'information guidée par les dépendances" ?
[^] # Re: quelqu'un ?
Posté par BAud (site web personnel) . Évalué à 6.
ça parle d'intelligence artificielle, je dirais rétro-propagation par suivi des dépendances...
d'ailleurs la question est posée dans l'interview et la réponse est :
You make some assumptions, and with those together with some given facts you draw a conclusion. You may reach a contradiction; if so, at least one of your assumptions that led to that contradiction must be wrong. You also record which combination of assumptions actually related to the contradiction, so you can deduce that that combination of assumptions cannot all be true. Then you backtrack by changing assumptions, but you never try a set of assumptions that includes the combination that you know are contradictory. Now, this is a technique that people had used for a long time in thinking. It's also known as proof analysis. But it hadn't been used in computerized reasoning.
c'est pas du réseau de neurones (c'est venu après de toute façon il me semble, genre dans les années 80...) c'est plutôt du système expert : t'as un ensemble de règles, tu les appliques à partir de tes conditions initiales, t'arrives sur une contradiction (en comparant à d'autres données disponibles ou une règle...) donc là tu repars en arrière en changeant certaines des conditions initiales (ou des hypothèses...) et tu redescends... du parcours d'arbre avec données incomplètes que tu cherches à trouver sans doute...
L'exemple qui me vient en tête c'est l'algo pour trouver la sortie dans un labyrinthe : quand t'arrives à la sortie c'est fini, si t'arrives à un cul de sac tu reviens au précédent choix que tu as fait et tu continues jusqu'à arriver à la sortie : là tu tiens une solution.
[^] # Re: quelqu'un ?
Posté par Zakath (site web personnel) . Évalué à 4.
Non, c'est arrivé très tôt (du temps de Minsky, en fait), vers le début des années 60 (voire peut-être avant mais je ne suis pas sûr). Comme toujours dans l'AI, il y a eu des hauts et des bas : d'abord tout le monde pensait que ce serait la solution ultime puis on s'est rendu compte que, en fait, non, et tout le monde s'est mis à leur taper dessus et ainsi de suite..
[^] # Re: quelqu'un ?
Posté par Manuel Menal . Évalué à 10.
Il s'agit grosso modo de modéliser un problème par un jeu de variables, pouvant prendre leurs valeurs dans un domaine, et un jeu de contraintes. Résoudre le problème revient alors à trouver des valeurs pour les variables de telle sorte que toutes les contraintes soient satisfaites. Le grand classique des CSP est le problème des reines, où il s'agit de placer 8 reines sur un échiquier de façon à ce qu'aucune ne risque de se faire prendre au coup suivant. On peut facilement identifier les X variables (8 couples, les coordonnées), les contraintes (lignes différentes, diagonales différentes, etc.). On peut alors disposer de tout l'armada algorithmique développé pour les CSP pour résoudre le problème des 8 reines.
La méthode naïve est la méthode de recherche par arbre, où on explore toutes les possiblités. C'est codé en trois minutes, mais vous vous rendrez vite compte que vos enfants, petits-enfants et l'Humanité sera probablement décédée quand vous aurez toutes vos solutions. Pour résoudre ça, on fait appel au "backtracking", c'est à dire qu'au lieu de générer et tester naïvement toutes les possibilités on va vérifier à chaque fois que l'instanciation partielle (par exemple, 4 reines sur 8 seulement) est bien consistante (elle ne viole aucune contrainte). Quand une instanciation partielle devient inconsistante, on backtracke, et on essaye l'autre combinaison. On a donc coupé une bonne partie de notre arbre, et les choses vont beaucoup mieux.
L'idée derrière le DDB (Dependency-Directed Backtracking, ce dont Stallman parlait) est que le backtracking "simple" (backtracking chronologique) explore une grande partie de l'espace de recherche du CSP en redécouvrant à chaque fois les mêmes contradictions. Il suffit pour éviter ça de garder en mémoire une trace des inférences que l'exploration a réussi à mettre en évidence (les dépendances, donc) et les contradictions rencontrées (les "nogoods" dans le papier en question). De là, on peut s'éviter beaucoup de tests inutiles, et plus facilement inférer une solution partiellement consistante lorsqu'on se retrouve bloqué dans un cas d'inconsistance.
Le DDB est une technique très utilisée en programmation par contraintes, et en particulier dans toute la branche de la démonstration automatique, et de l'analyse de preuves.
(Disclaimer: je n'assure pas la clareté ou le sens de mes propos à 2am. Désolé ;-)
[^] # Re: quelqu'un ?
Posté par Manuel Menal . Évalué à 10.
http://www710.univ-lyon1.fr/~csolnon/Site-PPC/e-miage-ppc-som.htm a l'air très, très bien fait.
http://www-cdr.stanford.edu/NextLink/ConstraintManager/constraint-satisfaction-problem.html pour un petit exemple de DDB.
http://www2.parc.com/spl/members/dekleer/Publications/Dependency%20directed%20backtracking.pdf a une explication un peu plus poussée du DDB et des limites du backtracking chronologique.
[^] # Re: quelqu'un ?
Posté par jerome (site web personnel) . Évalué à 3.
J'aurais juste soumis le mot récursif, de récursion ou récursivité pour backtracking, ça peut éclaircir un poil plus.
Pour les 8 reines, je ne sais pas pourquoi mais j'y pensais récemment, et en ai ré-entendu parler tout autour de moi au début décembre ... Certainement des réminiscences suite à la réception des invits pour prologin (faudrait qu'ils arrêtent, j'ai plus l'âge pour ces bêtises :)
Pour illustrer, y a en gros trois grandes méthodes pour déterminer au moins une solution au problème :
. essayer toutes les combinaisons de manière déterminée, si par chance, on tombe sur une solution, c'est gagné => KISS mais lent, lent, lent, on devrait trouver toutes les solutions.
. partir de l'idée qu'il est possible de poser une reine sur une nouvelle ligne seulement si cela était possible pour la ligne précédente (aspect récursif de la chose) => plus rapide que précédemment, trouve toutes les solutions ...
. poser les 8 reines sur l'échiquier et les déplacer selon les minimas de contraintes => permet de trouver vite UNE solution, pour toutes les trouver, c'est une autre affaire ...
[^] # cool !
Posté par skasowac . Évalué à 1.
le pire c'est que l'exemple des reines, j'en parlais avec un pote y'a pas 3 jours, sans savoir qu'on pouvait s'aider de cette technique (il ne m'a en effet pas parlé d'autre chose que de la méthode par arbres).
et oui, il semble naturel que cette méthode soit liée à l'AI.
# Faut-il bannir RMS de Linuxfr?
Posté par Gohar . Évalué à 4.
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par Gohar . Évalué à 0.
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par Gohar . Évalué à 10.
Il s'agit rien moins d'assurer la domination de l'homme sur la technique et non l'inverse. Ou plutôt, d'éviter que la technique ne permette la domination d'un groupe d'individus par un autre.
Ce projet ne peut être concrètement mené à bien que par une réalisation concrète, technique. C'est là où (d'après RMS, si je le comprends bien) certains s'égarent, fascinés par l'aspect technique. Et c'est aussi à mon sens l'un des travers des sites dédiés à Linux. Je pense à ce titre que si RMS intervenait sous un pseudo sur linuxfr, il se ferait assassiner. Libre à vous de penser autrement!
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par HeKa . Évalué à 5.
Tu soulève un bon point en disant que beaucoup se portent plus sur l'esprit technique de la chose que sur le politique, ethique ou philosophique. Cependant si toutes les personnes utilisant du GNU devaient suivrent une formation sur comment penser "libre" il ne s'agirait plus d'un monde libre mais de quelque chose qui s'approcherais plus d'une secte. C'est un peu fort comme comparaison, mais ça exprime assez bien l'idée.
Pour moi GNU n'est pas politique ou technologique, c'est une alternative, une voie différante que j'ai choisi d'utiliser pour différantes raisons c'est là qu'interviennent la politique et la technique. Il ne faut rejetter ni l'un ni l'autre, même si beaucoup ici sont très technique, ils n'oublient pas pour autant le fait que c'est bien différent d'une politique propriétaire. La force du monde de l'open source reste son nombre d'utilisateurs (pour la plus part actifs), et leurs diversités.
De plus, il est normal que les sites dédiés a Linux soit plus technique car au final Linux n'est qu'un programme parmis et les autres ce n'est pas l'essentiel du libre qu'est GNU. (c'est ce que RMS essais de faire comprendre aussi je pense).
P.S: Je dis en général Linux ou même nux et non GNU/Linux pas par ce que j'ignore l'importance de GNU dedans mais par simple faignantise de language. Ce n'est pas pour autant que j'oublis ce qu'est GNU et son importance dans nux ;-)
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par Gohar . Évalué à 6.
Mais pour moi, RMS est seulement quelqu'un qui va au bout de ses idées. Et comment peut-on être à moitié libre? Quand on parle de tels sujets, on ne peut qu'être radical.
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par HeKa . Évalué à 2.
RMS n'est donc pas banni de linuxfr mais seulement le côté RMS du site est moins apparent qu'il ne l'est vraiment.
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par iug . Évalué à 1.
Je vois pas d'où tu sors ça...
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par iug . Évalué à 2.
Je pense qu'un site technique est beaucoup plus fréquenté qu'un site de politique (non j'ai pas de sources :). En conséquences si on veut faire la pub de la philosophie il faudrait pouvoir la faire sur ces sites techniques.
C'est un des aspects de linuxfr qui me derrange : ce site est hanté par des fanas de techniques qui s'en tapent de l'aspect philosphique. Ils utilisent Linux ou *bsd parce que ça les fait plus tripper techniquement et ils t'attendent au tournant pour te moinsser si tu commences à trop partir politique.
Ex: comparer la fréquentation de eff.org ou gnu.org à Linuxfr.org ou slashdot.org.
[^] # Re: Faut-il bannir RMS de Linuxfr?
Posté par Yusei (Mastodon) . Évalué à 2.
# Debian et L4
Posté par galactikboulay . Évalué à 5.
Attention chairie, ça va troller....
Mis à part ça, je suis assez étonné qu'il soit déçu du passage de GNU/Mach vers L4 au niveau du Hurd. L4 est conçu pour être extrêmement petit et rapide, et ça serait a priori un grand pas en avant. GNU/mach n'a vraiment pas la réputation d'être très véloce.
[^] # Re: Debian et L4
Posté par Gohar . Évalué à 3.
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 8.
En tous cas, il est clair que le port sur un micro-noyau d'une nouvelle génération, un micro-noyau moderne, sur lequel beaucoup de gens bossent (dans le milieu professionnel et dans le milieu recherche) est capable d'apporter un certain dynamisme au projet. On voit d'ores et déjà beaucoup de gens intéressés spécifiquement par L4/Hurd et s'y consacrer alors qu'ils n'avaient jamais pris le temps de s'investir dans le projet avant. On voit aussi les développeurs gravitant autour de L4 (qui sont nombreux, croyez moi) s'intéresser vivement à ce projet grand public, multi-usages (pas qu'embarqué ou que hard RT, ...) utilisant leur petit bébé. Et puis, porter le Hurd sur L4, ça veut dire re-concevoir toute une partie du Hurd, des parties fondamentales (comme la VM, le scheduler, ...), ce qui ne manque pas d'intéresser beaucoup de monde. Alors certes, le port sur L4 rajoute beaucoup à la liste des tâches à effectuer. C'est beaucoup de travail en plus. Mais c'est aussi beaucoup de gens en plus pour le faire. Je crois personnellement que la dynamique d'un projet est beaucoup plus importante que la simple TODO list.
Ensuite, opposer liberté et confort d'utilisation, c'est déjà l'expression de toute une stratégie. Ça n'est certainement pas la mienne. Et en fait, je ne pense pas que ce soit celle de Richard Stallman.
Je crois que sa vision du port de L4 est beaucoup plus liée à des questions de contrôle (à des questions politiques, oui, mais au sens le plus bas du mot). RMS suit de façon peu attentive le Hurd : il attend des développeurs qu'on lui donne des choses à mettre en avant de temps en temps, pour faire de la promotion « grand public » (grossière, quoi ;-) : ses exemples sur les FS le montrent bien. Le projet de port sur L4 est bien plus difficile à mettre en avant. De même, les développeurs GNU/Hurd échappent beaucoup au « contrôle » que RMS souhaite garder sur les projets GNU centraux, comme le Hurd. Le projet sur L4 s'est fait beaucoup sans son avis et son aval. RMS ne l'a pas forcément digéré.
My 2¢.
[^] # Re: Debian et L4
Posté par Gohar . Évalué à 1.
Pour ce qui est du confort d'utilisation vs perfection technique, soit je n'ai rien compris à l'interview, soit RMS ne parle que de ça!
Je cite:
freedom is the main goal, and innovation is secondary.
It is better to develop no software than to develop non-free software.
our concern is for the user's freedom, not how the program is developed.
etc.
[^] # Re: Debian et L4
Posté par gnumdk (site web personnel) . Évalué à 4.
Il est bien gentils le richard, mais la liberté d'avoir de la merde, ca n'apporte pas grand chose. Si les devels du Hurd on jugé GNU Mach comme ne répondant pas à leurs besoins, c'est qu'il y avait de bonnes raisons.
C'est bien de parler de la liberté des utilisateurs, mais il y'a aussi celle des developpeurs. Coder pour coder, je sais pas ce que ca peux bien apporter, si des truc comme mplayer, cad des programmes qui peuvent etre tres bons mais donc le code source est un vrai cauchemar ambulant.
Par exemple, prenons E17, les devels ont mis du temps, se sont remis en question(arret du devel du wm pendant une longue periode pour se reconcentrer sur les libs puis réécriture complete de ce dernier), et resultat, on commence a voir arriver un truc tres interessant. Sur du matos de merde avec une carte graphique(intel) qui rame comme la mort avec xcomposite de X.Org, ben E17 avec tous ces effets "à la con" s'en sort super bien avec une fluidité plus qu'impressionante et le tout avec un XFree86 4.3...
Donc bon, je pense que le Hurd n'est pas un projet qui a pour but actuellement d'avoir des utilisateurs, que ca reste quelques chose en developpement actif et qu'il ne faut pas oublier que ce dernier s'est arreté pendant une longue periode.
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 5.
Mais RMS insiste bien sur l'apport complémentaire, comme le montre bien la dernière phrase que tu cites. Il dit donc, en résumé, qu'il faut valoriser le côté liberté plus que le côté "efficacité", sans pour autant nier que le deuxième sert le premier, ou affirmer que l'un peut s'affirmer sans l'autre. Voilà, c'est un peu plus long que ce que j'aurais souhaité. :)
[^] # Re: Debian et L4
Posté par Gohar . Évalué à 3.
Concrètement, j'utilise une distro PPC sur un Mac qui supporte Mac OS X. Et je ne fait pas ça par masochisme. Je perçoit Mac OS X comme une prison dorée.
[^] # Re: Debian et L4
Posté par GaGadget . Évalué à 1.
La version du micro-noyau L4 utilise est L4Ka::Pistachio qui est distibue sous license BSD ... il y n'a pas de probleme juridique mais un probleme de coherence avec la licence du systeme GNU, la GPL, et les propos de RMS. La licence BSD etant trop permissive a son avis.
Je trouve cela dommage sans pour autant etre choque.
Peut-etre qu'il y aura un GNU L4 comme il y a un GNU Mach ?
En tout cas, je trouve ce port super intertessant ... j'ai hate de voir des resultats !
RMS est peu etre un extremiste mais moi, je suis fan !
[^] # Re: Debian et L4
Posté par Arachne . Évalué à 3.
[^] # Re: Debian et L4
Posté par benja . Évalué à 1.
Ce que tu dis n'as pas beaucoup de sens, car quelqu'un aime la licence bsd pour les libertés qu'elle donne, c.-à-d. avoir aussi le choix de changer de license...
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 5.
Il n'y a pas de plan immédiat pour avoir un GNU L4, pour la simple et bonne raison que L4Ka::Pistachio nous convient parfaitement dans l'état. L'équipe de développement est très sympa, très ouverte. La licence est libre, compatible avec la GPL. Le développement est actif, L4Ka::Pistachio est utilisé, a réussi à fédérer des utilisateurs.
Si un jour les développeurs du Hurd souhaitent faire des choix concernant le développement de L4 que L4Ka ne souhaite pas faire, ou que chaque équipe décide que ça a sa place plutôt dans un GNU L4 que dans l'implémentation L4Ka::Pistachio, alors peut-être y aura t'il un "fork", et comme Guillaume le faisait remarquer, ça ne pose aucun problème que le projet soit alors sous GPL.
Je rajoute que c'est un peu ce qui s'est passé avec Mach. CMU Mach n'étant plus développé, GNU Mach a été créé. La plupart des sources sont encore sous une licence de type BSD, le projet GNU Mach étant lui-même sous GPL.
Et je rajoute enfin que pas mal de projets GNU ont du code sous BSD, voire sont entièrement sous licences BSD. Ca n'est pas une licence que le projet GNU encourage dans le cas général, mais il l'accepte tout à fait, voire l'encourage dans des cas bien particuliers (comme le code dans le domaine public, d'ailleurs).
[^] # Re: Debian et L4
Posté par patrick_g (site web personnel) . Évalué à 2.
1) Linux devient de plus en plus modulaire (on peux même choisir son scheduler...y'a 3 ou 4 possibilités).
2) Les inquiétudes sur sa maintenance à long terme d'un kernel soit-disant monolithique ne semblent pas se concrétiser.
3) le hurd est certes formé de modules interchangeables mais est-ce que ça ne correspond pas une réponse tardive au vieux paradigme d'un ordinateur central avec pleins de postes clients ? Pour que ces postes clients aient une certaine liberté il faut ce modèle de briques interchangeables....mais maintenant chacun est admin de son ordi et donc il n'y a plus de nécessité de tout modulariser.
Je sais (pour t'avoir lu sur dlfp) que tu bosse sur le hurd : tu crois vraiment en cette architecture pour le futur ou c'est juste un challenge technique ?
[^] # Re: Debian et L4
Posté par GaGadget . Évalué à 9.
Avec Linux, tu as le choix du scheduler pour ton systeme, mais avec le Hurd, tu auras le choix pour chaque utilisateur indepedamment les uns des autres, tu aura meme la possibilite d'en developper un pour toi, et l'utilisers pour tes taches sans gener les autres ...
2) => Les premieres version de Linux 2.4 ont montre les limites de la maintenabilite lors de changements en profondeur (cf les problemes de VM corriges seulement apres la version 2.4.9 ). C'est vrai maintenant la maintenance est mieux organisee et reagit beaucoup plus vite et par petites touches.
3 ) => C'est Linux qui a un design "depasse" qui date de l'epoque des "grosses machines", le Hurd sera beaucoup plus adapte a une informatique distribuee autant sur le plan administration que utilisation.
Pour moi, le Hurd est tres satisfaisant intellectuellement et est taille pour le futur. Apres, qui vivra, verra ...
[^] # Re: Debian et L4
Posté par patrick_g (site web personnel) . Évalué à 3.
avec le Hurd, tu auras le choix pour chaque utilisateur indepedamment les uns des autres.
le Hurd sera beaucoup plus adapte a une informatique distribuee autant sur le plan administration que utilisation.
Ce sont des gains pour un serveur avec plusieurs users loggés dessus...alors que l'utilisation classique d'un ordi personnel aujourd'hui c'est : un ordi par personne et chacun est son propre admin.
Pour moi en tant qu'utilisateur je ne vois donc aucun avantage (à part c'est vrai la quantité de code en mode noyau).
Je ne dis pas ça péjorativement ou pour dénigrer le travail des devs du hurd, au contraire je pense qu'ils ont raison de poursuivre le travail sur un truc qui les interessent et que cela favorise la diversité....n'empêche que j'y crois absolument pas.
ça va être comme Plan9 : un os novateur mais qui restera un bidule ésotérique utilisé pour la recherche informatique.
PS : pour le pb du NFS qui fait tomber le système => UML ou le futur Xen est une bonne solution.
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 10.
Le premier point sur lequel je voudrais insister est que c'est une vision extrêmement étriquée de l'informatique que de penser qu'aujourd'hui, chacun est son propre administrateur. Il reste beaucoup d'endroits où ce genre de solutions n'est pas souhaitable ou réalisable : dans les labos en général, où beaucoup d'utilisateurs ont besoin de ressources partagées (gros serveur de calcul, serveur d'applications), sans qu'il soit envisageable que le moindre thésard ait des droits privilégiés sur la machine. Réussir à lui donner suffisamment de droits pour qu'il puisse faire son travail de façon correcte sans pour autant lui donner de quoi compromettre la machine est un éternel travail d'équilibriste, et n'aboutit que très rarement à des solutions satisfaisantes. On remarque d'ailleurs que les solutions à base de sudo(8) (sur une seule commande, par groupe, ...) deviennent de plus en plus monnaie courante, et je pense que même si c'est bien pratique, tout le monde s'accordera à dire que c'est loin d'être satisfaisant. Le problème se pose encore plus dans le contexte éducatif, puisqu'on peut rarement considérer qu'on fait confiance aux étudiants (et on nous taperait sur les doigts encore plus si on le faisait que pour les thésards). Et ça n'est pas qu'une subsistance : avec le développement des connexions "haut débit", il est de plus en plus possible de donner accès à des ressources électroniques à distance, et l'arbitrage entre utilisabilité et sécurité devient plus important que jamais (si quelqu'un travaille en télétravail 3 jours par semaine, il faut que ce soit _très_ utilisable ; mais il faut en même temps faire _très_ attention point de vue sécurité).
Par ailleurs, je crois que toute l'innovation apportée pour permettre à des utilisateurs non privilégiés de faire toujours plus sans compromettre le système est encore très profitable même dans le cas de l'informatique personnelle. D'une part, si les utilisateurs peuvent faire plus c'est parce que de moins en moins de code nécessitent des privilèges noyau : d'autant moins de risque de faire planter totalement la machine, d'autant moins de risque de l'endommager, et d'autant moins de risque de permettre à un attaquant (et le problème des attaques à distance est plus que jamais le problème de l'informatique personnelle) de gagner des privilèges lui permettant des dégâts irréparables. D'autre part, ces possibilités résolvent bien des problèmes couramment rencontrés même sur des machines où le seul utilisateur est son administrateur. Je pense par exemple aux problèmes de droit que l'on rencontre quand on monte un FS : les droits qui se retrouvent à user:user et donc la moitié des choses qui marchent plus, les comportements tout bizarres pour les suid... Et je ne parle pas du fait qu'il faille rajouter une entrée dans le fstab à chaque fois qu'on veut pouvoir monter un truc en utilisateur normal (et l'utilisateur normal a plus envie de double-cliquer pour monter que faire un "sudo mount", si, si). Sous GNU/Hurd, absolument aucun problème : vous montez vos propres FS sans vous soucier du problème de droit et des problèmes de sécurité (tout utilisateur ayant des notions d'Unix verra sa barbe se hérisser en laissant un utilisateur monter un FS quelconque sans avoir pourtant de droits privilégiés, quand bien même ça ne serait que lui ;-). Tu apprécieras aussi choisir le comportement en cas de crash par utilisateur, grâce à la flexibilité des translators, et pas se retrouver que le ~ de ta petite soeur se retrouve faire 80G du fait des .core du dernier jeu que tu lui as installé qui plantait de partout. (OK, ulimit -c ça existe, mais la soeur risque d'être surprise si tu as eu l'idée de mettre un "suspend" par défaut en cas de crash, croyez moi ;-)
Et puis, c'est être extrêmement simpliste que de limiter les avantages du Hurd à ça. Les avantages du Hurd se posent par exemple en terme de flexibilité : amusez vous à faire un système de fichiers "virtuel" un peu original, comme un FS modélisant un annuaire LDAP (un ldapfs, quoi). Le peu de flexibilité qu'offre le VFS centralisé d'un Unix, la complexité du développement de telles choses en mode noyau vous apparaîtra évidente. Et pourtant, de plus en plus on essaye d'intégrer ce genre de webservices à l'OS. Par exemple, iDisk pour MacOS X ou les WebFolders pour Windows, qui utilisent tous deux WebDAV, permettent de fournir assez facilement à des utilisateurs leurs ~ à distance, sans les problèmes de FTP (passif/actif, galères de firewall, FTPS impossible si firewalls stateful, ...) et les galères de NFS/etc. Ceci n'existe pas sous GNU/Linux, où il faut se contenter de passer par Gnome-VFS ou KIO (ou par un module totalement instable et qui fait peur à voir). Ces besoins se font sentir dans le milieu professionnel depuis déjà plusieurs années, et pourtant toujours pas de solutions pour ce genre de services, ou alors complètement insatisfaisantes (aucune sécurité, aucune stabilité). Je crois qu'on touche là aux limites de la flexibilité d'Unix.
Le Hurd, c'est aussi un système de gestion des droits totalement différent. À l'heure de Kerberos et des ST un peu partout, il est hallucinant qu'un système comme GNU/Linux soit aussi limité en terme de gestion des droits. Tous les jours, dans mes développements internes, je vois de plus en plus le besoin d'un système où je pourrais, sur mon système, fournir un certificat, un couple (login, pass), ou un quelconque autre moyen d'authentification et obtenir un jeton me donnant des droits bien particuliers. Et cela au coeur du système, pas que pour les WebServices, pas en surcouche. Ma remarque sur le développement d'utilisation de sudo(8) de plus en plus massive est un signe de la nécessité d'une gestion des droits plus fine, je pense.
Le Hurd, c'est aussi la possibilité d'avoir des personnalités multiples. Il est tout à fait envisageable, dès maintenant, de programmer des serveurs "alternatifs" remplaçant des gros bouts du GNU/Hurd tel qu'on le connaît. Tant que ces serveurs respectent les interfaces clairement définies, chaque utilisateur pourra alors facilement lancer son propre "sous-système" avec les serveurs qui lui plaisent. Et ça ne sert pas que sur des grosses stations multi-utilisateur : il est tout à fait possible que je souhaite lancer un environnement particulier que pour une seule application, et pour tout le reste je veuille rester dans l'environnement POSIX standard.
Tu parlais de UML ou de Xen. Tout d'abord laisse moi te dire ma perplexité face à ce conseil. Il est -inimaginable- d'utiliser une telle solution en production. UML peut tout au mieux servir à réaliser des tests préliminaires dans un environnement non critique. 'préliminaires', parce qu'un environnement UML a de moins en moins à voir avec un environnement 'réel' à base de Linux : Linux n'est pas fait pour tourner en mode utilisateur, et de ce fait les modifications nécessaires sont énormes, et changent considérablement le comportement de l'application. Et 'non critique', parce que du fait de la complexité d'un tel travail, UML est extrêmement peu stable, et fait même très souvent planter le noyau principal lui-même (un comble !). Si pratique que cette bidouille puisse être, elle reste une bidouille et ne devrait pas avoir d'autre ambition que d'être réservée au développement Linux comme elle l'était à l'origine. Pour le Hurd, en revanche, c'est bien différent : tous les serveurs tournant en user space, faire tourner un deuxième "co-Hurd" ou "sous-Hurd" (les deux sont possibles, selon que l'un agit comme "proxy" de l'autre pour les ressources partagées ou qu'ils agissent en parallèle, avec des bouts communs) est quelque chose de naturel, et ça ne nécessite pas une version modifiée ou quoi que ce soit.
Je concluerai enfin sur ce qui est généralement ma première remarque quand on me demande les avantages du Hurd. Le Hurd est le coeur d'un système d'exploitation. Il ne fournit directement qu'extrêmement peu aux utilisateurs. Ce qu'il fournit, c'est des -possibilités- que les développeurs d'application utilisent ou non. GaGadget parlait de la possibilité d'avoir plusieurs VM, plusieurs schedulers en parallèle. Utilisé à bon escient, c'est là une possibilité d'optimisation fabuleuse : on sait pertinemment que tel comportement de VM est bien plus adapté à tel environnement que tel autre, et d'ailleurs tout le travail d'un développeur de VM sur des systèmes centralisés consiste à déterminer ce qu'on considère comme le "cas moyen", et ce qui est moins pire dans ce cas là. Sur un système décentralisé comme le Hurd sur L4, il est tout à fait possible d'avoir plusieurs VM en parallèle qui régissent différemment la mémoire qui leur est allouée. Et je ne parle pas des négociations de QoS que permettent une conception décentralisée, et fondée sur la communication entre processus, qui représentent des possibilités de 20 à 50% d'amélioration des performances sur des applications spécifiques, comme les serveurs de base de donneés, et encore plus sur le cas du multimedia. Si les développeurs utilisent ces possibilités (que ce soit la possibilité de remplacer des serveurs, la flexibilité du système d'authentification, les notifications, ou la négociation de QoS), alors toi, utilisateur, oui, tu verras les amélirations, et pas qu'un peu.
[^] # Re: Debian et L4
Posté par patrick_g (site web personnel) . Évalué à 3.
c'est vrai qu'il y a beaucoup d'avantages auxquels je n'avais absolument pas pensé.
je reste quand même dubitatif sur le succès final du hurd (il ne semble pas avoir réussi à percer auprès d'une grande communauté de devs....y'a pas le phénomène d'engouement qu'il y a eu autour de linux : il manque peut-être un benevolent dictator à la Linus ?)
en plus pour switcher vers Linux y'avait 2 grosses motivations : la liberté et la qualité technique.
maintenant pour switcher vers le hurd les entreprises ou les particuliers ne pourront plus compter que sur la qualité technique car ils ont déja conquis la liberté avec Linux.
Et puis ça risque de changer trop d'habitudes (voir le manque de succès des claviers dvorak).
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 8.
Quant au "switch", je pense au contraire qu'il pourrait se faire extrêmement rapidement, une fois le Hurd arrivé à maturité. Tout dépend bien sûr de quelles entreprises ou de quels particuliers on parle. Pour les particuliers, l'arrivée à GNU/Linux et aux logiciels libres se fait quasi-systématiquement par un tiers, qui fait la première installation, la première initiation. C'est cette frange de "prosélytes" qui répand GNU/Linux. C'est à celle-là que tiendra l'implantation de GNU/Hurd chez les particuliers. Et ils ne rencontreront probablement aucune opposition, parce que GNU/Hurd fournit une interface de compatibilité POSIX totale, et que le changement sera (ou plutôt, pourra être) totalement transparent. Le grand pas a été fait avec GNU/Linux. GNU/Hurd pourrait très bien profiter de ça. Dans le milieu professionnel, il faut distinguer les petites unités indépendantes, les petits CRI, les PME/PMI/TPE, où la décision revient couramment à quelques personnes, ça se passera probablement pareil. Évidemment, il y a ensuite les réticences des grandes organisations. Mais il y en a toujours. Et je crois qu'on aura peu de mal à convaincre.
La force du Hurd, c'est de respecter à la lettre le GNU Manifesto : totalement compatible avec Unix (l'existant), mais repoussant les limites, permettant toujours plus, "à côté". Nul besoin de changer ses habitudes : vous le pouvez, et vous n'en tirerez que plus d'avantages. En attendant, même avec des logiciels purs POSIX et une utilisation purement Unixienne classique, GNU/Hurd s'efforcera d'être au moins aussi performant, stable et puissant que l'existant.
[^] # Re: Debian et L4
Posté par GaGadget . Évalué à 3.
Exemple simple avec le scheduler : Sous linux, faire tourner un programme avec une priorité presque temps réel est impossible, le fameux problème du xmms qui saccade ton morceau preferé lorsque tu scrolles une peu vite dans tes fenetres X11 ... et bien avec Hurd, il suffira d'avoir un scheduler special multimedia juste dispo pour certaines applications et/ou utilisateurs (physiques ou virtuels) pour éviter ce problème.
J'ai aussi oublié de parler de la sécurité qui découlera naturellement du design du Hurd ( secure by design ), la gestion des privilèges pourra etre beacoup plus fine et équilibrée ( plus de user root qui peut tout faire et des users de base avec peu de privilèges ). Ceci s'appliquera aussi bien aux gros serveurs ( qui sont plus présents que jamais dans l'informatique, cf toutes las applis internet ) qu'aus machines individuels.
Je connais UML comme language de description fonctionnel et Xen, jamais entendu parler, c'est quoi ?
[^] # Re: Debian et L4
Posté par GaGadget . Évalué à 2.
Xen : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...)
UML ( User Mode Linux et non Unified Modeling Language comme je pensais ) : http://user-mode-linux.sourceforge.net/index.html(...)
[^] # Re: Debian et L4
Posté par patrick_g (site web personnel) . Évalué à 2.
Bon la solution finalement c'est que les devs de NFS sortent des releases bien stables ;-)
[^] # Re: Debian et L4
Posté par VoixOff . Évalué à 2.
Je ne vois pas bien comment chacun pourrait avoir son propre ordonnanceur sans compromettre la répartition des ressources. (De la même façon qu'une tâche RT ne peut être interrompue par une non-RT.)
Il doit bien falloir un méta-ordonnanceur qui protège le système contre les "abus" (entre guillemets car ce n'est pas forcément intentionel).
Ne se retrouve-t-on pas dans le contexte du multi-tâche en mode utilisateur et ses restrictions ?
ps: merci Manuel pour la clarté de tes commentaires précédents.
[^] # Re: Debian et L4
Posté par GaGadget . Évalué à 3.
_ par des changements de contextes trop fréquents ( noyo - user - noyo -user ... )
_ par de trop nombreuses recopies des messages entres les serveurs ( cf accès à un contenu de repertoire, ou la communication sur le réseau )
Ce qui entraine des performances moindre par rapport à des systèmes à base de noyaux monolithiques, et cela sera très difficile d'y remédier du fait meme du design. La liberté est à ce prix !
Mais soyons confiant, une bonne parti des problèmes sera résolu avec le micro noyau de l4ka et la puissances des machines. Ces problèmes de performances seront donc de moins en moins visibles à mesure que le Hurd sera mature et que les devs pourront se concentrer sur les perfs.
Vive GNU, vive Linux, vive BSD et vive la liberté ( à défaut d'égalité et de fraternité :-)
[^] # Re: Debian et L4
Posté par munshausen . Évalué à 1.
Même si son créateur le qualifie lui-même de monolithique.
Mais si je dis une bêtise, n'hésitez pas...
[^] # Re: Debian et L4
Posté par pasBill pasGates . Évalué à 2.
Le fait de pouvoir loader/unloader des modules n'en fait pas un micro-noyau, ces modules tournent en mode kernel, pas en mode user.
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 3.
Les LKM ne sont rien de plus qu'une facilité de plus pour l'utilisateur. Qui plus est, comme tu y vas fort quand tu parles de noyau "minimaliste" : les parties essentielles du noyau (gestion de la mémoire, ordonnancement, VFS, fondement de la gestion des périphériques) se trouvent encore présentes. Il n'y a, grosso modo, que la partie "pilotes de périphériques" (qui est, contrairement à ce qu'on se représente souvent, une partie assez peu conséquente d'un noyau "classique") et les systèmes de fichiers qui soit "modularisée". Et les initiés se rendront compte que ce sont là deux des parties les plus simples à comprendre du noyau, de par leur modularité justement.
Mais ça ne change rien aux problèmes de fond : celui de la sécurité, celui des effets de bord, celui de la substituabilité des composants, celui, tout à fait lié, de la stabilité des interfaces (l'instabilité des interfaces est au contraire un dogme pour Linus, de la même façon que la non-séparation des parties répond à son dogme du "No design, code"), et j'en passe.
Pour en revenir à la question "Peut-on qualifier Linux de monolithique ?", il faut définir "noyau" au sens où on l'entend classiquement en développement d'OS. Il s'agit de l'ensemble du code qui tourne avec des privilèges particuliers sur le matériel. Il est assez difficile ensuite de définir micronoyau et noyau monolithique de façon "statique", à instant 't' : c'est le mouvement "vers le noyau" ou "vers l'espace utilisateur" qu'on considère souvent comme définissant s'il s'agit d'un noyau monolithique ou non. Dans Linux, tout (VM, ordonnancement, pilotes de périphérique, systèmes de fichiers, gestion des droits, ...) se trouve en "mode noyau". Et de plus en plus de choses se retrouvent dans le noyau, et très peu de choses sont bougées en user space. C'est définitivement un noyau monolithique. Quel que soit la façon dont on construit le monolythe. :-)
[^] # Re: Debian et L4
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Debian et L4
Posté par Manuel Menal . Évalué à 1.
[^] # Re: Debian et L4
Posté par Sylvain Sauvage . Évalué à 3.
Les monolythes ne sont pas contruits, ils apparaissent. Et quand on y touche, il se passe plein de choses merveilleuses et on atteint un autre stade.
Enfin, c'est comme ça que Zarathoustra en parle...
[^] # Re: Debian et L4
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
# Et ça fait mal?
Posté par jimee (site web personnel) . Évalué à 9.
C'est honteux de profiter ainsi de la santé fragile d'un pauvre téléphone!
[^] # Re: Et ça fait mal?
Posté par TazForEver . Évalué à 4.
[^] # Re: Et ça fait mal?
Posté par Arnaud (site web personnel) . Évalué à 8.
<Kerneltrap> alors, finie la branlette ?
<RMS> m'en fout, chui gaucher ;-)
;-))
# Livre
Posté par Gohar . Évalué à 1.
[^] # Re: Livre
Posté par Jiel (site web personnel) . Évalué à 2.
# Chercher un autre job
Posté par Alban Crequy (site web personnel) . Évalué à 1.
Dois-je chercher un autre job? C'est dommage, j'avais trouvé un truc super intéressant sous GNU Slash Linux, même si c'est non libre.
[^] # Re: Chercher un autre job
Posté par rhizome . Évalué à 4.
La distinction que fait RMS sur ce point n'est pas bête. C'est vrai que beaucoup de boites font du développement mêtier et vendent le soft avec ses sources à leurs clients. Effectivement dans ce cas, le client n'est pas complêtement "coincé". En théorie du moins.
[^] # Re: Chercher un autre job
Posté par gc (site web personnel) . Évalué à 4.
Et il faut aussi parler des données. C'est le format des données qui est un piège lorsque seul le prestataire en connait le secret. Quand une entreprise confie toute la chaine de traitement informatique à un prestataire et qu'elle n'exige pas un minimum de règles et de transparence sur les données manipulées, elle est coincée (et c'est en partie sa faute). Ca me semblerait aussi "mal" pour RMS de travailler sur du "custom software" si dans la customisation il y a cette prise en otage du client à travers un format de données complètement opaque.
[^] # Re: Chercher un autre job
Posté par n m . Évalué à 9.
- Bah je suis caissier à monop'
- Ah ... et sinon ?
- Ben je maintien la branche 2.4 du noyau
Hop --> [ ]
# encore le bras!
Posté par sly20oo . Évalué à 1.
(http://www.nickhill.co.uk/rms-speech-status.html(...))
A-t'il encore glissé sur une plaque de verglas?... C'est quand même assez louche ces chutes à répétitions...
[^] # Re: encore le bras!
Posté par Arachne . Évalué à 1.
[^] # Re: encore le bras!
Posté par Ramón Perez (site web personnel) . Évalué à 3.
Comme ça : http://www.csdm.qc.ca/stejarc/dictionnaire/imagesdicolm/louche.jpg(...) ?
Non, je pense que quelqu'un lui veut du mal.
[^] # Re: encore le bras!
Posté par Arachne . Évalué à 3.
[^] # Re: encore le bras!
Posté par Yohann (site web personnel) . Évalué à 10.
Emacs est juste developpe par des bras casses :^)
[^] # Re: encore le bras!
Posté par rhizome . Évalué à -1.
Libre ? Moi qui croyait qu'il était sous licence GPL...
[^] # Re: encore le bras!
Posté par Pooly (site web personnel) . Évalué à 2.
--> []
[^] # Re: encore le bras!
Posté par pasPierre pasTramo . Évalué à 9.
C'est pas louche, quand tu est un advanced user d'emacs, tu soumet ton corps a rude épreuve.
Il suffit d'avoir envie d'ouvrir un fichier dans une autre fenetre pour y laisser un doigt voir un bras si t'est rms.
[^] # Re: encore le bras!
Posté par EdB . Évalué à 5.
;o)
=====>[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.