Sytoka Modon a écrit 4544 commentaires

C++ évolue sans casser la compatibilité

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…

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…

Ca tombe bien, rust 1.0 viens de sortir : http://lwn.net/Articles/644671

Pourquoi y aurait-il UNE bonne stratégie ?

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 ?

Ah ah, excellent ;-)

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.

De toute manière, rpm et dpkg aurait du interdire d'écrire dans /opt afin de garder ce dossier aux installations manuelles…

La version libre ne semble pas gérer les groupes via LDAP. Il y a un contournement possible ?

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

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…

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é.

Copyright (c) 1998-2002 W3C (MIT, INRIA, Keio),

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/).

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.

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;-)

Maintenant aurait-on intérêt à essayer d'obtenir des organismes de recherche des décisions fermes sur les licences des logiciels produites par leurs employé-e-s ? Bien sûr je serais content d'une directive imposant aux chercheu-r-se-s de produire du logiciel libre (mon opinion est que tout le logiciel produit par la recherche publique devrait être libre),

Qu'est ce que la recherche publique ?

Actuellement, dans les laboratoires universitaires, environ 20% du budget (hors salaire des fonctionnaires et des bourses ministères) sont des crédits récurrents. Ces 20% ne permettent même plus d'assurer une fonctionnement minimale (financement des locaux… Yep, on paye un loyer !). Donc 80% sont sur contrat donc c'est de l'argent que le chercheur se démène pour l'avoir (appel à projet, rapports intermédiaires, finaux, réunionite…). Une partie provient d'institution publique (Europe, ANR…) et une partie de boite privée (qui doivent en recevoir plus de l'état en parallèle), assez souvent il y a un mixte de plein de financement car on n'arrive pas toujours à tout financer sur un seul contrat…

Je suis pour la diffusion universelle MAIS il faut reconnaître que la concurrence est là. Les autres pays sont loin de mettre sur la table leur recherche publique et ne se gêne pas pour venir piocher chez nous (par exemple, il y a quelques années, on faisait venir des experts étrangers lors des comités d'évaluation AERES qui repartaient chez eux avec une feuille de route toute faite financé par le contribuable). Il y a des domaines, comme en SPI, ou la recherche publique est au service des français mais en ne mettant pas tout sur la table. Le contribuable s'y retrouve normalement via la bonne santé des entreprises !

Faut-il publier le code source du logiciel permettant de simuler la combustion des futures fusée Ariane VI ?

Il y a des principes et une réalité. Je n'ai pas d'avis complètement tranché. Je serais par contre plutôt partisan pour définir une charte pour les entreprises bénéficiant de la recherche publique (arrêter les paradis (et les bidouilles) fiscaux, salaire max dans l'entreprise à 20 fois le SMIC…). Déjà, rien que cela, ça pourrait être intéressant de voir ce que cela donne.

Des domaines très ouverts comme la mécanique quantique ne diffusent pas tout sur le coup. Par exemple, le CERN garde les données de manip quelques années avant diffusion le temps pour les chercheurs de trouver et publier. L'idéal publique est obligé de se contorsionner aux notions de concurrences et d'état nation dans nombre de cas…

Sincèrement si 2 des plus gros logiciels d'images sous linux ne sont pas capable…

Je suis d'accord pour dire que l'évolution est lente. Pour Inkscape, je ne sais pas pourquoi, je ne le suit plus de près. J'ai l'impression qu'au début il y avait une feuille de route claire sur une dizaine de version et que depuis quelques années, toute cette dynamique s'est un peu essoufflée.

De plus ça ne répond absolument pas au point

Exact. Je n'ai de bien pertinent à rajouter à tes belles paroles ;-)

Désolé de tomber à plat… ce doit être l'âge du coup je tombe dans les clichés ;-) Ceci dis, faire un compilateur C non libre aujourd'hui, je ne suis pas sur que ce soit un choix très judicieux pour assurer sa diffusion… L'INRIA fait plein de truc super mais malheureusement, je n'ai pas l'impression d'en voir beaucoup sur les ordinateurs de mon laboratoire. D'ailleurs, en disant cela, je me demande s'il y aurait un 'grep' magique sous Debian qui pourrait nous donner ce genre de réponse ?

J'ai regardé la vidéo de bout en bout. Je dis juste que que le mode d'action de la souris influence grandement sur la conception des logiciels et des utilisateurs d'aujourd'hui. Actuellement, très peu de jeune raisonnent avec une vision FollowMouse, normal, cela a quasiment disparu des IHM depuis plus de 10 ans.

Or Gimp mais aussi Inkscape ont été conçu à l'origine par des personnes travaillant sur des environnement en FollowMouse. Un énorme boulot a été fait pour les adapter mais je ne suis pas surpris qu'il faille encore du boulot pour les rendre encore plus intuitif (en ClickToFocus).

Bien sur mais ce n'est pas top. D'abord c'est pas intégré dans ssh, les options de la ligne de commande sont très différentes, cela fonctionne par profile. Pas évident de rediriger un port en parallèle. Il y a mosh qui est dans le même esprit que x2go mais en console et il n'utilise ssh que pour ouvrir la connexion, il bascule ensuite en UDP et est très robuste sur des réseaux à très bas débit, ce que n'est pas x2go.

Bref, x2go, c'est très bien mais il reste du travail pour que tout le monde bascule dessus. Et au rythme actuel, plus personne ne sera sous X ;-(

Ceci dis, ça fait chier que Xorg/ssh n'est pas intégré la libnx…