ça avance. Mais ce n'est pas une question de légèreté, c'est une question de réactivité. Même sur un Pi avec 512Mio de RAM, Haiku peut tourner sans problème. Par contre, sans accélération de l'affichage, ça va pas être si intéressant que ça. Le Pi a un GPU très puissant, et il faudrait l'exploiter au maximum pour le rendu graphique ce qui permettrait de libérer le CPU pour des choses importantes.
Sous Linux ça devient de plus en plus difficile. Pour que ça marche bien on a besoin d'un serveur graphique qui coordonne toutes les opérations de dessin. X le fait, mais comme il ne fait pas d'antialiasing, c'est moche, et du coup les toolkits majeurs (Qt, GTK) n'utilisent plus X et font le rendu côté client. Et du coup il y a Wayland qui se prépare et qui supprime définitivement le rendu côté serveur.
Dans le cas de Haiku, c'est toujours app_server qui fait le rendu pour les applications natives, et donc si on fait un backend de l'app_server qui utilise le GPU pour le tracé 2D (par exemple via OpenVG), toutes les applications en bénéficieront. Mais ça reste pas mal de travail à faire.
Pour le port ARM lui même, ça avance doucement (le kernel se lance, maintenant il faut modifier le pilote USB qui n'est pas capable de fonctionner sans un bus PCI, de façon a faire marcher le stockage de masse USB et pouvoir charger le reste du système de fichiers pour booter plus loin). Par contre on cible pour le moment les ARMv7 ce qui exclut le Raspberry Pi. Il y a un peu de support à faire pour ARMv6 (pour les opérations atomiques, qui n'ont pas d'instruction dédiée et doivent être implémentées autrement, si je me souviens bien). Le manque de support du Pi dans QEMU est aussi un peu embêtant pour démarrer le travail.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
ça avance. Mais ce n'est pas une question de légèreté, c'est une question de réactivité. Même sur un Pi avec 512Mio de RAM, Haiku peut tourner sans problème. Par contre, sans accélération de l'affichage, ça va pas être si intéressant que ça. Le Pi a un GPU très puissant, et il faudrait l'exploiter au maximum pour le rendu graphique ce qui permettrait de libérer le CPU pour des choses importantes.
Sous Linux ça devient de plus en plus difficile. Pour que ça marche bien on a besoin d'un serveur graphique qui coordonne toutes les opérations de dessin. X le fait, mais comme il ne fait pas d'antialiasing, c'est moche, et du coup les toolkits majeurs (Qt, GTK) n'utilisent plus X et font le rendu côté client. Et du coup il y a Wayland qui se prépare et qui supprime définitivement le rendu côté serveur.
Dans le cas de Haiku, c'est toujours app_server qui fait le rendu pour les applications natives, et donc si on fait un backend de l'app_server qui utilise le GPU pour le tracé 2D (par exemple via OpenVG), toutes les applications en bénéficieront. Mais ça reste pas mal de travail à faire.
Pour le port ARM lui même, ça avance doucement (le kernel se lance, maintenant il faut modifier le pilote USB qui n'est pas capable de fonctionner sans un bus PCI, de façon a faire marcher le stockage de masse USB et pouvoir charger le reste du système de fichiers pour booter plus loin). Par contre on cible pour le moment les ARMv7 ce qui exclut le Raspberry Pi. Il y a un peu de support à faire pour ARMv6 (pour les opérations atomiques, qui n'ont pas d'instruction dédiée et doivent être implémentées autrement, si je me souviens bien). Le manque de support du Pi dans QEMU est aussi un peu embêtant pour démarrer le travail.