Haiku a 16 ans

Posté par pulkomandy (site web personnel, Mastodon) le 19 août 2017 à 09:19. Édité par Benoît Sibaud, ZeroHeure, Francois Revol, Anonyme, fred2541, Davy Defaud, bubar🦥 et palm123. Modéré par bubar🦥. Licence CC By‑SA.

Étiquettes :

août

2017

Le 18 août 2001, le premier message sur la liste de diffusion d’OpenBeOS était envoyé par Marcus Overhagen (« OK, let’s start »). Seize ans plus tard, le projet est toujours là, même si les versions se font rares. Faisons donc un point annuel sur les derniers développements et ce qu’il se passe dans le projet.

Sommaire

Rappels sur le projet Haiku

Haiku est un système d’exploitation pour les ordinateurs de bureau (on ne vise ni les serveurs, ni les téléphones et tablettes, pour le moment). Il fonctionne sur les plates‐formes x86 (32 et 64 bits) et est compatible avec BeOS (au niveau binaire pour la version 32 bits, en recompilant les applications pour la version 64 bits).

L’objectif du projet est de continuer là ou BeOS s’est arrêté et de fournir un système d’exploitation facile à utiliser, réactif et efficace. Et, bien sûr, de permettre à tous les développeurs intéressés de se lancer dans un projet de grande envergure et de découvrir l’intérieur d’un système d’exploitation.

Haiku est écrit principalement en C++ et tous les composants (noyau, pilotes, applications, serveur graphique, etc.) sont réalisés par la même équipe, ce qui simplifie les possibilités d’intégration entre les différents composants. Il n’est pas encore complètement compatible POSIX, mais ça avance petit à petit.

En route pour la bêta

La feuille de route de Haiku

Lors de la création du projet, l’objectif pour la version 1 de Haiku était simple : « fournir un système 100 % compatible avec BeOS R5 (la dernière version officielle publiée) et qui remplace complètement ce dernier ».

Des jalons ont été définis : la première version « alpha » ne serait publiée que lorsque le système serait suffisamment avancé et stable pour pouvoir se compiler lui‐même. La première version « bêta » ne serait publiée que lorsque toutes les API de BeOS R5 seraient implémentées (même s’il restait des bogues).

Après la première version alpha, les objectifs de la version 1 ont été réexaminés. En effet, cette version n’est arrivée qu’en 2009, et déjà à ce moment il était clair que BeOS était un système vieillissant et que le reproduire à l’identique ne serait pas suffisant. Une consultation parmi les développeurs de Haiku ainsi que parmi les utilisateurs a donc permis d’ajouter de nombreux points à la liste des fonctions nécessaires pour la version 1 (et donc pour la version bêta 1, qui doit comprendre les mêmes fonctionnalités).

Cette feuille de route élaborée dans l’enthousiasme de la sortie de la première version alpha était peut‐être un peu trop ambitieuse. Cependant, la plupart des fonctionnalités prévues (gestion du Wi‐Fi, par exemple) sont effectivement arrivées.

L’infrastructure de publication des paquets

C’est le gros point bloquant pour la prochaine publication.

L’un des derniers points restant était qu’« il doit être possible de mettre à jour le système sans tout réinstaller ». Après de longues discussions entre les développeurs et avec la communauté, la solution retenue fut de réaliser un gestionnaire de paquets, qui pourrait mettre le système à jour. Ce dernier présente quelques propriétés intéressantes. En particulier, les paquets ne sont pas extraits comme pour la plupart des systèmes existants, mais montés dans un système de fichiers virtuel. Ceci permet une installation et une désinstallation très rapide et sans utiliser d’outils spécifiques (il suffit de copier le paquet dans le dossier /system/packages prévu à cet effet).

Cependant, le gestionnaire de paquets est inutile si personne n’est capable de publier un dépôt de paquets et de le tenir à jour. Le projet Haiku espérait que ce serait fait par d’autres. En particulier, HaikuWare (le site sur lequel on trouvait la plupart des logiciels pour Haiku) et HaikuPorts (l’outil permettant de compiler des logiciels à partir des sources pour Haiku) auraient pu répondre à cette demande. Cependant, le responsable de HaikuWare n’a pas du tout aimé le système de gestion de paquets (jugé trop complexe pour les développeurs) et a finalement décidé de fermer son site et de cesser tout soutien à Haiku. Quant à HaikuPorts, l’outil a été mis à jour pour générer des paquets plutôt que d’installer les fichiers directement sur le système. Cependant, ce travail a été réalisé par les développeurs de Haiku et cette « intrusion » dans le développement de l’outil a fini par causer le départ du principal mainteneur de HaikuPorts. Les développeurs de Haiku se retrouvent donc seuls en charge de tout l’écosystème de logiciels.

En dehors de ces soucis d’infrastructure, il y a également du travail pour les outils graphiques permettant de gérer les dépôts et les logiciels installés. Dans Haiku, il y a plusieurs logiciels prévus à cet effet :

HaikuDepot, qui est un magasin d’applications un peu comme ceux que l’on trouve sur les smartphones ou Synaptic sur Debian. Il permet d’explorer la liste des logiciels avec captures d’écran et description, ainsi que les notes et commentaires d’autres utilisateurs. En plus du dépôt de paquets, il repose sur un service Web indépendant qui se charge uniquement des métadonnées (commentaires, notes, icônes, captures d’écran) qui ne sont pas présentes dans le paquet logiciel lui‐même ;
Repositories, l’application de préférences qui permet de choisir les dépôts de logiciels que l’on veut utiliser ; en plus des dépôts officiels fournis par Haiku et HaikuPorts, il existe à présent plusieurs dépôts complémentaires permettant la distribution de nombreux logiciels ;
enfin, SoftwareUpdater se charge de surveiller et de notifier la disponibilité de mises à jour pour le système et pour les applications ;
et bien sûr pkgman, l’outil en ligne de commande équivalent d’apt ou yum, est toujours présent et permet de faire tout ça sans cliquer.

Prise en charge du 64 bits et passage à GCC 6

La dernière version alpha 4 de Haiku n’était disponible que pour les machines 32 bits. À l’époque, la prise en charge du 64 bits était encore considérée comme expérimentale et nous avions choisi de ne pas la publier dans une version officielle tout de suite.

Cela va changer avec la version bêta 1, qui sera donc disponible en 32 et 64 bits. Il y a eu récemment des changements sur l’ABI 64 bits (par exemple, time_t est passé de 32 à 64 bits pour prévenir le bogue de l’an 2038).

La version 32 bits de Haiku utilise GCC en versions 2.95.3 (pour la compatibilité avec BeOS) et 5.4. La version 64 bits utilise uniquement GCC 5.4. Le passage à GCC 6 est en cours, mais comme souvent, cette nouvelle version de GCC apporte de nouvelles optimisations et de nouvelles alertes (warnings), qui révèlent des problèmes dans le code de Haiku. Il faut donc être prudent et prendre le temps d’investiguer chacun de ces problèmes avant de pouvoir officiellement mettre à jour la version de GCC prise en charge.

HaikuArchives

http://haikuarchives.github.io/

L’un des problèmes de Haiku est le manque de logiciels disponibles. En principe, la compatibilité avec BeOS devrait permettre de réutiliser tous les logiciels écrits pour BeOS, mais ceux‐ci ne sont plus maintenus. De plus, suite à la fermeture de HaikuWare et de BeBits (les deux principaux sites répertoriant ces logiciels), il était à craindre qu’ils soient perdus pour toujours.

Le projet HaikuArchives répond à ce problème. Le but de ce projet est de retrouver les auteurs de logiciels pour BeOS et de les convaincre de retrouver leurs sources (c’est le plus difficile) pour les publier (en général, ça ne pose pas trop de problèmes), de préférence sous une licence libre.

Ceci permet d’effectuer au moins une maintenance minimale sur le code, en attendant que les projets soient repris par d’autres développeurs. Cela permet de suivre les petits changements dans l’API, de vérifier que les logiciels compilent toujours avec un compilateur récent et de préparer le passage au 64 bits.

Développements dans l’année

Le navigateur Web

Haiku utilise le moteur WebKit (partagé avec Safari et GNOME, entre autres). Le développement de ce moteur est très actif et il est difficile de suivre pour un projet qui n’a pas de développeurs affectés à plein temps pour cela.

Aussi, Haiku utilise actuellement une version de WebKit datant de début 2016 et commence à rencontrer des problèmes pour cette raison sur certains sites Web. Il est donc nécessaire de mettre à jour notre portage de WebKit et des efforts dans ce sens sont en cours.

D’autre part, la prise en charge des protocoles HTTP, HTTPS et Gopher mûrit doucement, avec encore de nombreux bogues corrigés.

Déboguer à distance

« Debugger » est, comme son nom l’indique, le débogueur fourni avec Haiku. C’est un outil indispensable pour les développeurs.

Cependant, il s’agit d’une application graphique et assez complexe, ce qui peut se révéler problématique lorsqu’il s’agit d’investiguer des problèmes dans les composants de Haiku comme le serveur graphique app_server.

La solution choisie est de permettre d’utiliser Debugger à distance, depuis une autre machine. Le code du débogueur est donc adapté petit à petit pour permettre ce fonctionnement à travers le réseau.

Flux médias

Haiku propose une implémentation du « Media Kit » de BeOS, qui permet entre autres choses le décodage, la lecture et l’encodage de sons et de vidéos.

Jusqu’à présent, ce décodage pouvait se faire uniquement à partir d’un fichier ou de données chargées en mémoire. Mais il est maintenant possible de l’utiliser avec des flux, ce qui rend par exemple possible la lecture de webradios avec MediaPlayer.

Prise en charge de l’impression

Pouvoir imprimer des documents est indispensable sur un système de bureau comme Haiku. Bien que la gestion des imprimantes soit présente, il reste encore de nombreux problèmes à traiter avant que cela soit complètement fonctionnel.

Les pilotes d’imprimantes utilisés sont ceux de Gutenprint, qui permet d’assurer la compatibilité avec un assez grand nombre de marques et de modèles. C’est maintenant la dernière version de Gutenprint qui est utilisée pour cela.

La version 64 bits de Haiku est capable d’imprimer aussi bien que la version 32 bits.

Un gros nettoyage a été effectué sur les diverses fenêtres de configuration de l’imprimante et de mise en page (gestion des marges, etc.), pour les simplifier et les uniformiser entre différentes applications.

La prochaine étape est de régler tous les problèmes de rendu lors de l’impression d’un document : texte mal positionné, dégradés de couleurs qui disparaissent, par exemple.

Le « launch daemon »

launch_daemon est un serveur qui se charge de séquencer le démarrage et l’extinction de la machine (des opérations courantes sur une machine de bureau — surtout que Haiku ne sait pas encore se mettre en veille).

Il remplace la procédure d’inititalisation qui était auparavant implémentée sous forme d’un simple script shell.

Launch daemon peut lancer plusieurs services en parallèle, en réagissant à des évènements (par exemple, « tous les disques sont montés »). Il permet également de redémarrer un service automatiquement en cas de plantage et même de mettre en attente les messages envoyés à un service qui n’est pas démarré.

Ceci permet par exemple de ne démarrer le serveur d’impression que lorsqu’on imprime un document pour la première fois, limitant ainsi le temps de démarrage du système et l’utilisation de la mémoire vive.

Systèmes de fichiers

Plusieurs corrections ont été effectuées dans la gestion des systèmes de fichiers.

BFS, le système de fichiers principal de Haiku, avait encore quelques différences avec celui de BeOS, qui sont maintenant corrigées afin d’assurer une complète interopérabilité entre les deux systèmes.

Divers petits problèmes ont été également corrigés dans le VFS (le code commun à tous les systèmes de fichiers), ainsi que dans rootfs (qui gère le système de fichiers racine monté en /), devfs (qui gère /dev et les fichiers représentants les périphériques) et packagefs (qui gère le montage des paquets logiciels dans un système de fichiers virtuel). Ces corrections permettent d’avoir un meilleur comportement dans des cas inhabituels, par exemple lors d’une tentative d’ouverture en écriture d’un dossier.

Enfin, du côté des systèmes de fichiers réseau, Haiku peut maintenant se connecter à des partages SMB (en plus du NFS qui était déjà présent), permettant d’échanger facilement des fichiers avec d’autres machines présentes sur le réseau.

Il est également possible d’utiliser un disque en mémoire vive (RAM disk) pour y stocker des données non persistantes qui n’ont pas besoin d’être sur un disque dur.

Des pilotes

La prise en charge matérielle est évidemment un problème pour un projet comme Haiku qui a fait le choix de ne pas utiliser un système existant. Cette année, les efforts ont porté principalement sur :

la prise en charge de xHCI (USB 3), qui devient indispensable sur les machines récentes où l’USB2 est en voie de disparition ;
la mise à jour du pilote intel_extreme, qui pilote toutes les cartes graphiques Intel à partir de la GMA 950 ;
la prise en charge de l’UEFI, pour démarrer sur les machines qui n’ont pas de BIOS ; ainsi que la prise en charge complète des tables de partitionnement GPT qui y sont souvent associées ;
la prise en charge des cartes réseau virtuelles virtio, permettant de lancer Haiku dans certaines machines virtuelles (Hyper-V, par exemple) ;
le pilote atheros813x est à jour avec la version de FreeBSD 11. Tous les autres pilotes réseau importés de FreeBSD sont pour l’instant à jour avec la version 9 uniquement.

Prise en charge de l’internationalisation

Depuis le début du projet, Haiku utilisait la police de caractères DejaVu Sans pour son interface graphique. Cependant, celle‐ci ne permettait pas la gestion de toutes les langues.

Désormais, c’est la police de caractères Noto qui est installée par défaut, ce qui permet la prise en charge, entre autres, du japonais et du coréen, en plus des langues latines et cyrilliques.

D’autre part, la méthode de saisie Canna, qui permet de taper du texte en japonais, est maintenant complètement fonctionnelle ; et KeymapSwitcher, qui permet de changer de disposition de clavier par une combinaison de touche, est disponible dans les dépôts de logiciels et sera probablement inclus directement dans la version bêta 1.

Terminal

On pourrait penser que ce n’est pas l’application la plus importante, mais les développeurs passent beaucoup de temps en face d’un shell Bash.

Le terminal de Haiku peut enfin avoir plus de six onglets ouverts dans une même fenêtre.

Plusieurs problèmes apparus avec ncurses 5.9 ont été résolus par l’implémentation de séquences d’échappement manquantes. En particulier, il est possible d’utiliser Nano avec le curseur affiché au bon endroit et tous les caractères visibles.

Des projets autour du système d’exploitation

Avoir un système, c’est bien. Mais avoir des applications, c’est mieux.

Portage de Qt 5

Grâce aux efforts mis en place pour la gestion des paquets, il est devenu possible de capitaliser les efforts de portage de logiciels et de maintenir en état de marche un grand nombre de bibliothèques portées.

Cela a rendu possible la reprise du développement de Qt 4, puis de Qt 5 pour Haiku, ce qui permet de bénéficier de nombreuses applications.

Bien que l’objectif final de Haiku soit de développer son propre écosystème d’applications, bien intégrées avec le reste du système, les applications Qt permettent d’avoir dès maintenant un système de bureau opérationnel avec des applications fonctionnelles.

Le portage de Qt se complète petit à petit, avec par exemple la gestion du glisser‐déposer et une apparence qui se rapproche autant que possible de celle des applications natives.

L’une des applications Qt souvent utilisées est Qupzilla, un navigateur Web qui permet de visiter certains sites qui ne fonctionnent pas bien avec le navigateur natif.

LibreOffice

Un gros manque sur Haiku est l’absence d’une suite bureautique digne de ce nom. Il existe quelques vieilles applications pour BeOS, en particulier la suite GoBe productive et le tableur Sum-It, mais ils sont loin d’être suffisants et les sources de GoBe productive ne sont pas disponibles pour la maintenir à jour.

En conséquence, la solution retenue est d’essayer de porter LibreOffice. C’est un gros travail, mais les premières captures d’écran semblent prometteuses.

Présence dans les manifestations autour du logiciel libre

Le projet Haiku reste assez peu connu. La présence dans différentes manifestations autour du logiciel libre nous permet de nous faire connaître et d’essayer d’attirer de nouveaux développeurs.

C’est aussi l’occasion d’aider certains projets à porter leurs applications sur Haiku lorsque cela est possible et pertinent.

FOSDEM

Cette année nous avons partagé un stand avec ReactOS, un projet aux objectifs similaires puisqu’il s’agit d’un système d’exploitation libre compatible avec Windows.

https://www.haiku-os.org/blog/mmu_man/2017-02-09_back_from_fosdem/

mmu_man a donné une conférence sur les idées que les autres bureaux devraient emprunter à Haiku.

RMLL

Haiku était également présent aux Rendez‐vous mondiaux du logiciel libre, avec un stand et une conférence faisant un point sur les progrès vers la prochaine version bêta de Haiku :

Ce fut également l’occasion de porter QElectrotech vers Haiku et d’essayer de mettre à jour le portage de Pytouhou pour une version un peu plus récente.

Capitole du Libre

Haiku était aussi présent au Capitole du Libre, avec un stand, et deux conférences :

La fin de BeGeistert

http://begeistert.org/

BeGeistert était depuis 1998 une conférence autour de BeOS, puis de Haiku. Organisée habituellement à Düsseldorf, elle permettait à la communauté de Haiku de se retrouver une fois par an, avec quelques présentations et un coding sprint consistant à enfermer plusieurs développeurs dans une pièce, à secouer, et à voir ce qui en ressort.

Avec un nombre de participants de plus en plus faible et des coûts de plus en plus élevés pour la location de la salle utilisée, l’association HSA (Haiku Support Association) organisatrice de l’évènement a décidé qu’il n’était plus pertinent de maintenir BeGeistert dans ce format.

Il n’y aura donc pas de BeGeistert en 2017, mais il y aura tout de même un coding sprint, organisé à Toulouse juste après le Capitole du Libre.

http://pulkomandy.tk/kdc

Participation au Google Code‐in

https://codein.withgoogle.com/archive/2016/organization/5146925732986880/

Le Google Code-In est un programme du bureau de l’open source de Google. Il s’adresse au 13 à 17 ans. Le but étant de leur faire découvrir le logiciel libre et l’informatique en général.

Cela se présente sous la forme d’un concours où les participants doivent réaliser des contributions à l’un des projets de logiciels libres participants. Les tâches à réaliser peuvent être par exemple la réalisation d’une icône, d’un prospectus, d’un fond d’écran, l’écriture de documentation, faire une présentation du projet ou, bien sûr, écrire un peu de code pour corriger un bogue.

Haiku est l’un des trois projets qui ont participé tous les ans depuis le lancement du Code‐in en 2010 (les deux autres étant KDE et Apertium). En effet, la participation à ce programme demande un gros investissement de la communauté pour accueillir efficacement des participants qui n’ont pas forcément l’habitude du fonctionnement des logiciels libres.

Haiku a pu gagner quelques nouveaux contributeurs grâce à ce concours, mais les résultats sont surtout à long terme d’encourager la contribution aux logiciels libres en général.

De retour dans le Google Summer of Code

https://www.haiku-os.org/community/gsoc/2017/ideas

Haiku participe également régulièrement au Google Summer of Code. Celui‐ci se présente sous la forme d’un stage où des étudiants sont rémunérés par Google mais encadré par les contributeurs de différents projets de logiciels libres.

Le résultat en termes de contribution aux logiciels participants étant en principe beaucoup plus important que pour le Google Code-in, il y a beaucoup plus de projets intéressés pour participer, aussi il n’est pas possible pour tous les projets de participer tous les ans (il faut laisser de la place aux autres). Haiku n’avait donc pas participé aux éditions 2015 et 2016, mais est de retour en 2017 avec sept étudiants contribuant entre autres à l’amélioration de la pile TCP, le prise en charge de l’écriture sur le système de fichiers Btrfs, ou encore l’écriture d’une application agenda et un travail sur l’interface graphique des préférences du système.

Le Google Summer of Code se termine à la fin du mois d’août, donc les contributions des étudiants participants sont intégrées petit à petit d’ici là et seront probablement présentes dans la version bêta de Haiku.

Aller plus loin

OK, let’s start (440 clics)
Site officiel (549 clics)
Téléchargement (108 clics)

# divers

Posté par freem le 19 août 2017 à 14:52. Évalué à 5.

Avec ce systeme de paquets, du coup, comment fonctionne la config dans l'etc et les donnees du var?
Pourquoi n'avoir pas utilise un des nombreux systemes de paquets deja existants?

Pour le terminal, meme question: pourquoi ne pas reprendre de code existant, quitte a detourner l'ihm pour l'adapter a ce qui semble etre le vrai objectif: une ihm proche de beos?

Je pourrai dire idem pour l'init, mais on m'accuserai a raison de troller : D
De maniere generale, j'ai l'impression que le projet est tres ambitieux, et je me demande si chercher a refaire des composants plus systeme que end-user est vraiment pertinent…(du point de vue de l'objectif, pas du point de vue plaisir)
- [^] # Re: divers
  
  Posté par pulkomandy (site web personnel, Mastodon) le 19 août 2017 à 17:21. É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: divers
    
    Posté par Maclag le 19 août 2017 à 18:56. Évalué à 6.
    
    Si je comprends bien, l'avantage est surtout de n'avoir aucun besoin de "généricité".
    
    Mais reste qu'il faut sans doute énormément de ressources pour développer tout ça, même avec moins de contraintes.
    
    Linux est peut-être entravé par son écosystème foisonnant qui fait que tout doit marcher avec une palanquée de composants différents, mais les ressources cumulées sont énormes, et j'ai du mal à voir comment le projet Haiku pourrait prendre de l'ampleur sans arriver à cette dispersion qui oblige justement à revenir à une certaine généricité.
    
    Est-ce que l'équipe voit vraiment le bout du tunnel à l'horizon où Haiku pourrait être utilisable au quotidien par autre chose que les passionnés à forte compétences techniques, ou est-ce une course sans fin parce que les objectifs, si ambitieux soient-ils, finissent toujours par être insuffisants au vu de ce que doit proposer un OS moderne?
    - [^] # Re: divers
      
      Posté par pulkomandy (site web personnel, Mastodon) le 19 août 2017 à 19:37. É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: divers
        
        Posté par Le Gab le 19 août 2017 à 21:59. Évalué à 5.
        
        Je verrais bien Haiku comme OS de prédilection pour le RaspberryPi.
        Le hardware est quasi figé, il y a une forte communauté.
        
        Le plaisir de développer n'est pas incompatible avec la volonté de rendre Haiku utile aux autres.
        
        [^] # Re: divers
        
        Posté par pulkomandy (site web personnel, Mastodon) le 20 août 2017 à 11:41. É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: divers
        
        Posté par claudex le 22 août 2017 à 17:30. Évalué à 5.
        
        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).
        
        Ce n'est plus le cas depuis le 2. Mais du coup, ça contredit l'argument du "matériel figé". Genre le 2 a apporté de nouvelles instructions CPU, le 3 a apporté le wifi, le bluetooth.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Corrections

Posté par NumOpen le 19 août 2017 à 17:07. Évalué à 2.

suffisament avancé -> suffisamment avancé
découvrir l'intèrieur -> découvrir l'intérieur
les mêmes fonctionalités -> les mêmes fonctionnalités
- [^] # Re: Corrections
  
  Posté par Benoît Sibaud (site web personnel) le 19 août 2017 à 18:14. Évalué à 3.
  
  Corrigé, merci.
  - [^] # Re: Corrections
    
    Posté par pulkomandy (site web personnel, Mastodon) le 19 août 2017 à 19:55. É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
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 19 août 2017 à 20:05. Évalué à 0. Dernière modification le 19 août 2017 à 20:10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 19 août 2017 à 20:29. Évalué à 0. Dernière modification le 19 août 2017 à 20:31.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Corrections
      
      Posté par Benoît Sibaud (site web personnel) le 19 août 2017 à 22:57. Évalué à 3.
      
      Corrigé, merci.
# shell

Posté par MCMic (site web personnel) le 19 août 2017 à 18:13. Évalué à 2.

On pourrait penser que ce n'est pas l'application la plus importante, mais les développeurs passent beaucoup de temps en face d'un shell bash.

Redévelopper tout un tas de truc comme l’init, le gestionnaire de paquets, le serveur graphique, … pour finir devant un bash c’est un peu triste.
C’est vraiment bash le shell ? Ya une raison à ça ?

https://fishshell.com
https://zsh.org
- [^] # Re: shell
  
  Posté par pulkomandy (site web personnel, Mastodon) le 19 août 2017 à 19:30. É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: shell
    
    Posté par Le Gab le 19 août 2017 à 21:49. Évalué à 6. Dernière modification le 19 août 2017 à 21:50.
    
    et Haiku est compatible avec BeOS.
    
    Pour quelle utilisation? Quel est l'avantage d'être compatible BeOS si le dit OS est mort depuis 16ans ?
    Quelles sont les applications que vous utilisez qui datent de BeOS?
    
    Après, je n'ai rien contre BASH, c'est juste cet argument de compatibilité qui m'intrigue.
    - [^] # Re: shell
      
      Posté par pulkomandy (site web personnel, Mastodon) le 20 août 2017 à 11:36. É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.
# Réécrire l'histoire

Posté par ʭ ☯ le 20 août 2017 à 19:53. Évalué à 5.

C'est drôle tous ces projets qui essayent de réécrire l'histoire, et qui durent aussi longtemps. Jean-Louis Gassée a vu que l’écosystème n'était pas là très vite, mais quelques barbus font vivre le bébé bien des années plus tard…. ceci étant, le côté monolithique est un gros frein, quand on voit que les morceaux des couches de GNU/Linux sont utilisés sur mesure par Android, les routeurs, etc…

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: Réécrire l'histoire
  
  Posté par pulkomandy (site web personnel, Mastodon) le 21 août 2017 à 08:47. É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: Réécrire l'histoire
  
  Posté par steph1978 le 21 août 2017 à 16:14. Évalué à 5.
  
  Je partage cette impression. Je ne savais pas le dire poliment.
  Quand j'ai essayé BeOS sur disquette, il y a peut être vingt ans (pfiu le vieux), j'ai été bluffé.
  Par rapport à ce qui existait, c'était dément : beau, ergonomique, fluide, multitâche. Peut être comparable à QNX mais largement plus impressionnant que windows ou linux.
  Mais maintenant que le OS encore en force (windo, GNU/linux, *BSD, MacOS) ont largement dépassé ce niveau, à part la nostalgie, qu'est-ce qui motive les personnes travaillant sur un projet comme celui-ci ? Un hobbies ? La vertu éducative ? L'ambition de faire mieux que ce qui existe ?
  - [^] # Re: Réécrire l'histoire
    
    Posté par pulkomandy (site web personnel, Mastodon) le 21 août 2017 à 17:09. É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.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 21 août 2017 à 21:44. Évalué à 2.
      
      Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: Réécrire l'histoire
      
      Posté par Renault (site web personnel) le 22 août 2017 à 09:29. Évalué à 6.
      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.
      
      C'est difficile de comparer des OS qui sont assez différents. Linux peut tourner sur des petites machines, vraiment petites et des mainframes gigantesques en passant par toute une série de machines intermédiaires. Pour que cela soit efficient, cela impose du code en plus, des couches d'abstractions supplémentaires, plus de pilotes et d'autres mécanismes. Cela a un impact sur l'architecture et le fonctionnement du système.
      
      Sans compter que, je ne connais pas Haiku donc je vais peut être dire une bêtise, mais quid de la sécurité ? Le noyau Linux n'est pas exemplaire en la matière, mais a des tas et des tas de revues de code et d'autres personnes qui se penchent sur la question. Des mécanismes (lourds parfois) ont été introduits pour limiter les failles. La sécurité a très souvent un impact négatif sur les performances du système. Est-ce que Haiku a un suivi sécurité à la hauteur ? À l'heure où les machines sont connectées en permanence sur Internet, que certaines failles sont identifiable et exploitable très rapidement, est-ce que conseiller Haiku est une bonne idée ? C'est complexe.
      
      Il y a aussi le fait que la communauté des développeurs autour de Haiku est plutôt ouverte et accueillante aux nouveaux contributeurs.
      
      La communauté Linux n'est pas malfamée non plus. Même au sein du noyau, tu as des sous-systèmes gérés par des gens adorables et super sympas (Linus Torvalds n'est pas le seul interlocuteur). Et je ne parle pas de l'espace utilisateur qui est tellement diversifié que tu as des projets très accueillants ici (car Haiku semble être présenté comme un tout-en-un ici, entre le noyau et ses applications).
      
      Après chacun fait ce qu'il veut, mais je me pose quelques questions :
      
      Est-ce que la compatibilité avec BeOS est vraiment pertinente aujourd'hui ? Fournir le même système sans se préoccuper de cet aspect ne serait pas préférable ?
      
      Est-ce que l'intérêt de ce système ne pourrait pas être transposé dans l'univers Linux ou autres système libre ? Je veux dire, avec un framework graphique bien pensé, tu peux récupérer l'essentiel de l'intérêt de BeOS (même si je sais qu'il y en a d'autres).
      
      BeOS était très novateur à son époque, est-ce que Haiku souhaite (ou a) explorer d'autres concepts ? Plan 9 est par exemple intéressant sur cet aspect également.
      
      En tout cas, bon courage. ;-)
      - [^] # Re: Réécrire l'histoire
        
        Posté par oinkoink_daotter le 22 août 2017 à 17:07. Évalué à 3.
        
        mais quid de la sécurité ?
        
        La dernière fois que j'ai regardé (ça remonte à trèèèèèès longtemps), ça ne gérait pas le multi utilisateur. Une recherche rapide aujourd'hui a l'air de le confirmer.
        Il n'y a pas l'air d'y avoir non plus de partition root/user comme l'écrit pulkomandy< ici.
        
        Rajoute à ça un webkit "début 2016".
        
        A priori ce n'est pas fait pour faire de la sécu (ce qui n'est pas un reproche, je trouve la démarche absolument géniale)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 22 août 2017 à 17:55. Évalué à 1.
        
        D'un autre côté, un certain nombre de patchs sont là pour rattraper les erreurs des applications.
        On peut considérer que vu que Haiku vise le tout intégré, le problème se posera moins. Je pense notamment à la politique optimiste sur la quantité de ram encore disponible… qui rend au final impossible d'avoir une application réellement fiable (on ne sais jamais si oui ou non, la totalité de la mémoire demandée nous est vraiment allouée) tant que ce truc est activé. Et je crains qu'il ne soit activé sur la majorité des distribs.
        Je gage qu'il y a d'autres exemples, et peut-être que ce type de fonctionnalités n'a aucun intérêt sur Haiku? Peut-être est-ce aussi valable pour des patchs liés à la sécurité? Ou peut-être, et c'est très probable, que je dis de la merde ;)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 22 août 2017 à 19:06. É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: Réécrire l'histoire
      
      Posté par Kerro le 22 août 2017 à 19:44. Évalué à 4.
      
      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.
      
      Ma machine principale n'est pas spécialement récente (2011), pas rapide (AMD Athlon X2 215), et équipée d'un disque-dur ordinaire qui à 5 ans.
      Je ne constate AUCUNE lenteur, sauf dans les cas évidents où je demande à find+grep de me trouver ce satané fichier qui contient une information que je recherche.
      C'est du Linux, j'ai actuellement 6 Gio de mémoire occupée (cas courant) et l'occupation processeur est inférieure à 10 % quasi tout le temps.
      
      Idem pour Windows. Sur mon ordinateur portable de bricolage (Intel Celeron 1005M) avec un disque-dur poussif (récupération), je n'ai de lenteur que pour les accès aux fichiers. Le reste ça tourne du tonnerre.
      Je fais même de petits développements dessus (en bureau à distance depuis mon Linux) avec Microsoft Visual Studio qui n'est pas vraiment un poids plume.
      
      --> qu'est-ce qui te semble lent ? Surtout au point de t'être quasi-insupportable.
      - [^] # Re: Réécrire l'histoire
        
        Posté par Shunesburg69 le 23 août 2017 à 15:01. Évalué à 2.
        
        6 Gio de mémoire occupée
        
        6Go de RAM utilisé c'est énorme à moins que tu parles d'espace disque.
        Moi aussi j'ai du mal avec la lenteur sur Windows et les distribution Linux sous Gnome, KDE & Co.
        Par contre, sur Linux avec XFCE ou un MacOS pas ce genre de problème.
        Après c'est sûr qu si on a plus de 8Go de RAM et un SSD les lenteurs sont quasiment invisible sur tout les OS.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Kerro le 23 août 2017 à 17:45. Évalué à 0.
        
        6Go de RAM utilisé c'est énorme
        
        C'est pour ça que je précise, afin de faire comprendre que ma machine est relativement chargée.
        
        Par contre, sur Linux avec XFCE ou un MacOS pas ce genre de problème.
        
        Ah oui, je n'ai pas précisé : j'utilise XFCE.
        Avec KDE et Gnome j'ai laissé tomber : plus de 10 minutes pour piger comment ça marche = trop compliqué (oui je suis exigent, non je n'ai pas envie d'utiliser des trucs complexes lorsque la même chose existe en simple).
        
        Mais c'est quoi tes lenteurs sous Windows ? Je ne pige pas car je n'ai pas du tout la même expérience.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Adrien Dorsaz (site web personnel, Mastodon) le 23 août 2017 à 18:24. Évalué à 6.
        
        Ces 6Go ne veulent pas dire grand chose: quand de la RAM est disponible, Linux l'utilise au max pour y mettre des données en cache (ça ne sert à rien d'avoir de la RAM vide et le cache est hyper pratique pour se passer de la lecture des disques).
        
        Il faudrait avoir plus de détails au moins sur l'utilisation réelle et l'utilisation en cache. Ce genre d'infos est disponible avec htop.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Kerro le 27 août 2017 à 15:58. Évalué à 3.
        
        Les 6 Gio sont de « vrais » Gio.
        
        Tout ça ne répond pas à la question de base : qu'est ce que c'est cette histoire de sentir que Linux ou Windows est horriblement lent ?
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 27 août 2017 à 20:55. Évalué à 5.
        
        J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.
        
        Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).
        
        Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
        - L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
        - Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
        - Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).
        
        Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).
        
        La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.
        
        Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.
        
        J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.
        
        Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par claudex le 27 août 2017 à 21:01. Évalué à 5.
        
        De ce que tu explique, j'ai plutôt l'impression que c'est un problème d'application que de système. Et si ces applications tournaient sur Haiku, elles seraient tout aussi lentes.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Réécrire l'histoire
        
        Posté par ʭ ☯ le 28 août 2017 à 12:13. Évalué à 2.
        
        Il parle de ressenti. Je crois que souvent on attend dans linux que firefox ou libreoffice s'ouvre sans aucune indication à l'écran, et on se dit c'est normal. Si j'ai bien compris, Haiku affiche immédiatement une fenêtre vide, pour qu'on sache que le clic a bien été pris en compte. Kde de son côté affiche un logo sautillant sur le curseur de souris pendant que l'application se lance, mais c'est pas propre.
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
        
        [^] # Re: Réécrire l'histoire
        
        Posté par claudex le 28 août 2017 à 14:29. Évalué à 4.
        
        Il parle aussi de plusieurs thread dans l'application. Ce qui fait qu'un clic sur un bouton affiche un retour immédiatement. Ça c'est clairement lié à l'application. Concernant, l'affichage d'une fenêtre vide dès le lancement, c'est aussi tout à fait faisable par l'application sous GNU/Linux, c'est juste un choix de développement.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Kerro le 28 août 2017 à 16:43. Évalué à 3.
        
        Et surtout je ne vois pas comment il est possible d'obliger un thread à faire le job que les architectes de l'OS ont décidé.
        Par exemple comment obliger le thread à afficher une fenêtre vide dès qu'on lance l'application ? Ce n'est pas propre à cet OS, c'est juste que les développeurs acceptent de suivre la ligne de conduite. L'OS n'y est pour rien.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 29 août 2017 à 08:56. Évalué à 3.
        
        Dans Haiku, tu ne peux pas créer une fenêtre sans créer un thread qui va gérer sa boucle d'évènement. A ma connaissance, sur tous les autres systèmes, si tu veux faire une fenêtre avec son propre thread pour gérer les évènements, c'est possible, mais il faut créer le thread explicitement. Du coup, sous Haiku, pour faire une application qui n'arrive pas à afficher rapidement sa fenêtre, il faut le faire exprès.
        
        La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger. Sous Haiku, le système de base fournit déjà pas mal de fonctionnalités dans deux ou trois bibliothèques partagées, qui du coup sont tout le temps chargées en RAM puisque tout le monde les utilise. Du coup, il y a beaucoup moins besoin d'accès disques pour charger toutes les dépendances de chaque application. D'où, je suppose, un lancement plus rapide.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 29 août 2017 à 09:24. Évalué à 2.
        
        La deuxième chose: sous Linux, chaque application utilise un ensemble de bibliothèques qu'il va falloir charger.
        
        En effet. Sauf que… ce n'est pas si simple que ça. La grande majorité des distribs mettent toutes les libs en partagées, mais il existe des tentatives pour faire autrement. De la même manière, les distribs qui sont basées sur Debian vont hériter de la manie d'activer quasiment toutes les options: par exemple, mpd dépend de plusieurs lib dont le rôle, à vue de nez, est le même: support des wav. Il y a aussi une chiée de dépendance pour qu'il puisse lire les musiques utilisées par les jeux d'amiga ou atari, plusieurs qui semblent liées au format mp3, etc.
        
        Bref, je ne crois pas que ce soit la faute de Linux, ni même des dev d'application. Enfin, peut-être un peu (c'est partagé en même temps) mais je pense que la majorité du problème viens des mainteneurs des distribs. Et, fatalement, des logiciels que l'on choisit d'utiliser. Celui qui mélange du KDE, du E17 du gnome et un peu de trucs avec motif, forcément qu'il va bloater son système.
        
        Du coup, comme Haiku se positionne à la fois au niveau de l'OS, des applications et de la distrib, je comprend bien que ce soit plus simple de régler ce type de problème.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 30 août 2017 à 10:35. Évalué à 2.
        
        Parlons décodage de médias alors:
        
        Une application native pour Haiku utilisera pour cela le "Media Kit" (dans la bibliothèque libmedia.so). Au chargement de l'application, il y a juste besoin de charger cette lib, qui est de toutes façons déjà en mémoire puisque par exemple, elle est utilisée par l'icône "systray" pour le contrôle du volume.
        
        Le chargement des codecs spécifiques ne se fera qu'à la demande lorsque l'application voudra décoder (ou encoder) un fichier média. Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 30 août 2017 à 13:19. Évalué à 2.
        
        Du coup, le temps nécessaire pour cela est reporté au moment où le décodage commence, et pas au chargement de l'application.
        
        Mouai… ou pas, en fait. Ta lib à beau être déjà en mémoire, il faut quand même résoudre les symboles. La lecture d'un fichier sur disque dur, ce n'est pas ce qui coûte le plus cher au démarrage d'une application.
        Ceci étant dit, ce phénomène peut être drastiquement réduit en limitant le nombre de symboles exportés par la lib, donc oui, je pense que si Haiku fait les choses bien, avec une API pas trop riche, il peut y avoir un vrai gain.
        Du moins c'est le cas pour le format ELF.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Kerro le 29 août 2017 à 17:11. Évalué à 3.
        
        Dans Haiku, tu ne peux pas créer une fenêtre sans créer un thread qui va gérer sa boucle d'évènement.
        
        J'ai bien compris, mais l'OS ne peut pas mettre un flingue sur la tempe du développeur pour que le thread en question fasse réellement le job. Et bien souvent le dév à autre chose à faire qu'afficher un truc de progression qui va durer 1/4 de seconde la plupart du temps (et 5 secondes parfois).
        Créer un thread vide = 4 lignes de code copié/collé
        Créer un thread qui fasse le job = 30 lignes de code qu'il faut adapter
        Ben c'est simple : on commence par les 4 lignes de code pour se concentrer sur l'essentiel. Et puis ça reste comme ça.
        --> les applications de cet OS sont réactives parce que les développeurs le veulent. L'OS n'y est pour rien.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par dinomasque le 29 août 2017 à 17:16. Évalué à 6.
        
        https://www.haiku-os.org/docs/api/classBWindow.html
        
        Il faut 1 ligne de code pour créer une fenêtre avec son thread sous BeOS.
        
        Faire autrement est très compliqué.
        
        BeOS le faisait il y a 20 ans !
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 30 août 2017 à 10:43. Évalué à 3.
        
        int main(void) { BApplication* app = new BApplication("x-vnd/PulkoMandy-test"); BWindow* window = new BWindow(BRect(100, 100, 400, 400), "Une fenêtre!", B_DOCUMENT_WINDOW_LOOK, B_QUIT_ON_WINDOW_CLOSE); window->Show(); app->Run(); return 0; }
        
        Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku. En 4 lignes de code, on a donc:
        - Créé et affiché une fenêtre (ce qui lance un thread pour traiter les évènements de cette fenêtre: redimensionnement, fermeture, etc),
        - Créé une boucle d'évènement pour l'application (BApplication) qui tourne dans le thread principal (Run() ne rend pas la main tant que l'application n'est pas quittée).
        
        Il peut y avoir quelques variantes, du genre, créer la fenêtre plutôt dans le constructeur de l'application ou au pire dans son callback ReadyToRun(). Mais dans les trois cas ce sera très tôt au lancement de l'application, et je ne vois pas pourquoi il faudrait plusieurs secondes pour instancier 2 objets C++ (même compliqués).
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 30 août 2017 à 13:13. Évalué à 3.
        
        Tu aurais au moins pu utiliser un pointeur intelligent franchement… même dans la vieille norme, il y avait auto_ptr (qui a ses défauts, ok, mais moins pire que le pointeur brut).
        
        Sinon, j'ai une question: quid des applications qui ont besoin d'un rendu bien particulier? Typiquement les jeux, mais aussi blender, et de manière générale, tout ce qui fait appel à OpenGL?
        Je sais que c'est un peu hors sujet, mais ça me semble un sujet important: le seul endroit ou il peut y avoir du feedback dans ces cas, c'est le curseur de souris ou les décorations de fenêtre…
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 31 août 2017 à 09:14. Évalué à 4.
        
        Tu remarqueras l'absence de delete dans ce code. C'est volontaire: ces deux classent se suppriment toute seules, respectivement lorsque la fenêtre est fermée, et lorsque l'application est quittée. L'utilisation d'un smart pointer est donc inutile ici.
        
        Pour OpenGL, on commence par créer une BWindow comme ci-dessus, puis on lui ajoute une BGlView qui permet d'obtenir un contexte OpenGL. On peut également utiliser EGL, qui se chargera alors de créer la fenêtre.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 31 août 2017 à 09:54. Évalué à 3.
        
        Donc, il y a un contexte qui est initialisé quand on charge la lib, et qui référence les instances de fenêtres, les nettoyant quand elles se ferment? Admettons que ce soit une bonne idée (c'est la technique que semblait utiliser glfw2, abandonnée par la v3 étrangement quand ils semblent avoir ajouté le support de multi-fenêtrage. Bon, la sdl semble toujours faire ça, mais force m'est de reconnaître que les applications SDL ne s'interfacent pas super bien avec le reste de mon système), pourquoi dans ce cas utiliser des pointeurs nus et non des objets réels?
        
        Ça éviterait que quelqu'un ne soit tenté de delete… d'ailleurs, si quelqu'un le faisait, il se passerait quoi?
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 31 août 2017 à 20:27. Évalué à 3.
        
        Chaque fenêtre est associée à un thread. Du coup, on ne peut pas faire facilement fonctionner un appel au destructeur "normal", il faut que la destruction se fasse forcément depuis le thread propre à la fenêtre.
        
        Pour la détruire, on lui envoie un message (B_QUIT_REQUESTED, en l'occurence) qui sera traité par sa boucle d'évènements. La fenêtre peut d'ailleurs refuser de se fermer (par exemple si elle contient un document non enregistré et qu'elle veut d'abord demander à l'utilisateur s'il est d'accord pour perdre ses changements).
        
        Le traitement du message se termine par la libération de la mémoire occupée par la fenêtre, puis l'arrêt de l'exécution du thread.
        
        Si on fait un delete sans arrêter la boucle d'évènements, l'application va probablement se planter dès que la fenêtre en question va recevoir un évènement. Cependant, il y a quelques sécurités pour avoir un genre de weak reference vers une fenêtre pour lui envoyer des messages seulement si elle existe encore. Dans ce cas, le thread continuera d'exister mais ne recevra plus de messages. Pour éviter cela, l'appel du destructeur de la fenêtre ouvre directement le debuger avec un message d'erreur clair pour le développeur ("you can't call delete on a BLooper object once it is running"). Et donc, normalement ce genre de code ne devrait pas survivre très longtemps.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par xcomcmdr le 01 septembre 2017 à 14:01. Évalué à 0.
        
        Wow, on dirait exactement Win32.
        
        Genre le message pour quitter, c'est WM_QUIT :
        https://msdn.microsoft.com/fr-fr/library/windows/desktop/ms632641(v=vs.85).aspx
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Renault (site web personnel) le 30 août 2017 à 13:27. Évalué à 3.
        
        Voilà à quoi va ressembler le main() de la plupart des applications pour Haiku.
        
        Qui ressemble aussi à un code typique d'une application Qt ou GTK+. Ce n'est pas si original que cela.
        
        Sinon bon, je trouve qu'il est assez délicat de comparer Haiku avec d'autres systèmes d'exploitations étant donné que c'est, dans l'ensemble, un système plus léger avec des applications qui sont elles aussi souvent plus légères. Il faudrait pouvoir comparer à fonctionnalité équivalente pour que cela fasse sens. Avec des applications vraiment lourdes (typiquement Firefox).
        
        Car bon, moi aussi je peux faire mon noyau qui ne fait pas grand chose et que j'optimise à fond pour un processeur donné et je poutre Haiku et Linux pour lancer mon éditeur de texte maison. J'exagère le trait, Haiku n'est pas un petit OS non plus, il y a de quoi travailler et tant mieux.
        
        Mais beaucoup de choses manquent et les applications (des tests que j'ai fait) sont souvent aussi plus simples que ceux sous Linux moderne (ce qui est fourni par GNOME, KDE ou Xfce en somme) du coup cela ne me semble pas délirant que Haiku soit plus rapide car la comparaison est biaisée. Ce n'est pas dit que ce soit dû à son architecture (et le peu qui est mis en avant ici est souvent reproduit par les autres systèmes depuis ou a un impact en réalité négligeable sur d'autres considérations).
        
        Après je conviens que Haiku a un choix architectural qui simplifie l'écriture d'applications avec son API, c'est bien, mais globalement Qt et GTK+ font la même chose depuis quelque temps (le monde a évolué depuis BeOS et se sont inspirés de lui). La question de savoir si pour l'utilisateur c'est mieux d'afficher une fenêtre vide qui se rempli ou d'envoyer le tout quand c'est fini reste une question d'implémentation. Et à fonctionnalité constante système + applicatif, j'émets des doutes sur la réelle vitesse d'exécution de Haiku par rapport à d'autres systèmes.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 31 août 2017 à 09:21. Évalué à 1.
        
        Qu'est-ce qui est arrivé à Firefox pour qu'il soie si lourd? Haiku a un navigateur web basé sur WebKit, certes pas parfait, mais qui permet quand même d'afficher un grand nombre de pages web sans trop de problèmes. Je ne dirais pas que WebKit est une bibliothèque légère, mais ce n'est que quelques méga-octets de code à charger. Et comme les autres applications, le navigateur affiche une fenêtre et est prêt à fonctionner en moins d'une seconde.
        
        Pourtant, je pense que c'est l'une des applications qui fait le plus "mal" les choses. En effet, l'architecture de WebKit (et surtout de WebKit 1 qui est encore utilisé dans Haiku) se prête très mal au fonctionnement avec plusieurs threads. En conséquence, une grande partie du rendu graphique est faite dans le thread de l'application et pas dans celui de la fenêtre. Mais ça, ça ne ralentit pas le temps de démarrage.
        
        Alors certes, on ne fait pas tout ce que fait Firefox, mais quand même, je pense que pour démarrer le navigateur et afficher une fenêtre, il ne devrait pas y avoir tant de choses à faire que ça? Ce n'est que plus tard, quand on commence à navigure sur des pages compliquées pleines de Javascript et d'effets graphiques animés, qu'on devrait commencer à avoir des problèmes.
        
        Pourquoi donc Firefox met-il tant de temps à se charger et à ouvrir une fenêtre?
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Renault (site web personnel) le 31 août 2017 à 09:42. Évalué à 4.
        
        Je te trouve assez naïf sur ces questions quand même.
        
        Firefox ce n'est pas une application simple. Comme tout navigateur moderne avec un peu de fonctionnalités, c'est proche d'être un autre système d'exploitation. Déjà les binaires et bibliothèques dont il dépend sont lourds (il faut donc du temps pour charger ça en mémoire), comme Firefox est un peu gros il doit dès le départ initialiser beaucoup de choses pour que la navigation soit opérande (la gestion de la mémoire par exemple qui est très complexe), Firefox est aussi hautement configurable (la liste d'options possibles est immense) en plus d'avoir des extensions, il faut bien charger et interpréter tout ça à chaque lancement. Sans compter qu'il faut charger l'historique et les marques pages, afficher les widgets personnalisés, etc.
        
        Et Firefox aussi doit identifier certains éléments matériels pour savoir s'il peut activer des choses comme l'accélération matérielle pour WebGL ou les codecs vidéo.
        
        Peu d'applications graphiques ont autant à faire au lancement, donc le chargement de Firefox au démarrage ne me paraît pas si lent (et tous les navigateurs modernes que j’ai testé prennent un peu de temps de ce côté là). Ce n'est en effet pas difficile de faire mieux si tu retires la quasi totalité de ce qui fait la complexité d'un navigateur (hors moteur de rendu).
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 31 août 2017 à 10:35. Évalué à 1.
        
        Je pense que le fait qu'il n'y presque (il existe de rares forks de firefox) que la mofo qui utilise gecko joue aussi: moins de contributeurs. Reste maintenant à déterminer pourquoi tant d'autres projets préfèrent webkit à gecko…
        
        il doit dès le départ initialiser beaucoup de choses pour que la navigation soit opérande (la gestion de la mémoire par exemple qui est très complexe)
        
        Genre… la gestion de la mémoire, toutes les applications natives le font hein… avec plus ou moins de bonheur, certes.
        A moins que, comme certains développeurs de jeux vidéo, FF ne fasse que de gros malloc et gère ensuite lui-même les blocs mémoire (surcharge de new et delete en C++, détournement de *alloc et free en C et C++ pour qu'ils pointent vers des fonctions custom)?
        Je serai surpris (parce que l'augmentation de la consommation mémoire de FF me semble trop douce pour ce type de modèle, à moins que les chunks ne soient vraiment petits, mais je reconnais n'avoir pas creusé la question), mais pourquoi pas (et puis, vue la quantité de parsing qu'il doit gérer, ce ne serait pas débile).
        
        Sans compter qu'il faut charger l'historique et les marques pages
        
        C'est vrai, tous les navigateurs ne le font pas. J'en vois au moins… 1 seul en fait (uzbl, parce que le but est d'être minimaliste). Même dillo et netsurf le font (mais pas de JS, nous sommes d'accord).
        
        Et Firefox aussi doit identifier certains éléments matériels pour savoir s'il peut activer des choses comme l'accélération matérielle pour WebGL ou les codecs vidéo.
        
        Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
        
        Le pire, c'est qu'au fond je suis d'accord avec toi: un browser, c'est complexe. Ceci dit, tu sembles chercher la petite bête pour défendre à tout prix firefox.
        Personnellement, je me pose juste les questions suivantes: Haiku utilise une vieille version de webkit.
        Quid du respect de la chiée de nouveaux standards de plus en plus complexes apparus depuis?
        Quid des sandbox?
        Firefox et les browsers multi-onglets que je connais tendent à avoir plusieurs processus et non threads pour sandboxer et éviter qu'un crash d'un onglet ne ferme le brouteur. Et celui de Haiku? Lancer un processus par page (si ce n'est plus), c'est autrement plus lourd que lancer 1 thread par page…
        
        Bref, oui, il y a des raisons au "long" démarrage de firefox (j'ai vu pire perso), et il est probable que ça pourrait être amélioré (le code est pas tout neuf non plus, je ne serai pas surpris qu'il y ait plus que quelques dizaines de KLoc de dette technique, après tout l'origine date des années 90 hein) mais je m'interroge sur comment Haiku serait plus rapide en offrant la même sécurité et robustesse, en se basant sur du code obsolète…
        
        [^] # Re: Réécrire l'histoire
        
        Posté par Renault (site web personnel) le 31 août 2017 à 10:52. Évalué à 4.
        
        Genre… la gestion de la mémoire, toutes les applications natives le font hein… avec plus ou moins de bonheur, certes.
        
        Je ne parle pas de faire des free / malloc à la demande, Firefox a un système de cache personnel à gérer et a son propre ramasse-miette. Pas tant d'applications recourent à ce genre de choses, souvent laissés à la charge de l'interpréteur / machine virtuelle de le faire quand il y en a.
        
        Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
        
        De manière individuelle, l'impact est faible. Là où je voulais en venir c'est que Firefox comme la plupart des gros navigateurs a beaucoup de petites choses du genre à faire au démarrage (et même en continue pour d'autres aspects). Je doute très fortement que tu as une fonction gros_ralentissement_au_démarrage(), mais un cumul de petits ralentissements qui à la fin ont un impact assez gros.
        
        Il y a du coup des couches d'abstraction à mettre en place, peut être même une implémentation purement logicielle quand ce genre de chose manquent à l'appel.
        
        C'est un logiciel multiplateforme, comme tout logiciel multiplateforme sur des systèmes hétérogènes et potentiellement complexes, pour gérer au mieux les écarts tu dois concevoir des couches d'abstractions qui peuvent avoir aussi un impact sur les performances et la fiabilité du machin. Quand tu fais une application monoplateforme, comme ici pour Haiku, c'est plus simple, les accès sont plus directs, moins de choses à vérifier, moins de code pour gérer les différentes situations, tu peux optimiser bien des choses…
        
        Je ne cherche pas spécialement à défendre Firefox, car le problème est le même ailleurs d'une part (je ne trouve pas Chrome rapide au démarrage non plus), et que cela concerne beaucoup d'applications aussi (LibreOffice par exemple). En fait je défends plutôt les autres systèmes face à Haiku car il me semble simpliste de dire que Haiku est plus rapide que les autres sans proposer autant de fonctionnalités.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 31 août 2017 à 20:18. Évalué à 3.
        
        Version obsolète, c'est un peu exagéré. On utilise actuellement un WebKit de mars 2016. Alors certes, ce n'est pas la toute dernière version, mais c'est quand même pas si ancien que ça.
        
        Pour les sandboxes, ce n'est pas encore fait (c'est ce qu'apporte webkit2 - le moteur de rendu étant le même entre webkit1 et webkit2). ça viendra un jour mais c'est un assez gros travail de passer de webkit1 à webkit2 et on a pas encore eu le temps de s'y mettre. De plus, cela devient plus facile avec les versions plus récentes de WebKit qui commencent à mieux séparer les parties spécifiques à chaque plateforme du code commun à toutes. Donc on préfère d'abord rattraper un peu notre retard sur les versions à jour du moteur, avant de se pencher sur ce problème.
        
        Cependant, si on faisait un processus par page, on pourrait afficher la fenêtre principale encore plus vite, et lancer ces processus seulement lorsque les onglets sont affichés pour la première fois. Du coup, l'apparition de la fenêtre serait encore plus rapide, mais par contre l'apparition de la page dans la fenêtre, serait elle un peu plus lente (encore que, lancer un process, c'est pas forcément un truc qui prend des heures non plus).
        
        De mon point de vue, ça semble bien: je clique sur l'icône du navigateur, et paf, la fenêtre apparaît. Ensuite, la page se charge, mais j'ai une barre de progression en bas de l'écran qui m'indique qu'une opération potentiellement lente est en cours (téléchargement depuis le réseau, lancement du process de rendu, et tout le bazar). C'est ce genre de chose qui me semble importantes pour une interaction confortable avec un ordinateur. Que les traitements soit longs, ça ne me pose pas de problème, par contre, les actions de l'utilisateur doivent être prises en compte immédiatement et avec un retour rapide à l'écran, pour qu'on sache que l'ordre est reçu.
        
        Un splash screen est l'exemple le moins discret. En réfléchissant un peu on peut faire quelque chose de plus subtil et qui passe inaperçu. Exemple amusant: sur iOS, les applications sont packagées avec une capture d'écran de la première chose qu'elles affichent. Cette image est affichée tout de suite quand on lance l'application. Du coup, on a l'impression que le système réagit très vite, et éventuellement que c'est l'application qui met du temps à s'activer. Mais on a au moins un retour sur le fait que l'application est lancée.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par xcomcmdr le 30 août 2017 à 13:47. Évalué à 3. Dernière modification le 30 août 2017 à 13:49.
        
        C'est exactement pareil avec Win32, Windows Forms, WPF…
        
        Exemple avec WPF :
        
        internal class Startup { [STAThread] public static void Main(string[] args) { var application = new App(); application.InitializeComponent(); application.Run(); } }
        
        Et là on a déjà :
        - Un thread de rendu WPF (interne)
        - Un thread principale pour l'application, dans lequel s'exécute la boucle des messages.
        
        Win32 et Windows Forms, c'est exactement pareil, au moins sur le fond.
        (et idem, application.Run() ne rend pas la main avant la fin du programme)
        
        Un traitement long, si l'application est bien faite, se fera dans un thread dédié avec à la fin un appel (asynchrone ou non) au dispatcher WPF pour mettre à jour les éléments graphiques (qui exécute le code qu'on lui donne sur le thread principale).
        
        Si l'application met du temps à s'afficher, on peut lui mettre un SplashScreen en deux clics (ça arrive si la machine est vielle ou sur un cold-boot de l'application, surtout).
        
        Mais c'est pas l'OS qui va forcer une application à être bien écrite.
        
        Depuis Windows Vista et DWM, une application qui ne répond pas reçoit :
        - Forcément un contour de la fenêtre principale qui permet de la fermer (en fait, ça existait déjà sous XP - au moins)
        - Pouvoir choisir à partir de la fenêtre si on veut la fermer tout de suite ou attendre
        - Un titre de fenêtre auquel on rajoute "(Ne répond pas)" (depuis XP, en fait)
        - Un effet graphique qui blanchi à 50% la zone cliente de la fenêtre.
        
        Mais c'est tout.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 30 août 2017 à 08:49. Évalué à 1.
        
        Créer un thread vide = 4 lignes de code copié/collé
        
        Je HAIS le code dupliqué!
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 29 août 2017 à 09:14. Évalué à 2.
        
        Ça s'appelle une API standard.
        
        Hors, Linux n'a pas vraiment d'API graphique au sens affichage de boutons, de fenêtres, scrollbars, etc.
        X11 en à peut-être, et je ne suis même pas sûr que ce soit vraiment le cas (motif peut-être? le truc super hideux la…): des gens ont construit Qt, Gtk, Fltk et sûrement bien d'autres, mais ce n'est aucunement lié à Linux. À X11, à la rigueur.
        
        C'est la qu'un système comme Haiku peut, tant qu'on se limite aux outils «standards» qu'il fournit (j'imagine bien qu'on doit pouvoir contourner, ne serait-ce que parce que c'est du code libre), imposer la création de threads.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par pulkomandy (site web personnel, Mastodon) le 30 août 2017 à 10:54. Évalué à 2.
        
        Le serveur graphique lui-même va créer un thread de son côté pour gérer les interactions avec l'application. Donc ça fait au moins un thread.
        
        De l'autre côté, si on veut attaquer les choses en bas niveau, on a un protocole à base de communication inter-process avec des "ports", qui permettent d'envoyer et de recevoir des messages. Le protocole utilisé n'est pas documenté, et peut changer d'une version à l'autre de Haiku. Alors oui, en théorie c'est possible de réécrire tout le framework côté applicatif à partir de ça, mais franchement, pourquoi on ferait une chose pareille?
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 30 août 2017 à 13:02. Évalué à 2.
        
        Le protocole utilisé n'est pas documenté, et peut changer d'une version à l'autre de Haiku. Alors oui, en théorie c'est possible de réécrire tout le framework côté applicatif à partir de ça, mais franchement, pourquoi on ferait une chose pareille?
        
        C'est bien ce que je voulais mettre en exergue :)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 30 août 2017 à 13:24. Évalué à 2. Dernière modification le 30 août 2017 à 13:24.
        
        Tu sais, je répondais à ça:
        
        Par exemple comment obliger le thread à afficher une fenêtre vide dès qu'on lance l'application ?
        
        D'ailleurs, maintenant que j'y pense, j'aurai peut-être pu mentionner windows et son fameux winmain (qui n'est pas utilisé pour ça, mais ça aurait pu).
        J'aurai aussi du mentionner que la fonction main n'est pas la première chose à s'exécuter (init des variables globales, qui, en C++, peuvent inclure des singleton).
        
        Enfin bref, quand on à le contrôle du chargeur de binaire, il sera difficile pour l'application de contourner les règles… encore faut-il qu'il y en ait ;) (pas trop le cas avec ELF sous linux contrairement à Haiku à priori, mais je ne maîtrise pas le sujet.)
      - [^] # Re: Réécrire l'histoire
        
        Posté par steph1978 le 28 août 2017 à 01:07. Évalué à 2.
        
        Je parlais d'essais sur des machines de 256Mo de RAM à l'époque.
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 29 août 2017 à 09:38. Évalué à 2.
        
        Si c'est ce genre d'info que tu veux, sache que je fais tourner linux sur un i586 (des softs compilés en 686 plantent à cause des instructions pas connues) cadencé à 700MHz et disposant de moins de 200Mio de RAM.
        
        Ce n'est pas à proprement parler rapide (surtout quand je lance une compilation hihi), mais c'est réactif. Détail amusant: un soir ou je revenais de formation (avec donc le PC pro sur moi), je les ai fait faire la course.
        
        Du bouton power au login réellement utilisable, les 2 systèmes vont aussi vite, windows, son octo-core et ses palanquées (16Gio) de RAM se font rattraper par le machin poussif designed for windows Me. La raison est simple: windows ne charge rien avant le login, tandis que le vieux BIOS mets 3 plombes.
        
        Si je dois dire qui est responsable, je dirai que c'est mon choix d'outils: les logiciels que j'utilise, je les ai sélectionnés pour leur légèreté. i3, urxvt, zsh (important l'air de rien, il consomme moins de ram que bash tout en offrant un vrai confort supplémentaire), mpd, vim, xosview (parce que j'aime savoir si mon CPU passe plus de temps à attendre après le matos à vraiment bosser, et l'affichage des divers usages de la RAM m'est aussi utile pour savoir quand je dois laisser un peu d'air au système) et ce genre de jouets. J'arrive même à regarder des vidéos pas trop lourdes (mpv) et aller sur des sites pas trop lourds (uzbl, links2, netsurf, dillo).
        
        [^] # Re: Réécrire l'histoire
        
        Posté par xcomcmdr le 29 août 2017 à 10:35. Évalué à 3.
        
        Tu compares des choux et des carottes, quand même.
        
        Moi aussi je peux le faire :
        - Si on compare sur un ordinateur disposant d'un Pentium III Slot 1 à 800 MHz, une GeForce 4 Ti4800 sur un port AGP2X, un chipset Intel 440BX sur une carte mère ASUS P2B-F, 512 Mo de RAM PC100, et un disque dur IDE en UDMA/33 avec une vitesse de rotation par minutes de 7200 (sans fragmentation quel que soit le FS), on remarque que Xubuntu 12.04 prend 10 fois plus de temps à démarrer que Windows 98SE (merci Xorg).
        
        Voilà, voilà.
        
        Je sais pas si c'est très utile.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Réécrire l'histoire
        
        Posté par freem le 29 août 2017 à 11:02. Évalué à 2.
        
        En même temps, c'est ce qu'il demandait: comparer un système sur du matos ancien. C'est sûr, si tu mets du bloat, linux ou windows, ça va ralentir le système, surtout s'il est ancien et/ou restreint.
        
        Toujours est-il que oui, on peut avoir un système (linux dans mon cas) réactif sur un truc qui devrait être relégué dans un musée. Pas avec n'importe quels logiciels, forcément. J'aurai pu utiliser LXDE aussi (déjà testé, ça passe bien) mais XFCE commence déjà à faire sentir le poids de ses outils. Des trucs qui fournissent plus de fonctionnalités, ça ne passe juste pas (animations, transparence réelle, calendrier intégré à tout, horloge "analogique" en couleur, seront autant de trucs qui risquent de ralentir, peut-être pas pris seuls, mais le combo est gagnant).
# Est ce utilisable tout les jours?

Posté par seb95 (site web personnel) le 21 août 2017 à 23:24. Évalué à 1.

Bonjour, voila je suis comment dire, impressionné par ce petit haiku, propre et sympa, surtout bien plus rapide que ce que je connais deja avec mes linux.

Ma question est simle, est ce utilisable sur une seconde machine? J'entends par la que ma debian est mon système principale et le restera mais j'ai bien d'autre PC, qui sont aussi sur Debian mais ça c'est autre chose. J'ai en revanche deux PC qui sont un peu vieillot, entendez par la que c'est des PC qui fonctionnent mais qui ne supporte rien d'autre qu'une SUSE 9.3 kde, et / ou slitaz. Pourrais je y mettre haiku et l'utiliser comme machine d’appoint par exemple?
- [^] # Re: Est ce utilisable tout les jours?
  
  Posté par pulkomandy (site web personnel, Mastodon) le 22 août 2017 à 09:33. É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: Est ce utilisable tout les jours?
    
    Posté par seb95 (site web personnel) le 22 août 2017 à 12:01. Évalué à 1.
    
    Merci de ta reponse, je pense que ça ne doit pas etre plus penible a utiliser que ma suse9.3 qui n'est plus mit a jour depuis 10 ans au bas mot, qui ne peut q'a peine aller sur certain site.
    Je cherche surtout un truc pouvant redonner vie a ce pc avec 512 mo de ram, et l'autre a 256 mo, c'est surtout pour aller lire des sites, faire un peu de note avec un éditeur, pas grand chose en faite;)
    
    Je vais me mettre ça sur une cle USB, j'ai deja testé dans une virtualbox et je suis vraiment charmé. Sur la page de téléchargement nous avons toujours le lien de l'alpha et pas de la beta qui est pourtant question ici, est ce normal?
    
    En tout cas merci de continuer ce projet un peu fou;)
    - [^] # Re: Est ce utilisable tout les jours?
      
      Posté par Psychofox (Mastodon) le 22 août 2017 à 12:25. Évalué à 2.
      
      c'est surtout pour aller lire des sites,[…] pas grand chose en faite;)
      
      Ce n'était pas le cas à l'époque où ce pc a été créé mais à notre époque javascript&co oblige c'est devenu une des activitées demandant le plus de ressources.
      
      Si tu as une autre machine à côté sur laquelle tu peux mettre un serveur SPICE, j'en ferais plutôt un thin client à base de mini distro style tinycore linux ou puppy linux.
    - [^] # Re: Est ce utilisable tout les jours?
      
      Posté par pulkomandy (site web personnel, Mastodon) le 22 août 2017 à 14:02. É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 freejeff le 23 août 2017 à 11:24. Évalué à 2.
      
      Je ne connais rien à Haiku mais j'ai récemment redonné vie à un netbook d'il y a plus de 10 ans avec puppy linux et le résultat est bluffant. Le choix d'application est fait pour que cela soit utilisable sur de très vielles machines. Tu as de plus un très large éventail d'applications installable. Tu as pleins de version avec comme base slackware ou ubuntu.
      
      Je pense que tu pourras facilement refaire vivre ton PC avec ça. De plus tu peux tester en liveCD.
      
      Je pense que le test en machine virtuelle ne sert pas à grand chose. Les problème que tu risque d'avoir serait la compatibilité de ta carte graphique avec les noyaux modernes.
      
      C'est super en tout cas de ne pas abandonner de vieux PCs !
      - [^] # Re: Est ce utilisable tout les jours?
        
        Posté par seb95 (site web personnel) le 23 août 2017 à 13:37. Évalué à 2.
        
        En tout cas merci de vos réponses.
        @ pulkomandy ,
        
        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.
        
        Je l'ai fais, mis sur une clé, et installé pour le moment sur une petite clé, c'est super, a tel point que je suis entièrement convaincu d'avoir trouvé l'OS dont j'ai besoin et puis quelle rapidité!!! Ça nous change de nos linux qui plus ça va plus il devient lourd, je parle surtout des deux mastodontes kde et gnome.
        
        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.
        
        Alors je certifie que c'est vraiment stable et surtout rapide, c'est un peu bizarre puisque jamais utilisé sauf rarement pour essayer a une ou deux reprises, mais c'est très intéressant, bon je me vois pas mettre haiku sur mon pc principal car j'aime le confort de kde, gnome (actuellement) ou/et surtout xfce mais sur un second pc utilisé tout aussi souvent c'est vraiment top…
        
        Vraiment encore une fois, je sais pas si j'aurais les capacités a donner de mon temps, mais votre projet m'interesse au plus haut point.
        
        @ freejeff;
        
        Je ne connais rien à Haiku mais j'ai récemment redonné vie à un netbook d'il y a plus de 10 ans avec puppy linux et le résultat est bluffant. Le choix d'application est fait pour que cela soit utilisable sur de très vielles machines. Tu as de plus un très large éventail d'applications installable. Tu as pleins de version avec comme base slackware ou ubuntu.
        
        Effectivement, je connais un peu pupy ou sa version française toutoulinux (je sais meme plus si c'est ça)
        
        Je pense que tu pourras facilement refaire vivre ton PC avec ça. De plus tu peux tester en liveCD.
        Oui il est facilement capable, un peu comme slitaz mais en meme temps ça fait du bien d'essayer des chose autre que du linux;)
        
        Je pense que le test en machine virtuelle ne sert pas à grand chose. Les problème que tu risque d'avoir serait la compatibilité de ta carte graphique avec les noyaux modernes.
        Je suis d'accord, le virtuel c'est pour donner une idée avant de l'essayer en dur, ce que je fais tres vite apres ;)
        
        C'est super en tout cas de ne pas abandonner de vieux PCs !
        Ça c'est sur, je n'aime pas le gaspillage, j'avais encore peu une grosse tv qui faisait précisément 45 kg, je l'ai gardé jusqu’à ce qu'elle me lâche, 13 ans de vie on va pas se plaindre. Là les PC dont je parle fonctionnent encore tres bien, alors le plus vieux n'est pas capable de me faire démarrer firefox en un temps record mais midori me permet de voir les sites que je visite souvent, pour l'autre il tourne sur une nutyx xfce mais j'ai bien peur que tôt ou tard le 32 bits dans linux soit de moins en moins toléré ( c'est un i586).
        
        Amicalement
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par Psychofox (Mastodon) le 23 août 2017 à 14:06. Évalué à 5.
        
        Ça nous change de nos linux qui plus ça va plus il devient lourd, je parle surtout des deux mastodontes kde et gnome.
        
        En même temps tu prends ton linux de tous les jours et tu démarre une session flux/openbox au lieu de kde ou gnome et c'est déjà le jour et la nuit en terme de ressenti.
        
        Après ça va plus dépendre des applications que tu fais tourner au dessus mais j'imagine qu'on auras beau avoir un OS léger avec Haïku le jour où on porte une application comme libreoffice ou un navigateur bien moderne tu verras que la différence n'est pas aussi grand qu'elle n'y parait.
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par seb95 (site web personnel) le 23 août 2017 à 15:44. Évalué à 2.
        
        Je vais etre radicale, mais il me semble que les kernels linux récents ne supportaient plus le i386? Je sais plus si c'est ici ou autre part mais maintenant le kernel supporte le 32bits a partir du i586, si je me trompe pas. Alors c'est simple mais la première machine que j'ai n'est simplement pas du i586. Ensuite même avec du fluxbox et autre tout léger, le démarrage est tout de même long. Par exemple ma Debian ne fonctionne pas dessus, elle échoue a chaque fois, je dois garder une lenny pour y être installé.
        
        Voila, puis après il y a le coté plus ou moins complet, avec fluxbox je devrais sélectionner paquets après paquets pour mes besoin, au pif une application calculette, avec haiku j'ai déjà tout ça et tout prêt. Et puis changer un peu ça fait du bien :)
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par Renault (site web personnel) le 23 août 2017 à 17:28. Évalué à 3.
        
        Je vais etre radicale, mais il me semble que les kernels linux récents ne supportaient plus le i386? Je sais plus si c'est ici ou autre part mais maintenant le kernel supporte le 32bits a partir du i586, si je me trompe pas.
        
        Tu ne te trompes pas.
        Après il faut reconnaître que le i386 n'est plus produit depuis 2007, et qu'il a été conçu en 1985.
        
        Cela a été supprimé car cela introduisait du code complexe pour les prendre en compte et qu'en plus le code était régulièrement cassé et personne ne semblait s'en plaindre. Devant le peu d'utilisateurs concernés, cette décision a été actée.
        
        Concernant la légèreté des systèmes, je trouve qu'il y a des éléments gênants dans l'argumentation globale vis à vis de ces machines.
        Le i586 est technologiquement dépassé depuis 22 ans, commercialement depuis 20 ans. C'est colossal. Et vous voulez utiliser des logiciels modernes sur ces machines ? Tu ne peux pas demander à du matériel si ancien de gérer des cas d'usages qui n'existaient pas vraiment à cette époque, car ce n'était pas possible.
        
        Le Web a grossi, le multimédia prend une place grandissant et s’alourdit aussi (images et vidéos plus volumineuses), les interfaces sont plus riches pour être plus simples et élégantes, etc. Les fichiers qu'on s'échange sont plus gros également, les logiciels qui les traitent font plus de choses et donc grossissent avec.
        
        Bref, le numérique a grandement évolué en 20 ans, ton processeur (et la machine qui va avec) ne peut suivre le rythme si longuement. Donc si ton usage de cette machine a changé significativement, je ne peux que te conseiller de changer de machines. Si ton usage n'a pas vraiment changé en 20 ans, garde ta machine sur un système adapté à son âge et débranche le d'Internet.
        
        Essayer d'avoir le beurre (ta machine antédiluvienne) et l'argent du beurre (des usages modernes de son ordinateur) me semble vain et non pertinent.
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par pulkomandy (site web personnel, Mastodon) le 24 août 2017 à 08:42. É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: Est ce utilisable tout les jours?
        
        Posté par ʭ ☯ le 01 septembre 2017 à 08:31. Évalué à 2.
        
        Vrai, son CPU est compatible i586.
        
        Faux, le MMX est arrivé avec les P55C, aka Pentium MMX. C'est du i586, et le Pentium Pro inaugurait le i686 sans MMX.
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par Psychofox (Mastodon) le 23 août 2017 à 21:14. Évalué à 4.
        
        Voila, puis après il y a le coté plus ou moins complet, avec fluxbox je devrais sélectionner paquets après paquets pour mes besoin, au pif une application calculette, avec haiku j'ai déjà tout ça et tout prêt. Et puis changer un peu ça fait du bien :)
        
        Non mais j'essaye pas de te convaincre d'utiliser du linux à la place d'Haïku, je dis juste qu'il y'a moyen de faire tourner du plus léger que la distro de base avec gros environnement de bureau.
        
        Perso sur les vieilles machines j'aime bien mettre du openbsd. C'est hyper vite installé, à peu près tous les applis que je veux sont dispos, c'est facile à maintenir et à comprendre et ça supporte à peu près n'importe quoi à partir du intel 486.
        
        [^] # Re: Est ce utilisable tout les jours?
        
        Posté par freejeff le 23 août 2017 à 16:53. Évalué à 3.
        
        mais j'ai bien peur que tôt ou tard le 32 bits dans linux soit de moins en moins toléré ( c'est un i586).
        
        Honnêtement, je pense que tu as le temps !
        
        De plus, il existe toujours la gamme des Intel Quark en 32 bits. Lorsque tu n'as pas besoin de beaucoup de RAM, l'utilisation de 64 bits est discutable, donc Linux qui est aussi utilisé en embarqué, n'est pas prêt de se séparer du support 32 bits.
        
        Après que tu veuilles t'amuser avec un autre OS, fonce !
        
        Mais Tu pourras probablement toujours faire tourner un Linux dessus dans 10 ans. Par contre la couche applicative (firefox, libreoffice, …), rien n'est moins sûr !
# Serveur down ?

Posté par MTux le 27 août 2017 à 23:15. Évalué à 4. Dernière modification le 27 août 2017 à 23:16.

$ wget https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
--2017-08-27 23:00:56-- https://download.haiku-os.org/nightly-images/x86_64/current-anyboot
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:443… connecté.
requête HTTP transmise, en attente de la réponse… 302 Moved Temporarily
Emplacement : http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip [suivant]
--2017-08-27 23:00:56-- http://download.haiku-os.org:8081/nightly-images/x86_64/haiku-nightly-hrev51382-x86_64-anyboot.zip
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Résolution de download.haiku-os.org (download.haiku-os.org)… 2a01:4f8:190:64c3::2, 78.46.189.196
Connexion à download.haiku-os.org (download.haiku-os.org)|2a01:4f8:190:64c3::2|:8081… échec : Connexion terminée par expiration du délai d'attente.
Connexion à download.haiku-os.org (download.haiku-os.org)|78.46.189.196|:8081… échec : Connexion terminée par expiration du délai d'attente.
Nouvel essai.

Le serveur ne répond pas en ipv4/ipv6