reno a écrit 3886 commentaires

De toutes façons, je te retourne la question, pourquoi continuer Linux et GNU maintenant que le vrai UNIX est libre sous la forme des BSD?

"vrai Unix" ça ne veut pas dire grand chose (Plan9?) et puis la compatibilité matérielle de Linux est bien meilleure que celle des *BSD.

Pour faire la même chose que Haiku, il faudrait prendre plusieurs morceaux de la pile logicielle classique de Linux (un noyau, un serveur graphique, un toolkit, un framework media du genre de gstreamer, etc).

Ça c'est totalement FAUX, tu peux prendre juste le noyau Linux (même pas glibc si tu n'en as pas envie) et faire un clone de BeOS là dessus, ça représente déjà énormément de travail en moins que de partir de rien (enfin presque rien pour Haiku, je crois que le noyau existait déjà mais il avait très peu de driver), certes tu peux aussi partir d'une distrib Linux classique et ajouter 'à minima' un support des appli BeOS comme tu le suggère mais ça n'est pas le seul choix possible: tout le continuum est possible.

Il me semble que maintenant il y a les 2 en Erlang: les threads légères reparties sur des threads systèmes(1 par core(?)), après je n'y connais pas grand chose en Erlang..

Bah, ça te fera une belle jambe tes 32Mo de RAM quand tu essayera de naviguer sur le web!
Je me souviens d'un site web pas spécialement graphique ou Chrome indiquait que la page faisait 300 Mo (probablement un bug du blog)..
Alors une machine ou tu ne peux pas vraiment naviguer sur le web, ça restreint beaucoup l’intérêt..

Il y a deux projets basés sur Linux qui visaient à recréer BeOS et qui se sont plantés.

Vrai, les projets qui se plantent, c'est fréquent.

HaikuOS est celui qui réussi là où ceux qui ont tenté ta solution se sont plantés.

Ça fait des années que Haiku essaye de faire une béta sans y arriver, donc dire que Haiku réussit c'est tout de même un peu prématuré..
On pourra dire qu'ils ont réussi le jour ou ils auront sorti une version stable (ce que je leur souhaite!!), pas avant..

Euh, c'est pas nouveau, ça date au moins des années 90s. C'est possible de le faire en[coupé]Rien à voir avec les frameworks…

1) Entre ce qui est possible et ce qui est réalisé en pratique, il y a une GROSSE différence.

2) Le framework a de l'importance dans la mesure ou il pousse/encourage le multi-threading ou pas, de mémoire sur BeOS le multi-threading est encouragé avec par exemple une thread pour la fenêtre et une thread pour l'application.

C'est un peu la même chose que pour les langages: le C te "permet" de faire des threads, Erlang "impose" de faire des threads..

Ce ne sont pas que des considérations théoriques, le résultat est(était?) que sur BeOS les applis que j'avais utilisé à l'époque étaient super-réactives, ce n'était PAS le cas pour les applis sur Windows ou Linux.

Bon ça date et les applis ont eu le temps d'évoluer pas mal depuis, donc ça sera intéressant de comparer Haiku et un desktop Linux moderne(Wayland peut aider ici d'ailleurs), mais ça ne m'étonnerai pas que les applis Haiku restent bien plus réactives que les applis Linux: la latence/le temps de réaction, c'est difficile a mesurer et donc c'est rarement optimisé..

Je doute malheureusement du succès de Haiku. L'architecture compacte et très performante de BeOS n'est plus aussi utile aujourd'hui.

Pas si sur que toi là, OK le démarrage un SSD et ca roule, les videos/OpenGL là Linux devrait etre bien supérieur (à plus forte raison s'il faut faire tourner Haiku dans une VM!), mais une GUI très réactive grâce aux applications utilisant le multithreading?
Sur ce point, BeOS/Haiku a peut être un avantage sur les OS a base de Linux, ce n'est pas vraiment lié au noyau, plutôt aux frameworks..

Punaise y'a encore des gens pour s'intéresser à BeOS ?

Et bien pour avoir utiliser BeOS a l'époque les avantages listés dans le journal sont(étaient?) vraies, pas juste du marketing: les applications natives étaient très réactives (beaucoup plus que sur Windows ou Linux), démarrage en 14s sur mon PC de l'époque (Céléron 333!) comparés à 1min(Windows qui triche et est très lent au démarrage) et 1m20s(Linux), donc ça ne m'étonne pas que certains s'intéressent toujours à BeOS, maintenant sur un PC moderne avec SSD, est-ce que BeOS/Haiku reste intéressant?

Je ne sais pas..

A voire quand ils sortiront une version 'stable', enfin si ils y arrivent parce que prendre la décision de développer un nouveau noyau plutôt que de réutiliser Linux ou FreeBSD, on sent bien que (comme la majorité des projets opensource/libre) ils ont pris le parti de se faire plaisir en réinventant la roue et tant pis si ça prend beaucoup plus de temps au final.

1 semaine (MS14-066) vs 24h(Heartbleed), ça change beaucoup de choses!!

et tout le monde vous écoute quand même.

Oui, enfin à priori s'il a fait une grosse donation plutôt que plusieurs petites c'est pour profiter de la publicité engendrée pour encourager d'autre a donner pas pour 'raconter sa vie'.

mais pas si facile à recevoir.

La fondation FreeBSD a déjà l'habitude de recevoir des donations donc elle a déjà les structures pour, après effectivement un don comme ça est probablement plus compliqué a gérer que les contributions 'habituelles'.

Plutôt d'accord avec toi, note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada, mais il y a l'inverse aussi: Ada n'a pas le typage incluant la durée de vie comme Rust (enfin je crois).

Dans les trois cas, il y a un ramasse miettes.

Il y a un ramasse miettes dans la base mais j'ai lu plusieurs fois que les devs de jeux contournaient en fait le GC faisant des trucs plutôt sale comme réutiliser les objets existants plutôt que de les effacer.
A partir de là, le GC est un ami ou un ennemi pour un dev de jeux?
Ça se discute..

et il fait des jeux en Java.

Ah? Des petits jeux pas très interactif alors..
Quand je vois les articles sur les problèmes de GC dans Minecraft, ça me conforte dans l'idée que Java n'est pas très adapté pour faire des jeux..

Ton Java?
Ton C++ plutôt, Rust n'est pas un concurrent de Java..

code source est publié sous double licence Apache 2.0 et licence MIT.

Tiens? Je croyais que ces licences étaient équivalentes, quelqu'un sait il pourquoi il y a ces 2 licences?

Bon ça n'a pas une grande importance..

En tout cas merci pour la dépêche.

Si oui, ça permettra d'en finir avec la sempiternelle discussion sur ce sujet..

Par contre j'imagine que contrairement à Weston le compositeur Wayland d'E19 n'a pas de sortie RDP..

Merci je sais. Mais pour qu'un serveur X soit un serveur X il doit supporter tout le protocole même si les toolkit modernes ne s'en servent plus.
Dessiner une ligne a peu d'intérêt mais avec X tu peux cacher les lettres côté serveur d'affichage ce qui permet d'afficher du texte avec une utilisation de bande passante réduite (la plupart du temps, ça peut dépendre du rendu).

Donc en théorie X peut avoir des avantages en efficacité sur Wayland en distant pour comparer en pratique il va falloir attendre que Wayland devienne mature..

PS: je sais bien que tout nouveau tout beau, mais je ne comprends pas pourquoi le poste précédent a été moinsser..

Un troll?

Pas vraiment non: à l'heure actuelle pour avoir le déport d'écran avec Wayland il faut que le compositeur le supporte ce qui est loin d'être toujours le cas! Avec X, dans la majorité des cas ça fonctionnait sans problème, avec Wayland c'est optionnel (et immature).

En plus, par conception le déport d'écran Wayland est en théorie moins efficace qu'avec X (puisqu'avec X on peut envoyer des buffers comme Wayland mais pas l'inverse: on ne peut pas dire affiche moi une ligne avec Wayland), là c'est effectivement plus discutable car la qualité de l'implémentation l'emporte souvent sur des avantages "théoriques".

Hum, avec une syntaxe pareil 99% des gens utiliseront les cast classique au lieu de la version safe :-(

Plutôt d'accord sur le problème du wrapping en cas d'overflow, mais ça reste quand même mieux que le C/C++ avec son comportement indéfini (bon c'est pas dûr).

C'est de la faute des concepteurs de CPUs!! Ils auraient du suivre le MIPS ou toutes les instructions entière ont un mode 'trap sur overflow' ça permet de détecter le dépassement entier avec un cout quasi-nul.

Le seul CPU qui prévoit de fournir l'équivalent de ce que fournissait le MIPS, c'est le Mill un CPU même pas implémenté en FPGA à l'heure actuel..

Merci pour ta réponse.

Si je comprends bien pour obtenir l'équivalent d'un export DISPLAY avec RDP il faudrait ajouter un démon qui va faire la connexion car avec RDP se fait de la partie qui a l'écran receveur a la partie qui émet l'image de l'application au contraire d'X.

Tu peux développer? C'est la première fois que j'entends parler de fullscreen-shell..
Ça marche bien la backend RDP de Weston?

Effectivement d'après Wikipedia c'est Lipstick (qui est propriétaire) qui est le compositeur.
Pas de bras, pas de chocolat.

Weston a une backend RDP mais j'ignore si elle permet d'exporter juste une fenetre ou si c'est nécessairement tout le bureau.
Ce que tu propose me parait possible en tout cas.

Pourquoi y'a-t-il autant de protocoles ?

Parce que Wayland peut être utilisé dans des contextes différents.
Donc tu as un protocole 'de base' (wayland) pour l'envoi de buffers graphiques plus d'autre protocole qui eux sont utiles ou pas selon le contexte.
xdg-shell c'est le protocole pour les environnements de bureaux (gestion des fenêtres, des titres, du copier/coller(pas sûr là)), protocole dont tu n'as rien a faire si tu est dans l'embarqué par exemple.
Je crois qu'il y a un consortium automobile qui travaille sur un protocole par exemple.

C'est xdg-shell qui est expérimental pas Wayland.
Xdg-shell c'est spécifique aux environnements de bureaux genre KDE/Gnome.