C'est un bon point de départ. Il manque quelques trucs dans les possibilités de "styles" mais on s'en sort avec quelques outils autour (un makefile et quelques astuces à base de cat pour concaténer des fichiers).
Il y a une interface graphique pour Windows, avec un apperçu du rendu et un éditeur (pas terrible). Il y a bien sur un outil en ligne de commande pour générer le graphe. Il y a une intégration dans Microsoft Office sous forme d'objets OLE, mais c'est un peu gadget.
Il manque un export en format vectoriel de qualité, même l'export en SVG a certaines parties du diagramme rendues en bitmap, et du coup ça pixellise quand on veut intégrer les SDL à un document imprimé.
En tout cas, il serait appréciable de garder une syntaxe proche de mscgen et/ou msc-generator (qui a quelques variantes). ça permettra aux gens de migrer vers ton outil.
Enfin, Python est facile à installer sous Windows. Alors qu'une chaîne de compilation pour du C/C++, c'est moins facile.
Avec le même CPU, il y a aussi l'Utilite chez Compulab, qui a un port mSATA en interne. Mais c'est donc pour mettre un SSD et pas un grod disque tournant.
Les paquets sont montés dans un "packagefs" qui fusionne les fichiers fournis par tous les paquets (plus des fichiers de configuration stockés directement sur la partition système dans certains dossiers). Du coup, c'est transparent pour les applications (sauf qu'elles ne peuvent plus écrire dans les dossiers qui sont composés uniquement du contenu des packages).
C'est un "vrai" système de fichier, pas de FUSE. D'ailleurs, le noyau de Haiku est lui-même stocké dans un paquet (non compressé, celui là), et il est extrait par le bootloader au démarrage du système.
Autre avantage: lors d'une mise à jour, on stocke les anciennes versions des paquets dans un dossier "state". Le bootloader est capable de booter une ancienne version du système stockée de cette façon, ce qui est très pratique en cas de mise à jour qui casse tout.
Les paquets sont stockés compressés sur le disque dur. Le format de compression utilisé (par blocs de 4K) permet de décompresser à la volée quand les fichiers du paquets sont lus (et la version décompressée est stockée dans le cache de fichiers en RAM).
Du coup, l'installation d'un paquet (ou même de centaines de paquets) est très rapide, il y a juste à copier les paquets dans /system/packages. Et la suppression est aussi très simple, puisqu'il y a juste à supprimer le paquet, et pas besoin de suivre les douzaines de fichiers installés un peu partout sur le disque.
Il faut bien comprendre aussi que quand quelqu'un choisit de ne pas contribuer ses changements upstream, c'est pas l'upstream qui va avoir des problèmes pour faire les merges à chaque nouvelle version ou les backports de bugfixes dans son fork.
On a pas besoin de la GPL pour faire comprendre ça aux gens. Il faut qu'ils se rendent compte que c'est dans leur intérêt de contribuer leur code, pas parce qu'ils risquent de se prendre un procès ou de pourrir leur image, mais parce que sur le moyen et le long terme, ça leur fera gagner plein de temps.
J'en sais quelque chose: mon travail en ce moment consiste en partie à faire des backports et des merges de ce genre sur du code en BSD ou MIT. C'est chiant, et si les changements avaient été versés upstream, y'aurait pas besoin de le faire.
La GPL, elle sert à forcer les gens à publier leurs changements, dans leur intérêt. Le but est noble, mais le moyen me semble pas terrible.
Sauf que si on attaque jamais personne, ceux qui jouent le jeu diffusent leur code à l'avantage de leurs concurrents qui ne le diffusent pas. Et sur le long terme, ils vont voir qu'on leur a vendu les avantages de la GPL (que tout le monde doit jouer le jeu, ce qui rend les choses équitables et permet un retour sur l'investissement qu'est l'effort de publier les sources), sauf qu'en fait, ce qui jouent le jeu, ils ont que les inconvénients, et les autres, ils ont que les avantages.
Sur le court terme, ça marche, mais au bout d'un moment, y'en a qui en auront marre de se faire avoir comme ça. Est-ce qu'ils porteront plainte eux-même contre les concurrents qui ne jouent pas le jeu de la GPL? Possible, après avoir contribué du code (pas avant: c'est seulement le détenteur du copyright qui peut attaquer).
Il n'y a pas beaucoup d'entreprises qui développent des produits pour ne pas les diffuser (en les vendant, en général). Mais oui, techniquement, la GPL oblige à fournir les sources lors de toute diffusion des binaires.
La GPL, c'est pour forcer les gens à diffuser leur code. Si on ne le fait pas, ça sert à rien.
Personnellement, je préfère effectivement expliquer aux gens que le libre c'est mieux et que tout le mone peut y gagner. Mais j'utilise la licence MIT quand j'ai le choix pour le code que j'écris. Ainsi je ne force personne à me suivre.
Si on fait de la GPL mais qu'en fait on ne se défend pas contre les gens qui ne la respectent pas, ça va devenir difficile de "vendre" cette licence, dont l'intérêt est justement que les gens doivent la respecter et partager leurs changements. Si on n'oblige personne à le faire, alors les gens qui ne veulent pas contribuer de cette façon pourront prendre le code sans contrepartie.
pour avoir plus léger il faut taper dans des moteurs alternatifs, genre Vivaldi pour n'en citer qu'un.
Mauvaise pioche: le navigateur Vivaldi utilise le moteur Blink (alors qu'il a été créé suite à la décision chez Opera d'utiliser… Blink!).
ça devient compliqué de trouver des moteurs alternatifs. Dans les libres, il y a bien NetSurf et Dillo, mais c'est loin d'avoir toutes les fonctionnalités nécessaires. Dans les non libres, il y a Presto (qui est toujours utilsé par Opera Mini, mais plus par Opera Desktop), et NetFront. Peut-être que Servo viendra un peu relancer les choses?
Oui enfin préférer miser sur "une éventuelle continuation propriétaire de BeOS" plutôt que sur Linux (même en 2001), comment dirais-je?
Cela a bien fonctionné avec Zeta, pendant plusieurs années, certains développeurs contribuant aux deux projets.
Pour les noyaux BSD et Linux, à l'époque le support du SMP était à base de Giant Lock, pas du tout en ligne avec ce que Haiku voulait faire. Il manquait la compatibilité des drivers avec BeOS qui était un des buts du projet. Et comme je l'ai indiqué, il manquait du support dans les noyaux Linux et BSD pour pas mal de choses, qu'il aurait fallu ajouter, en particulier au niveau des IPC qui permettent à différents processus de communiquer entre eux.
Il aurait donc fallu forker un de ces noyaux, et il aurait été difficile d'upstreamer les patches (encore aujourd'hui, Android a du mal à le faire pour des raisons similaires).
Alors c'est sûr que 15 ans plus tard avec un peu de recul, on peut dire que ça n'a pas été la meilleure décision prise dans l'histoire du projet. Mais ce n'était pas forcément évident à l'époque.
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).
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.
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!
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.
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?
# msc-generator
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Écrire des diagrammes de séquences. Évalué à 5.
Il y a msc-generator, qui est plus ou moins basé sur mscgen avec plein de fonctions en plus: https://sites.google.com/site/mscgen2393/
C'est un bon point de départ. Il manque quelques trucs dans les possibilités de "styles" mais on s'en sort avec quelques outils autour (un makefile et quelques astuces à base de cat pour concaténer des fichiers).
Il y a une interface graphique pour Windows, avec un apperçu du rendu et un éditeur (pas terrible). Il y a bien sur un outil en ligne de commande pour générer le graphe. Il y a une intégration dans Microsoft Office sous forme d'objets OLE, mais c'est un peu gadget.
Il manque un export en format vectoriel de qualité, même l'export en SVG a certaines parties du diagramme rendues en bitmap, et du coup ça pixellise quand on veut intégrer les SDL à un document imprimé.
En tout cas, il serait appréciable de garder une syntaxe proche de mscgen et/ou msc-generator (qui a quelques variantes). ça permettra aux gens de migrer vers ton outil.
Enfin, Python est facile à installer sous Windows. Alors qu'une chaîne de compilation pour du C/C++, c'est moins facile.
[^] # Re: Wandboard
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du stockage, du stockage :). Évalué à 1. Dernière modification le 08 septembre 2016 à 15:45.
Avec le même CPU, il y a aussi l'Utilite chez Compulab, qui a un port mSATA en interne. Mais c'est donc pour mettre un SSD et pas un grod disque tournant.
[^] # Re: J'ai déjà entendu ça quelque part
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Tout simplement E P I Q U E. Évalué à 6.
Je voulais faire un journal, et puis, trop la flemme!
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 6.
Les paquets sont montés dans un "packagefs" qui fusionne les fichiers fournis par tous les paquets (plus des fichiers de configuration stockés directement sur la partition système dans certains dossiers). Du coup, c'est transparent pour les applications (sauf qu'elles ne peuvent plus écrire dans les dossiers qui sont composés uniquement du contenu des packages).
C'est un "vrai" système de fichier, pas de FUSE. D'ailleurs, le noyau de Haiku est lui-même stocké dans un paquet (non compressé, celui là), et il est extrait par le bootloader au démarrage du système.
Autre avantage: lors d'une mise à jour, on stocke les anciennes versions des paquets dans un dossier "state". Le bootloader est capable de booter une ancienne version du système stockée de cette façon, ce qui est très pratique en cas de mise à jour qui casse tout.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 2.
Les paquets sont stockés compressés sur le disque dur. Le format de compression utilisé (par blocs de 4K) permet de décompresser à la volée quand les fichiers du paquets sont lus (et la version décompressée est stockée dans le cache de fichiers en RAM).
Du coup, l'installation d'un paquet (ou même de centaines de paquets) est très rapide, il y a juste à copier les paquets dans /system/packages. Et la suppression est aussi très simple, puisqu'il y a juste à supprimer le paquet, et pas besoin de suivre les douzaines de fichiers installés un peu partout sur le disque.
[^] # Re: Pas logique ou militant licence MIT
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 3.
Il faut bien comprendre aussi que quand quelqu'un choisit de ne pas contribuer ses changements upstream, c'est pas l'upstream qui va avoir des problèmes pour faire les merges à chaque nouvelle version ou les backports de bugfixes dans son fork.
On a pas besoin de la GPL pour faire comprendre ça aux gens. Il faut qu'ils se rendent compte que c'est dans leur intérêt de contribuer leur code, pas parce qu'ils risquent de se prendre un procès ou de pourrir leur image, mais parce que sur le moyen et le long terme, ça leur fera gagner plein de temps.
J'en sais quelque chose: mon travail en ce moment consiste en partie à faire des backports et des merges de ce genre sur du code en BSD ou MIT. C'est chiant, et si les changements avaient été versés upstream, y'aurait pas besoin de le faire.
La GPL, elle sert à forcer les gens à publier leurs changements, dans leur intérêt. Le but est noble, mais le moyen me semble pas terrible.
[^] # Re: Mauvaise licence, changer licence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 5.
Sauf que si on attaque jamais personne, ceux qui jouent le jeu diffusent leur code à l'avantage de leurs concurrents qui ne le diffusent pas. Et sur le long terme, ils vont voir qu'on leur a vendu les avantages de la GPL (que tout le monde doit jouer le jeu, ce qui rend les choses équitables et permet un retour sur l'investissement qu'est l'effort de publier les sources), sauf qu'en fait, ce qui jouent le jeu, ils ont que les inconvénients, et les autres, ils ont que les avantages.
Sur le court terme, ça marche, mais au bout d'un moment, y'en a qui en auront marre de se faire avoir comme ça. Est-ce qu'ils porteront plainte eux-même contre les concurrents qui ne jouent pas le jeu de la GPL? Possible, après avoir contribué du code (pas avant: c'est seulement le détenteur du copyright qui peut attaquer).
[^] # Re: Mauvaise licence, changer licence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 2.
Un lien sur un changement de licence un peu similaire, de CC-BY-SA à CC-0, et les raisons qui ont conduit à le faire:
http://blog.ninapaley.com/2013/01/18/ahimsa-sita-sings-the-blues-now-cc-0-public-domain/
[^] # Re: Mauvaise licence, changer licence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 3.
Il n'y a pas beaucoup d'entreprises qui développent des produits pour ne pas les diffuser (en les vendant, en général). Mais oui, techniquement, la GPL oblige à fournir les sources lors de toute diffusion des binaires.
# Mauvaise licence, changer licence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 10.
La GPL, c'est pour forcer les gens à diffuser leur code. Si on ne le fait pas, ça sert à rien.
Personnellement, je préfère effectivement expliquer aux gens que le libre c'est mieux et que tout le mone peut y gagner. Mais j'utilise la licence MIT quand j'ai le choix pour le code que j'écris. Ainsi je ne force personne à me suivre.
Si on fait de la GPL mais qu'en fait on ne se défend pas contre les gens qui ne la respectent pas, ça va devenir difficile de "vendre" cette licence, dont l'intérêt est justement que les gens doivent la respecter et partager leurs changements. Si on n'oblige personne à le faire, alors les gens qui ne veulent pas contribuer de cette façon pourront prendre le code sans contrepartie.
[^] # Re: Lapin compris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche À Toulouse, ouverture d'une formation de développeur d'Applications « full-stack ». Évalué à 3.
Développeur maison = développeur façade + développeur fondations ?
[^] # Re: Toutes ces années de dev
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 3.
Mauvaise pioche: le navigateur Vivaldi utilise le moteur Blink (alors qu'il a été créé suite à la décision chez Opera d'utiliser… Blink!).
ça devient compliqué de trouver des moteurs alternatifs. Dans les libres, il y a bien NetSurf et Dillo, mais c'est loin d'avoir toutes les fonctionnalités nécessaires. Dans les non libres, il y a Presto (qui est toujours utilsé par Opera Mini, mais plus par Opera Desktop), et NetFront. Peut-être que Servo viendra un peu relancer les choses?
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 7.
Cela a bien fonctionné avec Zeta, pendant plusieurs années, certains développeurs contribuant aux deux projets.
Pour les noyaux BSD et Linux, à l'époque le support du SMP était à base de Giant Lock, pas du tout en ligne avec ce que Haiku voulait faire. Il manquait la compatibilité des drivers avec BeOS qui était un des buts du projet. Et comme je l'ai indiqué, il manquait du support dans les noyaux Linux et BSD pour pas mal de choses, qu'il aurait fallu ajouter, en particulier au niveau des IPC qui permettent à différents processus de communiquer entre eux.
Il aurait donc fallu forker un de ces noyaux, et il aurait été difficile d'upstreamer les patches (encore aujourd'hui, Android a du mal à le faire pour des raisons similaires).
Alors c'est sûr que 15 ans plus tard avec un peu de recul, on peut dire que ça n'a pas été la meilleure décision prise dans l'histoire du projet. Mais ce n'était pas forcément évident à l'époque.
[^] # Re: Sauter le pas !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Appel aux fabricants de liseuse. Évalué à 9.
Sur certains Kindle d'Amazon, il est assez facile d'avoir accès au système Linux caché dessous (avec un accès SSH par wifi ou par le port USB):
http://wiki.mobileread.com/wiki/Kindle4NTHacking#Jailbreak
et ensuite d'installer ce qu'on veut (Debian dans un chroot, par exemple):
http://wiki.mobileread.com/wiki/Debian_Installation_on_Kindle_Touch
Ou simplement stopper le service qui fait tourner l'UI Amazon:
/etc/init.d framework stop
Et ensuite faire autre chose avec l'écran et les boutons, par exemple s'en servir pour afficher la météo du jour:
https://fnordig.de/2015/05/14/using-a-kindle-for-status-information/
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 9.
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
[^] # Re: Toutes ces années de dev
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 4.
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.
# ECMA
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Les coulisses du standard C++. Évalué à 4.
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.
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 8.
Le monde serait plus triste sans http://hannahmontana.sourceforge.net/ et http://biebian.sourceforge.net/ .
[^] # Re: Godot ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 4.
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.
[^] # Re: Une autre philosophie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 10.
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.
[^] # Re: Random OS generator
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal PowerShell sur Linux. Évalué à 10.
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!
[^] # Re: Comment ils font ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 15 ans. Évalué à 10.
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.
# Rainloop
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal À la recherche des clients mail sous Linux. Évalué à 2.
Mais donc j'ai pas compris, c'est quoi le problème avec Rainloop? Chez moi c'est lui qui a gagné.
[^] # Re: GNU/Linux timeline
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Debian a 23 ans. Évalué à 1.
C'est pourtant écrit en gros sur le graphique:
https://github.com/konimex/linuxtimeline
[^] # Re: désentrelacement ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Numérisation de cassettes VHS avec VLC. Évalué à 4.
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?