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.
Haiku n'est pas plus rapide qu'un autre OS (en fait, il est même plutôt plus lent car le noyau est compilé en mode debug pour le moment). Mais, chaque fenêtre fonctionne dans son propre thread, et ces threads en question ont une priorité plus élevée que les autres. Du coup, même si le CPU est très occupé, le système reste toujours réactif et fluide.
ça ne veut pas dire qu'il n'y a jamais besoin d'attendre, par exemple lors des accès disque, mais au moins on n'a pas une fenêtre complètement gelée et qui ne se redessine plus coincée au milieu de l'écran.
Cela dit, c'est aussi pour ça que Haiku a son propre navigateur, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.
Pour les serveurs: non. Haiku est un système destiné uniquement aux ordinateurs de bureau. Il est possible de lancer un serveur web (PoorMan, qui est fourni avec Haiku, ou encore Cherokee, par exemple), mais ça a peu d'interêt.
Pour le bureau, c'est vrai que Linux a fait beaucoup de progrès depuis 2001 et le lancement du projet Haiku. Et du coup, Haiku utilise effectivement du code développé ailleurs, comme freetype, wpa_supplicant, bash, et encore beaucoup d'autres.
Cependant, il y a des différences de taille, comme par exemple l'absence d'un serveur X. Dans le monde Linux/BSD/…, on a souvent des projets qui doivent fonctionner dans plusiurs cas. Le serveur X.org fonctionne aussi bien sur Linux que sur un FreeBSD, par exemple, certaines applications peuvent utiliser GTK 2 ou 3, qui lui-même peut fonctionner avec Wayland ou X, et ainsi de suite. Cela complexifie le code pour tout le monde, oblige à avoir plusieurs couches d'abstraction à tous les étages, et il reste tout de même des différences de comportement entre les différents systèmes. Dans Haiku au contraire, il n'y a en général qu'une façon de faire les choses.
Un deuxième avantage de Haiku est une stabilité des APIs mais aussi des ABIs. Dans le monde de Linux on n'hésite pas à remplacer ou modifier plein de choses dans le système à chaque version. Les logiciels doivent s'adapter en permanence. C'est résolu la plupart du temps par les distributions qui vont essayer de packager un ensemble cohérent de logiciels qui fonctionnent ensemble. Fort hereusement, une très grande partie de ces logiciels sont libres, et peuvent être patchés pour fonctionner correctement. ça représente tout de même beaucoup de travail, et c'est souvent un problème pour intégrer des logiciels distribués uniquement sous forme de binaires. Ces derniers ne pourront fonctionner qu'avec une version bien précise d'une ou deux distributions.
Ceci permet aux applications de mieux s'intégrer dans le système. Citons par exemple les "translators" (traducteurs) qui permettent de décoder des images (png, jpeg, …) sans en connaître le format. Des applications écrites avant l'apparition d'un format donné pourront donc le décoder si le système dispose du traducteur approprié. La même chose est possible pour d'autre types de fichiers (texte, RTF par exemple). Le Media Kit dispose également d'un mécanisme similaire pour le décodage des fichiers sons et vidéo. Là encore, des codecs peuvent être ajoutés au système et toutes les applications pourront les utiliser. Alors c'est vrai, maintenant, sous Linux il y a GStreamer, mais tout le monde ne l'utilise pas.
Dès le début du projet Haiku est prévu pour permettre à certaines applications non-libres de continuer à exister après la disparition de BeOS. à l'époque, il était encore possible que BeOS continue d'exister d'une façon ou d'une autre, donc, le choix de la licence MIT a été fait, ce qui permettrait une éventuelle réintégration du code de Haiku dans une nouvelle version de BeOS. La compatibilité avec ce dernier est assurée (les applications écrites avant 2001 pour BeOS fonctionnent toujours aujourd'hui), même pour les pilotes matériels, qui peuvent être compilés indépendement du noyau. Un exemple d'application non-libre qui fonctionne sous Haiku après avoir utilisé BeOS pendant assez longtemps: http://www.tunetrackersystems.com/
Enfin, au niveau de l'apparence, moi je la trouve très bien. L'interface est compacte et discrète et permet de se concentrer sur ce qu'on fait. Elle est assez équilibrée, quelque part entre Mac OS X qui met des arrondis et des dégradés partout, et Windows 8 qui est quand même très minimaliste.
[^] # 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.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 3.
En fait, si!
Haiku n'est pas plus rapide qu'un autre OS (en fait, il est même plutôt plus lent car le noyau est compilé en mode debug pour le moment). Mais, chaque fenêtre fonctionne dans son propre thread, et ces threads en question ont une priorité plus élevée que les autres. Du coup, même si le CPU est très occupé, le système reste toujours réactif et fluide.
ça ne veut pas dire qu'il n'y a jamais besoin d'attendre, par exemple lors des accès disque, mais au moins on n'a pas une fenêtre complètement gelée et qui ne se redessine plus coincée au milieu de l'écran.
Cela dit, c'est aussi pour ça que Haiku a son propre navigateur, qui lui, n'a pas besoin de plusieurs Go de RAM (là, il utilise 375Mo avec 5 onglets ouverts).
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 10.
Quelques informations sur la stack graphique (app_server) et l'architecture des drivers pour les cartes vidéo:
https://www.haiku-os.org/tags/app_server
https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/04-accelerant
Le toolkit graphique a une particularité: chaque fenêtre fonctionne dans son propre thread, aussi bien au niveau de l'application que du serveur graphique. C'est ce qui permet la réactivité légendaire de BeOS et de Haiku: même si le thread principal de l'application est bloqué par une tâche de calcul intensif (ou en attente sur des E/S ou autre chose), les fenêtres ont leurs threads dédiés et ne gèleront pas. (ceci justifie l'importance du travail en cours sur le scheduler mentionné dans la dépêche)
Pour que cela fonctionne bien, la plupart des communications se font via des messages envoyés entre threads, dans le même processus ou pas, d'ailleurs. BMessage est une classe qui fonctionne comme un conteneur dans lequel on peut ajouter des types primitifs (entiers, chaînes de caractères), des pointeurs, des blocs de données bruts, ou même des objets C++ si la classe implémente BArchivable ou BFlattenable. Toutes les données sont contenues dans le message ce qui évite de gérer manuellement le partage de mémoire entre threads et tous les problèmes de partage de ressources. Les messages peuvent être envoyés et reçus par chaque vue dans une fenêtre. On peut rapprocher ça du système de signaux et slots en Qt, mais l'implémentation est uniquement en C++, là ou Qt a besoin du préprocesseur moc.
Les messages étant un composant central dans la programmation avec la BeAPI, leur implémentation doit être optimisée autant que possible. C'est une des raisons pour lesquelles le noyau de Haiku implémente les "ports", un mécanisme plus bas niveau qui permet l'implémentation des messages de façon plus performante qu'on pourrait le faire avec les seules APIs POSIX. C'est un exemple de l'interêt que l'on a a maîtriser l'ensemble du système dans Haiku, là ou une implémentation utilisant un noyau tiers aurait du soit utiliser une solution plus lente, par exemple avec des pipe ou des sockets unix, soit modifier le noyau en question pour y ajouter un mécanisme similaire aux ports (et soit réussir à le faire accepter aux développeurs du noyau, soit maintenir un fork). Il y a d'ailleurs eu une tentative avec le projet BlueEyedOS de porter la BeAPI sur un système à base de noyau Linux. Ce projet n'est malhereusement plus maintenu.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku est vivant. Évalué à 10.
Pour les serveurs: non. Haiku est un système destiné uniquement aux ordinateurs de bureau. Il est possible de lancer un serveur web (PoorMan, qui est fourni avec Haiku, ou encore Cherokee, par exemple), mais ça a peu d'interêt.
Pour le bureau, c'est vrai que Linux a fait beaucoup de progrès depuis 2001 et le lancement du projet Haiku. Et du coup, Haiku utilise effectivement du code développé ailleurs, comme freetype, wpa_supplicant, bash, et encore beaucoup d'autres.
Cependant, il y a des différences de taille, comme par exemple l'absence d'un serveur X. Dans le monde Linux/BSD/…, on a souvent des projets qui doivent fonctionner dans plusiurs cas. Le serveur X.org fonctionne aussi bien sur Linux que sur un FreeBSD, par exemple, certaines applications peuvent utiliser GTK 2 ou 3, qui lui-même peut fonctionner avec Wayland ou X, et ainsi de suite. Cela complexifie le code pour tout le monde, oblige à avoir plusieurs couches d'abstraction à tous les étages, et il reste tout de même des différences de comportement entre les différents systèmes. Dans Haiku au contraire, il n'y a en général qu'une façon de faire les choses.
Un deuxième avantage de Haiku est une stabilité des APIs mais aussi des ABIs. Dans le monde de Linux on n'hésite pas à remplacer ou modifier plein de choses dans le système à chaque version. Les logiciels doivent s'adapter en permanence. C'est résolu la plupart du temps par les distributions qui vont essayer de packager un ensemble cohérent de logiciels qui fonctionnent ensemble. Fort hereusement, une très grande partie de ces logiciels sont libres, et peuvent être patchés pour fonctionner correctement. ça représente tout de même beaucoup de travail, et c'est souvent un problème pour intégrer des logiciels distribués uniquement sous forme de binaires. Ces derniers ne pourront fonctionner qu'avec une version bien précise d'une ou deux distributions.
Ceci permet aux applications de mieux s'intégrer dans le système. Citons par exemple les "translators" (traducteurs) qui permettent de décoder des images (png, jpeg, …) sans en connaître le format. Des applications écrites avant l'apparition d'un format donné pourront donc le décoder si le système dispose du traducteur approprié. La même chose est possible pour d'autre types de fichiers (texte, RTF par exemple). Le Media Kit dispose également d'un mécanisme similaire pour le décodage des fichiers sons et vidéo. Là encore, des codecs peuvent être ajoutés au système et toutes les applications pourront les utiliser. Alors c'est vrai, maintenant, sous Linux il y a GStreamer, mais tout le monde ne l'utilise pas.
Dès le début du projet Haiku est prévu pour permettre à certaines applications non-libres de continuer à exister après la disparition de BeOS. à l'époque, il était encore possible que BeOS continue d'exister d'une façon ou d'une autre, donc, le choix de la licence MIT a été fait, ce qui permettrait une éventuelle réintégration du code de Haiku dans une nouvelle version de BeOS. La compatibilité avec ce dernier est assurée (les applications écrites avant 2001 pour BeOS fonctionnent toujours aujourd'hui), même pour les pilotes matériels, qui peuvent être compilés indépendement du noyau. Un exemple d'application non-libre qui fonctionne sous Haiku après avoir utilisé BeOS pendant assez longtemps: http://www.tunetrackersystems.com/
Enfin, au niveau de l'apparence, moi je la trouve très bien. L'interface est compacte et discrète et permet de se concentrer sur ce qu'on fait. Elle est assez équilibrée, quelque part entre Mac OS X qui met des arrondis et des dégradés partout, et Windows 8 qui est quand même très minimaliste.