bmc a écrit 1651 commentaires

Moi, je les trouve hyper class les couvertures de bouquins O'Reilly. Un dromadaire par ci, un koala par là, bref, que du bonheur !

À quand le «Twm - La plus professionnelle des interfaces ( Login ?? )» ?

Je ne pense pas que le problème soit d'avoir les droits root au départ. Le problème, c'est d'éviter qu'un bug dans lufs permette à quiconque d'obtenir les droits root. Si aucune partie du logiciel ne tourne avec les droits root et dans le noyau, les implications sur la sécurité sont, encore une fois, très réduites par rapport à un module noyau.
Il suffit de voir qu'un des moyens les plus sophistiqués pour un attaquant de masquer sa prise de possession sur une machine Linux est d'installer un module noyau pour modifier le comportement de certains exécutables.

Ça n'est plus en gras, un modéro a du modifier qqch ou un truc du genre.

et décrédibiliser le sondage, qui pourtant aurait pu être intéressant. Bon, c'est sûr que c'est au concepteur de s'en occuper, mais un peu de civisme n'a jamais fait de mal...

Dans le titre peut etre
Ok j'arrete :)

Merde, c'est peut etre le span
les moins vont pleuvoir !

Je tente une balise fermante.
-1

UML, si je ne m'abuse, utilise des modules noyau. Ces modules noyaux sont, comme tout programme informatique, sujets à bug. S'il y a une seule différence à retenir entre le Hurd et Linux en tant que noyaux, c'est bien que les modules Linux ont d'énormes privilèges, qui sont très certainement disproportionnés par rapport à ce qu'ils devraient: un module a accès, à travers le noyau, à l'ensemble de l'espace d'adressage du noyau, il peut foutre une merde noire s'il est mal codé, et faire planter toute la machine alors meme qu'il ne sert qu'à une fonction très particulière.
Les serveurs Hurd n'ont pas ce type de privilèges. Ils tournent dans l'espace utilisateur. Je pense qu'on peut tenter un parallèle (corrigez moi si je me trompe) avec les serveurs DNS, FTP, Web, etc. bref les applications serveurs sous n'importe quel OS, qui tournent sous un utilisateur quelconque, et dont les droits sont restreints à ceux de cet utilisateur.

Ainsi (et là je parle de quelque chose dont je n'ai qu'une connaissance très imparfaite, donc merci de me corriger), je pense qu'on peut assigner à un certain serveur Hurd un utilisateur (par exemple, l'utilisateur "fs" au serveur de systèmes de fichiers), et ainsi limiter les retombées d'un bug ou d'un trou de sécurité quelconque. Bien sur, un bug dans le serveur de systèmes de fichiers peut etre catastrophique: après tout, celui qui gère le système de fichiers a un accès privilégié aux fichiers, il peut donc les foutre en l'air ! L'idée est qu'il ne peut pas faire de mal en dehors de ce qu'il est censé gérer. Un peu l'idée d'un chroot, ou l'utilisateur peut bien sur massacrer tous ses fichiers, mais ça n'affectera pas les autres utilisateurs.

On dirait que c'est un bug du moteur de Linuxfr...

Depuis quelque temps déjà, il existe une partie "Library routines" qui contient une libraire de CRC dans mon "make menuconfig" favori. La différence n'est-elle que dans le fait que les libraires doivent être chargées dans l'espace d'adressage du noyau (et donc bouffer de la place sans pouvoir être swappées si j'ai bien compris), ou y'a-t-il un truc plus subtil ?

Les *BSD, c'est monolithique. L'approche moitié-moitié est une approche plutôt batarde à mon avis: c'est faire du micro-noyau "pour le style" et bourrer le micro-noyau de choses qui devraient être en dehors... bref, je trouve cette approche pas géniale.

À mon avis, la plus grande avancée du Hurd en terme de design c'est sa souplesse: le code dans le noyau est très très difficile à débugguer, une erreur et c'est le crash fatal. Certes, certains projets tels kksymoops et User Mode Linux (qui permet de lancer un Linux sur un autre) peuvent faciliter la découverte des bugs et leur résolution. Mais il est bien plus simple et propre de ne laisser que le strict minimum dans le noyau. Comme chacun sait, un logiciel compliqué a statistiquement bien plus de bugs qu'un logiciel simple, à compétence de programmeurs égale. Un micro-noyau présente donc une sécurité et une fiabilité théorique bien supérieure à un noyau monolithique style Linux ou *BSD. Ensuite, si tu codes les serveurs (un serveur est une partie de code tournant en espace utilisateur et remplissant les fonctions habituellement contenues dans le noyau monolithique) comme un goret, les trous de sécurité seront légion. En résumé, le Hurd (comme tout micro-noyau) permet en théorie (et à terme) d'accroitre la fiabilité et la sécurité d'un système. J'ai bien dit en théorie... Niveau performances, étant donné qu'il faut plus de changements de contexte (passage espace noyau <-> espace utilisateur), il peut paraître logique qu'un micro-noyau soit plus lent. Néanmoins, certaines études tendent à montrer qu'il est possible de limiter ces pertes au strict minimum, grâce aux communications inter-processus rapides (fast IPC), cf le projet L4 http://os.inf.tu-dresden.de/L4/ Donc, concept intéressant, développement constant, le tout est encore un peu jeune, mais c'est typiquement le moment de tester et d'aider. Pour les vieux, rappelez-vous Linux il y a 8 ou 10 ans...

je remplaçerais "à chaque fois qu'une entreprise ne méprise pas GNU/Linux et ses utilisateurs" par "à chaque fois qu'une entreprise ne piétine pas les standards".
Mais ça serait pinailler, n'est-ce pas ?

En effet, c'est la meme erreur, sauf que je me la suis tapée sur console-tools, et j'ai recherché le paquet console-tools sur la base de bugs.

Pour Sendmail, c'est facile, y'a Postfix (voire exim ou qmail), mais pour Bind ? Maradns est sympa, mais y'avait des petits bugs vraiment chiants dans la résolution récursive quand je l'ai testé y'a qqs mois, peut-etre corrigés. Mais sinon ? Quelles alternatives ?

Quel flemmard ce DAE :-)

C'est nickel ce truc !
Hop, 95 Mo de nettoyés rapidement. Merci :)

J'avais essayé, et ça n'avait pas fonctionné (mais je peux tout à fait m'etre planté). L'explication rationnelle semble fort lointaine...

<i>> Au moins on sait exactement ce qu'on a - et ça fout pas en l'air la gestion des dép vu qu'il y en a pas si on met des choses à la mano.

J'en profite pour vous faire (re)découvrir ces merveilleux outils pour la Debian, j'ai nommé deborphan (à voir sur http://www.tribe.eu.org/deborphan/(...) , il permet de localiser et désinstaller les paquets dont aucun autre ne dépend) et debfoster (à voir sur http://www.fruit.eu.org/debfoster/(...) , permet de ne conserver que les paquets explicitement demandés).

Ces deux logiciels sont apt-gettables (au moins sous Sid). Grace à eux, vous allez pouvoir économiser pas mal d'espace disque...

Ça semble fonctionner. Je ne sais pas par quel miracle, peut-etre qu'en forçant l'install du paquet modifié j'avais reglé la chose qui était la cause de ce problème...
y'a une explication rationnelle ?

Merci :)

Mais non, il parlait de ce formidable éditeur de texte qu'est mcedit !

> Il y a aussi des sociétés qui veulent refaire le cablage de leurs locaux
> et prenant le moins cher, se rendent compte, une fois installé, qu'aucun
> lien filaire n'est en place mais tout est en WiFi. Et ces sociétés peuvent
> avoir des besoins de confidentialité.


Eh oui, y'a des inconscients partout. Personnellement, je pense que si je signais un contrat avec un fournisseur (ici, un câbleur), j'aurais au moins la présence d'esprit de me renseigner sur ce qu'il va exactement faire dans mes locaux... même (et peut-être surtout) si c'est le moins cher !

Ce qui n'est pas forcément totalement anormal... pourquoi changer de format quand celui qu'on utilise fonctionne très bien, et si le format «concurrent» ne fonctionne pas bien ?

Je suppose que le décodage est fait "en entier" (au contraire de "en virgule flottante"), mais je n'ai pas trouvé de précision sur les liens (j'ai pas forcément trop fouillé non plus).

En effet. Personnellement, je déteste le Flash, surtout quand il n'est pas forcément nécessaire. Mais je me permets de rappeler qu'il s'agit ici du site linuxfr.org, dédié à la communauté Linux francophone, et en aucun cas de fsf.org ou autre site dédié au libre uniquement.

D'ailleurs, il me semble bien que BitKeeper, outil utilisé par nombre de développeurs du noyau Linux, n'est pas du tout libre, ce qui montre (ce que certains appellent) le pragmatisme de ces développeurs, qui utilisent les outils qui leur conviennent le plus.

À partir de là, chacun peut avoir sa propre opinion, que ce soit sur l'utilisation de Flash, de BitKeeper, de Linux (qui, je le sais bien, est totalement libre), ou même de mon commentaire pour s'essuyer aux toilettes.

Merde, je sens que ça va finir en gros troll ça...
où est le -1 !!