Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive (avec un développeur de Haiku qui l'utilise toujours pour gérer sa comptabilité et la migration vers autre chose est compliquée) et SynC Modular (un synthé musical). Et il y a des centaines de logiciels écrits pour BeOS dont on a récupéré les sources aussi, avoir une compatibilité au niveau des APIs serait suffisant, mais autant avoir l'ABI aussi tant qu'on y est. Sans parler de TuneTracker Systems et iZ Corp, les deux entreprises qui ont migré depuis BeOS et comptent pas mal sur Haiku pour rester assez compatible pour ça.
Deuxième intérêt: on peut facilement comparer le comportement de notre implémentation avec celle de BeOS, il nous arrive encore de temps en temps d'avoir un doute sur le "bon" comportement d'une API et c'est utile d'avoir une référence (même si, souvent, on finit par décider de faire mieux que BeOS, par exemple sur la gestion d'erreurs).
Troisième intérêt: cela nous permet d'identifier les problèmes de compatibilité que pose la maintenance à long terme d'une API/ABI, ce qui sera utile pour la version R2 de Haiku ou on prévoit des changements plus importants, mais avec de la rétro compatibilité tout de même. Du coup on sait dans quel genre de bazar on met les pieds :)
[^] # Re: mode 'brut'
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 8.
Il reste quelques logiciels dont on a pas les sources: au moins GoBe productive (avec un développeur de Haiku qui l'utilise toujours pour gérer sa comptabilité et la migration vers autre chose est compliquée) et SynC Modular (un synthé musical). Et il y a des centaines de logiciels écrits pour BeOS dont on a récupéré les sources aussi, avoir une compatibilité au niveau des APIs serait suffisant, mais autant avoir l'ABI aussi tant qu'on y est. Sans parler de TuneTracker Systems et iZ Corp, les deux entreprises qui ont migré depuis BeOS et comptent pas mal sur Haiku pour rester assez compatible pour ça.
Deuxième intérêt: on peut facilement comparer le comportement de notre implémentation avec celle de BeOS, il nous arrive encore de temps en temps d'avoir un doute sur le "bon" comportement d'une API et c'est utile d'avoir une référence (même si, souvent, on finit par décider de faire mieux que BeOS, par exemple sur la gestion d'erreurs).
Troisième intérêt: cela nous permet d'identifier les problèmes de compatibilité que pose la maintenance à long terme d'une API/ABI, ce qui sera utile pour la version R2 de Haiku ou on prévoit des changements plus importants, mais avec de la rétro compatibilité tout de même. Du coup on sait dans quel genre de bazar on met les pieds :)