reno a écrit 3879 commentaires

J'ai pris l'exemple d'Ada justement car c'est un vieux langage qui a un compilateur libre depuis longtemps, ce qui montre bien que la communauté libre n'est pas tellement intéressé par les langages "sécurisés".

Note que:
1) Haskell, Ocaml, Scala ont tous des GCs, pour certaines utilisations c'est un problème.
2) avoir des bonnes performances avec Haskell, c'est compliqué.
3) une JVM ça met du temps a démarrer donc Scala est a oublier pour coder des petits outils ou un démarrage rapide est nécessaire.
4) Rust n'est même pas encore en 1.0 (seulement 1.0 alpha pour le moment).

Y'avait quel compilateur Ada accessible librement quand OpenBSD a démarré ?

Loupé: OpenBSD date de fin 1995, la même année où il y a eu la première "validation officielle" de GNAT (dixit Wikipédia).

Bon ceci dit, OpenBSD est un fork de NetBSD qui est bien plus vieux que ça..

Ça ferait quelle quantité de code de reprendre tout ce qu'ils ont besoin en Ada ?

Mais n'oublions qu'OpenBSD c'est une distribution complète, donc ils pourraient remplacer progressivement des outils userspace du C en un langage plus sécurisé (en commençant par ceux qui sont suid root), ça serait déjà un bon début..

Pour ce qui est de la portabilité, certains langages compilent en C (par exemple Nim) donc ont -à priori- la même portabilité que le C.
NB: Nim était juste un exemple, la version 1.0 n'est pas encore sortie!

Et donc ta phrase "Pour l'instant il(Rust) bénéficie d'un effet de mode dans la lancée de Go." est fausse, d'autant plus que Go et Rust ciblent des domaines très différents qu'on peut résumer en un point: avec ou sans GC.

Go c'est avec GC, Rust sans.

En vrai, c'est plutôt que Ada c'est très bien sur le papier, mais que c'est un tue l'amour à réussir à passer la compilation (les inconvénients de ses avantages).

Pourtant Rust qui intéresse beaucoup de monde est/sera ENCORE PIRE de ce côté là..

Je pense que développer des fonctionnalités est considéré comme bien plus important que d'avoir ces fonctionnalités fiable/sécurisée.
Autrement on ne continuerai pas d'utiliser le C ou le C++ au lieu d'Ada (par exemple)..

C'est un choix tout à fait compréhensible, mais ne prétendons pas que les logiciels libres soient spéciaux concernant la sécurité ou la fiabilité..
J'avoue être tout de même surpris qu'OpenBSD qui est supposé mettre l'accent coté sécurité ait fait le même choix (utiliser un langage privilégiant la performance à la sécurité par défaut).

Ça dépend beaucoup de l'enfant je pense!

Je n'ai pas encore beaucoup d'expérience, mais j'ai noté que même sur des bébés de 6 mois, la différence de comportement avec le grand frère est impressionnante..

Je ne connais pas le format INFO mais il y a le format TOML qui est intéressant: https://github.com/toml-lang/toml

Bon ça n'est pas encore en version 1.0 et il n'y a pas de de spec BNF la spec (A)BNF est cachée dans une branche et je ne l'avais pas remarquée.

Hum, tu chiffre comment "l'apport en stabilité" d'un projet??

Sinon pour ce qui est de l'apport en mémoire/perf, ça sera probablement un chiffre négatif..

Après Chrome te permet (option de démarrage) de tout mettre dans le même processus, de mettre chaque onglet dans un processus séparé ou de limiter le nombre de processus en regroupant si besoin est plusieurs onglets par processus (le défaut), ce qui permet a l'utilisateur averti (je parie que quasiment personne ne connaît / fait ça(*)) de choisir son compromis performance/(sécurité|stabilité) comme il l'entend..

*: je m'inclus dans la liste: j'ai vu qu'il y avait ces options dans la BD amusante au lancement de Chrome et je ne les ai jamais utilisée..

Un vil scientifique de la mission Rosetta disait que pour des raisons de coût "Dans l'espace, on en fait jamais deux fois exactement la même expérience"

Amusant ton interprétation.. Mais pour ré-analyser le fond cosmique ils n'ont pas envoyé une deuxième sonde identique, ils en ont envoyée une plus précise!

Ceci dit, je crois que dans la médecine une très faible partie des résultats sont reproductibles (<50%): trop de pression et d'argent en jeux probablement.

Tu mets snowden en tag: si tu envois des emails en clair, alors il n'est pas improbable que la NSA y ai déjà accès quelque soit l'hébergeur des emails..

Comme chiffrer ses mails c'est pénible personne ne le fait, mais après s'indigner parce que la NSA y a accès.. Ce n'est pas un peu faire l'autruche?

lookup --> lockup / blockage

Il y a effectivement pas mal de gens qui ne savent pas ce qu'est un bit et ils vont donc penser à une bite, mais ce n'est pas un problème:ça donne l'opportunité de leur apprendre quelque chose. .

Je préfère bitouilleur (bidouilleur de bit) après ça restreint la définition à l'informatique..

Ça m'a fait pareil chez moi: click sur la page: affichage quasi-instantanée de la page avec le JPEG uniquement, moi: "tiens ça ne marche pas leur truc", un long moment plus tard(1sec?): affichage du BPG.
C'est un PC normal, mais avec la RAM bien chargé..
Donc le décodage Javascript du BPG N'EST PAS acceptable, mais c'est intéressant pour une démo.

Certains traduisent magalivre.

Personnellement le mot qui m'était venu à l'esprit: méga-magazine ou plus sympa: méga-zine.

C'est Français ça? Un petit google plus tard, bah je n'ai toujours pas bien compris le concept..

Bon un intermédiaire entre magazine et livre, OK, pas sûr que ça vaille un nouveau nom, surtout si laid..

Probablement oui. En tout cas, je n'aimerai pas naviguer sur le Web avec 32Mode mémoire..

Pourquoi ça marcherait pas pour Haiku si ça a marché pour Linux?

1) Parce que Linux existe déjà? Le pool de développeurs libre est limité..
2) Linux sur le desktop ça n'a pas si bien marché que ça..

Pour les diverses raisons que j'ai mentionnées par ailleurs:
- Faire un noyau et des drivers en C++, c'est pas courant et c'est un projet intéressant
- Le code du noyau et des drivers est propre et lisible (ce n'est pas toujours le cas de Linux)
- L'API entre les drivers et le noyau est compatible avec BeOS et surtout, est stable: un vieux driver continue de fonctionner meme s'il n'a pas été "mainliné". Dans Linux ces APIs changent quasi systématiquement d'une version à l'autre.<<

Sauf que toutes ces raisons ne concernent que les développeurs de la partie noyau, donc ce que tu écris c'est qu'implémenter un noyau est très intéressant pour des développeurs noyau, OK mais le reste du monde s'en fiche pas mal..

-Avoir la main sur le noyau permet d'implémenter les choses comme on veut, avec par exemple une IPC spécifique

La OK, effectivement le Linux de base n'a pas l'équivalent de l'IPC 'haute performance' de BeOS (Android si, inspiré de BeOS d'ailleurs), après est-ce que ça a un réel impact sur le ressenti utilisateur sur un PC 'normal'?
Difficile à dire, d'autant plus que Linux est plus performant a d'autres endroits..

Je passe sur l'histoire du gestionnaire de paquet et du noyau, oui toute utilisation de code externe a des conséquences mais bon même Haiku réutilise WebKit pour le navigateur web..

Mais pour contribuer à Cosmoe, d'un coup, y'a plus personne

1) Personne n'a dit que le développement de logiciel libre était rationnel.
2) Finaliser Haiku a l'air de prendre beaucoup de temps, un classique: la partie fun ça intéresse des gens mais peaufiner le bébé (ce qui est énormément de travail) là..

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.