Ce sont pas les premiers à faire ce genre de choses (désactiver les coeurs non fonctionnels). C'est le cas sur le processeur de la PlayStation 3, et c'est une solution qui est tout à fait raisonnable quand le "die" est un peu large. De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.
Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.
Alors je sais pas si c'est un choix de Dell de ne faire que du Intel, ou si c'est Intel qui leur met la pression pour ne rien faire avec les CPUs concurrents.
En poussant les choses un peu loin dans cette direction on a Java: le compilateur (javac) traduit le code Java en bytecode complètement générique et fait assez peu d'optimisations. Et laisse la machine virtuelle se débrouiller pour optimiser les choses pour la machine sur laquelle le code s'exécute en mettant en oeuvre les stratégies appropriées: JIT ou pas, différentes possibilités de garbage collector, mise en cache du code compilé définitif, …
L'inconvénient c'est qu'un code qui s'exécute très bien dans un cas peut devenir très lent dans un autre, et c'est souvent assez obscur à débugger quand il faut comprendre pourquoi.
Il a fallu attendre que AMD implémente le SSE2 dans ses processeurs 64bit pour que ça devienne un standard de fait, en effet. Avant ils avaient leur propre jeu d'instruction (3dNow!). Mais je ne vois pas ce que Intel pouvait y faire. Enfin si, ils auraient pu utiliser 3dNow! au lieu d'inventer le SSE qui est arrivé après…
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 :)
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
Ce sont pas les premiers à faire ce genre de choses (désactiver les coeurs non fonctionnels). C'est le cas sur le processeur de la PlayStation 3, et c'est une solution qui est tout à fait raisonnable quand le "die" est un peu large. De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.
Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.
[^] # Re: AMD dans les consoles next-gen
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 8.
Par exemple chez Dell il n'y a aucun PC dans les gammes pro avec un CPU AMD:
https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/all-amd-processors?appliedRefinements=6077 (il trouve deux Inspiron, qui n'est pas une gamme pro)
Alors je sais pas si c'est un choix de Dell de ne faire que du Intel, ou si c'est Intel qui leur met la pression pour ne rien faire avec les CPUs concurrents.
[^] # Re: Out of order
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 7.
En poussant les choses un peu loin dans cette direction on a Java: le compilateur (javac) traduit le code Java en bytecode complètement générique et fait assez peu d'optimisations. Et laisse la machine virtuelle se débrouiller pour optimiser les choses pour la machine sur laquelle le code s'exécute en mettant en oeuvre les stratégies appropriées: JIT ou pas, différentes possibilités de garbage collector, mise en cache du code compilé définitif, …
L'inconvénient c'est qu'un code qui s'exécute très bien dans un cas peut devenir très lent dans un autre, et c'est souvent assez obscur à débugger quand il faut comprendre pourquoi.
[^] # Re: ce qui tue intel...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 5.
Il a fallu attendre que AMD implémente le SSE2 dans ses processeurs 64bit pour que ça devienne un standard de fait, en effet. Avant ils avaient leur propre jeu d'instruction (3dNow!). Mais je ne vois pas ce que Intel pouvait y faire. Enfin si, ils auraient pu utiliser 3dNow! au lieu d'inventer le SSE qui est arrivé après…
[^] # 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 :)