ça marche aussi avec qemu et virtualbox, pour parallels je ne sais pas.
Si tu as essayé la version alpha de novembre 2012, peut être il vaut mieux tester un nightly build récent: http://download.haiku-os.org. Et inversement…
Avant la fin de Be, il y a eu un effort désespéré et de dernière minute pour libérer le code. Mais c'était déjà trop tard. On a quelques indices:
- Le code de la DeskBar (la barre des tâches) et du Tracker (le navigateur de fichiers) ont été libérés, et sont utilisés par Haiku.
- Une version "fuitée" de BeOS appelée "Dano" a été diffusée. Elle comporte plusieurs petits changements, mais en particulier remplace une bibliothèque SSL propriétaire par OpenSSL dans le navigateur web.
- Binder était une nouveauté prévue pour BeOS. Ce projet a été publié par Palm sous la forme d'OpenBinder, et il est nu des composants principaux d'Android. D'ailleurs une partie des développeurs de BeOS sont aujourd'hui employés par Google pour travailler sur Android.
Quelques fonctions de BeOS ont été intégrées dans PalmOS (dans la version 6, "Cobalt"). Donc on ne peut pas non plus dire que Palm n'a rien fait avec.
D'autre part, la socciété allemande Yellowtab a pu continuer pendant quelque temps le développement de BeOS (sous le nom de Zeta) après la fin de Be. Une possible collaboration entre Yellowtab (ou Palm) et Haiku était envisagée dès les débuts de Haiku, c'est d'ailleurs la raison du choix de la license MIT plutôt que de la GPL (afin de permettre l'utilisation du code de Haiku dans un projet commercial réuitlisant également des parties de BeOS). Cela a fonctionné quelques temps avec Yellowtab, mais ils n'ont pas trouvé de modèle commercial viable. Par la suite, une société appelée Magnussoft a continué à distribuer Zeta mais il n'y a plus vraiement eu d'évolutions, et finalement ils ont eu des soucis avec Access corporation (qui a récupéré les droits de BeOS après que PalmSource ait coulé… vous suivez?) car il semblerait que le contrat qui leur permettait d'utiliser les sources de BeOS se soit perdu en route quelque part.
Le choix de refaire un OS complet a au moins deux raisons. D'abord, au lancement du projet, Linux n'était pas du tout ce qu'il est aujourd'hui. En 2001, la distribution à la mode pour avoir un PC facile à utiliser, c'était Mandrake 8 ou Corel Linux. C'était très loin de ce que pouvait faire BeOS, et il manquait au noyau plein de petites choses qui faisaient que ça ne semblait pas être une solution viable.
De plus, un des buts du projet était de préserver la compatibilité avec BeOS, y compris pour les pilotes de périphériques (à l'époque le support était à peu près aussi bon que sous Linux, et les gens intéressés par Haiku avaient plutôt des machines compatibles avec BeOS).
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? Pourquoi continuer GTK alors que Qt est libre aujourd'hui?
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). Alors oui, tout ce qu'on peut faire avec Haiku, on peut aussi le faire avec un GNU/Linux récent, mais en utilisant une douzaine de bibliothèques, chacune avec son API différente, chacune avec ses développeurs, son bugtracker, sa mailing list de support. C'est ça qui rend compliqué le développement d'une application. Et ça c'est sans parler des problèmes d'intégration entre applications utilisant des bibliothèques différentes.
En fait, le problème vient surtout du matériel. Pour l'accélération 2D, à l'époque de BeOS les cartes savaient faire des copies et des remplissages de rectangles, mais aussi du tracé de lignes et d'autres opérations utiles. Déjà à l'époque certaines cartes étaient plus lentes que le CPU sur certaines opérations, et donc c'était délicat de bien utiliser ces fonctions.
Aujourd'hui, les fonctions 2D cablées ont disparu des cartes graphiques, l'accélération se fait via un GPU générique. Il faut donc un driver plus complexe permettant de programmer ce GPU et exposer une API qui va bien (OpenGL pour la 3D, OpenVG pour la 2D). Quand on aura ça, on pourra faire de nouveau de l'accélération 2D.
Le support est présent dans certains drivers (pour les vieilles cartes, donc) et on peut même utiliser les pilotes de BeOS dans Haiku puisqu'ils sont compatibles au niveau binaire. Mais l'app_server (notre équivalent de X11) n'utilise pas ces fonctions, pour les 2 raisons mentionnées: c'est plus lent et c'est moche car il n'y a pas d'antialiasing. Si quelqu'un se propose pour maintenir la version accélérée de l'app_server, les patches seraient acceptés sans problème. Mais, à mon avis, il est plus intéressant d'avoir d'abord la 3D accélérée (car là le CPU n'est pas encore assez puissant - encore que, on fait tourner de la 3D d'il y a 15 ans en rendu logiciel aujourd'hui). Pour la 2D on verra plus tard.
Enfin, quand je parle de machines "récentes", pour moi c'est "moins de 10 ans". J'ai encore un PC qui date de 2003 en état de marche (avec un peu plus de RAM qu'à l'origine il est vrai). Sur cette machine les performances de Haiku sont tout à fait acceptables (c'est un Athlon XP 2200+ avec 1Go de RAM). Je ne pense pas qu'on puisse avoir des performances acceptables sur une machine d'il y a 20 ans (un des tout premiers pentium de 1994): même si l'OS pouvait fonctionner, il serait impossible de lire une vidéo dans un format moderne (et même un MP3 ça risque d'être compliqué), ou d'afficher la moindre page web pleine de CSS et de Javascript. ça ferait donc un système rapide, mais quasi inutile.
Déjà, le noyau de Haiku est toujours en mode "debug" (avec plein de vérifications, écrasement systématique de la mémoire libérée, etc) de façon à détecter et pouvoir déboguer plus facilement les problèmes (et il y en a!). Recompiler le noyau en mode "release" sans tous ces controles permet de gagner en vitesse.
Comme je l'ai indiqué, il n'y a pas d'accélération 2D, et tout l'affichage se fait avec de l'antialiasing; c'est beau, mais c'est lent. Et en plus c'est en double buffer (ce n'était pas le cas pour BeOS) et l'un des deux buffers est en RAM centrale (l'accès en lecture à la RAM vidéo via le BUS AGP étant trop lent).
Enfin, le gestionnaire de paquets qui est implémenté sous forme d'un système de fichiers virtual a besoin de RAM pour garder en cache les fichiers extraits des paquets (un peu comme un DriveSpace pour ceux qui connaissent). Et plein d'autres choses que BeOS ne faisait pas, comme la gestion du wifi, par exemple.
Un navigateur web de l'époque de BeOS (NetPositive ou Opera 3) fonctionnera sous Haiku par exemple, mais pour naviguer sur internet, c'est difficile. Meme chose pour lire la moindre vidéo, de nos jours tout est en full-HD en h.264 que meme mon Core 2 duo a un peu de mal à décoder en temps réel. Alors pour faire la meme chose qu'il y a 15 ans, ça pourrait marcher sur le matériel d'époque (avec un peu d'efforts), mais il est je pense plus intéressant de fonctionner sur des machines un peu plus récentes (disons moins de 10 ans) et d'avoir des fonctionalités modernes pour une utilisation moderne. De toutes façons, sur un Pentium avec 32Mio de mémoire, BeOS continue de fonctionner comme il le faisait déjà il y a 15 ans, non?
Malhereusement non!
La plupart des frameworks ont un seul thread qui fait tout.
Dans BeOS et dans Haiku, la moindre application a au moins 3 threads:
- Le thread de l'application, qui fait les traitements longs
- Le thread de la fenêtre, qui répond aux actions de l'utilisateur
- Et un thread dans le serveur graphique, qui dessine la fenêtre
Alors oui, c'est possible de faire la même chose avec d'autres frameworks, mais c'est tout un bazar (avec des problèmes de synchronisation) et personne (ou pas beaucoup de gens) ne le fait.
Les APIs de BeOS et de Haiku sont conçues pour limiter les problèmes. La communication entre ces threads se fait via des messages (similaires aux signaux/slots de Qt) qui permettent d'échanger des données sans avoir à traiteer soi même les problèmes de synchronisation. Donc, quand l'utilisateur clique sur un bouton, le thread de la fenÛêtre réagit au quart de tour (il a rien d'autre à faire, en même temps), et tout ce qu'il fait, c'est transmettre le message:
- Au thread de l'application: "clic sur le bouton x" (pour lancer un traitement quelconque)
- Au thread du serveur graphique (pour redessiner le bouton)
Avec ce système il est difficile d'avoir une fenêtre gelée (à moins de le faire exprès). L'utilisation de la plupart des autres systèmes m'est insupportable avec des curseurs en sablier ou en ballon de plage à chaque clic.
En ce qui concerne les autres projets morts, il s'agit de BlueEyedOS (une implémentation des API de BeOS sur une base GNU/Linux/X classique) et de Cosmoe (un portage de l'espace utilisateur de Haiku sur un noyau Linux ou BSD). Ce dernier est de nouveau vivant depuis le coding sprint BeGeistert, ça se passe sur github. Les contributions sont les bienvenues pour Cosmoe aussi bien que pour Haiku.
Le noyau de Haiku est l'un des seuls (le seul?) à être implémenté principalement en C++. Mon avis est que ça permet d'avoir un code plus simple, plus lisible, et plus facile à maintenir que le C utilisé par Linux. Il reste la question des drivers, mais on utilise par exemple pour le support réseau les drivers de FreeBSD via une couche de compatibilité. On pourrait étendre ce principe à d'autres drivers si c'est nécessaire. Pour les cartes graphiques, on nous avait promis que Gallium allait régler tous les problèmes, que les drivers seraient portables, et tout ça, et finalement, il faut faire du kernel mode setting, et absolument implémenter DRI/DRM dans le noyau et les drivers pour que ça marche. Et comme les APIs ne sont pas stables dans le noyau Linux, le temps que tout ça soit porté, ça aura changé et il faudra recommencer (on y était presque arrivé en 2008).
Un projet qui existe depuis 14 ans, avec un développeur à plein temps (c'est moi!) financé par les dons des utilisateurs, je trouve que c'est déjà pas mal.
Le fait que les 4 versions de Haiku déjà disponibles aient "Alpha" écrit en rouge dessus a l'air de faire peur aux gens. On aurait certainement du les appeler 0.1, 0.2, 0.3 et 0.4 ou quelque chose dans ce goût là.
Personellement j'utilise Haiku sur mes ordinateurs depuis plusieurs années et ça marche bien. Oui, c'est pas fini, y'a plein de bugs chiants et ça manque d'applications. Mais mon expérience de Linux auparavant n'a pas été forcément meilleure, et il est nettement plus facile de contribuer à Haiku. L'équipe des développeurs est disponible pour répondre aux questions, prend le temps d'aider les gens à s'y retrouver dans le code, et le code est propre. Et surtout, tout est dans un seul projet, ce qui facilite énormément la coordination. Pas besoin de trouver si le bug vient de systemd, du noyau, de udev, de dbus ou de quelque autre bibliothèque obscure pour savoir à qui demander de l'aide.
La configuration minimale pour utiliser Haiku est "un processeur x86 avec MMX et 128Mio de RAM". Mais bon, soyons honnêtes, sur une configuration de ce genre on ne pourra pas faire grand chose. Il y a plusieurs problèmes, mais en particulier le gestionnaire de paquets de Haiku se comporte mieux quand il y a plus de RAM. D'autre part, nos drivers graphiques n'utilisent plus l'acceleration 2D qui permettait à BeOS de bien fonctionner sur ce genre de machines, d'abord parce qu'on veut faire du rendu avec antialiasing et que ça ne s'accélère pas aussi facilement, mais aussi parce que sur les machines récentes, le processeur est de toutes façons plus rapide que la carte graphique pour ce genre de choses (c'est différent pour la 3D, mais on a pas encore d'accélération 3D).
Sur un "petit" netbook avec un CPU ATOM et 1Go de RAM, par contre, Haiku devient tout à fait utilisable. Je pense que c'est plutôt sur ce genre de machines qu'il est intéressant de se concentrer, on est en 2014, les Celeron vendus il y a 15 ans, il n'en reste plus beaucoup en service.
Même pour les traductions, ça reste un travail "dans l'ombre". Dans un cas que je connaît un peu (le projet Haiku), c'est vrai que le travail des développeurs est mis en avant, avec par exemple la boîte de dialogue "à propos de ce système" qui donne la liste des contributeurs pour le moindre patch.
D'un autre côté, la liste des gens qui contribuent à la traduction du système dans plein de langues n'est pas tenue à jour. Je vais aller le faire de ce pas tiens.
En ce qui concerne les tâches administratives (aussi bien l'administration système et la gestion de l'infrastructure, que l'administration de l'association Haiku, inc dans notre cas), on en entend parler que quand il y a des problèmes (et hereusement, ça n'arrive pas souvent).
Le problème n'est pas de rendre ces contributions plus faciles, mais de les mettre en avant autant que les contributions sous forme de code. Sinon, même si c'est facile à faire, ça reste une tâche ingrate dont personne n'aura envie de s'occuper.
Apple crée son propre standard? Pas sûr: c'est la même disposition utilisée sur Amiga et plein d'autres machines dans les années 80. C'est IBM qui a fait un truc à sa sauce pour le PC, mais qui du coup est très courant aujourd'hui.
Le projet Haiku utilise MLS. On est sous license MIT, mais voilà ce qu'on a mis en place:
Le code source ne contient pas de clé. Elle est injectée dans nos images officielles par nos serveurs de build. Cependant, une autre clé peut etre fournie à la compilation. De plus, l'API permet de spécifier une clé et un service différents à l'exécution. Elle reste donc utilisable pour toute personne qui a une clé MLS ou une clé Google APIs (le service de geolocalisation de Google utilisant le meme format de requetes).
De plus, il existe une clé "test" pour le service de Mozilla. Elle est disponible à condition d'en faire une utilisation raisonable. Dans le cas de Haiku elle est utilisée par notre testsuite.
Il y a donc une petite différence de comportement entre le binaire distribué et les sources fournies, mais rien de grave, je pense. J'ajoute que Mozilla utilise une solution similaire pour distribuer Firefox, qui contient une clé pour utiliser ce service aussi bien avec MLS que l'équivalent chez Google.
Pour ceux qui ne veulent pas donner leur numéro de téléphone à leur banque, il y a le PassCyberPlus de la banque populaire:
Le PassCyberplus est un lecteur de carte à puce qui permet de générer des codes de contrôle à usage unique pour sécuriser les opérations effectuées sur Internet.
Vous devez utiliser la (ou les) carte(s) bancaire Banque Populaire rattaché(es) à votre abonnement Cyberplus.
Il permet de repérer plein de choses dans un fichier "blob". Les en-têtes ELF, les bases de données SQLite, certains systèmes de fichiers, des séquences d'opcodes caractéristiques de certains CPUs, etc.
Pour les machines 8-bit, il y a d52, d48 et dz80: http://packages.debian.org/unstable/d52
avec une interface pas trop bête (un fichier de config permet d'indiquer quelles parties du fichier à analyser sont du code ou des données, de placer des labels et des commentaires sur des addresses, etc). Il y a une interface en SDL que je ne connait pas.
Je pense qu'une approche de ce type peut déjà bien fonctionner. ça permet aussi de travailler avec le fichier de config de façon scriptable, dans la philosophie unix.
Sans doute, mais ça ne suffit pas: si SSL ne (re)connaît pas le certificat du serveur auquel il se connecte, ça fonctionne quand même (en tout cas OpenSSL fonctionne comme ça). C'est à l'application de vérifier le certificat, de voir s'il est bien signé par qui il faut (autorité tierce, ou autre chose), et si ce n'est pas le cas, prévenir l'utilisateur: "Attention, cette connexion n'est peut être pas sûre. Continuer quand même ?". C'est tout. Si on clique quand même sur continuer, ben, ça continue. Et comme le certificat est en fait celui du pirate, c'est lui qui reçoit toutes les infos, cryptées, mais c'est lui qui a envoyé la clé!
C'est un héritage de Mac OS 9 (d'ailleurs Haiku fonctionne comme cela aussi): l'idée est de dimensionner la fenêtre en fonction de son contenu, et pas de bêtement prendre tout l'écran.
Le problème, c'est que d'une part les utilisateurs (et certains développeurs) s'attendent à trouver un bouton pour mettre la fenêtre en plein écran à cet endroit (il faut dire que le symbole '+' n'aide pas dans Mac OS X…). En plus, pour certaines applications ça n'a pas vraiement de sens de fonctionner de cette façon (par exemple, dans un client IRC, plus il y a de place dans la fenêtre, mieux c'est), ou alors, la taille change tout le temps (dans un navigateur web par exemple, chaque page a ses propres besoins).
Je trouve ce fonctionnement plutôt pratique quand on l'utilise avec plusieurs bureaux: on peut avoir des fenêtres plein écran occupant tout un bureau, et d'autres bureaux avec plusieurs fenêtres, ce qui permet de travailler avec plusieurs applications (pour copier coller un bout de code trouvé sur internet dans un éditeur de texte, déplacer des fichiers d'un dossier à un autre, et plein d'autres choses).
Je n'avais pas donné ce lien, il s'agit d'une vidéo qui présente stack&tile, maintenant intégré dans Haiku. Il permet d'utiliser les fenêtres comme des onglets (on en a parlé ailleurs dans les commentaires) et aussi de "coller" plusieurs fenêtres par leurs bordures. Stack and Tile a été développé par l'université d'Auckland (Nouvelle Zélande) pour améliorer les interfaces graphiques. La vidéo donne une bonne idée de ce que peut être le travail en multi-fenêtres, si on oublie les mauvais souvenirs de Mac OS (avant X) et des premières versions de Windows 95 qui ont conduit au mode "une fenêtre en plein écran" que beaucoup préfèrent aujourd'hui.
Je trouve le modèle UNIX, tel qu'il est utilisé actuellement, un peu compliqué. On utilise la notion de 'user' pour plusieurs choses: les vrais utilisateurs, et du sandboxing pour certaines applications. C'est lié à la gestion des droits sur les fichiers qui est un peu limitée (un utilisateur, un groupe, tout le reste), ce qui oblige à créer beaucoup de groupes et d'utilisateurs pour pouvoir avoir une gestion des droits suffisament fine. Et du coup, des complications du côté utilisateur du genre ilfaut être dans le groupe adm pour consulter les logs, dans le groupe dialup pour utiliser les ports série, et ainsi de suite.
Je ne sais pas quelle solution sera retenue pour Haiku, mais comme c'est un système mono-utilisateur pour un ordinateur de bureau, je ne vois pas pourquoi la notion d'utilisateur et la sécurité devraient être liées. Il y a un point de contact entre les deux: on veut peut être que les fichiers d'un utilisateur ne soient pas accessibles par les autres. Mais pour faire ça correctement, il faut crypter les fichiers de chaque utilisateur (avec une clé différente pour chacun), car sur une machine de bureau tout le monde a un accès physique au disque dur.
La gestion du multi-utilisateur sur Haiku va plutôt ressembler à ce qu'il y avait dans Windows 98: un dossier "home" séparé, un fond d'écran différent, et ça sera déjà pas mal.
Pour la sécurité, il est plus intéressant d'essayer de se protéger des attaques venant de l'extèrieur et de protéger les services du genre SSH, FTP et compagnie. Mais il n'y a pas forcément besoin de lier ça aux utilisateurs de façon aussi forte que dans UNIX.
Le montant de 35000$ annoncé sur la page d'accueil est calculé à partir du budget de l'année précédente. On est un peu en retard sur cet objectif cette année car Haiku n'a pas été retenu pour le Google Summer of Code et car il n'y a pas eu de release de Haiku (qui sont toujours un bon moment pour récupérer quelques dons).
En 2013 les dépenses pour le développement sont:
* 8000 euros pour Ingo Weinhold et Oliver Tappe pendant 2 mois sur le développement du gestionnaire de paquets,
* 4000 euros pour Pawel Dziepak pour le travail sur le scheduler pendant 2 mois,
* 4000 euros pour moi, pour le travail sur WebPositive et WebKit pendant 2 mois également.
On arrive à un total de 16000 euros (environ 21000 dollars), soit un peu plus que le montant des dons récoltés cette année. J'aurais bien continué à travailler sur WebKit en décembre mais ce ne sera apparament pas possible.
Un mode "multi-utilisateur", ainsi qu'une sécurisation du système (gestion des droits, etc) est prévue pour la version R2 de Haiku. La version R1 peut difficilement intégrer ces fonctionalités, d'une part parce que ça poserait des problèmes de compatibilité avec BeOS, et d'autre part parce que ça retarderait encore la publication de la version R1.
Cela dit, avec le gestionnaire de paquets, le dossier système est en lecture seule. C'est en fait un dossier virtuel qui est constitué par le contenu des paquets installés. Du coup, il devient difficile de tout casser en modifiant ce dossier. Il reste possible de remplacer un paquet du système, mais la réparation (remplacer de nouveau ce paquet par la version originale) est beaucoup plus facile que sous Windows.
On n'a probablement pas besoin d'un modèle multi-utilisateur similaire à celui de UNIX, qui est prévu pour un grand nombre d'utilisateurs sur une même machine. Le but de Haiku étant plutôt d'avoir un seul utilisateur pour le moment, ou peut-être quelques uns. On peut regarder par exemple ce qui est fait dans Android.
En effet, les BMessages de Haiku sont très ressemblants à ceux de Qt. Précisons tout de même qu'on peut envoyer un message à une autre application, ou bien le stocker dans un fichier ou l'envoyer via le réseau à une autre machine. C'est utilisé par exemple pour stocker la configuration d'un programme (sous forme binaire), faire du drag and drop ou du copier coller entre applications, et plein d'autres choses. Je ne sais pas si tout cela est possible dans Qt, que je n'ai pas utilisé depuis assez longtemps.
Pour quelque chose de plus proche de l'utilisation des signaux/slots de Qt, il y a les méthodes StartWatching() et SendNotices() de la classe BHandler, qui est encore une autre façon d'utiliser les BMessages.
Les barres de titre peuvent être utilisées comme des onglets. On peut empiler plusieurs fenêtres et passer de l'une à l'autre facilement. Sous BeOS il fallait gérer ça à la main, mais pour Haiku il y a "Stack and Tile" qui permet de laisser le window manager s'en occuper. C'est encore assez récent et peu d'application l'utilisent directement, mais cela devrait remplacer les fenêtres à onglet, par exemple dans le navigateur web ou le terminal.
Pour la DeskBar, quand elle est placée à droite, elle est facilement accessible même quand elle est sous une autre fenêtre, grace au trou laissé par la barre de titre de cette dernière. Avoir une barre verticale permet d'avoir la place pour lister beaucoup plus de fenêtres ouvertes que sur une barre horizontale, ce qui est assez utile quand on utilise le navigateur de fichiers en mode spatial (1 dossier = 1 fenêtre), par exemple.
Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, …). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.
[^] # Re: Parallels desktop
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 6.
ça marche aussi avec qemu et virtualbox, pour parallels je ne sais pas.
Si tu as essayé la version alpha de novembre 2012, peut être il vaut mieux tester un nightly build récent: http://download.haiku-os.org. Et inversement…
[^] # Re: Qu'est devenu le code source officiel de BeOS
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Avant la fin de Be, il y a eu un effort désespéré et de dernière minute pour libérer le code. Mais c'était déjà trop tard. On a quelques indices:
- Le code de la DeskBar (la barre des tâches) et du Tracker (le navigateur de fichiers) ont été libérés, et sont utilisés par Haiku.
- Une version "fuitée" de BeOS appelée "Dano" a été diffusée. Elle comporte plusieurs petits changements, mais en particulier remplace une bibliothèque SSL propriétaire par OpenSSL dans le navigateur web.
- Binder était une nouveauté prévue pour BeOS. Ce projet a été publié par Palm sous la forme d'OpenBinder, et il est nu des composants principaux d'Android. D'ailleurs une partie des développeurs de BeOS sont aujourd'hui employés par Google pour travailler sur Android.
Quelques fonctions de BeOS ont été intégrées dans PalmOS (dans la version 6, "Cobalt"). Donc on ne peut pas non plus dire que Palm n'a rien fait avec.
D'autre part, la socciété allemande Yellowtab a pu continuer pendant quelque temps le développement de BeOS (sous le nom de Zeta) après la fin de Be. Une possible collaboration entre Yellowtab (ou Palm) et Haiku était envisagée dès les débuts de Haiku, c'est d'ailleurs la raison du choix de la license MIT plutôt que de la GPL (afin de permettre l'utilisation du code de Haiku dans un projet commercial réuitlisant également des parties de BeOS). Cela a fonctionné quelques temps avec Yellowtab, mais ils n'ont pas trouvé de modèle commercial viable. Par la suite, une société appelée Magnussoft a continué à distribuer Zeta mais il n'y a plus vraiement eu d'évolutions, et finalement ils ont eu des soucis avec Access corporation (qui a récupéré les droits de BeOS après que PalmSource ait coulé… vous suivez?) car il semblerait que le contrat qui leur permettait d'utiliser les sources de BeOS se soit perdu en route quelque part.
[^] # Re: wifi et imprimantes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 7.
Il y a une liste des pilotes ici: https://dev.haiku-os.org/wiki/HardwareInfo
http://haikuware.com a également une liste de machines supportées.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
C'est un interêt de Haiku.
Le choix de refaire un OS complet a au moins deux raisons. D'abord, au lancement du projet, Linux n'était pas du tout ce qu'il est aujourd'hui. En 2001, la distribution à la mode pour avoir un PC facile à utiliser, c'était Mandrake 8 ou Corel Linux. C'était très loin de ce que pouvait faire BeOS, et il manquait au noyau plein de petites choses qui faisaient que ça ne semblait pas être une solution viable.
De plus, un des buts du projet était de préserver la compatibilité avec BeOS, y compris pour les pilotes de périphériques (à l'époque le support était à peu près aussi bon que sous Linux, et les gens intéressés par Haiku avaient plutôt des machines compatibles avec BeOS).
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? Pourquoi continuer GTK alors que Qt est libre aujourd'hui?
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). Alors oui, tout ce qu'on peut faire avec Haiku, on peut aussi le faire avec un GNU/Linux récent, mais en utilisant une douzaine de bibliothèques, chacune avec son API différente, chacune avec ses développeurs, son bugtracker, sa mailing list de support. C'est ça qui rend compliqué le développement d'une application. Et ça c'est sans parler des problèmes d'intégration entre applications utilisant des bibliothèques différentes.
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
En fait, le problème vient surtout du matériel. Pour l'accélération 2D, à l'époque de BeOS les cartes savaient faire des copies et des remplissages de rectangles, mais aussi du tracé de lignes et d'autres opérations utiles. Déjà à l'époque certaines cartes étaient plus lentes que le CPU sur certaines opérations, et donc c'était délicat de bien utiliser ces fonctions.
Aujourd'hui, les fonctions 2D cablées ont disparu des cartes graphiques, l'accélération se fait via un GPU générique. Il faut donc un driver plus complexe permettant de programmer ce GPU et exposer une API qui va bien (OpenGL pour la 3D, OpenVG pour la 2D). Quand on aura ça, on pourra faire de nouveau de l'accélération 2D.
Le support est présent dans certains drivers (pour les vieilles cartes, donc) et on peut même utiliser les pilotes de BeOS dans Haiku puisqu'ils sont compatibles au niveau binaire. Mais l'app_server (notre équivalent de X11) n'utilise pas ces fonctions, pour les 2 raisons mentionnées: c'est plus lent et c'est moche car il n'y a pas d'antialiasing. Si quelqu'un se propose pour maintenir la version accélérée de l'app_server, les patches seraient acceptés sans problème. Mais, à mon avis, il est plus intéressant d'avoir d'abord la 3D accélérée (car là le CPU n'est pas encore assez puissant - encore que, on fait tourner de la 3D d'il y a 15 ans en rendu logiciel aujourd'hui). Pour la 2D on verra plus tard.
Enfin, quand je parle de machines "récentes", pour moi c'est "moins de 10 ans". J'ai encore un PC qui date de 2003 en état de marche (avec un peu plus de RAM qu'à l'origine il est vrai). Sur cette machine les performances de Haiku sont tout à fait acceptables (c'est un Athlon XP 2200+ avec 1Go de RAM). Je ne pense pas qu'on puisse avoir des performances acceptables sur une machine d'il y a 20 ans (un des tout premiers pentium de 1994): même si l'OS pouvait fonctionner, il serait impossible de lire une vidéo dans un format moderne (et même un MP3 ça risque d'être compliqué), ou d'afficher la moindre page web pleine de CSS et de Javascript. ça ferait donc un système rapide, mais quasi inutile.
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Déjà, le noyau de Haiku est toujours en mode "debug" (avec plein de vérifications, écrasement systématique de la mémoire libérée, etc) de façon à détecter et pouvoir déboguer plus facilement les problèmes (et il y en a!). Recompiler le noyau en mode "release" sans tous ces controles permet de gagner en vitesse.
Comme je l'ai indiqué, il n'y a pas d'accélération 2D, et tout l'affichage se fait avec de l'antialiasing; c'est beau, mais c'est lent. Et en plus c'est en double buffer (ce n'était pas le cas pour BeOS) et l'un des deux buffers est en RAM centrale (l'accès en lecture à la RAM vidéo via le BUS AGP étant trop lent).
Enfin, le gestionnaire de paquets qui est implémenté sous forme d'un système de fichiers virtual a besoin de RAM pour garder en cache les fichiers extraits des paquets (un peu comme un DriveSpace pour ceux qui connaissent). Et plein d'autres choses que BeOS ne faisait pas, comme la gestion du wifi, par exemple.
Un navigateur web de l'époque de BeOS (NetPositive ou Opera 3) fonctionnera sous Haiku par exemple, mais pour naviguer sur internet, c'est difficile. Meme chose pour lire la moindre vidéo, de nos jours tout est en full-HD en h.264 que meme mon Core 2 duo a un peu de mal à décoder en temps réel. Alors pour faire la meme chose qu'il y a 15 ans, ça pourrait marcher sur le matériel d'époque (avec un peu d'efforts), mais il est je pense plus intéressant de fonctionner sur des machines un peu plus récentes (disons moins de 10 ans) et d'avoir des fonctionalités modernes pour une utilisation moderne. De toutes façons, sur un Pentium avec 32Mio de mémoire, BeOS continue de fonctionner comme il le faisait déjà il y a 15 ans, non?
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Malhereusement non!
La plupart des frameworks ont un seul thread qui fait tout.
Dans BeOS et dans Haiku, la moindre application a au moins 3 threads:
- Le thread de l'application, qui fait les traitements longs
- Le thread de la fenêtre, qui répond aux actions de l'utilisateur
- Et un thread dans le serveur graphique, qui dessine la fenêtre
Alors oui, c'est possible de faire la même chose avec d'autres frameworks, mais c'est tout un bazar (avec des problèmes de synchronisation) et personne (ou pas beaucoup de gens) ne le fait.
Les APIs de BeOS et de Haiku sont conçues pour limiter les problèmes. La communication entre ces threads se fait via des messages (similaires aux signaux/slots de Qt) qui permettent d'échanger des données sans avoir à traiteer soi même les problèmes de synchronisation. Donc, quand l'utilisateur clique sur un bouton, le thread de la fenÛêtre réagit au quart de tour (il a rien d'autre à faire, en même temps), et tout ce qu'il fait, c'est transmettre le message:
- Au thread de l'application: "clic sur le bouton x" (pour lancer un traitement quelconque)
- Au thread du serveur graphique (pour redessiner le bouton)
Avec ce système il est difficile d'avoir une fenêtre gelée (à moins de le faire exprès). L'utilisation de la plupart des autres systèmes m'est insupportable avec des curseurs en sablier ou en ballon de plage à chaque clic.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
En ce qui concerne les autres projets morts, il s'agit de BlueEyedOS (une implémentation des API de BeOS sur une base GNU/Linux/X classique) et de Cosmoe (un portage de l'espace utilisateur de Haiku sur un noyau Linux ou BSD). Ce dernier est de nouveau vivant depuis le coding sprint BeGeistert, ça se passe sur github. Les contributions sont les bienvenues pour Cosmoe aussi bien que pour Haiku.
Le noyau de Haiku est l'un des seuls (le seul?) à être implémenté principalement en C++. Mon avis est que ça permet d'avoir un code plus simple, plus lisible, et plus facile à maintenir que le C utilisé par Linux. Il reste la question des drivers, mais on utilise par exemple pour le support réseau les drivers de FreeBSD via une couche de compatibilité. On pourrait étendre ce principe à d'autres drivers si c'est nécessaire. Pour les cartes graphiques, on nous avait promis que Gallium allait régler tous les problèmes, que les drivers seraient portables, et tout ça, et finalement, il faut faire du kernel mode setting, et absolument implémenter DRI/DRM dans le noyau et les drivers pour que ça marche. Et comme les APIs ne sont pas stables dans le noyau Linux, le temps que tout ça soit porté, ça aura changé et il faudra recommencer (on y était presque arrivé en 2008).
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Un projet qui existe depuis 14 ans, avec un développeur à plein temps (c'est moi!) financé par les dons des utilisateurs, je trouve que c'est déjà pas mal.
Le fait que les 4 versions de Haiku déjà disponibles aient "Alpha" écrit en rouge dessus a l'air de faire peur aux gens. On aurait certainement du les appeler 0.1, 0.2, 0.3 et 0.4 ou quelque chose dans ce goût là.
Personellement j'utilise Haiku sur mes ordinateurs depuis plusieurs années et ça marche bien. Oui, c'est pas fini, y'a plein de bugs chiants et ça manque d'applications. Mais mon expérience de Linux auparavant n'a pas été forcément meilleure, et il est nettement plus facile de contribuer à Haiku. L'équipe des développeurs est disponible pour répondre aux questions, prend le temps d'aider les gens à s'y retrouver dans le code, et le code est propre. Et surtout, tout est dans un seul projet, ce qui facilite énormément la coordination. Pas besoin de trouver si le bug vient de systemd, du noyau, de udev, de dbus ou de quelque autre bibliothèque obscure pour savoir à qui demander de l'aide.
[^] # Re: Petites machines
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 7.
La configuration minimale pour utiliser Haiku est "un processeur x86 avec MMX et 128Mio de RAM". Mais bon, soyons honnêtes, sur une configuration de ce genre on ne pourra pas faire grand chose. Il y a plusieurs problèmes, mais en particulier le gestionnaire de paquets de Haiku se comporte mieux quand il y a plus de RAM. D'autre part, nos drivers graphiques n'utilisent plus l'acceleration 2D qui permettait à BeOS de bien fonctionner sur ce genre de machines, d'abord parce qu'on veut faire du rendu avec antialiasing et que ça ne s'accélère pas aussi facilement, mais aussi parce que sur les machines récentes, le processeur est de toutes façons plus rapide que la carte graphique pour ce genre de choses (c'est différent pour la 3D, mais on a pas encore d'accélération 3D).
Sur un "petit" netbook avec un CPU ATOM et 1Go de RAM, par contre, Haiku devient tout à fait utilisable. Je pense que c'est plutôt sur ce genre de machines qu'il est intéressant de se concentrer, on est en 2014, les Celeron vendus il y a 15 ans, il n'en reste plus beaucoup en service.
[^] # Re: Super mais seulement 1M ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Freebsd reçoit une peu de thunes.. Évalué à 6.
Même pour les traductions, ça reste un travail "dans l'ombre". Dans un cas que je connaît un peu (le projet Haiku), c'est vrai que le travail des développeurs est mis en avant, avec par exemple la boîte de dialogue "à propos de ce système" qui donne la liste des contributeurs pour le moindre patch.
D'un autre côté, la liste des gens qui contribuent à la traduction du système dans plein de langues n'est pas tenue à jour. Je vais aller le faire de ce pas tiens.
En ce qui concerne les tâches administratives (aussi bien l'administration système et la gestion de l'infrastructure, que l'administration de l'association Haiku, inc dans notre cas), on en entend parler que quand il y a des problèmes (et hereusement, ça n'arrive pas souvent).
Le problème n'est pas de rendre ces contributions plus faciles, mais de les mettre en avant autant que les contributions sous forme de code. Sinon, même si c'est facile à faire, ça reste une tâche ingrate dont personne n'aura envie de s'occuper.
[^] # Re: Clavier et normalisation.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un agencement de clavier normalisé : bientôt pour la France !. Évalué à 0.
Apple crée son propre standard? Pas sûr: c'est la même disposition utilisée sur Amiga et plein d'autres machines dans les années 80. C'est IBM qui a fait un truc à sa sauce pour le PC, mais qui du coup est très courant aujourd'hui.
[^] # Re: Incompatible GPLv3?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla location services: quand il faut choisir entre liberté et vie privée. Évalué à 3.
Le projet Haiku utilise MLS. On est sous license MIT, mais voilà ce qu'on a mis en place:
Le code source ne contient pas de clé. Elle est injectée dans nos images officielles par nos serveurs de build. Cependant, une autre clé peut etre fournie à la compilation. De plus, l'API permet de spécifier une clé et un service différents à l'exécution. Elle reste donc utilisable pour toute personne qui a une clé MLS ou une clé Google APIs (le service de geolocalisation de Google utilisant le meme format de requetes).
De plus, il existe une clé "test" pour le service de Mozilla. Elle est disponible à condition d'en faire une utilisation raisonable. Dans le cas de Haiku elle est utilisée par notre testsuite.
Il y a donc une petite différence de comportement entre le binaire distribué et les sources fournies, mais rien de grave, je pense. J'ajoute que Mozilla utilise une solution similaire pour distribuer Firefox, qui contient une clé pour utiliser ce service aussi bien avec MLS que l'équivalent chez Google.
# Êtes-vous concerné?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fin du support de MS Windows XP. Évalué à 8.
Un site très pratique mis en place par Microsoft pour vérifier si votre ordinateur est concerné: http://amirunningxp.com/
[^] # Re: Numéro de compte et virement ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Paylib va enfin remplacer paypal !. Évalué à 2.
Pour ceux qui ne veulent pas donner leur numéro de téléphone à leur banque, il y a le PassCyberPlus de la banque populaire:
# binwalk
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Disséquer du binaire sous linux. Évalué à 5.
Avant d'attaquer le désassemblage, il y a binwalk: http://code.google.com/p/binwalk/
Il permet de repérer plein de choses dans un fichier "blob". Les en-têtes ELF, les bases de données SQLite, certains systèmes de fichiers, des séquences d'opcodes caractéristiques de certains CPUs, etc.
Pour les machines 8-bit, il y a d52, d48 et dz80: http://packages.debian.org/unstable/d52
avec une interface pas trop bête (un fichier de config permet d'indiquer quelles parties du fichier à analyser sont du code ou des données, de placer des labels et des commentaires sur des addresses, etc). Il y a une interface en SDL que je ne connait pas.
Je pense qu'une approche de ce type peut déjà bien fonctionner. ça permet aussi de travailler avec le fichier de config de façon scriptable, dans la philosophie unix.
Pour le 68000, il y a IRA qui fait un peu la même chose: http://sun.hasenbraten.de/~frank/projects/
Enfin, pour l'analyse dynamique, n'oublions pas strace qui permet d'avoir déjà un bon apperçu de ce qu'il se passe.
[^] # Re: ssl / tls
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les mails des eurodéputés ont été piratés par un hacker. Évalué à 1.
Sans doute, mais ça ne suffit pas: si SSL ne (re)connaît pas le certificat du serveur auquel il se connecte, ça fonctionne quand même (en tout cas OpenSSL fonctionne comme ça). C'est à l'application de vérifier le certificat, de voir s'il est bien signé par qui il faut (autorité tierce, ou autre chose), et si ce n'est pas le cas, prévenir l'utilisateur: "Attention, cette connexion n'est peut être pas sûre. Continuer quand même ?". C'est tout. Si on clique quand même sur continuer, ben, ça continue. Et comme le certificat est en fait celui du pirate, c'est lui qui reçoit toutes les infos, cryptées, mais c'est lui qui a envoyé la clé!
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 2.
C'est un héritage de Mac OS 9 (d'ailleurs Haiku fonctionne comme cela aussi): l'idée est de dimensionner la fenêtre en fonction de son contenu, et pas de bêtement prendre tout l'écran.
Le problème, c'est que d'une part les utilisateurs (et certains développeurs) s'attendent à trouver un bouton pour mettre la fenêtre en plein écran à cet endroit (il faut dire que le symbole '+' n'aide pas dans Mac OS X…). En plus, pour certaines applications ça n'a pas vraiement de sens de fonctionner de cette façon (par exemple, dans un client IRC, plus il y a de place dans la fenêtre, mieux c'est), ou alors, la taille change tout le temps (dans un navigateur web par exemple, chaque page a ses propres besoins).
Je trouve ce fonctionnement plutôt pratique quand on l'utilise avec plusieurs bureaux: on peut avoir des fenêtres plein écran occupant tout un bureau, et d'autres bureaux avec plusieurs fenêtres, ce qui permet de travailler avec plusieurs applications (pour copier coller un bout de code trouvé sur internet dans un éditeur de texte, déplacer des fichiers d'un dossier à un autre, et plein d'autres choses).
Je n'avais pas donné ce lien, il s'agit d'une vidéo qui présente stack&tile, maintenant intégré dans Haiku. Il permet d'utiliser les fenêtres comme des onglets (on en a parlé ailleurs dans les commentaires) et aussi de "coller" plusieurs fenêtres par leurs bordures. Stack and Tile a été développé par l'université d'Auckland (Nouvelle Zélande) pour améliorer les interfaces graphiques. La vidéo donne une bonne idée de ce que peut être le travail en multi-fenêtres, si on oublie les mauvais souvenirs de Mac OS (avant X) et des premières versions de Windows 95 qui ont conduit au mode "une fenêtre en plein écran" que beaucoup préfèrent aujourd'hui.
http://www.cs.auckland.ac.nz/~lutteroth/videos/stack-and-tile.html
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 2.
Je trouve le modèle UNIX, tel qu'il est utilisé actuellement, un peu compliqué. On utilise la notion de 'user' pour plusieurs choses: les vrais utilisateurs, et du sandboxing pour certaines applications. C'est lié à la gestion des droits sur les fichiers qui est un peu limitée (un utilisateur, un groupe, tout le reste), ce qui oblige à créer beaucoup de groupes et d'utilisateurs pour pouvoir avoir une gestion des droits suffisament fine. Et du coup, des complications du côté utilisateur du genre ilfaut être dans le groupe adm pour consulter les logs, dans le groupe dialup pour utiliser les ports série, et ainsi de suite.
Je ne sais pas quelle solution sera retenue pour Haiku, mais comme c'est un système mono-utilisateur pour un ordinateur de bureau, je ne vois pas pourquoi la notion d'utilisateur et la sécurité devraient être liées. Il y a un point de contact entre les deux: on veut peut être que les fichiers d'un utilisateur ne soient pas accessibles par les autres. Mais pour faire ça correctement, il faut crypter les fichiers de chaque utilisateur (avec une clé différente pour chacun), car sur une machine de bureau tout le monde a un accès physique au disque dur.
La gestion du multi-utilisateur sur Haiku va plutôt ressembler à ce qu'il y avait dans Windows 98: un dossier "home" séparé, un fond d'écran différent, et ça sera déjà pas mal.
Pour la sécurité, il est plus intéressant d'essayer de se protéger des attaques venant de l'extèrieur et de protéger les services du genre SSH, FTP et compagnie. Mais il n'y a pas forcément besoin de lier ça aux utilisateurs de façon aussi forte que dans UNIX.
[^] # Re: Haiku sur AMD64 ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 2.
Un article qui explique comment faire un rapport de bug utile à partir du KDL:
https://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land
Pour récupérer les données on peut utiliser des QR Codes:
https://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_output
Sinon, la commande kdlhangman permet de jouer au pendu.
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 4.
Le montant de 35000$ annoncé sur la page d'accueil est calculé à partir du budget de l'année précédente. On est un peu en retard sur cet objectif cette année car Haiku n'a pas été retenu pour le Google Summer of Code et car il n'y a pas eu de release de Haiku (qui sont toujours un bon moment pour récupérer quelques dons).
Les dépenses sont détaillées sur le site de Haiku, inc:
http://haiku-inc.org/funded-infrastructure.html
http://haiku-inc.org/funded-development.html
En 2013 les dépenses pour le développement sont:
* 8000 euros pour Ingo Weinhold et Oliver Tappe pendant 2 mois sur le développement du gestionnaire de paquets,
* 4000 euros pour Pawel Dziepak pour le travail sur le scheduler pendant 2 mois,
* 4000 euros pour moi, pour le travail sur WebPositive et WebKit pendant 2 mois également.
On arrive à un total de 16000 euros (environ 21000 dollars), soit un peu plus que le montant des dons récoltés cette année. J'aurais bien continué à travailler sur WebKit en décembre mais ce ne sera apparament pas possible.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 2.
Un mode "multi-utilisateur", ainsi qu'une sécurisation du système (gestion des droits, etc) est prévue pour la version R2 de Haiku. La version R1 peut difficilement intégrer ces fonctionalités, d'une part parce que ça poserait des problèmes de compatibilité avec BeOS, et d'autre part parce que ça retarderait encore la publication de la version R1.
Cela dit, avec le gestionnaire de paquets, le dossier système est en lecture seule. C'est en fait un dossier virtuel qui est constitué par le contenu des paquets installés. Du coup, il devient difficile de tout casser en modifiant ce dossier. Il reste possible de remplacer un paquet du système, mais la réparation (remplacer de nouveau ce paquet par la version originale) est beaucoup plus facile que sous Windows.
On n'a probablement pas besoin d'un modèle multi-utilisateur similaire à celui de UNIX, qui est prévu pour un grand nombre d'utilisateurs sur une même machine. Le but de Haiku étant plutôt d'avoir un seul utilisateur pour le moment, ou peut-être quelques uns. On peut regarder par exemple ce qui est fait dans Android.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 2.
En effet, les BMessages de Haiku sont très ressemblants à ceux de Qt. Précisons tout de même qu'on peut envoyer un message à une autre application, ou bien le stocker dans un fichier ou l'envoyer via le réseau à une autre machine. C'est utilisé par exemple pour stocker la configuration d'un programme (sous forme binaire), faire du drag and drop ou du copier coller entre applications, et plein d'autres choses. Je ne sais pas si tout cela est possible dans Qt, que je n'ai pas utilisé depuis assez longtemps.
Pour quelque chose de plus proche de l'utilisation des signaux/slots de Qt, il y a les méthodes StartWatching() et SendNotices() de la classe BHandler, qui est encore une autre façon d'utiliser les BMessages.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 1.
Les barres de titre peuvent être utilisées comme des onglets. On peut empiler plusieurs fenêtres et passer de l'une à l'autre facilement. Sous BeOS il fallait gérer ça à la main, mais pour Haiku il y a "Stack and Tile" qui permet de laisser le window manager s'en occuper. C'est encore assez récent et peu d'application l'utilisent directement, mais cela devrait remplacer les fenêtres à onglet, par exemple dans le navigateur web ou le terminal.
Pour la DeskBar, quand elle est placée à droite, elle est facilement accessible même quand elle est sous une autre fenêtre, grace au trou laissé par la barre de titre de cette dernière. Avoir une barre verticale permet d'avoir la place pour lister beaucoup plus de fenêtres ouvertes que sur une barre horizontale, ce qui est assez utile quand on utilise le navigateur de fichiers en mode spatial (1 dossier = 1 fenêtre), par exemple.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 6.
Le rendu est fait par un thread dédié (pour chaque fenêtre) dans l'app_server. Dans ce cas, le thread de l'application n'accède pas directement à la mémoire écran, il envoie des instructions de dessin au thread correspondant dans l'app_server (via les APIs de BView.
Comme tout le travail de dessin est fait par l'app_server, la façon dont il travaille n'impacte pas l'application. Actuellement, tout est fait dans un buffer de la taille de l'écran qui est ensuite recopié dans la mémoire vidéo. BeOS utilisait les fonctions d'accélération 2D de la carte graphique disponibles à l'époque (tracé de lignes, copie de blocs, remplissage de rectangles, …). Il est théoriquement possible de passer à un fonctionnement avec un compositeur et un tampon mémoire dédié à chaque fenêtre. On y a déjà réfléchi ici, par exemple. Ou encore, on peut utiliser remote_app_server qui fait le rendu sur une autre machine (de la transparence réseau!).
Au passage, BView peut aussi être utilisée pour dessiner dans un BBitmap, ce qui permet de travailler hors mémoire écran, puis d'afficher le bitmap à l'écran plus tard (via une autre BView avec DrawBitmap), de l'imprimer sur papier, de le stocker dans une image PNG (ou autre) via les translators, etc.
Pour OpenGL, tout ceci est court-circuité. On utilise alors BDirectWindow ou BWindowScreen qui permettent un accès direct à la RAM vidéo en empêchant app_server de toucher à la fenêtre en question. Actuellement, on utilise uniquement du rendu logiciel (avec Mesa) pour OpenGL, qui vient donc écrire dans le buffer d'écran directement. Mais pour l'accélération matérielle, BDirectWindow permet d'appeler directement des méthodes de l'accelerant de la carte graphique (partie du driver fonctionnant dans l'app_server et non dans le noyau). C'est ce qui était utilisé sous BeOS pour l'accélération 2D, et ça devrait permettre également l'accélération 3D en ajoutant de nouveaux points d'entrées.