Alors il y a une petite erreur: c'est 3 ans et pas 5. Mais sinon oui, c'est écrit clairement dans la license:
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:
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)
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.
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.
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?
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…
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!
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 :)
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.
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.
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.
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
Surtout, il y a des gens qui ont essayé de le compiler et il semblerait qu'il manque des morceaux, si j'en crois par exemple le README dans ce fork: https://github.com/dspinellis/GW-BASIC
Alors, dire que la seule différence entre les domaines gratuits et payants est qu'il faut renouveler le domaine tous les ans, c'est un peu trompeur. Par exemple pour un domaine gratuit, il est obligatoire d'y héberger un site web accessible en http, sans quoi le domaine est supprimé au bout de 15 jours.
Le but étant que ces domaines soient référencés au maximum, afin de pouvoir les revendre plus cher par la suite dès qu'ils sont inutilisés ou suspendus pour d'autres raisons (hébergement de malware, pornographie, … par exemple). Ce n'est bien entendu pas le cas pour les domaines payants, pour lesquels le fonctionnement est celui d'un nom de domaine classique.
Ah non ce sont les "game engines" qui sont interdits. Un "moteur de jeu" ça ne pose aucun problème? :o)
Bon en vrai ils ont défini ce qu'ils entendent par "game engine product" dans la license:
“Game Engine Product” shall mean software used for video game development. This includes both the content authoring software and the software used to show the created content.
C'est donc plus basé sur l'utilisation à laquelle c'est destiné que sur le nom qu'on lui donne.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
Oui, et OpenBSD a l'air de bien fonctionner sur SPARC64 également (y compris les machines les plus récentes de chez Fujitsu qui continue pour le moment à vendre du matériel avec l'architecture SPARC).
Pour FreeBSD, les machines sun4v n'ont apparament jamais été vraiment fonctionnelles, et donc ce port n'était utilisable que pour les machines fabriquées avant 2000 et utilisant encore sun4u. Je suppose que le travail en cours dans FreeBSD pour se débarasser complètementde gcc et utiliser clang ne doit pas aider s'il n'y a personne pour tenir le code spécifique au SPARC à jour.
"10 ans d'empoisonnement de l'éducation, invasion de la vie privée, et menaces sur la sécurité", dit le message.
On se demande bien pourquoi il faudrait publier les sources de cette version obsolète. Il vaudrait mieux que Microsoft continue de publier les sources des versions actuelles, comme ils ont déjà un peu commencé à le faire par petits morceaux.
Donc oui, anti-Windows mais on veut bien les sources quand même. Sans aucun plan pour en faire quoi que ce soit, cela dit, parce qu'il ne faut pas exagérer. Si ça venait par exemple de ReactOS avec un plan pour faire quelque chose des sources une fois publiées, pourquoi pas, mais là, je vois pas bien l'intérêt du truc.
La page Wikipedia qui traite de l'"upcycling" a été créée en 2007. Si c'est créé pour l'occasion, c'est une belle anticipation, puisque Windows 7 a été publié seulement 2 ans après.
Haiku utilise WebKit et notre navigateur a besoin d'environ 32Mo de mémoire au démarrage, ce qui me semble assez raisonnable.
Sous Linux, il faut voir que WebKit réserve beaucoup d'espace mémoire sans forcément l'utiliser tout de suite. Du coup ça ne consomme pas vraiment de mémoire, en fait. C'est juste que les chiffres indiqués par les outils de mesure ne sont pas ce qu'on croit.
De plus, il n'est pas si compliqué que ça de configurer WebKit pour être moins gourmand. Le JIT pour Javascript peut être désactivé, les trucs qui réservent beaucoup d'espace mémoire sont configurables, etc. Sinon il ne pourrait pas fonctionner sur l'Apple Watch, par exemple.
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 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:
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:
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: Amusant que Haiku soit le seul survivant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 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: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
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!
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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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: Il y a actuellement un flou assez important sur ce qui vient après cette version R1
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 6.
Je pense qu'on va garder notre launch_daemon pour la gestion des services et de l'init :)
[^] # Re: Logo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
En PNG: https://raw.githubusercontent.com/haiku/haiku/master/data/artwork/HAIKU logo - black on transparent - big.png
En SVG: https://raw.githubusercontent.com/haiku/haiku/master/data/artwork/HAIKU logo - black.svg
[^] # Re: Persévérance et intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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 :)
[^] # Re: Persévérance et intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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: Intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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.
# Logo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5. Dernière modification le 15 septembre 2024 à 19:27.
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
[^] # Re: Quelle générosité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Microsoft continue sa libération du code source des applications stratégiques. Évalué à 2.
Surtout, il y a des gens qui ont essayé de le compiler et il semblerait qu'il manque des morceaux, si j'en crois par exemple le README dans ce fork: https://github.com/dspinellis/GW-BASIC
# Tu as ce pour quoi tu payes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Domaine en .TK. Évalué à 2.
Alors, dire que la seule différence entre les domaines gratuits et payants est qu'il faut renouveler le domaine tous les ans, c'est un peu trompeur. Par exemple pour un domaine gratuit, il est obligatoire d'y héberger un site web accessible en http, sans quoi le domaine est supprimé au bout de 15 jours.
Le but étant que ces domaines soient référencés au maximum, afin de pouvoir les revendre plus cher par la suite dès qu'ils sont inutilisés ou suspendus pour d'autres raisons (hébergement de malware, pornographie, … par exemple). Ce n'est bien entendu pas le cas pour les domaines payants, pour lesquels le fonctionnement est celui d'un nom de domaine classique.
[^] # Re: ajout à la licence apache 2.0
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le moteur et l'éditeur de jeu Defold édités par King deviennent open source… mais pas libres. Évalué à 2. Dernière modification le 19 mai 2020 à 14:44.
Ah non ce sont les "game engines" qui sont interdits. Un "moteur de jeu" ça ne pose aucun problème? :o)
Bon en vrai ils ont défini ce qu'ils entendent par "game engine product" dans la license:
C'est donc plus basé sur l'utilisation à laquelle c'est destiné que sur le nom qu'on lui donne.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 2.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 4.
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 5.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
[^] # Re: J'ai moinssé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vélib' et open data. Évalué à 8.
Je crois que c'était fait exprès pour piquer les yeux des gens allergiques à l'écriture inclusive encore plus fort.
[^] # Re: Cela concerne uniquement la SPARC sur FreeBSD ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sparc RISC, c'est fini … et dire que c'était l'archi de mes premiers amours. Évalué à 2.
Oui, et OpenBSD a l'air de bien fonctionner sur SPARC64 également (y compris les machines les plus récentes de chez Fujitsu qui continue pour le moment à vendre du matériel avec l'architecture SPARC).
Pour FreeBSD, les machines sun4v n'ont apparament jamais été vraiment fonctionnelles, et donc ce port n'était utilisable que pour les machines fabriquées avant 2000 et utilisant encore sun4u. Je suppose que le travail en cours dans FreeBSD pour se débarasser complètementde gcc et utiliser clang ne doit pas aider s'il n'y a personne pour tenir le code spécifique au SPARC à jour.
[^] # Re: Taxation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal JSON est dans les airs. Évalué à 10.
[^] # Re: Esprit potache es-tu là ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 9.
"10 ans d'empoisonnement de l'éducation, invasion de la vie privée, et menaces sur la sécurité", dit le message.
On se demande bien pourquoi il faudrait publier les sources de cette version obsolète. Il vaudrait mieux que Microsoft continue de publier les sources des versions actuelles, comme ils ont déjà un peu commencé à le faire par petits morceaux.
Donc oui, anti-Windows mais on veut bien les sources quand même. Sans aucun plan pour en faire quoi que ce soit, cela dit, parce qu'il ne faut pas exagérer. Si ça venait par exemple de ReactOS avec un plan pour faire quelque chose des sources une fois publiées, pourquoi pas, mais là, je vois pas bien l'intérêt du truc.
[^] # Re: Esprit potache es-tu là ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 5.
La page Wikipedia qui traite de l'"upcycling" a été créée en 2007. Si c'est créé pour l'occasion, c'est une belle anticipation, puisque Windows 7 a été publié seulement 2 ans après.
[^] # Re: Une arme noble d'une époque civilisée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal KHTML c'est fini. Évalué à 7.
Haiku utilise WebKit et notre navigateur a besoin d'environ 32Mo de mémoire au démarrage, ce qui me semble assez raisonnable.
Sous Linux, il faut voir que WebKit réserve beaucoup d'espace mémoire sans forcément l'utiliser tout de suite. Du coup ça ne consomme pas vraiment de mémoire, en fait. C'est juste que les chiffres indiqués par les outils de mesure ne sont pas ce qu'on croit.
De plus, il n'est pas si compliqué que ça de configurer WebKit pour être moins gourmand. Le JIT pour Javascript peut être désactivé, les trucs qui réservent beaucoup d'espace mémoire sont configurables, etc. Sinon il ne pourrait pas fonctionner sur l'Apple Watch, par exemple.