Ce qui marche bien c'est surtout de rejoindre quelques groupes de discussions (par exemple le salon de JabberFR qui sert un peu d'accueil général pour la communauté francophone).
Le moyen le plus évident de rencontrer des utilisateurs de XMPP, après tout, c'est de les contacter par XMPP!
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.
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)
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.
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?
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.
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.
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.
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.
[^] # Re: Conseils demandés
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche XMPP@home, 9 juin 2020. Évalué à 4. Dernière modification le 18 juin 2020 à 08:53.
Ce qui marche bien c'est surtout de rejoindre quelques groupes de discussions (par exemple le salon de JabberFR qui sert un peu d'accueil général pour la communauté francophone).
Le moyen le plus évident de rencontrer des utilisateurs de XMPP, après tout, c'est de les contacter par XMPP!
[^] # 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é à 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: Logiciels compatibles ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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 pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. É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: 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é à 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: 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.
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: 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é à 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: 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.
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:
[^] # 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.