Quand tu dis "absurdes", est-ce que tu connais bien les points de droit en relation ? Parce que souvent, il y a des trucs absurdes qui proviennent de trucs de base comme la recherche a tout prix d'un responsable. Parfois, il y a des responsabilités plus facile à démontrer que d'autres, même si cela parait absurde (quand des enfants sont impliqués par exemple).
Vu que ces remboursement de frais sont pour les personnes injustement accusés, je ne vois pas le rapport avec le fait de baisser le recourt à la justice.
Il ne parle pas des sources. Ce qu'il y a "autour" n'a rien de problématique. Mais bon en dessous, il est dit qu'ils reversent leur patch à gcc à la FSF, donc, il n'y a pas de problème.
Je n'ai jamais vraiment regarder les détails, mais il me semble que adacore "reprends" le code de gnat, le compilateur ada de gcc. Ils en ont fait une version propriétaire avec support. Mais bon, le code de gcc n'est-il pas en GPL à la base ?!
Oui, c'est bien ce que je dis, la migration est lente. Si je me souviens bien, un CPU dans la norme DO est considéré comme valide sans plus de preuves que cela s'il est monocoeur et ne réorganise pas l'ordre des instructions… Ce qui est de plus en plus rare aujourd'hui.
Il n'y a rien de tel dans la norme. Elle est justement très peu technique et parle surtout de processus de fabrication. Le cpu typique est le powerPC 601 qui fait un peu d'out of order, il me semble.
Ce cas de figure n'est pas vraiment documenté dans les standards aéro, et ils ont globalement 20 ans de retard sur ce qui est considéré comme standard. Ce qui est un soucis pour introduire bien sûr des calculs plus puissants pour le contrôle de l'appareil.
Projet assez génial on dirait :) Pour moi votre difficulté serait de faire valider tout le runtime qui est vendu avec ce genre de machin. Cela peut être extrêmement complexe. Le pire est le compilateur. Comment prouver que ce qui est compiler est correct, si vous n'avez pas la description de l'assembleur qui va avec ?
Pour les compilo C, on est censé prouver que le compilo génère le bon code objet. Cela a dû se faire par relecture et traçabilité entre code ASM et code C, mais maintenant, cela doit pouvoir se faire avec des exemples de code C à compiler, puis ensuite, on dit que tout code sera issue de ces blocs de base. Mais avec les trucs proprio NVIDIA, je ne vois pas comment faire ça. Vous avez regardez les "array de cpu" comme ceux de Kalray ?
Je n'en suis pas sûr, quand je m'y étais un peu intéressé il semblait impossible de pouvoir (mathématiquement) faire le langage parfait qui puisse exprimer n'importe quel programme de manière assez simple et en garantir la preuve de son bon fonctionnement.
Mais non, je parle de formaliser la DO178, elle-même, pour inclure dans un langage toutes les étapes décrites dans la norme. Le compilateur ne ferait que vérifier la cohérence de l'ensemble des informations (type traçabilité spec<->code<->test<->couverture de test, vérification de la couverture, etc…).
Cela revient à faire un langage qui impose une spec, le teste, la traçabilité et des revues.
Pour info, j'ai fais uniquement du DAL A (code qui vole, générateur de donné, outils de validation). Les démonstrations formelles ne sont pas accepté, en DO178b, et commence à l'être en DO178c. Le problème principale est que l'outil de validation lui-même doit être écris en DAL A pour être accepté.
SCADE est souvent utilisé dans les fadec, mais il n'y a aucune "preuve". Le langage est formel dans le sens ou il ne comporte pas d’ambigüité. Et le compilo est certifié.
D'ailleurs pour les DAL >= C, il devient difficile d'employer des CPU multi-cœurs ou avec un GPU moderne tellement que c'est contraignant vis à vis des normes.
Cela commence tout doucement. La première version de vxworks multicpu, tournait avec 2 instances d'OS, comme si il y avait 2 ordinateurs. C'est très compliqué de calculer le temps d’exécution avec ce genre de machine (ex: il y a une perte de perf de 20% sur les 2 cpu à cause de l'usage du bus mémoire). Si tu prends des marges de fou, avoir 2 cpu n'a plus trop d’intérêt.
Mais la mode IMA, c'est de tout "virtualiser" plus ou moins statiquement. Leur rêve est d'avoir des racks standards et de mettre les applications sur les ordinateurs fonctionnelles.
Concernant les GPU, je n'ai pas encore vu de code certifié. En graphique, il utilise de l'openGL SC, genre d'opengl 1.0, je crois que la dernières version a simplement pris l'api opengl ES vu comme plus propre. Il n'y a pas de shader la-dedans (il faudrait qualifier le compilateur…).
A part ça, je suis persuadé qu'il doit être possible de pouvoir créer un langage qui respecte toutes les contraintes de la DO178b, de le bootstraper et ensuite de pouvoir écrire plus facilement des applications qualifié. Mais cela va au-delà du code pure, car il faut gérer la documentation (les revues de code humaine, les descriptions api, le rapport d'architecture), les versions, les tests (et leur couverture), la traçabilitée.
Globalement la qualité se résume souvent à un cahier de tests, avec des tests unitaires ou fuzzing sans oublier la revue de code et l'intégration continue. Quand tu as ça, déjà, tu es content.
Tu voudrais quoi de plus ? C'est déjà pas mal. Dans l'aéronautique, ils n'ont pas de fuzzer, mais ont des revues de testes.
Typiquement en aéronautique cela sera exigé / recommandé pour les DAL A ou B, mais pas au delà.
Tu fais références à quoi ?
D'autant que si ton programme a un lien fort avec ton matériel (cas du noyau ou d'un logiciel embarqué), il faut aussi formaliser le matériel et cette liaison. Est-ce que des processeurs ou GPU modernes bénéficient d'un tel travail ? J'en doute.
Il te répond avec un langage qui fait cela pour du code sur GPU, et tu réponds que ça ne te parle pas ? C'est quoi le problème ? Qu'ils utilisent la lettre \lambda pour définir des fonctions ? Qu'ils écrivent reduce et non fold ?
Attention ne de pas tout mélanger. Le journal est a propos de la qualité des langages, de leur "ergonomie". Un des principes de l'ergonomie est le principe de "moindre surprise". Trouver un langage utilisant des caractères qui ne sont même pas présent sur un clavier, c'est "surprenant".
A force d'explication, personnellement, je comprends le lien entre lambda/map/fold/reduce, mais je pensais plus général, à l'acceptation du langage dans un cadre bien plus large.
Je ne suis pas sûr que la concision soit le principal moyen pour arriver à la "clarté".
Je conseil très fortement la même chose pour du code C. Utiliser une moyenne n'a pas beaucoup de sens. J'ai remarqué que il faut 3 exécutions de la boucle pour atteindre un palier bas, pour remplir la mémoire cache. Et évidement, un code ne se comporte pas pareil avec des données en cache ou non. Donc, optimiser un code en dehors
de son cas d'usage réel peux être un mauvais plan.
N'utilisez plus un seul chiffre, mais des courbes !
C'est très courant, surtout dans les boîtes qui n'ont en fait pas de problème technique difficile à résoudre et n'ont donc pas vraiment besoin d'une branche R&D qui fait du vrai boulot.
La R&D, c'est surtout du 'D' et pas beaucoup de recherche.
(Il y a aussi des boîtes avec de la vraie R&D. Quand on discute avec les gens de la R&D d'EDF par exemple, on sent qu'ils sont très câlés sur leurs sujets.)
Et se sont souvent des docteurs, et des boites de la taille d'EDF, il n'y a pas 50.
Je ne crois pas avoir vu de boites faisant de la recherche sans docteur dans le domaine.
Halide est un tout nouveau langage, c'est compliqué de demander à un gros projet comme Cimg de tout recoder son C++ dans un nouveau truc, sachant que l’auto-vectorisation fonctionne, et openMP aussi.
Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
J'en suis un. Mais non, c'est pas simple du tout. Il n'y a pas de contact avec la recherche, ni le même vocabulaire (d'où ma proposition de stage de fin d'année en + du stage en entreprise) .
Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
En face, tu as des devs qui font une release avec 1000 commits "corrects" avec un niveau de qualité assez élevé toutes les 6 semaines sur un code de 20 Millions de lignes. Tu imagines la quantité de travail que cela représente en intégration.
Je pense que si c'est difficile de convaincre Linus, cela doit être plus facile de le faire pour les responsables de sous système qui travaillent pour Google, Red Hat, Oracle, Sony ou Intel, voir pour un fondeur comme TI, ST, Qualcomm, ou Infineon.
Mozilla est dans dans une pente descendante, elle perd des utilisateurs et à rater le mobile. Elle recherche de l'aide autour d'elle. Linux a l'inverse est présent absolument partout, sauf dans le desktop Windows et le monde Apple.
Non mais attendre qu'une société (créée à la base par des chercheurs mais développée comme un effort industriel) donne des rapports de bugs tout cuits à analyser, faire quelques changements et puis râler contre les faux positifs, ce n'est pas ce que j'appelle un précédent.
Et pourtant, cela a été déclaré comme une perte de temps par certain dev.
des classes entières de bugs possibles du code du noyau (use-after-free, accès à de la mémoire non initialisée, usage incorrect des verrous…). Tu écris comme si l'utilité de ce résultat final restait à démontrer, ce qui me semble complètement fou
Pour ton exemple, valgrind supporte (en dynamique) la détection des 2 premiers type de bug, et Sparse la dernière. Ce qui reste à démontrer est que l'usage de ces techniques demandent moins d'énergie pour corriger les bugs que les techniques actuelles (phase de mise au point inclus)
Encore une fois, le principe de la recherche n'est pas qu'on développe des programmes C pour dominer le monde, et qu'on va se faire des outils d'analyse statique pour nos propres besoin. C'est de comprendre les problèmes difficiles à résoudre qui affectent tout le monde, et d'essayer de les étudier dans un cadre simplifié, qui permet de se concentrer sur les problèmes de fond.
Tous les outils BSD proviennent bien de l'université Berkeley à l'origine ? Les outils GNU dont GCC ont été codé part RMS qui bossait pour le MIT. Idem pour Spice, le simulateur de circuit analogique. Donald Knuth de tex (latex) bossait pour Stanford. Apache provient de patch de NCSA httpd de l'Université de l'Illinois, idem pour Mosaic, le 1er navigateur internet. BIND (dns) a été conçu a Berkeley.
Tous ces logiciels sont repris par des entités plus ou moins commerciales, mais on été directement utile sous leur 1er forme.
Encore une fois, ce n'est pas le métier des chercheurs que de développer une interface facile d'accès à leur travail.
Vous avez pourtant des chercheurs en ergonomie.
Si quelqu'un veut prendre ça et en faire une bibliothèque grand public,
Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
C'est un peu facile de ta part : tu commences par dire qu'il n'y a pas de recherche sur des langages efficaces (que le milieu de recherche n'a pas les priorités qui t'intéressent), et maintenant je te montres qu'il y en a et ta réponse c'est que c'est trop de la recherche !
Non, pas trop de la recherche, mais trop frustrant de ne pas pouvoir facilement s'en servir simplement parce que le formalisme retenu est celui des maths et non celui de l'informatique. Un tel DSL serait énorme pour un projet comme The Gimp ou CIMG, mais je ne suis pas sûr qu'ils aient la compétence pour le mettre en œuvre.
Tu voudrais un truc tout cuit, mieux que l'existant, déjà prêt pour être utilisé par tout le monde, et puis un café aussi ?
Et sans sucre s'il te plait.
Il y a une incompréhension de fond sur la façon dont les universitaires travaillent, quel est leur but.
Oui et non. Je comprend ce que tu veux dire. Mais en même temps, une des mission de la recherche est de transmettre ce savoir acquis. Si la différence de savoir augmente entre les ingénieurs et les chercheurs, c'est bien qu'il manque un rouage de transmission. (Peut-être qu'il faudrait dans les écoles d'ingénieur, en plus des stage en entreprise, des stages en labo de recherche.)
Je trouve très frustrant d'avoir autant de mal à lire les papiers de recherche en informatique, je ne me considère pas pourtant comme un mauvais ingénieur. Si les ingénieurs moyens sont incapables de comprendre vos publications, comment la transmission pourrait se faire ?
# comme le cloud ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Vers des serveurs libres, ouverts et sécurisés : NERF (2). Évalué à 3.
Niveau interface, j'imagine que la gestion des clouds peut être une bonne source d'inspiration.
La mode est au API, comme celle d'AWS ou au conteneur type docker. Je dis une connerie ?
"La première sécurité est la liberté"
[^] # Re: l'assignation ne va jamais venir
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 6.
Quand tu dis "absurdes", est-ce que tu connais bien les points de droit en relation ? Parce que souvent, il y a des trucs absurdes qui proviennent de trucs de base comme la recherche a tout prix d'un responsable. Parfois, il y a des responsabilités plus facile à démontrer que d'autres, même si cela parait absurde (quand des enfants sont impliqués par exemple).
"La première sécurité est la liberté"
[^] # Re: l'assignation ne va jamais venir
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 10.
Vu que ces remboursement de frais sont pour les personnes injustement accusés, je ne vois pas le rapport avec le fait de baisser le recourt à la justice.
"La première sécurité est la liberté"
[^] # Re: adacore et GPL ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Retour d'expérience et présentation d'Ada dans le contexte d'une appli audio. Évalué à 3.
Il ne parle pas des sources. Ce qu'il y a "autour" n'a rien de problématique. Mais bon en dessous, il est dit qu'ils reversent leur patch à gcc à la FSF, donc, il n'y a pas de problème.
"La première sécurité est la liberté"
[^] # Re: adacore et GPL ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Retour d'expérience et présentation d'Ada dans le contexte d'une appli audio. Évalué à 4.
Cela veut dire que le code de GNAT pro est donné à ses clients payant, et qu'ensuite le code est reversé dans le code de gcc chaque année ?
"La première sécurité est la liberté"
# adacore et GPL ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Retour d'expérience et présentation d'Ada dans le contexte d'une appli audio. Évalué à 4.
Je n'ai jamais vraiment regarder les détails, mais il me semble que adacore "reprends" le code de gnat, le compilateur ada de gcc. Ils en ont fait une version propriétaire avec support. Mais bon, le code de gcc n'est-il pas en GPL à la base ?!
"La première sécurité est la liberté"
[^] # Re: l'assignation ne va jamais venir
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 5.
J'ai l'impression que les juges donnent rarement plus de 700 à 1000€, on est très loin des frais réels. Je ne comprends pas pourquoi d'ailleurs.
"La première sécurité est la liberté"
[^] # Re: l'assignation ne va jamais venir
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 5.
~ 1500€ pour une première instance. Si cela dure avec appel, expertise et autre, cela peut monter à 5/10 k€.
"La première sécurité est la liberté"
[^] # Re: Dommages
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 4.
Ce n'est pas une contrefaçon d'une œuvre qui n'est pas orignal publié avant son propre billet (si on en croit un autre commentaire)
"La première sécurité est la liberté"
[^] # Re: on vit une époque formidable
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à -8.
C'est le début d'etherum. Les avions n'ont pas commencé à voler avec peu de carburant pour transporter 150 personnes à 800 hm/h à 20 000 km.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Il n'y a rien de tel dans la norme. Elle est justement très peu technique et parle surtout de processus de fabrication. Le cpu typique est le powerPC 601 qui fait un peu d'out of order, il me semble.
Projet assez génial on dirait :) Pour moi votre difficulté serait de faire valider tout le runtime qui est vendu avec ce genre de machin. Cela peut être extrêmement complexe. Le pire est le compilateur. Comment prouver que ce qui est compiler est correct, si vous n'avez pas la description de l'assembleur qui va avec ?
Pour les compilo C, on est censé prouver que le compilo génère le bon code objet. Cela a dû se faire par relecture et traçabilité entre code ASM et code C, mais maintenant, cela doit pouvoir se faire avec des exemples de code C à compiler, puis ensuite, on dit que tout code sera issue de ces blocs de base. Mais avec les trucs proprio NVIDIA, je ne vois pas comment faire ça. Vous avez regardez les "array de cpu" comme ceux de Kalray ?
Mais non, je parle de formaliser la DO178, elle-même, pour inclure dans un langage toutes les étapes décrites dans la norme. Le compilateur ne ferait que vérifier la cohérence de l'ensemble des informations (type traçabilité spec<->code<->test<->couverture de test, vérification de la couverture, etc…).
Cela revient à faire un langage qui impose une spec, le teste, la traçabilité et des revues.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Pour info, j'ai fais uniquement du DAL A (code qui vole, générateur de donné, outils de validation). Les démonstrations formelles ne sont pas accepté, en DO178b, et commence à l'être en DO178c. Le problème principale est que l'outil de validation lui-même doit être écris en DAL A pour être accepté.
SCADE est souvent utilisé dans les fadec, mais il n'y a aucune "preuve". Le langage est formel dans le sens ou il ne comporte pas d’ambigüité. Et le compilo est certifié.
Cela commence tout doucement. La première version de vxworks multicpu, tournait avec 2 instances d'OS, comme si il y avait 2 ordinateurs. C'est très compliqué de calculer le temps d’exécution avec ce genre de machine (ex: il y a une perte de perf de 20% sur les 2 cpu à cause de l'usage du bus mémoire). Si tu prends des marges de fou, avoir 2 cpu n'a plus trop d’intérêt.
Mais la mode IMA, c'est de tout "virtualiser" plus ou moins statiquement. Leur rêve est d'avoir des racks standards et de mettre les applications sur les ordinateurs fonctionnelles.
Concernant les GPU, je n'ai pas encore vu de code certifié. En graphique, il utilise de l'openGL SC, genre d'opengl 1.0, je crois que la dernières version a simplement pris l'api opengl ES vu comme plus propre. Il n'y a pas de shader la-dedans (il faudrait qualifier le compilateur…).
A part ça, je suis persuadé qu'il doit être possible de pouvoir créer un langage qui respecte toutes les contraintes de la DO178b, de le bootstraper et ensuite de pouvoir écrire plus facilement des applications qualifié. Mais cela va au-delà du code pure, car il faut gérer la documentation (les revues de code humaine, les descriptions api, le rapport d'architecture), les versions, les tests (et leur couverture), la traçabilitée.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Tu voudrais quoi de plus ? C'est déjà pas mal. Dans l'aéronautique, ils n'ont pas de fuzzer, mais ont des revues de testes.
Tu fais références à quoi ?
Il n'y a pas d'étude formelle, mais il y a une norme à respecter https://fr.wikipedia.org/wiki/DO-254
"La première sécurité est la liberté"
[^] # Re: Trop génial ! Une base de données légale.
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Atelier Barcamp I. A. & Droit le 7 novembre 2017 à Paris. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Attention ne de pas tout mélanger. Le journal est a propos de la qualité des langages, de leur "ergonomie". Un des principes de l'ergonomie est le principe de "moindre surprise". Trouver un langage utilisant des caractères qui ne sont même pas présent sur un clavier, c'est "surprenant".
A force d'explication, personnellement, je comprends le lien entre lambda/map/fold/reduce, mais je pensais plus général, à l'acceptation du langage dans un cadre bien plus large.
Je ne suis pas sûr que la concision soit le principal moyen pour arriver à la "clarté".
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Non, elle ne s'en moque pas. Elle n'est simplement pas persuadé du tout que les chercheurs peuvent l'aider sur la question.
"La première sécurité est la liberté"
[^] # Re: microbenchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Optimisation, microbenchmark et compilation Just In Time : quand 1 + 1 ne font pas 2. Évalué à 5.
Sur un microbenchmark de memcpy, il y avait un facteur x10 entre cold/hot start.
Sur un code de calcul, de mémoire, il y avait une augmentation de 30% des perfs au 3ième tour.
"La première sécurité est la liberté"
# microbenchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Optimisation, microbenchmark et compilation Just In Time : quand 1 + 1 ne font pas 2. Évalué à 6. Dernière modification le 03 novembre 2017 à 16:49.
Je conseil très fortement la même chose pour du code C. Utiliser une moyenne n'a pas beaucoup de sens. J'ai remarqué que il faut 3 exécutions de la boucle pour atteindre un palier bas, pour remplir la mémoire cache. Et évidement, un code ne se comporte pas pareil avec des données en cache ou non. Donc, optimiser un code en dehors
de son cas d'usage réel peux être un mauvais plan.
N'utilisez plus un seul chiffre, mais des courbes !
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
La R&D, c'est surtout du 'D' et pas beaucoup de recherche.
Et se sont souvent des docteurs, et des boites de la taille d'EDF, il n'y a pas 50.
Je ne crois pas avoir vu de boites faisant de la recherche sans docteur dans le domaine.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Bon, on dirait que c'est une lib C++, cela simplifie beaucoup de chose pour s'intégrer.
https://github.com/halide/Halide/wiki/Static-vs.-JIT-compilation
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Halide est un tout nouveau langage, c'est compliqué de demander à un gros projet comme Cimg de tout recoder son C++ dans un nouveau truc, sachant que l’auto-vectorisation fonctionne, et openMP aussi.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
J'en suis un. Mais non, c'est pas simple du tout. Il n'y a pas de contact avec la recherche, ni le même vocabulaire (d'où ma proposition de stage de fin d'année en + du stage en entreprise) .
En face, tu as des devs qui font une release avec 1000 commits "corrects" avec un niveau de qualité assez élevé toutes les 6 semaines sur un code de 20 Millions de lignes. Tu imagines la quantité de travail que cela représente en intégration.
Je pense que si c'est difficile de convaincre Linus, cela doit être plus facile de le faire pour les responsables de sous système qui travaillent pour Google, Red Hat, Oracle, Sony ou Intel, voir pour un fondeur comme TI, ST, Qualcomm, ou Infineon.
Mozilla est dans dans une pente descendante, elle perd des utilisateurs et à rater le mobile. Elle recherche de l'aide autour d'elle. Linux a l'inverse est présent absolument partout, sauf dans le desktop Windows et le monde Apple.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3. Dernière modification le 02 novembre 2017 à 15:36.
Aurais-tu la page ou l'on peut avoir ce compilateur DSL, je n'arrive pas à le trouver ?
c'est ça ? http://www.lift-project.org/
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Et pourtant, cela a été déclaré comme une perte de temps par certain dev.
Pour ton exemple, valgrind supporte (en dynamique) la détection des 2 premiers type de bug, et Sparse la dernière. Ce qui reste à démontrer est que l'usage de ces techniques demandent moins d'énergie pour corriger les bugs que les techniques actuelles (phase de mise au point inclus)
Tous les outils BSD proviennent bien de l'université Berkeley à l'origine ? Les outils GNU dont GCC ont été codé part RMS qui bossait pour le MIT. Idem pour Spice, le simulateur de circuit analogique. Donald Knuth de tex (latex) bossait pour Stanford. Apache provient de patch de NCSA httpd de l'Université de l'Illinois, idem pour Mosaic, le 1er navigateur internet. BIND (dns) a été conçu a Berkeley.
Tous ces logiciels sont repris par des entités plus ou moins commerciales, mais on été directement utile sous leur 1er forme.
"La première sécurité est la liberté"
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Vous avez pourtant des chercheurs en ergonomie.
Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
Non, pas trop de la recherche, mais trop frustrant de ne pas pouvoir facilement s'en servir simplement parce que le formalisme retenu est celui des maths et non celui de l'informatique. Un tel DSL serait énorme pour un projet comme The Gimp ou CIMG, mais je ne suis pas sûr qu'ils aient la compétence pour le mettre en œuvre.
Et sans sucre s'il te plait.
Oui et non. Je comprend ce que tu veux dire. Mais en même temps, une des mission de la recherche est de transmettre ce savoir acquis. Si la différence de savoir augmente entre les ingénieurs et les chercheurs, c'est bien qu'il manque un rouage de transmission. (Peut-être qu'il faudrait dans les écoles d'ingénieur, en plus des stage en entreprise, des stages en labo de recherche.)
Je trouve très frustrant d'avoir autant de mal à lire les papiers de recherche en informatique, je ne me considère pas pourtant comme un mauvais ingénieur. Si les ingénieurs moyens sont incapables de comprendre vos publications, comment la transmission pourrait se faire ?
"La première sécurité est la liberté"