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…
Je pense que ça se fait avec un pistolet à air chaud sur ces puces mais je n'ai pas essayé (je l'ai fait avec des composants avec un écartement de pattes un petit peu plus large, genre 0.8mm au lieu de 0.6).
Pour les fréquences, l'intérêt de ces puces avec la RAM intégrée c'est justement que toute la partie haute fréquence est entièrement contenue dans une seule puce. Donc, pas de problèmes de routage pour ce qui reste. Sauf si on veut faire de l'USB 3, de l'Ethernet Gigabit, une sortie vidéo en haute résolution (l'Allwinner V3s ne va pas au-delà de 1024x1024 pixels de toutes façons, ce qui est déjà pas mal), etc.
Oui, si on veut utiliser un system-on-module, c'est le plus logique de prendre un module de ce type.
L'idée au départ était de faire une carte mère complète avec juste le composant dessus, mais finalement je n'ai pas trouvé de truc très facile à souder (là, c'est possible, mais l'espacement entre les pins est trop fin pour le faire au fer à souder classique).
Par contre ça devrait être possible de faire assembler la carte par un fabricant qui propose ce service, et à un coût assez faible même en petits volumes.
oui, c'est ce que je vais faire pour cette première version (ou alors je peux utiliser un clavier avec un hub USB intégré). Mais avoir un clavier + une souris + un port de libre pour le reste serait pas mal.
Et le hub USB est plus gros que l'ordinateur, ce qui est un peu dommage :)
Il n'y a qu'un seul port USB, j'aurais du ajouter un hub USB sur la carte. Une fois un clavier branché, il n'y a plus de ports disponibles pour brancher autre chose. Une autre solution serait de brancher une matrice clavier directement sur quelques GPIOs ou sur un IO expander en I2C ou en SPI, ce qui permettrait d'avoir un clavier fonctionnel sans avoir à démarrer toute une stack USB. Les composants Allwinner plus récents peuvent aussi avoir 2 ports USB.
Question de point de vue. L'approche de Linux est qu'ils n'hésitent pas à modifier les interfaces entre le noyau et les pilotes, donc un pilote de périphérique qui veut survivre longtemps a tout intérêt à être inclus dans le noyau et à se trouver un mainteneur pour faire les mises à jour.
Une autre approche serait d'avoir une interface stable entre le lyau et les pilotes, et dans ce cas, le pilote pourrait etre écrit une bonne fois pour toutes et nécessiter peu de maintenance. Peut-être que les entreprises construisant du matériel arriveraient mieux à maintenir leurs pilotes à jour dans ce cas, et sans avoir à publier leur code source (il y a une certaine culture du secret sur le sujet…)
Les deux modèles peuvent se défendre, mais dans tous les cas, c'est toujours mieux d'avoir le code source sous une license qui permet d'assurer soi-même la maintenance
Ensuite j'envoie la sortie dans sed pour remplacer ce qui gêne le diff par des informations génériques
Et ben c'est très malin ça! Merci, je vais le noter dans ma boîte à outils!
Chose étonnante, j'observe cette perte quand mon binaire passe de 12,1 Mo à 12,6 Mo (tailles obtenues en activant LTO), mais pas de perte en passant de 13,2 à 13,7 Mo (tailles obtenues en désactivant LTO). Cette énigme restera de côté pour l'instant.
Il me semble que la LTO à l'époque de GCC 4.8, c'était pas extraordinaire. Un état des lieux d'époque annonçant les améliorations prévues pour les versions suivantes.
Est-ce que tu utilises function-sections, data-sections et gc-sections pour découper les fichiers .o en sections séparées et supprimer les sections inutiles? Pour éliminer le code mort, cela fonctionnera peut-être mieux. Et on peut ajouter print-gc-sections pour que le linker dise ce qu'il a éliminé du binaire final.
Free Vision est une réécriture à partir de 0 car la version de Borland en Pascal n'a jamais été publiée sous licence libre (contrairement à la version C++). Ici il s'agit du code original de Borland, qui fonctionne toujours sous MS-DOS et qui a été adapté pour fonctionner aussi sur des systèmes plus modernes.
Il y a aussi des implémentations dans d'autres langages:
En Java avec un mode graphique avec des images, de la transparence, …
L'article annonce la plus haute résolution du monde avec 1.2millions de LEDs. Je suppose que chaque LED correspond à un seul pixel. Ça fait environ 1100x1100 pixels. L'écran posé sur mon bureau fait mieux.
J'en conclus qu'il y a une erreur dans l'article, soit sur le nombre de LEDs, soit sur le fait que ça soit la plus haute résolution du monde?
Et avec une surface de 54000 mètres carrés, ça nous fait chaque LED à 450cm2, soit des LEDs de 21cm de côté environ. Un peu gros pour une seule LED, non?
il y imagine un milliardaire Texan qui décide de traiter le problème du changement climatique par géo-ingénierie en construisant le plus gros flingue du monde, un super six-coup géant capable d'envoyer des balles de dioxide de souffre dans la stratosphère.
Des milliardaires achètent le pôle nord pour pas cher puis annoncent qu'ils vont utiliser un très gros canon pour modifier l'axe de rotation de la terre pour avoir un meilleur climat au pôle nord et en exploiter les mines de charbon (et tant pis pour toutes les autres zones habitables qui vont finir innondées à cause de la montée des eaux).
Le changement climatique n'était pas encore découvert à l'époque, mais à part ça, je crois que l'idée y est.
(et bien sûr le projet échoue lamentablement à la fin)
Le serveur xmPp de Google est resté en ligne bien plus longtemps (jusqu'en 2022) mais il a été déconnecté de la fédération xmpp. Pas par Google, mais par les autres serveurs quand ils ont tous activé le chiffremwnt des connexions serveur-à-serveur et que Google ne s'est jamais mis à jour pour le faire aussi.
Le projet XMPP côté Google est tombé à l'abandon après avoir échoué à convaincre d'autres plateformes de discussion de se fédérer. Ils avaient presque réussi à convaincre Skype, mais ce oernier a été racheté par Microsoft juste après. Et y'avait des trucs chez AOL aussi il me semble?
En tout cas ça n'a pas du tout tué XMPP, qui reste un petit réseau pour un tas d'autres raisons mais est toujours bien vivant.
Le TGV-M est en cours de développement, il est prévu pour rouler jusqu'à 360km/h par Asltom mais la SNCF a déjà dit qu'elle l'exploiterait à 320km/h, parce que l'augmentation de vitesse entraîne une usure du train et des voies qui n'est pas rentable (ou alors il faudrait beaucoup augmenter le prix des billets).
Par contre il réduit la consommation électrique de 20% et permet d'embarquer plus de passagers, et il est modulaire (on peut ajouter ou retirer des voitures) contrairement aux TGV actuels qui ont une taille fixe (et donc roulent à moitié vides quand il y a peu de monde).
On va probablement voir un nouveau record de vitesse sur rail une fois les essais un peu plus avancés? Et on va voir comment ça se compare aux maglev Japonais, les seuls à faire mieux que le TGV et qui n'est qu'à l'état de prototype sur une voie de test.
Peut-être qu'on est trop habitués à prendre le TGV et qu'on a oublié à quel point on est pas si mauvais que ça en terme de trains rapides :) (même si, bien sûr, on peut toujours en faire plus).
Si on compare les records, le maglev est à 603km/h et le TGV à 574.8km/h. Et sinon on peut regarder chez les américains, qui ont mis un réacteur de fusée sur des rails et atteint mach 8.6 (10000km/h).
Et en terme d'exploitation commerciale, le TGV est dans le top 3, en partie parce qu'on a pas des grandes lignes droites de 1000km sans arrêt comme les chinois.
soit l’inverse de celle de Thunderbird la dernière fois que j’ai testé
Je ne sais pas ce que font les devs de Thunderbird mais il y a 2 champs de recherche: celui par défaut qui met 3 heures à chercher et qui trouve des mails n'ayant aucun rapport avec ce que tu as tapé dedans, et un autre qui est caché derrière un raccourci clavier où un réglage dans les options quelque part, et qui lui fonctionne correctement: une simple recherche par mots clés avec des résultats instantanés.
Ce qui revient un peu au sujet du débat: dans le logiciel libre, on a des développeurs pas mauvais, mais en ce qui concerne l'expérience utilisateur, y'a encore du boulot dans pas mal de projets. On peut pleurer après que les GAFAM attirent beaucoup de monde, mais il faut bien avouer que, malgré toute la pub intrusive qu'ils rajoutent dans leurs outils, ils restent tout de même mieux pensés et plus agréables à utiliser…
Je ne sais pas comment ce SVG est optimisé, mais par exemple, le logo de Google tient dans un SVG de 305 octets, et en passant un peu de temps sur le sujet, des gens sont arrivés à le réduire à 146 octets:
Et ça c'est pour le SVG. Comme ce n'est pas toujours suffisant, il existe des formats vectoriels conçus pour prendre très peu de place. Le format HVIF de Haiku est un exemple, et il y a aussi IconVG. Mais pour l'instant, pas d'utilisation possible dans les navigateurs web :(
[^] # 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…
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
Je pense que ça se fait avec un pistolet à air chaud sur ces puces mais je n'ai pas essayé (je l'ai fait avec des composants avec un écartement de pattes un petit peu plus large, genre 0.8mm au lieu de 0.6).
Pour les fréquences, l'intérêt de ces puces avec la RAM intégrée c'est justement que toute la partie haute fréquence est entièrement contenue dans une seule puce. Donc, pas de problèmes de routage pour ce qui reste. Sauf si on veut faire de l'USB 3, de l'Ethernet Gigabit, une sortie vidéo en haute résolution (l'Allwinner V3s ne va pas au-delà de 1024x1024 pixels de toutes façons, ce qui est déjà pas mal), etc.
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 4.
Oui, si on veut utiliser un system-on-module, c'est le plus logique de prendre un module de ce type.
L'idée au départ était de faire une carte mère complète avec juste le composant dessus, mais finalement je n'ai pas trouvé de truc très facile à souder (là, c'est possible, mais l'espacement entre les pins est trop fin pour le faire au fer à souder classique).
Par contre ça devrait être possible de faire assembler la carte par un fabricant qui propose ce service, et à un coût assez faible même en petits volumes.
[^] # Re: J'ai oublié
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 3.
oui, c'est ce que je vais faire pour cette première version (ou alors je peux utiliser un clavier avec un hub USB intégré). Mais avoir un clavier + une souris + un port de libre pour le reste serait pas mal.
Et le hub USB est plus gros que l'ordinateur, ce qui est un peu dommage :)
# J'ai oublié
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Je construis un micro-ordinateur. Évalué à 7.
Dans la liste des choses à améliorer:
[^] # Re: Contexte
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apps and driver support in Redox OS - OSnews. Évalué à 2.
Question de point de vue. L'approche de Linux est qu'ils n'hésitent pas à modifier les interfaces entre le noyau et les pilotes, donc un pilote de périphérique qui veut survivre longtemps a tout intérêt à être inclus dans le noyau et à se trouver un mainteneur pour faire les mises à jour.
Une autre approche serait d'avoir une interface stable entre le lyau et les pilotes, et dans ce cas, le pilote pourrait etre écrit une bonne fois pour toutes et nécessiter peu de maintenance. Peut-être que les entreprises construisant du matériel arriveraient mieux à maintenir leurs pilotes à jour dans ce cas, et sans avoir à publier leur code source (il y a une certaine culture du secret sur le sujet…)
Les deux modèles peuvent se défendre, mais dans tous les cas, c'est toujours mieux d'avoir le code source sous une license qui permet d'assurer soi-même la maintenance
[^] # Re: Contexte
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apps and driver support in Redox OS - OSnews. Évalué à 2.
Dans les systèmes à micronoyaux il faut quand même citer Fuchsia chez Google, même si il n'est pas très utilisé en dehors de l'entreprise.
# Astuces
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Prise de poids et perte de perf. Évalué à 4.
Et ben c'est très malin ça! Merci, je vais le noter dans ma boîte à outils!
Il me semble que la LTO à l'époque de GCC 4.8, c'était pas extraordinaire. Un état des lieux d'époque annonçant les améliorations prévues pour les versions suivantes.
Est-ce que tu utilises function-sections, data-sections et gc-sections pour découper les fichiers .o en sections séparées et supprimer les sections inutiles? Pour éliminer le code mort, cela fonctionnera peut-être mieux. Et on peut ajouter print-gc-sections pour que le linker dise ce qu'il a éliminé du binaire final.
[^] # Re: Et pour Pascal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La bibliothèque d'interface semigraphique Borland Turbo Vision est libre et tourne sous Linux. Évalué à 4. Dernière modification le 21 juillet 2023 à 13:47.
Free Vision est une réécriture à partir de 0 car la version de Borland en Pascal n'a jamais été publiée sous licence libre (contrairement à la version C++). Ici il s'agit du code original de Borland, qui fonctionne toujours sous MS-DOS et qui a été adapté pour fonctionner aussi sur des systèmes plus modernes.
Il y a aussi des implémentations dans d'autres langages:
# La plus haute résolution
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Un écran géant de 54 000 m² à Las Vegas. Évalué à 5.
L'article annonce la plus haute résolution du monde avec 1.2millions de LEDs. Je suppose que chaque LED correspond à un seul pixel. Ça fait environ 1100x1100 pixels. L'écran posé sur mon bureau fait mieux.
J'en conclus qu'il y a une erreur dans l'article, soit sur le nombre de LEDs, soit sur le fait que ça soit la plus haute résolution du monde?
Et avec une surface de 54000 mètres carrés, ça nous fait chaque LED à 450cm2, soit des LEDs de 21cm de côté environ. Un peu gros pour une seule LED, non?
[^] # Re: Super Fail
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Lessons From the Catastrophic Failure of the Metaverse. Évalué à 4.
Intéressant, mais ça me rapelle beaucoup un livre de Jules Verne publié en 1889.
Des milliardaires achètent le pôle nord pour pas cher puis annoncent qu'ils vont utiliser un très gros canon pour modifier l'axe de rotation de la terre pour avoir un meilleur climat au pôle nord et en exploiter les mines de charbon (et tant pis pour toutes les autres zones habitables qui vont finir innondées à cause de la montée des eaux).
Le changement climatique n'était pas encore découvert à l'époque, mais à part ça, je crois que l'idée y est.
(et bien sûr le projet échoue lamentablement à la fin)
[^] # Re: stackoverflow
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Dans le TIOBE Index de juillet, Fortran est n°11 et COBOL n°20 : le Jurassique est de retour !. Évalué à 4.
Les explications sont ici sur le site de l'Affaire Goldorak
[^] # Re: Instagram
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien What is threads app?. Évalué à 3.
Le serveur xmPp de Google est resté en ligne bien plus longtemps (jusqu'en 2022) mais il a été déconnecté de la fédération xmpp. Pas par Google, mais par les autres serveurs quand ils ont tous activé le chiffremwnt des connexions serveur-à-serveur et que Google ne s'est jamais mis à jour pour le faire aussi.
Le projet XMPP côté Google est tombé à l'abandon après avoir échoué à convaincre d'autres plateformes de discussion de se fédérer. Ils avaient presque réussi à convaincre Skype, mais ce oernier a été racheté par Microsoft juste après. Et y'avait des trucs chez AOL aussi il me semble?
En tout cas ça n'a pas du tout tué XMPP, qui reste un petit réseau pour un tas d'autres raisons mais est toujours bien vivant.
[^] # Re: Et pendant tout ce temps, en Asie de l'Est...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien « Hyperloop , la fin de l'entourloupe ». Évalué à 10.
Le TGV-M est en cours de développement, il est prévu pour rouler jusqu'à 360km/h par Asltom mais la SNCF a déjà dit qu'elle l'exploiterait à 320km/h, parce que l'augmentation de vitesse entraîne une usure du train et des voies qui n'est pas rentable (ou alors il faudrait beaucoup augmenter le prix des billets).
Par contre il réduit la consommation électrique de 20% et permet d'embarquer plus de passagers, et il est modulaire (on peut ajouter ou retirer des voitures) contrairement aux TGV actuels qui ont une taille fixe (et donc roulent à moitié vides quand il y a peu de monde).
On va probablement voir un nouveau record de vitesse sur rail une fois les essais un peu plus avancés? Et on va voir comment ça se compare aux maglev Japonais, les seuls à faire mieux que le TGV et qui n'est qu'à l'état de prototype sur une voie de test.
Peut-être qu'on est trop habitués à prendre le TGV et qu'on a oublié à quel point on est pas si mauvais que ça en terme de trains rapides :) (même si, bien sûr, on peut toujours en faire plus).
Si on compare les records, le maglev est à 603km/h et le TGV à 574.8km/h. Et sinon on peut regarder chez les américains, qui ont mis un réacteur de fusée sur des rails et atteint mach 8.6 (10000km/h).
Et en terme d'exploitation commerciale, le TGV est dans le top 3, en partie parce qu'on a pas des grandes lignes droites de 1000km sans arrêt comme les chinois.
Source: https://en.wikipedia.org/wiki/Railway_speed_record
[^] # Re: Super-intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien J’ai ma propre instance Mastodon. Sept mois plus tard, je déconseille. . Évalué à 5.
Je ne sais pas ce que font les devs de Thunderbird mais il y a 2 champs de recherche: celui par défaut qui met 3 heures à chercher et qui trouve des mails n'ayant aucun rapport avec ce que tu as tapé dedans, et un autre qui est caché derrière un raccourci clavier où un réglage dans les options quelque part, et qui lui fonctionne correctement: une simple recherche par mots clés avec des résultats instantanés.
Ce qui revient un peu au sujet du débat: dans le logiciel libre, on a des développeurs pas mauvais, mais en ce qui concerne l'expérience utilisateur, y'a encore du boulot dans pas mal de projets. On peut pleurer après que les GAFAM attirent beaucoup de monde, mais il faut bien avouer que, malgré toute la pub intrusive qu'ils rajoutent dans leurs outils, ils restent tout de même mieux pensés et plus agréables à utiliser…
[^] # Re: PNG encore utile.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 4.
Je ne sais pas comment ce SVG est optimisé, mais par exemple, le logo de Google tient dans un SVG de 305 octets, et en passant un peu de temps sur le sujet, des gens sont arrivés à le réduire à 146 octets:
https://clicktorelease.com/blog/svg-google-logo-in-305-bytes/
Et ça c'est pour le SVG. Comme ce n'est pas toujours suffisant, il existe des formats vectoriels conçus pour prendre très peu de place. Le format HVIF de Haiku est un exemple, et il y a aussi IconVG. Mais pour l'instant, pas d'utilisation possible dans les navigateurs web :(
[^] # Re: Ca me fait sourire cet article .....
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le futur, c'est XML. Évalué à 4.
Ça a été remplacé par JSON et YAML qui font… la même chose en moins bien.
On aurait peut-être mieux fait de garder XML, en fait. Avec ses fonctionnalités innovantes comme par exemple: