On peut le voir comme ça, mais on peut aussi le faire sans s'éloigner de la réalité. Il s'agit simplement, par exemple, de présenter son parcours professionel pas juste comme une suite d'emplois déconnectés les uns des autres, mais comme une continuité avec des raisons pour les changements.
En gros, en partant de'un cv:
de 1826 à 1829: dévelopeur chez Machin Industries
de 1829 à 1835: chef de projet chez Truc et Compagnie
en expliquant que il y avaxt peu de chances qu'un poste de cqef se libère chez Machin, et que ça twas décidé à aller voir chez Truc si c'était mieux. Ce qui permet d'enchaîner sur la suite du parcours: oui c'était mieux, mais maintenant ça ne l'est plus, ou alors c'est toujours bien mais tu as envie de devenir chef de chef de projet, ou toute autre raison.
Si tu sais présenter ce genre d'explication sans préparation, tant mieux, mais sinon ça peut valoir le coup d'y réfléchir un peu en avance. Finalement, ça peut permettre de prendre un peu de hauteur sur un parcours professionel, et c'est plutôt intéressant (parce que les donées brutes, on les a déjà dans le cv, normalement le recruteur les a lues avant l'entretien et ce n'est pas la peine de juste les répéter).
Alors oui, le "narratif" c'est une technique commerciale. Y'a pas de secret, dans un entretien d'embauche, une partie consiste à se vendre, en se présentant sous son meilleur jour. Et ça peut être fait de façon plus ou moins honnête, mais je ne vois pas trop l'intérêt de raconter n'importe quoi pour décrocher un job qui ne te convient pas?
Bon, mon job actuel, j'y suis depuis 10 ans, c'est que ça doit pas être si pourri que ça. Le seul truc embêtant en ce mome/t c'est que mon client construit des engins miniers, se dire que ce qu'on fait va servir à améliorer la productivité de l'extraction du charbon, ça n'est pas très compatible avec mon penchant écologiste. Mais c'est le jeu des ESN, on ne choisit pas direcement ses clients. À part ça, les collègues sont sympa, compétents et motivés, le projet est techniquement intéressant, on me laisse travailler comme je veux, et j'ai même le droit d'utiliser Linux sur mon PC.
Du coup je vais plutôt parler des jobs précédents:
Mon premier emploi était dans une petite entreprise (tout juste 10 salariés), une startup qui n'a pas vraiment décollé mais qui survit. C'était le premier emploi de tous les collègues et ils sortaient presque tous de la même formation, ce qui donnait une monoculture technique pas extraordinaire. Mais surtout, les délais imposés par l'équipe commerciale (qui faisait les plannings) étaient irréalistes et nous imposaient de développer trop rapidement des solutions propres à chaque client, au lieu de prendre un peu de temps pour factoriser les choses. On avait fait une roadmap avec des post-its sur un mur. Au bout d'un an, un seul post-it avaiù bougé. Au bout de 2 ans, les post-its ont été recouverts avec un tableau blanc pour faire autre chose. Je suis parti à ce moment là, marre de trourer en rond en réimplémentant plusieurs fois la même fonction pour plusieurs clients et de ne pas avancer sur les sujets de fond.
Ensuite j'ai testé oe travailler pour un projet open source. Full télétravail, totale autonomie pour faire ce que je voulais. C'est bien, mais ça paye vraiment pas cher (l'association qui gère le projet n'avait pas beaucoup de sous). Et surtout, la personne qui faisait tourner l'association, relançait les donateurs, etc, a fini par partir. Les dernières factures ont été payées avec un ou deux mois de retard puis le contrat s'est arrêté quand il n'y avait plus de sous avec un préavis de 15 jours. Aujourd'hui je suis moins jeune et moins inconscient, je ne le referai pas sans des garanties plus solides.
Enfin j'ai fait des missions dans mon ESN chez des clie/ts qui ont voulu m'embaucher. J'ai refusé pour les mêmes raisons à peu près: structures trop petites, qui ne mettent pas les moyens qui seraient nécessaires pour ce qu'elles veulent faire. Mais il y a certainement des projets où c'est l'inverse: trop de moyens pour faire une usine à gaz inutile. Je crois que là où je suis, l'équilibre est à peu près bon.
Mouais, alors ça marche si dans "centre" on compte le centre droit, avec vraiment tout le monde: LIOT, le MoDem et Horizons. Et encore, ça donne la majorité absolue à 3 sièges près. Ça marche, mais il suffit qu'une paire députés (à droite ou à gauche du truc) changent d'avis et de groupe pour que la majorité absolue disparaisse.
Si vous voulez tenter vos propres mélanges politiques plus ou moins improbables, on trouve des simulateurs pour ça, par exemple chez Le Monde
Oui, ça a tendance à créer des "boîtes noires" dans lesquelles on a du mal à comprendre comment ça fonctionne.
Ça ne veut pas dire que la techno est mauvaise, si cette boîte noire fonctionne mieux que les algorithmes connus, elle peut très bien s'utiliser, et ça a d'autres avantages (par exemple, être capable de s'adapter automatiquement et de continuer à s'entraîner avec de nouvelles données en entrées).
Mais j'avoue ne pas bien comprendre comment ça peut être utile pour modéliser quelque chose, si on ne comprend pas mieux le fonctionnement du modèle que celui de l'original. Ça n'empêche pas que ça pourrait servir à plein d'autres choses: dans ce cas précis, peut-être que ça pourrait servir à prédire seulement quelques images à l'avance, dans un jeu vidéo en ligne, en attendant de se resynchroniser avec le serveur? Est-ce que ça peut fonctionner plus vite qu'une latence réseau classique?
Cela dit, il est probable qu'on fasse du progrès sur la façon d'étudier un réseau de neurones pour comprendre ce qu'il fait. Les outils nous manquent pour l'instant mais ça se développe. On se souvient par exemple des premiers tests de génération d'images de Google DeepDream, qui avaient démarré comme une expérience pour comprendre comment leur algorithme de reconnaissance d'image fonctionnait, en essayant de visualiser et d'amplifier ce qui était reconnu dans une image. On peut aussi identiifer des "zones" (des ensemble de neurones interconnectés) qui s'activent dans certains cas, mais ça reste une vision à très haut niveau.
Les dévelopeurs Rust qui esaient de participer au noyau Linux sont pour certains aussi impliqués dans Redox. Mais il y a pas mal de travail à faire dans Redox avant d'avoir un système utilisable.
C'est donc pas une mauvaise idée d'essayer de faire avancer Rust dans Linux en attendant, et on pourrait même envisager que certains modules soit portables entre les deux.
Mais si les développeurs de Linux se montrent complètement réfractaires à cette idée (comme ils l'ont été avec C++ il y a quelques années), il est probable que les développeurs qui ont envie de faire du code noyau en Rust aillent voir ailleurs.
Ce n'est pas forcément un reproche pour les développeurs de Linux: maintenir un projet avec un mélange de 2 langages de programmation pose aussi un certain nombre de problèmes. Personellement je l'envisagerais pour migrer d'un langage à un autre progressivement, mais pas pour maintenir éternellement les 2 langages.
La mauvaise qualité du chiffre Allemand est en partie la raison de leur défaite.
On parle de la seconde guerre mondiale et des machines Enigma, là?
Parce qu'il a quand même fallu faire pas mal de progrès en informatique (qui n'existait presque pas avant la guerre) pour venir à bout de ce chiffrement.
Il était suffisant pour son époque, tout comme les algorithmes utilisés aujourd'hui ne survivront peut-être pas au développement de l'informatique quantique ou à d'autres innovations.
Mais là on a un modèle où une porte sensée être verrouillée finit par s'ouvrir quand même sans avoir été chercher la clé, des ennemis qui disparaissent sans qu'on leur tire dessus ou qui réapparaissent, etc.
C'est donc une modélisation qui n'a aucune utilité pour comprendre comment le jeu fonctionne.
L'intérêt d'une modélisation, il est non seulement dans l'utilisation du modèle, mais aussi dans sa construction: s'interroger sur quels sont les paramètres essentiels à modéliser et les choses qui sont négligeables. Oui, ça prend du temps, mais c'est du temps passé à comprendre comment le système fonctionne.
Ici, l'IA a créé un modèle dont on ne sait pas trop comment il fonctionne, et qui se comporte vaguement comme le système original, mais seulement en apparence. Et il est peut-être plus compliqué à étudier que le système original. Du coup, ça nous avance à quoi?
Personellement, le code incompréhensible, j'en trouve dans Linux mais moins dans d'autres systèmes d'exploitation. Le fait cue ça soit du code noyau n'est pas une excuse pour l'absence de commentaires, les APIs mal documentées, l'absence de logs alors qu'un framework existe pour en faire.
Je crois surtout que la lisibilité du code n'est pas un critère hrioritaire pour les développeurs de drivers (ils ont surtout envie que ça fonctionne sur le matériel sur lequel ils sont en train de travailler).
L'excuse de "oui mais c'est du code noyau, les règles et bonnes pratiques de l'industrie ne s'appliquent pas" a un côté élitiste que je n'aime pas trop. Au contraire, c'est du code critique pour lequel il faudrait faire deux fois plus attention à ce qu'il soit clair et facile à suivre.
On peut ajouter que le concurrent principal, Tom's hardware, appartient au même éditeur. Ce n'était probablement pas utile de s'autoconcurrencer et il vaut mieux un gros site que deux plus petits?
c'est plus difficile d'en parler tous les jours dans un journal
ça marche assez bien avec la guerre russo-ukrainienne ou on a des nouvelles dès que la ligne de front bouge d'une centaine de mètres, avec des cartes mises à jour et tout. Je n'ai pas trop vu passer la même chose pour les feux de forêt (ça doit pouvoir se trouver, mais les Grands Méchants Algorithmes n'ont pas l'air d'envoyer les infos jusque chez moi).
Le clavier FrogPad (qui s'utilise à une seule main et pourrait se porter en bracelet) n'est plus fabriqué, c'est bien dommage. Ce serait parfait pour cette utilisation.
En enlevant le clavier affiché sur l'écran du smartphone, on doit déjà à peu près doubler l'espace disponible pour afficher des choses. Pour une utilisation simple (et si on a une bonne vue et qu'on peut mettre une police de caractères assez petite, et si on a un smartphone moderne avec un grand écran) il n'y a peut-être pas besoin d'un écran externe? Après tout, il n'y a pas si longtemps on avait que 640x480 pixels et on se débrouillait bien avec?
mais la politique, y compris de ceux qui le voudraient mais font des caricatures en argumentant, en a décidé autrement, et le coût est donc sur la migration des derniers terminaux 2G, par choix politique.
C'est un choix qui n'est pas délirant. En particulier il permet de libérer les fréquences radio utilisées et de les réattribuer à un système plus récwnt qui en fera une utilisation plus efficace (par exemple: plus de débit pour une bande de fréquence équivalente, meilleure portée à puissance d'émission équivalente, …).
La politique elle est surtout dans ce qu'on choisit de faire de l'espace arnsi libéré. Par exemple pour la télévision, onea choisi de mettore plus de chaînes de TV sur chaque fréquence. On aurait pu choisir de garder autant de chaînes qu'avant (environ 6, il me semble) et d'utiliser moins de bandes de fréquence pour la télévision.
Les bandes fréquence dsponibles n'étant pas illimitées, le choix de "on garde le même système pas efficace pendant 100 ans" est difficilement défendable.
l'ensemble est désormais publié sous cette licence
oui et non: s'il n'y a que ces deux fichiers qui sont sous gpl3, il n'est pas difficile de les enlever et de faire une version de forgejo qui est encore sous la license précédente.
ça n'empêchera donc probablement pas Gitea de récupérer les autres contributions.
Il reste à voir si la pratique va se développer ou si au contraire, quelqu'un s'amuse à réécrire ces fichiers avec une license plus permissive.
Ce signal émis exactement à la fréquence naturelle de l'hydrogène était donc émis par de l'hydrogène, et pas par des extraterrestres ayant choisi la fréquence la plus encombrée de l'univers pour essayer de nous joindre.
Moi, si j'étais un extraterrestre, j'aurais plutôt choisi une fréquence plus calme, et vous?
ce que dit l'article à la fin, c'est que c'est bien le cas:
Précisons par ailleurs que pour lancer une mise à jour, la Tesla doit être garée en mode « park ». Un compte à rebours de deux minutes se lance, permettant d’annuler le processus de mise à jour. On se demande donc comment ce conducteur a pu se retrouver dans cette situation.
Donc si je comprend bien:
Le pilote a vu une notification de mise à jour sur son écran,
Il a cliqué sur "mettre à jour maintenant",
Il a activé son frein à main (c'est le mode "park"),
Il a attendu pendant 2 minutes sur l'écran lui disant "êtes vous sûr de vouloir installer cette mise à jour?" (à ce moment là, le feu rouge auquel il était arrêté a du repasser au vert)
Sur les plateformes mobile (c'est là que beaucoup de choses se jouent désormais) il y a sûrement plein de choses à faire. La preuve, c'est que plein d'entreprises insistent pour développer des applications natives pour les téléphones, là où un site web conviendrait parfaitement. Si le site pouvait envoyer des notifications sans le garder dans un onglet ouvert. Si on pouvait facilement mettre temporairement une page en marque-page (par exemple pour y retrouver un billet de train dématérialisé, avec les infos si le train est à l'heure, etc).
Cela dit, après une ou deux décénnies de révolution constante des interfaces informatiques, on a peut-être aussi besoin de respirer un peu avant de plonger dans le prochain changement de paradigme?
J'apprécie toujours de lire des projets qui font preuve de transparence sur les dons reçus et sur les dépenses. C'est intéressant de pouvoir comparer avec d'autres projets, et c'est aussi plutôt bon signe pour la gouvernance du projet qui prend le temps de publier ces informations de façon claire et lisible
Tu es entrain de dire qu'avoir un seul acteur c'est bien ? J'en crois pas mes yeux on est sur LinuxFR ?
On applique cela aussi aux OS, aux traitements de texte, … Tout serait tellement plus simple non ?
Non, pour me faire dire ça, il faudrait penser que l'innovation, c'est forcément bien.
Je constate que, avec un quasi-monopole, Google peut se permettre de faire évoluer la plateforme web et jintroduire comme il veut plein de fonctionalités ou d'anti-fonctionalités, sans se préoccuper de discuter ça avec les autres imhlémentations.
Je suis bien hlus à lwaise dans un univers technologique qui évolue moins vite, en prenant le temps de ne faire que les évolutions qui sont nécessaires. Moins d'innovation, mais plus d'améliorations. Par exemple POSIX ou le langage C, avec une version tous les 5 ans, c'est un rythme qui permet d'anticiper. Si on avait une version majeure de HTML ou de CSS tous les 5 ans, ça serait mieux cue le bazar actuel. Tout en étant moins propice à l'innovation à coup d'extensions non standardisées.
Internet Explorer/Trident comme moteur de l'innovation? Mouais, c'est plus compliqué que ça.
À l'époque, le w3c était fonctionnel: on avait oes versions majeures de html (la dernière étant la 4) avec un ensemble bien défini de fonctionalités. Même chose pour le css. L'innovation était donc plus lente, ou alors il fallait développer des sites fonctionnant avec les 3 ou 4 moteurs concurrents avec chacun leurs extensions non-standard.
Maintenant qu'on a un moteur dominant, Google peut unilatéralement innover des trucs dedans, et les autres courrent derrière pour rattraper. Les choses sont ensuites standardisées par le whatwg et ajoutées dans "html5" qui est en évolution perpétuelle.
De mon point de vue de développeur de navigateur, la différence se voit très bien. Autour de 2010, avoir un navigateur avec 4 ans de retard sur les concurrents ne posait pas trop de problèmes, parce que internet explorer 6 tirait les choses vers l'arrière et que le html4 était un standard fixe n'évoluant pas du tout. Aujourd'hui, si on ne déploie pas dans les 6 mois les dernières nouveautés et corrections de bugs, on a des sites qui se mettent à ne plus fonctionner.
Dans cet environnement complexe, assez technique, et ou l'innovation ne fait pas vendre (les navigateurs sont gratuits et les sites web gagnent surtout à s'afficher correctement partout), les règles théorique de l'économie et de la concurrence libre et non faussée ne s'appliquent pas.
Dans mes messages j'ai comparé plutôt partir de WebKit et partir de Firefox. Je me suis jamais posé la question de recréer un truc à partir de zéro.
Même pour des besoins plus simple, on pourrait regarder du côté de NetSurf, dont l'équipe fait un très bon travail sur les performances pour les petites machines (utilisation mémoire qui se mesure en Mo et vitesse en MHz) ou de Dillo qui est à nouveau actif depuis quelque temps.
Donc, personellement, je n'envisagerai ni de partir de zéro, ni de regarder chez Firefox,parce qu'il y a pas mal de choix ailleurs et que, pour les autres moteurs, on ne parle pas d'un fork "dur", mais d'un truc où on peut collaborer avec l'upstream et intégrer facilement leurs développements. Sinon, on se retrouve assez vite dépassé, comme c'est arrivé il me semble à Classilla, Camino, Galeon, K-Meleon et autres navigateurs basés sur Gecko. Il reste peut-être PaleMoon, mais j'ai pas envie d'aller voir de ce côté à cause de l'ambiance et des opinions politiques des développeurs. Il est basé sur Firefox 52 et backporte certains trucs des versions suivantes mais conserve l'API XUL qui permet de construire des applications web utilisant le moteur (rebaptisé Goanna). Je ne sais pas trop quel est le résultat pour naviguer sur le web moderne.
Toute la difficutslté d'un projet informatique, ce n'est pas d'écrire le code, mais de s'assurer que le code fait bien ce qui est demandé dans la spécification (ou que la documentation documente bien ce que fait le code).
Du code généré par un LLM fait ça moins bien qu'un déâeloppeur, et si on lui dit "hé, tu t'es trompé, c'est pas ce qu'on t'a demandé" il va répondre "oh, je suis désolé, vous avez raison, voici le code corrigé" et remettre un bout de code avec le même bug.
Dans le cas d'une traduction d'un langage à un autre, il faudrait entraîner un modèle spécial en lui fournissant du code c++ et la version traduite. Puis lui demander de "faire la même chose" sur d'autres morceaux de code. Le tout avec des tests pour valider si les traductions générées fonctionnent (@qui doivent être écrits au cas par cas, j'imagine?). Quel volume de code et de tests faut-il traduire à la main avant d'avoir assez de données pour avoir un traducteur fonctionnel? Est-ce qu'il restera encore du code non traduit quelque part une fois cet entraînement terminé?
Je me demande si on ne devrait pas (les developpeurs) mettre plus les mains dans sous le capot de firefox ou de webkit. Je ne sais pas à quel point la base de code est horrible à reprendre, mais elle doit être à la fois, collossale, particulierement complexe et comporter pas mal de code historique plus ou moins documenté.
Bonjour,
Je maintiens le navigateur WebPositive de Haiku qui est basé sur WebKit. Je me rend la vie compliquée avec une version de WebKit fonctionnant sur un OS différent, et je dois donc maintenir tout un tas de choses en particulier au niveau du rendu graphique (branché sur nos APIs natives au lieu d'utiliser Skia ou Cairo comme tout le monde), par exemple.
Mais pour développer un navigateur pour Linux ou Windows, il n'y a pas besoin de ça: vous prenez la dernière version de GTKWebKit et cela vous fournit les APIs nécessaires pour développer un navigateur. C'est faisable sans toucher à 99% du code de WebKit.
Ensuite il sera toujours possible de commencer à creuser pour régler des problèmes. Mes contacts avec les développeurs de WebKit sont assez bons lorsque j'ai des questions. Ils utilisent Slack pour collaborer (c'est pas génial, je préférais quand il y avait un canal IRC, mais ça a été tué par le rachat de Freenode). Les contributeurs externes m'ont l'air plutôt bien accueillis.
Je ne sais pas du tout comment les choses se passent pour Firefox à ce niveau. Mais je sais qu'il n'y a pas d'API permettant de créer un nouveau navigateur utilisant le même moteur. Dans ce cas, il faudrait plutôt partir sur un fork de tout l'ensemble (moteur + navigateur) ce qui ne facilite pas la collaboration entre projets. Ou alors envoyer des patchs à Mozilla pour retirer les fonctionnalités pénibles (trackers, add-ons préinstallés, …) mais là, bon courage pour faire accepter les changements?
Le problème pourrait aussi se trouver du côté des versements de grosses sommes d'argent à des développeurs de navigateurs web pour les pousser à configurer Google comme moteur de recherche par défaut dans leurs produits.
Si cette pratique est interdite, cela nuirait à Apple et surtout à Mozilla, qui bénéficient de ce type de contrats et se verraient privés d'une source de revenus.
En ce moment j'ncadre un des participants du Google Summer of Code qui est en train de migrer notre port de WebKit de l'API WebKitLegacy vers la "nouvelle" API WebKit2 (nouvelle entre guillemets parce qu'on a plus de 10 ans de retard pour cette migration).
Après ça, je vais prendre quelques vacances (j'en ai effectivement besoin) et je pourrai ensuite m'occuper ge l'upstreaming sans avoir à imposer à WebKit de prolonger l'existence oe l'API legacy plus longtemps que ce que nécessitent les besoins de Apple (qui maintient cette API en vie pour les besoins de quelques vieilles applications iOS, il me semble).
[^] # Re: État d’esprit
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal cherche nouveau boulot. Évalué à 3.
On peut le voir comme ça, mais on peut aussi le faire sans s'éloigner de la réalité. Il s'agit simplement, par exemple, de présenter son parcours professionel pas juste comme une suite d'emplois déconnectés les uns des autres, mais comme une continuité avec des raisons pour les changements.
En gros, en partant de'un cv:
en expliquant que il y avaxt peu de chances qu'un poste de cqef se libère chez Machin, et que ça twas décidé à aller voir chez Truc si c'était mieux. Ce qui permet d'enchaîner sur la suite du parcours: oui c'était mieux, mais maintenant ça ne l'est plus, ou alors c'est toujours bien mais tu as envie de devenir chef de chef de projet, ou toute autre raison.
Si tu sais présenter ce genre d'explication sans préparation, tant mieux, mais sinon ça peut valoir le coup d'y réfléchir un peu en avance. Finalement, ça peut permettre de prendre un peu de hauteur sur un parcours professionel, et c'est plutôt intéressant (parce que les donées brutes, on les a déjà dans le cv, normalement le recruteur les a lues avant l'entretien et ce n'est pas la peine de juste les répéter).
Alors oui, le "narratif" c'est une technique commerciale. Y'a pas de secret, dans un entretien d'embauche, une partie consiste à se vendre, en se présentant sous son meilleur jour. Et ça peut être fait de façon plus ou moins honnête, mais je ne vois pas trop l'intérêt de raconter n'importe quoi pour décrocher un job qui ne te convient pas?
# Pourquoi c'est pourri
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal cherche nouveau boulot. Évalué à 5.
Bon, mon job actuel, j'y suis depuis 10 ans, c'est que ça doit pas être si pourri que ça. Le seul truc embêtant en ce mome/t c'est que mon client construit des engins miniers, se dire que ce qu'on fait va servir à améliorer la productivité de l'extraction du charbon, ça n'est pas très compatible avec mon penchant écologiste. Mais c'est le jeu des ESN, on ne choisit pas direcement ses clients. À part ça, les collègues sont sympa, compétents et motivés, le projet est techniquement intéressant, on me laisse travailler comme je veux, et j'ai même le droit d'utiliser Linux sur mon PC.
Du coup je vais plutôt parler des jobs précédents:
Mon premier emploi était dans une petite entreprise (tout juste 10 salariés), une startup qui n'a pas vraiment décollé mais qui survit. C'était le premier emploi de tous les collègues et ils sortaient presque tous de la même formation, ce qui donnait une monoculture technique pas extraordinaire. Mais surtout, les délais imposés par l'équipe commerciale (qui faisait les plannings) étaient irréalistes et nous imposaient de développer trop rapidement des solutions propres à chaque client, au lieu de prendre un peu de temps pour factoriser les choses. On avait fait une roadmap avec des post-its sur un mur. Au bout d'un an, un seul post-it avaiù bougé. Au bout de 2 ans, les post-its ont été recouverts avec un tableau blanc pour faire autre chose. Je suis parti à ce moment là, marre de trourer en rond en réimplémentant plusieurs fois la même fonction pour plusieurs clients et de ne pas avancer sur les sujets de fond.
Ensuite j'ai testé oe travailler pour un projet open source. Full télétravail, totale autonomie pour faire ce que je voulais. C'est bien, mais ça paye vraiment pas cher (l'association qui gère le projet n'avait pas beaucoup de sous). Et surtout, la personne qui faisait tourner l'association, relançait les donateurs, etc, a fini par partir. Les dernières factures ont été payées avec un ou deux mois de retard puis le contrat s'est arrêté quand il n'y avait plus de sous avec un préavis de 15 jours. Aujourd'hui je suis moins jeune et moins inconscient, je ne le referai pas sans des garanties plus solides.
Enfin j'ai fait des missions dans mon ESN chez des clie/ts qui ont voulu m'embaucher. J'ai refusé pour les mêmes raisons à peu près: structures trop petites, qui ne mettent pas les moyens qui seraient nécessaires pour ce qu'elles veulent faire. Mais il y a certainement des projets où c'est l'inverse: trop de moyens pour faire une usine à gaz inutile. Je crois que là où je suis, l'équilibre est à peu près bon.
[^] # Re: Oui, droit à l'oubli, droit à changer d'avis : démocrate et lté d'exp.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Droit à l'oubli ?. Évalué à 7.
Mouais, alors ça marche si dans "centre" on compte le centre droit, avec vraiment tout le monde: LIOT, le MoDem et Horizons. Et encore, ça donne la majorité absolue à 3 sièges près. Ça marche, mais il suffit qu'une paire députés (à droite ou à gauche du truc) changent d'avis et de groupe pour que la majorité absolue disparaisse.
Si vous voulez tenter vos propres mélanges politiques plus ou moins improbables, on trouve des simulateurs pour ça, par exemple chez Le Monde
[^] # Re: Le jeu recréé?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le jeu Doom recréé par une IA après qu'elle y a joué plusieurs milliers de parties. Évalué à 2. Dernière modification le 02 septembre 2024 à 14:39.
Oui, ça a tendance à créer des "boîtes noires" dans lesquelles on a du mal à comprendre comment ça fonctionne.
Ça ne veut pas dire que la techno est mauvaise, si cette boîte noire fonctionne mieux que les algorithmes connus, elle peut très bien s'utiliser, et ça a d'autres avantages (par exemple, être capable de s'adapter automatiquement et de continuer à s'entraîner avec de nouvelles données en entrées).
Mais j'avoue ne pas bien comprendre comment ça peut être utile pour modéliser quelque chose, si on ne comprend pas mieux le fonctionnement du modèle que celui de l'original. Ça n'empêche pas que ça pourrait servir à plein d'autres choses: dans ce cas précis, peut-être que ça pourrait servir à prédire seulement quelques images à l'avance, dans un jeu vidéo en ligne, en attendant de se resynchroniser avec le serveur? Est-ce que ça peut fonctionner plus vite qu'une latence réseau classique?
Cela dit, il est probable qu'on fasse du progrès sur la façon d'étudier un réseau de neurones pour comprendre ce qu'il fait. Les outils nous manquent pour l'instant mais ça se développe. On se souvient par exemple des premiers tests de génération d'images de Google DeepDream, qui avaient démarré comme une expérience pour comprendre comment leur algorithme de reconnaissance d'image fonctionnait, en essayant de visualiser et d'amplifier ce qui était reconnu dans une image. On peut aussi identiifer des "zones" (des ensemble de neurones interconnectés) qui s'activent dans certains cas, mais ça reste une vision à très haut niveau.
[^] # Re: OK, l'humain, c'est compliqué....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Réactions de David Airlie (Red Hat) et Asahi Lina (d'Asahi) à propos de Rust dans le noyau Linux. Évalué à 3.
Les dévelopeurs Rust qui esaient de participer au noyau Linux sont pour certains aussi impliqués dans Redox. Mais il y a pas mal de travail à faire dans Redox avant d'avoir un système utilisable.
C'est donc pas une mauvaise idée d'essayer de faire avancer Rust dans Linux en attendant, et on pourrait même envisager que certains modules soit portables entre les deux.
Mais si les développeurs de Linux se montrent complètement réfractaires à cette idée (comme ils l'ont été avec C++ il y a quelques années), il est probable que les développeurs qui ont envie de faire du code noyau en Rust aillent voir ailleurs.
Ce n'est pas forcément un reproche pour les développeurs de Linux: maintenir un projet avec un mélange de 2 langages de programmation pose aussi un certain nombre de problèmes. Personellement je l'envisagerais pour migrer d'un langage à un autre progressivement, mais pas pour maintenir éternellement les 2 langages.
# Le chiffre Allemand
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Chiffrement : on est vraiment des petits joueurs. Évalué à 3.
On parle de la seconde guerre mondiale et des machines Enigma, là?
Parce qu'il a quand même fallu faire pas mal de progrès en informatique (qui n'existait presque pas avant la guerre) pour venir à bout de ce chiffrement.
Il était suffisant pour son époque, tout comme les algorithmes utilisés aujourd'hui ne survivront peut-être pas au développement de l'informatique quantique ou à d'autres innovations.
[^] # Re: Le jeu recréé?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le jeu Doom recréé par une IA après qu'elle y a joué plusieurs milliers de parties. Évalué à 7. Dernière modification le 02 septembre 2024 à 09:26.
Mais là on a un modèle où une porte sensée être verrouillée finit par s'ouvrir quand même sans avoir été chercher la clé, des ennemis qui disparaissent sans qu'on leur tire dessus ou qui réapparaissent, etc.
C'est donc une modélisation qui n'a aucune utilité pour comprendre comment le jeu fonctionne.
L'intérêt d'une modélisation, il est non seulement dans l'utilisation du modèle, mais aussi dans sa construction: s'interroger sur quels sont les paramètres essentiels à modéliser et les choses qui sont négligeables. Oui, ça prend du temps, mais c'est du temps passé à comprendre comment le système fonctionne.
Ici, l'IA a créé un modèle dont on ne sait pas trop comment il fonctionne, et qui se comporte vaguement comme le système original, mais seulement en apparence. Et il est peut-être plus compliqué à étudier que le système original. Du coup, ça nous avance à quoi?
[^] # Re: Termux , c'est mort sur Android 5 et 6
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un environnement de dev dans son téléphone.. Évalué à 3.
Personellement, le code incompréhensible, j'en trouve dans Linux mais moins dans d'autres systèmes d'exploitation. Le fait cue ça soit du code noyau n'est pas une excuse pour l'absence de commentaires, les APIs mal documentées, l'absence de logs alors qu'un framework existe pour en faire.
Je crois surtout que la lisibilité du code n'est pas un critère hrioritaire pour les développeurs de drivers (ils ont surtout envie que ça fonctionne sur le matériel sur lequel ils sont en train de travailler).
L'excuse de "oui mais c'est du code noyau, les règles et bonnes pratiques de l'industrie ne s'appliquent pas" a un côté élitiste que je n'aime pas trop. Au contraire, c'est du code critique pour lequel il faudrait faire deux fois plus attention à ce qu'il soit clair et facile à suivre.
[^] # Re: Hasta la vista
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le site d'actualités tech AnandTech va fermer ses portes après 27 ans d'existence . Évalué à 5.
On peut ajouter que le concurrent principal, Tom's hardware, appartient au même éditeur. Ce n'était probablement pas utile de s'autoconcurrencer et il vaut mieux un gros site que deux plus petits?
[^] # Re: Pendant ce temps, au Brésil…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Au Brésil, un juge ordonne la suspension de Twitter "X" . Évalué à 9.
ça marche assez bien avec la guerre russo-ukrainienne ou on a des nouvelles dès que la ligne de front bouge d'une centaine de mètres, avec des cartes mises à jour et tout. Je n'ai pas trop vu passer la même chose pour les feux de forêt (ça doit pouvoir se trouver, mais les Grands Méchants Algorithmes n'ont pas l'air d'envoyer les infos jusque chez moi).
[^] # Re: Clavier souple + screen mirroring
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un environnement de dev dans son téléphone.. Évalué à 3.
Le clavier FrogPad (qui s'utilise à une seule main et pourrait se porter en bracelet) n'est plus fabriqué, c'est bien dommage. Ce serait parfait pour cette utilisation.
En enlevant le clavier affiché sur l'écran du smartphone, on doit déjà à peu près doubler l'espace disponible pour afficher des choses. Pour une utilisation simple (et si on a une bonne vue et qu'on peut mettre une police de caractères assez petite, et si on a un smartphone moderne avec un grand écran) il n'y a peut-être pas besoin d'un écran externe? Après tout, il n'y a pas si longtemps on avait que 640x480 pixels et on se débrouillait bien avec?
[^] # Re: Va falloir qu'ils s'y fassent, et rigolons
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pour le rétablissement de la couverture 2G/GSM de Free Mobile (via itinérance). Évalué à 4. Dernière modification le 27 août 2024 à 23:57.
C'est un choix qui n'est pas délirant. En particulier il permet de libérer les fréquences radio utilisées et de les réattribuer à un système plus récwnt qui en fera une utilisation plus efficace (par exemple: plus de débit pour une bande de fréquence équivalente, meilleure portée à puissance d'émission équivalente, …).
La politique elle est surtout dans ce qu'on choisit de faire de l'espace arnsi libéré. Par exemple pour la télévision, onea choisi de mettore plus de chaînes de TV sur chaque fréquence. On aurait pu choisir de garder autant de chaînes qu'avant (environ 6, il me semble) et d'utiliser moins de bandes de fréquence pour la télévision.
Les bandes fréquence dsponibles n'étant pas illimitées, le choix de "on garde le même système pas efficace pendant 100 ans" est difficilement défendable.
[^] # Re: Précisions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La forge libre Forgejo est désormais distribuée sous la GPLv3+. Évalué à 3.
oui et non: s'il n'y a que ces deux fichiers qui sont sous gpl3, il n'est pas difficile de les enlever et de faire une version de forgejo qui est encore sous la license précédente.
ça n'empêchera donc probablement pas Gitea de récupérer les autres contributions.
Il reste à voir si la pratique va se développer ou si au contraire, quelqu'un s'amuse à réécrire ces fichiers avec une license plus permissive.
# C'était de l'hydrogène
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Signal Wow ! : la piste de l'appel d'une civilisation extraterrestre semble écartée. Évalué à 7.
Ce signal émis exactement à la fréquence naturelle de l'hydrogène était donc émis par de l'hydrogène, et pas par des extraterrestres ayant choisi la fréquence la plus encombrée de l'univers pour essayer de nous joindre.
Moi, si j'étais un extraterrestre, j'aurais plutôt choisi une fréquence plus calme, et vous?
[^] # Re: Pourquoi la voiture propose une maj en roulant...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien il paralyse Sète en lançant une mise à jour Tesla au feu rouge. Évalué à 9.
ce que dit l'article à la fin, c'est que c'est bien le cas:
Donc si je comprend bien:
Il manquait peut-être un avertissement sur la durée d'installation. Mais peut-être aussi que les automobilistes obéissent trop facilement aux indications données par leur véhicule. Comme les gens qui se jettent à la mer en suivant les instructions du GPS ou bien qui s'enfoncent hors des routes dans le désert au point de détruire leur voiture. Finalement, créer un embouteillage pendant 45 minutes, ce n'est peut être pas la pire chose qui pouvait arriver.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Firefox mis en danger par les déboires de Google.. Évalué à 3.
Sur les plateformes mobile (c'est là que beaucoup de choses se jouent désormais) il y a sûrement plein de choses à faire. La preuve, c'est que plein d'entreprises insistent pour développer des applications natives pour les téléphones, là où un site web conviendrait parfaitement. Si le site pouvait envoyer des notifications sans le garder dans un onglet ouvert. Si on pouvait facilement mettre temporairement une page en marque-page (par exemple pour y retrouver un billet de train dématérialisé, avec les infos si le train est à l'heure, etc).
Cela dit, après une ou deux décénnies de révolution constante des interfaces informatiques, on a peut-être aussi besoin de respirer un peu avant de plonger dans le prochain changement de paradigme?
# Transparence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien PostmarketOS: approx 8k€ de dons, en six mois... Évalué à 3.
J'apprécie toujours de lire des projets qui font preuve de transparence sur les dons reçus et sur les dépenses. C'est intéressant de pouvoir comparer avec d'autres projets, et c'est aussi plutôt bon signe pour la gouvernance du projet qui prend le temps de publier ces informations de façon claire et lisible
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Firefox mis en danger par les déboires de Google.. Évalué à 6.
Non, pour me faire dire ça, il faudrait penser que l'innovation, c'est forcément bien.
Je constate que, avec un quasi-monopole, Google peut se permettre de faire évoluer la plateforme web et jintroduire comme il veut plein de fonctionalités ou d'anti-fonctionalités, sans se préoccuper de discuter ça avec les autres imhlémentations.
Je suis bien hlus à lwaise dans un univers technologique qui évolue moins vite, en prenant le temps de ne faire que les évolutions qui sont nécessaires. Moins d'innovation, mais plus d'améliorations. Par exemple POSIX ou le langage C, avec une version tous les 5 ans, c'est un rythme qui permet d'anticiper. Si on avait une version majeure de HTML ou de CSS tous les 5 ans, ça serait mieux cue le bazar actuel. Tout en étant moins propice à l'innovation à coup d'extensions non standardisées.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Firefox mis en danger par les déboires de Google.. Évalué à 10.
Internet Explorer/Trident comme moteur de l'innovation? Mouais, c'est plus compliqué que ça.
À l'époque, le w3c était fonctionnel: on avait oes versions majeures de html (la dernière étant la 4) avec un ensemble bien défini de fonctionalités. Même chose pour le css. L'innovation était donc plus lente, ou alors il fallait développer des sites fonctionnant avec les 3 ou 4 moteurs concurrents avec chacun leurs extensions non-standard.
Maintenant qu'on a un moteur dominant, Google peut unilatéralement innover des trucs dedans, et les autres courrent derrière pour rattraper. Les choses sont ensuites standardisées par le whatwg et ajoutées dans "html5" qui est en évolution perpétuelle.
De mon point de vue de développeur de navigateur, la différence se voit très bien. Autour de 2010, avoir un navigateur avec 4 ans de retard sur les concurrents ne posait pas trop de problèmes, parce que internet explorer 6 tirait les choses vers l'arrière et que le html4 était un standard fixe n'évoluant pas du tout. Aujourd'hui, si on ne déploie pas dans les 6 mois les dernières nouveautés et corrections de bugs, on a des sites qui se mettent à ne plus fonctionner.
Dans cet environnement complexe, assez technique, et ou l'innovation ne fait pas vendre (les navigateurs sont gratuits et les sites web gagnent surtout à s'afficher correctement partout), les règles théorique de l'économie et de la concurrence libre et non faussée ne s'appliquent pas.
[^] # Re: titre trop long
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Firefox mis en danger par les déboires de Google.. Évalué à 5. Dernière modification le 10 août 2024 à 23:30.
Dans mes messages j'ai comparé plutôt partir de WebKit et partir de Firefox. Je me suis jamais posé la question de recréer un truc à partir de zéro.
Même pour des besoins plus simple, on pourrait regarder du côté de NetSurf, dont l'équipe fait un très bon travail sur les performances pour les petites machines (utilisation mémoire qui se mesure en Mo et vitesse en MHz) ou de Dillo qui est à nouveau actif depuis quelque temps.
Donc, personellement, je n'envisagerai ni de partir de zéro, ni de regarder chez Firefox,parce qu'il y a pas mal de choix ailleurs et que, pour les autres moteurs, on ne parle pas d'un fork "dur", mais d'un truc où on peut collaborer avec l'upstream et intégrer facilement leurs développements. Sinon, on se retrouve assez vite dépassé, comme c'est arrivé il me semble à Classilla, Camino, Galeon, K-Meleon et autres navigateurs basés sur Gecko. Il reste peut-être PaleMoon, mais j'ai pas envie d'aller voir de ce côté à cause de l'ambiance et des opinions politiques des développeurs. Il est basé sur Firefox 52 et backporte certains trucs des versions suivantes mais conserve l'API XUL qui permet de construire des applications web utilisant le moteur (rebaptisé Goanna). Je ne sais pas trop quel est le résultat pour naviguer sur le web moderne.
[^] # Re: Je me méfie quand il s'agit de nos amis états-uniens
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La DARPA veut traduire automatiquement le code C/C++ en Rust. Évalué à 2.
Non.
Toute la difficutslté d'un projet informatique, ce n'est pas d'écrire le code, mais de s'assurer que le code fait bien ce qui est demandé dans la spécification (ou que la documentation documente bien ce que fait le code).
Du code généré par un LLM fait ça moins bien qu'un déâeloppeur, et si on lui dit "hé, tu t'es trompé, c'est pas ce qu'on t'a demandé" il va répondre "oh, je suis désolé, vous avez raison, voici le code corrigé" et remettre un bout de code avec le même bug.
Dans le cas d'une traduction d'un langage à un autre, il faudrait entraîner un modèle spécial en lui fournissant du code c++ et la version traduite. Puis lui demander de "faire la même chose" sur d'autres morceaux de code. Le tout avec des tests pour valider si les traductions générées fonctionnent (@qui doivent être écrits au cas par cas, j'imagine?). Quel volume de code et de tests faut-il traduire à la main avant d'avoir assez de données pour avoir un traducteur fonctionnel? Est-ce qu'il restera encore du code non traduit quelque part une fois cet entraînement terminé?
[^] # Re: The next big thing
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Firefox mis en danger par les déboires de Google.. Évalué à 10.
Bonjour,
Je maintiens le navigateur WebPositive de Haiku qui est basé sur WebKit. Je me rend la vie compliquée avec une version de WebKit fonctionnant sur un OS différent, et je dois donc maintenir tout un tas de choses en particulier au niveau du rendu graphique (branché sur nos APIs natives au lieu d'utiliser Skia ou Cairo comme tout le monde), par exemple.
Mais pour développer un navigateur pour Linux ou Windows, il n'y a pas besoin de ça: vous prenez la dernière version de GTKWebKit et cela vous fournit les APIs nécessaires pour développer un navigateur. C'est faisable sans toucher à 99% du code de WebKit.
Ensuite il sera toujours possible de commencer à creuser pour régler des problèmes. Mes contacts avec les développeurs de WebKit sont assez bons lorsque j'ai des questions. Ils utilisent Slack pour collaborer (c'est pas génial, je préférais quand il y avait un canal IRC, mais ça a été tué par le rachat de Freenode). Les contributeurs externes m'ont l'air plutôt bien accueillis.
Je ne sais pas du tout comment les choses se passent pour Firefox à ce niveau. Mais je sais qu'il n'y a pas d'API permettant de créer un nouveau navigateur utilisant le même moteur. Dans ce cas, il faudrait plutôt partir sur un fork de tout l'ensemble (moteur + navigateur) ce qui ne facilite pas la collaboration entre projets. Ou alors envoyer des patchs à Mozilla pour retirer les fonctionnalités pénibles (trackers, add-ons préinstallés, …) mais là, bon courage pour faire accepter les changements?
[^] # Re: Comment naviguer sans ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Google Chrome va pousser uBlock Origin vers la sortie. Évalué à 2.
Non, Falkon a migré (comme tout l'écosystème Qt) de QtWebKit vers QWebEngine qui est, vous aviez deviné, encore un dérivé de Chromium/Blink.
QtWebKit n'est plus officiellement maintenu depuis plusieurs années maintenant.
[^] # Re: Et aussi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien [AFP] États-Unis : Google condamné pour pratiques anticoncurrentielles avec son moteur de recherche. Évalué à 3.
Le problème pourrait aussi se trouver du côté des versements de grosses sommes d'argent à des développeurs de navigateurs web pour les pousser à configurer Google comme moteur de recherche par défaut dans leurs produits.
Si cette pratique est interdite, cela nuirait à Apple et surtout à Mozilla, qui bénéficient de ce type de contrats et se verraient privés d'une source de revenus.
[^] # Re: Comment naviguer sans ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Google Chrome va pousser uBlock Origin vers la sortie. Évalué à 3.
En ce moment j'ncadre un des participants du Google Summer of Code qui est en train de migrer notre port de WebKit de l'API WebKitLegacy vers la "nouvelle" API WebKit2 (nouvelle entre guillemets parce qu'on a plus de 10 ans de retard pour cette migration).
Après ça, je vais prendre quelques vacances (j'en ai effectivement besoin) et je pourrai ensuite m'occuper ge l'upstreaming sans avoir à imposer à WebKit de prolonger l'existence oe l'API legacy plus longtemps que ce que nécessitent les besoins de Apple (qui maintient cette API en vie pour les besoins de quelques vieilles applications iOS, il me semble).