Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau.
Linux a même déjà eu plusieurs ordonnanceurs "en même temps" (à choisir à la compilation).
Je me demande si la logique avec cfs pour gérer ce niveau de précision, ne devrait pas être que l'application crée des cgroups et dispatche ses threads en fonction. C'est plus souple car tu peu créer des groupes plus adaptés que les niveaux de priorité prédéfini (et tu peux configurer finement leur groupe), par contre c'est à chaque développeur de faire ces choix et effectivement aujourd'hui ça n'est pas pratiqué.
Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
C'est bien sûr faux, ubuntu a une version dédiée bureau et un paquet de ses dérivées ne sont faites que pour le bureau. De même pour RedHat qui a des versions spécifiques pour bureaux, mais je suis d'accord que je n'ai pas l'impression que les distributions bossent véritablement dans ce sens. Sans aller jusqu'à avoir des logiciels réécris pour se comporter comme il faut avec cfs, il est possible déjà de lancer le gestionnaire de fenêtre dans son propre groupe. Ça avait était une super démo technique il y a pas mal d'année maintenant de comment on peut lancer une compilation du noyau en lui donnant beaucoup de thread tout en gardant une interface fluide.
On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul)[...]
Je suis pas certains que ce soit très pratique d'avoir une demande comme ça. C'est pas forcément simple de savoir quoi faire. Mais rendre le gestionnaire de fenêtre non ciblable par l'OOM-killer ce serait vraiment quelque chose de bien.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Je ne remet pas en cause Haiku. Ça n'était vraiment pas mon but. C'est très bien que d'autres chose que linux existent et tenter de faire autrement c'est toujours pertinent, même "en soit".
Mais j'ai l'impression qu'on pourrait déjà faire bien plus avec linux avec un vrai travail plus important pour les distributions orientées desktop (sur la manière de configuré et de compiler linux, systemd, la gestion des sessions, etc) et potentiellement des guidelines sur comment faire correctement des applications graphiques linux.
Je ne sais pas ce qui est plus simple entre faire évoluer un écosystème tel que linux ou créer un écosystème à partir de pas grand chose (pardon pour BeOS, mais leur écosystème me semble relativement petit, non ?).
Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente.
Je pense aussi que certaines décisions au sein de la LKML ont pu refroidir ceux qui se lanceraient. Il me semble qu'à l'époque où cfs a était incorporé il y avait un concurrent techniquement très sérieux mais qui s'est fait sortir pour des raisons qui avait était très discutées à l'époque.
[^] # Re: Incroyable !
Posté par barmic 🦦 . En réponse au journal Coroutines, histoire d'un nouvel inutilitaire.... Évalué à 2.
Linux a même déjà eu plusieurs ordonnanceurs "en même temps" (à choisir à la compilation).
Je me demande si la logique avec cfs pour gérer ce niveau de précision, ne devrait pas être que l'application crée des cgroups et dispatche ses threads en fonction. C'est plus souple car tu peu créer des groupes plus adaptés que les niveaux de priorité prédéfini (et tu peux configurer finement leur groupe), par contre c'est à chaque développeur de faire ces choix et effectivement aujourd'hui ça n'est pas pratiqué.
C'est bien sûr faux, ubuntu a une version dédiée bureau et un paquet de ses dérivées ne sont faites que pour le bureau. De même pour RedHat qui a des versions spécifiques pour bureaux, mais je suis d'accord que je n'ai pas l'impression que les distributions bossent véritablement dans ce sens. Sans aller jusqu'à avoir des logiciels réécris pour se comporter comme il faut avec cfs, il est possible déjà de lancer le gestionnaire de fenêtre dans son propre groupe. Ça avait était une super démo technique il y a pas mal d'année maintenant de comment on peut lancer une compilation du noyau en lui donnant beaucoup de thread tout en gardant une interface fluide.
Je suis pas certains que ce soit très pratique d'avoir une demande comme ça. C'est pas forcément simple de savoir quoi faire. Mais rendre le gestionnaire de fenêtre non ciblable par l'OOM-killer ce serait vraiment quelque chose de bien.
Je ne remet pas en cause Haiku. Ça n'était vraiment pas mon but. C'est très bien que d'autres chose que linux existent et tenter de faire autrement c'est toujours pertinent, même "en soit".
Mais j'ai l'impression qu'on pourrait déjà faire bien plus avec linux avec un vrai travail plus important pour les distributions orientées desktop (sur la manière de configuré et de compiler linux, systemd, la gestion des sessions, etc) et potentiellement des guidelines sur comment faire correctement des applications graphiques linux.
Je ne sais pas ce qui est plus simple entre faire évoluer un écosystème tel que linux ou créer un écosystème à partir de pas grand chose (pardon pour BeOS, mais leur écosystème me semble relativement petit, non ?).
Je pense aussi que certaines décisions au sein de la LKML ont pu refroidir ceux qui se lanceraient. Il me semble qu'à l'époque où cfs a était incorporé il y avait un concurrent techniquement très sérieux mais qui s'est fait sortir pour des raisons qui avait était très discutées à l'époque.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll