Au contraire, je trouve que c'est une très bonne idée qui permet de faire passer le message qu'une installation de linux ne doit pas être invasive. Le mbr reste intacte, on ne touche pas aux partitions. « Je peux le désinstaller quand je veux ». Encore une démonstration de l'extrème adaptabilité des logiciels libres.
Ensuite, on ne rend pas "linux dépendant d'un autre système". Il fonctionne de manière autonome (au lieu d'avoir grub dans le mbr, c'est le mbr de windows qui appelle une version modifié de grub qui lance le noyau d'une manière tout ce qu'il y a de plus traditionnelle). Certes, à défaut de partition, il a besoin d'une image disque; quoi de plus normal ?
Si des utilisateurs ne sont pas capable d'installer Linux, je doute qu'ils deviennent utilisateur réguliers.
Ma mère n'a jamais installé de gnu/linux (ni quoi que ce soit d'autre d'ailleurs) mais pourtant elle est bien une utilisatrice régulière de son ordinateur...
Blague à part, je ne vois pas du tout où est le problème avec cet installateur. Je suppose que c'est très bien pour les gens qui n'ont pas spécialement envie de toucher à leur disque dur juste pour essayer une distribution linux. D'abord on économise un cd (puisque de toutes façons les personnes visées ne sont pas celles qui auraient fait une installation par le réseau). Ensuite, s'ils sont conquis, rien ne leur empêche de faire une installation normale.
C'est le nom d'un article d'ars qui vous enlèvera tout doute si vous pouviez encore avoir un peu de confiance dans les machines électroniques de vote.
L'url de l'article: http://arstechnica.com/articles/culture/evoting.ars
Erik Meijer [1] aussi est un grand nom de la recherche de la programmation fonctionnelle. Cela explique pourquoi C#3, Visual Basic, tendent à reprendre les features les plus avancée des languges fonctionnelles (générics, LINQ, compréhension,...). cf [2]
Je précise que je suis un profane en designe de micro kernel et de programmation système donc il faut prendre tout ce que je dis avec de très grosses pincettes.
Premièrement, selon http://en.wikipedia.org/wiki/Call_gate , Very few modern operating systems use call gates. With the introduction of SYSENTER/SYSEXIT and SYSCALL/SYSRET, a new faster mechanism was introduced for control transfers for x86 programs. Apparemment on pourrait y passer outre...
Ensuite, selon [1] (qui a 10 ans déja) The macrobenchmarks answer our first question. The current implementation of L4Linux comes reasonably close to the behavior of native Linux, even under high load. Typical penalties range from 5% to 10%. Actuellement, sur [5] (L4Linux2.6): However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. Aussi selon [2], les context switch de wombat sont bien plus rapides que linux/ARM (d'autant que les messages sont petits). Évidemment ce n'est qu'un linux au dessus de l4 donc les programmes linux ont un double overhead, puisqu'ils passent d'abord par linux puis, les driver linux par l4 pour accéder aux ressources. Peut-on penser qu'un système complèt sur l4 serait plus rapide ?
Sinon, [3] & [4] contiennent des pistes vers des papiers intéressants. Enfin bon, ce que j'en retiens c'est que L4 a été designé pour avoir des ipc très rapides (optimisation des caches, petits messages incrustés dans les registres, exploitation sioux de la tlb, mmapping efficace,...) qui sont bien plus léger que faire un system call sous linux.
Enfin, l'avantage premier d'un micro-noyau ce n'est pas tellements ses performaces mais bien la sécurité qu'il apporte. Cela permet de relativiser beaucoup les différents benchmark. Note qu'apparemment il y aurait 2 grandes tendances pour imposer la sécurité: l'ipc indirection (l4) et les capabilities (eros, coyotos). Bon après je n'en sais pas plus.
BeOS n'est pas un micro-noyau. Il y a une séparation de services en serveur, certes, mais les drivers tournent dans le même espace noyau. C'est un Hybride, au même titre que XNU (OSX), NT, Plan 9, DragonFly BSD, AmigaOS cf. http://en.wikipedia.org/wiki/Hybrid_Kernel pour une liste plus exhaustive et les explications.
Concernant l'assertion micro-noyau -> lent, c'est un mythe en effet comme l'ont démontré les chercheurs de L4 (http://www.l4ka.org/ ). Question d'implémentation.
[c'est pas très polis de répondre à soi-même mais j'ai envie de continuer ce délire]
De tout façon, l'histoire n'est pas finie et peut-être qu'un jours Linus se rendra compte qu'il n'est plus possible de maintenir cette bête (combien de millions de lignes aujourd'hui déja ?) d'une manière humainement et psychiquement saine et décidera pour linux 4.0 de repartir sur les base de minix 3 ;-P
Où alors, autre scénario, Linus abandonne son développement pour partir en thérapie. Andrew Morton. lui. a déja quitté le bateau depuis longtemps pour s'offrir une vie. Les développeurs des principales distributions principales distributions n'arrivent pas à se mettre d'accord sur la direction du noyau (faut dire qu'elles se partagent une solide part de marché maintenant). Ça forke chacun dans son coins, de toute façon leurs noyau sont aussi buggés les unes que les autres. Puis ce qui devait arriver arriva, debian, après une flameware de quelques mois, décide de laisser tomber le support de linux et promeut le hurd comme noyau de référence. De toute façon, cela faisait longtemps qu'il était fonctionnel, le problème étant justement de patcher linux pour arriver aux mêmes fonctionnalités.
Tout cela c'est sans compter Haskell OS, qui après avoir implémenté une couche de comptabilité posix en moins de 2 mois, a raflé toutes les places des mainframe et qui s'immisse de plus en plus dans le desktop computing...
si c'est bien organisé, je ne vois pas ou est le problème.
Justement c'est cette organisation qui fait défaut. Je ne parle pas ici de découpage en fichier (ou classe, ou module, ou sous-système, ou ce que tu veux) mais bien de compartimentisation du code (binaire, exécutable) en micro serveur. Il faut savoir que dans un micro noyau, les différentes tâche du noyau (pagination, allocation de mémoire, driver, pile réseau, authentification, système de fichier,...) sont réparties dans de "processus différents" (les micros-serveur) qui communiquent entre eux par messages (communication gérer par le micro-noyau proprement dit). Si tu veux, c'est le même genre de séparation kernel/userland d'un noyau monolithique mais entre chaque serveur, en ce sens qu'il y une protection de la mémoire au niveau de chaque serveur. Si un serveur essaye de faire un accès illégal et/ou qu'il se crache et bien il n'emène pas le reste du système avec lui. Dans linux, ces x millions de lignes de code ont toute le même potentiel de destruction vu qu'elles sont dans le même espace d'addressage.
On a souvent dit que cette compartimentalisation entraînait une perte de performance (flagrant pour mach cf le commentaire à propos d'OSX plus haût et pourquoi OSX n'a plus rien à voir avec un micro noyau pour palier à ces problèmes justement) mais la recherche sur L4 (avec ses fast-ipc) montre que les performances n'ont plus à rougir du tout (cf L4Linux où la perte de performance est très faible http://l4linux.org/ alors que linux n'a pas du tout été prévu pour fonctionner de cette façon).
Pour en revenir à mes lignes de codes, bah c'est très simple: il suffit de considérer que le taux de bug est proportionnel au nombre de lignes de codes.
Il faut aussi se rendre compte que les périphériques deviennent de plus en plus complexes (et donc buggés mais c'est un autre débat) et corrolairement les drivers le sont aussi de plus en plus. La complexité augmente, les code-paths s'imbriquent plus profondément (au nom de la performance justement), le débuggage est bien plus ardus qu'à l'époque de linux 1.0. Pour essayer de t'en convaincre, je t'invite à lire la saga sur kerneltrap à propos de la corruption. Oui, ils y sont arrivés mais après quels efforts ? Après combien de supputation ? Aurait-ils découvert ce bug, qui apparemment date d'un bon bout de temps (ou alors c'est un autre qui court toujours, on ne sait pas) sans le patch des pages clustering ? Enfin bref, qu'est-ce que ce sera quand le noyau serat 4x plus grand, ou 10x, voir plus ? Parce qu'il ne fera qu'augmenter en taille, c'est indéniable (à moins de balancer la moitié des drivers à la poubelle).
Je suis loin d'être un spécialiste du domaine (avec un peu de chance, mmenal passera dans le coin nous éclairer de sa lanterne ;-) ) mais voila j'espère que tu comprendras mieux mon commentaire maintenant.
je ne suis pas sur que le micro kernel "by design" garantisse forcement moins de ligne de code...
Au contraire, à fonctionnalités égales (et à language égale), il en contiendra plus vu qu'il faut coder les interfaces des micro-serveurs.
coincé du derrière ou pas,
C'était pour couper court au troll sur le chinois menfin passons...
je ne vois pas en quoi le nombre de ligne a avoir là dedans,
[en répétant un argument déja ennoncé plus haut]
Tout comme l'utilisation de windows (et de son succès planétaire) résulte d'un choix...
Pour les coincés du derrière, évidemment que tout décision découle d'un choix. Mais ce choix, qu'il soit massivement effectué ou non n'a pas d'importance (et il est _là_ l'argument de Tanebaum à mon sens), a été fait pour des raisons qui ne sont pas toujours celle que l'on croit (c.-à-d. la recherche de ce qui se fait de mieux); elles sont dépendantes du contexte socio-culturel qui influencent nos critères de sélections. Encore heureux, car s'il fallait être un théoricien des systèmes d'exploitation pour pouvoir choisir son OS, l'informatique ne se serait pas si développée :o)
De tout façon, l'histoire n'est pas finie et peut-être qu'un jours Linus se rendra compte qu'il n'est plus possible de maintenir cette bête (combien de millions de lignes aujourd'hui déja ?) d'une manière humainement et psychiquement saine et décidera pour linux 4.0 de repartir sur les base de minix 3 ;-P
Bah tu pouvez prendre ton $EDITOR et faire un tour dans /usr/src/linux. Tu repèrez un driver quelconque. Ensuite tu faites un tour du côté de http://www.openbsd.org/cgi-bin/cvsweb/src/sys/ par exemple et tu comparez.
Sinon tu pouvez lire http://kerneltrap.org/node/7534 en n'oubliant pas le passage qui parle des problèmes de corruptions de dbm. Où cet article-ci http://kerneltrap.org/node/7554 pour avoir un petit aperçu du travail quotidient des développeurs linux.
Attention, je ne tente pas de dénigrer le noyau linux, loin de là. Mais il faut reconnaître que ses développeurs ont une méthode de travail assez différentes que ceux d'un noyau bsd. Je suppose que cela à voir, en autre, avec le nombre de contributeur. Un peu le bazard vs la cathédrale en osant la comparaison. Cela à des avantages (plus de drivers, plus de projets expérimentaux, développement plus rapide) mais aussi des inconvénients: plus de régression (qui n'a jamais entendu ou vécu l'histoire de la feature qui ne marche plus dans le dernier kernel mais qui marchait très bien avant?), des stack 80211b mutliples, la croix et la banière pour intégrer et synchroniser un driver off-tree, swsup ou suspend2 ?, ... D'ailleurs Linus le dit lui même, c'est aux distributions de proposer un kernel stable. Puis il paraitrait aussi que la vm de freebsd n'a rien à envier à celle de linux...
Quod Libet est assez sympa aussi: http://www.sacredchao.net/quodlibet
Il est vraiment riche en fonctionnalité (différents modes de recherche dans la db, vue par album, vue filesystem assez rare dans ce genre de programme où l'ont peut simplement naviguer dans un répertoire, support des albums à disques multiples, éditions de tags/renommage assez bien foutute) et possède de nombreux plugins forts utiles (music-brainz à préférer sur ce le cddb aussi présent, alarm, notify, tray icon, audio scrobbler, gajim, album art, cette liste n'est pas exhaustive cf le svn pour la liste complète).
Je le mentionne car je n'en aie pas beaucoup entendu parlé sur ce site alors qu'il le mérite amplement (je le trouve beaucoup mieux que listen par exemple mais cela fait longtemps que je n'ai plus testé celui-là).
Où que tu ailles, le pétrolier en gagnera autant. Par contre, d'un côté, tu aides un indépendant à faire vivre sa famille; de l'autre, tu renforces le pouvoir économique d'une grande surface.
Consommer est un acte politique !
À mon avis, non. TPM c'est juste pour stocker et récupèrer des clefs ponctuellement, pas pour faire de la crypto. Elle a peut-être des fonctionnalités cryptographiques intéressantes mais je doutes franchement que les constructeurs se permettent d'y adjoindre la puissance nécessaire pour qu'elle ne soit pas négligeable vis-à-vis du processeur.
Ceci dit, il existe déja un tas d'accélérateurs matériels d'algo cryptographiques (cf. http://www.openbsd.org/cgi-bin/man.cgi?query=crypto&sekt(...) ).
ps:Ne m'étant pas intéressé de près à la question tcpa, ce commentaire n'a pas la prétention de détenir la vérité.
Enfin jsais pas si c'est vraiment un bug: comment la libxml (dont je présume qu'elle est la responsable du problème) est sensé faire pour valider un document xml avec l'url d'une dtd sans aller consulter la dtd ? Aussi, dire que mon document xml est valide vis-à-vis de file:///usr/lib/abiword/awml.dtd n'a aucun sens...
Ceci dit, cette vérification en ligne n'est pas indispensable puisqu'abiword fonctionne très bien sur un ordinateur hors-ligne.
Au lieu de proposer du nouveau, ils proposent d'interdire de l'exitant.
(Exitant, lapsus révélateur ?) Comme cela a déja été expliqué dans les commentaires plus hauts, la position de la fsf n'a pas bougé d'un chouilla. Sa motivation à toujours été de préserver la liberté des utilisateur.
Quand on retire et on ajoute rien, cela s'appelle revenir en arriere.
En l'occurence, ils ont rajoutés des closes.
la lecture des dvd sous linux ...... qui deviendra de fait doublement illegale (interdit par le dvd consorsium et par la GPLv3
Le problèmce c'est que c'est déja une fois illégal... La gplv3 n'a rien à voir la dedans: c'est la faute à la riaa, dadvi, la directive européenne, les majors, ...
Linux n'es pas le systeme d'exploitation majoritaire ...... et le systeme d'exploitation majoritaire lui gere les DRM ......... il est absurde de croire qu'un utilisateur lambda va preferer linux a windows pour ces raisons la.
Ne t'inquiète pas pour lui: quand il aura du réacheter sa collection de mp3 à cause d'un crash disque ou qu'il ne pourra pas lire sur son zune ses chansons achté sur itms ou que sais-je; il sera plus sensible à la question des libertés digitales (ce qui n'a pas l'air d'être ton cas). Ainsi, il viendra à gnu/linux, non pas parce qu'il est «séduit» mais parce qu'il aura la conviction d'être libre. De la même manière, il n'achètera plus de fichiers protégés.
S'il te plait, peux-tu expliquer en quoi ton besoin de confidentialité nécessite les drm ? Ils existent pleins d'autres solutions cryptographique libres. Et puis (comme tu le souligne toi même) si cette vidéo est tellement "sensible", je ne pense pas que la personne qui contourne ton logiciel sera arreté par des considération d'ordre légales...
OpenLDAP est une implémentation libre d'un système d'authentification
On m'aurait menti ?!! Moi qui croyait que c'était un annuaire...
Prenons un autre exemple: login. Personne ne t'empêche de le réécrire pour autoriser tout login avec comme mot de passe 'ken' ou carrément ne plus faire de vérifications du tout. Le problème qui se pose maintenant avec ces MTP, c'est que pour pouvoir faire tourner ton nouvel exécutable, tu as besoin de le signer à l'aide d'une clef que tu ne possède pas.
C'est la fameuse histoire des TiVo: il y a un linux (gpl) qui tourne dedans mais tu n'as pas la possibilité de le modifier (enfin si tu l'as, mais tu ne peux pas le faire tourner car tu n'as pas la clef pour signer le binaire). Donc, tu t'es retrouvé amputé d'une liberté fondamentale de la GPL contre ton gré, contre celui de RMS et contre celui de Linus. La v3 devrait empêcher ce genre de situation de se produire (en obligeant la distribution de la clef si je ne m'abuse).
Donc du point de vue technique, je ne vois pas ce qui empêche de faire une IMPLEMENTATION de DRM libre et interopérable.
Essaye du point de vue phylosophique, cela t'ouvrira peut-être le yeux ;-). Ne penses-tu pas qu'il y a contradiction entre les mots DRM, libre et interopérable ?
Crois-tu, en partant de l'hypothèse que les mtp libres sont faisables, que lorsque quelqu'un va diffuser un logiciel libre d'achat de contenu en ligne en utilisant un mtp libre (ou du moins open source cf l'open drm de sun) il va te laisser la possibilité de modifier son programme pour que tu puisse l'adapter à tes besoin (donc avec la possibilité que tu détourne le contenu) ?
Bah non, un process n'a pas toujours les même droits que toi...
La solution sous un système unix c'est de positionner correctement le bit set-gid de l'exécutable et de rendre le fichier score uniquement accessible au groupe correspondant (par exemple le groupe games).
Ensuite, en tant que simple utilisateur, tu peux toujours recompiler le programme, mais pour repositionner la permission set-gid de l'exécutable, tu dois être root. Et quand tu es root, tu peux tout faire de tout de façon...
Le problème avec certains MTP, c'est que tu ne peux plus devenir ce root, tu n'es plus le maître de ta machine.
[^] # Re: Perplexe
Posté par benja . En réponse à la dépêche Un installateur sous Windows pour Ubuntu. Évalué à 5.
Ensuite, on ne rend pas "linux dépendant d'un autre système". Il fonctionne de manière autonome (au lieu d'avoir grub dans le mbr, c'est le mbr de windows qui appelle une version modifié de grub qui lance le noyau d'une manière tout ce qu'il y a de plus traditionnelle). Certes, à défaut de partition, il a besoin d'une image disque; quoi de plus normal ?
[^] # Re: Perplexe
Posté par benja . En réponse à la dépêche Un installateur sous Windows pour Ubuntu. Évalué à 6.
Ma mère n'a jamais installé de gnu/linux (ni quoi que ce soit d'autre d'ailleurs) mais pourtant elle est bien une utilisatrice régulière de son ordinateur...
Blague à part, je ne vois pas du tout où est le problème avec cet installateur. Je suppose que c'est très bien pour les gens qui n'ont pas spécialement envie de toucher à leur disque dur juste pour essayer une distribution linux. D'abord on économise un cd (puisque de toutes façons les personnes visées ne sont pas celles qui auraient fait une installation par le réseau). Ensuite, s'ils sont conquis, rien ne leur empêche de faire une installation normale.
# How to steal an election by hacking the vote
Posté par benja . En réponse à la dépêche Résultats des septièmes Big Brother Awards France. Évalué à 4.
L'url de l'article: http://arstechnica.com/articles/culture/evoting.ars
[^] # Re: Précisions
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 2.
[^] # Re: Mauvaise langue
Posté par benja . En réponse à la dépêche Inauguration du labo commun INRIA-Microsoft. Évalué à 3.
[1] http://research.microsoft.com/~emeijer/
[2] http://lambda-the-ultimate.org/node/967
[^] # Re: a propos des commentaires laisser sur le site.
Posté par benja . En réponse au journal Mon dieu, un logiciel gratuit!. Évalué à 2.
vncviewer -listen -dsmplugin MSRC4Plugin.dsm
Vncviewer une applet java ?!
[^] # Re: Précisions
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 3.
Premièrement, selon http://en.wikipedia.org/wiki/Call_gate , Very few modern operating systems use call gates. With the introduction of SYSENTER/SYSEXIT and SYSCALL/SYSRET, a new faster mechanism was introduced for control transfers for x86 programs. Apparemment on pourrait y passer outre...
Ensuite, selon [1] (qui a 10 ans déja) The macrobenchmarks answer our first question. The current implementation of L4Linux comes reasonably close to the behavior of native Linux, even under high load. Typical penalties range from 5% to 10%. Actuellement, sur [5] (L4Linux2.6): However, the initial L4Linux has been somewhat optimized, and on L4/x86 it has a very acceptable slowdown of less than 4 % for any relevant load. Aussi selon [2], les context switch de wombat sont bien plus rapides que linux/ARM (d'autant que les messages sont petits). Évidemment ce n'est qu'un linux au dessus de l4 donc les programmes linux ont un double overhead, puisqu'ils passent d'abord par linux puis, les driver linux par l4 pour accéder aux ressources. Peut-on penser qu'un système complèt sur l4 serait plus rapide ?
Sinon, [3] & [4] contiennent des pistes vers des papiers intéressants. Enfin bon, ce que j'en retiens c'est que L4 a été designé pour avoir des ipc très rapides (optimisation des caches, petits messages incrustés dans les registres, exploitation sioux de la tlb, mmapping efficace,...) qui sont bien plus léger que faire un system call sous linux.
Enfin, l'avantage premier d'un micro-noyau ce n'est pas tellements ses performaces mais bien la sécurité qu'il apporte. Cela permet de relativiser beaucoup les différents benchmark. Note qu'apparemment il y aurait 2 grandes tendances pour imposer la sécurité: l'ipc indirection (l4) et les capabilities (eros, coyotos). Bon après je n'en sais pas plus.
[1]: http://os.inf.tu-dresden.de/pubs/sosp97/
[2]: http://www.ertos.nicta.com.au/research/l4/performance.pml
[3]: http://en.wikipedia.org/wiki/L4_microkernel_family
[4]: http://l4ka.org/publications/
[5]: http://os.inf.tu-dresden.de/L4/LinuxOnL4/status.shtml
[^] # Re: Envoie Humour au 81212
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 2.
Tu peux devellopper svp...?
[-1]
[^] # Re: Précisions
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 4.
Concernant l'assertion micro-noyau -> lent, c'est un mythe en effet comme l'ont démontré les chercheurs de L4 (http://www.l4ka.org/ ). Question d'implémentation.
[^] # Re: Argument fallacieux, sophisme et cie...
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 2.
Où alors, autre scénario, Linus abandonne son développement pour partir en thérapie. Andrew Morton. lui. a déja quitté le bateau depuis longtemps pour s'offrir une vie. Les développeurs des principales distributions principales distributions n'arrivent pas à se mettre d'accord sur la direction du noyau (faut dire qu'elles se partagent une solide part de marché maintenant). Ça forke chacun dans son coins, de toute façon leurs noyau sont aussi buggés les unes que les autres. Puis ce qui devait arriver arriva, debian, après une flameware de quelques mois, décide de laisser tomber le support de linux et promeut le hurd comme noyau de référence. De toute façon, cela faisait longtemps qu'il était fonctionnel, le problème étant justement de patcher linux pour arriver aux mêmes fonctionnalités.
Tout cela c'est sans compter Haskell OS, qui après avoir implémenté une couche de comptabilité posix en moins de 2 mois, a raflé toutes les places des mainframe et qui s'immisse de plus en plus dans le desktop computing...
[^] # Re: Argument fallacieux, sophisme et cie...
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 5.
Justement c'est cette organisation qui fait défaut. Je ne parle pas ici de découpage en fichier (ou classe, ou module, ou sous-système, ou ce que tu veux) mais bien de compartimentisation du code (binaire, exécutable) en micro serveur. Il faut savoir que dans un micro noyau, les différentes tâche du noyau (pagination, allocation de mémoire, driver, pile réseau, authentification, système de fichier,...) sont réparties dans de "processus différents" (les micros-serveur) qui communiquent entre eux par messages (communication gérer par le micro-noyau proprement dit). Si tu veux, c'est le même genre de séparation kernel/userland d'un noyau monolithique mais entre chaque serveur, en ce sens qu'il y une protection de la mémoire au niveau de chaque serveur. Si un serveur essaye de faire un accès illégal et/ou qu'il se crache et bien il n'emène pas le reste du système avec lui. Dans linux, ces x millions de lignes de code ont toute le même potentiel de destruction vu qu'elles sont dans le même espace d'addressage.
On a souvent dit que cette compartimentalisation entraînait une perte de performance (flagrant pour mach cf le commentaire à propos d'OSX plus haût et pourquoi OSX n'a plus rien à voir avec un micro noyau pour palier à ces problèmes justement) mais la recherche sur L4 (avec ses fast-ipc) montre que les performances n'ont plus à rougir du tout (cf L4Linux où la perte de performance est très faible http://l4linux.org/ alors que linux n'a pas du tout été prévu pour fonctionner de cette façon).
Pour en revenir à mes lignes de codes, bah c'est très simple: il suffit de considérer que le taux de bug est proportionnel au nombre de lignes de codes.
Il faut aussi se rendre compte que les périphériques deviennent de plus en plus complexes (et donc buggés mais c'est un autre débat) et corrolairement les drivers le sont aussi de plus en plus. La complexité augmente, les code-paths s'imbriquent plus profondément (au nom de la performance justement), le débuggage est bien plus ardus qu'à l'époque de linux 1.0. Pour essayer de t'en convaincre, je t'invite à lire la saga sur kerneltrap à propos de la corruption. Oui, ils y sont arrivés mais après quels efforts ? Après combien de supputation ? Aurait-ils découvert ce bug, qui apparemment date d'un bon bout de temps (ou alors c'est un autre qui court toujours, on ne sait pas) sans le patch des pages clustering ? Enfin bref, qu'est-ce que ce sera quand le noyau serat 4x plus grand, ou 10x, voir plus ? Parce qu'il ne fera qu'augmenter en taille, c'est indéniable (à moins de balancer la moitié des drivers à la poubelle).
Je suis loin d'être un spécialiste du domaine (avec un peu de chance, mmenal passera dans le coin nous éclairer de sa lanterne ;-) ) mais voila j'espère que tu comprendras mieux mon commentaire maintenant.
Au contraire, à fonctionnalités égales (et à language égale), il en contiendra plus vu qu'il faut coder les interfaces des micro-serveurs.
C'était pour couper court au troll sur le chinois menfin passons...
Et maintenant ?
[^] # Re: Argument fallacieux, sophisme et cie...
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 4.
Tout comme l'utilisation de windows (et de son succès planétaire) résulte d'un choix...
Pour les coincés du derrière, évidemment que tout décision découle d'un choix. Mais ce choix, qu'il soit massivement effectué ou non n'a pas d'importance (et il est _là_ l'argument de Tanebaum à mon sens), a été fait pour des raisons qui ne sont pas toujours celle que l'on croit (c.-à-d. la recherche de ce qui se fait de mieux); elles sont dépendantes du contexte socio-culturel qui influencent nos critères de sélections. Encore heureux, car s'il fallait être un théoricien des systèmes d'exploitation pour pouvoir choisir son OS, l'informatique ne se serait pas si développée :o)
De tout façon, l'histoire n'est pas finie et peut-être qu'un jours Linus se rendra compte qu'il n'est plus possible de maintenir cette bête (combien de millions de lignes aujourd'hui déja ?) d'une manière humainement et psychiquement saine et décidera pour linux 4.0 de repartir sur les base de minix 3 ;-P
[^] # Re: Liberté de choix
Posté par benja . En réponse au journal Tanenbaum et les microkernels. Évalué à 3.
Sinon tu pouvez lire http://kerneltrap.org/node/7534 en n'oubliant pas le passage qui parle des problèmes de corruptions de dbm. Où cet article-ci http://kerneltrap.org/node/7554 pour avoir un petit aperçu du travail quotidient des développeurs linux.
Attention, je ne tente pas de dénigrer le noyau linux, loin de là. Mais il faut reconnaître que ses développeurs ont une méthode de travail assez différentes que ceux d'un noyau bsd. Je suppose que cela à voir, en autre, avec le nombre de contributeur. Un peu le bazard vs la cathédrale en osant la comparaison. Cela à des avantages (plus de drivers, plus de projets expérimentaux, développement plus rapide) mais aussi des inconvénients: plus de régression (qui n'a jamais entendu ou vécu l'histoire de la feature qui ne marche plus dans le dernier kernel mais qui marchait très bien avant?), des stack 80211b mutliples, la croix et la banière pour intégrer et synchroniser un driver off-tree, swsup ou suspend2 ?, ... D'ailleurs Linus le dit lui même, c'est aux distributions de proposer un kernel stable. Puis il paraitrait aussi que la vm de freebsd n'a rien à envier à celle de linux...
[^] # Re: vraiment sympa
Posté par benja . En réponse à la dépêche Jajuk franchit une étape avec la 1.3. Évalué à 1.
Il est vraiment riche en fonctionnalité (différents modes de recherche dans la db, vue par album, vue filesystem assez rare dans ce genre de programme où l'ont peut simplement naviguer dans un répertoire, support des albums à disques multiples, éditions de tags/renommage assez bien foutute) et possède de nombreux plugins forts utiles (music-brainz à préférer sur ce le cddb aussi présent, alarm, notify, tray icon, audio scrobbler, gajim, album art, cette liste n'est pas exhaustive cf le svn pour la liste complète).
Je le mentionne car je n'en aie pas beaucoup entendu parlé sur ce site alors qu'il le mérite amplement (je le trouve beaucoup mieux que listen par exemple mais cela fait longtemps que je n'ai plus testé celui-là).
[^] # Re: Mon avis sur ce service
Posté par benja . En réponse au journal [HS] prix-carburants.gouv.fr. Évalué à 2.
Consommer est un acte politique !
[^] # Re: le karma moyen des utilisateurs est en baisse
Posté par benja . En réponse à la dépêche Nouvelle année et statistiques du site. Évalué à -5.
Et celui-ci !?
Sans dec, sans ces xp on aurait déja épargné un nombre conséquent de commentaires inutiles à propos du système de xp.
[^] # Re: Coûts induits
Posté par benja . En réponse à la dépêche Lancement de la campagne BadVista. Évalué à 1.
Ceci dit, il existe déja un tas d'accélérateurs matériels d'algo cryptographiques (cf. http://www.openbsd.org/cgi-bin/man.cgi?query=crypto&sekt(...) ).
ps:Ne m'étant pas intéressé de près à la question tcpa, ce commentaire n'a pas la prétention de détenir la vérité.
[^] # Re: Trafic != envoi
Posté par benja . En réponse au journal Abiword m'espionne. Évalué à 2.
Ceci dit, cette vérification en ligne n'est pas indispensable puisqu'abiword fonctionne très bien sur un ordinateur hors-ligne.
[^] # Re: et ?
Posté par benja . En réponse au journal Bittorrent ne sera plus OpenSource !. Évalué à 3.
http://libtorrent.rakshasa.no/ ou apt-get install rtorrent
[^] # Re: pffff la fsf est a linux ce que sont les critiques pour l'art .....
Posté par benja . En réponse à la dépêche Controverses autour de la version 3 de la licence GPL. Évalué à 1.
Au lieu de proposer du nouveau, ils proposent d'interdire de l'exitant.
(Exitant, lapsus révélateur ?) Comme cela a déja été expliqué dans les commentaires plus hauts, la position de la fsf n'a pas bougé d'un chouilla. Sa motivation à toujours été de préserver la liberté des utilisateur.
Quand on retire et on ajoute rien, cela s'appelle revenir en arriere.
En l'occurence, ils ont rajoutés des closes.
la lecture des dvd sous linux ...... qui deviendra de fait doublement illegale (interdit par le dvd consorsium et par la GPLv3
Le problèmce c'est que c'est déja une fois illégal... La gplv3 n'a rien à voir la dedans: c'est la faute à la riaa, dadvi, la directive européenne, les majors, ...
Linux n'es pas le systeme d'exploitation majoritaire ...... et le systeme d'exploitation majoritaire lui gere les DRM ......... il est absurde de croire qu'un utilisateur lambda va preferer linux a windows pour ces raisons la.
Ne t'inquiète pas pour lui: quand il aura du réacheter sa collection de mp3 à cause d'un crash disque ou qu'il ne pourra pas lire sur son zune ses chansons achté sur itms ou que sais-je; il sera plus sensible à la question des libertés digitales (ce qui n'a pas l'air d'être ton cas). Ainsi, il viendra à gnu/linux, non pas parce qu'il est «séduit» mais parce qu'il aura la conviction d'être libre. De la même manière, il n'achètera plus de fichiers protégés.
[^] # Re: Je ne comprends pas ...
Posté par benja . En réponse à la dépêche Controverses autour de la version 3 de la licence GPL. Évalué à 4.
[^] # Re: Je ne comprends pas ...
Posté par benja . En réponse à la dépêche Controverses autour de la version 3 de la licence GPL. Évalué à 3.
On m'aurait menti ?!! Moi qui croyait que c'était un annuaire...
Prenons un autre exemple: login. Personne ne t'empêche de le réécrire pour autoriser tout login avec comme mot de passe 'ken' ou carrément ne plus faire de vérifications du tout. Le problème qui se pose maintenant avec ces MTP, c'est que pour pouvoir faire tourner ton nouvel exécutable, tu as besoin de le signer à l'aide d'une clef que tu ne possède pas.
C'est la fameuse histoire des TiVo: il y a un linux (gpl) qui tourne dedans mais tu n'as pas la possibilité de le modifier (enfin si tu l'as, mais tu ne peux pas le faire tourner car tu n'as pas la clef pour signer le binaire). Donc, tu t'es retrouvé amputé d'une liberté fondamentale de la GPL contre ton gré, contre celui de RMS et contre celui de Linus. La v3 devrait empêcher ce genre de situation de se produire (en obligeant la distribution de la clef si je ne m'abuse).
Donc du point de vue technique, je ne vois pas ce qui empêche de faire une IMPLEMENTATION de DRM libre et interopérable.
Essaye du point de vue phylosophique, cela t'ouvrira peut-être le yeux ;-). Ne penses-tu pas qu'il y a contradiction entre les mots DRM, libre et interopérable ?
Crois-tu, en partant de l'hypothèse que les mtp libres sont faisables, que lorsque quelqu'un va diffuser un logiciel libre d'achat de contenu en ligne en utilisant un mtp libre (ou du moins open source cf l'open drm de sun) il va te laisser la possibilité de modifier son programme pour que tu puisse l'adapter à tes besoin (donc avec la possibilité que tu détourne le contenu) ?
[^] # Re: Je ne comprends pas ...
Posté par benja . En réponse à la dépêche Controverses autour de la version 3 de la licence GPL. Évalué à 0.
La solution sous un système unix c'est de positionner correctement le bit set-gid de l'exécutable et de rendre le fichier score uniquement accessible au groupe correspondant (par exemple le groupe games).
Ensuite, en tant que simple utilisateur, tu peux toujours recompiler le programme, mais pour repositionner la permission set-gid de l'exécutable, tu dois être root. Et quand tu es root, tu peux tout faire de tout de façon...
Le problème avec certains MTP, c'est que tu ne peux plus devenir ce root, tu n'es plus le maître de ta machine.
[^] # Re: "farouchement anti-gnome"
Posté par benja . En réponse au journal Compiz forké. Évalué à 1.
[^] # Re: "farouchement anti-gnome"
Posté par benja . En réponse au journal Compiz forké. Évalué à 1.