Il ne faut pas oublier qu'en Occident quand même il y avait des gens exprimant des doutes concernant la licence GPLv3 et qui ont préféré de continuer à publier ses logiciels sous GPLv2 parce que GPLv3 contient une clause permettant de réutiliser le code source sous une version de GPL ultérieure à GPLv3, qui n'existe pas encore, mais qui pourrait un jour être publiée par la FSF.
Cette clause ne fait pas partie de la license, mais du "manuel d'utilisation" de la FSF expliquant comment utiliser la license. Les deux sont indépendants. La clause de mise à jour existait déjà avec la GPL2, et certains projets ont choisi de l'utiliser, et d'autres pas.
Le choix de rester en GPL2 plutôt qu'en GPL3 s'est fait surtout parce que la GPL3 apporte des contraintes par exemple sur l'utilisation et le dépôt de brevets, que les juristes par exemple chez Apple ne voulaient pas s'engager là dedans (parce que c'était trop compliqué à faire). Ce qui fait que Apple est passé de GCC à LLVM, de Bash à ZSH, et sûrement quelques autres changements.
Y-a-t-il un leader charismatique autre que RMS qui pourrait lui succéder et faire avancer la liberté logicielle à travers les frontières ?
Une autre question: est-ce que la très forte centralisation de la FSF autour de RMS n'empêche pas l'émergence d'autres leaders? Pourquoi il n'y a qu'une seule personne autant mise en avant, et pas 2 ou 3?
Je me demandais ce qui se passerait pour le noyau et tout ce qui tourne autour si un jour Linux venait à prendre sa "retraite"
On a des exemples assez récents dans d'autres projets:
Python, ou Guido Van Rossum a pris sa retraite et organisé le passage de relais,
Vim, ou Bram Moleenar n'a malheureusement pas eu le temps de le faire dans de bonnes conditions.
Pour Vim, il y avait déjà Neovim qui aurait pu prendre le relais, mais les développeurs de Vim s'organisent tout de même pour prendre la suite dans le projet original. Pour l'instant il y a peu d'annonces à part les choses les plus urgentes: s'assurer de garder l'accès aux dépôts de code source, que ke site web reste en ligne, etc. Il va falloir leur laisser le temps de trouver leur nouvelle organisation et voir comment ça se passe.
Au delà du débat sur les opinions de RMS (il peut penser ce qu'il veut, après tout), moi ce qui m'embête dans cette histoire c'est que la FSF semble incapable de le remplacer, au point de le faire revenir dans le comité de direction.
Ce n'est pas rassurant pour la survie de la FSF après RMS, qui n'est pas immortel (même s'ils le gardent comme le pape jusqu'à sa mort).
Le fonctionnement serait plus sain si la FSF était en mesure de remplacer RMS, et pourrait ainsi se poser la question de le mettre dehors si nécessaire, sans que ça mette un tel bazar dans l'organisation.
Et on voit bien que ça pose problème à beaucoup de monde: la FSFE comme la Software Freedom Conservancy ont jugé nécessaire d'affichier clairement qu'elles ne sont pas liées ou associées à la FSF, par exemple. Et elles font, à mon avis, beaucoup mieux avancer les choses aujourd'hui.
Alors, est-ce que la FSF veut rester coincée dans sa vision des années 1980 avec toujours les mêmes personnes, ou bien est-ce qu'elle va se renouveler? Est-ce que ce renouvellement est possible tant que RMS avec ces propos controversés sera toujours dans la FSF?
Pour moi ce serait rassurant que la FSF puisse mettre RMS de côté et mettre en avant d'autres personnes à la place. Mais ce n'est pas ce qu'elle a choisi de faire.
Les yeux ne sont pas si bons que ça en termes de résolution, ils sont par contre extrêmement sensibles (on est capables de détecter et de ressentir un seul photon s'il arrive sur un des récepteurs de l'oeuil).
Mais en fait ça rend le travail du cerveau encore olus impressionnant: il est capable de se construire une perception très précise de l'environnement à hartirede données d'entrée finalement pas si bonnes que ça.
Ce n'est pas un problème d'intelligence artificielle en général. Bien sûrqu'un ordinateur, programmé de la bonne façon, peut faire des maths sans se tromper.
Le problème ici cencerne les "llm" (large language models), qui fonctionnent très bien pour générer du texte bien rédigé et à peu près dans le contexte de ce qu'on a demandé, mais… C'est tout. La capacité à faire des calculs mathématiques fiables, à ne pas inventer des références qui n'existent pas, etc, ce n'est simplement pas possible avec cette technologie. Il va falloir trouver une autre approche. Et il ne s'agit pas juste de bricoler un peu un algorithme ou de faire des plus gros calculs avec des plus gros ordinateurs.
Un des problèmes actuellement avec ces systèmes est qu'on ne comprend pas bien comment fonctionne l'intérieur d'un réseau de neurones. On peut donc difficilement l'intégrer avec d'autres méthodes de programmation, ce qui serait le mieux pour, par exemple, faire des calculs mathématiques. Peut-ètre qu'une solution émergera un jour, mais je pense que ça n'est pas pour tout de suite.
Ah, et aussi:
pour deep blue contre kasparov, la victoire a été causée par un jug qui a conduit deep blue a faire un coup sous-optimal, ce qui a conduit kasparov à croire qu'il avait raté un truc.
Et pour le Go, les joueurs humainssavent à nouveau vaincre les ordinateurs, il suffit de jouer des coups évidents qu'un joueur humain contrerait immédiatement, et qui n'apparaissent
t donc jamais dans les jeux de données sur lesquels l'ordinateur a été entraìné. Ce qui fait qu'il ne sait pas les bloquer.
Si je me souviens bien, le TO7-70 avait son système sur une "cartouche" (qui était probablement adressable directement par le processeur) avec, au choix, Basic ou Logo.
Il y avait quand même une ROM interne (le "moniteur") pour afficher un écran demandant d'insérer une cartouche, et contenant du code commun permettant de faire les opérations de base (lire le clavier, afficher du texte, …). Un genre de BIOS, donc.
Particularité intéressante (ou pas): cette ROM fait seulement 6Ko et elle est intégrée dans le composant "PIA" 6846, qui regroupe aussi un timer et des entrées-sorties.
La cartouche est effectivement adressable directement. Mais cela utilise de l'espace mémoire qui aurait pu être attribué à de la RAM. Pas vraiment un problème sur le TO7 (la RAM était trop chère à l'époque pour remplir même seulement 64Ko d'espace mémoire avec), mais les machines suivantes vont ajouter tout un système de "banques" permettant de déconnecter la cartouche et de mettre de la RAM à la place. Par contre la ROM interne reste toujours en place, ce qui est bien dommage. D'autres ordinateurs permettent de n'avoir que de la RAM, et cela apporte une flexibilité bien appréciable.
Dans les ordinateurs qui n'ont presque pas de BIOS, on peut citer l'Amstrad PCW: seulement 256 octets de code, qui sont stockés dans le contrôleur de l'imprimante et envoyés au CPU dans un ordre fixe (pas directement addressables). Il y a juste de quoi lire un secteur de la disquette, et l'exécuter, après une initialisation minimale du matériel. Tout le reste est chargé depuis la disquette. Si le lecteur de disquette ne fonctionne pas, la machine devient complètement inutilisable et ne peut même pas afficher un message d'erreur.
C'est le montant qu'il a dépensé pour acheter Twitter. Il était donc sur son compte en banque avant.
Je sais pas vous, mais je pense qu'on aurait pu facilement trouver une utilisation plus intelligente de tout cet argent. Enfin c'est pas grave pour Elon, il lui en reste encore plein, pour lui c'est de l'argent de poche.
Merci pour l’info. En fait, je me rends compte que le Transimpressux est assez géo centré depuis le début puisqu’on n’a guère quitté le bloc Eurasie-Afrique.
C'est dommage, parce qu'il y aurait des trucs à dire sur le syllabaire Cherokee par exemple.
Pour le dessert, vous pouvez aussi faire une raclette de chocolat, en remplaçant le fromage par du chocolat, et les patates et la charcuterie par des fruits (pommes, bananes, clémentines, adaptez selon la saison).
Les recettes utilisées pour les fontaines de chocolat s'appliquent bien, mais c'est moins compliqué à mettre en place surtout si l'appareil à raclette est déjà installé sur la table (pensez à laver les poêlons quand même avant de passer au dessert).
Le BIOS est une invention un peu spéciale de l'IBM PC. Lors de la conception du PC, IBM voulait utiliser du matériel disponible «sur l'étagère» : les premiers PCs étaient un assemblage de composants existants. Problème pour IBM : comment empêcher la création de clones du PC ?
La solution : le BIOS. Un composant logiciel intégré sur la carte mère, dont dépendra l'ensemble de la pile logicielle du PC (MS-DOS et ses applications, pour simplifier), et qu'IBM ne diffusera pas aux concurrents. Simple et efficace, non ? Et puis tant qu'à faire, autant y embarquer un interpréteur BASIC pour que la machine serve à quelque chose même sans disquette de système…
Euh, ça me semble, comment dire… assez loin de la réalité.
Lors de la conception du PC, IBM n'avait pas envie de vendre beaucoup de machines. Ils préféraient de loin vendre des gros ordinateurs très chers, mais ils avait identifié tout de même une demande, et surtout, leurs concurrents commençaient à dire que peut-être IBM n'était tout simplement pas capable de concevoir un micro-ordinateur simple et peu cher.
Leur choix s'est donc dirigé vers des composants standards, non seulement pour le matériel, mais aussi pour le logiciel: au départ, c'est le système CP/M de Digital Research qui est envisagé. Ce système repose sur… un BIOS, un bout de code qui doit être fourni par le fabricant de la machine, et qui permet à tout le reste du système d'être indépendant du matériel. Ainsi, Digital Research livre le binaire de CP/M, et la spécification pour écrire le BIOS.
Cependant, la visite d'IBM chez Digital Research s'est mal passée (le patron n'était pas là, et la personne qui les a reçu a refusé de signer un NDA sans l'accord de son supérieur et n'a donc jamais pu savoir ce qu'ils voulaient). IBM s'est ensuite rendu chez Microsoft, et Bill Gates a bien joué son coup en vendant non seulement son BASIC (pour lequel Microsoft était connu à l'époque), mais en sous-entendant qu'il pourrait aussi très bien fournir CP/M ou un équivalent à un prix tout à fait acceptable. Microsoft s'est ensuite procuré QDOS (Quick and Dirty Operating System), un clone de CP/M en moins bien, et l'a modifié pour en faire MS-DOS. L'idée d'avoir un BIOS ne vient donc pas d'IBM, et ce n'était certainement pas dans le but de fermer la machine, c'était la pratique habituelle pour ce type de matériel.
Suite au choix de travailler avec Microsoft, le BIOS a pu intégrer plus de fonctions et se moderniser un peu par rapport à ce que proposait CP/M (oui oui, on partait de loin…). Cela dit, il était tout de même possible d'obtenir un PC avec CP/M, le BIOS restant compatible avec ce dernier au moins pour les premières générations de machines.
Ce n'est que plus tard que IBM a réalisé son "erreur" avec l'utilisation de composants standard et a essayé de reprendre la main sur l'architecture du PC. Ça a échoué, d'une part à cause des choix matériels complexes et coûteux, mais aussi suite au choix d'utiliser le processeur 286, qui était imparfait, ils se sont fait devancer par Compaq et lâcher par Microsoft sur le projet OS/2 (IBM a continué de s'enfoncer dans l'idée de le faire marcher sur 286 pendant que Microsoft est passé sur 386).
Bref, le but du BIOS n'était pas de fermer l'architecture du PC, au contraire, c'était la bonne chose à faire pour lancer un système standard: CP/M. Ça ne s'est pas vraiment passé comme prévu, et ça a probablement changé beaucoup de chose pour la suite de l'histoire de la micro informatique, dont la montée en puissance de Microsoft et de Windows qui a un peu écrasé toute la concurrence.
iDSK, pour créer des images disques au format DSK (reconnu par les émulateurs Amstrad et inscriptible aussi sur de vraies disquettes)
gfx2crtc, pour convertir des images au format de l'Amstrad CPC
rasm, un assembleur z80
2CDT, pour créer des images de cassettes informatiques au format CDT (chargeable dans la plupart des émulateurs Amstrad)
apultra, un compresseur de données avec un décompresseur optimisé pour le processeur z80
Ils sont déjà tous disponibles et maintenus par ailleurs, mais le "vendoring" (préservation d'une copie d'une version spécifique) permet de s'assurer que le jeu restera compilable dans le futur, quand bien même les nouvelles versions de ces outils ne seraient pas compatibles.
C'est bien sûr faux, ubuntu a une version dédiée bureau et un paquet de ses dérivées ne sont faites que pour le bureau. De même pour RedHat qui a des versions spécifiques pour bureaux
Elles ont toutes les deux des images téléchargeables "bureau", mais dedans, c'est le même noyau que sur la version serveur, et de façon générale, le dépôt de paquets est le même.
On trouve bien chez Ubuntu un noyau "low latency" (https://packages.ubuntu.com/search?keywords=linux-image) (au milieu d'un tas de noyau optimisés pour différentes plateformes cloud) mais ce n'est pas celui installé par défaut. On ne le trouvera que dans les distributions dédiées à la musique assistée par ordinateur, où la latence est également très importante. C'est d'ailleurs probablement grace au travail des utilisateurs de Linux en MAO que ce noyau a fini par arriver dans les dépôts.
C'est donc bien ce que je disais: Ubuntu et RedHat ciblent à la fois les serveurs et les machines de bureau. Et c'est compliqué de faire les deux à la fois. Même si je comprend très bien qu'elles fassent ce choix: sur mon PC de bureau, je suis sous Debian, et je suis bien content que ma machine aie la même configuration que les serveurs de builds et autres machines de notre plateforme de test. Dans ce contexte, le gain en uniformité est tout à fait appréciable face à la perte en latence et en fluidité. Même si ça me fait râler quand je lance une grosse compilation Yocto avec trop de jobs en parallèle et que je peux plus bouger mon curseur de souris pendant 20 minutes à cause d'une combinaison de forte utilisation CPU, forte utilisation RAM, qui passe pas mal de temps à envoyer des trucs en swap, avant de finalement décider de lancer un OOM killer. Alors, oui, je pourrais passer du temps à essayer de mieux configurer tout ça, mais c'est le job que j'attendrais d'une distribution Linux dédiée au desktop, que ça vienne déjà réglé comme il faut.
Malheureusement pour Syllable, le projet s'est quelque peut égaré avec le développement de "Syllable Server" (une distribution Linux), et une reprise en main du projet par le développeur du langage Rebol, qui essaie d'intégrer son langage à tout prix dans le système et a fait fuir les développeurs C++ qui maintenaient le projet.
Il a récemment relancé un site internet qui semble être surtout fait pour faire de la publicité (mal) dissimulée pour son nouveau langage de programmation appelé Meta (vous noterez par exemple la roadmap qui n'a aucun plan pour le développement de l'OS).
Je ne vois pas bien en quoi un OS complet serait nécessaire. La partie bas niveau ne fais que de gérer le matériel. Je peux imaginer qu'il y a des tweaks différent pour serveur, bureau, smartphone, IoT,… Mais en soit ça ne me paraît qu'être de la configuration.
Alors, en principe oui. Mais ça a en fait des impacts assez profonds sur pas mal de choses. Par exemple, l'ordonnanceur du noyau. Sur un système de bureau, Haiku fait le choix de privilégier les threads qui sont liés à tout ce qui est sortie son et affichage. Pour ce faire, toutes les APIs natives de Haiku pour créer un thread obligent à donner un niveau de priorité, et les niveaux sont nommés ("display priority", "realtime priority", "background priority", etc). Sous Linux, la plupart des logiciels existants n'ont pas ce type d'info, et donc, l'ordonnanceur doit se débrouiller tout seul pour identifier les choses à prioriser, ou bien il faut le configurer à la main avec des fonctions comme nice, et, les valeurs choisies étant arbitraires, chaque application risque de toujours essayer de mettre "plus que les autres" pour passer devant.
On pourrait se dire que pourtant, Linux a plein d'APIs pour configurer des priorités, mais:
For threads scheduled under one of the normal scheduling policies (SCHED_OTHER, SCHED_IDLE, SCHED_BATCH), sched_priority is not used in scheduling decisions (it must be specified as 0).
Donc on oublie, ça ne concerne que les algorithmes d'ordonnancement "realtime". Cela dit, Linux est plutôt bien équipé au niveau de l'ordonnancement realtime, par exemple avec SCHED_DEADLINE, mais ça demande de développer les applications d'une façon bien précise et plus complexe que ce qu'on a l'habitude de faire.
L'ordonnanceur de Linux est très bon pour des sysèmes serveurs ou il faut surtout gérer des connexions réseau et des I/O disque. Pour ce type de tâche, il vaut mieux exécuter les choses pendant plutôt longtemps et faire peu de changements de contexte. Au contraire, Haiku va plutôt changer de tâche plus souvent, pour donner l'occasion à toutes les fenêtres affichées à l'écran de se rafraîchir en une ou deux dizaines de millisecondes par exemple. Dans l'absolu, cela a un coût sur les performances, mais le ressenti est que c'est beaucoup plus réactif.
Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau. Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
Voilà, c'était juste un petit exemple en regardant le cas de l'ordonnanceur, il se trouve que je connaît un peu le sujet à la fois dans Haiku et dans Linux. On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul), la sécurité (les problématiques sur une machine de bureau et sur un serveur hébergeant des douzaines de machines virtuelles ne sont pas du tout les mêmes), etc.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Les autres aspects qui ont poussé Haiku à faire ce choix sont:
Le fait d'avoir une seule équipe qui maîtrise tout l'OS, et de ne pas dépendre de quelqu'un d'autre pour le développement du noyau ou d'autres composants essentiels,
Le manque de maturité de Linux (c'était en 2001, aujourd'hui cet argument ne serait probablement plus valable). Pour rappel en 2001 (au tout début de Linux 2.6 pour ceux qui se souviennent): il y avait à peine le support de l'USB, le système de fichier EXT3 n'existait pas encore (alors que BeOS avec BFS disposait déjà d'un système de fichiers journalisé), et plein d'autres problèmes de ce type.
La volonté d'offrir une compatibilité totale avec BeOS, y compris de pouvoir réutiliser les pilotes matériels écrits pour ce dernier (là aussi, si c'était à refaire, Linux a aujourd'hui une bien meilleure liste de pilotes).
Il existe également plusieurs tentatives de réimplémenter quelque chose de proche de BeOS sur une base d'un noyau existant (Linux, BSD, ou même Windows). Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente. Cela dit, on entend plus parler de RedOX OS ou de Serenity que de la trente huit millième distribution Linux (même si certaines comme Hello System méritent probablement qu'on y jette un oeuil si on s'intéresse aux systèmes de bureau).
omemo permet de chiffrer la communication de client à client. Mais dans XMPP il y a plein de trucs qui sont stockés sur le serveur, par exemple, la liste de contacts, l'historique des messages dans les canaux auxquels on est connecté (les messages peuvent être chiffrés de bout en bout mais ils sont quand même stockés), les messages reçus pendant que le client n'était pas connecté, …
De plus, l'attaque permet de s'insérer entre le client et le serveur et donc, par exemple, d'empêcher un client d'envoyer des messages, d'intercepter des messages (chiffrés de bout en bout, éventuellement, mais on peut essayer d'obtenir la clé par ailleurs), de remplacer la clé de chiffrement, d'injecter des messages comme s'ils étaient envoyés par un client (si on a besoin de fabriquer des preuves qu'un des utilisateurs du service est un terroriste, il suffit d'envoyer des messages non chiffrés par ce moyen… tant qu'on ne se fait pas détecter en tout cas).
Il faut donc sécuriser cet aspect de la connexion (du client vers le serveur) en plus du chiffrement de bout en bout (de client à client, via leurs serveurs XMPP respectifs), ainsi bien sûr que les connections de serveur à serveur.
Hour compléter, côté XMPP, il est possible de faire du "channel binding" qui permet de s'assurer que les 2 machines à chaque bout d'une connexion ssl sont bien dans la même connexion ssl (sans intermédiaire au milieu comme ça semble être le cas ici).
Est-ce que ce serveur n'était pas configuré correctement pour le faire? Ou bien est-ce que l'attaquant a réussi à contourner ce mécanisme aussi?
Oui, si on veut se lancer pour plus de 10 ans avec la même machine, il vaut mieux bien choisir la machine au départ. Ce qui est de moins en moins facile. On trouve encore quelques fabricants qui font des ordinateurs avec un chassis en fibre de carbone ou en magnésium, mais c'est de plus en plus rare.
J'ai acheté l'an dernier un PC portable chez Fujitsu, qui est fourni avec un guide de démontage complet écrit par Fujitsu, et est visiblement conçu pour être démonté facilement (batterie accessible, nappe longue pour le clavier qui permet d'accéder confortablement au connecteur, etc).
Je vous tiens au courant dans 10 ans.
Du côté du téléphone, j'ai un XPeria X Compact de 2016. Je viens donc de passer la barre des 7 ans, j'ai du changer la batterie qui avait commencé à gonfler. La coque arrière est collée mais le gonflement de la batterie l'avait un peu décolléee et ensuite j'ai pu l'enlever en tirant dessus sans avoir besoin d'un pistolet à air chaud. Et j'ai pu commander facilement le joint autocollant qui n'est pas trop compliqué à installer. Je pense que c'est reparti pour 7 ans de plus!
Enfin je viens de récupérer une tablette Samsung Galaxy Tab 3 qui date de 2013. Sur celle-ci, aucun problème matériel: la batterie tient plusieurs jours, elle est comme neuve. Mais avec seulement 1Go de RAM, difficile de lancer même un simple navigateur web. En plus, elle a un processeur x86 32bit, qui limite encore un peu le choix d'applications disponibles.
Déjà, c'est du droit US, il est peu probable que ça s'applique tel quel en droit européen ou dans d'autres pays.
Il me semble que la SFC avait élaboré de façon un peu plus claire sur le sujet quand ils ont annoncé leur travail sur le cas de Vizio.
Si je me souviens bien (mais je suis pas juriste, j'ai sùrement pas tout compris): habituellement la GPL est présentée comme reposant sur le copyright et c'est donc une license. C'est l'auteur du code qui établit les conditions dans lesquelles il peut être diffusé et les restrictions qui doivent s'appliquer. Logiquement c'est donc cette même personne (l'auteur du code) qui peut porter réclamation lorsque la license n'est pas respectée.
Dans l'affaire Vizio, la SFC s'est positionnée en tant que réceptrice du code (en achetant plusieurs modèles de TVs commercialisées par Vizio). Ils ont demandé (comme la GPL leur en donne le droit) a recevoir une copie du code source contenu dans ces téléviseurs, je crois que Vizio leur a fourni certains éléments mais pas l'intégralité du code du téléviseur.
La SFC tente donc une action en justice en se plaçant du côté "réception" de la GPL. Ils ne sont pas auteurs du code et détenteurs du copyright. Du coup, ça oblige à envisager la GPL sous un tout autre angle: celui du droit des contrats, qui n'est pas lié au droit d'auteur et au copyright. C'est ce droit qui est utilisé pour les "end-user license agreement"/"contrat de license utilisateur final" que certains logiciels (non-libres le plus souvent) demandent d'accepter avant toute utilisation.
C'est donc en quelque sorte une expérimentation juridique pour voir si et comment la GPL peut s'appliquer sous cet angle, et si cela ouvre une façon pour les acheteurs de matériel contenant du logiciel libre (téléphones, TVs, …) de réclamer l'accès aux sources qui leur est dû, et ce, sans l'intervention du détenteur du copyright. Ce qui n'est pour l'instant pas du tout évident si on envisage la GPL uniquement du point de vue du droit du copyright États-Unien.
[^] # Re: Le problème n'est pas vraiment là
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L’avis de RMS sur les relations sexuelles. Évalué à 5.
Cette clause ne fait pas partie de la license, mais du "manuel d'utilisation" de la FSF expliquant comment utiliser la license. Les deux sont indépendants. La clause de mise à jour existait déjà avec la GPL2, et certains projets ont choisi de l'utiliser, et d'autres pas.
Le choix de rester en GPL2 plutôt qu'en GPL3 s'est fait surtout parce que la GPL3 apporte des contraintes par exemple sur l'utilisation et le dépôt de brevets, que les juristes par exemple chez Apple ne voulaient pas s'engager là dedans (parce que c'était trop compliqué à faire). Ce qui fait que Apple est passé de GCC à LLVM, de Bash à ZSH, et sûrement quelques autres changements.
Une autre question: est-ce que la très forte centralisation de la FSF autour de RMS n'empêche pas l'émergence d'autres leaders? Pourquoi il n'y a qu'une seule personne autant mise en avant, et pas 2 ou 3?
[^] # Re: Le problème n'est pas vraiment là
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L’avis de RMS sur les relations sexuelles. Évalué à 3.
On a des exemples assez récents dans d'autres projets:
Pour Vim, il y avait déjà Neovim qui aurait pu prendre le relais, mais les développeurs de Vim s'organisent tout de même pour prendre la suite dans le projet original. Pour l'instant il y a peu d'annonces à part les choses les plus urgentes: s'assurer de garder l'accès aux dépôts de code source, que ke site web reste en ligne, etc. Il va falloir leur laisser le temps de trouver leur nouvelle organisation et voir comment ça se passe.
[^] # Re: Mon retour d'expérience sur wikipédia
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal On efface la communauté du libre. Évalué à 6. Dernière modification le 01 décembre 2023 à 14:23.
Attention, tu vas bientôt inventer les pages web.
# Le problème n'est pas vraiment là
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L’avis de RMS sur les relations sexuelles. Évalué à 3.
Au delà du débat sur les opinions de RMS (il peut penser ce qu'il veut, après tout), moi ce qui m'embête dans cette histoire c'est que la FSF semble incapable de le remplacer, au point de le faire revenir dans le comité de direction.
Ce n'est pas rassurant pour la survie de la FSF après RMS, qui n'est pas immortel (même s'ils le gardent comme le pape jusqu'à sa mort).
Le fonctionnement serait plus sain si la FSF était en mesure de remplacer RMS, et pourrait ainsi se poser la question de le mettre dehors si nécessaire, sans que ça mette un tel bazar dans l'organisation.
Et on voit bien que ça pose problème à beaucoup de monde: la FSFE comme la Software Freedom Conservancy ont jugé nécessaire d'affichier clairement qu'elles ne sont pas liées ou associées à la FSF, par exemple. Et elles font, à mon avis, beaucoup mieux avancer les choses aujourd'hui.
Alors, est-ce que la FSF veut rester coincée dans sa vision des années 1980 avec toujours les mêmes personnes, ou bien est-ce qu'elle va se renouveler? Est-ce que ce renouvellement est possible tant que RMS avec ces propos controversés sera toujours dans la FSF?
Pour moi ce serait rassurant que la FSF puisse mettre RMS de côté et mettre en avant d'autres personnes à la place. Mais ce n'est pas ce qu'elle a choisi de faire.
[^] # Re: Pour combien de temps ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien À ce jour, toutes les intelligences artificielles butent sur les maths . Évalué à 6.
Une victiore contre katago en 2022 avec un algorithme simple: https://arstechnica.com/information-technology/2022/11/new-go-playing-trick-defeats-world-class-go-ai-but-loses-to-human-amateurs/
une autre en 2023, sans assistance informatique une fois la stratégie découverte: https://arstechnica.com/information-technology/2023/02/man-beats-machine-at-go-in-human-victory-over-ai/
[^] # Re: Pour combien de temps ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien À ce jour, toutes les intelligences artificielles butent sur les maths . Évalué à 4.
Les yeux ne sont pas si bons que ça en termes de résolution, ils sont par contre extrêmement sensibles (on est capables de détecter et de ressentir un seul photon s'il arrive sur un des récepteurs de l'oeuil).
Mais en fait ça rend le travail du cerveau encore olus impressionnant: il est capable de se construire une perception très précise de l'environnement à hartirede données d'entrée finalement pas si bonnes que ça.
[^] # Re: Pour combien de temps ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien À ce jour, toutes les intelligences artificielles butent sur les maths . Évalué à 10. Dernière modification le 24 novembre 2023 à 23:35.
Ce n'est pas un problème d'intelligence artificielle en général. Bien sûrqu'un ordinateur, programmé de la bonne façon, peut faire des maths sans se tromper.
Le problème ici cencerne les "llm" (large language models), qui fonctionnent très bien pour générer du texte bien rédigé et à peu près dans le contexte de ce qu'on a demandé, mais… C'est tout. La capacité à faire des calculs mathématiques fiables, à ne pas inventer des références qui n'existent pas, etc, ce n'est simplement pas possible avec cette technologie. Il va falloir trouver une autre approche. Et il ne s'agit pas juste de bricoler un peu un algorithme ou de faire des plus gros calculs avec des plus gros ordinateurs.
Un des problèmes actuellement avec ces systèmes est qu'on ne comprend pas bien comment fonctionne l'intérieur d'un réseau de neurones. On peut donc difficilement l'intégrer avec d'autres méthodes de programmation, ce qui serait le mieux pour, par exemple, faire des calculs mathématiques. Peut-ètre qu'une solution émergera un jour, mais je pense que ça n'est pas pour tout de suite.
Ah, et aussi:
pour deep blue contre kasparov, la victoire a été causée par un jug qui a conduit deep blue a faire un coup sous-optimal, ce qui a conduit kasparov à croire qu'il avait raté un truc.
Et pour le Go, les joueurs humainssavent à nouveau vaincre les ordinateurs, il suffit de jouer des coups évidents qu'un joueur humain contrerait immédiatement, et qui n'apparaissent
t donc jamais dans les jeux de données sur lesquels l'ordinateur a été entraìné. Ce qui fait qu'il ne sait pas les bloquer.
[^] # Re: Apprximation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 9.
Il y avait quand même une ROM interne (le "moniteur") pour afficher un écran demandant d'insérer une cartouche, et contenant du code commun permettant de faire les opérations de base (lire le clavier, afficher du texte, …). Un genre de BIOS, donc.
Particularité intéressante (ou pas): cette ROM fait seulement 6Ko et elle est intégrée dans le composant "PIA" 6846, qui regroupe aussi un timer et des entrées-sorties.
La cartouche est effectivement adressable directement. Mais cela utilise de l'espace mémoire qui aurait pu être attribué à de la RAM. Pas vraiment un problème sur le TO7 (la RAM était trop chère à l'époque pour remplir même seulement 64Ko d'espace mémoire avec), mais les machines suivantes vont ajouter tout un système de "banques" permettant de déconnecter la cartouche et de mettre de la RAM à la place. Par contre la ROM interne reste toujours en place, ce qui est bien dommage. D'autres ordinateurs permettent de n'avoir que de la RAM, et cela apporte une flexibilité bien appréciable.
Dans les ordinateurs qui n'ont presque pas de BIOS, on peut citer l'Amstrad PCW: seulement 256 octets de code, qui sont stockés dans le contrôleur de l'imprimante et envoyés au CPU dans un ordre fixe (pas directement addressables). Il y a juste de quoi lire un secteur de la disquette, et l'exécuter, après une initialisation minimale du matériel. Tout le reste est chargé depuis la disquette. Si le lecteur de disquette ne fonctionne pas, la machine devient complètement inutilisable et ne peut même pas afficher un message d'erreur.
[^] # Re: Elon
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal SNCF/RATP et X (Twitter). Évalué à 4.
C'est le montant qu'il a dépensé pour acheter Twitter. Il était donc sur son compte en banque avant.
Je sais pas vous, mais je pense qu'on aurait pu facilement trouver une utilisation plus intelligente de tout cet argent. Enfin c'est pas grave pour Elon, il lui en reste encore plein, pour lui c'est de l'argent de poche.
[^] # Re: Le système d'écriture maya
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Comment écrit-on les systèmes d’écriture aujourd’hui ?. Évalué à 2.
C'est dommage, parce qu'il y aurait des trucs à dire sur le syllabaire Cherokee par exemple.
# Dessert
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Il est temps que la communauté internationale fasse un choix. Évalué à 7.
Pour le dessert, vous pouvez aussi faire une raclette de chocolat, en remplaçant le fromage par du chocolat, et les patates et la charcuterie par des fruits (pommes, bananes, clémentines, adaptez selon la saison).
Les recettes utilisées pour les fontaines de chocolat s'appliquent bien, mais c'est moins compliqué à mettre en place surtout si l'appareil à raclette est déjà installé sur la table (pensez à laver les poêlons quand même avant de passer au dessert).
# Apprximation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Petitboot sur ARM, le bon, le bad et le ugly. Évalué à 10.
Euh, ça me semble, comment dire… assez loin de la réalité.
Lors de la conception du PC, IBM n'avait pas envie de vendre beaucoup de machines. Ils préféraient de loin vendre des gros ordinateurs très chers, mais ils avait identifié tout de même une demande, et surtout, leurs concurrents commençaient à dire que peut-être IBM n'était tout simplement pas capable de concevoir un micro-ordinateur simple et peu cher.
Leur choix s'est donc dirigé vers des composants standards, non seulement pour le matériel, mais aussi pour le logiciel: au départ, c'est le système CP/M de Digital Research qui est envisagé. Ce système repose sur… un BIOS, un bout de code qui doit être fourni par le fabricant de la machine, et qui permet à tout le reste du système d'être indépendant du matériel. Ainsi, Digital Research livre le binaire de CP/M, et la spécification pour écrire le BIOS.
Cependant, la visite d'IBM chez Digital Research s'est mal passée (le patron n'était pas là, et la personne qui les a reçu a refusé de signer un NDA sans l'accord de son supérieur et n'a donc jamais pu savoir ce qu'ils voulaient). IBM s'est ensuite rendu chez Microsoft, et Bill Gates a bien joué son coup en vendant non seulement son BASIC (pour lequel Microsoft était connu à l'époque), mais en sous-entendant qu'il pourrait aussi très bien fournir CP/M ou un équivalent à un prix tout à fait acceptable. Microsoft s'est ensuite procuré QDOS (Quick and Dirty Operating System), un clone de CP/M en moins bien, et l'a modifié pour en faire MS-DOS. L'idée d'avoir un BIOS ne vient donc pas d'IBM, et ce n'était certainement pas dans le but de fermer la machine, c'était la pratique habituelle pour ce type de matériel.
Suite au choix de travailler avec Microsoft, le BIOS a pu intégrer plus de fonctions et se moderniser un peu par rapport à ce que proposait CP/M (oui oui, on partait de loin…). Cela dit, il était tout de même possible d'obtenir un PC avec CP/M, le BIOS restant compatible avec ce dernier au moins pour les premières générations de machines.
Ce n'est que plus tard que IBM a réalisé son "erreur" avec l'utilisation de composants standard et a essayé de reprendre la main sur l'architecture du PC. Ça a échoué, d'une part à cause des choix matériels complexes et coûteux, mais aussi suite au choix d'utiliser le processeur 286, qui était imparfait, ils se sont fait devancer par Compaq et lâcher par Microsoft sur le projet OS/2 (IBM a continué de s'enfoncer dans l'idée de le faire marcher sur 286 pendant que Microsoft est passé sur 386).
Bref, le but du BIOS n'était pas de fermer l'architecture du PC, au contraire, c'était la bonne chose à faire pour lancer un système standard: CP/M. Ça ne s'est pas vraiment passé comme prévu, et ça a probablement changé beaucoup de chose pour la suite de l'histoire de la micro informatique, dont la montée en puissance de Microsoft et de Windows qui a un peu écrasé toute la concurrence.
[^] # Re: mais...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Google confirms they will disable uBlock Origin in Chrome in 2024. Évalué à 2.
Pour Vivaldi, une annonce sur leur blog qui traite du sujet: https://vivaldi.com/blog/manifest-v3-webrequest-and-ad-blockers/
# Chez les concurrents
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Décès des pages de résultats Google sans tracking à 25 ans. Évalué à 10.
Duckduckgo propose une version "lite" qui est déjà sans tracking et sans javascript:
https://lite.duckduckgo.com
Pourquoi s'embêter avec Google?
[^] # Re: LSD
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien DOS Subsystem for Linux: allowing users to make use of both DOS and Linux applications from DOS. Évalué à 3.
Il y a dosemu pour lancer les programmes DOS sous Linux depuis bien longtemps. Ça marche tellement bien qu'on peut même lancer Windows 3.1 dedans.
Et pour compléter la collection: il existe aussi HXDOS Extender qui permet de lancer des applications win32 sous DOS sans avoir besoin de Windows
[^] # Re: Roteur ou moteur?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Publication sous license libre du moteur du jeu Amstrad CPC Kitsune's Curse. Évalué à 6. Dernière modification le 06 novembre 2023 à 09:18.
Pour les outils, on trouve dedans des copies de:
Ils sont déjà tous disponibles et maintenus par ailleurs, mais le "vendoring" (préservation d'une copie d'une version spécifique) permet de s'assurer que le jeu restera compilable dans le futur, quand bien même les nouvelles versions de ces outils ne seraient pas compatibles.
# C'est un reboot
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le z80, c'est comique (attention à vos zylogmatiques). Évalué à 5.
Je vous rajoute les deux premiers épisodes de 1979: http://offthebeatenpanel.blogspot.com/2013/08/unusual-heroes-captain-zilog-1-zilog.html
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Coroutines, histoire d'un nouvel inutilitaire…. Évalué à 5.
Elles ont toutes les deux des images téléchargeables "bureau", mais dedans, c'est le même noyau que sur la version serveur, et de façon générale, le dépôt de paquets est le même.
On trouve bien chez Ubuntu un noyau "low latency" (https://packages.ubuntu.com/search?keywords=linux-image) (au milieu d'un tas de noyau optimisés pour différentes plateformes cloud) mais ce n'est pas celui installé par défaut. On ne le trouvera que dans les distributions dédiées à la musique assistée par ordinateur, où la latence est également très importante. C'est d'ailleurs probablement grace au travail des utilisateurs de Linux en MAO que ce noyau a fini par arriver dans les dépôts.
C'est donc bien ce que je disais: Ubuntu et RedHat ciblent à la fois les serveurs et les machines de bureau. Et c'est compliqué de faire les deux à la fois. Même si je comprend très bien qu'elles fassent ce choix: sur mon PC de bureau, je suis sous Debian, et je suis bien content que ma machine aie la même configuration que les serveurs de builds et autres machines de notre plateforme de test. Dans ce contexte, le gain en uniformité est tout à fait appréciable face à la perte en latence et en fluidité. Même si ça me fait râler quand je lance une grosse compilation Yocto avec trop de jobs en parallèle et que je peux plus bouger mon curseur de souris pendant 20 minutes à cause d'une combinaison de forte utilisation CPU, forte utilisation RAM, qui passe pas mal de temps à envoyer des trucs en swap, avant de finalement décider de lancer un OOM killer. Alors, oui, je pourrais passer du temps à essayer de mieux configurer tout ça, mais c'est le job que j'attendrais d'une distribution Linux dédiée au desktop, que ça vienne déjà réglé comme il faut.
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Coroutines, histoire d'un nouvel inutilitaire…. Évalué à 3.
SkyOS est non libre, mais Syllable est libre.
Malheureusement pour Syllable, le projet s'est quelque peut égaré avec le développement de "Syllable Server" (une distribution Linux), et une reprise en main du projet par le développeur du langage Rebol, qui essaie d'intégrer son langage à tout prix dans le système et a fait fuir les développeurs C++ qui maintenaient le projet.
Il a récemment relancé un site internet qui semble être surtout fait pour faire de la publicité (mal) dissimulée pour son nouveau langage de programmation appelé Meta (vous noterez par exemple la roadmap qui n'a aucun plan pour le développement de l'OS).
[^] # Re: Incroyable !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Coroutines, histoire d'un nouvel inutilitaire…. Évalué à 10.
Alors, en principe oui. Mais ça a en fait des impacts assez profonds sur pas mal de choses. Par exemple, l'ordonnanceur du noyau. Sur un système de bureau, Haiku fait le choix de privilégier les threads qui sont liés à tout ce qui est sortie son et affichage. Pour ce faire, toutes les APIs natives de Haiku pour créer un thread obligent à donner un niveau de priorité, et les niveaux sont nommés ("display priority", "realtime priority", "background priority", etc). Sous Linux, la plupart des logiciels existants n'ont pas ce type d'info, et donc, l'ordonnanceur doit se débrouiller tout seul pour identifier les choses à prioriser, ou bien il faut le configurer à la main avec des fonctions comme nice, et, les valeurs choisies étant arbitraires, chaque application risque de toujours essayer de mettre "plus que les autres" pour passer devant.
On pourrait se dire que pourtant, Linux a plein d'APIs pour configurer des priorités, mais:
Donc on oublie, ça ne concerne que les algorithmes d'ordonnancement "realtime". Cela dit, Linux est plutôt bien équipé au niveau de l'ordonnancement realtime, par exemple avec SCHED_DEADLINE, mais ça demande de développer les applications d'une façon bien précise et plus complexe que ce qu'on a l'habitude de faire.
L'ordonnanceur de Linux est très bon pour des sysèmes serveurs ou il faut surtout gérer des connexions réseau et des I/O disque. Pour ce type de tâche, il vaut mieux exécuter les choses pendant plutôt longtemps et faire peu de changements de contexte. Au contraire, Haiku va plutôt changer de tâche plus souvent, pour donner l'occasion à toutes les fenêtres affichées à l'écran de se rafraîchir en une ou deux dizaines de millisecondes par exemple. Dans l'absolu, cela a un coût sur les performances, mais le ressenti est que c'est beaucoup plus réactif.
Est-ce que ce serait faisable sur une base de noyau Linux? Oui, sans doute. Il existe déjà quelques options de configuration du noyau (PREEMPT et PREEMPT_VOLUNTARY) qui vont changer le comportement pour être plus approprié pour un PC de bureau. Mais, comme toutes les distributions Linux actuelles ciblent à la fois le bureau et le serveur, c'est rare de voir ces options activées dans les noyaux proposés.
Voilà, c'était juste un petit exemple en regardant le cas de l'ordonnanceur, il se trouve que je connaît un peu le sujet à la fois dans Haiku et dans Linux. On a le même genre de questionnements avec l'allocation de la mémoire (s¡il n'y a plus de mémoire, sur un PC de bureau on peut afficher un message d'erreur demandant quoi faire, sur un serveur, il n'y aura personne pour répondre, il faut donc se débrouiller tout seul), la sécurité (les problématiques sur une machine de bureau et sur un serveur hébergeant des douzaines de machines virtuelles ne sont pas du tout les mêmes), etc.
Donc, oui, tout est possible, ça serait peut être un peu moins de travail.
Les autres aspects qui ont poussé Haiku à faire ce choix sont:
Il existe également plusieurs tentatives de réimplémenter quelque chose de proche de BeOS sur une base d'un noyau existant (Linux, BSD, ou même Windows). Aucun de ces projets n'est vraiment actif aujourd'hui. Peut-être simplement parce que ledéfi d'implémenter un nouveau noyau a attiré plus de développeurs, ou peut-être parce que c'était vraiment le meilleur choix technique à l'époque, même si aujourd'hui la décision serait peut-être différente. Cela dit, on entend plus parler de RedOX OS ou de Serenity que de la trente huit millième distribution Linux (même si certaines comme Hello System méritent probablement qu'on y jette un oeuil si on s'intéresse aux systèmes de bureau).
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Interception de traffic sur les serveurs jabber.ru xmpp.ru. Évalué à 5. Dernière modification le 21 octobre 2023 à 12:00.
omemo permet de chiffrer la communication de client à client. Mais dans XMPP il y a plein de trucs qui sont stockés sur le serveur, par exemple, la liste de contacts, l'historique des messages dans les canaux auxquels on est connecté (les messages peuvent être chiffrés de bout en bout mais ils sont quand même stockés), les messages reçus pendant que le client n'était pas connecté, …
De plus, l'attaque permet de s'insérer entre le client et le serveur et donc, par exemple, d'empêcher un client d'envoyer des messages, d'intercepter des messages (chiffrés de bout en bout, éventuellement, mais on peut essayer d'obtenir la clé par ailleurs), de remplacer la clé de chiffrement, d'injecter des messages comme s'ils étaient envoyés par un client (si on a besoin de fabriquer des preuves qu'un des utilisateurs du service est un terroriste, il suffit d'envoyer des messages non chiffrés par ce moyen… tant qu'on ne se fait pas détecter en tout cas).
Il faut donc sécuriser cet aspect de la connexion (du client vers le serveur) en plus du chiffrement de bout en bout (de client à client, via leurs serveurs XMPP respectifs), ainsi bien sûr que les connections de serveur à serveur.
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Interception de traffic sur les serveurs jabber.ru xmpp.ru. Évalué à 3.
Hour compléter, côté XMPP, il est possible de faire du "channel binding" qui permet de s'assurer que les 2 machines à chaque bout d'une connexion ssl sont bien dans la même connexion ssl (sans intermédiaire au milieu comme ça semble être le cas ici).
Est-ce que ce serveur n'était pas configuré correctement pour le faire? Ou bien est-ce que l'attaquant a réussi à contourner ce mécanisme aussi?
[^] # Re: Pas mal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La barrière décennale. Évalué à 2. Dernière modification le 18 octobre 2023 à 00:05.
Ça devient de plus en plus compliqué à démonter et de moins en moins solide à chaque génération de machines, malheureusement…
Même si ça reste des gammes d'ordinateurs destinés aux entreprises qui sont tout de même loin devant les modèles grand public
[^] # Re: Pas mal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La barrière décennale. Évalué à 4.
Oui, si on veut se lancer pour plus de 10 ans avec la même machine, il vaut mieux bien choisir la machine au départ. Ce qui est de moins en moins facile. On trouve encore quelques fabricants qui font des ordinateurs avec un chassis en fibre de carbone ou en magnésium, mais c'est de plus en plus rare.
J'ai acheté l'an dernier un PC portable chez Fujitsu, qui est fourni avec un guide de démontage complet écrit par Fujitsu, et est visiblement conçu pour être démonté facilement (batterie accessible, nappe longue pour le clavier qui permet d'accéder confortablement au connecteur, etc).
Je vous tiens au courant dans 10 ans.
Du côté du téléphone, j'ai un XPeria X Compact de 2016. Je viens donc de passer la barre des 7 ans, j'ai du changer la batterie qui avait commencé à gonfler. La coque arrière est collée mais le gonflement de la batterie l'avait un peu décolléee et ensuite j'ai pu l'enlever en tirant dessus sans avoir besoin d'un pistolet à air chaud. Et j'ai pu commander facilement le joint autocollant qui n'est pas trop compliqué à installer. Je pense que c'est reparti pour 7 ans de plus!
Enfin je viens de récupérer une tablette Samsung Galaxy Tab 3 qui date de 2013. Sur celle-ci, aucun problème matériel: la batterie tient plusieurs jours, elle est comme neuve. Mais avec seulement 1Go de RAM, difficile de lancer même un simple navigateur web. En plus, elle a un processeur x86 32bit, qui limite encore un peu le choix d'applications disponibles.
[^] # Re: Version pour le commun des mortels?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien On avait tort à propos des licences GPL. Évalué à 10.
Déjà, c'est du droit US, il est peu probable que ça s'applique tel quel en droit européen ou dans d'autres pays.
Il me semble que la SFC avait élaboré de façon un peu plus claire sur le sujet quand ils ont annoncé leur travail sur le cas de Vizio.
Si je me souviens bien (mais je suis pas juriste, j'ai sùrement pas tout compris): habituellement la GPL est présentée comme reposant sur le copyright et c'est donc une license. C'est l'auteur du code qui établit les conditions dans lesquelles il peut être diffusé et les restrictions qui doivent s'appliquer. Logiquement c'est donc cette même personne (l'auteur du code) qui peut porter réclamation lorsque la license n'est pas respectée.
Dans l'affaire Vizio, la SFC s'est positionnée en tant que réceptrice du code (en achetant plusieurs modèles de TVs commercialisées par Vizio). Ils ont demandé (comme la GPL leur en donne le droit) a recevoir une copie du code source contenu dans ces téléviseurs, je crois que Vizio leur a fourni certains éléments mais pas l'intégralité du code du téléviseur.
La SFC tente donc une action en justice en se plaçant du côté "réception" de la GPL. Ils ne sont pas auteurs du code et détenteurs du copyright. Du coup, ça oblige à envisager la GPL sous un tout autre angle: celui du droit des contrats, qui n'est pas lié au droit d'auteur et au copyright. C'est ce droit qui est utilisé pour les "end-user license agreement"/"contrat de license utilisateur final" que certains logiciels (non-libres le plus souvent) demandent d'accepter avant toute utilisation.
C'est donc en quelque sorte une expérimentation juridique pour voir si et comment la GPL peut s'appliquer sous cet angle, et si cela ouvre une façon pour les acheteurs de matériel contenant du logiciel libre (téléphones, TVs, …) de réclamer l'accès aux sources qui leur est dû, et ce, sans l'intervention du détenteur du copyright. Ce qui n'est pour l'instant pas du tout évident si on envisage la GPL uniquement du point de vue du droit du copyright États-Unien.