Pour le moment je continue faire "confiance" à Mozilla mais ça me turlupine.
Pourquoi pas un rapprochement de Mozilla et de Xorg via une intégration dans SPI ! Xorg était sur le point d'intégrer le SPI mais ça a foiré de peu et je ne sais plus pourquoi mais c'était pas vraiment la volonté des participants. Au final, on le voit avec FirefoxOS, Firefox joue petit à petit le même rôle que X…
Si tu veux, en plus les détails d'implémentation varient selon les OS ;-) En pratique, on ne trouve pas de malloc dans du code C en mode noyau. J'ai pris exprès l'exemple de malloc car c'est vraiment l'instruction que tu vois très rapidement lorsque tu débutes en C ET qui n'est pas une vraie primitive du langage (comme printf…).
Il me semble que ce que tu décris est du passé, non sur la partie non libre ou il est clair que la FSF ne pousse pas au non libre (et ils n'ont pas tord) mais l'architecture de GCC a été fortement ouverte ces derniers temps et j'ai vu des greffons arriver sur cette plate-forme qu'on ne voyait que sur LLVM.
On voit que GCC évolue lui aussi et que la dernière version, 5.1, permet par exemple le JIT. Bref, il est désormais possible d'envisager une machine virtuelle dans GCC comme cela se fait sous LVVM.
L'équipe de Rust envisage t-elle un portable sur GCC ?
Il est tout a fait possible d'enlever des anciennes fonctionnalités à des langages. Cela se fait via des annonces d'obsolescence dans une norme avant de l'enlever effectivement dans la norme suivante (si aucun biais n'a été trouvé entre temps). C'est ainsi que fait par exemple Fortran qui est toujours là malgré son grand âge…
C'est justement ma question. Quelqu'un a t-il déjà fait une étude permettant de dégager une ou plusieurs stratégies plus ou moins adaptées au contexte du projet ou, par exemple, la stratégie de la licence n'a que peu d'influence devant le charisme de l'équipe, l'effet de groupe… autour du projet ?
Mais d'un autre côté, il faut se mettre à leur place. Ils gagnent de l'argent en vendant leur licence entreprise, et il faut bien qu'elle garde des avantages par rapport à la version gratuite.
A t-il été montré, via par exemple un certain nombre de projet, que cette stratégie est la bonne ? La stratégie du tout libre améliore grandement la diffusion du projet et n'empêche pas nombre d'entreprise de prendre du support. Les deux modèles existent donc.
Parce qu'on installe sous /opt/VENDOR ;-) Autant faire un /vol qu'un /opt/shared… En pratique, selon les postes, j'aurais aimé installer en local ou faire un montage NFS. Exemple : un noeud de calcul -> montage NFS, un portable utilisateur -> copie locale. /opt/shared, ça donne l'impression qu'on est en partagé…
Et puis on retombe toujours dans le même problème, si ce dossier devient populaire, il y aura un couillon qui fera un paquetage qui utilise ce chemin…
Sur un cluster par exemple, tu n'as pas forcément envie d'installer Matlab, Ansys… en local sur chaque poste. Tu as donc bien envie de les mettre sur /opt et de partager/monter ce dossier via NFS (voir monter en lecture seule). Or des paquetages écrivent sous /opt donc le dossier est difficilement partageable via NFS car quels noeuds va écrire dessus si tu déploie ton paquet ? Et si tu supprimes le paquet, c'est le merdier…
Bref, le seul moyen est de trouver un nom que pas grand monde utilise, genre /vol ou /mysoft et d'utiliser ce dossier à la place de /opt… C'est dommage car le premier paquetage qui écrira dessus cassera tout. Faut donc avoir un nom de dossier qui ne devienne surtout pas populaire !
En conclusion, la seule solution, à mon avis, serait que les gestionnaires de paquetages interdisent un dossier racine. Cela aurait du être /opt mais comme c'est trop tard à mon grand regret, il faudrait en trouver un autre et qu'ils se mettent tous d'accord pour l'interdire effectivement.
On interdit le montage de /opt par NFS en autorisant les gestionnaires de paquetage d'écrire dedans. Les paquets crades devraient à la rigueur écrire sous /usr/local qui est de toute manière crade. Sinon, il n'y a aucun soucis pour mettre /usr/local sous un autre volume que /usr… j'ai pas bien compris tes arguments sur ce point.
Yep ;-) Il faut noter qu'un certain nombre de développeurs Debian arrête de réellement être développeurs au bout d'un certain temps, notamment pour des raisons de contrainte familliales…
Dans le cas de la LTS, cela ne pouvait se faire sur du bénévolat et/ou en parallèle de son boulot donc une équipe s'est monté qui essaye d'en faire son boulot (à temps très partiel). Peut être que si la LTS a beaucoup de succès, le modèle économique pourra être étendus.
En fait, toutes les Debian seront /a priori/ des LTS ;-) Il faut deux ans pour sortir une Debian en moyenne + 1 an de recouvrement + 2 ans par l'équipe LTS sur un sous ensemble de la Debian.
Donc 5 ans mais pas sur tout. A noter que l'équipe LTS a besoin de manger le soir ET de s'occuper des enfants qui feront la Debian de demain… Il faut donc les aider sinon le projet ne pourra pas continuer. Le succès de LTS est important et il faut noter que c'est beaucoup moins cher qu'une licence RHEL. Voir https://wiki.debian.org/LTS
Par exemple, j'aime pas qu'on ne puisse pas avoir un recouvrement lors du changement de certificat. Ainsi, on pourrait avoir une chaîne de confiance dans la durée plutôt que par le haut. La dernière version de SSH implémente enfin cela.
On pourrait implémenter des certificats GPG et se baser sur cette chaîne de confiance. On pourrait alors décider de faire confiance aux amis de Google ou d'Amazon ou … autres et avoir ainsi une autre forme de chaîne indépendant des éditeurs de certificats SSL, une chaîne que chacun pourrait adapter à ses besoins…
Bref, cette chaîne SSL n'est pas top top mais je ne sens pas de grande motivation pour aller vers un système plus décentralisé.
Il y a des personnes du W3C à l'INRIA de Grenoble. J'en ai croisé un une fois en formation…
De toute façon je ne sais pas si distinguer les contributions INRIA et CNRS a vraiment du sens
Si, le CNRS est beaucoup plus gros ;-) En fait, le CNRS est un EPST un peu particulier car il est fusionnel avec les universités. La recherche universitaire en France est assez particulière en cela. Cela me semble bien moins le cas de l'INRIA (que je connais pas super bien) où les chercheurs me semblent suivre une hiérarchie parfois plus proche du CEA (fonctionnement par projet piloté par le haut) que de l'autonomie quasi totale que l'on a à l'université (d'ailleurs, je ne sais pas si la majorité des chercheurs INRIA sont dans des unités propres ou sont disséminés dans des UMR comme les CNRS ?). Par ailleurs, beaucoup de personne au CNRS font du code mais dans des domaines pas du lié à l'informatique…
Je vois Erlang et tout un tas de truc pas spécialement INRIA… Que l'INRIA participe est logique mais la plupart de ces paquetages ne sont pas portés par l'INRIA comme le sont OCaml et Scilab… Par exemple, David Tschumperlé, leader du projet Cimg/G’MIC travaille au GREYC, une UMR, et il est CNRS si mes souvenirs sont bons (http://opensource.graphics/about/).
Quand je consulte wikipedia, je me fiche d'être en http ou https… Il y a tout plein de site dont on se fiche éperdument que les données soient chiffrées. Que cela n'empêche pas de les proposer en deux versions mais il peut être très pratique de laisser une version en http dont on est assurer qu'elle soit en lecture seule (pas de password qui passe par là).
Le problème pour moi viens de l'authentification et des cookies. Je propose de virer les champs cachés ainsi que les cookies d'http, surtout les cookies. De plus, on limite les en têtes afin de revenir a seulement quelques champs simple et on vire tout le reste. On aura ainsi du http pour des sites simples sans authentification et on chiffre lorsque c'est nécessaire. Ainsi on est plus serein coté client mais aussi coté serveur. Quand on fait du http, on n'aura pas de mot de passe du trousseau ou des cookies qui pourront se balader. Le https n'empêche absolument pas de se faire tracer SAUF qu'on croit que tout est clean…
En passant mais non directement liée, quel est le surcoût électrique du TLS actuellement ?
Bref, je milite pour du http en read-only ! Moi, je veux consulter google en http et que cet enfoiré ne compile pas tout cela dans mon compte gmail;-)
[^] # Re: Plutôt bonne nouvelle en fait.
Posté par Sytoka Modon (site web personnel) . En réponse au journal La publicité ciblée s'invite chez Firefox. Évalué à 1.
Pourquoi pas un rapprochement de Mozilla et de Xorg via une intégration dans SPI ! Xorg était sur le point d'intégrer le SPI mais ça a foiré de peu et je ne sais plus pourquoi mais c'était pas vraiment la volonté des participants. Au final, on le voit avec FirefoxOS, Firefox joue petit à petit le même rôle que X…
[^] # Re: Rythme de mise à jour oO
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
Tiens, en voila un qui sors une version tous les mois ;-)
http://rakudo.org/how-to-get-rakudo/
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Si tu veux, en plus les détails d'implémentation varient selon les OS ;-) En pratique, on ne trouve pas de malloc dans du code C en mode noyau. J'ai pris exprès l'exemple de malloc car c'est vraiment l'instruction que tu vois très rapidement lorsque tu débutes en C ET qui n'est pas une vraie primitive du langage (comme printf…).
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Comment ton programme peux avoir de la mémoire sans demander au noyau ? Voir par exemple https://fr.wikipedia.org/wiki/Appel_syst%C3%A8me
[^] # Re: Rust over GCC
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 7.
Il me semble que ce que tu décris est du passé, non sur la partie non libre ou il est clair que la FSF ne pousse pas au non libre (et ils n'ont pas tord) mais l'architecture de GCC a été fortement ouverte ces derniers temps et j'ai vu des greffons arriver sur cette plate-forme qu'on ne voyait que sur LLVM.
# Rust over GCC
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
On voit que GCC évolue lui aussi et que la dernière version, 5.1, permet par exemple le JIT. Bref, il est désormais possible d'envisager une machine virtuelle dans GCC comme cela se fait sous LVVM.
L'équipe de Rust envisage t-elle un portable sur GCC ?
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.
Il est tout a fait possible d'enlever des anciennes fonctionnalités à des langages. Cela se fait via des annonces d'obsolescence dans une norme avant de l'enlever effectivement dans la norme suivante (si aucun biais n'a été trouvé entre temps). C'est ainsi que fait par exemple Fortran qui est toujours là malgré son grand âge…
[^] # Re: «Il concurrence donc directement les langages C et C++.»
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.
En mode noyau, l'allocation est déjà différente, même en C. C'est un peu normal puisque le malloc est un appel système…
[^] # RUST 1.0
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Le compilateur GCC 5.1 : harder, better, faster, stronger. Évalué à 3.
Ca tombe bien, rust 1.0 viens de sortir : http://lwn.net/Articles/644671
[^] # Re: Vraiment libre?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 2.
C'est justement ma question. Quelqu'un a t-il déjà fait une étude permettant de dégager une ou plusieurs stratégies plus ou moins adaptées au contexte du projet ou, par exemple, la stratégie de la licence n'a que peu d'influence devant le charisme de l'équipe, l'effet de groupe… autour du projet ?
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 2.
Ah ah, excellent ;-)
[^] # Re: Vraiment libre?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 2.
A t-il été montré, via par exemple un certain nombre de projet, que cette stratégie est la bonne ? La stratégie du tout libre améliore grandement la diffusion du projet et n'empêche pas nombre d'entreprise de prendre du support. Les deux modèles existent donc.
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 2.
Parce qu'on installe sous /opt/VENDOR ;-) Autant faire un /vol qu'un /opt/shared… En pratique, selon les postes, j'aurais aimé installer en local ou faire un montage NFS. Exemple : un noeud de calcul -> montage NFS, un portable utilisateur -> copie locale. /opt/shared, ça donne l'impression qu'on est en partagé…
Et puis on retombe toujours dans le même problème, si ce dossier devient populaire, il y aura un couillon qui fera un paquetage qui utilise ce chemin…
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 3.
Sur un cluster par exemple, tu n'as pas forcément envie d'installer Matlab, Ansys… en local sur chaque poste. Tu as donc bien envie de les mettre sur /opt et de partager/monter ce dossier via NFS (voir monter en lecture seule). Or des paquetages écrivent sous /opt donc le dossier est difficilement partageable via NFS car quels noeuds va écrire dessus si tu déploie ton paquet ? Et si tu supprimes le paquet, c'est le merdier…
Bref, le seul moyen est de trouver un nom que pas grand monde utilise, genre /vol ou /mysoft et d'utiliser ce dossier à la place de /opt… C'est dommage car le premier paquetage qui écrira dessus cassera tout. Faut donc avoir un nom de dossier qui ne devienne surtout pas populaire !
En conclusion, la seule solution, à mon avis, serait que les gestionnaires de paquetages interdisent un dossier racine. Cela aurait du être /opt mais comme c'est trop tard à mon grand regret, il faudrait en trouver un autre et qu'ils se mettent tous d'accord pour l'interdire effectivement.
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 2.
On interdit le montage de /opt par NFS en autorisant les gestionnaires de paquetage d'écrire dedans. Les paquets crades devraient à la rigueur écrire sous /usr/local qui est de toute manière crade. Sinon, il n'y a aucun soucis pour mettre /usr/local sous un autre volume que /usr… j'ai pas bien compris tes arguments sur ce point.
[^] # Re: Prolongement de la durée de support
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
Yep ;-) Il faut noter qu'un certain nombre de développeurs Debian arrête de réellement être développeurs au bout d'un certain temps, notamment pour des raisons de contrainte familliales…
Dans le cas de la LTS, cela ne pouvait se faire sur du bénévolat et/ou en parallèle de son boulot donc une équipe s'est monté qui essaye d'en faire son boulot (à temps très partiel). Peut être que si la LTS a beaucoup de succès, le modèle économique pourra être étendus.
[^] # Re: Des vrais paquets ?
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 4.
De toute manière, rpm et dpkg aurait du interdire d'écrire dans /opt afin de garder ce dossier aux installations manuelles…
[^] # Re: Omnibus c'est hasbeen !
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gitlab: paquets Debian, intégration continue. Évalué à 3.
La version libre ne semble pas gérer les groupes via LDAP. Il y a un contournement possible ?
[^] # Re: Prolongement de la durée de support
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 8.
En fait, toutes les Debian seront /a priori/ des LTS ;-) Il faut deux ans pour sortir une Debian en moyenne + 1 an de recouvrement + 2 ans par l'équipe LTS sur un sous ensemble de la Debian.
Donc 5 ans mais pas sur tout. A noter que l'équipe LTS a besoin de manger le soir ET de s'occuper des enfants qui feront la Debian de demain… Il faut donc les aider sinon le projet ne pourra pas continuer. Le succès de LTS est important et il faut noter que c'est beaucoup moins cher qu'une licence RHEL. Voir https://wiki.debian.org/LTS
[^] # Re: Mauvais problème
Posté par Sytoka Modon (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Ils ont mis des brouilleurs à Bercy ? Si non, je ne sais pas alors ce qu'ils surveillent réellement…
Le TCP/IP par pigeon voyageur a sa RFC. Pour certaines données, on utilise le disque dur par DHL, ça a un débit par si mauvais…
[^] # Re: Mauvais problème
Posté par Sytoka Modon (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Par exemple, j'aime pas qu'on ne puisse pas avoir un recouvrement lors du changement de certificat. Ainsi, on pourrait avoir une chaîne de confiance dans la durée plutôt que par le haut. La dernière version de SSH implémente enfin cela.
On pourrait implémenter des certificats GPG et se baser sur cette chaîne de confiance. On pourrait alors décider de faire confiance aux amis de Google ou d'Amazon ou … autres et avoir ainsi une autre forme de chaîne indépendant des éditeurs de certificats SSL, une chaîne que chacun pourrait adapter à ses besoins…
Bref, cette chaîne SSL n'est pas top top mais je ne sens pas de grande motivation pour aller vers un système plus décentralisé.
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 2.
Il y a des personnes du W3C à l'INRIA de Grenoble. J'en ai croisé un une fois en formation…
Si, le CNRS est beaucoup plus gros ;-) En fait, le CNRS est un EPST un peu particulier car il est fusionnel avec les universités. La recherche universitaire en France est assez particulière en cela. Cela me semble bien moins le cas de l'INRIA (que je connais pas super bien) où les chercheurs me semblent suivre une hiérarchie parfois plus proche du CEA (fonctionnement par projet piloté par le haut) que de l'autonomie quasi totale que l'on a à l'université (d'ailleurs, je ne sais pas si la majorité des chercheurs INRIA sont dans des unités propres ou sont disséminés dans des UMR comme les CNRS ?). Par ailleurs, beaucoup de personne au CNRS font du code mais dans des domaines pas du lié à l'informatique…
[^] # Re: Compilateur sans bugs
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche OpenBSD 5.7 « Blues Brothers ». Évalué à 2.
Je vois Erlang et tout un tas de truc pas spécialement INRIA… Que l'INRIA participe est logique mais la plupart de ces paquetages ne sont pas portés par l'INRIA comme le sont OCaml et Scilab… Par exemple, David Tschumperlé, leader du projet Cimg/G’MIC travaille au GREYC, une UMR, et il est CNRS si mes souvenirs sont bons (http://opensource.graphics/about/).
[^] # Re: Mauvais problème
Posté par Sytoka Modon (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 4.
L'intégrité peut se résoudre sans chiffrement, via signature numérique. C'est une autre fonction qui peut être résolue indépendamment.
# Mauvais problème
Posté par Sytoka Modon (site web personnel) . En réponse au journal HTTP poussé vers la sortie ?. Évalué à -1. Dernière modification le 03 mai 2015 à 20:57.
Quand je consulte wikipedia, je me fiche d'être en http ou https… Il y a tout plein de site dont on se fiche éperdument que les données soient chiffrées. Que cela n'empêche pas de les proposer en deux versions mais il peut être très pratique de laisser une version en http dont on est assurer qu'elle soit en lecture seule (pas de password qui passe par là).
Le problème pour moi viens de l'authentification et des cookies. Je propose de virer les champs cachés ainsi que les cookies d'http, surtout les cookies. De plus, on limite les en têtes afin de revenir a seulement quelques champs simple et on vire tout le reste. On aura ainsi du http pour des sites simples sans authentification et on chiffre lorsque c'est nécessaire. Ainsi on est plus serein coté client mais aussi coté serveur. Quand on fait du http, on n'aura pas de mot de passe du trousseau ou des cookies qui pourront se balader. Le https n'empêche absolument pas de se faire tracer SAUF qu'on croit que tout est clean…
En passant mais non directement liée, quel est le surcoût électrique du TLS actuellement ?
Bref, je milite pour du http en read-only ! Moi, je veux consulter google en http et que cet enfoiré ne compile pas tout cela dans mon compte gmail;-)