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.
Ce qui marche bien c'est surtout de rejoindre quelques groupes de discussions (par exemple le salon de JabberFR qui sert un peu d'accueil général pour la communauté francophone).
Le moyen le plus évident de rencontrer des utilisateurs de XMPP, après tout, c'est de les contacter par XMPP!
Il y a d'autres petits trucs du même genre dans les licenses MIT et BSD en effet (je ne crois pas avoir dit le contraire).
D'autres exemple:
Il y a une permission de "sublicense", et ce mot n'est pas clair. Est-ce que ça permet de mettre le même code sous une license qui donne moins de droits?
La license nécessite que toute redistribution du code inclue "le texte de la license et la notice de copyright ci-dessus". Le "ci-dessus" est pénible parce qu'on ne peut pas séparer la license de la notice de copyright. Et du coup, impossible d'avoir un seul fichier "license MIT" utilisable par plusieurs bouts de code utilisant la même license mais avec des copyrights différents (le problème se pose dans Haiku pour les paquets d'applications, qui se contentent de préciser LICENSE="MIT", le texte de la license étant fourni par ailleurs mais pas inclus verbatim dans le paquet).
Au final il n'y a peut être que la WTFPL qui arrive à éviter tous ces problèmes, forcément.
Il faut prévoir "pas mal" de RAM (les 256MB c'est vraiment la config mini pour démarrer le système, avec 512MB il y aura un peu plus de place pour lancer des applications), et ça sera probablement assez lent, en particulier pour les applications en Qt, je pense (pas que Qt soit forcément lent, mais il y a forcément une couche de bazar en plus par rapport aux applications natives). Pour le web tu vas être limité par NetSurf (pas de SSE2 dans ces CPUs, donc WebKit ne peut pas fonctionner), et donc pas de Javascript, ce qui allège pas mal les choses mais limite aussi les possibilités.
Je n'ai plus de matériel aussi ancien sous la main, ma config de référence (qui est compatible avec un BeOS bricolé, pour comparer le comportement avec Haiku quand on a un doute) c'est un Athlon XP 2200+ avec 512MB (ou 1GB?) de RAM et c'est utilisable (sauf pour le développement, en fait. ça prendrait des heures de compiler quoi que ce soit d'un peu imposant avec un gcc moderne).
Mais c'est l'occasion de repérer les trucs qui sont déraisonablement lents (et pas juste normalement lents sur une machine de ce type) et de nous remonter les infos pour savoir ce qu'on doit optimiser en priorité :o)
LibreOffice: oui
GIMP: non
Calibre: oui
Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.
Messagerie: clients natif (Beam et le client intégré à Haiku), une vieille version de Thunderbird.
Messagerie instantanée: client IRC natif Vision, XMPP natif Renga, divers clients en Qt sont disponibles aussi (Quassel, divers clients XMPP dont le nom m'échappe). Telegram est disponible, mais pas Whatsapp.
Editeurs de texte: Vim et Emacs sont disponibles ainsi que au moins deux éditeurs natifs: Koder et Pe.
Calculatrice: DeskCalc inclus avec Haiku, diverses alternatives plus ou moins complètes sont disponibles dont SpeedCrunch par exemple.
Capture d'écran: accessible par la touche prévue à cet effet sur le clavier (possibilité de prendre tout l'écran, ou une seule fenêtre)
Recompilation des drivers: hors de question, l'interface entre le noyau et les drivers est bien définie et ne change pas d'une version à l'autre. Maintenant on attend que NVidia, AMD et Intel fournissent les drivers… (et on travaille sur nos propres drivers en attendant mais on ne s'est pas lancés dans l'accélération 3D pour le moment)
Ecrans haute résolution: en principe il suffit de changer la taille des polices dans les préférences Apparence, et le reste de l'interface se met à l'échelle en fonction. Il nous reste du travail à certains endroits pour que ça fonctionne parfaitement.
Ah si, c'est du ELF, aucun problème de ce côté là.
Et oui, la LKML. Je crois qu'on passerait plus de temps et d'énergie à expliquer aux développeurs Linux le pourquoi et le comment de chaque patch qu'on en a passé à maintenir notre propre noyau, en fait.
Il y a aussi le fait qu'on a envie d'écrire du code propre en C++ et pas du C qui est trop bas niveau pour avoir quelque chose de lisible, y compris dans le kernel. Déjà avec ça je pense que c'est très très mal parti pour upstreamer quoi que ce soit.
Globalement ça ne me semble pas acceptable pour Haiku d'être dépendant d'un autre projet pour décider de ce qui sera intégré ou pas dans son noyau, des langages de programmation utilisés, et de choix d'architecture interne. Alors certes, ça nous fait un peu de travail en plus pour maintenir nos propres drivers, mais ça nous donne de l'indépendance et les moyens d'expérimenter des choses en allant beaucoup plus loin que si on devait travailler avec Linux.
Je pense que c'est globalement l'avis de la plupart des développeurs. Et sinon, il y a V-OS que j'ai mentionné dans un de mes commentaires qui tente cette approche, et qui peut-être nous donnera tort?
Un peu plus sérieusement, ce qui m'embête dans la GPL c'est surtout que la license est longue et que finalement peu de gens (même ici!) prennent le temps de la lire. La preuve, chaque fois que je parle de ce genre de détails, on me dit "mais t'es sûr de ça?".
Je trouve ça dommage parce que du coup c'est facile de louper un truc dans cette license assez longue et riche en subtilités. Il me semble d'ailleurs que l'une des personnes qui a beaucoup travaillé sur la rédaction de la GPL 3 n'est pas d'accord avec la FSF sur l'interprétation de certaines parties du texte…
Cette complexité fait aussi que, forcément, la license se retrouve moins adaptable au cours du temps, comme tu le dis, internet en 1991 c'était très différent d'aujourd'hui et une license qui rentre autant dans les détails ne pouvait pas tout prévoir.
Le résultat c'est que chaque paragraphe pose beaucoup de questions (c'est quoi un "medium"? est-ce que le "coût de la reproduction physique" implique que la reproduction est forcément sur un support physique, ou bien est-ce qu'un lien de téléchargement suffit? et ainsi de suite). Et on parle juste d'un tout petit morceau de la GPL, je trouve que le reste est à peu près du même genre. Du coup il faut ensuite aller lire la FAQ de la FSF pour des informations complémentaires, etc.
Ces raisons font que je n'aime pas beaucoup la GPL, même si je n'ai pas grand chose de mieux à proposer pour une license copyleft. Mon approche est plutôt d'utiliser une license permissive et de convaincre les gens de l'intérêt de publier les sources (facilité de maintenance, aide de la communauté pour le développement, etc) et je pense qu'une license comme la GPL n'est pas nécessaire. Mais cela dépend des projets, c'est facile par exemple pour Haiku ou on a pas vraiment (pour l'instant, et à ma connaissance) de Grand Méchant Microsoft ou je sais pas quoi qui viendrait nous piquer nos sources pour faire un truc sans rien publier. Il y a des cas ou la protection apportée par la GPL est utile, et c'est peut-être ça aussi qui a permis de populariser le logiciel libre et de montrer que c'est un modèle qui fonctionne.
[^] # 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.
[^] # Re: Conseils demandés
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche XMPP@home, 9 juin 2020. Évalué à 4. Dernière modification le 18 juin 2020 à 08:53.
Ce qui marche bien c'est surtout de rejoindre quelques groupes de discussions (par exemple le salon de JabberFR qui sert un peu d'accueil général pour la communauté francophone).
Le moyen le plus évident de rencontrer des utilisateurs de XMPP, après tout, c'est de les contacter par XMPP!
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 2.
Il y a d'autres petits trucs du même genre dans les licenses MIT et BSD en effet (je ne crois pas avoir dit le contraire).
D'autres exemple:
Il y a une permission de "sublicense", et ce mot n'est pas clair. Est-ce que ça permet de mettre le même code sous une license qui donne moins de droits?
La license nécessite que toute redistribution du code inclue "le texte de la license et la notice de copyright ci-dessus". Le "ci-dessus" est pénible parce qu'on ne peut pas séparer la license de la notice de copyright. Et du coup, impossible d'avoir un seul fichier "license MIT" utilisable par plusieurs bouts de code utilisant la même license mais avec des copyrights différents (le problème se pose dans Haiku pour les paquets d'applications, qui se contentent de préciser LICENSE="MIT", le texte de la license étant fourni par ailleurs mais pas inclus verbatim dans le paquet).
Au final il n'y a peut être que la WTFPL qui arrive à éviter tous ces problèmes, forcément.
[^] # Re: Logiciels compatibles ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 7.
Il faut prévoir "pas mal" de RAM (les 256MB c'est vraiment la config mini pour démarrer le système, avec 512MB il y aura un peu plus de place pour lancer des applications), et ça sera probablement assez lent, en particulier pour les applications en Qt, je pense (pas que Qt soit forcément lent, mais il y a forcément une couche de bazar en plus par rapport aux applications natives). Pour le web tu vas être limité par NetSurf (pas de SSE2 dans ces CPUs, donc WebKit ne peut pas fonctionner), et donc pas de Javascript, ce qui allège pas mal les choses mais limite aussi les possibilités.
Je n'ai plus de matériel aussi ancien sous la main, ma config de référence (qui est compatible avec un BeOS bricolé, pour comparer le comportement avec Haiku quand on a un doute) c'est un Athlon XP 2200+ avec 512MB (ou 1GB?) de RAM et c'est utilisable (sauf pour le développement, en fait. ça prendrait des heures de compiler quoi que ce soit d'un peu imposant avec un gcc moderne).
Mais c'est l'occasion de repérer les trucs qui sont déraisonablement lents (et pas juste normalement lents sur une machine de ce type) et de nous remonter les infos pour savoir ce qu'on doit optimiser en priorité :o)
[^] # Re: Logiciels compatibles ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
LibreOffice: oui
GIMP: non
Calibre: oui
Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.
Messagerie: clients natif (Beam et le client intégré à Haiku), une vieille version de Thunderbird.
Messagerie instantanée: client IRC natif Vision, XMPP natif Renga, divers clients en Qt sont disponibles aussi (Quassel, divers clients XMPP dont le nom m'échappe). Telegram est disponible, mais pas Whatsapp.
Editeurs de texte: Vim et Emacs sont disponibles ainsi que au moins deux éditeurs natifs: Koder et Pe.
Calculatrice: DeskCalc inclus avec Haiku, diverses alternatives plus ou moins complètes sont disponibles dont SpeedCrunch par exemple.
Capture d'écran: accessible par la touche prévue à cet effet sur le clavier (possibilité de prendre tout l'écran, ou une seule fenêtre)
Recompilation des drivers: hors de question, l'interface entre le noyau et les drivers est bien définie et ne change pas d'une version à l'autre. Maintenant on attend que NVidia, AMD et Intel fournissent les drivers… (et on travaille sur nos propres drivers en attendant mais on ne s'est pas lancés dans l'accélération 3D pour le moment)
Ecrans haute résolution: en principe il suffit de changer la taille des polices dans les préférences Apparence, et le reste de l'interface se met à l'échelle en fonction. Il nous reste du travail à certains endroits pour que ça fonctionne parfaitement.
[^] # Re: Amusant que Haiku soit le seul survivant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5.
Ah si, c'est du ELF, aucun problème de ce côté là.
Et oui, la LKML. Je crois qu'on passerait plus de temps et d'énergie à expliquer aux développeurs Linux le pourquoi et le comment de chaque patch qu'on en a passé à maintenir notre propre noyau, en fait.
Il y a aussi le fait qu'on a envie d'écrire du code propre en C++ et pas du C qui est trop bas niveau pour avoir quelque chose de lisible, y compris dans le kernel. Déjà avec ça je pense que c'est très très mal parti pour upstreamer quoi que ce soit.
Globalement ça ne me semble pas acceptable pour Haiku d'être dépendant d'un autre projet pour décider de ce qui sera intégré ou pas dans son noyau, des langages de programmation utilisés, et de choix d'architecture interne. Alors certes, ça nous fait un peu de travail en plus pour maintenir nos propres drivers, mais ça nous donne de l'indépendance et les moyens d'expérimenter des choses en allant beaucoup plus loin que si on devait travailler avec Linux.
Je pense que c'est globalement l'avis de la plupart des développeurs. Et sinon, il y a V-OS que j'ai mentionné dans un de mes commentaires qui tente cette approche, et qui peut-être nous donnera tort?
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
Un peu plus sérieusement, ce qui m'embête dans la GPL c'est surtout que la license est longue et que finalement peu de gens (même ici!) prennent le temps de la lire. La preuve, chaque fois que je parle de ce genre de détails, on me dit "mais t'es sûr de ça?".
Je trouve ça dommage parce que du coup c'est facile de louper un truc dans cette license assez longue et riche en subtilités. Il me semble d'ailleurs que l'une des personnes qui a beaucoup travaillé sur la rédaction de la GPL 3 n'est pas d'accord avec la FSF sur l'interprétation de certaines parties du texte…
Cette complexité fait aussi que, forcément, la license se retrouve moins adaptable au cours du temps, comme tu le dis, internet en 1991 c'était très différent d'aujourd'hui et une license qui rentre autant dans les détails ne pouvait pas tout prévoir.
Le résultat c'est que chaque paragraphe pose beaucoup de questions (c'est quoi un "medium"? est-ce que le "coût de la reproduction physique" implique que la reproduction est forcément sur un support physique, ou bien est-ce qu'un lien de téléchargement suffit? et ainsi de suite). Et on parle juste d'un tout petit morceau de la GPL, je trouve que le reste est à peu près du même genre. Du coup il faut ensuite aller lire la FAQ de la FSF pour des informations complémentaires, etc.
Ces raisons font que je n'aime pas beaucoup la GPL, même si je n'ai pas grand chose de mieux à proposer pour une license copyleft. Mon approche est plutôt d'utiliser une license permissive et de convaincre les gens de l'intérêt de publier les sources (facilité de maintenance, aide de la communauté pour le développement, etc) et je pense qu'une license comme la GPL n'est pas nécessaire. Mais cela dépend des projets, c'est facile par exemple pour Haiku ou on a pas vraiment (pour l'instant, et à ma connaissance) de Grand Méchant Microsoft ou je sais pas quoi qui viendrait nous piquer nos sources pour faire un truc sans rien publier. Il y a des cas ou la protection apportée par la GPL est utile, et c'est peut-être ça aussi qui a permis de populariser le logiciel libre et de montrer que c'est un modèle qui fonctionne.