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 :(
Bayonne à l'extrêmité de la France? Alors qu'on peut, en partant de Bayonne, prendre un train pour Irun ou St Jean Pied de Port, qui sont encore plus loin?
Le codage de source vient des télécommunications où on a souvent une chaîne de traitement comportant un codage de source (consistant à encoder les données efficacement pour supprimer la redondance, c'est à dire, compresser), suivi d'un codage de canal, consistant lui à rajouter de la redondance, mais prédictible cette fois-ci (contrôle d'erreur, parité, CRC, …) afin que le récepteur puisse en tirer parti pour corriger les erreurs qui surviendront pendant la transmission du message.
On peut reconnaître que Windows 95 a fait un très gros travail sur l'ergonomie du système et obtenu un résultat plutôt réussi. Il a beaucoup influencé tout ce qui s'est fait par la suite, y compris de nombreux environnements de bureau Linux.
De là à les qualifier de clones, par contre, il faut peut-être pas exagérer.
Dans le cas de chez.com, il ne s'agit pas du propriétaire historique du service. Free a racheté le domaine et y propose une version de son offre "pages perso" non liée à un abonnement chez free.
L'hébergement proposé est extrêmement minimaliste (pas du tout de console d'administration par exemple) mais fonctionnel.
Chez Haiku on a fait le choix de réutiliser WebKit. ça se passe globalement bien, mais WebKit est 2 fois plus gros que tout le reste du système d'exploitation, et 10x plus long à compiler (environ 1h contre quelques minutes).
Pour WebKit je passe la plupart de mon temps à juste fusionner les changements qui viennent de l'upstream avec le portage pour Haiku. Pour avoir le temps d'en faire plus il faudrait que je travaille à plein temps sur le sujet (ce qui n'est pas possible pour 2 raisons: j'ai un emploi salarié à côté parce qu'on ne reçoit pas de donations de 100 000$, et je suis aussi responsable de plein d'autres projets autour de Haiku donc je pourrais difficilement passer tout mon temps exclusivement sur WebKit).
Et puis, il semblerait que développer un nouveau moteur est plus excitant et intéressant. De la même façon que, il y a 20 ans, Haiku a pu démarrer en choisissant de ne pas réutiliser un noyau Linux et de faire son propre truc, et que ça a attiré un certain nombre de développeurs qui voulaient s'attaquer à l'écriture d'un noyau, et qui ont donc évité d'autres projets BeOS-like qui faisaient un choix plus pragmatique de réimplémenter les APIs au-dessus de la pile logicielle GNU/Linux existante (noyau Linux, serveur X, etc).
Il n'y a donc pas que des considérations purement techniques qui entrent en jeu. Surtout pour Serenity, dont, pour l'instant, l'objectif n'est pas vraiment de concurrencer les "vrais" OS, mais de s'amuser à développer un système d'exploitation et de partager les connaissances acquises au passage.
Il y a du Javascript dans NetSurf (utilisant le moteur Duktape), le problème est surtout de "brancher" le javascript avec le DOM, d'une part parce que de la façon dont c'est fait acutellement, il y a un peu de code à écrire à la main pour chaque 'classe' HTML, et d'autre part, parce que ça rend dynamique des choses que le moteur de rendu supposait être statique avant l'introduction de Javascript.
Ce deuxième problème fait que ce n'est peut-être pas tout à fait déraisonable de ne pas se baser sur le travail de NetSurf (qui est par ailleurs plutôt bien pensé pour ce que j'en ai vu). Et il y a bien sûr le fait que l'équipe de Serenity travaille en C++, et que l'utilisation de NetSurf qui est écrit en C est assez peu confortable quand on a l'habitude du C++.
[^] # 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:
[^] # Re: Toolinux rebrandé goodtech pour keep upstream avec Linagora
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Pub ou vrai attaque ?. Évalué à 5.
Ils ont perdu leur procès contre Bluemind qu'ils accusaient je crois de leur avoir volé leur code (open source), leurs clients, et leurs développeurs.
Cette histoire commence en 2014: https://linuxfr.org/users/ceciestuncompte-0/journaux/linagora-vs-bluemind
Continue ici: https://linuxfr.org/users/ceciestuncompte-0/journaux/linagora-vs-bluemind-la-suite
Puis ensuite en cours d'appel: https://www.lemondeinformatique.fr/actualites/lire-affaire-bluemind-linagora-retour-en-appel-maj-84811.html
Et en cours de cassation: https://www.lemondeinformatique.fr/actualites/lire-la-justice-donne-raison-a-bluemind-face-a-linagora-88805.html
[^] # Re: Villes à l'extrémité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Isochrones de transports en commun. Évalué à 2.
Bayonne à l'extrêmité de la France? Alors qu'on peut, en partant de Bayonne, prendre un train pour Irun ou St Jean Pied de Port, qui sont encore plus loin?
[^] # Re: Compression sans perte ou encodage ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Des formats d'image. Évalué à 7.
Le codage de source vient des télécommunications où on a souvent une chaîne de traitement comportant un codage de source (consistant à encoder les données efficacement pour supprimer la redondance, c'est à dire, compresser), suivi d'un codage de canal, consistant lui à rajouter de la redondance, mais prédictible cette fois-ci (contrôle d'erreur, parité, CRC, …) afin que le récepteur puisse en tirer parti pour corriger les erreurs qui surviendront pendant la transmission du message.
[^] # Re: SerenityOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 2.
On peut reconnaître que Windows 95 a fait un très gros travail sur l'ergonomie du système et obtenu un résultat plutôt réussi. Il a beaucoup influencé tout ce qui s'est fait par la suite, y compris de nombreux environnements de bureau Linux.
De là à les qualifier de clones, par contre, il faut peut-être pas exagérer.
[^] # Re: il y a plus de 3 ans
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Swift pour Mac OS 9. Évalué à 4.
Ce n'est pas récent en effet, mais ça fonctionne pour de vrai malgré la date de publication, et la lecture de l'article est intéressante.
Dans la catégorie des toolchains improbables publiées un 1er avril, il y a au moins un précédent, avec cette version de GCC pour les processeurs Intel 8086 et 8088: http://web.archive.org/web/20171029055208/https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
[^] # Re: Laché vos com
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Fermeture de la plateforme Skyblog. Évalué à 3.
Dans le cas de chez.com, il ne s'agit pas du propriétaire historique du service. Free a racheté le domaine et y propose une version de son offre "pages perso" non liée à un abonnement chez free.
L'hébergement proposé est extrêmement minimaliste (pas du tout de console d'administration par exemple) mais fonctionnel.
[^] # Re: L’art nous apprend-il quelque chose ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 10.
Chez Haiku on a fait le choix de réutiliser WebKit. ça se passe globalement bien, mais WebKit est 2 fois plus gros que tout le reste du système d'exploitation, et 10x plus long à compiler (environ 1h contre quelques minutes).
Pour WebKit je passe la plupart de mon temps à juste fusionner les changements qui viennent de l'upstream avec le portage pour Haiku. Pour avoir le temps d'en faire plus il faudrait que je travaille à plein temps sur le sujet (ce qui n'est pas possible pour 2 raisons: j'ai un emploi salarié à côté parce qu'on ne reçoit pas de donations de 100 000$, et je suis aussi responsable de plein d'autres projets autour de Haiku donc je pourrais difficilement passer tout mon temps exclusivement sur WebKit).
Et puis, il semblerait que développer un nouveau moteur est plus excitant et intéressant. De la même façon que, il y a 20 ans, Haiku a pu démarrer en choisissant de ne pas réutiliser un noyau Linux et de faire son propre truc, et que ça a attiré un certain nombre de développeurs qui voulaient s'attaquer à l'écriture d'un noyau, et qui ont donc évité d'autres projets BeOS-like qui faisaient un choix plus pragmatique de réimplémenter les APIs au-dessus de la pile logicielle GNU/Linux existante (noyau Linux, serveur X, etc).
Il n'y a donc pas que des considérations purement techniques qui entrent en jeu. Surtout pour Serenity, dont, pour l'instant, l'objectif n'est pas vraiment de concurrencer les "vrais" OS, mais de s'amuser à développer un système d'exploitation et de partager les connaissances acquises au passage.
[^] # Re: \o/
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 4.
Il y a du Javascript dans NetSurf (utilisant le moteur Duktape), le problème est surtout de "brancher" le javascript avec le DOM, d'une part parce que de la façon dont c'est fait acutellement, il y a un peu de code à écrire à la main pour chaque 'classe' HTML, et d'autre part, parce que ça rend dynamique des choses que le moteur de rendu supposait être statique avant l'introduction de Javascript.
Ce deuxième problème fait que ce n'est peut-être pas tout à fait déraisonable de ne pas se baser sur le travail de NetSurf (qui est par ailleurs plutôt bien pensé pour ce que j'en ai vu). Et il y a bien sûr le fait que l'équipe de Serenity travaille en C++, et que l'utilisation de NetSurf qui est écrit en C est assez peu confortable quand on a l'habitude du C++.