le code source en français (et pas que les commentaires).
Oui, incontestablement. Mais, quand je m'y suis mis, je ne pensais pas que j'irais si loin...
Cela dit, j'accepte les contributions en anglais, et il y a aussi un avantage à la chose : tant que les interfaces internes du noyau seront en français, il faudra les garder bien documentées. (Honte sur moi, faut que je m'y mette...)
vouloir guider les utilisateurs en limitant les choix (format du gestionnaire de paquets, interface graphique) me parait une bonne chose. Mais j'ai peur qu'avec la licence, cela conduise à des forks et "disperse" donc les forces...
En ce qui concerne le format de paquetage, il y a vraiment des motifs techniques pour n'utiliser que celui-là, parce que la logique des chroots lui est liée. En fait, le système de paquetages utilise l'arbre des dépendances d'un programme pour construire son chroot et ses lanceurs, donc aucun format de paquetage existant ne peut le concurrencer.
Quant à l'interface graphique, je ne pouvais pas accepter X.org : avec son appel-système iopl(2), il met l'ensemble des protections du système par terre (et, accessoirement, il est incapable de gérer l'isolement et les privilèges des applications). Donc, une nouvelle interface sera nécessaire... donc autant l'unifier.
Et puis, les forks... On disait la même chose au début de Linux, alors... :-)
...forces dispersées avec une licence qui, si je l'ai bien comprise (aussi en français), limite drastiquement les échanges de code entre différents projets qui seraient issus de Manux puisqu'il faut l'accord des détenteurs des droits patrimoniaux (cf. les difficultés de changement de licence de VLC).
Hmmm... Oui, effectivement. Cela dit, si ça devenait vraiment gênant, la clause de mise à jour de la licence ne m'interdit pas de supprimer cette disposition. On verra, mais je pense que les avantages dépasseront les inconvénients.
Les 7 octets en langage machine, ne serait-ce pas, par hasard, le passage en mode protégé ? :)
Non, mais pas loin :-) . Il s'agit du code du flot d'exécution inactif et du code pour le lancer; ils sont situés dans le bordereau du gfe. Ils doivent s'y trouver, parce qu'en cas de patchage du noyau, le code du flot d'exécution inactif doit demeurer au même emplacement.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 10.
Oui, incontestablement. Mais, quand je m'y suis mis, je ne pensais pas que j'irais si loin...
Cela dit, j'accepte les contributions en anglais, et il y a aussi un avantage à la chose : tant que les interfaces internes du noyau seront en français, il faudra les garder bien documentées. (Honte sur moi, faut que je m'y mette...)
En ce qui concerne le format de paquetage, il y a vraiment des motifs techniques pour n'utiliser que celui-là, parce que la logique des chroots lui est liée. En fait, le système de paquetages utilise l'arbre des dépendances d'un programme pour construire son chroot et ses lanceurs, donc aucun format de paquetage existant ne peut le concurrencer.
Quant à l'interface graphique, je ne pouvais pas accepter X.org : avec son appel-système iopl(2), il met l'ensemble des protections du système par terre (et, accessoirement, il est incapable de gérer l'isolement et les privilèges des applications). Donc, une nouvelle interface sera nécessaire... donc autant l'unifier.
Et puis, les forks... On disait la même chose au début de Linux, alors... :-)
Hmmm... Oui, effectivement. Cela dit, si ça devenait vraiment gênant, la clause de mise à jour de la licence ne m'interdit pas de supprimer cette disposition. On verra, mais je pense que les avantages dépasseront les inconvénients.
Non, mais pas loin :-) . Il s'agit du code du flot d'exécution inactif et du code pour le lancer; ils sont situés dans le bordereau du gfe. Ils doivent s'y trouver, parce qu'en cas de patchage du noyau, le code du flot d'exécution inactif doit demeurer au même emplacement.