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.
Version 1.1.0 de la XEP-0459 (XMPP Compliance Suites 2022)
Remplacement de la XEP-0411 (obsolète) par la XEP-0402 dans Advanced Group Chat. (egp)
Je trouvais ça bizarre de voir un changement sur les Compliance Suites 2022 alors que la version 2023 (XEP-0479) est déjà publiée.
J'ai donc regardé l'historique de version et je vois que ce changement date du 1er décembre 2021. Pourquoi apparaît-il dans cette newsletter presque 2 ans plus tard?
Pour le bluetooth, la base de la pile logicielle est en place mais il n'y a aucun pilote qui l'utilise pour l'instant. Donc, à part appairer des appareils, on ne peut rien faire.
Pour Wine, je ne sais pas, je n'ai pas testé.
Pour QEMU, ça devrait marcher, mais pas efficacement: il n'y a pas de pilote de virtualisation (type KVM) et donc l'émulation du CPU se fait logiciellement.
Oui j'utilise par ailleurs des solutions de ce genre (pour le travail, donc tout est sur le PC du travail, ça va bien). Mais pour GitHub où je me connecte depuis peut-être une dizaine de machines, même occasionnellement, et certaines avec des OS inhabituels genre Haiku, j'ai pas vraiment envie de configurer tout ça/porter les logiciels/écrire les drivers pour les tokens matériels, et les projets auxquels je contribue ne le méritent pas vraiment (beaucoup n'on qu'un seul utilisateur: moi).
Et puis ce n'était qu'une raison en plus de toutes les autres, mais qui est arrivé récemment et m'a rappelé que je m'étais dit que je devrais sortir mes trucs de Github et prendre une solution à base de logiciels libres.
Il fallait bien sûr lire --mirror, si la modération passe dans le coin et peur corriger :)
Oui, l'export de wiki Github est simple, c'est plutôt l'import dans Trac qui va demander un peu de travail. Mais comme je n'ai pas utilisé le wiki Github dans aucun de mes projets, je laisse ça à d'autres développeurs.
Le problème est peut-être l'utilisation de Github, qui n'a à peu près aucun outil de modération pour virer les gens qui se comportent n'importe comment.
Historiquement, MessagEase a été développé sur des téléphones avec un clavier numérique à l'ancienne comme alternative au T9. D'où le clavier en 3x3. Aujourd'hui ce n'est plus très justifé. Pour l'instant ThumbKey a repris cette disposition mais ils envisagent du 4x3 qui serait effectivement plus intéressant
Il faut garder un peu de place autour du clavier pour pouvoir utiliser les touches qui sont sur les bords avec des mouvements vers l'extérieur. Si la touche est tout au bord droit de l'écran, par exemple, on ne peut pas mettre de mouvement qui glisse vers la droite
C'est donc une bonne nouvelle que ThumbKey relance un peu la recherche sur le sujet, parce que MessagEase n'est plus maintenu depuis longtemps, non seulement l'application, mais aussi la disposition du clavier elle-même qui n'est pas forcément adaptée au matériel moderne. Cela dit, dans MessagEase il y a une disposition avec deux grilles de 3x3 boutons (une à gauche, une à droite), mais sur mon téléphone (écran 4"6), ça fait des boutons trop petits pour faire toutes les gestures précisément.
Personellement je n'utilise aucun autre clavier sur mes ordiphones, celui ci est beaucoup plus pratique.
Pour compléter sur Thumb-Key, ça fait tout pareil, mais il manque des touches dans le layout MessagEase français. Thumb-Key propose aussi son propre layout (avec une priorisation des touches un peu différentes), mais je ne l'ai pas testé, parce que j'ai déjà appris à écrire avec le MessagEase et j'ai pas envie de recommencer pour le moment.
Il manque aussi quelques fonctions, par exemple le fait de faire un aller-retour sur une lettre pour l'avoir en majuscules. Quelqu'un a l'air d'être en train de s'en occuper sur le bugtracker.
Il manque enfin la possibilité de personnaliser la disposition des touches (sans tout recompiler) mais de ce que j'ai compris ça devrait aussi bientôt arriver.
A la fin des années 1960, alors qu’elle approche des 30 ans – elle est née le 12 mars 1939 –, Judith Milhon s’installe à Berkeley, en Californie. […] Judith Milhon a appris seule à coder. Elle s’est formée en autodidacte aux langages Fortran et C ++ grâce à la lecture de manuels.
Apprendre le C++ entre 1969 et 1973, soit 15 ans avant que le langage soit créé, c'est vraiment très fort!
J'avoue que l'adaptateur LCD => VGA à coup de simples résistances, c'est assez bluffant. Mais j'imagine que cela peut tourner au cauchemar (valeurs des résistances, timings, rédaction du device tree …) et peut être qu'un oscilloscope ou un analyseur logique est indispensable pour déboguer tout ça.
Bonjour, j'avais raté ce commentaire.
Oui, un oscilloscope est utile, en particulier pour vérifier la configuration et les timings de la synchronisation horizontale et verticale (qui se configure depuis le device tree mais la documentation de linux-sunxi.org n'est pas à jour, j'ai du creuser un peu dans le code du pilote dans Linux). Le mien est un vieux truc à écran cathodique encombrant et qui ne fait que le minimum. Mais on doit trouver maintenant des oscilloscopes numériques qui feront assez bien le travail pour ce genre de choses.
Pour les choix de valeurs de résistances, j'ai surtout regardé ce que faisaient d'autres projets similaires, puis j'ai pris les résistances plus ou moins proches que j'avais en stock. Avec cette méthode je suis sûr d'être à peu près aux bonnes valeurs. Donc il n'y a pas trop de risque d'endommager le composant, juste d'avoir des couleurs "deformées" à l'écran.
Je précise aussi que je n'en suis pas à mon coup d'essai: j'avais écrit du code pour la bitbox qui utilise le même genre de système, j'ai fait du développement sur Amstrad CPC, machine où on joue pas mal avec le composant contrôleur vidéo pour plein de raisons, et j'ai aussi développé quelques morceaux de pilotes graphiques pour Haiku. Donc avec tout ça, j'ai une assez bonne compréhension de à quoi ressemble un signal VGA, ça aide bien!
# 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.
[^] # Re: Mince alors
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Perdu.com est mort. Évalué à 10. Dernière modification le 13 octobre 2023 à 22:15.
Heureusement il y a le beaucoup moins connu http://perdus.com qui est toujours en ligne, pour les internautes qui sont perdus à plusieurs.
# Cycle de vie des extensions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Lettre d'information XMPP d'août 2023. Évalué à 2.
Je trouvais ça bizarre de voir un changement sur les Compliance Suites 2022 alors que la version 2023 (XEP-0479) est déjà publiée.
J'ai donc regardé l'historique de version et je vois que ce changement date du 1er décembre 2021. Pourquoi apparaît-il dans cette newsletter presque 2 ans plus tard?
# Alexandria
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Stockage de 4GB de données et de programmes en 1959. Évalué à 5.
C'est un hasard que ces données soient stockées à Alexandria, Virginie? Ou bien c'est une référence à la bibliothèque d'Alexandrie?
# Problème de chronologie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Lorinda Cherry, la programmeuse Unix qui aimait la course automobile et les chiens et ses consœurs. Évalué à 3.
Il y a un petit problème dans l'ordre des évènements ici?
(merci d'avoir fini la dépêche à laquelle personne ne savait trop quelle direction donner…)
[^] # Re: synchro
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche 22 ans de Haiku. Évalué à 9.
Pour le bluetooth, la base de la pile logicielle est en place mais il n'y a aucun pilote qui l'utilise pour l'instant. Donc, à part appairer des appareils, on ne peut rien faire.
Pour Wine, je ne sais pas, je n'ai pas testé.
Pour QEMU, ça devrait marcher, mais pas efficacement: il n'y a pas de pilote de virtualisation (type KVM) et donc l'émulation du CPU se fait logiciellement.
[^] # Re: MFA sans téléphone
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Importer des "issues" GitHub dans des "tickets" Trac. Évalué à 3.
Oui j'utilise par ailleurs des solutions de ce genre (pour le travail, donc tout est sur le PC du travail, ça va bien). Mais pour GitHub où je me connecte depuis peut-être une dizaine de machines, même occasionnellement, et certaines avec des OS inhabituels genre Haiku, j'ai pas vraiment envie de configurer tout ça/porter les logiciels/écrire les drivers pour les tokens matériels, et les projets auxquels je contribue ne le méritent pas vraiment (beaucoup n'on qu'un seul utilisateur: moi).
Et puis ce n'était qu'une raison en plus de toutes les autres, mais qui est arrivé récemment et m'a rappelé que je m'étais dit que je devrais sortir mes trucs de Github et prendre une solution à base de logiciels libres.
[^] # Re: Wiki
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Importer des "issues" GitHub dans des "tickets" Trac. Évalué à 3.
Il fallait bien sûr lire
--mirror, si la modération passe dans le coin et peur corriger :)Oui, l'export de wiki Github est simple, c'est plutôt l'import dans Trac qui va demander un peu de travail. Mais comme je n'ai pas utilisé le wiki Github dans aucun de mes projets, je laisse ça à d'autres développeurs.
[^] # Re: Voir aussi :
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les devs de Bottles en ont marre des versions distro et vont leur faire afficher un message d'alerte. Évalué à 4.
Le problème est peut-être l'utilisation de Github, qui n'a à peu près aucun outil de modération pour virer les gens qui se comportent n'importe comment.
[^] # Re: Pourquoi ne pas avoir une surface plus grande ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Thumb-Key, un clone libre du clavier MessagEase pour Android. Évalué à 3.
Il y a plusieurs trucs qui rentrent en jeu:
C'est donc une bonne nouvelle que ThumbKey relance un peu la recherche sur le sujet, parce que MessagEase n'est plus maintenu depuis longtemps, non seulement l'application, mais aussi la disposition du clavier elle-même qui n'est pas forcément adaptée au matériel moderne. Cela dit, dans MessagEase il y a une disposition avec deux grilles de 3x3 boutons (une à gauche, une à droite), mais sur mon téléphone (écran 4"6), ça fait des boutons trop petits pour faire toutes les gestures précisément.
[^] # Re: Retour
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Thumb-Key, un clone libre du clavier MessagEase pour Android. Évalué à 3.
Il y a déjà un journal à propos de MessagEase qui date de 2022:
https://linuxfr.org/users/wapiti-2/journaux/messagease-le-clavier-qui-meriterait-une-version-libre
Personellement je n'utilise aucun autre clavier sur mes ordiphones, celui ci est beaucoup plus pratique.
Pour compléter sur Thumb-Key, ça fait tout pareil, mais il manque des touches dans le layout MessagEase français. Thumb-Key propose aussi son propre layout (avec une priorisation des touches un peu différentes), mais je ne l'ai pas testé, parce que j'ai déjà appris à écrire avec le MessagEase et j'ai pas envie de recommencer pour le moment.
Il manque aussi quelques fonctions, par exemple le fait de faire un aller-retour sur une lettre pour l'avoir en majuscules. Quelqu'un a l'air d'être en train de s'en occuper sur le bugtracker.
Il manque enfin la possibilité de personnaliser la disposition des touches (sans tout recompiler) mais de ce que j'ai compris ça devrait aussi bientôt arriver.
# Chronologie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien « St. Jude », hackeuse pionnière et méconnue de l’histoire d’Internet. Évalué à 9.
Je n'ai pas accès à la suite de l'article, mais…
Apprendre le C++ entre 1969 et 1973, soit 15 ans avant que le langage soit créé, c'est vraiment très fort!
[^] # Re: Windows Media Maker
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Window Maker 0.96 est plus ergonomique. Évalué à 5.
Alors en fait, oui: https://github.com/microsoft/Microsoft-3D-Movie-Maker
[^] # Re: J'ai hâte de voir la suite.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
Bonjour, j'avais raté ce commentaire.
Oui, un oscilloscope est utile, en particulier pour vérifier la configuration et les timings de la synchronisation horizontale et verticale (qui se configure depuis le device tree mais la documentation de linux-sunxi.org n'est pas à jour, j'ai du creuser un peu dans le code du pilote dans Linux). Le mien est un vieux truc à écran cathodique encombrant et qui ne fait que le minimum. Mais on doit trouver maintenant des oscilloscopes numériques qui feront assez bien le travail pour ce genre de choses.
Pour les choix de valeurs de résistances, j'ai surtout regardé ce que faisaient d'autres projets similaires, puis j'ai pris les résistances plus ou moins proches que j'avais en stock. Avec cette méthode je suis sûr d'être à peu près aux bonnes valeurs. Donc il n'y a pas trop de risque d'endommager le composant, juste d'avoir des couleurs "deformées" à l'écran.
Je précise aussi que je n'en suis pas à mon coup d'essai: j'avais écrit du code pour la bitbox qui utilise le même genre de système, j'ai fait du développement sur Amstrad CPC, machine où on joue pas mal avec le composant contrôleur vidéo pour plein de raisons, et j'ai aussi développé quelques morceaux de pilotes graphiques pour Haiku. Donc avec tout ça, j'ai une assez bonne compréhension de à quoi ressemble un signal VGA, ça aide bien!