Je crois qu'un des problèmes est le passage de 4K à 16K pour la taille des pages mémoire du MMU. A priori on se dit que ça devrait pas être bien important pour les applications, mais en fait, beaucoup d'applis qui ont besoin d'un peu de performance ont probablement réécrit leur propre allocateur mémoire par exemple. Et c'est pas du code qu'on modifie sans faire bien attention à ce qu'on fait, en général.
Et c'est probablement juste un exemple de truc qui change. C'est pas exclu que les devs d'Apple aient aussi profité de l'occasion pour supprimer plein de vieilles APIs inutiles au passage?
Pour l'exécution out of order, faire l'ordonnancement dans le compilateur fonctionne bien quand on cible un cpu spécifique. Le problème, c'est que le code ainsi optimisé ne sera peut-être pas optimal sur une autre architecture (nouvelle génération, puce développée par un concurrent…). C'est pour ça que le cpu se permet d'intervenir.
C'est sûr que si on réfléchit en terme d'une architecture cible stable et bien connue, plein de choses pourraient être faites complètement en statique. Par exemple on pourrait laisser le compilateur gérer lui-même la mémoire cache. Sauf que si le compilateur optimise pour 1Mo de cache et que la génération de cpu suivante en a 2Mo, ce code ne l'exploitera pas. Et du coup les gains de performance ne seront pas trop visibles.
Il est même co-maintenu par Apple, Sony (qui l'utilise pour la PlayStation), et Igalia (qui fait une partie du dev pour GTKWebKit, utilisé dans Epiphany, ainsi que la version "WPE" de WebKit qui peut être utilisée sur des systèmes embarqués et est conçue pour être plus facilement portable) ainsi que plusieurs contributeurs indépendants. Sans compter les versions maintenues hors du dépôt officiel (par exemple pour Haiku).
Alors oui, d'accord, "bouh c'est pas bien ce sont des entreprises et donc forcément des Grands Méchants". Mais ça reste un développement communautaire et assez ouvert aux contributions externes (la version Haiku a un temps été intégrée dans le dépôt officiel, elle avait été retirée faute de mainteneur actif).
C'est donc beaucoup mieux que Blink/Chromium, ou les sources sont publiées, mais par exemple les patchs pour permettre d'utiliser Blink sous *BSD sont rejetés. C'est donc pas vraiment le même état d'esprit.
Du côté de NetSurf, c'est plutôt un projet du type "4 personnes dans un garage" (quoi qu'il y aie eu occasionellement du sponsoring d'entreprises). Les objectifs du projet sont différents, le but étant d'avoir un navigateur très léger pouvant fonctionner sur des systèmes très divers (AmigaOS, RiscOS, …) ce qui suppose d'assurer, en plus du développement du navigateur, le portage ou la réécriture des bibliothèques nécessaires (curl, openssl, libpng, …) et la maintenance d'une toolchain pour pouvoir cross-compiler le tout pour ces architectures.
Si vous pensez que NetSurf est la solution d'avenir, il va falloir mettre les moyens pour que le projet avance (soit en y contribuant, soit en trouvant les moyens de financer un développeur qui s'y mettrait à plein temps). L'équipe actuelle n'a clairement pas assez de temps pour faire avancer les choses à une vitesse suffisante (même si ce qu'ils ont fait est déjà très bien).
Il s'agit d'un "bundle" de jeux qui a été vendu en reversant les profits au mouvement Black Lives Matter. Victime de son succès car des centaines de développeurs de jeux ont mis leurs jeux dans le bundle. Et du coup, c'est pas pratique de s'y retrouver et de savoir quels jeux on a acheté.
Il était question d'un bouton dans l'application pour récupérer tous les jeux d'un coup, mais finalement ça se fera pas. Les développeurs de l'applis ne pensaient visiblement pas qu'il y aurait autant de jeux dans ce bundle quand ils ont émis l'idée de ce bouton.
Problèmes de riches, donc: des centaines de jeux pour une dizaine d'euros, et se plaindre qu'ils sont compliqués à installer? Alors que des solutions tierces existent pour explorer la liste de jeux et s'y retrouver facilement.
C'est un peu ce qui fait la différence entre Haiku et un OS quelconque :)
On fournit dans Haiku des APIs pour plein de choses (applications graphiques, réseau, multimédia, décodage et encodage d'images…). On fait, en gros, l'équivalent d'un KDE ou d'un GNOME avec tout ce qu'il faut en-dessous pour que ça fonctionne.
Et donc, oui, il y a certes des APIs pour faire des sockets directement, mais aussi une API de plus haut niveau pour faire facilement du HTTP. Ça permet d'intégrer facilement le code réseau avec le reste, en particulier avec les boucles d'évènements BLooper/BHandler, et de faciliter la vie des développeurs d'applications.
On peut facilement combiner ça avec les APIs multimédia pour écouter de la musique ou regarder un flux vidéo en streaming. Ou avec le parser json pour interroger une API en quelques dizaines de lignes de code.
Ainsi que le gestionnaire de paquets de Haiku (aussi bien la version en ligne de commande pour le téléchargement des paquets, que l'interface graphique pour en plus récupérer les captures d'écran, icônes, commentaires des utilisateurs, …)
Le Terminal est développé (entre autres) par un ancien contributeur de Haiku, si jamais vous pensiez que les gens qui travaillent chez Microsoft ne sont pas des "vrais" libristes!
Il y ade plus en plus de morceaux de Windows qui apparaissent sur le compte github de Microsoft. Par exemple, la calculatrice: https://github.com/microsoft/calculator (c'est écrit en toute lettres "ships with Windows" et "MIT license")
Avec les téléphones et ordinateurs modernes qui restent tout le temps allumés et se mettent en veille plutôt que de s'éteindre complètement, un cookie de session expire… jamais en fait.
Il vaut mieux un cookie avec une date (ou heure, même) d'expiration proche.
De plus, que le cookie soit de session ou avec une date d'expiration, peu importe, s'il est déposé par un tracker externe comme c'est le cas ici, il peut être utilisé par ce tracker, sur tous les autres sites ou il est utilisé.
Je crois que tu as contourné la mesure d'obsolescence programmée intégrée dans le port USB de la tablette en question. Faut pas se plaindre après si c'est plus maintenu :o)
Grace à OnlyOffice je peux survivre sous Linux au bureau et échanger des documents avec mes collègues et clients utilisant Office sans tout casser dans la mise en page dès que j'ouvre un fichier. Et non, envoyer des fichier odt (ou docx tout cassés par LibreOffice) à mes clients et collègues en leur disant "j'en ai rien à faire vous avez qu'à installer LibreOffice" n'est pas une option acceptable, ni même, à mon avis, une façon de promouvoir le logiciel libre.
Personellement cela fait déjà plusieurs années que je n'ai que Haiku installé sur mon PC principal. Je ne compte pas revenir sous Linux un jour.
Je dirais que au fond, l'argument principal pour cela est le fait qu'il y a une seule équipe de personnes qui s'occupent tout à la fois de l'OS, du dépôt de paquets, et du développement des applications. Ce qui fait que quand je tombe sur un bug, ça peut être corrigé dans la journée avec .
Cela dit, il y a l'inconvénient que je tombe quand même assez souvent sur des bugs.
Pour les frais de douane, ça dépend aussi du transporteur. Les DHL, UPS, Fedex et compagnie ont tendance à faire ça systématiquement (et en profiter pour demander des frais de dédouanement au passage).
Quand tu commandes un truc en Chine, souvent, ça va passer par la poste. Le principe est différent dans ce cas, l'expéditeur paie les frais d'envoi à la poste chinoise qui remet le colis à la poste française (en gros) qui s'occupe de l'apporter jusque chez toi. La poste française transporte ça sans s'occuper de vérifier les frais de douanes, etc.
De plus les envois depuis la chine sont transportés par train ou par bateau, des USA ce sera plutôt par avion si c'est UPS/Fedex/DHL. On peut supposer que c'est plus facile de contrôler un avion qu'un train ou un bateau rempli de colis…
Il est assez facile d'installer soi-même le play store et les applications de Google sur un téléphone qui ne les a pas, non? C'est quelque chose que j'ai déjà fait en partant de LineageOS en tout cas.
Le problème n'est pas là. On peut installer n'importe quel OS sur certains téléphones (pas tous, certains fabricants verrouillent leur bootloader pour l'empêcher).
Le problème, c'est que même les fabricants ne sont pas fichus de proposer un système mis à jour. Qui d'autre en sera capable?
Il y a donc LineageOS qui prend les sources d'un Android plus à jour, et les fait fonctionner avec le noyau Linux fourni par le fabricant du téléphone.
Et il y a Replicant, qui lui fait l'exercice jusqu'au bout en compilant son propre noyau. Mais souvent, il manque des drivers parce qu'ils n'ont jamais été intégrés dans le noyau Linux mais uniquement dans les forks plus ou moins maintenus par les fabricants, voire dans le pire des cas (et assez souvent) les sources n'ont jamais été publiées nulle part.
Mais à part Fairphone, y'a pas beaucoup de fabricants pour qui le fait de proposer des mises à jour pendant plus de 2 ou 3 ans est un truc rentable. Forcément, ça leur ferait vendre moins de téléphones si les gens changent moins souvent. Ils en vendraient un peu plus aux libristes, qui aiment bricoler avec ce genre de choses, et aux écologistes, qui essaient de pas changer de téléphone tous les ans. Mais pas suffisament pour compenser le fait que si les gens changent de téléphone tous les 6 ans au lieu de tous les 3 ans, ils partent déjà avec 2 fois moins de ventes à la base. Il va falloir beaucoup plus de libristes et d'écologistes pour que ça fonctionne!
Il y a eu d'autres tentatives depuis. Certains développeurs de Haiku ont signé un NDA qui leur a permis d'accéder au code. Mais, il n'y a pas tout l'historique, seulement la dernière version qui a été portée vers Windows.
Du coup, ça fait beaucoup de travail pour étudier ce code, remplacer les morceaux qui ne pourraient pas être libéré (il faudrait vérifier qu'est-ce qui a été écrit par les auteurs de GoBe qui sont d'accord pour libérer, et qu'est-ce qui a été intégré dedans qui vient d'autres projets), et ensuite refaire le portage vers Haiku.
Finalement, porter LibreOffice était moins compliqué :)
La solution de migration sera probablement de proposer un "translator" permettant la conversion des fichiers GoBe pour les ouvrir dans LibreOffice, solution qui semble plus sage sur le long terme.
Pour Icon-O-Matic, il fonctionne très bien mais l'interface graphique est un peu perturbante. Il y a des barres de menus un peu partout dans l'interface sur lesquelles on ne pense pas forcément à cliquer. Ça fait partie des choses qu'on doit améliorer.
Problèmes connus également pour le navigateur web, et pour l'ajout d'imprimantes (j'ai une imprimante depuis quelques semaines ce qui va me permettre de travailler sur le sujet).
Pour le blocage des publicités, une solution (ou contournement?) est de les bloquer au niveau DNS via un fichier hosts, par exemple celui-ci: https://github.com/StevenBlack/hosts en attendant qu'on ajoute quelque chose dans le navigateur web.
Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive (avec un développeur de Haiku qui l'utilise toujours pour gérer sa comptabilité et la migration vers autre chose est compliquée) et SynC Modular (un synthé musical). Et il y a des centaines de logiciels écrits pour BeOS dont on a récupéré les sources aussi, avoir une compatibilité au niveau des APIs serait suffisant, mais autant avoir l'ABI aussi tant qu'on y est. Sans parler de TuneTracker Systems et iZ Corp, les deux entreprises qui ont migré depuis BeOS et comptent pas mal sur Haiku pour rester assez compatible pour ça.
Deuxième intérêt: on peut facilement comparer le comportement de notre implémentation avec celle de BeOS, il nous arrive encore de temps en temps d'avoir un doute sur le "bon" comportement d'une API et c'est utile d'avoir une référence (même si, souvent, on finit par décider de faire mieux que BeOS, par exemple sur la gestion d'erreurs).
Troisième intérêt: cela nous permet d'identifier les problèmes de compatibilité que pose la maintenance à long terme d'une API/ABI, ce qui sera utile pour la version R2 de Haiku ou on prévoit des changements plus importants, mais avec de la rétro compatibilité tout de même. Du coup on sait dans quel genre de bazar on met les pieds :)
Ce n'est pas vraiment le but de Haiku: on est là pour faire un système pour les PC de bureau. Donc tout ce qui est embarqué, ce n'est pas notre cible et on ne peut pas trop s'en occuper (on a déjà pas le temps pour ce qu'on essaie de faire…)
Sur le plan technique, on peut quand même avancer quelques réponses:
Les syscalls: il vaut mieux ne pas les utiliser directement, car on se permet des modifications dans leur API et ABI régulièrement. Il est très probable que les applications qui les utilisent cessent rapidement de fonctionner. Il faudra utiliser la libc pour les APIs POSIX et du C++ (pas le choix) pour les APIs de BeOS permettant de communiquer avec le serveur graphique. On pourrait virer le serveur graphique et utiliser directement le framebuffer, mais ce sera limité au VESA (les pilotes fonctionnant dans le serveur graphique pour les autres cas).
Les ABI: l'ABI pour le C++ ne fait pas partie du standard C++, mais aujourd'hui gcc et clang (au moins) sont d'accord pour utiliser l'ABI C++ définie à l'origine pour les processeurs Itanium, et qui s'adapte très bien aux autres machines. On peut donc utiliser indifférement ces deux compilateurs. Le problème, c'est que cette ABI est arrivée dans gcc version 3, et que BeOS utilisait la version 2. La solution pour l'instant est d'avoir 2 ensembles de bibliothèques compilées avec ces 2 versions (le problème ne se pose que pour la version x86 32bit de Haiku, pour les autres versions la compatibilité avec BeOS n'est pas assurée).
Il y a aussi plusieurs astuces dans la façon de définir les classes pour pouvoir les modifier après coup:
- Déclaration d'emplacements réservés à la fin de la vtable et des données de chaque objet, qui peuvent être remplacés ensuite par des méthodes si nécessaire,
- Ajout d'une méthode "Perform(int operationCode, …)" qui permet de faire toutes sortes de choses et qui est systématiquement surchargée par tous les objets,
- Déclaration à la main de symboles C++ pour des méthodes qui n'existent plus
Ces acrobaties demandent un peu d'habitude mais cela permet de faire fonctionner des applications écrites il y a plus de 20 ans sur les versions actuelles de Haiku. Les développeurs de chez BeOS s'étaient déjà posé la question et avaient mis en place ces solutions.
Aujourd'hui on peut également ajouter le versionnage des symboles qui permettent de modifier une fonction tout en gardant les versions précédentes pour les anciennes applications.
Par défaut l'interface graphique ne liste que les paquets "featured" (mis en avant) dont le choix est un peu arbitraire.
Pour Abiword, la version disponible n'est pas terminée et est assez instable, il me semble (en plus de ne pas être à jour). On avait voulu l'upstreamer mais on a pas été très bien reçus par les devs d'Abiword à l'époque…
Beaucoup de machines à base de ARM utilisent UEFI maintenant. U-Boot implémente aussi de quoi lancer les binaires EFI. Ce n'est donc pas un problème technique. On verra si Apple utilise ça ou choisit un bootloader fermé ne laissant pas la possibilité de démarrer autre chose que MacOS…
Cela dit, s'il s'agit de vidéos lues dans le navigateur web, le problème est surtout que le code pour faire marcher ça a été bricolé très rapidement et il y a moyen de faire beaucoup mieux. Seulement il y a toujours des choses plus urgentes à traiter ailleurs, et du coup c'est toujours pas fait.
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
Je crois qu'un des problèmes est le passage de 4K à 16K pour la taille des pages mémoire du MMU. A priori on se dit que ça devrait pas être bien important pour les applications, mais en fait, beaucoup d'applis qui ont besoin d'un peu de performance ont probablement réécrit leur propre allocateur mémoire par exemple. Et c'est pas du code qu'on modifie sans faire bien attention à ce qu'on fait, en général.
Et c'est probablement juste un exemple de truc qui change. C'est pas exclu que les devs d'Apple aient aussi profité de l'occasion pour supprimer plein de vieilles APIs inutiles au passage?
# Out of order
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 10.
Pour l'exécution out of order, faire l'ordonnancement dans le compilateur fonctionne bien quand on cible un cpu spécifique. Le problème, c'est que le code ainsi optimisé ne sera peut-être pas optimal sur une autre architecture (nouvelle génération, puce développée par un concurrent…). C'est pour ça que le cpu se permet d'intervenir.
C'est sûr que si on réfléchit en terme d'une architecture cible stable et bien connue, plein de choses pourraient être faites complètement en statique. Par exemple on pourrait laisser le compilateur gérer lui-même la mémoire cache. Sauf que si le compilateur optimise pour 1Mo de cache et que la génération de cpu suivante en a 2Mo, ce code ne l'exploitera pas. Et du coup les gains de performance ne seront pas trop visibles.
[^] # Re: Novice
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Parce que ça n'arrive qu'aux autres. Évalué à 10.
Tellement facile de se tromper, c'est le contraire ;)
Le vrai paquet: https://pypi.org/project/requests/
Et "request" n'existe plus: https://pypi.org/project/request/
[^] # Re: Article vide, titre putaclic, sans sources…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mozilla songerait à mettre de côté son navigateur historique Firefox. Évalué à 6.
Il est même co-maintenu par Apple, Sony (qui l'utilise pour la PlayStation), et Igalia (qui fait une partie du dev pour GTKWebKit, utilisé dans Epiphany, ainsi que la version "WPE" de WebKit qui peut être utilisée sur des systèmes embarqués et est conçue pour être plus facilement portable) ainsi que plusieurs contributeurs indépendants. Sans compter les versions maintenues hors du dépôt officiel (par exemple pour Haiku).
Alors oui, d'accord, "bouh c'est pas bien ce sont des entreprises et donc forcément des Grands Méchants". Mais ça reste un développement communautaire et assez ouvert aux contributions externes (la version Haiku a un temps été intégrée dans le dépôt officiel, elle avait été retirée faute de mainteneur actif).
C'est donc beaucoup mieux que Blink/Chromium, ou les sources sont publiées, mais par exemple les patchs pour permettre d'utiliser Blink sous *BSD sont rejetés. C'est donc pas vraiment le même état d'esprit.
Du côté de NetSurf, c'est plutôt un projet du type "4 personnes dans un garage" (quoi qu'il y aie eu occasionellement du sponsoring d'entreprises). Les objectifs du projet sont différents, le but étant d'avoir un navigateur très léger pouvant fonctionner sur des systèmes très divers (AmigaOS, RiscOS, …) ce qui suppose d'assurer, en plus du développement du navigateur, le portage ou la réécriture des bibliothèques nécessaires (curl, openssl, libpng, …) et la maintenance d'une toolchain pour pouvoir cross-compiler le tout pour ces architectures.
Si vous pensez que NetSurf est la solution d'avenir, il va falloir mettre les moyens pour que le projet avance (soit en y contribuant, soit en trouvant les moyens de financer un développeur qui s'y mettrait à plein temps). L'équipe actuelle n'a clairement pas assez de temps pour faire avancer les choses à une vitesse suffisante (même si ce qu'ils ont fait est déjà très bien).
[^] # Re: ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien c'était pas le bundle de l'honnêteté, en tout cas. Évalué à 3.
Il s'agit d'un "bundle" de jeux qui a été vendu en reversant les profits au mouvement Black Lives Matter. Victime de son succès car des centaines de développeurs de jeux ont mis leurs jeux dans le bundle. Et du coup, c'est pas pratique de s'y retrouver et de savoir quels jeux on a acheté.
Il était question d'un bouton dans l'application pour récupérer tous les jeux d'un coup, mais finalement ça se fera pas. Les développeurs de l'applis ne pensaient visiblement pas qu'il y aurait autant de jeux dans ce bundle quand ils ont émis l'idée de ce bouton.
Problèmes de riches, donc: des centaines de jeux pour une dizaine d'euros, et se plaindre qu'ils sont compliqués à installer? Alors que des solutions tierces existent pour explorer la liste de jeux et s'y retrouver facilement.
[^] # Re: HTTP ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 19 ans. Évalué à 9.
C'est un peu ce qui fait la différence entre Haiku et un OS quelconque :)
On fournit dans Haiku des APIs pour plein de choses (applications graphiques, réseau, multimédia, décodage et encodage d'images…). On fait, en gros, l'équivalent d'un KDE ou d'un GNOME avec tout ce qu'il faut en-dessous pour que ça fonctionne.
Et donc, oui, il y a certes des APIs pour faire des sockets directement, mais aussi une API de plus haut niveau pour faire facilement du HTTP. Ça permet d'intégrer facilement le code réseau avec le reste, en particulier avec les boucles d'évènements BLooper/BHandler, et de faciliter la vie des développeurs d'applications.
On peut facilement combiner ça avec les APIs multimédia pour écouter de la musique ou regarder un flux vidéo en streaming. Ou avec le parser json pour interroger une API en quelques dizaines de lignes de code.
Quelques exemples d'applications reposant là dessus:
- https://github.com/haikuarchives/streamradio
- https://github.com/haikuarchives/weather
- https://github.com/haikuarchives/maps
- https://github.com/pulkomandy/friss
Ainsi que le gestionnaire de paquets de Haiku (aussi bien la version en ligne de commande pour le téléchargement des paquets, que l'interface graphique pour en plus récupérer les captures d'écran, icônes, commentaires des utilisateurs, …)
[^] # Re: ma petite technique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Petite histoire de debug. Évalué à 6.
Moi j'ai un dévelopeur en peluche
[^] # Re: Peut-être pas ce qu'on croit...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sur PC, Linux monte et MS-Windows baisse. Juste un effet Covid-19 ou vraie tendance ? . Évalué à 3.
Le Terminal est développé (entre autres) par un ancien contributeur de Haiku, si jamais vous pensiez que les gens qui travaillent chez Microsoft ne sont pas des "vrais" libristes!
[^] # Re: Peut-être pas ce qu'on croit...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sur PC, Linux monte et MS-Windows baisse. Juste un effet Covid-19 ou vraie tendance ? . Évalué à 2. Dernière modification le 27 juillet 2020 à 23:16.
Il y ade plus en plus de morceaux de Windows qui apparaissent sur le compte github de Microsoft. Par exemple, la calculatrice: https://github.com/microsoft/calculator (c'est écrit en toute lettres "ships with Windows" et "MIT license")
Le Terminal: https://github.com/microsoft/terminal
[^] # Re: RGPD
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Quand la banque populaire force ses clients à manger des cookies. Évalué à 5.
Avec les téléphones et ordinateurs modernes qui restent tout le temps allumés et se mettent en veille plutôt que de s'éteindre complètement, un cookie de session expire… jamais en fait.
Il vaut mieux un cookie avec une date (ou heure, même) d'expiration proche.
De plus, que le cookie soit de session ou avec une date d'expiration, peu importe, s'il est déposé par un tracker externe comme c'est le cas ici, il peut être utilisé par ce tracker, sur tous les autres sites ou il est utilisé.
[^] # Re: À jour ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Quand la Caisse d'Épargne force ses clients à réactiver des protocoles de sécurité obsolètes. Évalué à 1.
Je crois que tu as contourné la mesure d'obsolescence programmée intégrée dans le port USB de la tablette en question. Faut pas se plaindre après si c'est plus maintenu :o)
[^] # Re: Une catastrophe pour l'interopérabilité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Dixième anniversaire d’ONLYOFFICE et nos actualités : nouveaux connecteurs, version 5.5.3. Évalué à 5.
Grace à OnlyOffice je peux survivre sous Linux au bureau et échanger des documents avec mes collègues et clients utilisant Office sans tout casser dans la mise en page dès que j'ouvre un fichier. Et non, envoyer des fichier odt (ou docx tout cassés par LibreOffice) à mes clients et collègues en leur disant "j'en ai rien à faire vous avez qu'à installer LibreOffice" n'est pas une option acceptable, ni même, à mon avis, une façon de promouvoir le logiciel libre.
[^] # Re: La nostalgie des anciens OS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Haiku, l'OS zen . Évalué à 7.
Personellement cela fait déjà plusieurs années que je n'ai que Haiku installé sur mon PC principal. Je ne compte pas revenir sous Linux un jour.
Je dirais que au fond, l'argument principal pour cela est le fait qu'il y a une seule équipe de personnes qui s'occupent tout à la fois de l'OS, du dépôt de paquets, et du développement des applications. Ce qui fait que quand je tombe sur un bug, ça peut être corrigé dans la journée avec .
Cela dit, il y a l'inconvénient que je tombe quand même assez souvent sur des bugs.
[^] # Re: America ? Say no more...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 3.
Pour les frais de douane, ça dépend aussi du transporteur. Les DHL, UPS, Fedex et compagnie ont tendance à faire ça systématiquement (et en profiter pour demander des frais de dédouanement au passage).
Quand tu commandes un truc en Chine, souvent, ça va passer par la poste. Le principe est différent dans ce cas, l'expéditeur paie les frais d'envoi à la poste chinoise qui remet le colis à la poste française (en gros) qui s'occupe de l'apporter jusque chez toi. La poste française transporte ça sans s'occuper de vérifier les frais de douanes, etc.
De plus les envois depuis la chine sont transportés par train ou par bateau, des USA ce sera plutôt par avion si c'est UPS/Fedex/DHL. On peut supposer que c'est plus facile de contrôler un avion qu'un train ou un bateau rempli de colis…
[^] # Re: Une maxime
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Haiku, l'OS zen . Évalué à 7.
Il faut dire "BeOS le faisait il y a 20 ans" maintenant. Ce qui est encore plus impressionnant!
[^] # Re: Pas clair
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la difficulté de mettre à jour Android (avec l'approbation Google). Évalué à 2.
Il est assez facile d'installer soi-même le play store et les applications de Google sur un téléphone qui ne les a pas, non? C'est quelque chose que j'ai déjà fait en partant de LineageOS en tout cas.
[^] # Re: La solution serait un genre de bios
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la difficulté de mettre à jour Android (avec l'approbation Google). Évalué à 10.
Le problème n'est pas là. On peut installer n'importe quel OS sur certains téléphones (pas tous, certains fabricants verrouillent leur bootloader pour l'empêcher).
Le problème, c'est que même les fabricants ne sont pas fichus de proposer un système mis à jour. Qui d'autre en sera capable?
Il y a donc LineageOS qui prend les sources d'un Android plus à jour, et les fait fonctionner avec le noyau Linux fourni par le fabricant du téléphone.
Et il y a Replicant, qui lui fait l'exercice jusqu'au bout en compilant son propre noyau. Mais souvent, il manque des drivers parce qu'ils n'ont jamais été intégrés dans le noyau Linux mais uniquement dans les forks plus ou moins maintenus par les fabricants, voire dans le pire des cas (et assez souvent) les sources n'ont jamais été publiées nulle part.
Mais à part Fairphone, y'a pas beaucoup de fabricants pour qui le fait de proposer des mises à jour pendant plus de 2 ou 3 ans est un truc rentable. Forcément, ça leur ferait vendre moins de téléphones si les gens changent moins souvent. Ils en vendraient un peu plus aux libristes, qui aiment bricoler avec ce genre de choses, et aux écologistes, qui essaient de pas changer de téléphone tous les ans. Mais pas suffisament pour compenser le fait que si les gens changent de téléphone tous les 6 ans au lieu de tous les 3 ans, ils partent déjà avec 2 fois moins de ventes à la base. Il va falloir beaucoup plus de libristes et d'écologistes pour que ça fonctionne!
[^] # Re: soundtracker
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Haiku, l'OS zen . Évalué à 5.
Je ne vois aucune raison qui l'empêcherait de fonctionner :) Et si jamais quelque chose est cassé, on devrait pouvoir corriger et recompiler.
On trouve aussi Protrekkr, Hively Tracker, ainsi que Sawteeth, ce dernier n'existant que pour BeOS et Haiku.
[^] # Re: mode 'brut'
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 6.
Il y a eu d'autres tentatives depuis. Certains développeurs de Haiku ont signé un NDA qui leur a permis d'accéder au code. Mais, il n'y a pas tout l'historique, seulement la dernière version qui a été portée vers Windows.
Du coup, ça fait beaucoup de travail pour étudier ce code, remplacer les morceaux qui ne pourraient pas être libéré (il faudrait vérifier qu'est-ce qui a été écrit par les auteurs de GoBe qui sont d'accord pour libérer, et qu'est-ce qui a été intégré dedans qui vient d'autres projets), et ensuite refaire le portage vers Haiku.
Finalement, porter LibreOffice était moins compliqué :)
La solution de migration sera probablement de proposer un "translator" permettant la conversion des fichiers GoBe pour les ouvrir dans LibreOffice, solution qui semble plus sage sur le long terme.
# Icon-O-Matic
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Haiku, l'OS zen . Évalué à 8.
Bonjour, merci pour ce compte rendu :)
Pour Icon-O-Matic, il fonctionne très bien mais l'interface graphique est un peu perturbante. Il y a des barres de menus un peu partout dans l'interface sur lesquelles on ne pense pas forcément à cliquer. Ça fait partie des choses qu'on doit améliorer.
Problèmes connus également pour le navigateur web, et pour l'ajout d'imprimantes (j'ai une imprimante depuis quelques semaines ce qui va me permettre de travailler sur le sujet).
Pour le blocage des publicités, une solution (ou contournement?) est de les bloquer au niveau DNS via un fichier hosts, par exemple celui-ci: https://github.com/StevenBlack/hosts en attendant qu'on ajoute quelque chose dans le navigateur web.
[^] # Re: mode 'brut'
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 8.
Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive (avec un développeur de Haiku qui l'utilise toujours pour gérer sa comptabilité et la migration vers autre chose est compliquée) et SynC Modular (un synthé musical). Et il y a des centaines de logiciels écrits pour BeOS dont on a récupéré les sources aussi, avoir une compatibilité au niveau des APIs serait suffisant, mais autant avoir l'ABI aussi tant qu'on y est. Sans parler de TuneTracker Systems et iZ Corp, les deux entreprises qui ont migré depuis BeOS et comptent pas mal sur Haiku pour rester assez compatible pour ça.
Deuxième intérêt: on peut facilement comparer le comportement de notre implémentation avec celle de BeOS, il nous arrive encore de temps en temps d'avoir un doute sur le "bon" comportement d'une API et c'est utile d'avoir une référence (même si, souvent, on finit par décider de faire mieux que BeOS, par exemple sur la gestion d'erreurs).
Troisième intérêt: cela nous permet d'identifier les problèmes de compatibilité que pose la maintenance à long terme d'une API/ABI, ce qui sera utile pour la version R2 de Haiku ou on prévoit des changements plus importants, mais avec de la rétro compatibilité tout de même. Du coup on sait dans quel genre de bazar on met les pieds :)
[^] # Re: mode 'brut'
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5.
Bonjour,
Ce n'est pas vraiment le but de Haiku: on est là pour faire un système pour les PC de bureau. Donc tout ce qui est embarqué, ce n'est pas notre cible et on ne peut pas trop s'en occuper (on a déjà pas le temps pour ce qu'on essaie de faire…)
Sur le plan technique, on peut quand même avancer quelques réponses:
Les syscalls: il vaut mieux ne pas les utiliser directement, car on se permet des modifications dans leur API et ABI régulièrement. Il est très probable que les applications qui les utilisent cessent rapidement de fonctionner. Il faudra utiliser la libc pour les APIs POSIX et du C++ (pas le choix) pour les APIs de BeOS permettant de communiquer avec le serveur graphique. On pourrait virer le serveur graphique et utiliser directement le framebuffer, mais ce sera limité au VESA (les pilotes fonctionnant dans le serveur graphique pour les autres cas).
Les ABI: l'ABI pour le C++ ne fait pas partie du standard C++, mais aujourd'hui gcc et clang (au moins) sont d'accord pour utiliser l'ABI C++ définie à l'origine pour les processeurs Itanium, et qui s'adapte très bien aux autres machines. On peut donc utiliser indifférement ces deux compilateurs. Le problème, c'est que cette ABI est arrivée dans gcc version 3, et que BeOS utilisait la version 2. La solution pour l'instant est d'avoir 2 ensembles de bibliothèques compilées avec ces 2 versions (le problème ne se pose que pour la version x86 32bit de Haiku, pour les autres versions la compatibilité avec BeOS n'est pas assurée).
Il y a aussi plusieurs astuces dans la façon de définir les classes pour pouvoir les modifier après coup:
- Déclaration d'emplacements réservés à la fin de la vtable et des données de chaque objet, qui peuvent être remplacés ensuite par des méthodes si nécessaire,
- Ajout d'une méthode "Perform(int operationCode, …)" qui permet de faire toutes sortes de choses et qui est systématiquement surchargée par tous les objets,
- Déclaration à la main de symboles C++ pour des méthodes qui n'existent plus
Ces acrobaties demandent un peu d'habitude mais cela permet de faire fonctionner des applications écrites il y a plus de 20 ans sur les versions actuelles de Haiku. Les développeurs de chez BeOS s'étaient déjà posé la question et avaient mis en place ces solutions.
Aujourd'hui on peut également ajouter le versionnage des symboles qui permettent de modifier une fonction tout en gardant les versions précédentes pour les anciennes applications.
[^] # Re: Super
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
Par défaut l'interface graphique ne liste que les paquets "featured" (mis en avant) dont le choix est un peu arbitraire.
Pour Abiword, la version disponible n'est pas terminée et est assez instable, il me semble (en plus de ne pas être à jour). On avait voulu l'upstreamer mais on a pas été très bien reçus par les devs d'Abiword à l'époque…
[^] # Re: Plus de Linux ou Windows sur Mac?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Transition ARM : Apple assistera certains projet open source . Évalué à 4.
Beaucoup de machines à base de ARM utilisent UEFI maintenant. U-Boot implémente aussi de quoi lancer les binaires EFI. Ce n'est donc pas un problème technique. On verra si Apple utilise ça ou choisit un bootloader fermé ne laissant pas la possibilité de démarrer autre chose que MacOS…
[^] # Re: Super
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
Oui.
Cela dit, s'il s'agit de vidéos lues dans le navigateur web, le problème est surtout que le code pour faire marcher ça a été bricolé très rapidement et il y a moyen de faire beaucoup mieux. Seulement il y a toujours des choses plus urgentes à traiter ailleurs, et du coup c'est toujours pas fait.