Gaël Le Mignot a écrit 812 commentaires

un mail ou un fichier renferment des informations de meme nature.

C'est ce que j'ai toujours dit: vive mboxfs ( http://people.type-z.org/ludo/hurd/README-mboxfs(...) , http://people.type-z.org/ludo/hurd/(...) ) ! :)

Un exemple très simple : programmez réseau en C ; vous passez votre vie à vérifier des codes de retour. Passez à un langage avec exceptions, si vous avez pas envie de trapper, vous trappez pas et ça se banane direct à le première erreur, ça va pas continuer avec un 0 ou un -1 dans une variable pour aller vous bousiller un fichier.

Bizarre, quand je programme réseau en C, en général j'utilise une lib comme ma netlib (faite une fois pour toute) qui utilise un méchanisme de callback (via pointeurs de fonctions) pour justement éviter d'avoir à tester les codes de retour... Sinon y'a aussi le méchanisme GError, enfin, tu as pas mal de solutions en C pour gérer les choses de manière plus jolie et agréable...

Par contre l'OS peut fournir des moyens de sécuriser les applications, via un modèle de sécurité fin et bien pensé...

En particulier pour tout ce qui est "connecté au monde", c'est à l'OS de fournir les méchanisme pour permettre aux applications de se protéger d'elles-mêmes (par exemple, un serveur FTP n'a pas à tourner en root, et un layout-engine n'a pas à tourner avec des privilèges quels qu'il soient).

Sur ce sujet je vous conseille des articles comme "Operating System Protection for Fine-Grained Programs" ( http://www.l4ka.org/publications/files/os-protection.pdf(...) )

Heu, je tiens à corriger un peu... Certes, le sigle VM peut signifier deux choses: Virtual Memory ou bien Virtual Machine.

Une Virtual Machine, c'est, comme son nom l'indique, une machine virtuelle, comme une machine virtuelle Java ou certains types d'émulateurs (émulateur HP48, ...) ou de debugers (valgrind).

La Virtual Memory, c'est le nom que l'on donne à la partie de l'OS qui gère la mémoire virtuelle des programmes, et donc en particulier le swap, le cache disque, le mappage de fichiers en mémoire, ...

Par contre, il n'y a aucun lien direct entre les deux, et très peu d'OS implémentent une Virtual Machine.

Hein ? Qu'est-ce que j'ai avoir avec ça moi ? Pour moi, à partir du moment ou aucune ambigüité n'est possible, et où l'appellation n'induit pas en erreur qui que ce soit, qu'on utilise une appellation ou une autre, je m'en balance plus que du sort des loutres belges bourrées à la bière dans les déserts de Sibérie par une nuit de pleine lune !

Je vous conseille de lire tout d'abord un bon livre d'OSDev qui explique ce que sont les "context-switches" et comment cela fonctionne (tel que Modern Operating Systems d'Andrew S. Tanenbaum).

Ensuite, si vous voulez vous tenir au courant des dernières avancées de la recherche en OSDev pour réduire le coût des changements de contexte, il existe de très bon articles là-dessus faits par l'épique de L4Ka: http://www.l4ka.org/publications/(...) en particulier: Performance of Address-Space Multiplexing on the Pentium, Lazy Process Switching, Improved Address-Space Switching on Pentium Processors by Transparently Multiplexing User Address Spaces et Lazy Context Switching Algorithms for Sparc-like Processors (les autres sont très intéressant aussi).

Le noyau 2.4 consomme plus de swap, ce qui sur une machine avec un disque LENT n'est pas du tout une bonne idée.

Quel noyau 2.4 ? La VM (gestion de la mémoire) du 2.4 a été complètement modifiée avec le 2.4.10. Il y a 3 VMs pour le 2.4:
* la VM de rik originale (2.4.0=>2.4.9)
* la VM d'Andrea (2.4.10=>2.4.20pre...)
* la VM -rmap (-ac récents, -mjc)

Pour chacune, il y en a plusieurs variantes. Donc parler du "noyau 2.4" en ce qui concerne la gestion de la mémoire, ça n'a pas beaucoup de sens.

La VM -rmap, en théorie tout du moins, permet de choisir plus vite et plus précisément quelle page "virer" de la mémoire lorsqu'il est nécessaire de swapper, et profite donc plus aux machines qui ont en besoin. De plus, elle permet de trouver plus facilement des pages dans une zone donnée de la mémoire (comme une page dans les 16M pour le DMA des cartes ISA, et la encore, ce sont les vieilles machines qui en profitent).

Hum, du calme, du clame...
1/ Le facteur 100 dont ils parlent, c'est par rapport au pacth -mm1 qui dans certains cas créait des congestions, pas par rapport au noyau 2.4...
2/ Le gain n'est visible qu'à très haute charge
3/ Il faut toujours se méfier des benchmarks, on peut faire dire ce qu'on veut à un benchmark... En particulier, dbench, est très spécifique...

Alors, oui, c'est bien, mais relativisons et essayons de comprendre au lieu de crier des chiffres comme ça...

La différence c'est que Phoenix est en XUL et donc cross-platform, contrairement aux autres gecko-allégés (galeon, skipstone, k-meleon); ce qui peut être un gros avantage dans un parc hétérogène ou pour faciliter une transition.

Pour l'instant, je ne pense pas que ce soit facilement possible... Mais il faut voir que ce n'est qu'une 0.1 de Phoenix (et il manque pas mal de fonctionnalités d'ailleurs). Ensuite, ça dépendra plus de la manière dont ce sera packagé par la distribution je pense... Je verrai bien un mozilla-common pour mozilla/galeon/phoenix et ensuite un mozilla, galeon ou phoenix qui utilise le gecko contenu dans mozilla-common... Techniquement, c'est faisable. Maintenant je ne sais pas à quel point c'est complexe, ni si ce sera fait par telle ou telle distribution.

Le O(n) permet de ne pas avoir à évaluer la constante qui est devant le 'n'. Ainsi que tous les autres, j'en convient. Si ton algorithme est en O(n^2), les termes en n, nln(n) ou autres ne sont pas intéressant pour la complexité. Mais le 'C' change d'un algo à un autre Ben non, on calcule la complexité d'un algo. Par contre, C change suivant l'implémentation de l'algo, par exemple. Ta complexité est toujours 'n' Ta complexité n'est pas 'n', mais 'O(n)' Par contre, le nombre de tes opérations pour un algorithme précis va tendre vers 'n'. Non. 1/ on parle de la complexité d'un algorithme, donc c'est forcément la complexité d'un algorithme précis 2/ le nombre d'opérations ne tend pas vers, mais r(n) = nbop(n) / n va tendre vers un réel k non nul

La complexité d'un algorithme est calculée quel que soit 'n'. hum ? Le problème du tri a une complexité en O(n.log(n)) certes, mais là je parlais de la complexité d'un algorithme, pas d'un problème. Donc mon exemple est bon. Je crois fermement que vous confondez votre cours de math sur les développements limités et votre cours d'info sur la théorie de la complexité. ;-) Ben vu que c'est la même chose...

Non, là je crois que tu mélanges les notions de limites en O(.) et la notion de complexité... :-/ C'est _exactement_ la même chose. Dire qu'un algorithme est en O(n) c'est dire que la suite qui représente son temps d'exécution moyen (ou en pire cas) est un O(n) au sens mathématique du terme.

Cela dit, il est important de se rendre compte que lorsqu'on parle de O(.) on parle de complexité au pire et non pas en moyenne. Cf mon autre commentaire, non, il y a plusieurs complexités pour un même algorithme: complexité en temps ou en espace mémoire, et complexité en pire cas ou en moyen cas. Ce que l'on appelle usuellement la complexité tout court, c'est la complexité moyenne en temps, qui est celle qui est la plus souvent utilisée. La complexité en pire cas n'est rellement utilisée qu'en temps réel ou ce qui compte ce n'est pas d'avoir un algo globalement performant, mais de pouvoir dire "on peut garantir que le résultat sera disponible à temps".

En general aussi, on s'arrete la et on note direct O(e^n) pour dire exponentiel (mauvais). oulàlàlà... Tu connais un algo de multiplication de matrice en moins que O(n^2) ? Pourtant, ils sont loin d'être en exponentiel ! (le meilleur connu est on O(n^2.8) IIRC)... Ensuite, même un algo exponentiel, ben euh... O(2^n) c'est pas égal à O(e^n). O() c'est une notation mathématique qui a une définition exacte, merci de l'utiliser avec la rigueur qui convient.

Pourquoi 'n' devrait-il etre "suffisamment grand" ? Ça, ça vient de la définition mathématique de O(). Si tu as un algo qui prend n^4+500*n^3, il est O(n^4), pourtant pour n=10, c'est le 500*n^3 qui compte. Il s'agit de la complexité dans le pire cas. C'est toujours vrai. Euh, pas toujours, non. L'algo de tri rapide, par exemple, est O(n^2) en pire cas, mais O(n ln(n)) en moyen cas. Et on le considère souvent comme un algo en O(n ln(n)) parce que sauf dans les applis temps réel, c'est plus la complexité en cas moyen qui nous intéresse.

Je conseillerai plutôt le "Modern Operating Systems, 2nb edition" d'Andrew S. Tanenbaum, qui est plus complet, plus précis et plus exhaustif... "Le noyau Linux" est pas mal, mais trop Linux-centrique je pense pour quelqu'un qui débute en OS Dev.

Un tri en O(n), je doute, un tri basé sur des comparaisons c'est minimum O(n*ln(n)) (ça se démontre). La complexité tu la calcules en analysant l'algo. Par exemple, un tri par fusion: * tu découpes ton tableau en 2 * tu tries chacune des deux moitiés * tu fusionnes les deux Fusionner les deux, ça prend O(n) comparaisons. Donc t(n) = 2 * t(n/2) + n . Ensuite tu as un simple problème de maths. n lg(n) = n lg (n/2) + lg(2) n = 2 * ( n/2 lg (n/2)) + lg(2) n = 2* (n/2 lg (n /2)) + n donc n lg(n) vérifie bien la relation de récurence, donc t(n) = n lg (n) (théorème d'unicité des suites récurentes avec conditions initiales (t(1) = 0)) J'espère que mes explications sont assez claires, mais le principe c'est ça. Bon, il manque un peu d'exactitude mathématiques, mais c'est pas le sujet.

mwais, bon, pour la notion de processus (je préfère dire tâche) et de thread, je vous conseille les défintions données dans le Mach Kernel Principles qui les explique très clairement AMHA: ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps. Je préfère voir ça comme deux choses distinctes: une tâche est une collection de ressources (espace d'addressage, fichiers ouverts, ...) dans laquelle s'exécute un plusieurs threads. Le problème, c'est que ce scheduleur doit essayer d'éviter les deadlocks entre les threads Ben, malheureusement, les algorithmes pour éviter les deadlocks sont loin d'être parfaits, et peu utilisables en pratique... Linux ne fait _rien_ pour éviter les deadlocks. Si je fais pthread_mutex_lock (mutexa); pthread_mutex_lock (mutexb); dans un thread et pthread_mutex_lock (mutexb); pthread_mutex_lock (mutexa); dans un autre, avec un peu de mal chance, mes deux threads vont être en deadlock, et Linux ne fera rien pour tenter de les sauver. Évidemment, lorsqu'on utilise des threads comme brique de base, il faut pouvoir commuter rapidement d'un processus à un autre Ben justement, non, la commutation de threads c'est beaucoup plus simple que la commutation de processus... changer de thread, c'est très simple, et ça peut même être fait uniquement en user-space (cf L4 et http://www.l4ka.org/publications/files/lazy-process-switching.ps ). C'est l'un des problèmes du noyau Linux actule où les notions de thread et de processus sont légèrement confondus (il n'y a pas de thread au sens propre, mais des processus pouvant partager certaines ressources, dont l'espace d'addressage).

Sur Solaris, on a la possibilité de mettre des "priorités" à des processus Avec l'ordonnanceur de Linux aussi, il y a deux choses différents: la "classe" du programme (temps-réel ou timesharing, seul un process tournant en root peut demander à être "temps-réel") et la "gentillesse", une valeur de -20 à 20 (0 à 20 pour les utilisateurs non privilégiés) (man nice, man renice, man setpriority)

ps: bon ok faut pas s'affoler, la route est encore longue avant de trouver un Linux 2.6 chez l'epicier du coin. Je rappelle à ce propos que le "feature freeze" est prévu pour Halloween, après il n'y aura plus que des bug fixes ou des ajouts mineurs, le noyau 2.6 devrait donc arriver dans un délai raisonnable (quelques mois après le feature freeze je pense). Mais comme tous les noyaux, il sera préférable d'attendre un peu avant d'upgrader là où c'est sensible... les 2.x.0 n'ont pas toujours été parfaits ;p

Ça dépend lesquels, on prend pas tous les mêmes drogues... moi je fais pas trop dans l'alcool personnellement... enfin, ça dépend des Hurdistes, on est tous des drogués, mais pas pareil ;p

-1

Mais c'est justement cette erreur de conception que l'on critique. Et oui, c'est bien une erreur. Certes, il existe un moyen de la contourner, mais à la base il s'agit bien d'une erreur de conception qui aurait pu être évitée sans trop de coût, et qui aurait permis plus de choses (comme on peut le faire sous X, avec des programmes de différents utilisateurs sur le même serveur X).

Heu, honnètement, remplacer du "suidé root" par du "dans le noyau" c'est loin d'être génial niveau sécurité, bien au contraire; sans compter les coûts des appels systèmes...

Quand une app root ouvre un socket, aucun mecanisme dans l'OS ne verifie qu'elle n'accepte pas des commandes de n'importe qui

iptables -A OUTPUT -m owner --uid-owner 0 -d ! <IP autorisés> -j DROP
et hop, mon OS il vérifie que root n'envoie pas de paquets à n'importe qui.
Et si, il peut le faire.

Le problème là, est qu'une application non-root puisse donner des ordres à une application root. Le work-around, la grosse rustine, c'est d'empêcher toute communication (donc pas de GUI). La solution élégante, puissante, et qui est une vrai solution, aurait été dés le début de contrôller ces messages, d'avoir un méchanisme d'IPC intelligent, flexible et sécurisé.