pulkomandy a écrit 1970 commentaires

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.

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

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?

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.

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

Le moteur est co-développé par Apple, Sony (qui l'utilise pour les consoles Playstation) et Igalia (pour les versions GTK et WPE pour les systèmes embarqués) actuellement. Il y a eu aussi des contributions de Samsung (pour Tizen), des différents propriétaires de Qt, et de Google. Il existe également des forks pour les versions pour Haiku (maintenu principalement par moi-même), pour Amiga OS, et probablement d'autres que je ne connaît pas.

Il n'est donc pas spécialement contrôlé par Apple. Je n'ai pas rencontré de difficultés pour upstreamer quelques contributions de bugs, et la version Haiku sera la bienvenue upstream quand j'aurai le temps d'envoyer les patchs nécessaires.

Niveau gouvernance, je crois que c'est mieux que Firefox, qui, lui, n'est développé que par Mozilla et ils font tout pour empêcher la réutilisation de leur travail dans d'autres navigateurs.

Qualifier Safari de navigateur très exotique, c'est pas très sympa. Il est quand même autour des 18% de parts de marché.

Et le développement de WebKit est indépendant de Blink/Chromium depuis plus de 10 ans maintenant. On ne peut plus dire que c'est un navigateur dérivé de Chromium.

Le papier carbone survit encore, dans les formulaire de constats d'accidents à remplir en 2 ou 3 exemplaires identiques. Je viens d'en remplir un avec mes voisin d'au-dessus qui ont un petit peu innondé mon appartement.

Une solution low-tech qui permet d'éviter des falsifications ou modifications sans l'accord de toutes les parties. Pour remplacer ça par une solution numérique il faudrait une sacrée usine à gaz (j'en entend déjà qui parlent de blockchain)

On peut se poser la question alors: est-ce que chaque humain est prêt à dépenser 100 dollars par an pour bénéficier d'une intelligence artificielle à son service?

ou bien est-ce que 10% des humains sont prêts à dépenser 1000$ par an?

Car, certes on peut générer de la dette, mais après il faut la rembourser, et ce seront les utilisateurs de ces technologies qui vont payer. Même si cette mise en relation est très approximative, ça donne une idée de ce que pourraient coùter ces systèmes.

Reste à voir si le résultat des IA est à la hauteur de leur coût ou pas. Est-ce que leur succès actuel n'est pas surtout lié au fait qu'elles sont accessibles gratuitement?

C'est vrai qu'on râle beaucoup sur Wikipedia, mais la suppression d'informations obsolètes ou non pertinentes est essentielle dans la bonne vie d'un wiki.

Sinon on se retrouve avec plein de pages incompréhensibles voire trompeuses, qu'on garde parce que "on sait jamais ça peut toujours servir".

Pour les développeurs, essayez un peu de maintenir une application sans jamais supprimer une seule ligne de code ou un seul fichier. Je pense qu'on va vite voir le problème.

Du côté de Wikipedia, le problème est peut être qu'il y a une incohérence entre l'image "grand public" du projet (l'idée que tout le monde peut éditer n'importe quoi) et le vrai fonctionnement (il y a des règles et des procédures, et les gens qui éditent des pages n'importe comment ne sont pas les bienvenus). La solution serait alors de réconcilier ces deux choses, ce qui peut se faire, soit en changeant les règles pour correspondre à l'idée que se fait le public, soit en changeant la perception du projet. Pour la deuxième solution, peut-être que ça peut se faire en partie via de la communication (comme les discussions ici), peut être via des évolutions de l'interface de MediaWiki pour guider les gens vers les bonnes façons de contribuer (ça me semble être assez peu le cas pour l'instant, on peut cliquer facilement sur le bouton éditer et faire un peu ce qu'on veut, mais à la fois, ne pas avoir des choses "en dur" dans l'outil permet aux règles d'évoluer et de s'adapter).

https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does

"Le ròle d'un système est défini par ce qu'il fait"

Il y a peut-être plein de bonnes intentions derrière le fonctionnement de Wikipedia, il n'empêche que le résultat est la suppression de la page de la future première ministre de la France, et que ce n'est pas la première fois que ce genre de chose se produit.

Il faut peut-être se poser des questions sur le bon fonctionnement des règles de Wikipédia Français et de la façon dont elles sont appliquées, parce que le résultat, c'est de poursuivre l'invisibilisation des femmes, la sous-représentation des logiciels libres parce qu'ils ont peu de visibilité dans les médias généraux, le non respect du choix de genre des personnes qui ont un article, et sûrement d'autres problémes dont je n'ai pas entendu parler dans des domaines qui m'intéressent moins.

On peut faire l'autruche et continuer de dire que les règles sont neutres et objectives, malgré des problèmes qui commencent à être un peu récurrents. Ou alors on peut les remettre en question et voir comment les améliorer.

Et s'il n'y a pas de remise en question, on va finir par penser que c'est fait exprès?

Malheureusement ça ne concerne que les fréquences TNT, ces chaînes pourront donc continuer à être diffusées par d'autres moyens (satellites, mais surtout via la TV sur IP dans les box internet de la plupart des opérateurs).

Elles vont par contre devoir libérer les numéros de chaîne (8 et 12, donc) et probablement changer de nom pour accompagner ce changement.

Reste à voir quel sera l'impact sur l'audience de ces chaînes, donc. Pas vraiment un "clap de fin"…

Supprimer les 'ages pour empêcher le vandalisme, ça me rapelle les pirates dans Astérix et Obélix qui coulent leur bateau hour ne pas se faire attaquer par les Gaulois

Pour Github, compter le nombre de comptes utilisateur n'est pas forcément pertinent pour détecter un exode: on peut supprimer ses projet de Github, ou encore continuer à y stocber un miroir du code, et s'y garder quand même un compte.

Et d'autre part, en fait, on s'en fiche un peu si il ya des millions d'étudiants qui stockent leur code de projets de travaux pratiques sur github, ça n'apporte pas grand chose au logiciel libre (voir rien s'ils ont pas mis de licence) et ça n'apporte pus de sous à github non plus.

Il faut plutôt regarder les déploiements en entreprise, dans la mienne c'ets Gitlab mais on a un historique oe privilégier les logiciels libres. Chez nos clients il y avait plutôt du bitbucket, qui a arrêté ses licenses pour l'autohébergement pour passer sur une offre choud, et ça a l'air d'être github qui est en position pour récupérer une hartie de ce marché, en bénéficiant de l'intégration avec les comptes Microsoft.

Drew est certes plutôt engagé politiquement et assez franc et direct sur ses opinions sur la façon dont les choses devraient fonctionner, mais, en général, il a plutôt raison (à mon avis, si vous êtes pour les cryptomonnaies, contre les codes de conduite et pour les bots qui ferment les rapports de bug automatiquement alors que rien n'est résolu, allez voir ailleurs).

C'est à prendre en compte si vous voulez héberger des trucs chez lui, mais pour moi ça ne le met pas forcément dans la case "à éviter". Cwest un peu la même chose pour ForgeJo/Codeberg, ça a tendance à me rassurer sur le fait que ces projets vont rester des logiciels libres jusqu'à leur mort, et pas se vendre à un fond d'investissement au bout de 5 ans avec un communiqué du type "on aime toujours le libre, mais ça rapporte pas de sous"

Je ne sais pas pour Datadog, mon message était plus sur la trajectoire des startups à base de logiciel libre après un rachat.

Da adog a l'air d'avoir racheté plein de trucs d'après https://en.m.wikipedia.org/wiki/Datadog mais ce sont des technos dont j'ai jamais entendu parler (c'est pas vraiment dans mes domaines d'expertise). Donc je ne sais pas ce que sont devenus les produits rachetés.

Le code est libre pour l'instant, mais il est possible que les nouvelles versions après le rachat ne le soient plus. Ce qui pourrait conduire à un fork et une migration vers ce dernier, mais ce n'est peut-être pas un projet simple et léger qui peut être repris par 1 ou 2 personnes. Surtout si le Gitlab non opensource continuait ses développements au rythme actuel.

Il y a encore d'autres solutions, plus modulaires et avec un workflow assez différent, par exemple Gerrit pour la revue de code et la gestion des dépôts Git, ou Trac pour le suivi des tickets et le wiki.

Pas de cache (ça n'aurait pas vraiment de sens: un cache est intéressant s'il est plus rapide que ce qu'il remplace), mais par contre avoir de l'espage vide déclaré au disque (via trim ou blkdscard, je ne connait pas exactement les commandes à utiliser sous linux) hermet de pré-effacer ces zones pour ensuite pouvoir les écrire. Sur de la mémoire flash, il faut effacer une zone avant de l'écrire, et l'effacement prend plus de temps que la lecture.

On gagne donc des meilleures performance si le disque peut se préparer d'avance des secteurs effacés et prêts à écrire.

D'autre part, il y a le "wear levelling": le disque déplace en permanence des données peu souvent modifiées d'un endroit à un autre sur le disque, dwune part afin d'avoir un nombre d'écritures équivalent sur tous les blocs, et d'autre part parce que si on laisse des données trop longtemps sans les réécrire, elles finissent par s'effacer petit à petit au bout de quelques années.

SLC (single level cell) stocke 1 bit par transistor (le transistor est chargé ou déchargé)
DLC (dual level) en stocke 2 (4 niveaux de charge)
TLC (triple level) en stocke 3 (8 niveaux de charge)
QLC (quad level) en stocke 4 (16 niveaux de charge)

MLC veut dire "multi level cell" et veut donc juste dire "ce n'est pas du SLC".

Le coût du disque est proportionnel (en gros) au nombre de transistors. Donc un disque SLC coûtera le même pris qu'un QLC pour stocker 4 fois moins de données. Mais ce sera plus fiable, parce que utiliser autant de niveaux différents dans un transistor, ça demande une électronique qui fonctionne de façon assez précise, ce qui est compliqué sur le long terme (les composants vieillissent).

Les disques SLC seront donc les plus fiables mais aussi les plus chers. Le QLC aura une plus grande capacité mais sera moins fiable.

Il ne serait pas complètement surprenant que le firmware passe sur un algorithme d'écriture plus lent, mais plus fiable, au bout d'un certain nombre d'heures de fonctionnement ou de cycles d'écriture, pour compenser le vieillissement des transistors qui se réécrivent de moins en moins facilement avec le temps. Ce qui permettrait d'avoir des bonnes performances sur un disque neuf, mais une fiabilité correcte sur le long terme. Mais ce n'est pas très honnête.