KDE et GNOME sont des assemblages cohérents de libs
Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !
. 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.
Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.
Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)
Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise.
Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)
Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux.
Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).
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.
Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
- "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
- "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
Choisi celle que tu veux moi c'est tout vu :-)
(tant pis pour eux, ils n'auront pas le meilleur de ce monde).
Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...
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é.
Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.
j'aurais tendance à virer la VM (beaucoup de code complexe),
Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)
Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles.
Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...
. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance
Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.
C'est passionnant!
Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)
[^] # Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !
. 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.
Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.
Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)
Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise.
Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)
Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux.
Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).
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.
Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
- "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
- "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
Choisi celle que tu veux moi c'est tout vu :-)
(tant pis pour eux, ils n'auront pas le meilleur de ce monde).
Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...
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é.
Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.
j'aurais tendance à virer la VM (beaucoup de code complexe),
Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)
Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles.
Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...
. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance
Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.
C'est passionnant!
Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)