(j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU)
euh... tu m'expliques là ? j'suis pas le seul à pas comprendre ce que tu entends par là... Par définition, le noyau c'est ce qui s'exécute en mode noyau....
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système
Parce que le noyau et le serveur spécialisé étant tous les deux plus simples et plus compacts, l'empreinte sur le cache, les problèmes de pile, ... sont réduits. Avoir un gros noyau oblige à compliquer le code à base de locks, ... qui coûtent chers en terme de performance.
De plus, les serveurs sont beaucoup plus facilement préemptibles et multithreadés que le code noyau, ce qui donne aussi un gain de performances, surtout sur les machines multi-processeurs.
Mais surtout, le plus important ce n'est pas le gain sur le RPC ou le syscall lui-même, ce sont toutes les autres optimisations qui sont possibles avec un système à base de micro-noyau, comme le 0-copy (cf mon post plus haut), la possibilité pour les programmes de gérer eux-mêmes leur mémoire virtuelle (ou au moins d'utiliser une VM qui leur convient, puisqu'il n'y a pas de VM optimale), ou bien l'optimisation des IPCs qui existent déjà. Trouve moi un seul noyau monolithique où tu peux choisir la VM et le scheduler que tu veux utiliser ? Sur un système à base de micro-noyaux, tu peux même avoir plusieurs VM et plusieurs schedulers pour des applications différentes. Et là, le gain de perf peut être énorme.
Grâce au multiplexage d'espace d'addressage (expliqué en détail dans les docs L4), justement, on peut faire de l'IPC sans réel changement de contexte (sans TLB flush par exemple).
Pour de l'IPC entre deux processus différents, oui, on est obligé de passer par le noyau. Par contre, le code exécuté dans le noyau pour transmettre l'IPC est si court et si simple, qu'il s'exécute très rapidement, et surtout sans polluer les lignes de cache. Le coût total d'un RPC L4 est donc inférieur à celui d'un appel système sur Linux.
De plus, dés qu'on veut un peu plus de fiabilité, de tolérance de panne et de souplesse, on ne met plus la totalité du code dans le noyau (comme le serveur X, par exemple, qui est en user-space). Donc là, on se retrouve à faire de l'IPC entre le client et X, avec un noyau qui n'est pas du tout prévu pour, et donc on a une perte de performances beaucoup plus importante. La même chose s'applique, par exemple, à une compilation en -pipe, ...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Je ne l'ai jamais nié. L4 existe, est extrêment rapide, mais il n'existe pas encore de système complet basé sur L4 aussi versatile qu'un GNU/Linux (il y'a bien des OS basés sur L4, mais uniquement pour des domaines très pointus et précis pour l'instant).
Quant aux modules, ça n'a absolument rien à voir avec ce que peut faire un système à base de micro-noyau.
Qu'est-ce que tu veux que je dise de plus ? Allez, fais un petit effort, et après on en reparlera (et lire, c'est lire, pas regarder les tableaux et les graphes sans lire le reste...)
Tout va plus lentement sur L4 que sur Linux (sans exception).
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
De plus le L4Linux testé est basé sur une vieille version de L4 qui est loin d'implémenter toutes les optimisations possibles.
"Performance of Address-Space Multiplexing on the Pentium"
Idem, cet article compare L4Linux et Linux, avec des applications utilisant les sémantiques POSIX. Pas un système à base de L4 utilisant les sémantiques L4 et des programmes utilisant de l'IPC L4.
simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
et ?
Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protection.pdf(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
Tu as lu les docs L4 ? Un système à base de micro-noyau est beaucoup plus souple et permet aux programmes eux-mêmes de prendre plus de décision, d'où un gain de vitesse (par exemple, si un SGBD peut décider lui-même quelles pages garder en mémoire et quelles pages 'swapper', il peut le faire de manière beaucoup plus efficace que si un VM globale qui ne sait rien sur lui prend la décision. Les exemples dans ce genre sont très nombreux.)
Beaucoup d'autres optimisations peuvent être réalisées (0-copy, multiplexage d'espaces d'addressage) de manière beaucoup plus simple et efficaces sur des systèmes à base de micro-noyau. Lis un peu les docs dont je te parlais avant de parler.
Hum... GNU/Hurd n'est _pas_ à l'heure actuelle plus simple d'utilisation, bien au contraire, comme tout système en cours de développement, il ne s'addresse pas au grand public.
Maintenant, à terme, oui on peut penser que les fonctionnalités du Hurd puissent être utilisées pour donner plus de confort à un utilisateur même néophyte, et à tous les niveaux (hotplug plus simple, meilleur gestion de la sécurité pour éviter les bourdes, sandboxing d'applications pour éviter les risques de trojan/virus, translators en tout genre, ...). Mais ce n'est pas encore là, qu'on ne se trompe pas.
Maintenant, pour répondre au commentaire précédent, j'aimerais qu'on me donne _un_ argument en faveur de Linux et des noyaux monolithiques (à part que Linux est actuellement plus abouti, plus stable, plus rapide, ... oui, c'est vrai, mais ce n'est pas un avantage intrinsèque. J'entends personne dire "Linux 2.4 c'est mieux que Linux 2.5 parce que le 2.5 est instable"...). Pour tous ceux qui vont dire "la rapidité" je vous demande de lire soigneusement les documents qui se trouvent sur http://l4ka.org/publications/(...) avant de répondre, merci :)
Ouais, enfin, quand je vois le nombre de paquets qu'on est obligé de recompiler sur les mandrakes au taf: omniorb, xerces2, libstlport, nano, ... (et pour moi à l'époque où j'avais une mdk: wmakerconf, wmpinboard, ...), alors que tout ça est en standard dans la debian, il n'y a pas que la granularité plus fine... et la granularité des paquets, c'est important aussi (entre autre parce que ça permet aussi d'avoir des dépendances plus fines et donc de faciliter la cohabitation de paquets de différentes versions de la distribution)
> Ca c'est un bon argument mais d'ici la il se pourrait que subversion soit utilisable ne penses tu pas?
Subversion est utilisable. CVS aussi (et beaucoup de gros projets s'en contentent). Mais ne crois-tu pas qu'il sera un peu trop tard ? Avec toutes les méta-données sur Bit Mover, tous les devs habitués à utiliser BK, ... ? Et ne crois-tu pas que les devs vont préférer ne pas intégrer ce genre de patchs plutôt que de remettre en cause leurs habitudes de travail ?
Et que dire pour Alan, Andrea, Rik, ... qui légalement n'ont pas le droit d'utiliser Bit Keeper puisque leurs employeurs diffusent CVS (et peut-être un jour Subversion) ? Larry a dit qu'il _permettait_ aux développeurs du noyau payés par une distribution de continuer à utiliser Bit Keeper... mais le texte exact de la licence dit le contraire. Alors ? On fait quoi ?
Ce que dit RMS, c'est que le logiciel libre est dangereux. Qu'il peut toujours se retourner contre l'utilisateur, et qu'accepter de l'utiliser c'est accepter des chaines et de dépendre du bon vouloir d'une société. Bien sûr, on peut toujours changer après, si la nouvelle licence ne plait pas. Mais ça veut dire abandonner ses habitudes de travail, souvent perdre des données d'une manière ou d'une autre, ...
Ce que Linus ne comprend pas, et ce que RMS a préféré signaler, c'est que la licence de Bit Keeper pour se retourner directement contre le noyau. En effet, si jamais Linux intègre un filesystem avec gestion des versions (comme le sera peut-être un jour ReiserFS ou d'autres), alors ce jour là _tous_ les développeurs du noyau perdront le droit d'utiliser gratuitement Bit Keeper (pour violation de la clause de "non-concurrence"). Ceci est un exemple parmi d'autres des dangers _réels_ que Bit Keeper fait courrir au noyau. RMS n'est pas intervenu à l'origine du choix de Bit Keeper.
Petite remarque: RMS n'a _pas_ été banni. Certains dev du noyau ont demandé à ce qu'il soit banni, mais ça n'a pas été fait (et heureusement... d'ailleurs s'ils l'avaient blacklisté, je crois qu'un grand nombre de gens, moi y compris, ce seraient désincrits de la liste).
C'est pas mal leur truc, mais c'est loin d'être aussi fiable que ce que fait GNU. Je m'explique: sous OpenBSD, login (ou ftpd, ou sshd) ne tourne pas en root, mais peut appeler setuid() en root. Si un buffer overflow (ou équivalent) est trouvé dans le programme, il ne pourra certes plus créer directement un shell root, mais il pourra appeler setuid() puis se transformer un shell root; la sécurité n'a donc été que très légèrement accure.
Pour les programmes qui ont juste besoin de binder un port (comme Apache), ça permet d'éviter de les lancer en root, de réaliser les opérations prioritaires puis d'abandonner les privilèges root, c'est mieux, mais encore une fois, ça ne change pas fondamentalement la sécurité.
Même pour une commande comme mount par exemple, si on trouve un trou dans mount, en lui faisant monter un loopback une image contenant un shell suidé root, on peut avoir un shell root alors que pourtant mount n'est autorisé qu'à faire le syscall mount() en root.
Donc oui, c'est toujours mieux que rien, ça élimine certains risques, et ça permet de rendre la tâche un peu plus difficile pour un "attaquant", mais fondamentalement, ça ne change que la taille des mailles du filet.
Juste une remarque: Thunderbird n'est pas basé sur Minotaur; mais est juste le nouveau nom du projet Minotaur... Il n'y a pas deux projets, juste un seul qui a changé de nom.
1/ Darwin ce n'est pas vraiment un Unix (vu que c'est basé sur un micro-noyau)
2/ Darwin c'est pas libre. L'APSL est Open Source, mais non libre.
3/ Euh... je croyais qu'NTFS est un FS journalisé, je me trompe ?
4/ Ça veut dire quoi "coûtera 10 à 15% de perfs" ? Parce que suivant ce que l'on fait (lecture ou écriture, petits ou gros fichiers, accès séquentiel ou linéaire, manipulation de données ou de meta-données, ...) les résultats risquent d'être très différents... ça n'a aucun sens de parler d'une chute de perf de 10% de manière générale comme ça...
Sans vouloir troller, il me semble au contraire qu'une bouée est très peu adaptée pour parler de la documentation. Une bouée, c'est quelque chose que l'on utilise lorsque l'on est danger, en situation d'urgence pour se sauver la vie. Une doc, ce n'est pas du tout ça. Lire la doc, c'est quelque chose de normal, que l'on devrait toujours faire (au moins en partie) avant de commencer à utiliser un programme. Pas uniquement le dernier recours quand on doit sauver sa peau.
Ce genre d'initiative est extrêment bénéfique pour tous. En effet, les logiciels utilisés dans les écoles lors des formations ont un très impact sur les choix que les futurs diplômés vont promouvoir dans leur futur entreprise. De plus, comme cela a si bien été dit, les principes fondateurs du logiciel libre (libre accés et libre diffusion de la connaissance) sont les mêmes que les principes de base de l'éduction publique, et il est bien dommage de voir que certaines écoles privées sont plus orientées logiciels libres que certaines écoles publiques.
Espérons que ce genre d'initiative ne restera pas isolé, mais servira d'exemples dans d'autres écoles, et sera suivi d'effets.
Sinon le Hurd fait partie de GNU, au même titre que gcc, la GNU libc, GNU emacs ou GNU bash. Dire GNU/Hurd c'est redondant, le Hurd est déjà contenu dans le système GNU.
Juste pour rappeler quelques liens pour ceux qui s'intéressent à GNU et au Hurd: le site d'HurdFr: http://hurdfr.org(...) et le site de news d'HurdFr: http://news.hurdfr.org(...) . Vous pouvez aussi nous retrouver sur IRC (#hurdfr @ FreeNode) si vous avez des questions, et comme l'expliquait Manuel il y a quelques temps, on peut même se retrouver autour d'un lait fraise^W^Wice tea (pour ceux qui habitent près de Paris) :)
Je tiens aussi à saluer cette initiative et à remercier son créateur ! Merci Olivier !
Enfin, comme vous le verrez en allant sur le site d'HurdFr ou en lisant les mailing lists, ce mois de septembre nous avons eu une nouvelle console (en espace utilisateur, avec consoles virtuelles, support de l'unicode, attachement/détachement à la screen...) et une implémentation des threads POSIX ! Le Troupeau galoppe :)
PS: Olivier, si tu pouvais faire des images de la J2 avec la console de Marcus et les pthreads, ce serait vraiment génial !
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
euh... tu m'expliques là ? j'suis pas le seul à pas comprendre ce que tu entends par là... Par définition, le noyau c'est ce qui s'exécute en mode noyau....
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système
Parce que le noyau et le serveur spécialisé étant tous les deux plus simples et plus compacts, l'empreinte sur le cache, les problèmes de pile, ... sont réduits. Avoir un gros noyau oblige à compliquer le code à base de locks, ... qui coûtent chers en terme de performance.
De plus, les serveurs sont beaucoup plus facilement préemptibles et multithreadés que le code noyau, ce qui donne aussi un gain de performances, surtout sur les machines multi-processeurs.
Mais surtout, le plus important ce n'est pas le gain sur le RPC ou le syscall lui-même, ce sont toutes les autres optimisations qui sont possibles avec un système à base de micro-noyau, comme le 0-copy (cf mon post plus haut), la possibilité pour les programmes de gérer eux-mêmes leur mémoire virtuelle (ou au moins d'utiliser une VM qui leur convient, puisqu'il n'y a pas de VM optimale), ou bien l'optimisation des IPCs qui existent déjà. Trouve moi un seul noyau monolithique où tu peux choisir la VM et le scheduler que tu veux utiliser ? Sur un système à base de micro-noyaux, tu peux même avoir plusieurs VM et plusieurs schedulers pour des applications différentes. Et là, le gain de perf peut être énorme.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Grâce au multiplexage d'espace d'addressage (expliqué en détail dans les docs L4), justement, on peut faire de l'IPC sans réel changement de contexte (sans TLB flush par exemple).
Pour de l'IPC entre deux processus différents, oui, on est obligé de passer par le noyau. Par contre, le code exécuté dans le noyau pour transmettre l'IPC est si court et si simple, qu'il s'exécute très rapidement, et surtout sans polluer les lignes de cache. Le coût total d'un RPC L4 est donc inférieur à celui d'un appel système sur Linux.
De plus, dés qu'on veut un peu plus de fiabilité, de tolérance de panne et de souplesse, on ne met plus la totalité du code dans le noyau (comme le serveur X, par exemple, qui est en user-space). Donc là, on se retrouve à faire de l'IPC entre le client et X, avec un noyau qui n'est pas du tout prévu pour, et donc on a une perte de performances beaucoup plus importante. La même chose s'applique, par exemple, à une compilation en -pipe, ...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Je ne l'ai jamais nié. L4 existe, est extrêment rapide, mais il n'existe pas encore de système complet basé sur L4 aussi versatile qu'un GNU/Linux (il y'a bien des OS basés sur L4, mais uniquement pour des domaines très pointus et précis pour l'instant).
Quant aux modules, ça n'a absolument rien à voir avec ce que peut faire un système à base de micro-noyau.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Qu'est-ce que tu veux que je dise de plus ? Allez, fais un petit effort, et après on en reparlera (et lire, c'est lire, pas regarder les tableaux et les graphes sans lire le reste...)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
De plus le L4Linux testé est basé sur une vieille version de L4 qui est loin d'implémenter toutes les optimisations possibles.
"Performance of Address-Space Multiplexing on the Pentium"
Idem, cet article compare L4Linux et Linux, avec des applications utilisant les sémantiques POSIX. Pas un système à base de L4 utilisant les sémantiques L4 et des programmes utilisant de l'IPC L4.
simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
et ?
Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protection.pdf(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Beaucoup d'autres optimisations peuvent être réalisées (0-copy, multiplexage d'espaces d'addressage) de manière beaucoup plus simple et efficaces sur des systèmes à base de micro-noyau. Lis un peu les docs dont je te parlais avant de parler.
[^] # Re: Debian n'est pas seulement APT: 9000 paquets, testing, sigs, assos...
Posté par Gaël Le Mignot . En réponse à la dépêche Debian sur les postes de travail. Évalué à 1.
-1 (toujours pas ?!)
[^] # Re: Debian n'est pas seulement APT: 9000 paquets, testing, sigs, assos...
Posté par Gaël Le Mignot . En réponse à la dépêche Debian sur les postes de travail. Évalué à 1.
[root@server run]#
idem sans la faute de frappe (désolé)
-1
[^] # Re: Debian n'est pas seulement APT: 9000 paquets, testing, sigs, assos...
Posté par Gaël Le Mignot . En réponse à la dépêche Debian sur les postes de travail. Évalué à 1.
[root@server run]# urpmf boot/vmlinuz
kernel-2.4.19.16mdk:/boot/vmlinuz-2.4.19-16mdk
kernel-enterprise-2.4.19.16mdk:/boot/vmlinuz-2.4.19-16mdkenterprise
kernel-linus2.4:/boot/vmlinuz-2.4.19-1mdklinus
kernel-secure-2.4.19.16mdk:/boot/vmlinuz-2.4.19-16mdksecure
kernel-smp-2.4.19.16mdk:/boot/vmlinuz-2.4.19-16mdksmp
donc urmpf marche bien avec des sources à jour mais:
[root@server run]# urpmf bin/nano
[root@server run]# urpmf ominiidl
[root@server run]#
Pour xerces, il y a le 1.5 mais pas le 2.0
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Maintenant, à terme, oui on peut penser que les fonctionnalités du Hurd puissent être utilisées pour donner plus de confort à un utilisateur même néophyte, et à tous les niveaux (hotplug plus simple, meilleur gestion de la sécurité pour éviter les bourdes, sandboxing d'applications pour éviter les risques de trojan/virus, translators en tout genre, ...). Mais ce n'est pas encore là, qu'on ne se trompe pas.
Maintenant, pour répondre au commentaire précédent, j'aimerais qu'on me donne _un_ argument en faveur de Linux et des noyaux monolithiques (à part que Linux est actuellement plus abouti, plus stable, plus rapide, ... oui, c'est vrai, mais ce n'est pas un avantage intrinsèque. J'entends personne dire "Linux 2.4 c'est mieux que Linux 2.5 parce que le 2.5 est instable"...). Pour tous ceux qui vont dire "la rapidité" je vous demande de lire soigneusement les documents qui se trouvent sur http://l4ka.org/publications/(...) avant de répondre, merci :)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
-1 (zut, y'a pas)
[^] # Re: Debian n'est pas seulement APT: 9000 paquets, testing, sigs, assos...
Posté par Gaël Le Mignot . En réponse à la dépêche Debian sur les postes de travail. Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
/me a honte
/me retourne faire du C++ pour expier
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
Subversion est utilisable. CVS aussi (et beaucoup de gros projets s'en contentent). Mais ne crois-tu pas qu'il sera un peu trop tard ? Avec toutes les méta-données sur Bit Mover, tous les devs habitués à utiliser BK, ... ? Et ne crois-tu pas que les devs vont préférer ne pas intégrer ce genre de patchs plutôt que de remettre en cause leurs habitudes de travail ?
Et que dire pour Alan, Andrea, Rik, ... qui légalement n'ont pas le droit d'utiliser Bit Keeper puisque leurs employeurs diffusent CVS (et peut-être un jour Subversion) ? Larry a dit qu'il _permettait_ aux développeurs du noyau payés par une distribution de continuer à utiliser Bit Keeper... mais le texte exact de la licence dit le contraire. Alors ? On fait quoi ?
Ce que dit RMS, c'est que le logiciel libre est dangereux. Qu'il peut toujours se retourner contre l'utilisateur, et qu'accepter de l'utiliser c'est accepter des chaines et de dépendre du bon vouloir d'une société. Bien sûr, on peut toujours changer après, si la nouvelle licence ne plait pas. Mais ça veut dire abandonner ses habitudes de travail, souvent perdre des données d'une manière ou d'une autre, ...
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . En réponse à la dépêche Bitkeeper, RMS et PLONK.. Évalué à 1.
[^] # Re: privileges ... élévation
Posté par Gaël Le Mignot . En réponse à la dépêche privileges ... élévation. Évalué à 1.
Pour les programmes qui ont juste besoin de binder un port (comme Apache), ça permet d'éviter de les lancer en root, de réaliser les opérations prioritaires puis d'abandonner les privilèges root, c'est mieux, mais encore une fois, ça ne change pas fondamentalement la sécurité.
Même pour une commande comme mount par exemple, si on trouve un trou dans mount, en lui faisant monter un loopback une image contenant un shell suidé root, on peut avoir un shell root alors que pourtant mount n'est autorisé qu'à faire le syscall mount() en root.
Donc oui, c'est toujours mieux que rien, ça élimine certains risques, et ça permet de rendre la tâche un peu plus difficile pour un "attaquant", mais fondamentalement, ça ne change que la taille des mailles du filet.
# Re: Un autre
Posté par Gaël Le Mignot . En réponse à la dépêche Un autre "Thunderbird" ?. Évalué à 1.
http://www.mozillazine.org/talkback.html?article=2546(...)
[^] # Re: Vous voulez du rapide et du léger ...
Posté par Gaël Le Mignot . En réponse à la dépêche Un autre "Thunderbird" ?. Évalué à 1.
http://www.epita.fr:8000/~le-che_e/pine.html(...)
# Quelques remarques en vrac
Posté par Gaël Le Mignot . En réponse à la dépêche MacOS X reçoit enfin un système de fichier journalisé. Évalué à 1.
2/ Darwin c'est pas libre. L'APSL est Open Source, mais non libre.
3/ Euh... je croyais qu'NTFS est un FS journalisé, je me trompe ?
4/ Ça veut dire quoi "coûtera 10 à 15% de perfs" ? Parce que suivant ce que l'on fait (lecture ou écriture, petits ou gros fichiers, accès séquentiel ou linéaire, manipulation de données ou de meta-données, ...) les résultats risquent d'être très différents... ça n'a aucun sens de parler d'une chute de perf de 10% de manière générale comme ça...
[^] # Re: Welcome to the real world !
Posté par Gaël Le Mignot . En réponse à la dépêche Nouvelle offensive sur les brevets logiciels. Évalué à 1.
[^] # Re: Le site de traductions des mans : un an déjà
Posté par Gaël Le Mignot . En réponse à la dépêche Le site de traductions des mans : un an déjà. Évalué à 1.
# Bravo
Posté par Gaël Le Mignot . En réponse à la dépêche De l'utilisation des logiciels propriétaires dans l'enseignement public. Évalué à 1.
Ce genre d'initiative est extrêment bénéfique pour tous. En effet, les logiciels utilisés dans les écoles lors des formations ont un très impact sur les choix que les futurs diplômés vont promouvoir dans leur futur entreprise. De plus, comme cela a si bien été dit, les principes fondateurs du logiciel libre (libre accés et libre diffusion de la connaissance) sont les mêmes que les principes de base de l'éduction publique, et il est bien dommage de voir que certaines écoles privées sont plus orientées logiciels libres que certaines écoles publiques.
Espérons que ce genre d'initiative ne restera pas isolé, mais servira d'exemples dans d'autres écoles, et sera suivi d'effets.
[^] # Re: GNU ... Pourquoi pas GNU/HURD ?
Posté par Gaël Le Mignot . En réponse à la dépêche image de GNU sous bochs. Évalué à 10.
Sinon le Hurd fait partie de GNU, au même titre que gcc, la GNU libc, GNU emacs ou GNU bash. Dire GNU/Hurd c'est redondant, le Hurd est déjà contenu dans le système GNU.
# Quelques liens - quelques infos
Posté par Gaël Le Mignot . En réponse à la dépêche image de GNU sous bochs. Évalué à 10.
Je tiens aussi à saluer cette initiative et à remercier son créateur ! Merci Olivier !
Pour ceux qui veulent tester un peu plus, je vous conseille d'utiliser le dernier tarball de Marcus (ftp://alpha.gnu.org/pub/gnu/hurd/contrib/marcus/(...) ) ou les ISOs de la Debian GNU/Hurd J2 - et n'oubliez le guide d'installation de Neal: http://ftp.walfield.org/pub/people/neal/papers/hurd-installation-gu(...) ); en effet un changement d'API a eu lieu entre la J1 et la J2. Un petit repository de paquets Debian pour la J2 (ou la Sid GNU/Hurd) fait par des membres d'HurdFr est disponible sur http://kilobug.free.fr/hurd/debian(...) (avec The Gimp, ...)
Enfin, comme vous le verrez en allant sur le site d'HurdFr ou en lisant les mailing lists, ce mois de septembre nous avons eu une nouvelle console (en espace utilisateur, avec consoles virtuelles, support de l'unicode, attachement/détachement à la screen...) et une implémentation des threads POSIX ! Le Troupeau galoppe :)
PS: Olivier, si tu pouvais faire des images de la J2 avec la console de Marcus et les pthreads, ce serait vraiment génial !