pulkomandy a écrit 1703 commentaires

C'est (comme souvent) plus compliqué. Toujours dans le cas de Haiku, que je connaît bien.

Lorsque le projet a été lancé (en 2001, donc), Linux, c'était pas encore vraiment ça. Ubuntu n'existait pas, Debian était particulièrement compliquée à installer, la distribution à la mode, c'était Corel. Le support de l'USB arrivait à peine, le SMP était encore tout récent.

Il y avait en plus un problème de licence: dès le début, Haiku a choisi la licence MIT car elle permettrait, plus facilement que la GPL, de partager du code avec une éventuelle continuation propriétaire de BeOS. Utiliser un noyau Linux n'était donc pas possible.

Enfin, une des contraintes du projet était la compatibilité avec BeOS, sur tous les points, y compris les pilotes de périphériques (qui fonctionnent encore aujourd'hui sous Haiku). Et aussi, il y a des besoins spécifiques pour les APIs utilisateur auxquelles le noyau Linux n'aurait pas permis de répondre (je pense aux "ports", une IPC utilisée pour implémenter les BMessages et beaucoup d'autres choses dans Haiku).

D'ailleurs, le noyau de Haiku n'est pas parti de zéro, c'est un fork de NewOS, un noyau développé par un des ex-employés de Be qui travaille en ce moment sur Fuchsia chez Google.

Si c'était à refaire aujourd'hui, et sans la contrainte de compatibilité, il est probable qu'on utiliserait un noyau BSD (on emprunte du code chez FreeBSD, par exemple tous les drivers réseau).

Plus de lecture à ce sujet:
https://archive.fosdem.org/2016/schedule/event/could_haiku_become_bsd/

Et du code source (des morceaux de l'userland Haiku sur un noyau Linux ou BSD):
https://github.com/Ithamar/cosmoe

On parle toujours de Haiku, là? Parce que la config minimale, c'est 192Mo de RAM, pour un système en version alpha (donc pas spécialement optimisé) et en plus, avec un noyau compilé en mode debug "paranoïaque" qui consomme un peu plus de ressources que la version "release". ça fait donc 3 à 6 fois plus de RAM.

Les OS qui ont besoin de 60 à 120 fois plus de RAM que AmigaOS3, je sais pas comment ils font pour tout remplir.

Et, oui, Haiku implémente l'ASLR, des systèmes de fichiers journalisés, la protection mémoire, la swap, etc.

Pourquoi le C++ n'est-il pas un standard publié (aussi) par l'ECMA?
Ils ont la bonne idée de proposer le téléchargement gratuit des PDF de leurs standards, par exemple dans la catégorie "langages de programmation" pour C#, EcmaScript, Eiffel, et Dart. Mais aussi plein d'autres choses comme le système de fichier "ISO9660" pour les CDROM, le JSON, les codes de contrôles "ANSI" (ECMA-48), le format physique des disquettes 3.5", et plein d'autres trucs.

Le monde serait plus triste sans http://hannahmontana.sourceforge.net/ et http://biebian.sourceforge.net/ .

Je pense que oui, mais sans accélération 3D, ça risque d'être lent. Je n'ai pas eu le temps de l'essayer.

Haiku est à peu près compatible POSIX, même s'il propose d'autres choses en plus et qu'il manque encore certains morceaux. Cela dit, c'est intéressant d'avoir un OS entier développé par la même équipe et ça permet d'expérimenter et de réaliser plein de choses qui seraient beaucoup plus difficiles autrement.

Et dans les OS libres, il y en a plein d'autres. Citons au hasard AROS, FreeDOS, OpenDOS, KolibriOS, Syllable. Certains beaucoup plus éloignés de POSIX que Haiku (je pense par exemple à Oberon

Utiliser Haiku pour la sécurité est une mauvaise idée, c'est de la sécurité par l'obscurité, ça ne marche pas très fort. On utilise quand même souvent les mêmes briques logicielles (OpenSSL, etc) et ce n'est pas forcément tout correctement intégré (on a pas de spécialistes en sécurité). Il vaut mieux aller voir du côté d'OpenBSD qui essaient de faire ça sérieusement, par exemple.

Par contre, tu as raison sur le fait que c'est bien d'avoir des systèmes différents pour des utilisations différentes. Haiku cible, pour cette raison, les ordinateurs personnels (pas les serveurs, pas les ordiphones, et pas non plus les systèmes embarqués). Le noyau Linux s'en sort plus ou moins bien dans chacun de ces domaines mais je ne pense pas qu'il puisse être parfait pour tout à la fois.

Il n'y a pas de noyau Linux dedans, donc ça serait plutôt un "Ubuntu GNU/Windows"? Mais il faudra l'expliquer aux gens de Microsoft qui n'ont pas trop bien compris et parlent de Linux sur Windows, alors que Linux est justement le seul morceau des systèmes GNU/Linux qu'ils n'utilisent pas!

Bonjour,

Pour ma part sur le projet Haiku, c'est l'OS que j'utilise sur mes machines chez moi, et je n'ai pas toujours le choix que de faire en sorte que ça fonctionne.

Il y a un côté expérience professionnelle (mettre sur son CV "j'ai codé une pile logicielle de gestion de l'USB3", ça fait classe). Et comme en plus le code est ouvert, un éventuel employeur peut aller fouiller dedans pour voir ce que ça vaut vraiment. Pour ma part, j'ai même eu la chance de travailler à plein temps sur Haiku pendant un an, en étant rémunéré par les dons de la communauté des utilisateurs. C'est une expérience enrichissante.

Avec Haiku, j'ai:
- Eu un job d'été pendant 2 ans lorsque j'étais étudiant (Google Summer of Code en 2009, puis un contrat directement avec Haiku, inc pendant l'été 2010),
- Appris le C++,
- Encadré des étudiants lors du Google Summer of Code, et des lycéens (13-17 ans) dans le cadre du Google Code-In,
- Appris à travailler en équipe dans un gros projet et à gérer des millions de lignes de code, avec svn puis git, et d'autres outils comme la gestion de tickets, les mailing lists, ou IRC,
- Appris à travailler à distance et en horaires décalés avec d'autres contributeurs, ce qui est bon pour l'autonomie,
- Travaillé à plein temps pendant un an sur un projet intéressant (la mise à jour du port de WebKit pour Haiku et de la pile HTTP en dessous),
- Rencontré plein de gens en animant des stands et présentations dans différentes conférences autour de Haiku et du logiciel libre,
- Le plaisir d'utiliser un OS auquel je peux contribuer pour résoudre des bugs et ajouter des fonctionalités,
- L'occasion de contribuer à plein d'autres projets (WebKit, SDL par exemple),
- Sûrement plein d'autres trucs que j'ai oublié où dont je ne me suis pas rendu compte.

En tout cas, j'ai appris plein de choses, rencontré plein de gens, et écrit des logiciels parfois plus utilisés que ce que j'ai fait dans le cadre d'un emploi "normal" d'ingénieur en informatique (ou il m'est arrivé de passer plus d'un an sur un projet qui a fini à la poubelle).

Dans les raisons qui ont conduit à la création de Haiku, il y avait aussi un besoin d'assurer une continuité après la fin de BeOS, pour la survie du petit écosystème qui s'était développé autour de ce dernier. Donc, on a des gens qui se sont mis à contribuer à un OS libre, pour pouvoir vendre leurs logiciels commerciaux, éventuellement non libres, fonctionnant dessus. On cite comme exemple (et c'est probablement le seul actuellement pour Haiku) TuneTracker Systems, qui fournit un système de gestion de stations radio fonctionnant entièrement sous Haiku depuis quelques années, et BeOS précédemment.

Mais donc j'ai pas compris, c'est quoi le problème avec Rainloop? Chez moi c'est lui qui a gagné.

C'est pourtant écrit en gros sur le graphique:
https://github.com/konimex/linuxtimeline

Je ne pense pas: la capture se fait forcément en entrelacé qui est le format de l'enregistrement sur la VHS. Par contre, on doit pouvoir ajouter toutes sortes de filtres, y compris de désentrelacement. Je ne sais pas ou cela se trouve dans VLC, peut-être dans le menu Vidéo?

Les Thinkpad chez Lenovo arrivaient à rentrer un clavier avec peu de concessions de ce genre sur leurs machines 12" (par exemple, le X200 que j'ai chez moi). Effectivement ce sont des machines coûteuses si on les achète neuves, mais il n'y a pas de raisons que ça ne sois pas possible sur une machine moins chère?

Les 4 flèches font 2/3 de la hauteur d'une touche normale, et il y a un pavé avec les touches home/end/page up/page down séparé, comme ceci:

Quand tu utilises un cable S-Video, c'est le magnétoscope qui sépare les canaux de luminance et chrominance qui sont de toutes façons enregistrés ensemble sur la bande. Quand tu utilises un câble composite, c'est fait par le PC. Il est possible que ton PC sache faire ça mieux que ton magnétoscope, et du coup, le résultat peut très bien être meilleur, suffisament pour compenser les pertes dues au transport des 2 infos sur un seul fil dans le câble composite.

C'est pas les premiers à choisir leur nom n'importe comment:
https://wiki.debian.org/WhyTheName

C'est un des problèmes réglés par le PAE. Quand il faut absolument tout faire rentrer dans des adresses 32 bits, y compris les adresses physiques, on ne peut avoir que 4Go d'espace mémoire.

Avec PAE, les adresses logiques (donc les pointeurs vus par les applications) sont toujours en 32 bits, par contre les adresses physiques sont en 64 bits. Du coup, on peut mapper toute la RAM (même s'il y a 4Go ou plus) plus les périphériques sans problème. Ensuite, chaque application dispose d'une ou plusieurs fenêtres qui permettent de voir des morceaux de cet espace (la RAM qu'elles ont allouées, les périphériques auxquels elles ont le droit d'accéder). Et du coup, toute la RAM peut être utilisée, du moment qu'elle est partagée entre plusieurs applications (ce qui est quand même souvent le cas).

Sur x86 on a fait de l'adressage segment:offset pendant longtemps (avec donc des adresses logiques 32 bits, des adresses physiques 20 bits, puis plus tard 32 bits, et des registres d'une largeur de 16 bits). Ce n'est qu'à partir du 386 qu'une gestion un peu plus "moderne" de la mémoire a commencé à apparaître, avec des registres 32 bits et un espace mémoire également 32 bits.

Concrètement, il y a des pointeurs "near" (pointant dans le "même" segment), et des pointeurs "far" (pointant sur un segment spécifique). Avec différents modèles d'allocation de la mémoire aux applications (toute l'application dans un seul segment, un segment de code + un segment de données, plusieurs segments de chaque).

C'est pas des plus confortable, mais ça peut marcher.

Pour Haiku, c'est en train de changer dourcement. On a peu de resources et on se concentre sur la version 32 bits (et gcc2!) pour le moment car c'est la seule compatible avec BeOS. Dès qu'on aura le support des applications 32bits sur un noyau 64, on n'hésitera pas à passer plus sérieusement au 64bit.

C'est donc un cas particulier lié à un héritage historique et des contraintes de compatiblité.

(et pour MenuetOS, il vaut peut être mieux regarder du côté du fork KolibriOS qui semble un peu plus actif et impliqué dans le libre en général).

On peut aussi citer AROS et ReactOS mais j'ai la flemme d'aller voir où en est leur support du 64-bits :)

Je comprend pas bien…

Le PAE permet au noyau de l'OS de gérer plus de 4Go de RAM, tout en exposant à chaque application un espace de 4Go. Donc, pour les applications qui n'ont pas besoin de 4Go dans un seul process, c'est transparent et ça marche très bien (et côté noyau, franchement, on est plus à un truc moche près…).

L'espace RAM en plus peut aussi être utilisé avec un adressage 64bit par exemple pour des caches disque ou d'autres trucs dont le noyau aurait besoin.

Après, de nos jours, l'intérêt est discutable et je ne vois pas de raison de ne pas tout mettre en 64bit.

Une ISA qui reflète trop le fonctionnement interne du CPU a un autre problème: ça devient compliqué d'implémenter la même ISA avec une architecture interne différente. Et quand on voit la durée de vie de l'ISA du x86, ou encore plus longue du jeu d'instruction du 8051 de chez Intel, il vaut mieux faire un truc qui laisse un peu de liberté du côté du design du CPU.

Si je me rappelle bien, ce documentaire sort (un peu?) Weleda du lot. Mais les recettes de shampoing chez eux ont l'air quand même un peu plus compliquées que celle du Journal:
https://www.weleda.fr/product/s/shampooing-usage-frequent-au-millet

(au moins il y a une "traduction" en français de la composition, avec des liens détaillant chaque ingrédient).

de toutes façons cela semble normal qu'une entreprise cherche à faire des profits. Il reste plus qu'à leur prouver qu'il y a un marché pour le bicarbonate de soude goût citron! Et à vérifier ce qu'il y a vraiment dans les agréments pour le bicarbonate de cuisine/cosmétique pour être sur de ce qu'on achète et s'il faut se méfier des produits qui n'ont pas cet agrément (par exemple je vois que Starwax propose les deux: http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude / http://www.starwax.fr/produit/les-indispensables/bicarbonate-soude-alimentaire [mais pas encore la version au citron!])

Oui mais y'en a un qui est naturel, et l'autre chimique!

Sans installation de logiciels, il y a aussi des clients XMPP qui se lancent dans un navigateur web sans rien installer. J'utilisais il y a quelque temps https://jwchat.org/, on a peut-être fait mieux depuis?

Chez moi c'est IceWM pour le WM et Gentoo pour le gestionnqire de fichier (pas la distrib, l'autre).

Petite astuce: il existe un outil xdg-open qui trouve une application par défaut en fonction du type de fichier. Je l'utilise comme action par défaut pour le double clic dans Gentoo, je suppose qu'on peut faire pareil dans ROX. Comme ça il ne reste plus qu'à paramétrer les cas particuliers.

Si vous ne changez pas à Strasbourg, vous allez tout droit en ALLEMAGNE!

http://michel.buze.perso.neuf.fr/lavache/chevalier_laspales_le_train_pour_pau.htm

XKCD^WCommitStrip pertinent: http://www.commitstrip.com/fr/2016/06/20/coder-bingo/