Oué, sa c'était la philosophie d'il y a 30 ans. Heuresement les mentalités évoluent.
KDE ou GNOME sont des grosses plateformes qui dans la philosophie Unix ne devrait pas exister, rappel toi, normalement tous les softs devraient être des jolis exécutables qui discutent avec des pipes...
Les mentalité changent, des bonnes recettes restent et on refait les mêmes erreurs...
KDE et GNOME sont des assemblages cohérents de libs. gnome va essayer de dropper corba car bien trop complexe pour les tâches d'un desktop (overkill). En effet, un des fondateurs a fait ce mauvais choix, mais avec lui c'est en train de devenir une habitude. Le but de ces projets est de fournir le service "desktop" pour utilisateur normal. Le service desktop est indépendant de xorg qui gère l'affichage. KDE,gnome et d'autres se fédèrent autour de freedesktop pour que la miriades d'éléments composant l'offre des desktops puissent intéropérer malgré leur différence dans les choix d'implémentation. Si ce projet réussi, à terme on pourra "composer" un desktop cohérent avec un certain degré de liberté... rien de plus normal pour du libre et dans le cadre de la philosophie unix.
Je suis sûr un site consacré à GNU Linux, et GNU is NOT Unix ! :-p
Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
C'est bon merci, je suis pas con, j'ai même argumenté derrière en expliquant pourquoi je préfère largement que les services les plus courants qui nécessite d'être codé avec un langage de bas niveau (gestion mémoire toussa) le soit une fois pour toute dans la VM, codée par des personnes compétentes, et que le jour où une faille de sécu est corrigée, toutes les applis qui tournent dessus en profite !
Ta VM tourne un OS. Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise. Déléguer la gestion mémoire, ou gérer plus finement sa gestion mémoire, c'est un choix (du moins tant qu'on te le laisse... huhu...). Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux. Mais bon, le meilleur compromis seraient que les codeurs s'intéresse un peu plus à la sécu pour coder au mieux "secure" tout en conservant une gestion fine de leur besoin de mémoire.
T'es incorrigible, t'es toujours pareil, dès que tu cherches un atout, tu le cherche dans une autre brique. Evidemment que Erlang permet de faire du réparti, c'est fait pour. Mais en attendant Erlang ne propose pas une plateforme aussi complète que Java ou .NET.
On m'a dit qu'Erlang était conçu dans le but de faire de l'informatique réparti pour les télécom et de le faire bien, et que pour pouvoir faire au mieux, il possédait une sémantique/syntax adaptée, ce que les autres langages n'offrent pas (tant pis pour eux, ils n'auront pas le meilleur de ce monde).
Ah oui, y'a la vraie gestion mémoire et la fausse... En attendant ton OS favori il a vraiment du mal à gérer les débordement tampons et les fuites mémoires. Moi je fais confiance au modèle de sécurité des VM modernes et à leur GC bien plus sécurisés que mes malloc.
Je parlais de la mémoire (allocation de page physique), pas de la gestion mémoire... pas grave, ct ambigüe. Sinon, je te renvois au paragraphe au dessus concernant la sécurité de la VM. Une règle général en sécurité: plus tu as de code, modulé par sa complexité, plus tu as de risques d'avoir des failles de sécurité. Donc pour réduire les risques de failles, j'aurais tendance à virer la VM (beaucoup de code complexe), simplifier au maximum le code et me concentrer sur les failles de l'OS.
Je voulais te montrer que dans la vraie vie avec des vraies applis, on ne peut se contenter de l'interpréteur Python de 5000 lignes, et que Zope fait plus de 5000 lignes pour être un minimum performant.
Tout ce je sais, c'est que j'ai pas sortie l'énormité que Zope avait 5000 lignes de code. Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles. Le C est là pour la performance et/ou abstaire les services de l'OS/libs de base plus "pythoniquement". En effet, dans certains cas, abstraire ces derniers services en C et bien plus efficace que de le faire en python (qu'avec des appels directs aux fonctions des services de bases) ou que d'alourdir et complexifier l'interpréteur en y ajoutant de nouveaux opcodes.
Oué et je joue au mécano ? Comment j'assemble tout ca ? Qui va s'assurer que mon assemblage ne va pas être bourré de trous de sécu ? Nan parcque moi je suis un simple développeur/Architecte, je suis pas un guru de la sécu.
Et puis bon, qui va résoudre tous mes problèmes d'intégration et de déploiement, nan parcque déployer une appli dont le coeur est codé en C/C++, le serveur d'application en erlang, les pages web en PHP, les clients lourds en Qt et les scripts en Perl, merci ! T'es à 15000 km des réalités du développement de grosses solutions toi c'est pas possible.
En général, tu as des entreprises qui offrent des audit de sécurité et qui peuvent fournir du conseil en sécu. Les composants exposés à des attaques réelles pourront être audités et le développement pourra être assisté par un consultant en sécu. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance (qui continue de se propager) de manière noble, cad pas par des campagnes de pub/com. Perso, les applications les plus gourmandes dont j'ai entendu parlées ont été re-écrites en langage machines. Cela dit, les solutions les plus hétérogènes que j'ai pu voir étaient des solutions qui avait vieilli sur des années, récupérant diverses technologies de divers âges au fur et à mesure de leur évolution fonctionnelle. C'est passionnant!
[^] # Re: Former des développeurs Python/Zope compétents
Posté par sylware . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à -2.
Les mentalité changent, des bonnes recettes restent et on refait les mêmes erreurs...
KDE et GNOME sont des assemblages cohérents de libs. gnome va essayer de dropper corba car bien trop complexe pour les tâches d'un desktop (overkill). En effet, un des fondateurs a fait ce mauvais choix, mais avec lui c'est en train de devenir une habitude. Le but de ces projets est de fournir le service "desktop" pour utilisateur normal. Le service desktop est indépendant de xorg qui gère l'affichage. KDE,gnome et d'autres se fédèrent autour de freedesktop pour que la miriades d'éléments composant l'offre des desktops puissent intéropérer malgré leur différence dans les choix d'implémentation. Si ce projet réussi, à terme on pourra "composer" un desktop cohérent avec un certain degré de liberté... rien de plus normal pour du libre et dans le cadre de la philosophie unix.
Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
Ta VM tourne un OS. Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise. Déléguer la gestion mémoire, ou gérer plus finement sa gestion mémoire, c'est un choix (du moins tant qu'on te le laisse... huhu...). Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux. Mais bon, le meilleur compromis seraient que les codeurs s'intéresse un peu plus à la sécu pour coder au mieux "secure" tout en conservant une gestion fine de leur besoin de mémoire.
On m'a dit qu'Erlang était conçu dans le but de faire de l'informatique réparti pour les télécom et de le faire bien, et que pour pouvoir faire au mieux, il possédait une sémantique/syntax adaptée, ce que les autres langages n'offrent pas (tant pis pour eux, ils n'auront pas le meilleur de ce monde).
Je parlais de la mémoire (allocation de page physique), pas de la gestion mémoire... pas grave, ct ambigüe. Sinon, je te renvois au paragraphe au dessus concernant la sécurité de la VM. Une règle général en sécurité: plus tu as de code, modulé par sa complexité, plus tu as de risques d'avoir des failles de sécurité. Donc pour réduire les risques de failles, j'aurais tendance à virer la VM (beaucoup de code complexe), simplifier au maximum le code et me concentrer sur les failles de l'OS.
Tout ce je sais, c'est que j'ai pas sortie l'énormité que Zope avait 5000 lignes de code. Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles. Le C est là pour la performance et/ou abstaire les services de l'OS/libs de base plus "pythoniquement". En effet, dans certains cas, abstraire ces derniers services en C et bien plus efficace que de le faire en python (qu'avec des appels directs aux fonctions des services de bases) ou que d'alourdir et complexifier l'interpréteur en y ajoutant de nouveaux opcodes.
En général, tu as des entreprises qui offrent des audit de sécurité et qui peuvent fournir du conseil en sécu. Les composants exposés à des attaques réelles pourront être audités et le développement pourra être assisté par un consultant en sécu. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance (qui continue de se propager) de manière noble, cad pas par des campagnes de pub/com. Perso, les applications les plus gourmandes dont j'ai entendu parlées ont été re-écrites en langage machines. Cela dit, les solutions les plus hétérogènes que j'ai pu voir étaient des solutions qui avait vieilli sur des années, récupérant diverses technologies de divers âges au fur et à mesure de leur évolution fonctionnelle. C'est passionnant!