Pour préciser, les choses, j'ajoute un autre commentaire.
J'aimerais un jour que tu arrêtes de répondre en considérant qu'il y a une vérité, avec des gens qui ont raison et des gens qui ont tord, et que tout le monde est con quand il ne pense pas comme toi. Je ne suis pas anti-systemd mais je considère que j'ai quand même le droit d'avoir une opinion sur la manière de développer des logiciel (relis le titre). Et si tu ne penses pas que le fait qu'un logiciel soit écrit en C soit un problème, soit. Mais admets quand même que certains puissent le penser, et je te prie d'arrêter de prendre ce ton hautain quand tu réponds à mes commentaires (et ceux des autres si possible). Tu aurais pu me demander pourquoi je considérais ça comme un problème au lieu de répondre comme si je venais de proférer la pire merde de l'histoire du monde et de troller inutilement.
Le C est quand même un langage très très faible au niveau du typage et de la sureté qu'il apporte. Il est très simple d'ajouter des failles et des bugs dans un code en C. Si tu relis mon commentaire précédant, tu te rendras compte que je disais qu'a mon avis, un logiciel écrit en C ne devrait pas avoir ce genre de design monolithique. En effet, la surface d'attaque et de bugs est plus grande. De plus, en re-codant divers services, il y a plus de chance d'introduire de nouveaux bugs alors que réutiliser du code existant est potentiellement plus fiable et plus simple, car le code a été utilisé pendant des années et a plus de chance d'être stable. Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent. POur unix, ça revient à séparer le code en plusieurs processus qui ont différente permission, et à communiquer via l'IPC, essentiellement des pipes ou des sockets unix. Maintenant, si tu considères que ça n'est pas souhaitable, dis moi pourquoi au lieu de troller.
[^] # Re: Mon opinion sur systemd
Posté par Enj0lras . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 5.
Pour préciser, les choses, j'ajoute un autre commentaire.
J'aimerais un jour que tu arrêtes de répondre en considérant qu'il y a une vérité, avec des gens qui ont raison et des gens qui ont tord, et que tout le monde est con quand il ne pense pas comme toi. Je ne suis pas anti-systemd mais je considère que j'ai quand même le droit d'avoir une opinion sur la manière de développer des logiciel (relis le titre). Et si tu ne penses pas que le fait qu'un logiciel soit écrit en C soit un problème, soit. Mais admets quand même que certains puissent le penser, et je te prie d'arrêter de prendre ce ton hautain quand tu réponds à mes commentaires (et ceux des autres si possible). Tu aurais pu me demander pourquoi je considérais ça comme un problème au lieu de répondre comme si je venais de proférer la pire merde de l'histoire du monde et de troller inutilement.
Le C est quand même un langage très très faible au niveau du typage et de la sureté qu'il apporte. Il est très simple d'ajouter des failles et des bugs dans un code en C. Si tu relis mon commentaire précédant, tu te rendras compte que je disais qu'a mon avis, un logiciel écrit en C ne devrait pas avoir ce genre de design monolithique. En effet, la surface d'attaque et de bugs est plus grande. De plus, en re-codant divers services, il y a plus de chance d'introduire de nouveaux bugs alors que réutiliser du code existant est potentiellement plus fiable et plus simple, car le code a été utilisé pendant des années et a plus de chance d'être stable. Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent. POur unix, ça revient à séparer le code en plusieurs processus qui ont différente permission, et à communiquer via l'IPC, essentiellement des pipes ou des sockets unix. Maintenant, si tu considères que ça n'est pas souhaitable, dis moi pourquoi au lieu de troller.