Pour un projet mature il me semble normal qu'il y aie peu d'activité: il n'y a plus rien à faire, plus de bugs à corriger, pas de nouvelles fonctionalités à ajouter.
On peut pas à la fois se plaindre que KDE 5 est tout le temps tout cassé et pas stable, et que Trinity n'évolue pas assez.
Contribuer ce n'est pas forcément écrire du code. Les rapports de bugs, ou même écrire une documentation "par où commencer" lorsqu'il n'y en a pas, ça peut être une bonne façon de commencer à aider un projet.
Par contre, c'est vrai que tous les gens qui contribuent au libre, et toutes les communautés, ne sont pas forcément accueillantes. Mais là, c'est tant pis pour eux, tu peux les laisser se débrouiller tout seuls :)
D'abord, attention pour le multi-utilisateur, il y a bien une prise en charge des utilisateurs au sens UNIX, même si elle est imparfaite. Cependant, c'est avant tout un mécanisme de sécurité, et il est possible qu'on ne l'utilise pas (ou en tout cas, pas directement) pour faire un système multi-utilisateur. Il y a encore eu peu de travail de ce côté, mais l'idée est que la gestion des permissions et le fait d'avoir plusieurs utilisateurs sont des choses différentes et qui ne doivent pas être liées aussi fortement qu'elles le sont sous Linux.
Qiand on dit que Haiku ne gère pas plusieurs utilisateurs, c'est dans le sens où on ne peut avoir qu'une seule session graphique pour le moment. ça n'empêche pas de créer des utilisateurs différents qui pourront se connecter en ssh, par exemple (et qui ne pourront pas lancer d'applications utilisant le serveur graphiques ou certains autres services).
Sur la compatibilité avec BeOS: il existe déjà une version 64-bit de Haiku, qui n'est pas compatible avec BeOS. Elle sera officiellement supportée et diffusée dès la release beta1 (bientôt, enfin j'espère). La version R1 de Haiku sera la dernière compatible avec BeOS, ensuite on travaillera sur la version R2, qui elle, sera compatible avec la version R1 et introduira en parallèle de nouvelles APIs. Et ainsi de suite. Il est essentiel que chaque version soit compatible au moins avec la précédente, car cela permet aux développeurs d'application de pouvoir migrer d'une version majeure de l'API à la suivante dans un délai assez long. Le but de la compatibilité avec BeOS, plus que le fait de continuer à faire fonctionner les applications, est, d'une part de pouvoir comparer notre comportement avec celui de BeOS (parfois, on se demande pourquoi une application plante, et on se rend compte qu'elle ne fonctionnait pas non plus sous BeOS et donc que Haiku n'y est pour rien), et d'autre part, de faire nos armes sur la façon de gérer les problèmes de compatibilité et la façon de concevoir nos APIs et nos ABIs pour pouvoir assurer une certaine évolutivité tout en restant compatibles.
Pour l'idée de transporter certaines choses sur un noyau Linux, c'est possible, mais pas pour tout. Une raison pour cela est justement liée à des problématiques de sécurité. Par exemple, l'API de BeOS permet de référencer un fichier directement par son numéro d'inode. Ce qui est pratique dans certains cas (pour communiquer efficacement l'emplacement d'un fichier d'une application vers une autre), mais impossible sous Linux car cela permettrait de contourner les droits sur les fichiers. Du coup, cette API ne peut pas être reproduite telle quelle. Il existe, ou plutôt il a existé, au moins deux projets avec ce but: BlueEyedOS et Cosmoe. Personellement je serais plutôt content de les voir vivre, en plus de Haiku, de la même façon qu'il y a plein d'implémentations de UNIX ou POSIX aujourd'hui.
Ensuite pour l'aspect novateur: les idées ne manquent pas, mais les moyens pour les réaliser, un peu plus. Mais on a déjà accompli pas mal de choses. Il y a le gestionnaire de paquets, et il y a aussi des travaux de recherche de l'université d'Aukland, avec par exemple la possibilité de faire du tiling et des tabs dans le gestionnaire de fenêtres, ou encore un système de gestion du layout des interfaces graphiques utilisant un solveur de contraintes linéaires (en principe, il doit pouvoir faire le layout de la fenêtre "tout seul" en fonction des contraintes indiquées par le programmeur). Et il y a toutes sortes de choses dans les cartons et que l'on verra peut être fonctionner un jour.
En ce qui concerne la gestion de la RAM (commentaire en-dessous, je réponds à tout le monde en même temps): sous Haiku, s'il n'y a pas assez de mémoire disponible, une application qui fait une allocation se voit retourner un pointeur NULL, ce qui lui permet de gérer l'erreur proprement. Malhereusement, beaucoup d'applications supposent un comportement proche de celui de Linux et ne prennent pas la peine de vérifier.
Haiku étant écrit en C++ et avec de gros efforts faits sur la lisibilité du code, plutôt que sur la performance, je pense qu'il y a du potentiel pour obtenir du code sécurisé à terme. Mais ça ne marche que si les gens prennent le temps d'inspecter et de remonter les erreurs trouvées. Haiku utilise Coverity (un outil d'analyse statique du code qui détecte de nombreux cas de failles potentielles), et la plupart des erreurs trouvées sont dans du code tiers (la bibliothèque de résolution DNS importée de NetBSD, ou la librairie de résolution des dépendances du gestionnaire de paquets empruntée à SUSE, par exemple). Maintenant, je ne m'avancerai pas plus loin vu qu'il n'y a pas vraiment eu de tests ou d'investigations menées de ce côté.
La beta n'est pas encore disponible, mais sur http://download.haiku-os.org tu peux trouver des "nightly builds" qui s'en rapprochent et que je recommande d'utiliser. En particulier, le gestionnaire de paquets est disponible ce qui simplifie pas mal de choses.
Il n'y a plus tellement de travail à faire sur le code, les nightlies sont plutôt stable (même si ce n'est jamais parfait). Le gros du travail sur la beta est plutôt sur la mise en place de l'infrastructure pour construire et distribuer les paquets, chose qu'on a pas trop l'habitude de faire pour le moment.
Haiku a besoin de 192Mo de RAM et d'un processeur avec support du MMX (soit à peu près n'importe quoi fabriqué après 1995). Pour utiliser le navigateur web, il y a besoin de SSE (soit à peu près n'importe quoi fabriqué après 1999).
Bien sûr, il fonctionne mieux sur des machines plus puissantes, et si c'est possible, tu peux prendre la version 64-bit qui utilise un compilateur plus récent et est donc mieux optimisée.
On ne peut pas encore tout faire (le navigateur web est encore un peu en chantier et il n'y a pas encore de suite office - mais on y travaille).
Il est facile de tester en live USB pour voir ce que ça donne avant de se lancer pour une installation permanente.
En ce qui me concerne, j'ai appris beaucoup en contribuant à Haiku. J'ai commencé en tant qu'étudiant lors du Google Summer of Code. Je ne pense pas pouvoir parler de nostalgie, puisque je n'ai découvert BeOS que vers 2006 ou 2007 (c'était déjà mort depuis 5 ans) et que j'ai continué avec Haiku dès que cela a été possible (en gros vers 2009 avec la sortie de la première version alpha).
Mais même maintenant, mes machines sous Linux ou Windows sont loin d'avoir la fluidité de Haiku. Tout me semble insupportablement lent et pas pratique. Je suis bien content de pouvoir utiliser Haiku chez moi et pour faire de plus en plus de choses.
On connaît tous la blague de "l'année de Linux sur le Desktop". Pourtant, ça n'arrive toujours pas. Et peut-être, qui sait, ça marcherait mieux sans Linux? Mais bon, je ne me prends pas trop au sérieux là-dessus. J'ai eu la chance de pouvoir travailler un an à plein temps sur Haiku grâce aux dons de la communauté d'utilisateurs, et ça, c'est déjà super.
Il y a aussi le fait que la communauté des développeurs autour de Haiku est plutôt ouverte et accueillante aux nouveaux contributeurs. Comme je l'ai mentionné dans la dépêche, c'est un des 3 projets à avoir survécu à 7 ans de Google Code-In, et il y a d'autres exemples d'utilisateurs qui sont parti de rien et qui ont fini par apprendre le C++ et développer leurs propres applications.
Enfin, il y a bien des utilisateurs sérieux qui vendent des systèmes fonctionnant sous Haiku. Il y a au moins TuneTracker Systems (http://tunetrackersystems.com) et il est question de projets en cours chez iZ Corp (http://www.izcorp.com), qui sont probablement les derniers utilisateurs de BeOS.
Ce n'est pas monolithique. L'architecture du système est modulaire et on peut remplacer des composants. Cependant, il semble préférable d'avoir une seule équipe en charge de tout le système pour apporter de la cohérence.
On peut également réutiliser des morceaux de code venu d'ailleurs. Le shell est bash, le serveur graphique utilise AGG et Freetype, l'internationalisation est assurée par ICU, les drivers réseau viennent de FreeBSD, le décodage média est fait par ffmpeg et il y a plein d'autres exemples. Cependant, ceci est invisible des applications qui n'ont affaire qu'à l'API de Haiku. Donc, on peut à tout moment décider de remplacer une de ces bibliothèques par autre chose (soit une autre implémentation, soit simplement une version plus récente). Le tout sans le moindre changement dans les applications. Ainsi des applications écrites pour BeOS peuvent se lancer sur Haiku et décoder des fichiers vidéo dans des formats modernes qui n'existaient même pas quand elles ont été écrites, par exemple.
Le portage ARM de Haiku est malhereusement laissé de côté par manque d'intérêt ou de temps. De plus, on a choisi de laisser le Pi de côté en raison de son CPU ARMv6 (alors que tout le monde fait au moins de l'ARMv7). Il y a eu pas mal de travail sur le support de la Beagleboard xM, qui a l'avantage d'utiliser un CPU plutôt bien documenté. Et dernièrement, un peu de travail sur le Raspberry Pi 3, mais on a pas encore de driver fonctionnel pour le framebuffer, du coup le système plante au démarrage en essayant d'afficher le splash screen (et il manque plein d'autres trucs derrière avant d'espérer arriver sur le bureau de Haiku).
Mais on accepte toutes les contributions pour de nouveaux portages (ARM ou autres). Et il y a plein de gens prêt à partager leurs connaissances pour aider à faire avancer les choses, même s'ils n'ont pas forcément le temps d'écrire le code eux-même.
Le projet Haiku a été créé dans ce but: fournir une continuité à BeOS. La première étape, c'est de remplacer BeOS par un système entièrement libre. Comme c'est mentionné dans la dépêche, on essaie quand même de rester pertinents avec des choses comme le passage au 64-bit, qui de toutes façons casse la compatibilité. À partir de la version R2 de Haiku, on ne sera donc plus compatibles et on pourra se poser plein de questions sur le shell par défaut, les APIs, et tout plein d'autres trucs.
Mais pour le moment, on essaie de rester concentrés sur ce premier objectif.
Pour les applications BeOS encore utilisées, il y a au moins GoBe Productive (une suite bureautique, pour laquelle d'une part il n'y a pas vraiment de remplacement, et d'autre part, il faudrait pouvoir convertir les fichiers dans un format lisible par d'autres outils), et SynC Modular (un synthétiseur musical modulaire). Pour ces deux là, on a pas réussi à avoir accès au code source pour les mettre à jour pour une version 64-bits. Il y a sûrement plein d'autres logiciels pour BeOS qui fonctionnent avec Haiku et qui sont encore utiles.
La migration vers des applications plus à jour se fait petit à petit. Ce qui nous permettra par la suite de passer à un système entièrement 64bit et sans les contraintes de BeOS. Mais c'est pas quelque chose qu'on peut faire du jour au lendemain.
En ce qui me concerne, j'utilise Haiku autant que possible pour tout ce que je fais. Il me manque encore une suite office correcte, le support de l'impression qui marche complètement, et un client dropbox. Pour le reste j'arrive à m'en sortir.
Après il y a plein de besoins spécifiques (par exemple si je veux faire des schémas électroniques, j'aurais bien besoin de Kicad ou un outil du même genre).
Mais finalement, les trucs qui me manquent sont plutôt des applications. Donc je suppose que le système lui-même est prêt?
Après il y aura toujours des gens pour râler sur l'absence de drivers pour les webcams, les problèmes de compatibilité du navigateur web, ou l'absence de support de l'USB3, par exemple. C'est de ce côté là qu'on a le plus de travail, finalement: fournir des pilotes de périphériques pour du matériel qui continue d'évoluer tout le temps. Heureusement, on peut s'inspirer du travail de FreeBSD ou de Fuchsia/Magenta pour les drivers, et même parfois leur emprunter des morceaux de code (on n'utilise pas celui de Linux, car il est sous GPL - trop restrictive pour nous, on préfère la licence MIT - et aussi car en général le code est peu lisible, peut être par manque d'habitude).
Pour le terminal, on est parti de code existant, à l'époque c'était un terminal pour BeOS avec la prise en charge des caractères Japonais (qui font 2 fois la largeur des caractères latins, même avec une police monospace).
Mais en effet, il y a dans les cartons un projet de remplacer une partie du code du terminal par libvterm. Mais pour cela il faudrait que les performances soient acceptables, et avec le portage actuel de libvterm, ce n'est pas le cas.
Pour la gestion des fichiers modifiables, c'est prévu, certains dossiers sont accessible en écriture (la hiérarchie n'est pas la même que sous Linux, donc pas de /var et de /etc, mais l'idée est la même). Les paquets peuvent copier des fichiers dans ces dossiers lors de leur installation, avec une gestion des fichiers existants (soit remplacés, soit conservés, selon la décision du paquet).
Pour la décision de refaire les composants, je peux prendre l'exemple récent du gestionnaire de paquets. Avant de se lancer, on a fait une revue de tout ce qui existait, en essayant de prendre en compte les demandes de nos utilisateurs. La conclusion était que rien ne nous convenait. On a donc choisi de développer notre propre système. Cependant, on utilise libsolv, qui gère très bien la résolution des dépendances entre paquets et qui provient de SUSE.
L'un des objectifs de Haiku est de fournir un système cohérent et fortement intégré. Cela veut dire qu'on peut modifier le noyau ou le bootloader pour faire fonctionner notre système de paquets. Qu'on peut modifier le serveur graphique pour y ajouter les primitives nécessaires pour accélérer le rendu des pages par notre navigateur web. Ce genre de chose prend des années à coordonner dans un écosystème de type GNU/Linux, avec un assemblage hétéroclyte de plein de projets. D'autre part, avoir tout le système écrit par la même équipe et avec les mêmes conventions fait que écrire une application est beaucoup plus confortable - pas besoin de jongler entre différentes bibliothèques pour arriver à faire des choses.
Cela dit, il est vrai que cela marche surtout parce que c'est intéressant et enrichissant pour les développeurs. Il y avait d'autres projets plus pragmatiques autour de BeOS, allant de la "simple" distribution Linux avec un maquillage de l'interface graphique (ZevenOS) à un système entièrement nouveau mais pas forcément compatible (AtheOS puis Syllable), en passant par un système compatible au niveau du code source, mais sur une base de noyau Linux (BlueEyedOS) ou BSD (Cosmoe). Mais ils sont tous morts. Et pour les projets qui ne font que environnement de bureau, y'en a déjà plein :)
Je connait les mantecados, à base de graisse de porc. Mais j'avoue ne pas avoir de recette de gâteau avec de la graisse de thon. Faudra demander au capitaine Némo, peut être?
La date a été choisie parce que, d'une part c'était la journée de la Terre, et d'autre part, c'est surtout un évènement américain à la base (https://satellites.marchforscience.com/). Donc, les élections en France, bon, c'était pas si important que ça pour choisir une date.
C'est quoi le problème avec les drapeaux de la CGT? Ils ont pas le droit d'être là et de soutenir les scientifiques?
Pour la limite du 31/12, il y a eu (chez moi en tout cas) des possibilités de s'inscrire même après cette date. Cette date limite est là surtout pour éviter d'avoir plusieurs milliers d'inscriptions quelques jours avant l'élection, ce qui complique la vérification des listes électorales en particulier pour être sûr qu'une personne ne se trouve pas inscrite dans plusieurs bureaux de vote.
On met "xn--" au début de la chaîne (ce qui permet de reconnaître que c'est du punycode et évite les conflits avec les domaines existants),
On prend tous les caractères ASCII et on les laisse juste après le --,
On rajoute un - pour séparer de la suite,
Enfin, on prend les caractères non-ASCII (avec des accents, cyrilliques, etc) et pour chacun on insère dans la chaîne des caractères qui encodent, d'une part, le numéro unicode du caractère, et d'autre part, la position dans la chaîne initiale où il faut les insérer.
Par exemple, аpple.com (avec un a en cyrillique), devient xn--pple-43d.com.
On voit le xn--, le "pple" (аpple sans le а), le -, et le 43d qui dit "il faut insérer un а en position 0".
L'exemple de la Suisse n'est pas terrible d'ailleurs, parce qu'à ma connaissance, les taux de participation pour les votations locales sont inférieurs à 30%
Est-ce que c'est un problème?
C'est le droit des citoyens de ne pas avoir d'avis sur une question et pas spécialement envie de se renseigner, non?
"Les binaires ne peuvent pas être libre, ce sont uniquement les codes sources qui peuvent l'être."
Pourquoi pas du copyleft sur le matériel? Une licence où celui que te vend ou donne le matériel s'engage à te fournir les plans et documentations? Est-ce qu'il ne faudrait pas aussi tenir compte du fait que le matériel produit doit être démontable (sans tout casser) pour pouvoir le modifier?
L'ingénierie inverse, c'est le fait d'aller à contre courant du cycle de développement normal: partir d'un binaire pour écrire le code source correspondant, mais aussi partir du code source pour écrire la spécification qui va avec.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
Et donc?
Pour un projet mature il me semble normal qu'il y aie peu d'activité: il n'y a plus rien à faire, plus de bugs à corriger, pas de nouvelles fonctionalités à ajouter.
On peut pas à la fois se plaindre que KDE 5 est tout le temps tout cassé et pas stable, et que Trinity n'évolue pas assez.
[^] # Re: KDE presque un 10 sur 10 comme DE.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 2.
Pour ça il y a Trinity, qui continue de faire évoluer KDE3: https://www.trinitydesktop.org
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
Haiku a besoin du jeu d'instruction MMX qui est apparu… après le i586 (avec le Pentium Pro). Donc si ça marche, ton CPU est compatible i586.
[^] # Re: Le troll n'est pas sorti ?!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 3.
Contribuer ce n'est pas forcément écrire du code. Les rapports de bugs, ou même écrire une documentation "par où commencer" lorsqu'il n'y en a pas, ça peut être une bonne façon de commencer à aider un projet.
Par contre, c'est vrai que tous les gens qui contribuent au libre, et toutes les communautés, ne sont pas forcément accueillantes. Mais là, c'est tant pis pour eux, tu peux les laisser se débrouiller tout seuls :)
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 9.
On fait ce qu'on peut.
D'abord, attention pour le multi-utilisateur, il y a bien une prise en charge des utilisateurs au sens UNIX, même si elle est imparfaite. Cependant, c'est avant tout un mécanisme de sécurité, et il est possible qu'on ne l'utilise pas (ou en tout cas, pas directement) pour faire un système multi-utilisateur. Il y a encore eu peu de travail de ce côté, mais l'idée est que la gestion des permissions et le fait d'avoir plusieurs utilisateurs sont des choses différentes et qui ne doivent pas être liées aussi fortement qu'elles le sont sous Linux.
Qiand on dit que Haiku ne gère pas plusieurs utilisateurs, c'est dans le sens où on ne peut avoir qu'une seule session graphique pour le moment. ça n'empêche pas de créer des utilisateurs différents qui pourront se connecter en ssh, par exemple (et qui ne pourront pas lancer d'applications utilisant le serveur graphiques ou certains autres services).
Sur la compatibilité avec BeOS: il existe déjà une version 64-bit de Haiku, qui n'est pas compatible avec BeOS. Elle sera officiellement supportée et diffusée dès la release beta1 (bientôt, enfin j'espère). La version R1 de Haiku sera la dernière compatible avec BeOS, ensuite on travaillera sur la version R2, qui elle, sera compatible avec la version R1 et introduira en parallèle de nouvelles APIs. Et ainsi de suite. Il est essentiel que chaque version soit compatible au moins avec la précédente, car cela permet aux développeurs d'application de pouvoir migrer d'une version majeure de l'API à la suivante dans un délai assez long. Le but de la compatibilité avec BeOS, plus que le fait de continuer à faire fonctionner les applications, est, d'une part de pouvoir comparer notre comportement avec celui de BeOS (parfois, on se demande pourquoi une application plante, et on se rend compte qu'elle ne fonctionnait pas non plus sous BeOS et donc que Haiku n'y est pour rien), et d'autre part, de faire nos armes sur la façon de gérer les problèmes de compatibilité et la façon de concevoir nos APIs et nos ABIs pour pouvoir assurer une certaine évolutivité tout en restant compatibles.
Pour l'idée de transporter certaines choses sur un noyau Linux, c'est possible, mais pas pour tout. Une raison pour cela est justement liée à des problématiques de sécurité. Par exemple, l'API de BeOS permet de référencer un fichier directement par son numéro d'inode. Ce qui est pratique dans certains cas (pour communiquer efficacement l'emplacement d'un fichier d'une application vers une autre), mais impossible sous Linux car cela permettrait de contourner les droits sur les fichiers. Du coup, cette API ne peut pas être reproduite telle quelle. Il existe, ou plutôt il a existé, au moins deux projets avec ce but: BlueEyedOS et Cosmoe. Personellement je serais plutôt content de les voir vivre, en plus de Haiku, de la même façon qu'il y a plein d'implémentations de UNIX ou POSIX aujourd'hui.
Ensuite pour l'aspect novateur: les idées ne manquent pas, mais les moyens pour les réaliser, un peu plus. Mais on a déjà accompli pas mal de choses. Il y a le gestionnaire de paquets, et il y a aussi des travaux de recherche de l'université d'Aukland, avec par exemple la possibilité de faire du tiling et des tabs dans le gestionnaire de fenêtres, ou encore un système de gestion du layout des interfaces graphiques utilisant un solveur de contraintes linéaires (en principe, il doit pouvoir faire le layout de la fenêtre "tout seul" en fonction des contraintes indiquées par le programmeur). Et il y a toutes sortes de choses dans les cartons et que l'on verra peut être fonctionner un jour.
En ce qui concerne la gestion de la RAM (commentaire en-dessous, je réponds à tout le monde en même temps): sous Haiku, s'il n'y a pas assez de mémoire disponible, une application qui fait une allocation se voit retourner un pointeur NULL, ce qui lui permet de gérer l'erreur proprement. Malhereusement, beaucoup d'applications supposent un comportement proche de celui de Linux et ne prennent pas la peine de vérifier.
Haiku étant écrit en C++ et avec de gros efforts faits sur la lisibilité du code, plutôt que sur la performance, je pense qu'il y a du potentiel pour obtenir du code sécurisé à terme. Mais ça ne marche que si les gens prennent le temps d'inspecter et de remonter les erreurs trouvées. Haiku utilise Coverity (un outil d'analyse statique du code qui détecte de nombreux cas de failles potentielles), et la plupart des erreurs trouvées sont dans du code tiers (la bibliothèque de résolution DNS importée de NetBSD, ou la librairie de résolution des dépendances du gestionnaire de paquets empruntée à SUSE, par exemple). Maintenant, je ne m'avancerai pas plus loin vu qu'il n'y a pas vraiment eu de tests ou d'investigations menées de ce côté.
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
La beta n'est pas encore disponible, mais sur http://download.haiku-os.org tu peux trouver des "nightly builds" qui s'en rapprochent et que je recommande d'utiliser. En particulier, le gestionnaire de paquets est disponible ce qui simplifie pas mal de choses.
Il n'y a plus tellement de travail à faire sur le code, les nightlies sont plutôt stable (même si ce n'est jamais parfait). Le gros du travail sur la beta est plutôt sur la mise en place de l'infrastructure pour construire et distribuer les paquets, chose qu'on a pas trop l'habitude de faire pour le moment.
[^] # Re: Est ce utilisable tout les jours?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Le mieux, c'est d'essayer!
Haiku a besoin de 192Mo de RAM et d'un processeur avec support du MMX (soit à peu près n'importe quoi fabriqué après 1995). Pour utiliser le navigateur web, il y a besoin de SSE (soit à peu près n'importe quoi fabriqué après 1999).
Bien sûr, il fonctionne mieux sur des machines plus puissantes, et si c'est possible, tu peux prendre la version 64-bit qui utilise un compilateur plus récent et est donc mieux optimisée.
On ne peut pas encore tout faire (le navigateur web est encore un peu en chantier et il n'y a pas encore de suite office - mais on y travaille).
Il est facile de tester en live USB pour voir ce que ça donne avant de se lancer pour une installation permanente.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 7.
Un peu tout ça.
En ce qui me concerne, j'ai appris beaucoup en contribuant à Haiku. J'ai commencé en tant qu'étudiant lors du Google Summer of Code. Je ne pense pas pouvoir parler de nostalgie, puisque je n'ai découvert BeOS que vers 2006 ou 2007 (c'était déjà mort depuis 5 ans) et que j'ai continué avec Haiku dès que cela a été possible (en gros vers 2009 avec la sortie de la première version alpha).
Mais même maintenant, mes machines sous Linux ou Windows sont loin d'avoir la fluidité de Haiku. Tout me semble insupportablement lent et pas pratique. Je suis bien content de pouvoir utiliser Haiku chez moi et pour faire de plus en plus de choses.
On connaît tous la blague de "l'année de Linux sur le Desktop". Pourtant, ça n'arrive toujours pas. Et peut-être, qui sait, ça marcherait mieux sans Linux? Mais bon, je ne me prends pas trop au sérieux là-dessus. J'ai eu la chance de pouvoir travailler un an à plein temps sur Haiku grâce aux dons de la communauté d'utilisateurs, et ça, c'est déjà super.
Il y a aussi le fait que la communauté des développeurs autour de Haiku est plutôt ouverte et accueillante aux nouveaux contributeurs. Comme je l'ai mentionné dans la dépêche, c'est un des 3 projets à avoir survécu à 7 ans de Google Code-In, et il y a d'autres exemples d'utilisateurs qui sont parti de rien et qui ont fini par apprendre le C++ et développer leurs propres applications.
Enfin, il y a bien des utilisateurs sérieux qui vendent des systèmes fonctionnant sous Haiku. Il y a au moins TuneTracker Systems (http://tunetrackersystems.com) et il est question de projets en cours chez iZ Corp (http://www.izcorp.com), qui sont probablement les derniers utilisateurs de BeOS.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 9.
Ce n'est pas monolithique. L'architecture du système est modulaire et on peut remplacer des composants. Cependant, il semble préférable d'avoir une seule équipe en charge de tout le système pour apporter de la cohérence.
On peut également réutiliser des morceaux de code venu d'ailleurs. Le shell est bash, le serveur graphique utilise AGG et Freetype, l'internationalisation est assurée par ICU, les drivers réseau viennent de FreeBSD, le décodage média est fait par ffmpeg et il y a plein d'autres exemples. Cependant, ceci est invisible des applications qui n'ont affaire qu'à l'API de Haiku. Donc, on peut à tout moment décider de remplacer une de ces bibliothèques par autre chose (soit une autre implémentation, soit simplement une version plus récente). Le tout sans le moindre changement dans les applications. Ainsi des applications écrites pour BeOS peuvent se lancer sur Haiku et décoder des fichiers vidéo dans des formats modernes qui n'existaient même pas quand elles ont été écrites, par exemple.
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 4.
Le portage ARM de Haiku est malhereusement laissé de côté par manque d'intérêt ou de temps. De plus, on a choisi de laisser le Pi de côté en raison de son CPU ARMv6 (alors que tout le monde fait au moins de l'ARMv7). Il y a eu pas mal de travail sur le support de la Beagleboard xM, qui a l'avantage d'utiliser un CPU plutôt bien documenté. Et dernièrement, un peu de travail sur le Raspberry Pi 3, mais on a pas encore de driver fonctionnel pour le framebuffer, du coup le système plante au démarrage en essayant d'afficher le splash screen (et il manque plein d'autres trucs derrière avant d'espérer arriver sur le bureau de Haiku).
Mais on accepte toutes les contributions pour de nouveaux portages (ARM ou autres). Et il y a plein de gens prêt à partager leurs connaissances pour aider à faire avancer les choses, même s'ils n'ont pas forcément le temps d'écrire le code eux-même.
[^] # Re: shell
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
J'ai pas dit que c'était une bonne raison :D
Le projet Haiku a été créé dans ce but: fournir une continuité à BeOS. La première étape, c'est de remplacer BeOS par un système entièrement libre. Comme c'est mentionné dans la dépêche, on essaie quand même de rester pertinents avec des choses comme le passage au 64-bit, qui de toutes façons casse la compatibilité. À partir de la version R2 de Haiku, on ne sera donc plus compatibles et on pourra se poser plein de questions sur le shell par défaut, les APIs, et tout plein d'autres trucs.
Mais pour le moment, on essaie de rester concentrés sur ce premier objectif.
Pour les applications BeOS encore utilisées, il y a au moins GoBe Productive (une suite bureautique, pour laquelle d'une part il n'y a pas vraiment de remplacement, et d'autre part, il faudrait pouvoir convertir les fichiers dans un format lisible par d'autres outils), et SynC Modular (un synthétiseur musical modulaire). Pour ces deux là, on a pas réussi à avoir accès au code source pour les mettre à jour pour une version 64-bits. Il y a sûrement plein d'autres logiciels pour BeOS qui fonctionnent avec Haiku et qui sont encore utiles.
La migration vers des applications plus à jour se fait petit à petit. Ce qui nous permettra par la suite de passer à un système entièrement 64bit et sans les contraintes de BeOS. Mais c'est pas quelque chose qu'on peut faire du jour au lendemain.
[^] # Re: Corrections
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Je me rends compte que je n'ai pas pensé à mettre un lien vers le site de Haiku au début de la dépêche:
www.haiku-os.org - site officiel
download.haiku-os.org - page de téléchargement
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 3.
En ce qui me concerne, j'utilise Haiku autant que possible pour tout ce que je fais. Il me manque encore une suite office correcte, le support de l'impression qui marche complètement, et un client dropbox. Pour le reste j'arrive à m'en sortir.
Après il y a plein de besoins spécifiques (par exemple si je veux faire des schémas électroniques, j'aurais bien besoin de Kicad ou un outil du même genre).
Mais finalement, les trucs qui me manquent sont plutôt des applications. Donc je suppose que le système lui-même est prêt?
Après il y aura toujours des gens pour râler sur l'absence de drivers pour les webcams, les problèmes de compatibilité du navigateur web, ou l'absence de support de l'USB3, par exemple. C'est de ce côté là qu'on a le plus de travail, finalement: fournir des pilotes de périphériques pour du matériel qui continue d'évoluer tout le temps. Heureusement, on peut s'inspirer du travail de FreeBSD ou de Fuchsia/Magenta pour les drivers, et même parfois leur emprunter des morceaux de code (on n'utilise pas celui de Linux, car il est sous GPL - trop restrictive pour nous, on préfère la licence MIT - et aussi car en général le code est peu lisible, peut être par manque d'habitude).
[^] # Re: shell
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 6.
Y'a une raison: c'est le shell de BeOS, et Haiku est compatible avec BeOS.
Mais ça n'empêche pas d'installer zsh, bien sûr.
[^] # Re: divers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 7.
Pour le terminal, on est parti de code existant, à l'époque c'était un terminal pour BeOS avec la prise en charge des caractères Japonais (qui font 2 fois la largeur des caractères latins, même avec une police monospace).
Mais en effet, il y a dans les cartons un projet de remplacer une partie du code du terminal par libvterm. Mais pour cela il faudrait que les performances soient acceptables, et avec le portage actuel de libvterm, ce n'est pas le cas.
Pour la gestion des fichiers modifiables, c'est prévu, certains dossiers sont accessible en écriture (la hiérarchie n'est pas la même que sous Linux, donc pas de /var et de /etc, mais l'idée est la même). Les paquets peuvent copier des fichiers dans ces dossiers lors de leur installation, avec une gestion des fichiers existants (soit remplacés, soit conservés, selon la décision du paquet).
Pour la décision de refaire les composants, je peux prendre l'exemple récent du gestionnaire de paquets. Avant de se lancer, on a fait une revue de tout ce qui existait, en essayant de prendre en compte les demandes de nos utilisateurs. La conclusion était que rien ne nous convenait. On a donc choisi de développer notre propre système. Cependant, on utilise libsolv, qui gère très bien la résolution des dépendances entre paquets et qui provient de SUSE.
L'un des objectifs de Haiku est de fournir un système cohérent et fortement intégré. Cela veut dire qu'on peut modifier le noyau ou le bootloader pour faire fonctionner notre système de paquets. Qu'on peut modifier le serveur graphique pour y ajouter les primitives nécessaires pour accélérer le rendu des pages par notre navigateur web. Ce genre de chose prend des années à coordonner dans un écosystème de type GNU/Linux, avec un assemblage hétéroclyte de plein de projets. D'autre part, avoir tout le système écrit par la même équipe et avec les mêmes conventions fait que écrire une application est beaucoup plus confortable - pas besoin de jongler entre différentes bibliothèques pour arriver à faire des choses.
Cela dit, il est vrai que cela marche surtout parce que c'est intéressant et enrichissant pour les développeurs. Il y avait d'autres projets plus pragmatiques autour de BeOS, allant de la "simple" distribution Linux avec un maquillage de l'interface graphique (ZevenOS) à un système entièrement nouveau mais pas forcément compatible (AtheOS puis Syllable), en passant par un système compatible au niveau du code source, mais sur une base de noyau Linux (BlueEyedOS) ou BSD (Cosmoe). Mais ils sont tous morts. Et pour les projets qui ne font que environnement de bureau, y'en a déjà plein :)
[^] # Re: Oui mais non
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ADN overflow : c'est de la faute de l'open source. Évalué à 1.
Le language C a supprimé la fonction gets() dans sa version 2011, pour des raisons de sécurité. Donc oui, des failles dans un langage, ça existe.
[^] # Re: Étranger
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal On cherche mes remplaçants.... Évalué à 4.
Et du coup, est-ce que quelqu'un sait comment ça se passe en Grande-Bretagne?
[^] # Re: Calorie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Mon plat plat préféré. Évalué à 2.
Je connait les mantecados, à base de graisse de porc. Mais j'avoue ne pas avoir de recette de gâteau avec de la graisse de thon. Faudra demander au capitaine Némo, peut être?
[^] # Re: 5000 personnes à Paris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Marche pour les sciences samedi 22 avril 2017. Évalué à 5.
La date a été choisie parce que, d'une part c'était la journée de la Terre, et d'autre part, c'est surtout un évènement américain à la base (https://satellites.marchforscience.com/). Donc, les élections en France, bon, c'était pas si important que ça pour choisir une date.
C'est quoi le problème avec les drapeaux de la CGT? Ils ont pas le droit d'être là et de soutenir les scientifiques?
[^] # Re: Ah la manipulation (inconsciente?)...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et si les "erreurs purement matérielles" pouvaient influer sur le processus démocratique. Évalué à 3.
Pour la limite du 31/12, il y a eu (chez moi en tout cas) des possibilités de s'inscrire même après cette date. Cette date limite est là surtout pour éviter d'avoir plusieurs milliers d'inscriptions quelques jours avant l'élection, ce qui complique la vérification des listes électorales en particulier pour être sûr qu'une personne ne se trouve pas inscrite dans plusieurs bureaux de vote.
[^] # Re: N'oubliez pas dimanche
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Arrestation du développeur Debian Dmitry Bogatov. Évalué à 2.
On attendait qu'un autre pays en Europe fournisse le deuxième, peut-être?
[^] # Re: Commentaire ci-dessous
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Campagne d'hameçonnage, Firefox et Chrome vulnérables.. Évalué à 5.
Par exemple, аpple.com (avec un a en cyrillique), devient xn--pple-43d.com.
On voit le xn--, le "pple" (аpple sans le а), le -, et le 43d qui dit "il faut insérer un а en position 0".
[^] # Re: Machine a dépouillé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vote à l'urne et vote électronique. Évalué à 2.
Est-ce que c'est un problème?
C'est le droit des citoyens de ne pas avoir d'avis sur une question et pas spécialement envie de se renseigner, non?
[^] # Re: open schematics
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et si on achetait des serveurs Open Hardware ?. Évalué à 2.
"Les binaires ne peuvent pas être libre, ce sont uniquement les codes sources qui peuvent l'être."
Pourquoi pas du copyleft sur le matériel? Une licence où celui que te vend ou donne le matériel s'engage à te fournir les plans et documentations? Est-ce qu'il ne faudrait pas aussi tenir compte du fait que le matériel produit doit être démontable (sans tout casser) pour pouvoir le modifier?
[^] # Re: Protocole?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mastodon, le réseau social qui monte ?. Évalué à 4.
L'ingénierie inverse, c'est le fait d'aller à contre courant du cycle de développement normal: partir d'un binaire pour écrire le code source correspondant, mais aussi partir du code source pour écrire la spécification qui va avec.