Re: Mwai

Ah ben heureusement que t'es la pour accorder le peu de ton temps disponible a lennart et lui donner des conseils, parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense.

« le peu de ton temps disponible », non, ne me fait pas passer pour le chevalier blanc, ni batmand.
« et lui donner des conseils », je ne lui donne pas de conseils, je dis juste comment j'aurais fait, et peut-être comment je ferais.
« parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense. », FUD ? Je crois bien oui...

Bon, maintenant que tu nous a rappele ce qu'on apprends aux etudiants a leur deuxieme cour d'informatique en deug, si tu passais a la vitesse superieure?

Voila. Si tu as la flemme de cliquer, je pourrais résumer assez facilement: « on nous apprend à être des automates de traduction UML vers Java ».

Prend n'importe lequel de ces 80 binaires, et explique nous en quoi son role est mal defini, et ce que tu ferais pour le definir plus precisement, ainsi que comment tu modifierais son interface.

Je veux bien mais cela vas me prendre beaucoup de temps : je le ferais plus tard, quand la motivation sera revenu. Je dit ceci car cela doit faire à peu près 1 heure que j'écris ce commentaire et je commence à saturer.

Oui, c'est sur que quand on remplace des actions concretes par une vague phrase qui ne veut pas dire grand chose, ca parait plus simple.

Okay, tu m'en veux et je ne sais pas pourquoi.

Qu'est ce que tu disais deja sur l'importance d'avoir des roles clairement definis?

L'importance d'un rôle clairement défini, c'est que cela vas directement dans le sens de la fameuse maxime (version courte) : « Écrivez des programmes qui effectuent une seule chose et qui le font bien ». Et si tu veux comprendre pourquoi c'est important, je t'invite avec enthousiasme à lire « The Art Of Unix Programming » (TAOUP). Car non seulement tu trouveras une réponse bien meilleur que ce que j'aurais pu t'écrire, mais aussi parceque cela ne concerne pas uniquement UNIX, mais belle et bien la programmation en général.

D'ailleurs, je ferais bien enseigner la plupart des principes et de la méthodologie présente dans le TAOUP en DUT. Sisi, tu peux d'ores et déjà cliquer sur « inutile », si ce n'est pas déjà fait.

Tant qu'on y est , si tu pouvais nous expliquer en quoi sysv coordone quoi que ce soit, ca serait sympa. De ce que j'en sait, sysv coordonne pas grand chose, il se contente de lancer des scripts dans un ordre defini par l'utilisateur, qui se coordonent tant bien que mal eux meme.

Il est vrai que « coordonner » n'est peut-être pas le meilleur mot, mais tu as parfaitement décrit l'idée : « il se contente de lancer des scripts dans un ordre defini par l'utilisateur ». C'est simple, c'est efficace, ça marche. Comme systemd à ses début. Oh oui, si Lennart et les autres contributeurs avaient cessé d'ajouter des fonctionnalités, je n'aurais rien à dire. En gros avant que systemd ne « mange » udev, systemd faisait son boulot, et rien d'autre.

Et d'ailleurs, en quoi le reseau et /dev ne font pas partie de l'init? Remplir /dev, ca parait etre qq chose d'assez important a l'init quand meme, non? Ca va etre vachement plus dur de demarrer si tes disques ne sont pas dans /dev, tu crois pas?

Lancer le programme qui gère le réseau et le programme qui gère /dev fait partie de l'init, mais gérer le réseau et /dev ne font clairement pas partie de l'init. Si tu comprends toujours pas alors je ne vois vraiment pas comment l'expliquer. C'est la différence qu'il y a entre « lancer » (ou exécuter) et « gérer ».

Et demarrer tes services reseaux, ton pare feu et ce genre de choses, ca marcherait pas un chouilla mieux apres que tes interfaces reseaux soient montees?

Sisi, d'ailleurs c'est à cela que servent les systèmes d'init normalement : gérer l'ordre de lancement des programmes, comme tu l'as si bien décrit plus haut.