Haiku R1 bêta 2

Posté par  (site web personnel, Mastodon) . Édité par ZeroHeure, zurvan, Davy Defaud, palm123, Ysabeau 🧶 🧦, bubar🦥 et Thomas Debesse. Modéré par Davy Defaud. Licence CC By‑SA.
Étiquettes :
70
10
juin
2020
Haiku

Vingt mois après la première version bêta de Haiku, il était plus que temps pour une mise à jour ! La deuxième version bêta vient d’être publiée. Cette dépêche fait le tour des principaux changements et nouveautés.
Haiku, léger comme une plume

Haiku est un système d’exploitation pour les ordinateurs de bureau dont le développement a commencé en 2001. Il reprend les idées de BeOS et assure une certaine compatibilité avec les applications écrites pour ce dernier.

Sommaire

Encore une version bêta ?

Il semble utile de rappeler la feuille de route du projet Haiku, qui a des définitions un peu inhabituelles des versions Alpha et Bêta.

L’objectif de Haiku est de fournir un système d’exploitation complet au moins iso‑fonctionnel avec BeOS R5.0.3 (la dernière version officielle de BeOS). Cette version sera la version R1. Il y a actuellement un flou assez important sur ce qui vient après cette version R1. Probablement une rupture de compatibilité, rendue nécessaire par l’obsolescence des outils ou la nécessité de corriger des erreurs de conception dans l’API. Par exemple, la compatibilité avec BeOS nécessite de compiler une partie de Haiku avec la version 2 de gcc, qui est largement obsolète (elle ne permet pas de compiler du code conforme à la norme C99 ni aucune des versions suivantes de C ou de C++).

Avant la version R1, sont prévues deux phases :

  1. les versions Alpha, dont la première a été publiée en 2009, ont été publiées à partir du moment où il est devenu possible de compiler Haiku depuis Haiku (« self hosting ») ; cette étape permettant aux développeurs de commencer à utiliser eux‑mêmes le système ;
  2. les versions Bêta, dont la première a été publiée en 2018, ont démarré à partir du moment où toutes les fonctionnalités de BeOS R5.0.3, augmentée d’objectifs supplémentaires décidés en 2010, ont été disponibles.

Le système restera encore quelque temps en bêta, phase pendant laquelle l’équipe a choisi de se concentrer sur les corrections de bogues, les améliorations des performances et la simplification de l’expérience utilisateur. En parallèle, il faut essayer d’attirer les développeurs d’applications natives, sans lesquelles le système n’a pas de raison d’être (si c’est seulement pour lancer des applications conçues pour GNU/Linux, autant rester sous Linux).

À ces aspects s’ajoutent la nécessité de suivre l’évolution de l’informatique, par exemple au niveau des pilotes matériels ou du navigateur Web. C’est la partie qui demande probablement le plus de travail, suite au choix de ne pas réutiliser le noyau Linux qui aurait permis d'utiliser directement la plupart des pilotes nécessaires.

En conséquence, cette nouvelle version comporte peu de nouvelles fonctionnalités visibles. Il y en a tout de même quelques‑unes, car personne ne peut empêcher les contributeurs de faire ce qu’ils veulent, malgré tout.

L’objectif pour l’instant est de tenir un rythme d’une nouvelle version par an. Objectif encore manqué cette fois, puisque la version précédente date de septembre 2018 (1 an et 8 mois). C’est déjà beaucoup mieux que le trou de six ans entre la version alpha 4 et la bêta 1.

Configuration nécessaire

Haiku n’est pas très exigeant quant au matériel nécessaire, n’importe quel ordinateur âgé de moins de quinze ans fera probablement l’affaire. Cependant, le système saura sans problème tirer parti d’une configuration plus performante :

  • un ordinateur avec un processeur x86 (64 bits ou 32 bits) pouvant exécuter les instructions MMX ;
  • une carte graphique compatible VESA et un écran d’au moins 800 × 480 pixels ;
  • un clavier et/ou une souris ;
  • environ 300 Mo de mémoire vive ;
  • 2 Gio d’espace libre sur un disque dur ou une clé USB (ou choisir une utilisation autonome depuis un DVD).

Si votre processeur ne sait pas exécuter les instructions SSE2 vous ne pourrez pas utiliser le navigateur natif WebPositive (il s’agit d’une limitation du moteur HTML WebKit). Les développeurs de Haiku conseillent dans ce cas d’utiliser NetSurf en remplacement.

Principales nouveautés

Il est difficile de lister tous les changements, puisque près de 900 tickets ont été corrigés depuis la version précédente. Voici cependant quelques-uns des points les plus intéressants.

Périphériques d’entrée

Les différentes fenêtres pour la configuration des souris, claviers et pavés tactiles sont maintenant regroupées dans une unique fenêtre de configuration.

Les boutons au‑delà du troisième ainsi que la molette horizontale sur les souris USB peuvent être utilisés.

La nouvelle fenêtre de configuration avec une souris à cinq boutons

Matériel géré

Le pilote XHCI (USB 3) a été largement retravaillé et nettoyé pour résoudre la plupart des problèmes de compatibilité.

Il est maintenant possible d’utiliser les supports de stockage NVMe qui remplacent de plus en plus le SATA dans le matériel moderne.

Le travail sur le pilote Intel Extreme pour les contrôleurs vidéo Intel continue, avec une amélioration du fonctionnement sur les machines de génération Sandy Bridge et précédentes. Les premières étapes pour l’affichage sur plusieurs écrans (en mode clone, pour le moment) ont été franchies.

Les pilotes réseau ont été synchronisés avec FreeBSD 12, permettant l’utilisation de l’Ethernet et du Wi‑Fi sur la plupart des ordinateurs. D’autre part, la désactivation d’une vérification de cohérence (sanity check) dans la pile réseau permet de multiplier par cinquante les performances de cette dernière.

Le pilote pour les cartes audio compatibles Intel HDA a également reçu quelques améliorations, mais il reste encore fort à faire pour avoir une sortie son fonctionnelle sur toutes les machines concernées.

Amélioration du processus d’installation

L’intégration du gestionnaire d’amorçage EFI se poursuit, il est maintenant automatiquement inclus dans l’image amorçable anyboot (pour la version bêta 1, il avait été ajouté manuellement dans l’image disque publiée). Son installation reste manuelle mais est plus facile à réaliser car la partition EFI peut être montée depuis Haiku. D’autre part, divers bogues dans le gestionnaire d’amorçage ont été corrigés pour améliorer la compatibilité avec toutes les configurations.

L’installateur de Haiku permet d’activer ou de désactiver un certain nombre de paquets optionnels. Ces paquets (principalement des outils et bibliothèques de développement) sont maintenant désactivés par défaut en mode autonome (live CD), ce qui permet d’utiliser et d’installer le système sans problème sur les ordinateurs avec peu de mémoire (environ 300 Mo sont nécessaires).

L’installateur montrant la liste des paquets optionnels

DriveSetup, l’outil de partitionnement de disques, a reçu lui aussi plusieurs améliorations et peut afficher l’espace disponible sur chaque partition et détecter les volumes chiffrés.

Paquets disponibles

Le projet HaikuPorts continue son travail pour fournir un ensemble de paquets prêts à installer sur Haiku. Citons par exemple l’arrivée de Rust et de Node.js.

Le dépôt haikuports comporte 2 761 paquets dont 355 propres à Haiku.

Interface utilisateur

La « Deskbar » (similaire à la barre des tâches de Windows) se dote d’un nouveau mode « miniature » qui occupe moins de place à l’écran. Elle s’adapte également beaucoup mieux aux écrans à haute résolution (avec des icônes dans les menus et le cartouche plus ou moins large selon le besoin) et peut être redimensionnée à la largeur souhaitée. Le mode « auto‑raise » qui permet à la Deskbar de passer automatiquement en avant‑a été retravaillé pour éviter son activation intempestive. C’est maintenant le mode configuré par défaut sur les nouvelles installations.

La Deskbar dans son nouveau mode compact

Tracker (le navigateur de fichiers) permet maintenant de faire une sélection « multi‑plage ». L’affichage a été optimisé pour corriger un problème de lenteur lors de l’affichage d’un dossier avec beaucoup de fichiers. La fenêtre d’information sur les fichiers liste leurs attributs étendus, qui auparavant n’étaient visibles que depuis la ligne de commande. Un modèle de fichier « contact » (pour l’application People) a été ajouté dans le menu afin de permettre de créer de nouveaux fichiers.

L’application SoftwareUpdater qui permet la mise à jour des paquets indique maintenant si un redémarrage est nécessaire après mise à jour. Le magasin de paquets logiciels HaikuDepot a aussi été retravaillé et optimisé, avec par exemple l’affichage de plusieurs captures d’écran par application, la liste des paquets en attente de téléchargement, un indicateur clair pour savoir quand l’application est en train de télécharger des informations depuis le serveur de paquets, et une interface utilisateur un peu plus claire et compréhensible (bien que ce soit encore loin d’être parfait).

Le dock « LaunchBox » peut être lancé automatiquement au démarrage, et afficher de très grosses icônes en 96 x 96 ou 128 x 128 pixels.

Le Terminal dispose maintenant d’une touche Méta, indispensable entre autres pour les utilisateurs d’Emacs. D’autre part, la commande uname affiche la version exacte de Haiku en cours d’utilisation (numéro de révision « hrev »).

Le lecteur de médias peut se souvenir de l’emplacement où la lecture d’un fichier s’était arrêtée, et reprendre la lecture à cet endroit.

Navigateur Web

Haiku fournit le navigateur WebPositive, utilisant le moteur WebKit (partagé avec Safari chez Apple, Epiphany et les consoles Sony PlayStation, par exemple). L’adaptation du moteur pour Haiku se fait petit à petit, et il reste encore de nombreux problèmes de compatibilité et de stabilité. Cependant, les choses s’améliorent, cette nouvelle version bêta 2 vient avec une grosse mise à jour de WebKit (près de deux ans de travail) et de nombreuses corrections sur la couche réseau (WebSockets…) et le rendu graphique.

Le navigateur permet également de choisir une taille de police de base plus grande que 18 points si nécessaire.

Sécurité

Une revue de tous les appels système est en cours pour détecter et corriger les plus gros problèmes de sécurité et possibilités de « planter » tout le système par un appel avec des paramètres incorrects (de façon volontaire ou pas).

L’ajout de SMAP et SMEP permet de vérifier au niveau matériel qu’il n’y a pas de confusion entre les espaces mémoire noyau et utilisateur. Cela nécessite d’expliciter dans le noyau tous les accès à l’espace mémoire utilisateur (remplacement des appels à memcpy() par user_memcpy()).

Le client FTP hérité de BSD, et qui n’était plus maintenu, a été remplacé par tnftp, une implémentation plus propre et avec moins de trous de sécurité.

Traducteurs de fichiers

Les traducteurs permettent aux applications de lire et écrire des fichiers sans avoir à se soucier du format utilisé.

Le traducteur WebP traite maintenant les images avec un canal alpha (transparence).

La libjpeg a été remplacée par la libjpeg-turbo, une divergence simplifiée et optimisée qui gagne en popularité, car la libjpeg ajoute de plus en plus d’extensions non standardisées au format JPEG standard.

Localisation

La version coréenne a malheureusement dû être supprimée car elle n’était plus maintenue. Cependant, les traductions en danois, espéranto, frioulan, portugais européen, thaï et turc sont maintenant disponibles. Haiku peut être utilisé dans vingt‑neuf langues différentes. Le manuel d’utilisation est, quant à lui, disponible dans vingt de ces langues.

Informations pour les développeurs

S’agissant d’une version bêta, il y a relativement peu de nouveautés, l’objectif étant d’abord de stabiliser les interfaces de programmation (API) existantes et de corriger les dysfonctionnements. Cependant, des ajouts sont toujours possibles.

Compatibilité POSIX

POSIX est un standard décrivant les API de systèmes de type UNIX. Implémenter les API POSIX permet de porter facilement un très grand nombre de programmes écrits pour fonctionner sur ces systèmes. Le standard évolue assez peu, mais il est assez vaste puisqu’il couvre de nombreux aspects : allocation mémoire, fils d’exécution, processus, réseau…

Haiku complète petit à petit son implémentation, en priorisant les parties nécessaires au portage de certaines applications :

  • la fonction posix_fadvice() a été ajoutée, elle est sans effet pour l’instant (cette fonction est utilisée à titre indicatif à des fins d’optimisation) mais permet de simplifier l’adaptation de logiciels écrits pour d’autres systèmes POSIX ;
  • une couche de compatibilité avec les périphériques réseau virtuels TUN et TAP de Linux a été ajoutée ;
  • les fonctions pthread_attr_getstack(), pthread_attr_setstack(), getpriority(), setpriority() et nice() sont disponibles ;
  • ​la constante POSIX_SPAWN_SETSID est ajoutée et son utilisation est possible dans posix_spawn() ;
  • correction d’une déviation du comportement de putenv() par rapport à ce qui est spécifié dans POSIX ;
  • la fonction sysconf() peut répondre aux demandes sur _SC_HOST_NAME_MAX, _SC_REGEXP, _SC_SYMLOOP_MAX et _SC_SHELL.

Game Kit

Les API de Haiku sont découpées en « kits » regroupant un ensemble de fonctionnalités. Le « game kit » regroupe des fonctions destinées à l’origine aux développeurs de jeux vidéo.

Une partie de ce kit est dédiée au son, avec la possibilité de lire de la musique ou de déclencher des effets sonores, en utilisant la classe BFileGameSound. Jusqu’à présent, cette classe chargeait forcément le son à partir d’un fichier. Il est désormais possible d’utiliser n’importe quelle classe implémentant l’interface BDataIO : tampon en mémoire, socket, ressources stockées dans le binaire de l’application…).

Interface Kit

Il est possible de créer une vue (BView) avec une couleur de fond transparente, permettant à la vue parente de rester visible.

Une nouvelle fonction permet de remplir un rectangle avec une image matricielle répétée en tuiles de façon optimisée.

Est‑ce que c’est l’année de Haiku sur le desktop ?

À vous de voir !

Aujourd’hui, il est possible d’utiliser Haiku comme système d’exploitation principal. Le système est stable, de nombreuses applications Qt sont disponibles (et un portage de GTK est en cours), ainsi qu’un bon nombre d’outils en ligne de commande, dont l’adaptation depuis GNU/Linux se fait en général sans trop de problèmes. On pourra par exemple éditer des documents avec LibreOffice, versionner du code source avec Git et l’éditer avec Vim. Certaines applications intéressantes de KDE sont portées : l’EDI KDevelop, Calligra Suite, Krita, etc. — mais GIMP n’est pas encore disponible.

Tout plein d’applications

Cependant, il reste encore beaucoup de choses à améliorer ou à compléter. Les navigateurs Web les plus connus ne sont pas disponibles : pas de Chromium, pas même de Firefox en vue. Il faut se contenter d’Otter ou du navigateur natif WebPositive (et parfois jongler entre les deux pour contourner les problèmes de compatibilité).

Pour les joueurs, il faut garder en tête qu’il n’y a pas encore d’accélération 3D, et pas non plus de version de Wine qui permettrait de lancer les jeux Windows (QEMU fonctionne, mais sans accélération processeur, ce qui limite rapidement les possibilités). Il faudra donc se contenter de jeux sur émulateurs (la suite RetroArch est disponible) ou de jeux pouvant fonctionner correctement sans accélération.

Des jeux qui fonctionnent tout de même très bien sans accélération 3D

A priori, il vaut mieux réserver Haiku aux utilisateurs les plus enthousiastes et prêts à accepter ces limitations, ainsi qu’aux développeurs dont les applications pourraient venir utilement compléter l’offre disponible.

Aller plus loin

  • # Logo

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Ah c'est une bonne idée d'avoir mis le logo, mais il y a une version pour les fond blancs qui fonctionnera probablement mieux pour Linuxfr: Logo Haiku pour fond blanc

  • # Coquille

    Posté par  . Évalué à 4. Dernière modification le 10 juin 2020 à 08:42.

    "la simplification l’expérience utilisateur" ->
    "la simplification de l’expérience utilisateur"

    "l'expérience utilisateur", tout comme "le champ des possibles" et autres expressions à la mode 2.0, ne veut pas dire grand chose. Il vaudrait mieux parler d'ergonomie.

    • [^] # Re: Coquille

      Posté par  . Évalué à 3.

      une autre:

      C’est la partie qui demande probablement le plus de travail, suite au choix de ne pas réutiliser le noyau Linux qui aurait directement la plupart des pilotes nécessaires.

      qui aurait permit d'utiliser directement

    • [^] # Re: Coquille

      Posté par  . Évalué à 3.

      et celle-ci : « un divergence simplifiée » → « une divergence simplifiée »

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Intéressant

    Posté par  (site web personnel) . Évalué à 6.

    Haiku m'a toujours intéressé. J'avais déjà testé en machine virtuelle et beaucoup aimé. J'aimerais bien savoir ce qu'il en est du système de son sous Haiku et si un jour on pourrait l'imaginer idéal pour une station de MAO.

    L'audio sous Linux est probablement la plus complexe couche et je meurs d'envie d'avoir un autre système libre où il sera plus simple d'utiliser un DAW comme Ardour sans avoir à gérer PulseAudio/Jack1/Jack2/Alsa :)

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Intéressant

      Posté par  . Évalué à 5.

      L'audio sous Linux est probablement la plus complexe couche et je meurs d'envie d'avoir un autre système libre où il sera plus simple d'utiliser un DAW comme Ardour sans avoir à gérer PulseAudio/Jack1/Jack2/Alsa :)

      PulseAudio/Jack1/Jack2/Alsa/pipewire

      ou PulseAudio/Jack1/Jack2/Alsa/ pipewire suivant si tu es optimiste ;)

      • [^] # Re: Intéressant

        Posté par  (site web personnel, Mastodon) . Évalué à 9.

        Ou PulseAudio/Jack1/Jack2/Alsa/OSS/esd/pipewire si tu es pessimiste… (et j'en ai probablement loupé quelques uns).

        Dans Haiku il n'y a que le Media Kit mais y'a encore du travail pour avoir un truc vraiment fonctionnel: la partie encodage est cassée, les drivers marchent pas partout et pas tout le temps, la latence est vraiment pas terrible, … bref c'est une version beta.

  • # Persévérance et intérêt

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Bravo pour ce projet que je trouve vraiment intéressant. Je pense que je vais pouvoir jeter un coup d'oeil…

    Quelle est la taille de la communauté ? Je trouve le travail de l'équipe impressionnant en terme de volume mais également de persévérance !

    Une idée / projection d'une date de sortie de la R1 stable ?

    • [^] # Re: Persévérance et intérêt

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Bonjour,

      D'après les statistiques sur les dépôts Git, une soixantaine de contributeurs font au moins un changement par an: http://pulkomandy.tk/stats/authors.html

      Cela dit il y en a beaucoup moins qui sont actifs de façon régulière, je pense environ une dizaine, et on peut voir par exemple qu'en 2019, un seul développeur est responsable de 42% des changements, donc il y a 2 ou 3 personnes qui font la majorité du travail (cela dit, il y a aussi des gens qui font moins de changement mais s'attaquent à des problèmes demandant beaucoup plus de temps d'investigation, par exemple).

      A ceci s'ajoute le travail sur le packaging des applications, là aussi une soixantaine de personnes environ (pas forcément les mêmes) avec une poignée de contributeurs beaucoup plus actifs que les autres: http://pulkomandy.tk/stats_hp/authors.html

      Enfin il y a toutes les personnes qui travaillent sur le développement d'applications natives, là c'est plus compliqué d'avoir des jolis graphiques, car chaque application a son propre dépôt Git.

      Je ne sais pas dire si c'est comparable à d'autres projets libres, je serais intéressé à voir ce genre de statistiques dans d'autres projets. Peut être que je devrais faire un journal sur repostat, l'outil qui sert à les générer et dans lequel j'ai du mettre les doigts pour corriger quelques soucis.

      Pour l'instant le nombre de rapports de bugs ouverts dans la version R1 continue d'augmenter, il est donc difficile de projeter une date. Cependant il est possible d'utiliser les versions beta qui sont déjà plutôt stables même s'il y a des problèmes connus, en attendant.

      • [^] # Re: Persévérance et intérêt

        Posté par  . Évalué à 2.

        2 ou 3 personnes qui font la majorité du travail

        Ou plus exactement "2 ou 3 entitées" car parfois c'est un "chef" qui push le travail d'une petite équipe derrière.

        Je sais qu'historiquement, Haiku était principalement soutenu par une société éditrice d'un logiciel de MAO disponible que sous Haiku (dans un boitié préinstallé)…

        • [^] # Re: Persévérance et intérêt

          Posté par  (site web personnel, Mastodon) . Évalué à 10.

          Non, 2 ou 3 personnes, dont moi-même et deux autres que je connaît personellement (les noms sont dans les pages de statistiques que j'ai liées).

          On a effectivement travaillé avec TuneTracker Systems (qui utilise toujours Haiku), et un peu avec iz mais je ne sais pas s'ils ont finalement migré de BeOS à Haiku ou à autre chose. En tout cas, aucune des deux n'a les moyens actuellement d'avoir un petite équipe qui contribue à Haiku, et on a des contacts directs avec les développeurs (on assure le support comme on peut pour qu'ils puissent continuer à utiliser Haiku).

          De là à dire que Haiku est soutenu… ça doit se compter en centaines de dollars sur 20 ans, ça fait pas cher le soutien. On aurait pu facturer bien plus un vrai contrat de support.

          • [^] # Re: Persévérance et intérêt

            Posté par  (site web personnel) . Évalué à 3.

            Pas mal ce que fait TuneTracker Systems. Mais très cher ! :-)
            Est ce quelqu'un a eu la chance de jouer avec ? Comment ça se compare à Rivendell qui est aussi un outil complet de gestion de radio, mais libre et sous Linux ?

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Persévérance et intérêt

        Posté par  . Évalué à 2.

        Je ne sais pas dire si c'est comparable à d'autres projets libres, je serais intéressé à voir ce genre de statistiques dans d'autres projets.

        Tu as open hub qui fait ce travail.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Persévérance et intérêt

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          Ouais, "données collectées il y a 9 mois", et ça rentre pas autant dans les détails. Et il y a aussi des soucis avec les gens qui changent d'adresse mail qui ne sont pas forcément correctement identifiés (avec repostat j'ai un fichier mailmap pour rattraper ça), et sur un projet qui existe depuis bientôt 20 ans, il y a forcément des gens qui ont changé d'adresse une fois ou deux en cours de route.

          Les stats pour FreeBSD sont assez clairement incorrectes, aussi:
          https://www.openhub.net/p/freebsd (écrit principalement en C++? Pas de code ni de contributeurs avant 2020?)

          Et puis aussi y'a des watermarks sur tous les graphes :)

  • # Intérêt

    Posté par  . Évalué à 2. Dernière modification le 10 juin 2020 à 12:52.

    Il ne faut sans doute pas s'attendre à ce qu'un jour l'OS soit disponible avec beaucoup de logiciels intéressant. Je ne pense pas que l'intérêt soit là.
    Par contre le véritable intérêt (bien que relativement faible) est, si vous n'avez pas un besoin de logiciels non disponible (dont le navigateur internet ;) ) c'est d'avoir un PC sans virus (qui n'a pas besoin d'antivirus). L'hétérogénéité est une bonne sécurité minimal même si bien sûr, c'est sans doute pas l'OS le plus testé… Il y a sans doute des failles, et des failles relativement simple a exploiter mais probablement aucun virus ne les exploitent.

  • # Vingt mois

    Posté par  . Évalué à 1.

    J'avais lu "vingt ans après la première version", et ça ne m'avait même pas fait tiquer ;-)

    • [^] # Re: Vingt mois

      Posté par  . Évalué à 5. Dernière modification le 10 juin 2020 à 21:47.

      En même temps, le but est de reproduire les fonctions de BeOS 5.0.3, sorti en 2000.
      Ça fait bien 20ans depuis la version d'inspiration!

  • # Il y a actuellement un flou assez important sur ce qui vient après cette version R1

    Posté par  (site web personnel) . Évalué à 5.

    Vivement l'intégration de systemd !

  • # Contenu du CD d'installation

    Posté par  (site web personnel) . Évalué à 2.

    Qu'est-ce qu'il y a dans le CD ? j'avais compris qu'il y aurait beaucoup plus de choses que dans les nightly. Effectivement le CD est plus gros, mais à part les manuels je ne vois pas ce qui prend tant de place.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Contenu du CD d'installation

      Posté par  . Évalué à 8.

      J'espère qu'ils vont prolonger la tradition d'espièglerie de BeOS qui dans la boite de R5 avait un CD "Installation" avec les applications et un CD "Applications" avec le programme d'installation.

      Quelle rigolade à l'époque !

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Contenu du CD d'installation

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 11 juin 2020 à 13:03.

        Toi aussi t'avais une BeBox ?

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Contenu du CD d'installation

          Posté par  . Évalué à 3.

          Dans mes rêves les plus torrides, oui.

          Dans la réalité, BeOS transfigurait mon Pentium 100 d'une machine puissante sous Windows, il faisait une station de travail fulgurante (sous Linux je m'amusais bien, mais tout était terriblement lent dès que X était lancé).

          BeOS le faisait il y a 20 ans !

          • [^] # Re: Contenu du CD d'installation

            Posté par  (site web personnel) . Évalué à 4.

            sous Linux je m'amusais bien, mais tout était terriblement lent dès que X était lancé

            c'est la Ram qui faisait la différence. J'étais sur un 486 à deux disques (le swap sur le deuxième) et 12 MB de Ram et un Cyrix P120 (90 MHz) et 16 MB de Ram : X ne ralentissait rien. Ou alors tu ne savais pas configurer ;-)

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Contenu du CD d'installation

              Posté par  (Mastodon) . Évalué à 3.

              La gui avait quand même une influence. Genre avec mon pentium 90 overclocké à 100mhz je lisait les mp3 de façon fluide avec mpg123 et pouvais faire un peu de navigation internet en même temps. Si j'écoutais la même musique sur xmms tu ne pouvais quasi rien faire d'autre.

              Mais je crois que c'était guère mieux sous les autres OS parce que j'avais justement désinstallé le windows familial parce que je le trouvais bien trop lent. J'avais testé Beos également mais revenu à linux pour la logitèque bien plus développée.

              • [^] # Re: Contenu du CD d'installation

                Posté par  . Évalué à 4.

                Sous BeOS, avec la même machine, tu aurais pu lire plusieurs MP3 en même temps sans que tes applications se mettent à devenir inutilisable à cause de leur latence.

                BeOS le faisait il y a 20 ans !

            • [^] # Re: Contenu du CD d'installation

              Posté par  . Évalué à 2.

              Effectivement, X ne ralentissait pas les applications console.
              Mais tout ce qui utilisait X était effroyablement lent : il fallait des lustres pour que e16, KDE 1 ou GNOME acceptent de se lancer (hors de WindowMaker, Icewm et éventuellement un gestionnaire de fichiers léger comme ROX Filer, tout était ultra bloated).
              Après c'est sur que GIMP tout seul tournait bien.

              Mais ne pas pouvoir utiliser une GUI de type desktop sans bouffer toute la RAM était un drôle de retour en arrière.

              BeOS le faisait il y a 20 ans !

              • [^] # Re: Contenu du CD d'installation

                Posté par  (site web personnel) . Évalué à 3.

                Mais tu parles de quelle année alors ? Le Pentium 90 est sorti en mars 1994. KDE 1.0 est sorti en juillet 1998, Enlightenment DR16 et Gnome c'est encore plus tard. On avait déjà des processeurs beaucoup plus puissants, ne serait-ce qu'en fréquence.

                Les ordinateurs avec KDE 1 c'était au moins AMD K6 à 333 MHz avec 64 Mo de Ram (je déduis ça de configs vendues toutes prêtes avec une description qui me fait penser au minimum).

                J'ai trouvé une indication de minimum qui laise rêveur : la distribution Caldera OpenLinux 2.2, sortie début 1999 avec KDE 1.1 comme interface indique 16 MB de ram et un i386 en minimum.

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: Contenu du CD d'installation

                  Posté par  (Mastodon) . Évalué à 2. Dernière modification le 13 juin 2020 à 20:06.

                  Le pentium 90 je l'ai récupéré quand mon père a upgradé, pour un athlon quelque chose. C'était donc bien plus tard. Je dirais vers 1998.

    • [^] # Re: Contenu du CD d'installation

      Posté par  (site web personnel, Mastodon) . Évalué à 7.

      En fait ce qui prend le plus de place c'est le code source qui est inclus (fourni dans /boot/sources) pour nous simplifier la vie sur la distribution de DVDs en respectant la GPL.

      La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans. Ça voudrait dire que dans 5 ans quelqu'un pourrait nous demander un DVD avec les sources de la version qu'on vient de publier maintenant. Comme on a pas envie de s'embêter avec ça, le plus simple est de mettre les sources directement sur le même DVD.

      Il y a également quelques éléments en plus: le guide d'utilisateur (traduit dans 20 langues), et quelques applications comme Wonderbrush, ainsi que tous les outils de développement préinstallés (puisque c'est une version beta qui s'adresse plus aux développeurs qu'aux utilisateurs). On a encore du travail à faire sur la gestion de ces paquets supplémentaires dans l'Installeur, on a fait une partie pour cette version mais ce n'est pas encore complètement satisfaisant (pas de gestion des dépendances, pas de regroupement des paquets par catégorie, …). Une fois fait, on pourra remplir le DVD avec plein d'applications sympa. Ou alors, on se débarasse au maximum des morceaux en GPL pour ne plus avoir à livrer autant de code source et pouvoir à nouveau tout rentrer sur un CD!

      • [^] # Re: Contenu du CD d'installation

        Posté par  (site web personnel) . Évalué à 3.

        Il y a également quelques éléments en plus: quelques applications comme Wonderbrush, ainsi que tous les outils de développement préinstallés

        Mais alors que le guide est installé, les applications ne le sont pas (ou alors bien planquées). C'est un peu bête pour ceux qui installent en machine virtuelle. On ne pense pas à remonter le DVD pour ça.

        Sinon, j'apprécie la petite taille du DVD. Ne le remplissez surtout pas !

        Quant aux sources, j'imagine que vous en avez discuté, mais garder une image iso avec les sources sur le serveur ne suffit-il pas ?

        Et pour contrebalancer ce que je viens d'écrire : merci du boulot ! j'ai enfin retrouvé les sensations de Be sur ma BeBox. C'est une belle réussite.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Contenu du CD d'installation

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Mais alors que le guide est installé, les applications ne le sont pas (ou alors bien planquées).

          Pas dans la version live car cela augmente les besoins en RAM (problèmes de performance sur lequel on doit se pencher). Elles sont installées lorsqu'on installe le DVD vers une partition sur disque, par contre.

          De façon générale le process d'installation a besoin d'être revu: pour le choix des paquets, pour le partitionnement automatique des disques, pour l'installation du bootloader EFi, et quelques autres détails. Bref, y'a encore du travail!

          Quant aux sources, j'imagine que vous en avez discuté, mais garder une image iso avec les sources sur le serveur ne suffit-il pas ?

          Non, la GPL dit bien que les sources doivent être disponibles "par le même moyen". Donc si on vend/donne des DVDs par la poste ou sur un stand au FOSDEM, les sources doivent être disponibles au même endroit, et un lien vers un serveur ne suffit pas. Problème qui a été corrigé dans la GPL3 pour autoriser spécifiquement la méthode "lien vers un serveur" cela dit, donc on pourrait peut être faire ça. Va falloir revérifier toutes les licenses du code inclus…

          • [^] # Re: Contenu du CD d'installation

            Posté par  (site web personnel) . Évalué à 2.

            Elles sont installées lorsqu'on installe le DVD vers une partition sur disque

            Pas chez moi ou vraiment bien planquées. J'ai fait mumuse avec le système de requêtes qui n'a rien trouvé non plus. Je parle de « Wonderbrush, ainsi que tous les outils de développement » qui ne sont pas sur les nightly.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

            • [^] # Re: Contenu du CD d'installation

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Ben je sais pas, ils sont dans /boot/packages dans l'image de la Beta et Installer propose une liste de "optional packages" à partir de ça pour les activer à l'installation. Il y a au moins tous les outils de dev et quelques autres trucs.

              Ah oui j'avais oublié un truc: Wonderbrush n'est pas encore disponible en 64bit, c'est peut être ça?

              • [^] # Re: Contenu du CD d'installation

                Posté par  (site web personnel) . Évalué à 2.

                Ah OK, mais alors ils sont aussi dans les nightlies. Je pensais que tu parlais d'autre chose. Pour Wonderbrush oui c'est ça, j'aurais du préciser. Désolé pour ce bruit peu utile et merci pour cette enquête.

                Je me demandais si 32 ou 64 changeait quelque chose pour le matériel supporté ? J'imagine qu'il reste des drivers disponibles que sur l'un ou l'autre ?

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                • [^] # Re: Contenu du CD d'installation

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  Il y a quelques drivers qu'on a pas pris la peine de porter en 64bit parce que la combinaison CPU 64 bit + carte graphique Ati Mach64 (par exemple) nous semblait suffisamment improbable pour justifier d'y passer du temps, et aussi parce que personne parmi les développeurs ne dispose d'une machine permettant de tester le résultat (je pourrais essayer cela dit, j'ai une carte mère avec un CPU 64bit et un port PCI et peut être quelques cartes graphiques sous la main quelque part…).

                  Pas de différence dans le cas de machines "normales", du coup.

      • [^] # Re: Contenu du CD d'installation

        Posté par  . Évalué à 1. Dernière modification le 12 juin 2020 à 22:53.

        La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans.

        t'es sûr de ça ? Parce que si quelqu'un était assez chiant pour demander ce genre de truc (clairement, si quelqu'un fait ça, c'est par volonté de vous embêter), tu ne peux pas lui dire d'aller les télécharger sur github ? Ou sinon de vous envoyez un dvd vierge avec une enveloppe réponse prétimbrée pour la gravure du dvd ? Vous pouvez les mettres à disposition, mais pas à votre dépend tout de même.

        Je trouve ça dommage de remplir de l'espace (et de grossir les téléchargement d'iso) pour rien, les sources sont disponibles sur internet, c'est bien suffisant

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

        • [^] # Re: Contenu du CD d'installation

          Posté par  (site web personnel) . Évalué à 3.

          les sources sont disponibles sur internet, c'est bien suffisant

          Non, quand tu utilises une license que tu comptes faire respecter, tu es obligé toi-même de la respecter. C'est du droit. On va aller un peu loin, mais tout le monde connaît l'exemple de la police qui doit respecter la loi pour la faire respecter, sinon elle risque d'avoir des procédures annulées (ce qui arrive de temps en temps).

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Contenu du CD d'installation

            Posté par  . Évalué à -2.

            mouais, déjà il faudrait voir si ça s'applique exactement dans le cas qui nous concerne, ensuite, si ça ne serait pas suffisant, comme j'ai dit plus haut, d'indiquer à l'attention des 3 pelés qui vont vouloir "appliquer leur droit à disposer des sources au format DVD" au lieu de les télécharger sur internet comme tout le monde, d'envoyer à leur frais et avec l'affranchissement retour, un DVD vierge pour permettre de réaliser ça.

            Mais sinon, continuez à rajouter plusieurs centaines de Mo de sources "inutiles" dans les téléchargements et de contribuer à tuer des bébés phoques avec le réchauffement climatique, si ça peut faire plaisir aux intégristes de la GNU GPL :D

            « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

            • [^] # Re: Contenu du CD d'installation

              Posté par  (site web personnel) . Évalué à 5.

              Je viens de t'expliquer que c'est une question juridique et tu réponds «si ça peut faire plaisir aux intégristes de la GNU GPL» ! C'est pourtant simple : si un jour Haiku doit porter plainte contre quelqu'un qui ne respecterait pas la license, il vaut mieux qu'Haiku n'ait rien à se reprocher à ce niveau.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Contenu du CD d'installation

                Posté par  . Évalué à 3.

                oui, c'est une, voire des questions juridiques qui méritent d'être posées :

                • est-ce que c'est bien nécessaire de faire comme il a été dit ("si on distribue un dvd, il faut distribuer les sources sur DVD et non pas sur internet") : est-ce que la loi (française) est claire à ce sujet, ou est-ce que c'est une règle ou une directive qui a juste été donnée par les juristes américains de la FSF ? Est-ce que ça peut être interprété autrement ? Le commentaire plus haut de Jehan semble aller dans le sens que je disais : en bref, ça n'est plus d'actualité.

                • il y a aussi la jurisprudence. Que les tribunaux français puissent condamner une entreprise qui piétine la GNU GPL parce que les sources sont restées occultées, ça s'est vu (et c'est tant mieux), que quelqu'un puisse attaquer Haiku sur une base aussi faible (au cas où le point évoqué plus haut ne serait pas suffisant), c'est impensable. Je vois mal un juge accorder du crédit à un clampin qui viendrait attaquer Haiku parce que les sources sont seulement dispo sur internet et pas sur le dvd, et qu'on lui demande 28 € pour lui fournir les sources sur un support amovible.

                • et il y a aussi l'interprétation qu'en font les gens. Quelqu'un m'a envoyé un email parce qu'il estimait que j'avais violé la GPL sur un dépôt github, et il m'intimait l'ordre de me "mettre en conformité". Mais son interprétation était erroné, et il n'est pas allé bien loin dans sa démarche.

                « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Contenu du CD d'installation

            Posté par  (site web personnel, Mastodon) . Évalué à 10.

            La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans.

            C'est pas 5 ans, mais 3 ans. Ce n'est pas "par le même moyen" mais "par un moyen habituel d'échange de données logicielle" (cela pourrait être une clé USB de nos jours):

            on a medium customarily used for software interchange

            Personnellement je pourrais même lire qu'un lien sur internet est aussi un medium habituel pour l'échange de données logicielle de nos jours mais la FAQ gnu.org a un item spécifiquement sur le sujet qui dit en effet qu'on doit envoyer un média physique (notez bien que là non plus, ils disent pas que ça doit absolument être le même) si c'est explicitement demandé.

            Notez que cette histoire de 3 ans est seulement dans le cas d'une distribution du binaire sans les sources côte à côte. Donc pour une distribution physique sans les sources, c'est vrai. Mais si tu diffuses par un site web, et que sur le même serveur, le fichier à côté de l'exécutable est celui des sources, tu peux arrêter du jour au lendemain de distribuer les 2 ensemble.

            Enfin tout cela est vrai seulement pour la GPL2. Pour la GPL3, le cas spécifique d'une distribution physique est listé et indique que tu peux accompagner le média d'une note écrite qui donne accès à une copie des sources en ligne, du moment qu'il n'y a pas de frais additionnel pour le demandeur. Tu n'es plus obligé d'envoyer un autre média physique. Par contre l'histoire des 3 ans reste pour ce cas spécifique (ça me paraît logique, ça évite la vente abusive de logiciels libres avec une personne qui disparaît une semaine après et dit "ah bah la distribution est fini, trop tard pour demander les sources).

            Clairement cela s'adapte à l'ère du temps. Au temps de la GPL2 (écrite en 1991!), Internet était beaucoup moins commun (et plus cher) et imposer d'avoir internet pour récupérer des sources, c'était un bon moyen pour ne pas avoir à les donner à la majorité des gens. Donc je pense que c'est pour cela que cette ancienne version imposait de pouvoir les envoyer physiquement aussi (j'étais très loin de ce milieu à l'époque, mais de ce que je connais, s'échanger des programmes par média physique était chose courante). Avec la GPL3 (2007), ils se sont mis au goût du jour, car donner un moyen dématérialisé de transfert est devenu parfaitement acceptable, même pour le grand public.

            Vous pouvez les mettres à disposition, mais pas à votre dépend tout de même.

            Si tu diffuses par média physique, tu dois en effet aussi pouvoir fournir le code par média physique avec la GPL2. Mais comme le dit Zurvan, ce n'est en effet pas à ses dépends pour autant. Tu as le droit de demander de payer des frais pour l'envoi. Ensuite ces frais doivent être considéré "raisonnables pour le fait d'envoyer physiquement les sources". Plus précisément en anglais:

            Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code

            Donc de nos jours, ça voudrait dire re-facturer la clé USB (j'ai pas de graveur CD/DVD et je pense pas que beaucoup en ont encore de nos jours) et les frais de poste, au minimum. Ensuite si ça me prend un peu de mon temps (faire la copie: 15 min, aller à la poste: 30 min, aller dans une boutique acheter une clé: 30 min), je pense qu'il est raisonnable de facturer le temps perdu (pas de manière exubérante, genre rajoutez pas 500€ de travail humain, même si c'est peut-être vraiment votre valeur sur le marché du travail; mais mettre +25€ ne me paraît pas aberrant).

            Bon c'est mon interprétation. Faudrait demander à la FSF si ça rentre bien dans ce qu'ils appellent "your cost of physically performing source distribution"; moi ça me paraît raisonnable. Et devant un juge, je pense que l'intention rentre en compte. C'est à dire que si vous offrez aussi un lien dématérialisé facilement accessible, mais qu'une personne insiste absolument pour avoir une version physique, bon vous vous pliez à la demande, car c'est dans la licence choisie. Mais dans ce cas où vous perdez une heure de votre vie, rajouter quelques sous (pas grand chose, juste de quoi faire un bon repas; surtout peut-être comparé à votre salaire, ça dépend des cas) en plus du prix du support physique et de l'envoi, faudrait vraiment tomber sur un mauvais juge pour ne pas considérer que ça rentre dans "le coût pour un envoi physique".

            Ensuite, je rappelle, c'est GPLv2 seulement. La GPLv3 n'a pas cette restriction et le lien internet marche parfaitement même si vous distribuez en média physique.

            Enfin je pense qu'intégrer les sources dans le CD/DVD (si on veut absolument envoyer un logiciel par ce moyen dépassé!) reste de toute façon la vraie bonne chose à faire dans l'esprit de cette licence. Envoyer un logiciel libre en binaire seulement me paraît à l'antithèse de ce qu'est le logiciel libre et sa compréhension.
            Enfin sans moyen simple d'accéder aux sources, j'entends; insérer juste une note avec un lien qui va vraiment rester pour télécharger les sources me paraît tout à fait raisonnable (en fait même mieux, si en plus d'avoir accès à la version figée des sources, ça m'indique aussi où trouver la version en développement pour récupérer les sources les plus récentes). En gros, l'idée est qu'on ne doit pas entraver l'accès aux sources en rendant cela plus difficile que cela ne pourrait l'être. Si on fait cela, ça veut en général dire que c'est pas vraiment du logiciel libre qu'on veut faire.

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Contenu du CD d'installation

              Posté par  . Évalué à 3.

              Bon c'est mon interprétation. Faudrait demander à la FSF si ça rentre bien dans ce qu'ils appellent "your cost of physically performing source distribution"; moi ça me paraît raisonnable.

              Je ne suis pas un juriste, mais j'ai lu et relu les GPL depuis longtemps, et je suis d'accord avec ton interprétation, comme le reste de ce que tu dis dessus dans les autres commentaires.

              (je ne sais pas si mon commentaire t'es utile, mais voilà, t'es pas tout seul)

        • [^] # Re: Contenu du CD d'installation

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Alors il y a une petite erreur: c'est 3 ans et pas 5. Mais sinon oui, c'est écrit clairement dans la license:

          1. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

          a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

          b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

          c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

          Dans cette version, on a la section a (ce qu'on fait actuellement: donner les sources sur le même DVD), la section b (distribution physique, sur un "medium" des sources pendant 3 ans après la publication de chaque version, et donc non, un lien vers un serveur git ne suffit pas) et la section c (laisser les gens qui ont écrit le code GPL qu'on utilise se débrouiller, mais il faut quand même donner les infos aux gens sur comment récupérer les sources, et c'est interdit en cas de vente commerciale comme c'est peut-être le cas pour nos DVD).

          Dans la GPL 3 c'est devenu un peu plus spécifique:

          1. Conveying Non-Source Forms.

          You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

          a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

          b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

          c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

          d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

          e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

          Même principe pour les sections a et c. La section b est un peu reprécisée et moins restrictive: s'il y a distribution des binaires sur un support physique (c'est le cas de notre DVD), il faut que les sources soient disponibles par le même moyen ou via un serveur. Il faut quand même faire une offre écrite à ce sujet et y'a pas la place pour ça sur la pochette du DVD. Les sections d et e sont ajoutées pour la diffusion de binaires via des moyens en ligne (téléchargement depuis un serveur et p2p).

          Donc, oui, on peut dire "ouais, bon, ça vaaaa, personne va se plaindre si on le fait pas". Mais comme la FSF classe Haiku dans sa liste de "ça pue c'est pas libre", qui contient aussi des distros Linux louches comme Arch, CentOS, Debian, Fedora, Mandriva, Manjaro, OpenSUSE, RedHat, Slackware, Tails, Ubuntu; et tous les BSD, on a envie d'être un peu procédurier et de dire que c'est leur faute, tout ça.

          Sur le long terme, le plan est de se débarasser petit à petit des morceaux sous license GPL pour ne plus avoir ce genre de contrainte. Ceci par plusieurs moyens:
          - Remplacement du code par des alternatives (par exemple des morceaux de la glibc par des morceaux de musl ou de FreeBSD, en faisant attention de rester compatible au niveau binaire avec BeOS). On prévoit de faire ça également pour le driver NTFS (remplacer ntfs-3G par la version de Apple, remplacer bash peut-être par mksh ou zsh, …)
          - Contacter les auteurs pour leur demander un changement de license (pour ProcessController, MediaPlayer, l'implémentation de ReiserFS et du RAM-FS, par exemple)
          - Réécrire les derniers morceaux qui resteront, le cas échéant.

          Ceci dit ce n'est pas la première priorité dans le projet non plus, et ça se fait petit à petit en profitant d'autres raisons (par exemple, le travail sur les versions sparc et arm64 qui demande de pas mal toucher à la libc de toutes façons)

          • [^] # Re: Contenu du CD d'installation

            Posté par  (site web personnel, Mastodon) . Évalué à 6.

            Il faut quand même faire une offre écrite à ce sujet et y'a pas la place pour ça sur la pochette du DVD.

            Quand je lis "written offer" (offre écrite), je comprends que faire cette offre dans un fichier à l'intérieur du DVD (typiquement un fichier README/LISEZMOI, voire carrêment un nom bien explicite genre LINKS_TO_SOURCES, à la racine du DVD avec toutes les infos) serait aussi acceptable. "Offre écrite", pour moi, ne signifie pas "sur papier obligatoirement".

            Ensuite même si c'était vraiment là l'esprit de la licence (genre si le support est physique, alors l'offre écrite doit l'être aussi), une ligne ("Les sources de tous les logiciels sont disponibles sur ce lien:") avec une URL me paraît quand même pas insurmontable même pour une petite pochette CD.

            on a envie d'être un peu procédurier et de dire que c'est leur faute, tout ça.

            Pour être tout à fait juste, la GPL2, c'est une époque (1991) où internet est réservé soit au milieu académique, soit aux gens très riche. Moi je sais qu'à l'époque, j'étais loin de l'un comme de l'autre (et ma famille n'était pas du milieu informatique du tout non plus) et donc si j'obtenais un logiciel (sur disque à l'époque, et si j'avais un ordi, ce qui n'était même pas le cas) et qu'on me donnait un lien internet pour récupérer les sources, c'était comme si on m'avait rien donné.

            Mes premiers contacts avec internet, c'était vers le dernier tiers des années 90 quand un pote m'introduit au club info au lycée. Ce même pote avait déjà internet chez lui, mais justement il était d'une famille très aisée d'ingénieurs et chefs de grosses entreprises. Comme ma famille était quand même relativement dans une bonne moyenne financière, on a nous même eu internet un peu plus tard, je pense vers la toute fin des années 90, un peu avant 2000 (et à l'époque, on installait des logiciels pour compter les MiB téléchargés car on avait des abonnements avec quota super restreints; j'aurais pas téléchargé des centaines de MiB de code source même si j'avais un lien, même à cette époque). Les familles de mes potes moins à l'aise ont eu internet des années après.

            Clairement cette restriction (qui peut paraître absurde de nos jours) a vraiment un sens dans le contexte de l'époque et dans l'esprit de la GPL (qui est vraiment pas juste "on peut dans la théorie avoir accès aux sources, mais ahah c'est juste un leurre"). L'idée est que quand on dit qu'on a accès aux sources, il faut que ce soit vrai dans une mesure raisonnable (c'est à dire, on vous fait payer l'envoi en plus, mais rien d'insurmontable).

            Ensuite ils ont bien vu que cette restriction est devenue déraisonnable dans un monde où il est de plus en plus courant d'avoir accès à internet en haute vitesse (et même si vous faites partie des gens pour qui ce n'est pas le cas, il est simple de nos jours de payer un peu, genre cyber-café, pour avoir cet accès temporairement, ce qui équivaut à payer des frais pour un envoi physique). Donc ils ont juste mis à jour pour GPLv3 en rendant la restriction plus souple (plus d'obligation d'envoi sur support physique).

            Tout ça pour dire que dire que "c'est leur faute" me paraît un peu injuste. Ils sont juste très attachés à faire respecter l'esprit de la licence. Il est vrai que d'autres licences ne précisent rien de tout ça, voire ne demandent même pas forcément la livraison du source (il est possible de ne livrer que des binaires). Bon ben toujours la même histoire, c'est la différence entre les licences permissives et copyleft. Ces derniers sont en général plus attaché à la signification derrière la diffusion en logiciel libre. Pour aller au delà du théorique "vous avez le droit (mais on va tout faire pour que ça soit un parcours du combattant si vous essayez d'utiliser votre droit)", ben ils ont ajouté des restrictions à ce que veut dire de donner ce droit aux gens. Pas juste des mots jetés en l'air histoire de dire qu'on fait du logiciel libre. Perso j'aime bien. 🙂

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Contenu du CD d'installation

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Un peu plus sérieusement, ce qui m'embête dans la GPL c'est surtout que la license est longue et que finalement peu de gens (même ici!) prennent le temps de la lire. La preuve, chaque fois que je parle de ce genre de détails, on me dit "mais t'es sûr de ça?".

              Je trouve ça dommage parce que du coup c'est facile de louper un truc dans cette license assez longue et riche en subtilités. Il me semble d'ailleurs que l'une des personnes qui a beaucoup travaillé sur la rédaction de la GPL 3 n'est pas d'accord avec la FSF sur l'interprétation de certaines parties du texte…

              Cette complexité fait aussi que, forcément, la license se retrouve moins adaptable au cours du temps, comme tu le dis, internet en 1991 c'était très différent d'aujourd'hui et une license qui rentre autant dans les détails ne pouvait pas tout prévoir.

              Le résultat c'est que chaque paragraphe pose beaucoup de questions (c'est quoi un "medium"? est-ce que le "coût de la reproduction physique" implique que la reproduction est forcément sur un support physique, ou bien est-ce qu'un lien de téléchargement suffit? et ainsi de suite). Et on parle juste d'un tout petit morceau de la GPL, je trouve que le reste est à peu près du même genre. Du coup il faut ensuite aller lire la FAQ de la FSF pour des informations complémentaires, etc.

              Ces raisons font que je n'aime pas beaucoup la GPL, même si je n'ai pas grand chose de mieux à proposer pour une license copyleft. Mon approche est plutôt d'utiliser une license permissive et de convaincre les gens de l'intérêt de publier les sources (facilité de maintenance, aide de la communauté pour le développement, etc) et je pense qu'une license comme la GPL n'est pas nécessaire. Mais cela dépend des projets, c'est facile par exemple pour Haiku ou on a pas vraiment (pour l'instant, et à ma connaissance) de Grand Méchant Microsoft ou je sais pas quoi qui viendrait nous piquer nos sources pour faire un truc sans rien publier. Il y a des cas ou la protection apportée par la GPL est utile, et c'est peut-être ça aussi qui a permis de populariser le logiciel libre et de montrer que c'est un modèle qui fonctionne.

              • [^] # Re: Contenu du CD d'installation

                Posté par  . Évalué à 3.

                Existe-t-il des licences de logiciels libres à copyleft qui essaient d'être simples ?

                C'est vrai que comparé au tour de force de concision de la Free Software Definition, la GPL2 paraissait bien verbeuse et la GPL3 c'est pire.

                BeOS le faisait il y a 20 ans !

              • [^] # Re: Contenu du CD d'installation

                Posté par  (site web personnel, Mastodon) . Évalué à 7.

                Un peu plus sérieusement, ce qui m'embête dans la GPL c'est surtout que la license est longue

                J'écris plus en code (et en commentaires sur Linuxfr!) tous les 2/3 jours! Franchement c'est pas long, faut arrêter avec la légende (le texte de la GPLv3: https://www.gnu.org/licenses/gpl-3.0.en.html). N'importe quel contrat pour n'importe quelle connerie qu'on signe de nos jours est plus long que ça (et je les lis aussi, ces contrats, avant de les signer; par contre les trucs internet sont souvent aberrants, genre la taille d'un roman!).

                et que finalement peu de gens (même ici!) prennent le temps de la lire. La preuve, chaque fois que je parle de ce genre de détails, on me dit "mais t'es sûr de ça?".

                C'est pas une preuve. Des gens disent la même chose quand on parle des licences BSD. Ils les lisent pas plus et pourtant c'est quelques lignes.
                En fait c'est juste que plein de gens vont simplement jamais lire ces textes de licences parce qu'ils trouvent ça rébarbatifs par principe (de même que beaucoup de gens ne lisent jamais les contrats qu'ils signent).

                Pour aller plus loin, les forums sont pleins de gens qui comprennent pas comment marche le droit d'auteur de manière générale (en fait très peu de personne semble même comprendre la base de la logique de ce droit), et qui posent des questions sur même les licences très courtes genre les variantes BSD, voire même MIT.

                Je trouve ça dommage parce que du coup c'est facile de louper un truc dans cette license assez longue et riche en subtilités. Il me semble d'ailleurs que l'une des personnes qui a beaucoup travaillé sur la rédaction de la GPL 3 n'est pas d'accord avec la FSF sur l'interprétation de certaines parties du texte…

                C'est le propre des contrats. C'est justement pour cela que les gens essaient de les rendre plus longs et détaillés, pour essayer de retirer les différences d'interprétation en retirant les incertitudes. Mais quoiqu'on rajoute, il reste toujours des incertitudes (car y a une infinité de trucs possibles dans le monde).

                Tu crois qu'y a aucun désaccord d'interprétation sur les licences BSD ou MIT? Franchement quand je lis leur texte, y a plusieurs trucs qui sont vraiment sujets à interprétation. Par exemple dans la BSD 4-clauses, quand on demande l'ajout d'une phrase "This product includes software developed by the <organization>" sur les divers documents mentionnant des fonctionnalités ou le logiciel, jusqu'où va-t-on pour caractériser l'usage du logiciel donné dans un système plus large? C'est super vague. Que rentre-t-on dans les "advertising materials"? Ça peut aussi être potentiellement super large. Et puis faut-il que ce soit vraiment écrit dessus de manière proéminente, ou cela peut-il être mentionné en minuscule, limite illisible?

                Quant à la 4ème clause (ou 3ème clause sur la version 3 clause), jusqu'où va-t-on considérer que la mention du nom d'un développeur peut impliquer le soutien de ce dernier? D'ailleurs même la 3ème et 4ème clause ensemble peuvent potentiellement être très antithétique. On est obligé de nommer les auteurs, d'une façon donnée, quand on mentionne le logiciel sur du matériel promotionnel mais tout en faisant gaffe que ça ne donne pas l'impression que ces derniers soutiennent. Ex: X fait un logiciel générique, qui est utilisé dans un système logiciel plus large et une affiche promotionnel parle de ce système et décide de faire les choses bien en ajoutant "This product includes software developed by X". Sincèrement malgré la phrase assez neutre, c'est assez dur de pas donner l'impression que X soutient ce projet.

                Et puis le texte principal des diverses BSD (qui dit en gros "quoiqu'il arrive, c'est pas ma faute"), ben ça pose en fait plein de question sur la réalité dans les diverses circonscriptions légales. En gros, c'est pas parce qu'on l'écrit que c'est vrai en fonction de la loi du territoire. Et puis en plus si jamais c'est un logiciel écrit sous contrat, c'est pas parce qu'on a écrit "c'est pas ma faute" dans son code que ça ne le sera vraiment pas le jour où y a un problème.

                Même la licence MIT, super courte, pose des questions sur le peu écrit. Une question assez courante que j'ai lu sur divers forums est au sujet de cette phrase:

                The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

                Mais qu'est-ce qui est considéré une portion "substantielle"? Est-ce déjà substantiel dès quelques lignes? Un demi fichier? Si c'est une reprise d'une logique importante du code (vs. du code important en taille mais finalement plutôt basique en logique)?

                La raison pour laquelle je me pose moins de questions (comme pour beaucoup de gens), c'est l'expérience. À force des années (et des cas en justice dont j'ai eu vent, etc.), on comprends un peu ce que veulent dire les diverses parties d'une licence, on voit comment les autres utilisent ces licences, ce qu'on peut ou doit faire ou non, etc.
                Aussi clairement pour ceux qui ont choisi les licences permissives, il y a clairement tout un aspect "finalement j'abandonne, je vais rien faire même s'il y a violation de licence". Donc c'est pas que les gens comprennent mieux ces licences, c'est qu'on sait que ceux qui ont choisi ces licences vont rarement essayer de faire respecter leur droit.

                Mon approche est plutôt d'utiliser une license permissive et de convaincre les gens de l'intérêt de publier les sources […]

                En fait tout le reste de ton commentaire se résume à cette phrase de toi. Y a d'un côté ceux qui pensent qu'il faut protéger la liberté du code avec des règles claires, et ceux qui (comme toi, semblerait-il) sont plutôt fatalistes et décident qu'on y peut rien, c'est trop compliqué, donc laissent tomber le côté légal et essaient à la place de convaincre.

                Il n'y a pas vraiment de bon ou mauvais choix. Ce sont deux approches différentes. Perso je suis plus copyleft car je trouve que les gens s'en foutent du libre et si je régule pas mes règles par la licence, alors rien va se passer. J'ai arrêté d'essayer de "convaincre" les gens du libre. Je fais du libre de mon côté car je considère que c'est la chose à faire et que le code se doit d'être libre, mais si les gens veulent faire du propriétaire, grand bien leur fasse. Ils le feront pas avec mon code, c'est tout. Au moins avec la GPL, j'ai pas à les convaincre de faire du libre ou de ne pas faire du propriétaire avec mon code. J'ai clairement édicté les règles en en-tête de chacun de mes bouts de code donc tout est clair et net dès le début.

                Néanmoins je considère les licences permissives meilleures à terme, ou pour être plus clair, je pense que dans le futur idéal, on aurait plus à se faire chier avec des licences tout court. Tout serait libre par défaut, et chacun peut utiliser le code de tous sans suer. Faut arrêter avec tout cet égo comme si notre code à chacun était si fabuleux. Mais bon en attendant d'arriver à ce futur idyllique où les gens remettent enfin les pieds sur terre (ahahah on peut rêver! 🤣), ben je mets le code sous GPLv3 (ou mieux AGPL). Comme ça justement pas besoin de "convaincre".

                Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                • [^] # Re: Contenu du CD d'installation

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Il y a d'autres petits trucs du même genre dans les licenses MIT et BSD en effet (je ne crois pas avoir dit le contraire).

                  D'autres exemple:

                  Il y a une permission de "sublicense", et ce mot n'est pas clair. Est-ce que ça permet de mettre le même code sous une license qui donne moins de droits?

                  La license nécessite que toute redistribution du code inclue "le texte de la license et la notice de copyright ci-dessus". Le "ci-dessus" est pénible parce qu'on ne peut pas séparer la license de la notice de copyright. Et du coup, impossible d'avoir un seul fichier "license MIT" utilisable par plusieurs bouts de code utilisant la même license mais avec des copyrights différents (le problème se pose dans Haiku pour les paquets d'applications, qui se contentent de préciser LICENSE="MIT", le texte de la license étant fourni par ailleurs mais pas inclus verbatim dans le paquet).

                  Au final il n'y a peut être que la WTFPL qui arrive à éviter tous ces problèmes, forcément.

                • [^] # Re: Contenu du CD d'installation

                  Posté par  (site web personnel) . Évalué à 3.

                  J'ai arrêté d'essayer de "convaincre" les gens du libre. Je fais du libre de mon côté car je considère que c'est la chose à faire

                  Pareil.
                  Je crois que peu de gens se sentent concernés par « les choses ». C'est pourquoi ils ne s'impliquent pas dans les projets ou les assos, préfèrent ignorer les contraintes (lire les contrats ou les licenses, comprendre les privations de libertés, …) et ne voient pas la nécessité de réfléchir ou sortir des sentiers battus (mettre en license libre, chercher autrement, découvrir, …). Tout ça c'est un peu la même façon d'être et la plupart des gens font les autruches consommatrices. Va savoir si c'est un trait humain ou culturel ?

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Amusant que Haiku soit le seul survivant

    Posté par  . Évalué à 5.

    Amusant que Haiku soit le seul survivant: quand BeOS est mort, l'idée naturelle était de faire un clone de BeOS au dessus de Linux ou d'un BSD, mais le seul clone de BeOS qui reste part d'un "nouveau" noyau.

    Plusieurs explications possible, soit:
    1) seul le fait de repartir du début est assez motivant pour fidéliser des développeur.
    Même si d'un point de vue technique c'est sous-optimal (20 ans pour recréer BeOS..).

    2) l'utilisation de Linux/*BSD induit beaucoup de choix possible sur la réutilisation ou non de l'existant (au dessus de X11? sans X11?) qui fragmente et donc fragilise cette option.

    3) la faute a pas de chance.

    Je me souviens d'un projet de ré-implémentation au dessus de Linux qui avait commencé a prendre puis est mort: le nombre de développeur ayant le temps et les capacités pour travailler sur un projet de ce type étant très faible, un seul projet mort a peut-être suffit à tuer l'option BeOS/Linux.
    Après cette explication est peu satisfaisante car rien n’empêchait de forker le projet pour le continuer.

    • [^] # Re: Amusant que Haiku soit le seul survivant

      Posté par  . Évalué à 3.

      Je crois que beaucoup de projets ne reprenaient que l'aspect graphique de BeOS, là on parle aussi des binaires. Il aurait fallu créer un projet BINE (Bine Is Not an Emulator) ;-).

      Une des particularité de BeOS était une excellente gestion de processus en multi-CPU (le multi-cœur n’existait pas encore), bien meilleurs que Windows ou Linux de l’époque.

      BeOs est codé en C++, ce qui une fois fini la mise au point pourra profiter des normes récentes. Je ne sais pas si c’est un objectif, mais je trouve ça bien.

      • [^] # Re: Amusant que Haiku soit le seul survivant

        Posté par  . Évalué à 2.

        Une des particularité de BeOS était une excellente gestion de processus en multi-CPU (le multi-cœur n’existait pas encore), bien meilleurs que Windows ou Linux de l’époque

        Pas si sûr que c'était une force du kernel de BeOS: pour moi, c'était plutôt les API qui poussaient les développeurs a utilisé le multithreading + que sous les autres OS.
        Et même si c'était oe cas: qu'est-ce qui est plus facile : adapter le scheduler de Linux pour ses besoins (en espérant l'intégrer au noyau à (long) terme) ou réécrire un OS?

        Sinon d'accord avec toi qu'il aurait fallu avoir l'équivalent de Wine pour Be.

        • [^] # Re: Amusant que Haiku soit le seul survivant

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Il y a les 2: les APIs qui forcent à faire plusieurs thread et à partager peu de mémoire entre eux (via l'utilisation de BMessage pour envoyer des messages d'un thread à l'autre), et le scheduler qui savait en 2001 gérer plusieurs CPUs.

          La conception est assez particulière et liée aux contraintes matérielles de la BeBox au départ. Sur la BeBox, il fallait invalider le cache de chaque CPU à la main pour assurer la synchronization (car le CPU choisi n'était pas prévu pour fonctionner en multi processeur). Du coup, grosse perte de performance dès que de la mémoire était partagée entre deux CPUs, et donc une API essayant de limiter les cas où ça se produit.

          Est-ce que c'est possible de faire la même chose dans Linux? Oui, certainement. BlueEyedOS l'a montré et il se défend bien d'un point de vue des performances. Mais les priorités de Linux ne sont pas les mêmes. Aujourd'hui, Linux fait des choix plutôt orientés vers les gros serveurs qui vont traiter des milliers de requêtes réseau en parallèle. Ils font des compromis différents, et il n'est pas évident que des patches pour changer ça soient bienvenus.

          Surtout, ce serait facile si ça se limitait au scheduler. Dans Haiku, le principal endroit ou ça se joue, c'est en fait sur la priorisation des accès au disques. Si tu as un truc qui fait plein de gros accès disques (mettons, tu es en train de copier plein de photos et vidéos), il faut faire en sorte que ces accès n'occupent pas le disque trop en continu et soient mis en priorité plus basse, afin que des demandes plus ponctuelles (lancement d'une application qui doit être chargée depuis le même disque) puissent être traitées rapidement. C'est un sujet sur lequel on a encore du travail à faire. La solution actuelle essaie de minimiser les mouvements de la tête de lecture du disque dur, mais le matériel a bien changé depuis: bien sûr avec les SSD qui n'ont pas cette contrainte, mais même pour les disques classiques, qui ont une mémoire cache relativement importante en interne et donc il faut gérer les choses différement pour en tenir compte.

          Et dans les utilisations modernes, il y aurait probablement beaucoup à faire pour les aspects réseau, en gérant de la QoS entre différentes applications. Pour pas que le téléchargement d'un gros fichier ralentisse la navigation web ou n'augmente la latence d'une connexion ssh interactive, par exemple.

          • [^] # Re: Amusant que Haiku soit le seul survivant

            Posté par  . Évalué à 4.

            Aujourd'hui, Linux fait des choix plutôt orientés vers les gros serveurs qui vont traiter des milliers de requêtes réseau en parallèle. Ils font des compromis différents, et il n'est pas évident que des patches pour changer ça soient bienvenu

            Aujourd'hui, Linux, c'est aussi Android, qui justement cherche à avoir une réactivité et introduit ses patch dans le kernel Linux. Donc, je ne suis pas sûr que les développeurs kernels soient hostiles à ce genre de patch.

            Je ne dis pas que c'est simple à écrire et qu'il faut porter Haiku sous Linux, juste que le fait que ça va être refusé ne me semble pas une bonne justification (la charge de travail du patch en lui-même me semble une bonne justification à lui seul).

            Dans Haiku, le principal endroit ou ça se joue, c'est en fait sur la priorisation des accès au disques.

            Il y a aussi plusieurs scheduler disque dans Linux pour gérer différents cas/disque, donc ça pourrait être fait.

            Et dans les utilisations modernes, il y aurait probablement beaucoup à faire pour les aspects réseau, en gérant de la QoS entre différentes applications. Pour pas que le téléchargement d'un gros fichier ralentisse la navigation web ou n'augmente la latence d'une connexion ssh interactive, par exemple.

            Je pense qu'il y a plus de chance de se faire pourrir la connexion par un autre système connecté au même réseau que par une application sur la même machine. En plus, il n'est pas possible de savoir quelle est la bande passante disponible pour accéder à un hôte distant, ni avec quels autres hôtes elle est partagée.

            « 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: Amusant que Haiku soit le seul survivant

              Posté par  . Évalué à 2.

              Donc, je ne suis pas sûr que les développeurs kernels soient hostiles à ce genre de patch.

              Je suis d'accord. Linux ne se destine pas particulièrement à un type d'utilisation. Il est aujourd'hui surtout utilisé pour des serveurs, les smartphones et de l'embarqué, mais une partie si ce n'est tous les développeurs du noyaux l'utilisent sur leur station de travail.

              Mais il est possible qu'il y ai des points d'accroche véritablement gênant. Je ne connais pas BeOS mais je présume qu'il n'utilise pas elf et je ne sais pas si linux souhaite pouvoir supporter autre chose qu'a.out/coff/elf.

              Je présume aussi qu'ajouter l'ensemble des syscall de BeOS doit mener à un enfer de discussion dans la LKML.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Amusant que Haiku soit le seul survivant

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                Ah si, c'est du ELF, aucun problème de ce côté là.

                Et oui, la LKML. Je crois qu'on passerait plus de temps et d'énergie à expliquer aux développeurs Linux le pourquoi et le comment de chaque patch qu'on en a passé à maintenir notre propre noyau, en fait.

                Il y a aussi le fait qu'on a envie d'écrire du code propre en C++ et pas du C qui est trop bas niveau pour avoir quelque chose de lisible, y compris dans le kernel. Déjà avec ça je pense que c'est très très mal parti pour upstreamer quoi que ce soit.

                Globalement ça ne me semble pas acceptable pour Haiku d'être dépendant d'un autre projet pour décider de ce qui sera intégré ou pas dans son noyau, des langages de programmation utilisés, et de choix d'architecture interne. Alors certes, ça nous fait un peu de travail en plus pour maintenir nos propres drivers, mais ça nous donne de l'indépendance et les moyens d'expérimenter des choses en allant beaucoup plus loin que si on devait travailler avec Linux.

                Je pense que c'est globalement l'avis de la plupart des développeurs. Et sinon, il y a V-OS que j'ai mentionné dans un de mes commentaires qui tente cette approche, et qui peut-être nous donnera tort?

              • [^] # Re: Amusant que Haiku soit le seul survivant

                Posté par  . Évalué à 4.

                je ne sais pas si linux souhaite pouvoir supporter autre chose qu'a.out/coff/elf.

                Bof, avec binfmt_misc, tu lance ce que tu veux. Ce n'est sûrement pas le point le plus compliqué.

                Je présume aussi qu'ajouter l'ensemble des syscall de BeOS doit mener à un enfer de discussion dans la LKML.

                wine est en train de bosser sur un système pour ça, donc ça doit pouvoir se convertir.

                « 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: Amusant que Haiku soit le seul survivant

                  Posté par  . Évalué à 2.

                  Ce n'est sûrement pas le point le plus compliqué.

                  Je ne voyais pas le problème comme technique, mais comme politique.

                  wine est en train de bosser sur un système pour ça, donc ça doit pouvoir se convertir.

                  Que le noyau inclu une couche de compatibilité Windows ? Je suis surpris. Du coup wine intègrerait dans le noyau tout ce qui est émulation de windows (syscall + lecture du format PE + entêtes C) et ne garderait en espace utilisateur que les dll (ah et du coup il faut un chargeur pour les dll).

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Amusant que Haiku soit le seul survivant

                    Posté par  . Évalué à 3.

                    Je ne voyais pas le problème comme technique, mais comme politique.

                    Justement, il suffit de configurer binfmt_misc, pas besoin de faire de la politique sur la lkml, l'infra est déjà là dans le kernel.

                    Que le noyau inclu une couche de compatibilité Windows ?

                    Non, mais permettrait de contourner le problème le problème des jeux qui font des syscall

                    https://www.phoronix.com/scan.php?page=news_item&px=Linux-Syscall-Isolate-Memory

                    Du coup wine intègrerait dans le noyau tout ce qui est émulation de windows (syscall + lecture du format PE + entêtes C) et ne garderait en espace utilisateur que les dll (ah et du coup il faut un chargeur pour les dll).

                    Non, wine reste ce qu'il est, c'est juste que certains jeux récent bypass winapi.

                    « 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: Amusant que Haiku soit le seul survivant

      Posté par  (Mastodon) . Évalué à 3.

      Je me souviens d'un projet de ré-implémentation au dessus de Linux qui avait commencé a prendre puis est mort: le nombre de développeur ayant le temps et les capacités pour travailler sur un projet de ce type étant très faible, un seul projet mort a peut-être suffit à tuer l'option BeOS/Linux.
      Après cette explication est peu satisfaisante car rien n’empêchait de forker le projet pour le continuer.

      http://www.blueeyedos.com et cosmoe

      C'est d'ailleurs assez étonnant de voir que des sites de projets morts depuis plus de 15 ans soient encore en ligne. J'aurais coupé la prise plutôt que de continuer à payer pour l'hébergement et le domaine pendant si longtemps.

      • [^] # Re: Amusant que Haiku soit le seul survivant

        Posté par  . Évalué à 2.

        bah tu sais si tu n a pas de maintenance et peu de trafic, ca coute pas cher un site. J ai pas les prix exact mais c est environ 15-20 euros par an…

      • [^] # Re: Amusant que Haiku soit le seul survivant

        Posté par  (site web personnel) . Évalué à 8.

        La dessus, je peux vous répondre :)
        OVH, du temps où c'était encore une petite boite avait un backoffice buggé à souhait, je n'ai pas pu renouveler le nom de domaine de ce fait, le "support client" n'a pas traité le problème, un cybersquatteur est passé par là.
        Il paye d'ailleurs toujours l'hébergement, car il a inséré tout un tas de lien vers de la pub ou je ne sais quoi pour profiter du bon référencement du site.

        Cette perte a achevé l'équipe, à cette date déjà plus très grande.
        Dommage on avait un LiveCD avec une UI fonctionnelle (mais pas de desktop ou autre encore).

    • [^] # Re: Amusant que Haiku soit le seul survivant

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      L'idée revient de temps en temps. En ce moment c'est https://github.com/Barrett17/V-OS qui est développé par un ancien développeur de Haiku (qui s'est fait exclure pour attitude désagréable) en réutilisant les sources de Haiku mais sous license GPL pour empêcher la réutilisation par Haiku de son travail.

      Pour BlueEyedOS, il n'y a jamais eu de sources publiées, ça n'a pas du aider le projet à rester vivant non plus.

      Il y a plein d'autres raisons pour les choix de Haiku, moins aujourd'hui peut-être, mais Linux en 2001 c'était beaucoup moins fonctionnel que maintenant. Il y avait aussi la possibilité que le développement de BeOS reprenne un jour, et dans ce cas ça aurait été bien que le code écrit pour Haiku puisse y être intégré (ça a probablement été le cas au moins en partie dans Zeta). Cette possibilité n'existait pas avec un projet à l'architecture différente. Il y avait aussi la possibilité de réutiliser les drivers écrits pour BeOS, certes moins nombreux mais parfois plus avancés que les équivalents pour Linux à l'époque.

      Et surtout ça n'aurait au final été qu'un n-ième environnement de bureau sous Linux qui n'aurait pas apporté grand chose. Et ça pose plein de problèmes techniques, par exemple pour l'implémentation de l'indexation et des requêtes sur le système de fichier, chose que Linux ne sait toujours pas faire.

      • [^] # Re: Amusant que Haiku soit le seul survivant

        Posté par  . Évalué à 3.

        Je ne comprends pas ton argument : que tu repartes 'from scratch' ou que tu sois au dessus de Linux, si tu vises la récréation fidèle de BeOS, il faut créer un système de fichiers, ça ne change rien..

        Pas terrible l'attitude de Barret..

        • [^] # Re: Amusant que Haiku soit le seul survivant

          Posté par  (site web personnel) . Évalué à 7.

          Pour BlueEyedOS, il n'y a jamais eu de sources publiées, ça n'a pas du aider le projet à rester vivant non plus.

          En 2000, nous n'avions pas les moyens (financiers) de fournir facilement un "repository" public.
          Après avoir été viré de OpenBeOS (ancien nom de Haiku), je me suis tout de même arrangé pour que le code de BlueEyedOS qui pouvait être utile à Haiku arrive à destination…

          Ce que je retiens de cette période c'est que le projet qui faisait le plus rêver a le plus plu,
          c'est pourquoi Haiku a survécu.

          Les benchmarks ont tous démontré que sur une même machine (mon biprocesseur Pentium 3), Linux était 10 à 100 plus rapide que BeOS (BeOS 5), notamment sur les IPCs, qui sont centraux dans fonctionnement de BeOS.
          Je ne sais pas où en est Haiku aujourd'hui, mais vu différence de taille entre l'équipe de dev des noyau linux et Haiku, la voie choisit par BlueEyedOS me semble toujours pertinente (techniquement).

          Personnellement, tout ce que je retiens de tout cela est que tout est prêt à quitter Windows ou MacOS, mais personne n'est présent pour contribuer ou financer pour une alternative pour le "desktop" (à part Mark Shuttleworth ;) ).
          Ici même, j'avais parié ici à l'époque que dans 10 ans, rien n'aurait bougé.

          20 ans après c'est l'occasion de renouvelé ce triste pari.

  • # Bien !

    Posté par  . Évalué à -2.

    La racine du système de fichiers "/" dans haïku ça affiche la liste des partitions ou des lecteurs.
    Et tous les dossiers système sont regroupés dans /system.
    C'est vraiment bien foutu par rapport à Linux.
    Je me demande ce qu'ils attendent Linux pour pas faire pareil.

    • [^] # Re: Bien !

      Posté par  . Évalué à 3.

      L'organisation des dossier utilisé par la majorité des distributions linux est un standard de fait de la majorité des unix (bsd et aix l'utilisent aussi). C'est maintenant standardisé sous le nom Hierachical Filesystem (HFS) et une partie par freedesktop (surtout pour ce qu'il y a dans le ${HOME}). Ça évolue par petite touche (/run est plutôt récent) et en restant compatible.

      Je ne connais pas le fs de BeOS. Je ne comprends pas très description et ce qu'elle apporte. Tu peux expliciter ?

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Mariés pour une semaine

    Posté par  . Évalué à 10.

    Cela fait plus de 10 ans que je suis, de plus ou moins loin, les évolutions d'Haiku, c'est devenu une sorte d'OS chouchou que je reviens picorer de temps en temps, comme une belle friandise.

    Lors de la sortie de l'alpha 1, je m'étais engagé à l'utiliser sur mon PC principal à temps plein pendant 1 semaine (au moins), cf. https://linuxfr.org/nodes/24946/comments/1065440

    ainsi qu'à rédiger un petit compte-rendu à l'issue de cette période (ce qui avait donné lieu à ce journal, que je vais essayer de ne pas relire maintenant, pour ne pas m'influencer : https://linuxfr.org/users/farvardin/journaux/pourquoi-je-garde-haiku )

    Je vais renouveler l'expérience, à dans une semaine ! ;)

    (commentaire évidemment posté depuis Haiku R1 / beta 2)

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

    • [^] # Re: Mariés pour une semaine

      Posté par  (Mastodon) . Évalué à 4.

      Tu n'oublies pas de nous faire un retour ?

      Avec ton teasing, il y en a qui attendent (im)patiemment.

      Surtout, ne pas tout prendre au sérieux !

      • [^] # Re: Mariés pour une semaine

        Posté par  . Évalué à 5.

        Oui, je n'oublie pas ! J'ai pris du retard, et il faut que je réécrive mes notes pour que ça ne soit pas trop indigeste. Cette semaine j'espère…

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # Logiciels compatibles ?

    Posté par  . Évalué à 1.

    Existe-t-il une liste des logiciels fonctionnant sur la version courante ?
    Pour un desktop le minimum serait (à mon avis) :
    LibreOffice-6.3 ;
    Gimp ;
    Calibre-e-book (Python) ;
    Différents navigateurs (comme Firefox, Chrome, Opera, etc.) et clients courriel (Evolution, Thunderbird, Eudora, etc) ;
    Messagerie instantanée (Pidgin, Empathy, WhatsApp, etc.)
    et des outils classiques Éditeur de texte (compatible Emacs et/ou vi, si possible) calculette, capture d'écran.

    La prise en charge des définition d'écrans HD FHD QHD et UHD… et des cartes graphiques sans être obligé de recompiler les drivers à chaque release ou version d'OS !

    • [^] # Re: Logiciels compatibles ?

      Posté par  (site web personnel) . Évalué à 8.

      C'est à se demander pourquoi on a rédigé la dernière partie de la dépêche :-) les réponses y sont presque toutes.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Logiciels compatibles ?

        Posté par  . Évalué à 2.

        Peut-être un effet secondaire de la taille des captures par rapport a la taille du texte? N'est-il pas possible d'avoir des miniatures qui lient vers le lien d'une image plus grosse? (vraies questions, même si je repart derechef)

        • [^] # Re: Logiciels compatibles ?

          Posté par  (site web personnel) . Évalué à 2.

          Mais bien sûr, beaucoup le font. Regarde la dépêche 0AD ou la dépêche Haiku par exemple ;-)
          Plus sérieusement, les images ne sont pas si grosses, plus petites on n'y verrait pas grand chose. Et je crois bien lire des questions posées par des gens qui n'ont pas lu toute la dépêche (ou le journal) depuis très très très longtemps.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Logiciels compatibles ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      LibreOffice: oui
      GIMP: non
      Calibre: oui
      Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.
      Messagerie: clients natif (Beam et le client intégré à Haiku), une vieille version de Thunderbird.
      Messagerie instantanée: client IRC natif Vision, XMPP natif Renga, divers clients en Qt sont disponibles aussi (Quassel, divers clients XMPP dont le nom m'échappe). Telegram est disponible, mais pas Whatsapp.
      Editeurs de texte: Vim et Emacs sont disponibles ainsi que au moins deux éditeurs natifs: Koder et Pe.
      Calculatrice: DeskCalc inclus avec Haiku, diverses alternatives plus ou moins complètes sont disponibles dont SpeedCrunch par exemple.
      Capture d'écran: accessible par la touche prévue à cet effet sur le clavier (possibilité de prendre tout l'écran, ou une seule fenêtre)
      Recompilation des drivers: hors de question, l'interface entre le noyau et les drivers est bien définie et ne change pas d'une version à l'autre. Maintenant on attend que NVidia, AMD et Intel fournissent les drivers… (et on travaille sur nos propres drivers en attendant mais on ne s'est pas lancés dans l'accélération 3D pour le moment)
      Ecrans haute résolution: en principe il suffit de changer la taille des polices dans les préférences Apparence, et le reste de l'interface se met à l'échelle en fonction. Il nous reste du travail à certains endroits pour que ça fonctionne parfaitement.

      • [^] # Re: Logiciels compatibles ?

        Posté par  (site web personnel) . Évalué à 4.

        À propos, si on prend le matériel minimum pour Haïku (Pentium II), je me doute qu'on aura du mal sur le web, mais est-ce que Calligra office se lance par exemple ? La question plus large étant : est-ce qu'il y a des logiciels utiles sur du vieux matériel (hormis pour coder) ?

        (Je suis en train de remonter des vieilleries dont j'étais si fier autrefois, pour tester.)

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Logiciels compatibles ?

          Posté par  (site web personnel, Mastodon) . Évalué à 7.

          Il faut prévoir "pas mal" de RAM (les 256MB c'est vraiment la config mini pour démarrer le système, avec 512MB il y aura un peu plus de place pour lancer des applications), et ça sera probablement assez lent, en particulier pour les applications en Qt, je pense (pas que Qt soit forcément lent, mais il y a forcément une couche de bazar en plus par rapport aux applications natives). Pour le web tu vas être limité par NetSurf (pas de SSE2 dans ces CPUs, donc WebKit ne peut pas fonctionner), et donc pas de Javascript, ce qui allège pas mal les choses mais limite aussi les possibilités.

          Je n'ai plus de matériel aussi ancien sous la main, ma config de référence (qui est compatible avec un BeOS bricolé, pour comparer le comportement avec Haiku quand on a un doute) c'est un Athlon XP 2200+ avec 512MB (ou 1GB?) de RAM et c'est utilisable (sauf pour le développement, en fait. ça prendrait des heures de compiler quoi que ce soit d'un peu imposant avec un gcc moderne).

          Mais c'est l'occasion de repérer les trucs qui sont déraisonablement lents (et pas juste normalement lents sur une machine de ce type) et de nous remonter les infos pour savoir ce qu'on doit optimiser en priorité :o)

        • [^] # Re: Logiciels compatibles ?

          Posté par  . Évalué à 1.

          Ne pas négliger l'impact de la crypto sur les performances.

      • [^] # Re: Logiciels compatibles ?

        Posté par  . Évalué à 2.

        Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.

        Voila qui m'intrigue.

        Je comptais repartir derechef, mais… au final, le moteur de chromium et gecko sont moins simples a embarquer, porter et maintenir que webkit?

        • [^] # Re: Logiciels compatibles ?

          Posté par  . Évalué à 2.

          Je te laisse juger

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Logiciels compatibles ?

            Posté par  . Évalué à 2.

            Merci.
            J'allais répondre en long a ce lien, montrant a quel point je suis dépité et amer par rapport a mozilla, jusqu'a lire ça:

            Quelles plate-formes sont supportées ?

            Short answer is anything Mozilla can run on, then Gecko can too. However, the embedding is concentrating on three primary platforms:

            Windows (95? definitely 98 and later)

            Tu es sûr que ce lien est… a jour?

            • [^] # Re: Logiciels compatibles ?

              Posté par  . Évalué à 1. Dernière modification le 28 juin 2020 à 08:09.

              Dernière modification : 20 nov. 2019, par des contributeurs MDN

              Je crois me souvenir que Mozilla avait annoncé ne plus trop s'embêter avec le support de gecko parce que ça leur prenaient trop de ressources dans la guerre avec Google. Aujourd'hui tous les navigateurs tiers ont jeté l'éponge. Cette obsolescence date de 2015.

              Ce que je trouve risible, c'est devvoir des communiqués de Mozilla expliquer comment c'est triste de voir edge partir sur webkit.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Super

    Posté par  (site web personnel) . Évalué à 6.

    Vraiment super, je trouve cet OS vraiment bien foutu, je trouve certains programmes vraiment bien foutus et simple, notamment le petit serveur web "poorman". Après il manque un petit logiciel comme abiword, car se taper tout calligra avec les dépendances qui vont avec ça fait beaucoup.

    Je suis sur Haiku depuis l'alpha sur un vieux pc avec 512 mo de ram et c'est vivace.
    Par contre je remarque des ralentis sur les vidéos et ce même sur des pc récents et puissants.

    Sinon dans les plus, on peut dire que c'est rapide dans l'utilisation, dans le lancement de l'OS (même pas 15 sec), dans le lancement des programmes (instantanée), l'ergonomie est bien pensé… C'est vraiment top!!!

    Merci aux gars qui sont derrière.

    • [^] # Re: Super

      Posté par  (Mastodon) . Évalué à 4.

      Par contre je remarque des ralentis sur les vidéos et ce même sur des pc récents et puissants.

      J'imagine que contrairement aux autres OS, il manque les drivers et librairies pour utiliser le gpu ?

      • [^] # Re: Super

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Oui.

        Cela dit, s'il s'agit de vidéos lues dans le navigateur web, le problème est surtout que le code pour faire marcher ça a été bricolé très rapidement et il y a moyen de faire beaucoup mieux. Seulement il y a toujours des choses plus urgentes à traiter ailleurs, et du coup c'est toujours pas fait.

        • [^] # Re: Super

          Posté par  (site web personnel) . Évalué à 2.

          Non, en fait ce sont des films dvix et le lecteur par défaut avait par moment des latences.

    • [^] # Re: Super

      Posté par  . Évalué à 2.

      Après il manque un petit logiciel comme abiword

      tu plaisantes ? Il est dans le gestionnaire de paquets, avec pkgman install abiword en 4 secondes c'est installé et en 2 secondes c'est démarré !

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

      • [^] # Re: Super

        Posté par  (site web personnel) . Évalué à 2.

        Bah il n'est pas listé dans l'interface graphique.

        • [^] # Re: Super

          Posté par  . Évalué à 2.

          C'est étrange, je pensais que les deux interfaces étaient interchangeables

          « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

          • [^] # Re: Super

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Par défaut l'interface graphique ne liste que les paquets "featured" (mis en avant) dont le choix est un peu arbitraire.

            Pour Abiword, la version disponible n'est pas terminée et est assez instable, il me semble (en plus de ne pas être à jour). On avait voulu l'upstreamer mais on a pas été très bien reçus par les devs d'Abiword à l'époque…

  • # mode 'brut'

    Posté par  . Évalué à 3.

    En fait, j'ai une question qui est sûrement très bête.

    Il m'est arrivé, comme a d'autres ici je pense, de devoir travailler en "mode sans échecs", "mode mono utilisateur", en gros dans des modes dégradés sur lesquels ont peut faire a peu près tout ce qu'on veut, tant qu'on sait se passer de confort.

    Dans mon cas, j'ai utilisé linux pour du… disons, embarqué (ni baremetal, ni temps réel) pour des équipements de ville par exemple, qui ont un écran tactile, dédié a une seule application.
    Au début, ma boîte du moment est partie sur l'idée d'utiliser electronJS. Au bout de quelques mois, après le départ du développeur qui avait tout fait, on s'est aperçu qu'il y avait de nombreux crashs (oui, je sais) notamment des SIGILL. Ça, et le fait que Xorg et les scripts que j'ai bricolés étaient assez… aléatoires… concernant la gestion de l'orientation de la dalle graphique et celle de la dalle tactile (non, les dev logiciels ne sont pas les rois).
    Ça s'est fini a ce que je doive me farcir la gestion de l'UI, et vu que ni Xorg ni SDL ne permettaient de faire les choses facilement, je suis revenu a du bon vieux framebuffer + libinput (tellement plus simple, d'accéder direct a la mémoire et de faire une lib, dans ces cas, que de passer par 36 couches d'abstractions).
    Qu'en est-il également des
    Tout ça m'a amené a penser qu'une alternative portable et portée à d'autres systèmes serait plutôt sympa, et je me demandais si Haiku offrait ou planifiait ce genre de choses?

    Je me pose aussi la question sur la question des syscalls. J'imagine qu'ils sont en C, sinon ça serait se fermer aux autres langages ou leur ajouter une couche de compat? Si c'est du C++, alors, comment vous gérez l'absence de specs d'ABI? N'y aurat-il qu'un seul compilo "autorisé"?

    • [^] # Re: mode 'brut'

      Posté par  (site web personnel) . Évalué à 4.

      Tu ferais mieux de poser cette question sur le forum BeOS.
      Pour une piste ce commentaire de pulkomandy évoque TuneTracker Systems qui vend des boitiers préinstallés avec Haiku et leur outil de MAO.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: mode 'brut'

      Posté par  (site web personnel) . Évalué à 5.

      Qu'en est-il également des

      Ah? Toi aussi ton clavier se blo

      ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: mode 'brut'

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Bonjour,

      Ce n'est pas vraiment le but de Haiku: on est là pour faire un système pour les PC de bureau. Donc tout ce qui est embarqué, ce n'est pas notre cible et on ne peut pas trop s'en occuper (on a déjà pas le temps pour ce qu'on essaie de faire…)

      Sur le plan technique, on peut quand même avancer quelques réponses:

      Les syscalls: il vaut mieux ne pas les utiliser directement, car on se permet des modifications dans leur API et ABI régulièrement. Il est très probable que les applications qui les utilisent cessent rapidement de fonctionner. Il faudra utiliser la libc pour les APIs POSIX et du C++ (pas le choix) pour les APIs de BeOS permettant de communiquer avec le serveur graphique. On pourrait virer le serveur graphique et utiliser directement le framebuffer, mais ce sera limité au VESA (les pilotes fonctionnant dans le serveur graphique pour les autres cas).

      Les ABI: l'ABI pour le C++ ne fait pas partie du standard C++, mais aujourd'hui gcc et clang (au moins) sont d'accord pour utiliser l'ABI C++ définie à l'origine pour les processeurs Itanium, et qui s'adapte très bien aux autres machines. On peut donc utiliser indifférement ces deux compilateurs. Le problème, c'est que cette ABI est arrivée dans gcc version 3, et que BeOS utilisait la version 2. La solution pour l'instant est d'avoir 2 ensembles de bibliothèques compilées avec ces 2 versions (le problème ne se pose que pour la version x86 32bit de Haiku, pour les autres versions la compatibilité avec BeOS n'est pas assurée).

      Il y a aussi plusieurs astuces dans la façon de définir les classes pour pouvoir les modifier après coup:
      - Déclaration d'emplacements réservés à la fin de la vtable et des données de chaque objet, qui peuvent être remplacés ensuite par des méthodes si nécessaire,
      - Ajout d'une méthode "Perform(int operationCode, …)" qui permet de faire toutes sortes de choses et qui est systématiquement surchargée par tous les objets,
      - Déclaration à la main de symboles C++ pour des méthodes qui n'existent plus

      Ces acrobaties demandent un peu d'habitude mais cela permet de faire fonctionner des applications écrites il y a plus de 20 ans sur les versions actuelles de Haiku. Les développeurs de chez BeOS s'étaient déjà posé la question et avaient mis en place ces solutions.

      Aujourd'hui on peut également ajouter le versionnage des symboles qui permettent de modifier une fonction tout en gardant les versions précédentes pour les anciennes applications.

      • [^] # Re: mode 'brut'

        Posté par  (site web personnel) . Évalué à 3.

        C'est vraiment se casser la tête pour pas grand chose.

        Que reste t'il dans la bibliothèque de logiciels de BeOS qui vaille encore le coût de maintenir une compatibilité binaire ? (oui, je sais, j'ai déjà posé la question en 2003 ;) )

        Une deuxième façon de faire est de versionner les binaires (pas les libs ni le système) et de les patcher au 1er lancement si besoin.

        • [^] # Re: mode 'brut'

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive (avec un développeur de Haiku qui l'utilise toujours pour gérer sa comptabilité et la migration vers autre chose est compliquée) et SynC Modular (un synthé musical). Et il y a des centaines de logiciels écrits pour BeOS dont on a récupéré les sources aussi, avoir une compatibilité au niveau des APIs serait suffisant, mais autant avoir l'ABI aussi tant qu'on y est. Sans parler de TuneTracker Systems et iZ Corp, les deux entreprises qui ont migré depuis BeOS et comptent pas mal sur Haiku pour rester assez compatible pour ça.

          Deuxième intérêt: on peut facilement comparer le comportement de notre implémentation avec celle de BeOS, il nous arrive encore de temps en temps d'avoir un doute sur le "bon" comportement d'une API et c'est utile d'avoir une référence (même si, souvent, on finit par décider de faire mieux que BeOS, par exemple sur la gestion d'erreurs).

          Troisième intérêt: cela nous permet d'identifier les problèmes de compatibilité que pose la maintenance à long terme d'une API/ABI, ce qui sera utile pour la version R2 de Haiku ou on prévoit des changements plus importants, mais avec de la rétro compatibilité tout de même. Du coup on sait dans quel genre de bazar on met les pieds :)

          • [^] # Re: mode 'brut'

            Posté par  (site web personnel) . Évalué à 3.

            Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive

            Ça n’a finalement pas abouti : https://linuxfr.org/news/gobe-productive-libere ?

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: mode 'brut'

              Posté par  (site web personnel) . Évalué à 3.

              Bon en fait je me réponds à moi même…

              J’ai trouvé ici https://www.tldp.org/FAQ/WordPerfect-Linux-FAQ/future.html ceci :

              FreeRadicalSoftware announced on August 12, 2002 plans to open-source the entire suite under the GNU GPL, but then in December 2002 had to announce that sufficient funds—about US $100k—couldn't be raised to license the source code.

              Et un lien vers https://www.osnews.com/story/2308/obstacles-leave-gobeproductive-closed/ avec des explications et une copie de ce courriel :

              From: “Scott Lindsey” (wombat AT gobe DOT com)
              To: (gobe-usertalk AT gobe DOT com)
              Sent: Thursday, December 05, 2002 1:02 AM
              Subject: [gobe-usertalk] FreeRadical

              What has happended to the Open sourcing of the code ??

              At this time, Free Radical has been unable to raise the money necessary
              to license the code from Gobe Software Inc.
              Free Radical is effectively a nonstarter at this point.

              Donc Free Radical Software n’aurait en fait pas réussi à lever les fonds nécessaires pour libérer le code…

              😢

              Note : dans cette seconde page il y a un lien vers une brève au sujet du succès de la levée de fond qui a libéré Blender… c’est de l’archéologie tout ça… bon voyage dans le temps !

              ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: mode 'brut'

                Posté par  (site web personnel, Mastodon) . Évalué à 6.

                Il y a eu d'autres tentatives depuis. Certains développeurs de Haiku ont signé un NDA qui leur a permis d'accéder au code. Mais, il n'y a pas tout l'historique, seulement la dernière version qui a été portée vers Windows.

                Du coup, ça fait beaucoup de travail pour étudier ce code, remplacer les morceaux qui ne pourraient pas être libéré (il faudrait vérifier qu'est-ce qui a été écrit par les auteurs de GoBe qui sont d'accord pour libérer, et qu'est-ce qui a été intégré dedans qui vient d'autres projets), et ensuite refaire le portage vers Haiku.

                Finalement, porter LibreOffice était moins compliqué :)

                La solution de migration sera probablement de proposer un "translator" permettant la conversion des fichiers GoBe pour les ouvrir dans LibreOffice, solution qui semble plus sage sur le long terme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.