D'un autre côté avant qu'on parle de nuage toutes les 3 phrases, il y a avait déjà autre chose que Apache dans les datacenters… Et d'ailleurs il y a avait déjà du plus ou moins managé à tous les degrés imaginable.
À un moment il va falloir penser à définir ce putain de mot proprement (c'est à dire autrement que part: "ce que AWS/Azure propose en ce moment") et profondément en quoi il se distingue.
Parce que sinon je pourrais moi aussi parler ad nauseam de c'est quoi ce putain de mélange (confusion!?) entre de l'élasticité, protocoles proprio pour s'abstraire et parler à d'autres protocoles proprio, matériel spécifique, etc. Et trouver des exemples de gens qui faisait tout ça avant qu'on se mette à employer ce mot partout.
À la limite ça aurait plus de valeur d'appeler ça genre RHSHIaaSivdaatw (random heterogeneous software and hardware "infrastructure" as a service in various datacenters all around the world) en précisant les services en question, ou alors plus simplement dire directement: AWS, Azure etc.
Sans parler de ceux pour qui le saint mot "Cloud" n'est pas du tout utilisé pour désigner ça mais simplement genre stocker ses fichier en ligne, ou encore utiliser une application avec connexion au net obligatoire (en retour le service étant lui même peut-être "hébergé" dans un AWS & co; ou pas d'ailleurs).
Bref faute de def ça risque de rester de l'informatique nébuleuse tout ça.
Ceci étant dit je conteste pas que Azure propose sans doute autre/plus de chose que Gandi; juste que c'est (toujours aussi) ridicule de désigner ça par un mot aussi surchargé - et de simultanément faire une distinction basée sur finalement une limite tellement flou que personne n'arrivera à la définir.
C'est d'autant plus ridicule que j'ai utilisé aussi les mots "hébergé" et "infrastructure" dans mon rant, à mon goût totalement légitimement. On doit dire quoi si on peut pas dire qu'on est "hébergé", dans un "cloud": qu'on est "évaporé" ? Et si AWS continue à rajouter tout et n'importe quoi comme services dans leurs offres, faut appeler le résultat étendu pareil, ou inventer un 3è nom ?
Pour l'anecdote, Gosling raconte que Stallman lui a "piqué" tout "son" Emacs.
Stallman a une version différente, le LL était moins théorisé/formalisé et la position de Gosling sur Emacs a été semble-t-il changeante et peut-être même tentant de revendiquer rétroactivement le copyright alors qu'il y avait déjà d'autres contributeurs (et peut-être pas de CLA), la quantité de code provenant de Gosling pourrait avoir été bien moindre que ce que prétend ce dernier - et surtout il a été remplacé dès qu'il y a eu un doute, enfin les seules éléments de preuves avancés par Gosling sont très indirects (du style "d'autres ont été condamnés, mais Stallman il a pas de tunes et il se lave pas, on l'a pas attaqué").
Enfin bon l'anecdote a un intérêt historique, y compris dans la création de la GPL.
J'irais pas jusqu'à dire que ça a rattrapé Rust. Wlifetime est un espèce linter optionnel heuristique (unsound) proposé par certains compilateurs. Le check des lifetimes de Rust est ultra fondamental, mandatory, sound, et intégré au système de type.
Je ne sais pas si Wlifetime est utile en pratique, j'espère que oui, mais perso j'ai pas essayé. Mais sans intégration au système de type et soundness on pourra jamais dire qu'il a complètement rattrapé Rust. Or c'est pas vraiment la direction que souhaite prendre le C++ pour le moment (la solution de Rust étant trop contraignante pour faire évoluer des bases de code sans parfois des refactoring majeur, et sera probablement toujours perçu comme trop contraignante par certain programmeurs et/ou pour certaintes routines; les solutions moins contraignante le restent néanmoins beaucoup sur ce même aspect, et relèvent de toute manière pour l'instant du domaine de la recherche).
Et vu le langage et les objectifs usuels des migrations vers Rust, AMA ça serait pas une bonne idée que le C++ cherche à "rattraper" frontalement ce genre de caractéristiques. Il y a des problèmes pratiques qui sont difficiles à résoudre dans les projets potentiels (cf. les réflexions de Google et de MS), et il suffit que le C++ propose d'autres features en plus d'être suffisamment bon pour se placer dans une situation ou c'est en pratique économiquement compétitif de réduire la densité de bugs (en particulier des bugs susceptibles d'avoir des conséquences catastrophiques en stabilité et sécurité) en continuant en C++ que ce qui pourrait être fait en migrant des bouts vers Rust.
Mais si tu veux vraiment absolument un check de lifetime fiable et que c'est totalement critique, tu fais clairement du Rust plutôt que du C++ même avec Wlifetime, et je vois vraiment pas ça changer, du moins pas avant très longtemps (et même dans très longtemps, je pense que ça a une très faible proba que le C++ "rattrape" complètement le Rust sur ce point).
Par contre approximer par une gaussienne c'est effectivement pas très précis, mais ça devrait permettre d'obtenir un ordre de grandeur. Mais je suis pas sûr que ça soit suffisamment précis pour prédire par exemple la journée du nombre de mort max.
Tu peux trouver les comptes rendus des réunions du conseil scientifique.
J'ai pas souvenir qu'ils disent qu'il faut continuer à travailler à tout prix, ni que la situation n'a rien à voir avec celle de l'Italie.
Maintenant il faut bien comprendre qu'ils ne peuvent pas non plus chier dans les médias sur le gouvernement. Ça serait probablement contre productif, le politique étant en général bien borné et totalement incapable d'admettre ses erreurs.
Concernant l'attribution à l'employeur s'appliquant en dehors des heures de travail, il faut préciser:
dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur
Ainsi si tu codes un truc qui n'a rien à voir en dehors de tes heures de boulot et sans utiliser de ressource de ton employeur, c'est à toi.
Concernant les contributions que tu fais au/pour le boulot donc, je pars du principe que ce qui n'est pas interdit est autorisé, et donc l'accord simple y compris informel de la hiérarchie me suffit amplement (approche à moduler selon le poste.)
La situation est pragmatiquement facilitée AMA pour les logiciels copyleft dans les situations où on a de toute façon que le choix entre publication des sources ou "inexistence" (sauf à mettre l'entreprise dans l'illégalité) de la modification. Je serais "paradoxalement" plus prudent pour contribuer au taf pour un truc sous MIT que pour un truc sous GPL (destiné a être mis dans un produit).
Concernant le risque personnel (cf. "vas-y contribue" peux se retourner en "tu as commis une faute en livrant des infos, dehors"), j'aime bien utiliser l'approche suivante : si une boite veut jouer à ce genre de jeux, j'aurais mieux à faire ailleurs de toute façon.
Ben ouai. Tu peux déjà acheter plein de merde polluante à produire ou rouler toute la journée dans une voiture très puissante et très polluante si ça t'amuse.
Et effectivement tu peux pour l'instant prendre l'avion en masse pour bénéficier d'un effet de levier sur ta pollution, si t'as envie d'utiliser ton pouvoir d'achat pour polluer encore plus.
Je croyais qu'un avion était rempli d'avionique conçu pour une (ou quelques) familles, en tout cas conçus pour des avions.
Du coup en quoi c'est compliqué et/ou cher d'avoir des diodes physiques dans le design ?
Si la diode est purement logicielle, ça veut dire que qu'il y a un lien de données bidirectionnel que seul le logiciel diode en question peut piloter côté sécurisé. Il est réputé simple et fiable, mais est-il audité par des chercheurs indépendants en sécu informatique appliquant des tests d'attaque de l'état de l'art, ou est-ce en fait du whishful-thinking ? Si les coûts des audits sérieux sont pris en compte, est-ce toujours aussi intéressant d'éviter de coller une diode physique dans la conception ?
Je pose ces questions, car habituellement dans les industries un peu "opaques", dès que des indépendants en sécu informatique commencent à creuser, ils se rendent compte immédiatement du désastre. Ex les vulns de partout dans les réseaux télécom, ou les vulns dans les systèmes informatique/contrôle commande industriels critiques (cf les confs du C3)
Je rejoins par ailleurs tout ce qui t'a été dit sur les coûts. Si ta facture devait représenter l'épuisement des ressources de la planète, ton accès internet te coûterait quelque chose entre 5 et 100 fois plus cher… L'hypothèse que la nature est gratuite n'engagent que ceux qui la laissent à leurs enfants en sale état.
Mwai mais pour le reste aussi, en général (et en ordre de grandeur), nan ?
Il n'y en a pas parce que dans quelques temps (p"robablement C++23), il y aura les contrats qui permettront de vérifier les indices au bon endroit (c'est-à-dire dans le code appelant puisqu'avoir un bon indice est une pré-condition). Donc, le comité a décidé de ne pas ajouter une fonction (genre at) qui ne servira plus à rien bientôt.
Ça laisse quand même au minimum entre 2020 et 2023 sans solution sérieuse.
Sur le reste, je ne vois pas trop où tu veux en venir. C++ évolue aussi dans le bon sens. Par exemple, les entiers sont dorénavant considérés comme étant codés en complément à 2, ce qui était une scorie de l'époque où C a été standardisé.
Mais on reste en UB sur overflow. Non plus pour les raisons historiques de l'UB (difference entre 2 procs), mais bien uniquement pour les raisons postmodernes : "opti" (avec les guillemets pour indiquer que c'est avec la technique des transformations valides uniquement sous hypothèse, typiquement non prouvée, d'absence d'UB). Après étant donné l'impact sur le codegen des indexations sur x86, peut-être que cette opti là c'est une des rare que je "veux" peut-être (en compromis)—mais faudrait voir si on peut pas prouver les non débordements au lieu d'en faire l'hypothèse, ainsi que bencher avec/sans. Il y a des bases de code majeures (ex : Linux) qui compilent en fno-strict-overflow ou fwrapv, donc probablement que c'est pas si crucial que ça, en fait.
Depuis C++11, il y a un modèle mémoire pour faire du multithread.
Et il est extrêmement bienvenue, même si on arrivait à faire du multithread avant. Tout comme on arrive à faire de la shm ou du mmap aujourd'hui, alors que dans la machine abstraite c'est pas officiellement prévu. C et C++ avaient ce statut spécial nécessaire pour les langages systèmes ; la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes. La tendance postmoderne des implémenteurs est beaucoup plus de se contenter de la norme et d'ignorer tous les problèmes concrets que cet extrémisme engendre (et rejeter la faute sur les utilisateurs du compilo au lieu d'améliorer la qualité d'implémentation).
il ne faut pas se leurrer, C++ n'est pas fait pour être un langage «safe»
Justement. S'il refuse obstinément de prendre raisonnablement ce tournant, mon hypothèse c'est qu'il va passer de statut de langage système absolument majeur à celui de langage de niche. Et encore. Vu que j'arrive même pas à coder d'allocateur avec sans faire 42 UB formelles par ligne, j'ai du mal à voir quel niche il va finir par occuper : jeu vidéo offline, peut-être. Hm même ça, ça n'existera bientôt plus trop.
Hm comme souvent y a probablement des avantages et des inconvénients des deux côtés…
Par exemple git utilise des hard links pour avoir des clones locaux légers. Alors certes si on a pas ça on peut envisager un modèle plus worktree-style, mais avec ça aussi il y a des avantages et des inconvénients.
On peut encore noter la possibilité de gérer des dépots gigantesques "simplement" en virtualisant le FS (enfin c'était le plus gros du boulot)—MS a fait ça pour mettre tout le code source de Windows sous Git.
Enfin je connais pas les internals de Git mais je vois pas trop pourquoi on pourrait pas construire des structures de données plus complexes que des listes chaînées en partant d'un tel modèle ni en quoi ça disqualifirait pour être un "chercheur en informatique" (au contraire…)
Ceci étant dit, je ne déteste pas le fait d'utiliser une DB, mais simplement à lire votre échange, hm, c'est pas en jouant au tennis à coup de qui a "loupé un truc" que chacun va être incité à améliorer sereinement ses connaissances et sa compréhension des compromis, avantages et inconvénients de chaque solution.
Je comprends ce que ça veut dire mais je déteste l'approche qui prétend décorréler la "qualité" du code; ça veut juste dire que la "qualité" en question n'a pas (suffisamment) d'impact réel—c'est juste de la "qualité" au lieu d'être simplement de la qualité…
Je ne dis pas que c'est impossible de faire de très bonne choses avec un FPGA, ni même que ça n'a pas des avantages par rapport à un PC puissant + des émulateurs full-soft précis. Simplement ça n'est pas magique (surtout en ce qui concerne la fidélité), et ça a aussi des inconvénients. Donc à chacun de voir lesquels des avantages il privilégie et qu'est ce qu'il veut en faire. De toutes façons on a atteint un stade où les jeux majeurs, y compris souvent pour des consoles relativement "récentes" (Wii, etc.) tournent suffisamment bien même avec des solutions pas forcement 100% précises. Et on a aussi pas mal d'émulateurs qui utilisent des techniques de haut niveau pour améliorer l'expérience de jeu plutôt que de privilégier la fidélité; et c'est très bien : ça plaît à beaucoup de monde !
Un CPU high end moderne a une puissance démesurée et est cadencé super rapidement. On peut émuler une SNES quasi-parfaitement là-dessus (et en pratique tous les jeux ayant été édités sur SNES tournent parfaitement), et certes ça consomme un peu toute cette puissance mais en fait le problème principal est plus de reverse le hard d'origine avec un niveau de précision ultra fin et une bonne réimplantation, que la puissance nécessaire au runtime (puisque cette dernière est dispo sur étagère). Cf le projet higan.
De même, la réimplantation dans un FPGA ne va pas se faire d'une manière magique. Ni d'une manière "naïve" ou "triviale" (en copiant le hard d'origine bloc par bloc). Du coup le boulot est tout autant conséquent, et par exemple un projet commercial aura plus tendance à privilégier un peu les hacks (avec par exemple du tuning par jeu pour les plus courant, voire des patchs des ROMs connues) qu'une émulation absolument parfaite.
Et en plus, d'un point de vue conservation, on peut arguer que le résultat n'est pas aussi puissant qu'un émulateur full-soft, vu que le FPGA cible et la board cible va avoir son propre cycle d’obsolescence, alors qu'un soft peut être très largement portable pour son moteur d'émulation et pour les petits bouts d'IO la maintenance est relativement facile (et peut potentiellement n'être nécessaire que rarement).
Et la complexité de la réimplé augmente bien évidemment sur des consoles plus puissantes.
Enfin sur de la 3D on arrête rapidement l'émulation low level pour passer sur une traduction des primitives graphiques vers une API moderne, et là un FPGA n'aidera pas.
C'est extrêmement dur de se prévaloir d'une expertise en sécurité si tout est secret (ou en quoique ce soit, d'ailleurs, mais en fait encore plus particulièrement en sécu)
Même la NSA publie des trucs…
En passant j'ai fait un peu de presta pour Thales il y a quelques années et du micro échantillon que j'en ai vu à l'époque, la culture m'a semblé ultra corporate avec assez peu de collaboration interne hors cadre d'un contrat (les différents BU passant des appels d'offre auxquelles les autres et les externes peuvent répondent simultanément, et "grâce" à ce système Thales maintenait/adaptait probablement la même bibliothèque des dizaines de fois sans que les gens qui travaillent réellement dessus puissent ne serait-ce que savoir qui sont les autres—et ce y compris pour être intégré en tant que composant dans un même système). Pour faire de la sécu à un bon niveau, il faut de la collaboration informelle y compris en dehors de l'entreprise. Alors je sais pas si ça fonctionne toujours comme ça et si c'est global à tout Thales, mais si déjà c'est si dur de collaborer informellement en interne, en externe j'ose même pas imaginer.
La portabilité du C++ moderne, y compris et surtout avec une bibliothèque standard moderne, n'a rien a voir du tout avec la situation que tu as vécu lors de ton utilisation initiale. Les progrès ont été énormes surtout ces dernière années avec la mise en conformité et le rattrapage de MS pour MSVC (gcc et clang sous Nux étaient déjà beaucoup plus conformes depuis quelques années de plus).
Aujourd'hui pour la plupart des applications dans les domaines ou le C++ est applicable, il est de moins en moins pensable de s'abstenir d'utiliser la bibliothèque standard. La plupart de ceux qui le faisaient avaient de bonne raisons historiquement, mais au fur et à mesure de l'évolution du langage, les freins historiques sont traités et les raisons en question disparaissent ou s'amenuisent, et même certains projets historiques migrent petit à petit vers de plus en plus de bibliothèque standard. Permettre cela semble même être un des critères essentiels pour les évolutions du langage décidées par le commité.
[^] # Re: IPv4
Posté par Guillaume Knispel . En réponse au journal Rappel que les préfixes IPv6 d’Orange ne sont pas fixes. Évalué à 3.
SFR a des problèmes d'infra IPv6 sur leurs équipements existant je crois. Du coup ils déploient plus lentement que les autres.
[^] # Re: IPv4
Posté par Guillaume Knispel . En réponse au journal Rappel que les préfixes IPv6 d’Orange ne sont pas fixes. Évalué à 4.
Oui mais c'est des réattributions non ? En tout cas il y a bien une pénurie d'IPv4 depuis quelques années.
[^] # Re: Plus d'infos
Posté par Guillaume Knispel . En réponse au journal Améli et la Souveraineté Numérique. Évalué à 2.
Rant à moitié HS sur le vocabulaire:
D'un autre côté avant qu'on parle de nuage toutes les 3 phrases, il y a avait déjà autre chose que Apache dans les datacenters… Et d'ailleurs il y a avait déjà du plus ou moins managé à tous les degrés imaginable.
À un moment il va falloir penser à définir ce putain de mot proprement (c'est à dire autrement que part: "ce que AWS/Azure propose en ce moment") et profondément en quoi il se distingue.
Parce que sinon je pourrais moi aussi parler ad nauseam de c'est quoi ce putain de mélange (confusion!?) entre de l'élasticité, protocoles proprio pour s'abstraire et parler à d'autres protocoles proprio, matériel spécifique, etc. Et trouver des exemples de gens qui faisait tout ça avant qu'on se mette à employer ce mot partout.
À la limite ça aurait plus de valeur d'appeler ça genre RHSHIaaSivdaatw (random heterogeneous software and hardware "infrastructure" as a service in various datacenters all around the world) en précisant les services en question, ou alors plus simplement dire directement: AWS, Azure etc.
Sans parler de ceux pour qui le saint mot "Cloud" n'est pas du tout utilisé pour désigner ça mais simplement genre stocker ses fichier en ligne, ou encore utiliser une application avec connexion au net obligatoire (en retour le service étant lui même peut-être "hébergé" dans un AWS & co; ou pas d'ailleurs).
Bref faute de def ça risque de rester de l'informatique nébuleuse tout ça.
Ceci étant dit je conteste pas que Azure propose sans doute autre/plus de chose que Gandi; juste que c'est (toujours aussi) ridicule de désigner ça par un mot aussi surchargé - et de simultanément faire une distinction basée sur finalement une limite tellement flou que personne n'arrivera à la définir.
C'est d'autant plus ridicule que j'ai utilisé aussi les mots "hébergé" et "infrastructure" dans mon rant, à mon goût totalement légitimement. On doit dire quoi si on peut pas dire qu'on est "hébergé", dans un "cloud": qu'on est "évaporé" ? Et si AWS continue à rajouter tout et n'importe quoi comme services dans leurs offres, faut appeler le résultat étendu pareil, ou inventer un 3è nom ?
Fin du rant!
[^] # Re: historiques
Posté par Guillaume Knispel . En réponse au journal Les doutes d'un gars qui écrit: sérieusement se mettre à Emacs, ou pas ?. Évalué à 4. Dernière modification le 14 mai 2021 à 00:17.
Pour l'anecdote, Gosling raconte que Stallman lui a "piqué" tout "son" Emacs.
Stallman a une version différente, le LL était moins théorisé/formalisé et la position de Gosling sur Emacs a été semble-t-il changeante et peut-être même tentant de revendiquer rétroactivement le copyright alors qu'il y avait déjà d'autres contributeurs (et peut-être pas de CLA), la quantité de code provenant de Gosling pourrait avoir été bien moindre que ce que prétend ce dernier - et surtout il a été remplacé dès qu'il y a eu un doute, enfin les seules éléments de preuves avancés par Gosling sont très indirects (du style "d'autres ont été condamnés, mais Stallman il a pas de tunes et il se lave pas, on l'a pas attaqué").
Enfin bon l'anecdote a un intérêt historique, y compris dans la création de la GPL.
[^] # Re: "accès privilégié" et "root"?
Posté par Guillaume Knispel . En réponse au journal Prise en main de la carte Longan Nano RISC-V de Sipeed. Évalué à 2.
Juste pour pinailler, tu peux en implémentant une VM, cf. l'approche de Singularity.
[^] # Re: Toujours étonné
Posté par Guillaume Knispel . En réponse à la dépêche Le Frido et Giulietta : la mathématique libre. Évalué à 3.
Y a une énorme part de mode en informatique. Si tu te concentres sur les fondamentaux, TAOCP est très bien.
[^] # Re: Pffff
Posté par Guillaume Knispel . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 7. Dernière modification le 07 septembre 2020 à 01:49.
J'irais pas jusqu'à dire que ça a rattrapé Rust. Wlifetime est un espèce linter optionnel heuristique (unsound) proposé par certains compilateurs. Le check des lifetimes de Rust est ultra fondamental, mandatory, sound, et intégré au système de type.
Je ne sais pas si Wlifetime est utile en pratique, j'espère que oui, mais perso j'ai pas essayé. Mais sans intégration au système de type et soundness on pourra jamais dire qu'il a complètement rattrapé Rust. Or c'est pas vraiment la direction que souhaite prendre le C++ pour le moment (la solution de Rust étant trop contraignante pour faire évoluer des bases de code sans parfois des refactoring majeur, et sera probablement toujours perçu comme trop contraignante par certain programmeurs et/ou pour certaintes routines; les solutions moins contraignante le restent néanmoins beaucoup sur ce même aspect, et relèvent de toute manière pour l'instant du domaine de la recherche).
Et vu le langage et les objectifs usuels des migrations vers Rust, AMA ça serait pas une bonne idée que le C++ cherche à "rattraper" frontalement ce genre de caractéristiques. Il y a des problèmes pratiques qui sont difficiles à résoudre dans les projets potentiels (cf. les réflexions de Google et de MS), et il suffit que le C++ propose d'autres features en plus d'être suffisamment bon pour se placer dans une situation ou c'est en pratique économiquement compétitif de réduire la densité de bugs (en particulier des bugs susceptibles d'avoir des conséquences catastrophiques en stabilité et sécurité) en continuant en C++ que ce qui pourrait être fait en migrant des bouts vers Rust.
Mais si tu veux vraiment absolument un check de lifetime fiable et que c'est totalement critique, tu fais clairement du Rust plutôt que du C++ même avec Wlifetime, et je vois vraiment pas ça changer, du moins pas avant très longtemps (et même dans très longtemps, je pense que ça a une très faible proba que le C++ "rattrape" complètement le Rust sur ce point).
[^] # Re: Byuu, quel personnage !
Posté par Guillaume Knispel . En réponse au journal Petite histoire de la SD2SNES, et par là même du MSU1. Évalué à 5.
Il a pas arrêté longtemps de travailler sur des émulateurs; il a changé de pseudos et il code comme un fou un émulateur N64, depuis le leak géant:
https://twitter.com/ares_emu
[^] # Re: possession par l'employeur
Posté par Guillaume Knispel . En réponse au journal Contributions open source en entreprise. Évalué à 2. Dernière modification le 21 mars 2020 à 16:26.
Prend une tisane.
[^] # Re: Pas convaincu du tout
Posté par Guillaume Knispel . En réponse au journal Rappel : Si vous essayez de modéliser l'épidémie de Covid-19 et que votre modèle est dérivable …. Évalué à 2.
Par contre approximer par une gaussienne c'est effectivement pas très précis, mais ça devrait permettre d'obtenir un ordre de grandeur. Mais je suis pas sûr que ça soit suffisamment précis pour prédire par exemple la journée du nombre de mort max.
# Pas convaincu du tout
Posté par Guillaume Knispel . En réponse au journal Rappel : Si vous essayez de modéliser l'épidémie de Covid-19 et que votre modèle est dérivable …. Évalué à 2.
Tout le monde n'a pas le même temps d'incubation ni le même temps pour développer des symptômes sérieux.
[^] # Re: Méthodologie à améliorer
Posté par Guillaume Knispel . En réponse au journal Coronavirus : vers une sortie de crise ?. Évalué à 5.
Tu peux trouver les comptes rendus des réunions du conseil scientifique.
J'ai pas souvenir qu'ils disent qu'il faut continuer à travailler à tout prix, ni que la situation n'a rien à voir avec celle de l'Italie.
Maintenant il faut bien comprendre qu'ils ne peuvent pas non plus chier dans les médias sur le gouvernement. Ça serait probablement contre productif, le politique étant en général bien borné et totalement incapable d'admettre ses erreurs.
# possession par l'employeur
Posté par Guillaume Knispel . En réponse au journal Contributions open source en entreprise. Évalué à 7.
Concernant l'attribution à l'employeur s'appliquant en dehors des heures de travail, il faut préciser:
Ainsi si tu codes un truc qui n'a rien à voir en dehors de tes heures de boulot et sans utiliser de ressource de ton employeur, c'est à toi.
Concernant les contributions que tu fais au/pour le boulot donc, je pars du principe que ce qui n'est pas interdit est autorisé, et donc l'accord simple y compris informel de la hiérarchie me suffit amplement (approche à moduler selon le poste.)
La situation est pragmatiquement facilitée AMA pour les logiciels copyleft dans les situations où on a de toute façon que le choix entre publication des sources ou "inexistence" (sauf à mettre l'entreprise dans l'illégalité) de la modification. Je serais "paradoxalement" plus prudent pour contribuer au taf pour un truc sous MIT que pour un truc sous GPL (destiné a être mis dans un produit).
Concernant le risque personnel (cf. "vas-y contribue" peux se retourner en "tu as commis une faute en livrant des infos, dehors"), j'aime bien utiliser l'approche suivante : si une boite veut jouer à ce genre de jeux, j'aurais mieux à faire ailleurs de toute façon.
[^] # Re: Taxation
Posté par Guillaume Knispel . En réponse au journal JSON est dans les airs. Évalué à 4.
Ben ouai. Tu peux déjà acheter plein de merde polluante à produire ou rouler toute la journée dans une voiture très puissante et très polluante si ça t'amuse.
Et effectivement tu peux pour l'instant prendre l'avion en masse pour bénéficier d'un effet de levier sur ta pollution, si t'as envie d'utiliser ton pouvoir d'achat pour polluer encore plus.
[^] # Re: Plusieurs serveurs en ligne...
Posté par Guillaume Knispel . En réponse au journal JSON est dans les airs. Évalué à 5.
Je croyais qu'un avion était rempli d'avionique conçu pour une (ou quelques) familles, en tout cas conçus pour des avions.
Du coup en quoi c'est compliqué et/ou cher d'avoir des diodes physiques dans le design ?
Si la diode est purement logicielle, ça veut dire que qu'il y a un lien de données bidirectionnel que seul le logiciel diode en question peut piloter côté sécurisé. Il est réputé simple et fiable, mais est-il audité par des chercheurs indépendants en sécu informatique appliquant des tests d'attaque de l'état de l'art, ou est-ce en fait du whishful-thinking ? Si les coûts des audits sérieux sont pris en compte, est-ce toujours aussi intéressant d'éviter de coller une diode physique dans la conception ?
Je pose ces questions, car habituellement dans les industries un peu "opaques", dès que des indépendants en sécu informatique commencent à creuser, ils se rendent compte immédiatement du désastre. Ex les vulns de partout dans les réseaux télécom, ou les vulns dans les systèmes informatique/contrôle commande industriels critiques (cf les confs du C3)
[^] # Re: attention
Posté par Guillaume Knispel . En réponse au journal Informatique et écologie. Évalué à 3.
Mwai mais pour le reste aussi, en général (et en ordre de grandeur), nan ?
[^] # Re: Joli lancer !
Posté par Guillaume Knispel . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 2.
Ça laisse quand même au minimum entre 2020 et 2023 sans solution sérieuse.
Mais on reste en UB sur overflow. Non plus pour les raisons historiques de l'UB (difference entre 2 procs), mais bien uniquement pour les raisons postmodernes : "opti" (avec les guillemets pour indiquer que c'est avec la technique des transformations valides uniquement sous hypothèse, typiquement non prouvée, d'absence d'UB). Après étant donné l'impact sur le codegen des indexations sur x86, peut-être que cette opti là c'est une des rare que je "veux" peut-être (en compromis)—mais faudrait voir si on peut pas prouver les non débordements au lieu d'en faire l'hypothèse, ainsi que bencher avec/sans. Il y a des bases de code majeures (ex : Linux) qui compilent en fno-strict-overflow ou fwrapv, donc probablement que c'est pas si crucial que ça, en fait.
Et il est extrêmement bienvenue, même si on arrivait à faire du multithread avant. Tout comme on arrive à faire de la shm ou du mmap aujourd'hui, alors que dans la machine abstraite c'est pas officiellement prévu. C et C++ avaient ce statut spécial nécessaire pour les langages systèmes ; la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes. La tendance postmoderne des implémenteurs est beaucoup plus de se contenter de la norme et d'ignorer tous les problèmes concrets que cet extrémisme engendre (et rejeter la faute sur les utilisateurs du compilo au lieu d'améliorer la qualité d'implémentation).
Justement. S'il refuse obstinément de prendre raisonnablement ce tournant, mon hypothèse c'est qu'il va passer de statut de langage système absolument majeur à celui de langage de niche. Et encore. Vu que j'arrive même pas à coder d'allocateur avec sans faire 42 UB formelles par ligne, j'ai du mal à voir quel niche il va finir par occuper : jeu vidéo offline, peut-être. Hm même ça, ça n'existera bientôt plus trop.
[^] # Re: Le C++
Posté par Guillaume Knispel . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 3.
Mwai j'ai écris ça trop vite c'est vrai, j'aurais du le reprendre et poster demain.
[^] # Re: ... quelques problèmes (notamment sur l'espace disque): ne pas utiliser une BD ! URL + fichiers
Posté par Guillaume Knispel . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
Hm comme souvent y a probablement des avantages et des inconvénients des deux côtés…
Par exemple git utilise des hard links pour avoir des clones locaux légers. Alors certes si on a pas ça on peut envisager un modèle plus worktree-style, mais avec ça aussi il y a des avantages et des inconvénients.
On peut encore noter la possibilité de gérer des dépots gigantesques "simplement" en virtualisant le FS (enfin c'était le plus gros du boulot)—MS a fait ça pour mettre tout le code source de Windows sous Git.
Enfin je connais pas les internals de Git mais je vois pas trop pourquoi on pourrait pas construire des structures de données plus complexes que des listes chaînées en partant d'un tel modèle ni en quoi ça disqualifirait pour être un "chercheur en informatique" (au contraire…)
Ceci étant dit, je ne déteste pas le fait d'utiliser une DB, mais simplement à lire votre échange, hm, c'est pas en jouant au tennis à coup de qui a "loupé un truc" que chacun va être incité à améliorer sereinement ses connaissances et sa compréhension des compromis, avantages et inconvénients de chaque solution.
[^] # Re: Et la profession libérale ?
Posté par Guillaume Knispel . En réponse au journal Devenir un indépendant libre. Évalué à 2.
Je comprends ce que ça veut dire mais je déteste l'approche qui prétend décorréler la "qualité" du code; ça veut juste dire que la "qualité" en question n'a pas (suffisamment) d'impact réel—c'est juste de la "qualité" au lieu d'être simplement de la qualité…
[^] # Re: Certes, mais pour quels usages ?
Posté par Guillaume Knispel . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 5. Dernière modification le 17 janvier 2019 à 19:59.
Je ne dis pas que c'est impossible de faire de très bonne choses avec un FPGA, ni même que ça n'a pas des avantages par rapport à un PC puissant + des émulateurs full-soft précis. Simplement ça n'est pas magique (surtout en ce qui concerne la fidélité), et ça a aussi des inconvénients. Donc à chacun de voir lesquels des avantages il privilégie et qu'est ce qu'il veut en faire. De toutes façons on a atteint un stade où les jeux majeurs, y compris souvent pour des consoles relativement "récentes" (Wii, etc.) tournent suffisamment bien même avec des solutions pas forcement 100% précises. Et on a aussi pas mal d'émulateurs qui utilisent des techniques de haut niveau pour améliorer l'expérience de jeu plutôt que de privilégier la fidélité; et c'est très bien : ça plaît à beaucoup de monde !
[^] # Re: Certes, mais pour quels usages ?
Posté par Guillaume Knispel . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 10.
Hm c'est pas si simple que ça.
Un CPU high end moderne a une puissance démesurée et est cadencé super rapidement. On peut émuler une SNES quasi-parfaitement là-dessus (et en pratique tous les jeux ayant été édités sur SNES tournent parfaitement), et certes ça consomme un peu toute cette puissance mais en fait le problème principal est plus de reverse le hard d'origine avec un niveau de précision ultra fin et une bonne réimplantation, que la puissance nécessaire au runtime (puisque cette dernière est dispo sur étagère). Cf le projet higan.
De même, la réimplantation dans un FPGA ne va pas se faire d'une manière magique. Ni d'une manière "naïve" ou "triviale" (en copiant le hard d'origine bloc par bloc). Du coup le boulot est tout autant conséquent, et par exemple un projet commercial aura plus tendance à privilégier un peu les hacks (avec par exemple du tuning par jeu pour les plus courant, voire des patchs des ROMs connues) qu'une émulation absolument parfaite.
Et en plus, d'un point de vue conservation, on peut arguer que le résultat n'est pas aussi puissant qu'un émulateur full-soft, vu que le FPGA cible et la board cible va avoir son propre cycle d’obsolescence, alors qu'un soft peut être très largement portable pour son moteur d'émulation et pour les petits bouts d'IO la maintenance est relativement facile (et peut potentiellement n'être nécessaire que rarement).
Et la complexité de la réimplé augmente bien évidemment sur des consoles plus puissantes.
Enfin sur de la 3D on arrête rapidement l'émulation low level pour passer sur une traduction des primitives graphiques vers une API moderne, et là un FPGA n'aidera pas.
[^] # Re: Pauvres élèves qui aiment les sciences
Posté par Guillaume Knispel . En réponse au journal La spécialité N.S.I. de la réforme du lycée. Évalué à 10.
Ben faut bien défoncer le public dans des secteurs importants pour laisser la magie du marché libre opérer, nan ?
[^] # Re: secret défense
Posté par Guillaume Knispel . En réponse au journal Thales rejoint la fondation RISC-V pour participer à la sécurisation des uProcesseurs open source. Évalué à 8.
C'est extrêmement dur de se prévaloir d'une expertise en sécurité si tout est secret (ou en quoique ce soit, d'ailleurs, mais en fait encore plus particulièrement en sécu)
Même la NSA publie des trucs…
En passant j'ai fait un peu de presta pour Thales il y a quelques années et du micro échantillon que j'en ai vu à l'époque, la culture m'a semblé ultra corporate avec assez peu de collaboration interne hors cadre d'un contrat (les différents BU passant des appels d'offre auxquelles les autres et les externes peuvent répondent simultanément, et "grâce" à ce système Thales maintenait/adaptait probablement la même bibliothèque des dizaines de fois sans que les gens qui travaillent réellement dessus puissent ne serait-ce que savoir qui sont les autres—et ce y compris pour être intégré en tant que composant dans un même système). Pour faire de la sécu à un bon niveau, il faut de la collaboration informelle y compris en dehors de l'entreprise. Alors je sais pas si ça fonctionne toujours comme ça et si c'est global à tout Thales, mais si déjà c'est si dur de collaborer informellement en interne, en externe j'ose même pas imaginer.
[^] # Re: Mon histoire avec le C++
Posté par Guillaume Knispel . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 6.
La portabilité du C++ moderne, y compris et surtout avec une bibliothèque standard moderne, n'a rien a voir du tout avec la situation que tu as vécu lors de ton utilisation initiale. Les progrès ont été énormes surtout ces dernière années avec la mise en conformité et le rattrapage de MS pour MSVC (gcc et clang sous Nux étaient déjà beaucoup plus conformes depuis quelques années de plus).
Aujourd'hui pour la plupart des applications dans les domaines ou le C++ est applicable, il est de moins en moins pensable de s'abstenir d'utiliser la bibliothèque standard. La plupart de ceux qui le faisaient avaient de bonne raisons historiquement, mais au fur et à mesure de l'évolution du langage, les freins historiques sont traités et les raisons en question disparaissent ou s'amenuisent, et même certains projets historiques migrent petit à petit vers de plus en plus de bibliothèque standard. Permettre cela semble même être un des critères essentiels pour les évolutions du langage décidées par le commité.