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!
Pour la question du tore de ferrite, j'avoue je ne sais pas trop ! Mais c'est l'argument que j'ai vu à l'utilisation dans des conditions comme celles des voyages des missions Apollo.
Pour les systèmes embarqués dans les missions Apollo, le premier problème avant de se poser des questions sur les radiations, c'est plutôt les vibrations. Ça me semble difficile de faire fonctionner correctement un lecteur de disquettes ou même de bandes magnétiques dans une fusée en train de décoller.
Le choix se porte plutôt sur des solutions "solid state", sans composants mécaniques. Il y a peu de choix à l'époque, c'est le tout début des ROMs à base de transistors: https://www.computerhistory.org/siliconengine/semiconductor-read-only-memory-chips-appear/ et ceux-ci sont sensibles aux radiations (mais surtout, ils apparaissent un peu tard pour être embarqués dans Apollo).
La mémoire à tores de ferrite est magnétique (donc moins sensible aux radiations qu'une mémoire à base de transistors) et "solid state" (pas de composants mécaniques qui ne survivraient pas aux vibrations). C'est donc effectivement un bon choix.
En revanche, oui, en 1992, Microsoft et Apple se sont rapprochés afin que les disquettes d'un SE puisse être lues de l'autre et réciproquement (et là il ne s'agit donc pas du format matériel des disquettes évidemment, mais de leur formatage).
Mais avant ça il a fallu se mettre d'accord sur le matériel: Apple avait choisi les disquettes 3"1/2 pour le Macintosh, alors que les PC avaient historiquement des disquettes 5"1/4, puis ont eu les deux types de lecteurs pendant une période de transition.
La convergence et l'amélioration de l'intéropérabilité s'est faite petit à petit. On pourrait remonter un peu plus tôt et parler aussi de l'invention du code ASCII, et de ses prédécesseurs (code Baudot par exemple), ou de ses successeurs comme Unicode. Il y aurait là encore de quoi faire toute une dépêche!
Je suis un peu embêté de voir la mémoire à tores de ferrite dan la section sur les supports de stockage non magnétiques. Les tores de ferrites stockent de l'information grâce à leur polarisation magnétique, il me semble?
Pour les formats de stockages sur cassettes au début de la micro-informatique, il y a des formats standardisés, par exemple le standard de Kansas City, qui apparaissent assez tôt (1975 pour celui-ci).
Certains fabricants de micro-ordinateurs ont plus tard fait le choix de développer leurs propres formats, pour des raisons de performances (stocker plus de données), de fiabilité (meilleurs algorithme de détection d'erreurs), ou de coût (algorithmes plus simples, processeurs pas assez rapides, …).
Enfin pour les formats de disquettes: Microsoft a certes imposé le système de fichiers FAT, mais un niveau en-dessous, le format des disquettes et l'interfaçage des lecteurs était défini par des spécifications qui ne sont pas dûes à Microsoft:
https://en.wikipedia.org/wiki/Floppy_disk_drive_interface pour l'interfaçage entre le lecteur de disquettes et le contrôleur,qui date du milieu des années 1970. Ce standard de fait est utilisé par IBM sur le PC mais pas par les autres constructeurs. La raison est que IBM utilise un composant contrôleur de disquettes existant, là ou d'autres fabricants dont Apple ont choisi de concevoir des circuits plus simples n'utilisant pas un tel contrôleur.
Le format physique des disquettes (5"1/4 puis 3.5") est défini par Shugart (pour la première) et par Sony (pour la deuxième), ils seront plus tard standardisés par exemple par l'ECMA. D'autres formats proposés par d'autres constructeurs existent aussi mais ont connu moins de succès.
L'encodage des données sur les disquettes (découpage en secteurs, CRC pour la détection d'erreurs etc) est plutôt défini par le composant contrôleur de disquettes. Le format trouve ses origines https://en.wikipedia.org/wiki/IBM_3740, ensuite il est réutilisé par Western Digital en 1976 qui va le modifier pour augmenter la capacité des disquettes, et enfin ce format est réutilisé par NEC sur le contrôleur µPD765 commercialisé en 1978 et qui sera intégré sur les PC d'IBM.
Donc finalement Microsoft n'est pas pour grand chose dans l'élaboration de ce format de stockage.
Pour le nommage par Google, ce n'est pas ce qu'on m'avait répondu. Le titre du site n'a pas forcément de lien avec l'URL.
Pour le reste, sans doute un peu, mais, pour l'instant, on a pas réussi à racheter haiku.org. Il a appartenu pendant des années à un truc de parking de domaines, qui l'a finalement revendu à un projet de startup qui n'a rien donné et l'a laissé expirer. Maintenant il est entre les mains de GoDaddy.com qui ne l'a pas remis en vente pour l'instant.
Quand on a un système d'exploitation qui n'a pas OS dans son nom, comme par exemple Haiku, les gens le rajoutent d'eux-même et nous rebaptisent "Haiku OS".
Une personne travaillant chez Google m'avait expliqué qu'ils ont un algorithme pour générer des titres pour les pages, et qu'on ne peut rien y faire. Le nom "Haiku OS" n'apparaît nulle part sur le site de Haiku, pourtant, c'est le titre que Google a choisi pour cette page. Si je me souviens bien, c'est parce que c'est le terme utilisé par beaucoup de gens pour la trouver, et effectivement, quand on cherche juste "Haiku", le système d'exploitation se classe beaucoup moins bien dans les résultats.
On est également obligé de rajouter "OS" à différents endroits pour éviter les interférences avec d'autres sortes de Haiku (les poèmes japonais), par exemple dans les mots-dièses sur les réseaux sociaux, le nom de la communauté Reddit, …
On espère un jour avoir la reconnaissance (et la SEO) de Windows, Linux ou Android, qui sont suffisamment connus pour pouvoir se passer de "OS" dans la plupart des contextes (sauf quand on parle de fenêtres, de lessive, ou de robots respectivement). Mais pour l'instant, on a pas atteint cette étape.
Dans le classement de Matt Mahoney des algorithmes de compression, on ne prend pas en compte seulement la taille du fichier compressé, mais aussi la taille du programme de décompression (donc dans ce cas précis, le "dictionnaire").
Cela n'empêche pas nncp de se classer devant tous ses concurrents.
Le décompresseur fait 200Ko, ce qui n'est pas énorme pour ce test (ou les données à compresser sont très grosses).
Au départ le moteur (Gecko) était bien séparé du navigateur. Mozilla a fait le choix de ne plus livrer Gecko séparément, probablement parce que ça leur simplifiait la vie pour faire évoluer l'interface entre le navigateur et le moteur, et supprimer du moteur les trucs qui ne servaient plus.
Développer un moteur séparé demande une organisation plus complexe et moins de flexibilité. Ça a été compliqué aux débuts de WebKit, le code a été forké depuis khtml et la collaboration entre les 2 projets était compliquée. Je crois que ça va mieux maintenant même si Apple a peut-être encore un role trop important (ça se corrige en contribuant plus à WebKit, à mon avis, pas en faisant un fork?)
Il existe https://github.com/tildearrow/furnace comme tracker, il sait faire de la musique utidisant la puce son de la Colecovision, qu'est-ce qui empêche de l'utiliser?
Oui, d'après https://en.m.wikipedia.org/wiki/List_of_DTT_channels_in_the_United_Kingdom certaines chaines de radio sont diffusées en DVB-T (télévision numérique Terrestre) en plus de la réception FM et DAB (radio numérique) et des streams internet. C'est ce service de radio par DVB-T qui est concerné.
Il y a également plusieurs chaînes qui diffusent une version "en direct" et une version décalée d'une heure?
C'est peut-être mieux que de remplir tous les canaux de la TNT avec des chaînes de UV nulles que personne ne regarde?
La nouvelle licence ne s'applique qu'aux nouvelles versions publiées à partir de maintenant. Donc les versions précédentes restent disponibles.
De plus, la licence BSL a une date d'expiration après laquelle le code devient libre (2 ans par défaut).
Le temps que les nouvelles versions arrivent dans Debian stable, ce délai sera déjà expiré, du coup, ça ne devrait pas poser problème!
Plus sérieusement, c'est le risque de ce type de licence: se retrouver avec beaucoup de gens qui remontent des bugs sur la version opensource datant d'il y a 2 ans et qui sont corrigés dans la version à jour mais sous licence (temporairement) non-libre.
L'interview des organisateurs de http://cpcretrodev.byterealms.com/en/ pourrait être intéressante aussi (concours de programmation où participent entre autres des étudiants d'université qui reçoivent un cours sur la programmation de l'Amstrad CPC. Des points bonus sont attribués aux jeux publiés sous licence libre)
Il n'a pas de contrôleur d'écran, ce qui oblige à en implémenter un en logiciel et canaux DMA/timers. C'est intéressant aussi (et je me suis bien amusé avec ça sur la Bitbox grâce au travail de Makapuf qui avait mis tout le nécessaire en place), mais si le but est de faire une machine facile à programmer en "baremetal", je pense que ce n'est pas le mieux. Par contre c'est plus flexible.
Cela dit, chacun peut construire ce qu'il veut avec le matériel de son choix :)
Et il y a d'autres solutions, par exemple j'ai envisagé un écran eInk, mais ça reste un peu cher pour l'instant et les écrans couleur ont un rafraîchissement beaucoup trop lent (30 secondes sur un écran de taille acceptable pour ce que je voulais faire). Mais peut-être dans quelques années…
Je n'ai pas trouvé de composant tout-en-un avec 512Ko à 2Mo de RAM. Il faut donc choisir: faire un peu plus petit, ou un peu plus gros. Et les offres côté "plus petit" ne manquent pas.
Par contre j'ai un autre projet pour… plus tard… qui est de réécrire un OS pour l'ordinateur VTech Le Manager. C'est un proceseur 68000 (Dragonball pour être précis) avec 1 ou 2Mo de RAM.
Il y avait aussi un environnement de bureau complet reproduisant Windows XP appelé XPDE.
Il me semble que des vendeurs d'ordinateurs malhonnêtes avaient vendu des ordinateurs équipés d'un Linux avec cet environnement suffisant pour faire illusion le temps de tester la machine dans le magasin?
Donc tu as bien une possibilité de chiffrement, qui te sécurise vis à vis de quelqu'un qui snifferait ton réseau local. Par contre les clés restent je crois stockés sur les serveurs, donc tu n'es pas sécurisé de telegram et toute organisation y ayant accès.
Euh, on en est quand même pas là…
Toute la communication sur le réseau local est chiffrée en SSL (enfin j'espère, sinon c'est vraiment n'importe quoi).
Les groupes et conversations non secrètes sont transmises en SSL au serveur de Telegram, qui les déchiffre, puis les re-chiffre pour les envoyer aux autres participants de la conversation. C'est quand même le minimum de la sécurité, ça. On est plus dans les années 90 où les choses circulaient en clair sur le réseau local (même pour IRC la communication avec le serveur peut être chiffrée en SSL aujourd'hui).
La question c'est ce qui se passe après. Le serveur a accès aux conversations en clair. Est-ce qu'ils les stockent? Oui probablement, pour permettre aux gens d'accéder à l'historique de leurs messages quand ils utilisent un nouveau téléphone où qu'ils se connectent depuis un ordinateur. Telegram fait clairement un choix de facilité d'utilisation ici.
Quand on crée une conversation en mode "secret", on établit un secret qui n'appartient que aux clients aux deux extrêmités. C'est ce qu'on appelle le chiffrement de bout en bout. Ça s'ajoute à la communication déjà chiffrée avec le serveur. Maintenant, le serveur (et lui seul) peut savoir qui parle à qui (bien obligé, sinon il ne pourrait pas envoyer le message au destinataire), mais pas le contenu des messages. L'inconvénient est que ça complique le fait d'avoir un historique de conversation qu'on peut récupérer sur un autre appareil. L'avantage est que c'est sécurisé du mieux possible et qu'il n'y a pas besoin de faire confiance au serveur qui n'a pas accès au contenu de ces conversations.
Donc le système de message secrets de Telegram, c'est plutôt bien. L'inconvénient de Telegram, c'est une grosse communication sur cette fonctionnalité alors qu'elle n'est pas activée par défaut. Ce qui crée de la confusion, on ne sait plus ce qui est chiffré, ce qui ne l'est pas, et qui a accès ou pas aux messages.
Voptop, un système de visioconférence et de chat en partie en P2P et avec du relais de flux à la Tor pour empêcher de savoir qui parle avec qui.
Il s'est fait remarquer à une époque pour avoir un client pour Haiku, qui a été abandonné depuis pour se concentrer sur des plateformes plus populaires (Windows et Linux). Le développeur avait promis de publier les sources mais pour l'instant ce n'est pas fait (ça fait 8 ans qu'on attend).
Je me suis inspiré de la sortie VGA de la Bitbox et aussi de schémas d'autres projets à bases de puces Allwinner, j'ai découvert le forum https://whycan.com ou il y a plein de gens avec des projets de ce type (il faut utiliser un traducteur automatique pour naviguer, si on ne lit pas le chinois simplifié).
Mon implémentation va vraiment au plus simple: la sortie LCD du chip est directement branchée via quelques résistances sur le port VGA. Olimex a été un peu plus précautionneux avec un composant qui sert de "buffer", ce qui est probablement une bonne idée.
Ils ont aussi fait une conversion de niveau pour transformer le 3.3V en 5V pour les synchros horizontales et verticales, avec mon écran en tout cas ça ne semble pas nécessaire, la synchro à un niveau 3.3V est bien détectée.
Pour faire fonctionner le tout, il faut ensuite une "modeline" appropriée dans le device tree. Il faut définir les timings et ceux recommandés pour connecter directement une dalle LCD ne fonctionnent pas, ils utilisent une synchro horizontale beaucoup plus courte (une optimisation par rapport au VGA, qui prévoit le temps pour le faisceau d'électrons d'un écran cathodique de faire tranquillement son retour à la ligne…)
Il est également possible de générer avec une petite modification (et des timings différents) un signal RGB pour un connecteur péritel. Pour cela il faut ajouter une porte logique XOR entre les sorties HSYNC et VSYNC pour générer un signal de synchronisation unique.
Ou sinon, choisir une des puces Allwinner plus récentes qui propose directement une sortie HDMI, ça devient trop facile. Je ne sais pas s'il existe des ports HDMI facile à souder cela dit, mais on peut au pire se rabattre sur le DVI qui lui ne devrait pas poser trop de problème.
Pour le DisplayPort, je n'ai pas cherché, je n'ai pas d'écran compatible :)
Ça marche bien avec les composants qui ont des pattes assez rigides pour ne pas être endommagées en utilisant de la tresse à déssouder.
Personellement j'ai de meilleurs résultats avec:
Mettre du flux liquide,
Appliquer de l'étain sur toutes les pattes mais en essayant de limiter les courts-circuits,
Utiliser une pompe à dessouder pour retirer l'excès d'étain et les courts circuits.
Avec ça je soude sans problème des composants avec des pattes espacées de 0.8mm.
Mais là pour l'Allwinner V3s on est su un espacement de 0.5mm, ça devient plus compliqué, et en plus, il y a quand même pas mal de pattes donc le risque de court circuit devient plus important.
Le pistolet à air chaud permet en principe de faire ça:
étaler de la pate à souder (flux gélifié avec de l'étain en suspension dedans)
placer le composant
chauffer le tout, l'étain se met en place et le flux s'évapore
Le matériel n'est pas beaucoup plus compliqué et pas très cher (et j'en ai déjà un que j'utilise pour déssouder les composants montés en surface, ce qui ne se fait pas vraiment avec un fer à souder classique).
Je n'ai pas encore testé cette méthode de la pate à souder, donc je ne sais pas à quel point c'est facile.
Windows 95 avait fait un très bon travail sur le fait d'avoir une interface graphique cohérente (avec les mêmes icônes dans toutes les applications), aujourd'hui on a ça avec n'importe quel thème.
Il a aussi des icônes très lisibles malgré une petite taille et peu de couleurs utilisées. Ce qui les rend à la fois facilement identifiables et discrètes. Un bon équilibre entre les couleurs très flashy de certains thèmes qui ont suivi, et la tendance plus récente à tout mettre en monochrome.
Et en plus, il utilise très peu de place à l'écran, et fonctionne bien même sur une résolution de 640x480 pixels. Ou, sur un écran plus grand, on peut se permettre d'avoir plusieurs fenêtres ouvertes sans que les barres d'outils des applications prennent toute la place.
Même si l'apparence est un peu vieillie, ça reste un thème utilisable. Je vais peut-être en récupérer une partie sur mon PC de bureau, mon thème GTK actuel a quelques bugs que je n'ai pas le temps de corriger…
[^] # 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!
[^] # Re: Quelques détails sur les formats de stockage informatiques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Où il est question de conservation. Évalué à 4.
Pour les systèmes embarqués dans les missions Apollo, le premier problème avant de se poser des questions sur les radiations, c'est plutôt les vibrations. Ça me semble difficile de faire fonctionner correctement un lecteur de disquettes ou même de bandes magnétiques dans une fusée en train de décoller.
Le choix se porte plutôt sur des solutions "solid state", sans composants mécaniques. Il y a peu de choix à l'époque, c'est le tout début des ROMs à base de transistors: https://www.computerhistory.org/siliconengine/semiconductor-read-only-memory-chips-appear/ et ceux-ci sont sensibles aux radiations (mais surtout, ils apparaissent un peu tard pour être embarqués dans Apollo).
La mémoire à tores de ferrite est magnétique (donc moins sensible aux radiations qu'une mémoire à base de transistors) et "solid state" (pas de composants mécaniques qui ne survivraient pas aux vibrations). C'est donc effectivement un bon choix.
Mais avant ça il a fallu se mettre d'accord sur le matériel: Apple avait choisi les disquettes 3"1/2 pour le Macintosh, alors que les PC avaient historiquement des disquettes 5"1/4, puis ont eu les deux types de lecteurs pendant une période de transition.
La convergence et l'amélioration de l'intéropérabilité s'est faite petit à petit. On pourrait remonter un peu plus tôt et parler aussi de l'invention du code ASCII, et de ses prédécesseurs (code Baudot par exemple), ou de ses successeurs comme Unicode. Il y aurait là encore de quoi faire toute une dépêche!
# Quelques détails sur les formats de stockage informatiques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Où il est question de conservation. Évalué à 7.
Je suis un peu embêté de voir la mémoire à tores de ferrite dan la section sur les supports de stockage non magnétiques. Les tores de ferrites stockent de l'information grâce à leur polarisation magnétique, il me semble?
Pour les formats de stockages sur cassettes au début de la micro-informatique, il y a des formats standardisés, par exemple le standard de Kansas City, qui apparaissent assez tôt (1975 pour celui-ci).
Certains fabricants de micro-ordinateurs ont plus tard fait le choix de développer leurs propres formats, pour des raisons de performances (stocker plus de données), de fiabilité (meilleurs algorithme de détection d'erreurs), ou de coût (algorithmes plus simples, processeurs pas assez rapides, …).
Enfin pour les formats de disquettes: Microsoft a certes imposé le système de fichiers FAT, mais un niveau en-dessous, le format des disquettes et l'interfaçage des lecteurs était défini par des spécifications qui ne sont pas dûes à Microsoft:
Donc finalement Microsoft n'est pas pour grand chose dans l'élaboration de ce format de stockage.
[^] # Re: Quand on ne le met pas...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal mais pourquoi s'appellent ils tous "OS"?. Évalué à 2.
Pour le nommage par Google, ce n'est pas ce qu'on m'avait répondu. Le titre du site n'a pas forcément de lien avec l'URL.
Pour le reste, sans doute un peu, mais, pour l'instant, on a pas réussi à racheter haiku.org. Il a appartenu pendant des années à un truc de parking de domaines, qui l'a finalement revendu à un projet de startup qui n'a rien donné et l'a laissé expirer. Maintenant il est entre les mains de GoDaddy.com qui ne l'a pas remis en vente pour l'instant.
# Quand on ne le met pas...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal mais pourquoi s'appellent ils tous "OS"?. Évalué à 4.
Quand on a un système d'exploitation qui n'a pas OS dans son nom, comme par exemple Haiku, les gens le rajoutent d'eux-même et nous rebaptisent "Haiku OS".
Et même Google s'y est mis, par exemple le premier résultat dans cette recherche: https://www.google.com/search?q=haiku+operating+system
Une personne travaillant chez Google m'avait expliqué qu'ils ont un algorithme pour générer des titres pour les pages, et qu'on ne peut rien y faire. Le nom "Haiku OS" n'apparaît nulle part sur le site de Haiku, pourtant, c'est le titre que Google a choisi pour cette page. Si je me souviens bien, c'est parce que c'est le terme utilisé par beaucoup de gens pour la trouver, et effectivement, quand on cherche juste "Haiku", le système d'exploitation se classe beaucoup moins bien dans les résultats.
On est également obligé de rajouter "OS" à différents endroits pour éviter les interférences avec d'autres sortes de Haiku (les poèmes japonais), par exemple dans les mots-dièses sur les réseaux sociaux, le nom de la communauté Reddit, …
On espère un jour avoir la reconnaissance (et la SEO) de Windows, Linux ou Android, qui sont suffisamment connus pour pouvoir se passer de "OS" dans la plupart des contextes (sauf quand on parle de fenêtres, de lessive, ou de robots respectivement). Mais pour l'instant, on a pas atteint cette étape.
[^] # Re: Ai-je bien compris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Fabrice Bellard : Text Compression using Large Language Models. Évalué à 2.
Dans le classement de Matt Mahoney des algorithmes de compression, on ne prend pas en compte seulement la taille du fichier compressé, mais aussi la taille du programme de décompression (donc dans ce cas précis, le "dictionnaire").
Cela n'empêche pas nncp de se classer devant tous ses concurrents.
Le décompresseur fait 200Ko, ce qui n'est pas énorme pour ce test (ou les données à compresser sont très grosses).
[^] # Re: Avec perte
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Fabrice Bellard : Text Compression using Large Language Models. Évalué à 2. Dernière modification le 22 août 2023 à 10:19.
Pour la compression de texte avec perte il y a ltzip mais ça mérite quelques perfectionnements.
[^] # Re: eolie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Desktop Linux has a Firefox problem. Évalué à 2.
Au départ le moteur (Gecko) était bien séparé du navigateur. Mozilla a fait le choix de ne plus livrer Gecko séparément, probablement parce que ça leur simplifiait la vie pour faire évoluer l'interface entre le navigateur et le moteur, et supprimer du moteur les trucs qui ne servaient plus.
Développer un moteur séparé demande une organisation plus complexe et moins de flexibilité. Ça a été compliqué aux débuts de WebKit, le code a été forké depuis khtml et la collaboration entre les 2 projets était compliquée. Je crois que ça va mieux maintenant même si Apple a peut-être encore un role trop important (ça se corrige en contribuant plus à WebKit, à mon avis, pas en faisant un fork?)
# Tracker
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Alekmaul à propos de PVCollib. Évalué à 3.
Il existe https://github.com/tildearrow/furnace comme tracker, il sait faire de la musique utidisant la puce son de la Colecovision, qu'est-ce qui empêche de l'utiliser?
[^] # Re: Écouter avec un écran
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Notes de la BBC sur les économies d'énergie réalisées à l'aide d'une nouvelle charte graphique. Évalué à 4.
Oui, d'après https://en.m.wikipedia.org/wiki/List_of_DTT_channels_in_the_United_Kingdom certaines chaines de radio sont diffusées en DVB-T (télévision numérique Terrestre) en plus de la réception FM et DAB (radio numérique) et des streams internet. C'est ce service de radio par DVB-T qui est concerné.
Il y a également plusieurs chaînes qui diffusent une version "en direct" et une version décalée d'une heure?
C'est peut-être mieux que de remplir tous les canaux de la TNT avec des chaînes de UV nulles que personne ne regarde?
[^] # Re: Faux positif?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Virus dans uclibc. Évalué à 10.
Oui, il n'y a pas de virus dans uclibc, mais par contre il y a uclibc dans un virus.
[^] # Re: Adieu Vagrant et Terraform
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien HashiCorp adopts Business Source License. Évalué à 5.
La nouvelle licence ne s'applique qu'aux nouvelles versions publiées à partir de maintenant. Donc les versions précédentes restent disponibles.
De plus, la licence BSL a une date d'expiration après laquelle le code devient libre (2 ans par défaut).
Le temps que les nouvelles versions arrivent dans Debian stable, ce délai sera déjà expiré, du coup, ça ne devrait pas poser problème!
Plus sérieusement, c'est le risque de ce type de licence: se retrouver avec beaucoup de gens qui remontent des bugs sur la version opensource datant d'il y a 2 ans et qui sont corrigés dans la version à jour mais sous licence (temporairement) non-libre.
[^] # Re: je vais me répéter
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Alekmaul à propos de PVSnesLib. Évalué à 2.
ça marche aussi pour la console Amstrad GX4000 qui utilise le même matériel que l'Amstrad 464Plus (sans clavier et sans lecteur cassettes).
[^] # Re: je vais me répéter
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Alekmaul à propos de PVSnesLib. Évalué à 2.
Pour l'Amstrad CPC: https://github.com/lronaldo/cpctelera
L'interview des organisateurs de http://cpcretrodev.byterealms.com/en/ pourrait être intéressante aussi (concours de programmation où participent entre autres des étudiants d'université qui reçoivent un cours sur la programmation de l'Amstrad CPC. Des points bonus sont attribués aux jeux publiés sous licence libre)
[^] # Re: Quelle horreur !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Linux: c'était mieux avant !. Évalué à 5.
Mais si, il y a AmiWM !
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
Il n'a pas de contrôleur d'écran, ce qui oblige à en implémenter un en logiciel et canaux DMA/timers. C'est intéressant aussi (et je me suis bien amusé avec ça sur la Bitbox grâce au travail de Makapuf qui avait mis tout le nécessaire en place), mais si le but est de faire une machine facile à programmer en "baremetal", je pense que ce n'est pas le mieux. Par contre c'est plus flexible.
Cela dit, chacun peut construire ce qu'il veut avec le matériel de son choix :)
Et il y a d'autres solutions, par exemple j'ai envisagé un écran eInk, mais ça reste un peu cher pour l'instant et les écrans couleur ont un rafraîchissement beaucoup trop lent (30 secondes sur un écran de taille acceptable pour ce que je voulais faire). Mais peut-être dans quelques années…
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 5.
Je n'ai pas trouvé de composant tout-en-un avec 512Ko à 2Mo de RAM. Il faut donc choisir: faire un peu plus petit, ou un peu plus gros. Et les offres côté "plus petit" ne manquent pas.
Par contre j'ai un autre projet pour… plus tard… qui est de réécrire un OS pour l'ordinateur VTech Le Manager. C'est un proceseur 68000 (Dragonball pour être précis) avec 1 ou 2Mo de RAM.
Cela dit, il peut aussi faire tourner Linux
[^] # Re: Je sais que...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Thème Windows 95 pour Linux. Évalué à 2.
Il y avait aussi un environnement de bureau complet reproduisant Windows XP appelé XPDE.
Il me semble que des vendeurs d'ordinateurs malhonnêtes avaient vendu des ordinateurs équipés d'un Linux avec cet environnement suffisant pour faire illusion le temps de tester la machine dans le magasin?
[^] # Re: Sécurisée??
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal petit topo des messageries sécurisées, et leurs alternatives. Évalué à 2.
Euh, on en est quand même pas là…
Toute la communication sur le réseau local est chiffrée en SSL (enfin j'espère, sinon c'est vraiment n'importe quoi).
Les groupes et conversations non secrètes sont transmises en SSL au serveur de Telegram, qui les déchiffre, puis les re-chiffre pour les envoyer aux autres participants de la conversation. C'est quand même le minimum de la sécurité, ça. On est plus dans les années 90 où les choses circulaient en clair sur le réseau local (même pour IRC la communication avec le serveur peut être chiffrée en SSL aujourd'hui).
La question c'est ce qui se passe après. Le serveur a accès aux conversations en clair. Est-ce qu'ils les stockent? Oui probablement, pour permettre aux gens d'accéder à l'historique de leurs messages quand ils utilisent un nouveau téléphone où qu'ils se connectent depuis un ordinateur. Telegram fait clairement un choix de facilité d'utilisation ici.
Quand on crée une conversation en mode "secret", on établit un secret qui n'appartient que aux clients aux deux extrêmités. C'est ce qu'on appelle le chiffrement de bout en bout. Ça s'ajoute à la communication déjà chiffrée avec le serveur. Maintenant, le serveur (et lui seul) peut savoir qui parle à qui (bien obligé, sinon il ne pourrait pas envoyer le message au destinataire), mais pas le contenu des messages. L'inconvénient est que ça complique le fait d'avoir un historique de conversation qu'on peut récupérer sur un autre appareil. L'avantage est que c'est sécurisé du mieux possible et qu'il n'y a pas besoin de faire confiance au serveur qui n'a pas accès au contenu de ces conversations.
Donc le système de message secrets de Telegram, c'est plutôt bien. L'inconvénient de Telegram, c'est une grosse communication sur cette fonctionnalité alors qu'elle n'est pas activée par défaut. Ce qui crée de la confusion, on ne sait plus ce qui est chiffré, ce qui ne l'est pas, et qui a accès ou pas aux messages.
# Dans la catégorie "personne n'en a entendu parler"
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal petit topo des messageries sécurisées, et leurs alternatives. Évalué à 2.
Voptop, un système de visioconférence et de chat en partie en P2P et avec du relais de flux à la Tor pour empêcher de savoir qui parle avec qui.
Il s'est fait remarquer à une époque pour avoir un client pour Haiku, qui a été abandonné depuis pour se concentrer sur des plateformes plus populaires (Windows et Linux). Le développeur avait promis de publier les sources mais pour l'instant ce n'est pas fait (ça fait 8 ans qu'on attend).
[^] # Re: Vers un "microcontroller" qui fait tourner linux ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
C'est le même principe, oui.
Je me suis inspiré de la sortie VGA de la Bitbox et aussi de schémas d'autres projets à bases de puces Allwinner, j'ai découvert le forum https://whycan.com ou il y a plein de gens avec des projets de ce type (il faut utiliser un traducteur automatique pour naviguer, si on ne lit pas le chinois simplifié).
Mon implémentation va vraiment au plus simple: la sortie LCD du chip est directement branchée via quelques résistances sur le port VGA. Olimex a été un peu plus précautionneux avec un composant qui sert de "buffer", ce qui est probablement une bonne idée.
Ils ont aussi fait une conversion de niveau pour transformer le 3.3V en 5V pour les synchros horizontales et verticales, avec mon écran en tout cas ça ne semble pas nécessaire, la synchro à un niveau 3.3V est bien détectée.
Pour faire fonctionner le tout, il faut ensuite une "modeline" appropriée dans le device tree. Il faut définir les timings et ceux recommandés pour connecter directement une dalle LCD ne fonctionnent pas, ils utilisent une synchro horizontale beaucoup plus courte (une optimisation par rapport au VGA, qui prévoit le temps pour le faisceau d'électrons d'un écran cathodique de faire tranquillement son retour à la ligne…)
Il est également possible de générer avec une petite modification (et des timings différents) un signal RGB pour un connecteur péritel. Pour cela il faut ajouter une porte logique XOR entre les sorties HSYNC et VSYNC pour générer un signal de synchronisation unique.
Pour le HDMI (et le DVI, c'est pareil) c'est plus compliqué, il faut un HDMI transmitter comme par exemple celui ci: https://datasheet.lcsc.com/lcsc/1912111437_Lattice-SiI9024ACNU_C369574.pdf (j'en avais repéré un qui peut se souder à la main, mais je le retrouve plus).
Ou sinon, choisir une des puces Allwinner plus récentes qui propose directement une sortie HDMI, ça devient trop facile. Je ne sais pas s'il existe des ports HDMI facile à souder cela dit, mais on peut au pire se rabattre sur le DVI qui lui ne devrait pas poser trop de problème.
Pour le DisplayPort, je n'ai pas cherché, je n'ai pas d'écran compatible :)
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
Ça marche bien avec les composants qui ont des pattes assez rigides pour ne pas être endommagées en utilisant de la tresse à déssouder.
Personellement j'ai de meilleurs résultats avec:
Avec ça je soude sans problème des composants avec des pattes espacées de 0.8mm.
Mais là pour l'Allwinner V3s on est su un espacement de 0.5mm, ça devient plus compliqué, et en plus, il y a quand même pas mal de pattes donc le risque de court circuit devient plus important.
Le pistolet à air chaud permet en principe de faire ça:
Le matériel n'est pas beaucoup plus compliqué et pas très cher (et j'en ai déjà un que j'utilise pour déssouder les composants montés en surface, ce qui ne se fait pas vraiment avec un fer à souder classique).
Je n'ai pas encore testé cette méthode de la pate à souder, donc je ne sais pas à quel point c'est facile.
[^] # Re: Cahier des charges
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 2.
Pour Haiku, il n'y a pas assez de RAM :(
(essayer de le faire rentrer tout de même pourrait être intéressant, mais ce serait plus envisageable avec une puce contenant 128Mo…)
[^] # Re: Je sais que...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Thème Windows 95 pour Linux. Évalué à 10.
Windows 95 avait fait un très bon travail sur le fait d'avoir une interface graphique cohérente (avec les mêmes icônes dans toutes les applications), aujourd'hui on a ça avec n'importe quel thème.
Il a aussi des icônes très lisibles malgré une petite taille et peu de couleurs utilisées. Ce qui les rend à la fois facilement identifiables et discrètes. Un bon équilibre entre les couleurs très flashy de certains thèmes qui ont suivi, et la tendance plus récente à tout mettre en monochrome.
Et en plus, il utilise très peu de place à l'écran, et fonctionne bien même sur une résolution de 640x480 pixels. Ou, sur un écran plus grand, on peut se permettre d'avoir plusieurs fenêtres ouvertes sans que les barres d'outils des applications prennent toute la place.
Même si l'apparence est un peu vieillie, ça reste un thème utilisable. Je vais peut-être en récupérer une partie sur mon PC de bureau, mon thème GTK actuel a quelques bugs que je n'ai pas le temps de corriger…