Voici quelques nouvelles du monde Haiku, le système d'exploitation libre sous licence MIT, anciennement OpenBeOS (version libre de BeOS, qui fut abandonné en 2001, suite à la fermeture de la société Be, qui a également produit les BeBox).
Sommaire
- Ports
- WebPositive, le navigateur basé sur WebKit
- Gestionnaire de paquets
- Optimisations de l'ordonnanceur
Ports
Port ARM
Le port ARM avance au niveau du noyau, l'espace utilisateur suit. Débuté lors du Google Summer of Code de 2009, le port d'Haiku sur ARM continue d'avancer et en décembre 2012, les développeurs ont annoncé que tous les éléments de l'image de base sont compilables sur ARM. Il reste cependant beaucoup de travail à accomplir et c'est pourquoi le développeur principal de la branche ARM songe à proposer un contrat à la fondation Haiku Inc. pour avancer plus rapidement.
Port PPC Sam460ex
Un portage sur Sam460ex, une carte à base de PowerPC embarqué, utilisée dans les AmigaOne 500, est démarré. Pour l'instant le noyau compile, le gestionnaire de démarrage le charge et lui passe la main. La suite nécessite une modification du code gérant la MMU, car elle diffère des PowerPC "Classic", les processeurs embarqués répondant à la spécification "Book E". Les progrès seront détaillés lors de l'Alchimie X. Au passage, des corrections au support OpenFirmware sont apportées pour permettre un démarrage dans QEMU, dont le firmware OpenBIOS pose quelques problèmes.
Port M68K
Un portage sur l'architecture 68k existe mais reste peu avancé. Il s'agit surtout de tenter de supporter des machines mythiques comme l'Atari Falcon ou l'Amiga… pour le fun !
WebPositive, le navigateur basé sur WebKit
Le navigateur basé sur Webkit avance bien.
Début septembre, Adrien Destugues est une nouvelle fois embauché pour travailler cette fois-ci sur WebPositive et le portage de WebKit. Ses objectifs sont :
- Documenter le "Service Kit" (le composant qui gère les différents protocoles de communication : HTTP, FTP, …)
- Effectuer un travail de fond sur le port Haiku de WebKit, notamment s'assurer qu'il prend en charge le plus grand nombre possible de sites web.
- Améliorations en tout genre : retravailler le moteur de recherche, …
- Mettre à jour WebKit, l'évolution rapide du moteur de rendu rend difficile la synchronisation avec le port Haiku.
- Mettre en place un système de compilation automatisé de WebKit ( buildbot ) afin de faciliter les mises à jour et aussi avoir un moyen aisé pour faire de la cross-compilation.
Vous pouvez consulter les dépots WebKit et Haiku sur Github sur le sujet ou consulter les infos directement sur le site d'Haiku : 1 ou 2
Gestionnaire de paquets
Fin mars, la fondation a annoncé l'embauche de deux développeurs pour une durée de deux mois afin de travailler sur le système de paquets : Olivier Tappe et Ingo Weinhold. Le système de compilation des paquets a été grandement amélioré. Le principal objectif de ces deux mois de travail était de pouvoir compiler un paquet donné ainsi que toutes ses dépendances. Ingo et Olivier avaient donné une conférence au BeGeistert 024 fin novembre 2011 a propos de l'état des paquets et de ce qu'ils prévoyaient. Le tout est disponible en vidéo sur Youtube en cinq parties : partie 1, partie 2, partie 3, partie 4, partie 5.
Ce qui suit est un bref résumé du travail accompli sur la gestion des paquets pour Haiku, Olivier et Ingo ont régulièrement communiqué à la communauté l'avancement de leurs travaux. Malgré la fin de leur contrat, ils ont continué d'améliorer le système de paquet à tel point qu'Ingo a été de nouveau embauché début juin par la fondation pour une durée d'au moins trois mois.
Format des paquets et technologies utilisées
Haiku possédait déjà un système de paquets un peu rudimentaire, mais néanmoins fonctionnel. Un des objectifs était d'améliorer son fonctionnement et lui ajouter quelques fonctionnalités essentielles, comme la gestion des dépendances. Chaque paquet Haiku était décrit par un fichier BEP, une sorte de recette de cuisine qui permettait entre autres d'indiquer les dépendances, la manière de compiler et la manière d'installer un paquet. Bien que pratique, ces fichiers demandaient du temps pour être conçus et maintenus.
Pour faciliter la conception des fichiers BEP, l'idée était d'extraire un maximum d'informations des systèmes de paquets déjà existant. Plusieurs systèmes de paquet furent considérés et les EBuild de Gentoo furent retenus, en partie car ce sont de simples scripts shell. Afin de faciliter la conversion EBuild vers BEP, il a été décidé que les BEP devaient être eux aussi des scripts shell. De plus, haikuporter - le programme chargé de compiler un paquet à partir du BEP - alors écrit en Python devait dans l'idéal être réécrit avec Bash ou C/C++.
Il s'est finalement avéré qu'il n'y avait pas de difficulté majeure à continuer d'utiliser Python pour haikuporter. Seule la conversion des BEP en script shell a été effectuée. Ce changement de format a aussi occasionné un changement de nom : les fichiers BEP sont dorénavant appelés 'recettes' (recipes en anglais) et doivent être nommés nom_du_paquet.recipe. L'utilisation des EBuild de Gentoo fut abandonné, notamment car le nombre d'applications empaquetées pour Haiku est d'environ 50.
Réorganisation du système et cross-compilation
Afin d'avoir un système le plus cohérent possible, beaucoup de programmes dits "tiers" étaient inclus dans le dépot officiel des sources. Ces programmes sont nécessaires pour une installation basique d'Haiku, ils comprennent entre autre les outils GNU (coreutils), les classiques grep et sed, mais aussi haikuporter, essentiel puisqu'il permet d'installer d'autres logiciels. Néanmoins, cette manière de faire avait quelques défauts, notamment le fait d'avoir plusieurs systèmes de compilation à maintenir. C'est pourquoi il a été décidé d'enlever tous ces programmes tiers pour en faire des paquets, qui seront pré-compilés et inclus par la suite à l'image de base.
La poule ou l’œuf ?
Maintenant que le compilateur est lui aussi un paquet, un nouveau problème se pose. Sur une nouvelle architecture, comment compiler un paquet pour la première fois, alors que l'on a besoin de lui pour le compiler ? La solution utilisée est la compilation croisée (cross-compilation) : l'idée est de construire le paquet sur une autre architecture (et en n'utilisant pas forcément Haiku).
Construction d'un paquet
Une histoire de recette
Chaque paquet est dorénavant décrit par une recette, qui est en fait un script shell avec quelques contraintes de fonctionnement. Voici un exemple simple de fichier recette, haikuporter-0.recipe, tout droit tiré du dépôt git dédié aux recettes des programmes de "base"¹ :
SUMMARY="tool for building packages from build recipes"
DESCRIPTION="haikuporter drives the process of building Haiku packages from recipe files."
HOMEPAGE="http://ports.haiku-files.org/wiki/HaikuPorterForPM"
SRC_URI="git+https://bitbucket.org/haikuports/haikuporter.git#c2e271a220019327dc66edc24314dfb4177212b7"
LICENSE="MIT"
COPYRIGHT="2007-2013 Brecht Machiels et al"
REVISION="1"
ARCHITECTURES="any"
PROVIDES="
haikuporter = $portVersion
cmd:haikuporter = $portVersion
"
REQUIRES="
cmd:python
"
BUILD_REQUIRES="
"
BUILD_PREREQUIRES="
"
BUILD()
{
true
}
INSTALL()
{
haikuporterDir=$libDir/haikuporter
mkdir -p $installDestDir$haikuporterDir
cp -r haikuporter HaikuPorter $installDestDir$haikuporterDir
mkdir -p $installDestDir$binDir
ln -s $haikuporterDir/haikuporter $installDestDir$binDir
}À noter qu'en plus de BUILD et INSTALL, il existe une troisième action nommée PATCH, afin d'appliquer les éventuels patchs.
Le passage du format BEP aux scripts shell a aussi été l'occasion de revoir quelques points fondamentaux du système de paquets :
- Afin de rendre l'installation d'un paquet plus souple, seuls les chemins relatifs et/ou les variables du système de paquet doivent être utilisés
- Toutes sortes de documentation doivent aller dans le répertoire dédié :
documentation/ - Les anciens répertoires
etc/etshare/doivent être répartis dansdocumentation/,settings/oudata/ - Les fichiers d'en-tête auparavant situés dans
include/sont déplacés dansdevelop/headers/ - Enfin, les bibliothèques de développement sont placées dans
develop/lib/
Pour les curieux, consultez l'organisation des répertoires utilisée pour Haiku.
À noter qu'il est possible de générer plusieurs paquets à partir d'une recette, par exemple générer un programme et sa documentation dans deux paquets distincts.
(1) : Ce dépôt contient les recettes pour les programmes de base, c'est-à-dire absolument nécessaires pour faire fonctionner une installation d'Haiku. C'est pourquoi ils doivent avoir le moins possible de dépendances. Par exemple, la recette pour le programme grep de ce dépôt n'est pas la même que pour le grep classique.
Compilation
Le paquet est ensuite construit par haikuporter dans un environnement chrooté. Tout les outils nécessaires à la compilation du programme sont installés dans cet environnement. Bien que haikuporter soit écrit en Python, il n'y a pas eu de difficulté particulière pour mettre en place un environnement chrooté.
Gestion des paquets
Pour gérer les paquets d'un système, un démon a été conçu. Ce tout nouveau programme a plusieurs missions :
- Il doit gérer les paquets activés ou désactivés
- Il doit veiller sur les fichiers utilisés par les différents paquets.
- Il se charge de résoudre les dépendances et de détecter les conflits lors de l'installation ou la suppression de paquets.
Le dernier état des lieux concernant ce démon précise que toutes les fonctionnalités prévues n'ont pas encore été implémentées.
Tout est (système de) fichier
L'originalité de cette nouvelle gestion de paquets tient surtout à la façon dont leur contenu est publié. En effet, un packagefs monté au dessus de certaines parties de l'arborescence publie dans le système de fichier le contenu agrégé des paquets activés.
Ce changement ne s'est pas effectué sans problème. En effet, une partie importante de l'arborescence est maintenant en lecture seule, imposant de corriger de nombreux scripts, ainsi que certaines applications mal élevées se permettant d'écrire dans leur répertoire d'installation, ce qui est traditionnellement possible sous BeOS qui ne supportait pas le fonctionnement multi-utilisateurs. Il a été tenté d'introduire des répertoires non-packaged/ par ailleurs dont le contenu serait superposé par packagefs au contenu des paquets mais les performances étaient dégradées significativement. Certains débats sont encore en cours, concernant notamment le répertoire /boot/common, qui était l'équivalent de /usr mais a été supprimé, alors qu'il n'existait pas sous BeOS.
La sortie de la commande df :
~/Desktop> df
Mount Type Total Free Flags Device
--------------- -------- --------- --------- ------- --------------------------
/boot bfs 299.7M 147.4M QAM-P-W /dev/disk/ata/0/master/raw
/boot/system packagefs 4.0K 4.0K QAM-P--
/boot/home/config
packagefs 4.0K 4.0K QAM-P--
Il reste à savoir si cette idée originale passera à l'échelle, en tout cas c'est une manière originale d'installer un paquet !
Optimisations de l'ordonnanceur
Paweł Dziepak, qui a rejoint l'équipe des contributeurs Haiku durant l'édition 2012 du Google Summer of Code en contribuant un client NFSv4, est embauché par Haiku, Inc. pour améliorer l'ordonnanceur utilisé par Haiku. Il s'agit d'un élément important du système, la gestion des priorités des threads permettant de rendre Haiku plus réactif et plus rapide. Les différents objectifs sont:
- Verrouillage des threads sur un coeur de processeur, autant que possible, afin de mieux utiliser le cache de niveau 1,
- Répartition de la charge sur différents coeurs en tenant compte de la topologie, ce qui permet de diminuer la consommation électrique en désactivant ou ralentissant les coeurs non nécessaires, et d'augmenter les performances en utilisant au mieux les caches partagés entre coeurs (cache L1 avec HyperThreading, cache L2 unifié entre plusieurs coeurs).
- Découpage plus fin des verrous pour les structures utilisées par l'ordonnanceur pour la gestion des threads.
Il publie régulièrement sur son blog à ce sujet.
D'autre part, Julian Harnath a réalisé plusieurs améliorations sur l'implémentation des ports de communication (une des IPC natives) pour également réduire les problèmes de blocage qui rendaient Haiku difficilement utilisable avec une charge processeur trop élevée. Il poursuit son travail avec des améliorations au niveau du Media Kit, afin de diminuer la latence constatée sur le traitement temps réel du son avec l'implémentation actuelle.
# Recette
Posté par Rolinh (site web personnel) . Évalué à 10.
Une recette Haiku est très similaire à un PKGBUILD chez Arch Linux à ce que je vois, avec
haikuporterau lieu demakepkgpour la création du paquet.Exemple de PKGBUILD:
# Merci !
Posté par Thom (site web personnel) . Évalué à 10.
Merci pour cette dépêche.
Haiku est vraiment un projet intéressant, c'est même selon moi l'un des plus intéressant de ses dernières années.
Bref, à suivre.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Merci !
Posté par Guillaume Gasnier . Évalué à 1.
Effectivement, merci pour ces informations.
Je suis également la progression du projet depuis son annonce.
Cela fait vraiment plaisir d'avoir des nouvelles.
Encore merci.
[^] # Re: Merci !
Posté par the_grammar_nazi . Évalué à 2.
*ces
[^] # Re: Merci !
Posté par Thom (site web personnel) . Évalué à 4.
Tu portes bien ton nom. ;)
Merci pour la correction.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# Badbios
Posté par Astaoth . Évalué à 1.
Est-ce que Haiku est Badbiosproof ?
Emacs le fait depuis 30 ans.
# Intérêt
Posté par ariasuni . Évalué à 10.
J’entends dire beaucoup de bien d’Haiku de la part de nostalgiques de BeOS et/ou OpenBeOS, et j’avoue que j’ai un peu de mal à comprendre, ne faisant pas la catégorie sus-cité (étant un des plus jeunes à visiter Linuxfr, vous comprendrez aisément que je n’ai pas tellement connu la glorieuse période des disquettes).
J’ai jeté un œil vite fait aux captures d’écran et ça me fait penser à un truc tout vieux (sans vouloir être méchant, hein ;)) genre Window Maker, en tout cas ça donne pas trop envie aux personnes lambda (même si j’imagine que ce n’est pas la cible…) Perso je trouve ça agréable d’avoir un bel environnement et puis ça donne plus envie aux non-gnu-linuxiens de tester.
Deuxièmement, j’ai l’impression que ça demande vraiment beaucoup de boulot à refaire des logiciels, parce que bon autant le gestionnaire de paquet on a l’habitude (et dans ce cas je ne pense pas avoir l’expertise pour juger si c’est pertinent ou non), mais l’interface graphique, le système de fichiers, les applications BeOS, etc, ça commence à faire beaucoup de choses.
Je suppose qu’il serait difficile d’implémenter Ext4 et de le maintenir, pour la boite à outils graphique je suppose que tout ceux utilisés sous GNU/Linux sont fortement liés à X.org (et maintenant aussi à Wayland), et que vu la taille du bousin ça serait chiant de rajouter et maintenir un arrière-plan.
De toute manière, que le projet échoue (je ne le souhaite pas) ou continue encore plusieurs années (il semble bien parti pour), la diversité technologique et l’expérience que l’on pourra retirer des choix techniques fait pour ce système me paraisse très intéressant car HaikuOS semble pas mal différent des autres systèmes, contrairement à GNU/Linux et les *BSD qui semblent bien plus proches (même si bien sûr ils ont beaucoup de différences).
Bref, j’ai l’impression que ça demande beaucoup de travail pour ne viser que les nostalgiques sus-cités, et je me demandais quel intérêt ça pouvait avoir pour les autres. À priori la vitesse et la simplicité, mais bon cette dernière étant difficile à définir et impossible à mesurer, je m’en remet à vos commentaires éclairés sur «pourquoi BeOS c’est génial».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Atem18 (site web personnel) . Évalué à 10.
Gnu/Linux, c'est Ubuntu donc trop connu et OS X, ce n'est qu'un FreeBSD qui a couché avec Apple. En gros, le hispter geek ne peut pas se reconnaître dans ces systèmes mainstream. Il recherche donc l'exotisme et c'est dans Haiku qu'il le trouve. En plus, le nom sonne cool.
P.S. : C'est une blague hein, en tant qu'admin-sys, j'aimerais savoir aussi si ce système est intéressant pour le desktop ou pour le server.
[^] # Re: Intérêt
Posté par Le Gab . Évalué à 5.
Ou pose toi l'autre question: En quoi GNU/Linux n'est actuellement pas intéressant pour le bureau ou le serveur?
[^] # Re: Intérêt
Posté par Atem18 (site web personnel) . Évalué à 2.
J'aurais aimé te répondre, mais le BSOD de Windows et les fenêtres non redimensionnables de OS X, ainsi que Hyper-V ou IIS et la pseudo existence de OS X Server ne voient pas de réponse à ta question.
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 2.
Est-il possible de paver les fenêtres sur les bords de l'écran?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Gilles G. . Évalué à 1.
Sous OSX, il y a une application pour ça:
http://spectacleapp.com/
C'est limité, mais ça correspond exactement à mon usage (même fonctionnement que sous Lubuntu).
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 1.
Hahaha, une application pour faire ce qui se fait de base sur Windows 7/Unity/GNOME Shell/KDE/Xfce.
En plus c'est ultra-utile comme truc non? J'utilise ça assez rarement, mais je suis vachement content que ça existe.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Rolinh (site web personnel) . Évalué à 0.
Il existe également BetterTouchTool/BetterSnapTool. C'est pas libre mais très complet et personnalisable.
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 3.
Oui, avec
ExposéGrand Perspective, mais juste le temps de choisir la fenêtre à mettre au premier plan ;)BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 1.
Ce qui est moche avec les trolls c'est quand ils ne sont plus du tout à jour.
Car sous OSX on peut redimensionner les fenêtres depuis n'importe quel bord (en standard évidemment).
[^] # Re: Intérêt
Posté par Guillaume Denry (site web personnel) . Évalué à 6. Dernière modification le 06 novembre 2013 à 11:55.
Est-ce qu'on peut enfin les maximiser simplement ou bien "il y a une application pour ça" ?
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 0.
Je sais pas vraiment, je ne maximise jamais mes applications sur un mac (je vois pas vraiment l'intérêt)
Alors c'est sur que le bouton de maximisation a parfois des comportements inattendus lorsqu'on ne comprend pas ce que ça veut dire. Mais là avec mon chrome ça maximise bien comme il faut, sourcetree, sublime text, iterm2 aussi, etc. Donc je dirais qu'à priori oui.
[^] # Re: Intérêt
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
On ne ressent pas le besoin de maximiser ses applications sur un mac ? Wow, ils sont forts :)
[^] # Re: Intérêt
Posté par Strash . Évalué à 4.
Je crois que tu critiques surtout sans jamais avoir essayé.
Il existe bien entendu un bouton maximiser sur les fenêtres de (quasiment) toute les applications mac. Il s'agit du bouton vert, qui affiche un + lorsqu'on le survole. Une fois ce bouton cliqué, la fenêtre prends tout l'espace (excepté l'espace réservé au dock s'il n'est pas masqué et à la barre de menu, tout comme ça ne masque pas les barres des taches sous Windows ou Linux).
Les seules applications qui ne se maximisent pas complètement (et elles sont rares, je n'en utilise aucune) sont les applications qui n'ont aucun intérêt à être maximisée (agrandir la fenêtre n'afficherais pas plus d'information). Je n'ai pas d'exemple en tête tellement c'est rare.
Une différence majeure avec les autres OS est que lorsqu'on maximise une fenêtre, ça ne l'empêche pas de pouvoir être déplacée. Elle est donc redimensionnée pour prendre toute la place mais elle conserve la possibilité d'être déplacée ou redimensionnée. C'est un peu déroutant au début mais c'est vraiment une histoire d'habitude, et à l'usage ça ne dérange pas du tout (c'est même dans certains cas utile).
Une autre différence aussi est que sur certaines applications pour qui c'est utile (media player, visualisateur de photos, …) il y a un autre mode de maximisation qui prends alors tout l'espace à l'écran (donc qui masque aussi la barre de menu et le dock). C'est utile pour profiter pleinement de l'espace à l'écran (photos), et aussi pour se concentrer sur une tache en particulier.
Concrètement l'application crée un nouveau bureau et s'y maximise. On peut bien entendu revenir aux autres bureaux qui restent disponibles.
Tout ça pour dire qu'un argument "les fenêtres non redimensionnables de OS X" fait doucement rigoler un utilisateur de MacOS X, et ce depuis bien des années.
Et oui, c'est un fait, pour certaines applications, il ne me viendrait jamais à l'esprit de les maximiser, en effet la taille par défaut est souvent très bien adaptée au contenu, et comme cette taille s'adapte également suivant l'utilisation, maximiser est tout simplement inutile. Au final je pense que la seule fenêtre que je maximise régulièrement est celle de Firefox.
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 4.
Je ne sais pas si ça a changé, mais quand on veut maximiser Safari, il se maximise par rapport à la page web qu’on visite en largeur. Du coup, un site prévu pour 1024×768 s’affichera avec 768 pixels de largeur. Et quand tu vas sur un autre site optimisé pour le 1280×102, bah tu dois recommencer. Oui c’est stupide.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 1.
Je n'utilise jamais le bouton vert "maximiser" de Mac OS X.
Je dimensionne un peu au pif mes fenêtres (lorsqu'elles en ont besoin, par exemple les navigateurs) et ça passe partout.
Si je veux des applications maximisées, j'utilise iOS qui fait ça très bien, sinon je profite du système de multifenêtrage qui marche très bien.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par barmic . Évalué à 3.
Autant je trouve le débat inintéressant, autant changer d'OS pour changer de gestionnaire de fenêtre me semble euh… to much. Si on veut les boutons rouge, orange et vert à droite ou à gauche il faut passer à iOSXreloaded ?
Ce même si les même applications existent pour les 2 (je ne sais pas si c'est le cas). Si pour passer d'une utilisation à l'autre tu es obligé de faire une réinstallation ou un reboot avec un dualboot, va falloir arrêter de se moquer du manque de configuration de gnome.
Bien sûr je parle uniquement de ton argument bidon, je ne juge pas la qualité du gestionnaire de fenêtre d'OSX.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 1.
???
Ah, je comprend mieux ce commentaire décousu et hors sujet. Je prend ton attaque gratuite et la remet à sa juste place.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par freem . Évalué à 0.
En même temps, c'est toi qui a parlé de changer d'OS pour avoir des applications maximisées:
Avoues que ça à de quoi faire rire comme message. J'ai même cru que c'était volontaire au début. (bon, perso je m'en fiche, je considère le floating mode comme totalement inefficace. Je ne maximise pas mes fenêtres, c'est pas mon job, mais celui du gestionnaire de fenêtre après tout.)
[^] # Re: Intérêt
Posté par steph1978 . Évalué à 2.
Oui, c'est ce qu'on croit quand on clique dessus.
Et puis, on tombe des nues : la fenêtre se place n'importe où et ne prend clairement pas tout l'espace. Cela m'a toujours atterré que ce bug (feature ?!) se perpétue de version en version.
[^] # Re: Intérêt
Posté par Alex . Évalué à 2.
C'est par exemple le cas de chrome (vu qu'il fallait un exemple)
ceci dit le mode plein écran et/ou le mode présentation corrige plus ou moins cela
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 Dr BG (site web personnel) . Évalué à 2.
Hé bien non justement, on en perd vite l'habitude en se rendant compte que ce n'est pas forcément utile.
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 4.
Ben oui, en général c'est bien ça.
Alors que sous windows je maximise tout, sous linux beaucoup aussi, sous mac non. Y compris avec les mêmes applications pour faire la même chose.
C'est lié par exemple au fait que les applications ont une bordure extra fine, qu'il n'y a pas de menu et souvent peu de barres d'outils, ce qui qui fait qu'il y a moins d'espace perdu donc moins besoin de maximiser pour avoir un contenu suffisamment visible.
C'est probablement aussi lié au fait que derrière tout ça il y a le côté où les applications sont faites pour s'exécuter sans fenêtre visible, que le multi fenêtre est là depuis longtemps (voir par exemple ce qui existait déjà chez nextstep)
Donc oui en général sous mac je vais beaucoup moins maximiser que sur les autres systèmes où j'ai toujours l'impression de ne pas avoir de place.
[^] # Re: Intérêt
Posté par claudex . Évalué à 8.
C'est bizarre de lire qu'on ne maximise pas parce qu'il y a assez de place pour l'appli. Alors que moi, je maximise aussi pour cacher les trucs derrière qui n'ont rien à voir.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par flan (site web personnel) . Évalué à 3.
Dans ce cas, le mode plein-écran est fait pour toi.
Au final, le système est plutôt bien fichu. Il faut accepter que ça ne fonctionne pas comme sous Linux ou comme sous Windows, mais ce n'est pas pour autant que c'est moins bon… C'est simplement différent.
[^] # Re: Intérêt
Posté par claudex . Évalué à 2.
Ah non, le mode plein écran, ça ne permet pas de changer d'application facilement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par flan (site web personnel) . Évalué à 3.
Via F10 (Exposé), Pomme+Tab ou Ctrl+Flèches. C'est plutôt pas mal je trouve.
[^] # Re: Intérêt
Posté par claudex . Évalué à 3.
Ce n'est pas à la souris et j'aime bien changer de fenêtre à la souris ou au clavier en fonction de ce que je fais.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par Strash . Évalué à 3. Dernière modification le 07 novembre 2013 à 10:51.
Tu y mets vraiment de la mauvaise volonté.
On peut bien entendu changer de fenêtre à la souris, il y a plein de solutions:
- Cliquer sur l'icone de l'application en question sur le dock
- Configurer un "coin actif" pour lancer Exposé et choisir ta fenêtre
- Si tu utilises le Pad (ou la Magic Mouse tactile), faire la "gesture" 3 doigts vers le haut qui lance Exposé
- Mettre l'icone Exposé dans le dock et l'utiliser
Si tu es en mode plein écran:
- 3 doigts vers la droite/gauche pour repasser au bureau
- coin actif pour Exposé
[^] # Re: Intérêt
Posté par zebul0n (site web personnel) . Évalué à 2.
J'écris à partir du rmbp de ma moitié, et c'est une machine formidable, et mac OS est vraiment bien travaillé.
Tous ses trucs d'exposé sont aussi apparus dans les bureaux linux, par exemple j'utilise ElementaryOS depuis le passage à Ubuntu Unity et gnome-shell et c'est plutôt pas mal.
Mais j'arrive pas à m'y faire, je me force, mais mon cerveau reptilien est tellement ancré dans l'ancien paradigme, qu'il me faut une barre des tâches sinon je peste, comment je retrouve la 3eme fenêtre de sagasu que j'ai ouverte par exemple …
Du coup, j'ai installé Tint2 que j'ai configuré pour agir uniquement en barre des tâches et depuis je suis heureux, je peux bénéficier de tout ce que j'aime des nouveaux bureaux et conserver les bonne vieilles habitudes qui contribuent à ma productivité.
D'ailleurs, avant sous gnome, je pouvais faire alt-molette pour changer l'opacité de la fenêtre, c'était pratique dans bien des situations et je ne sais pas si c'est encore possible, ça aussi ça me manque terriblement, j'ai pas encore trouvé de solution.
Bref, tout ça pour dire que c'est pas de la mauvaise volonté, quand on a ses habitudes, c'est difficile d'en changer et c'est pas spécifique aux logiciels …
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 4.
La barre des tâches c'est pas si vieux que ça : Windows 95 !
Avant on faisait autrement et on s'en accommodait pas si mal.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par zebul0n (site web personnel) . Évalué à 4.
Absolument, j'ai jamais ressenti le besoin d'une barre des tâches sur mon commodore 64 à cassette ou sur le windows 3.11 de mon PS/1. C'est vrai que je m'en accommodais pas si mal.
Mais maintenant que ça fait plus de 15 ans que j'y suis habitué, j'ai du mal à m'accommoder de la voir disparaître, j'en ai besoin sur un ordinateur de bureau ou un portable …
Les habitudes ont la vie dure !
[^] # Re: Intérêt
Posté par flan (site web personnel) . Évalué à 3.
c'est sûr, il faut de la volonté pour changer ses habitudes.
J'ai dû pas mal me forcer (et m'y reprendre à trois reprises) pour utiliser un IDE (Pycharm) pour faire du Python à la place d'un VIM que j'utilise depuis 8 ans, avec une façon de travailler qui n'a plus rien à voir. Au final, j'y ai beaucoup gagné, mais ce n'était pas si facile.
Pareil pour passer à OS X (il y a 9 ans), j'ai dû me forcer à tout repenser (façon de ranger ses documents, utiliser les applications natives d'OS X alors que j'étais parti sur Firefox et Thunderbird, …) et utiliser les subtilités d'OS X, mais au final je pense avoir été gagnant.
Mais après, même en faisant des efforts, certains environnements ne plairont jamais à certaines personnes, on ne peut rien y faire.
[^] # Re: Intérêt
Posté par JGO . Évalué à 4. Dernière modification le 07 novembre 2013 à 10:57.
Je ne comprends pas trop ton commentaire du genre « sous linux [je maximise] aussi beaucoup » ou « ça ne fonctionne pas comme sous linux ». Ça ne dépend pas de linux mais de ton gestionnaire de fenêtres/bureau ; dire linux ne suffit pas, qu'as-tu testé : gnome, unity, kde ? (et quelle version ?)
Pour parler de ce que je connais, kwin est personnalisable en quelques clics pour faire ce que tu apprécies (aucune bordure si tu veux : clic droit sur la barre de titre → plus d'actions → pas de bordure) ; personnellement je configure fluxbox avec des décorations fines et minimalistes pour économiser la place (mais là il faut ouvrir les fichiers de conf). De nombreuses applications pour linux supportent aussi un mode plein écran ; touche F11 pour les logiciels gtk, ou ctrl-maj-F pour les logiciels kde.
[^] # Re: Intérêt
Posté par freem . Évalué à 3.
S'il te plaît… Associer linux à une seule façon de voir la gestion des fenêtre, c'est juste ridicule. Il y a moult gestionnaires de fenêtres, des grands classiques imitant le
fouillirangement des bureaux réels, à ceux qui sont rarement utilisés et utilisent la machine pour faire tout le travail de redimensionnement.Par contre, je te rejoins sur:
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 5.
Si c'est juste pour cacher, il est inutile de maximiser, il suffit de … cacher.
C'est un truc que j'adore avec *STEP et Mac : pouvoir cacher une application (≠ de réduire une fenêtre) et pouvoir cacher toutes les autres applications par exemple.
L'avantage c'est que tu ne te retrouve pas à maximiser pour faire autre chose. C'est plus propre comme comportement.
[^] # Re: Intérêt
Posté par claudex . Évalué à 4.
Comment tu cache le bureau ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 1.
Pour ceux qui ont de graves troubles de la concentration et/ou un wallpaper trop distrayant, il existe plusieurs applications qui jettent un voile d'ombre sur tout ce qui n'est pas la fenêtre active : http://mac.appstorm.net/roundups/productivity-roundups/15-mac-apps-to-help-you-focus-and-work-productively/
Mais à ce compte là, autant vraiment ce concentrer en passant l'application en plein écran.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par barmic . Évalué à 4.
C'est marrant moi j'ai une approche totalement opposée. Pour moi l'inintérêt des bureaux me pousse à ne pas chercher à lui laisser la moindre place sur mon écran. C'est quelque chose que j'ai appris avec les gestionnaires de fenêtres pavants. Ils n'implémentent pas de bureau tel qu'on l'entends à peut prêt partout ailleurs (et qui soit devient un immense bordel indémerdable avec des icones qui se mélangent avec le fond d'écran), soit se limitent à peu de choses qui sont vraiment utile et qui pourraient avantageusement être dans un lanceur (un dock, un truc à la unity, un truc à la unity ou autre).
Depuis que je n'ai plus de bureau et que j'ai pris l'habitude de travailler dans des dossiers temporaires à la place je perds moins de temps à trouver ou trier mes fichiers (je crée un nouveau répertoire de travail à chaque fois et je le range si je ne veux pas qu'il soit supprimé sous peu).
Comme quoi c'est vraiment une question d'habitude et de point de vu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par Le Gab . Évalué à 0.
Il y a eu/a un problème avec la maximisation, je ne sais pas si c'est résolue mais de toute façon, depuis "Mountain Lion" voire depuis Lion je crois, il y a un mode plein écran à la Firefox (raccourci F11), donc sans les décorations.
Oui, oui, ça existe depuis un bail dans nos gestionnaires de fenêtres libres là n'est pas la question. :)
intérêt: profiter un max de l'espace de ton bel écran et faire une chose et la faire bien.
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 3.
Oui, il y a depuis 2 ans à peu près un bouton "passer en plein écran" pour la plupart des applications (toutes celles qui en ont besoin)
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par Samir Noir (site web personnel) . Évalué à 9. Dernière modification le 06 novembre 2013 à 01:18.
Parce que les BSD sont supérieurs ?
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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.
[^] # Re: Intérêt
Posté par cedric . Évalué à 3.
Ca m'interresse de savoir comment la stack graphique fonctionne sur Haiku. Tu as un lien ou de la doc sur le sujet ? De plus, c'est une question historique, si il y a plusieurs moyens d'acceder a l'ecran (fb, kms/drm, X, directfb et wayland). Et le poid de porter un toolkit graphique est tres largement sur evalue. Ce qui prend du temps, c'est de l'optimiser. Mais ca, ca se fait en faisant evoluer le protocol sous jacent le plus souvent.
C'est le boulot de toolkit comme Qt ou les EFL de fournir ca, tout en tirant parti des ameliorations du systeme au fur et a mesure du temps. Sans compter que l'API de la libc et du kernel sont aussi stable. Donc je ne vois pas en quoi cela fait une difference ici (Il est vrai que des projets tierces n'auront pas cette garantie de fournit, mais au final le probleme se posera aussi pour Haiku).
D'ailleur une question qui me taraude quel est l'interet du toolkit graphique de Haiku par rapport aux autres toolkit existant.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 Thom (site web personnel) . Évalué à 3.
Pour quelqu'un qui fait du c++, ça donne l'eau à la bouche et ça donne bien envie d'aller voir le code pour voir comment tout ça est gérer.
Merci pour les compléments.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Intérêt
Posté par cedric . Évalué à 3.
Effectivement tres different de la stack Linux. Le principe ici, si j'ai bien compris, est que l'application construit une liste de ce qu'elle veut rendre a l'ecran et la donne a un thread en charge du rendu. Celui-ci est synchronise par le serveur graphique (equivalent de X) qui va en fait definir une zone de clip a l'ecran et laisser le thread de rendu faire le rendu de la fenetre en question directement dans le buffer de l'ecran.
Sous Linux, l'evolution de tous les toolkits graphiques est allez vers l'utilisation d'un systeme a multiple buffer qui est donne au compositeur. C'est a dire que l'application n'a jamais acces directement a l'ecran. Apres chaque toolkit peut si il le veut faire le rendu dans un thread de maniere asynchrone avant de donner le buffer au serveur graphique. C'est ce que font a ma connaissance les EFL et Qt/QML.
Je me demande d'ailleur comment s'en sort Haiku avec OpenGL, car ca me semble tres difficile a implementer dans un tel contexte.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 Guillaume Maillard (site web personnel) . Évalué à 4.
j'aurais bien mis le site à jour, mais il a été cybersquatté il y quelques années :)
BlueEyedOS était bien avancé, de quoi faire tourner des applications programmées avec l'API de BeOS sur linux rapidement et proprement.
Sur matériel identique, les IPCs via BMessage étaient plus de 20 fois plus rapide sur BlueEyedOS/Linux que sur BeOS 5…
Bref, BlueEyedOS c'était du BeOS sous stéroid. Et si tout cela s'est arrêté, il ne faut pas chercher bien loin :
tout le monde s'en fou (hormis peut être les créateurs de Wayland…) d'avoir un espace utilisateur moisi sous linux, Gnome et KDE sont sensés suffire!
Il y a 11 ans, quelques aspects de X(Free86) qui me font toujours sourire !
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 5.
J'ai été très triste de voire BlueEyedOS "mourrir". C'était de très très loin la meilleure initiative pour faire renaître BeOS (en tout cas la plus pragmatique).
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par cedric . Évalué à 5.
Ah mais non, c'est pas vrai ca ! Si on se demerde pour que Enlightenment avec tous les effets fonctionnent de maniere fluide meme sur le bas de gamme, c'est pas pour s'entendre dire ca quand meme ! Il y a des communautes pour qui la fluidite, la legerete, les effets graphiques doivent etre la. En tout cas, il y en a au moins une, Enlightenment.
Enlightenment en software marche tellement bien que les devs ne se rendent pas compte quand leur driver OpenGL ne fonctionne plus ! En plus, il fait gagner de la batterie par rapport a utiliser le backend OpenGL ! Terminologie, l'emulateur de terminal de Enlightenment, est aussi rapide que urxvt, consomme moins de memoire et a plus de fonctionnalite graphique que n'importe lequel de la concurrence.
Allez demo time: http://enlightenment.org/p.php?p=about/terminology&l=en . Donc non, il y a des trucs rapide, lege et customisable de dispo sous Linux. Apres si tu te cantonnes a KDE et GNOME, c'est clair, ce n'est pas leur objectif !
Plus aucun toolkit sain d'esprit ne fait ca de nos jours ! Tout est rendu cote client et c'est juste un swapbuffer cote serveur ou un xshm upload.
[^] # Re: Intérêt
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Génial ce truc ! J'ai l'impression d'être un hacker de blockbuster rien qu'en tapant des commandes shell.
[^] # Re: Intérêt
Posté par Spack . Évalué à 4.
Et si je tape
tyssh, j'ai des chances de me retrouver transporté dans le data centre ?[^] # Re: Intérêt
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
par "tout le monde s'en fou", j'entend les utilisateurs de linux sur desktop en général, ce qui est démontré par :
- le choix par défaut des distributions majeures avec Gnome et KDE
- le pourcentage faible d'utilisateurs d'Enlightenment… :) aie
- les développeurs d'applications qui utilisent majoritairement Qt & GTK (ou pour les plus jeunes.. HTML5 ;) ).
Si on aime les "si", on peut se dire que SI ça préoccupait tant que ça les développeurs, KDE et Gnome seraient des projets morts de puis 5 ans et que des projets comme feu BlueEyedOS compterais 553 développeurs et des millions d'utilisateurs.
Pour rebondir sur l'état du desktop il y a 11 ans, certaines choses perdurent comme le windowmanager indépendant qui entraîne une certaine décohérence de timing et d'état du rendu entre bordure de la fenêtre et son contenu.
Mais tout va bien désormais: qq workaround, une bonne carte graphique, un dual core à 3GHz avec 4Go de ram, voici le parfait cocktail pour ne plus avoir à se préoccuper de ce genre de détails.
Bref, ce qui compte maintenant c'est d'avoir un bon ERP genre OpenConcerto, nan? :)
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 0.
Ben voui, GNOME et KDE c’est du gros caca c’est bien connu. Et puis BeOS ça claque tout donc forcément que le reste c’est de la merde.
Nan mais oh.
Je pourrais retourner la situation, avec la dernière mouture de Linux qui poutre tout, systemd, Wayland, KDE Frameworks 5 et Qt5, etc.
Parce que bon, X.org est pourri mais on aura plus à le supporter bien longtemps!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par cedric . Évalué à 4.
J'avoue que le trend du tout HTML, va pas vraiment vers l'efficacite… Mais ca n'empeche que toutes les communautes ne suivent pas le meme chemin et que certains developpeurs y font attention. La masse n'a jamais fait la validite d'un choix technique, Windows… tout ca…
[^] # Re: Intérêt
Posté par freem . Évalué à 3.
En effet, ça à l'air impressionnant ce terminal, j'ai regardé pendant 5 min la démo. Bon, le type tapant à 2 l'heure, ça m'a soulé, mais j'ai vraiment aimé certains trucs. A voir par contre: il fait pas mal de démo de sélection de texte qui ont l'air intéressantes, mais il les fait.. à la souris. Que ce soit possible à la souris est bien, certes, mais quand j'utilise un terminal, j'ai tendance à ne plus toucher la souris. C'est d'ailleurs vrai pour n'importe quelle application que j'accepte de qualifier de "bien foutue". Donc, faisable au clavier aussi tout ça, ou pas?
Conseil: ne dis des choses pareilles que si aucun utilisateur de WM pavant se trouve physiquement à portée de jet de pavé de toi :)
Blague à part, ceux qui les codent, ainsi que leurs utilisateurs, ne sont pas du genre a aimer KDE/Gnome, justement à cause de ce problème.
[^] # Re: Intérêt
Posté par cedric . Évalué à 2.
Pas a ma connaissance pour l'instant. Tu peux ouvrir un ticket sur https://phab.enlightenment.org/maniphest/ pour demander cette fonctionnalite. Pas franchement la mer a boire a rajouter. Par contre, le plus problematique, ca va etre de trouver des raccourcis claviers sans conflits… Ca commence a etre assez difficile !
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
La multiplicité des raccourcis claviers est la raison qui fait que j'aime l'idée des applications modales. (Ne pas lire modale en tant que multi-thread, comme utilisé dans les toolkit GUI, mais au sens d'utilisation de modes, comme dans vi.)
[^] # Re: Intérêt
Posté par Gof (site web personnel) . Évalué à 2.
Pas vraiment. J'ai regardé vite fait la documentation de BMessage et ça ressemble plutôt au système d'événement de Qt.
Dans Qt, chaque
QObjectest associé à un thread. et on peux poster des messages a un object:Cela va poster un message qui va être reçu par un autre object: (QObject::event est appelé dans le thread associé à cet object)
Et ça ressemble fort à ce que j'ai pu voir dans la documentation de Haiku.
Les signaux est slots c'est du « sucre syntaxique » pour des callbacks. Moins de boilerplate, et plus facile à utiliser. C'est censé produire du code plus lisible et moins spaghetti que de la programmation événementielle.
(Ça utilise des événement en interne)
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 freem . Évalué à 2.
Ce n'est pas un peu lourd, de faire 2 thread (1 côté serveur, 1 côté applicatif) pour chaque fenêtre?
Les threads ne sont pas gratuits, et en plus, n'importe quel tookkit moderne permets de choisir, entre fenêtre modales et non-modales. Les freeze dont tu parles ne sont pas pas à cause du toolkit, mais bien du dev qui a merdé dans son choix.
A noter qu'a mon avis, on use et abuse trop des fenêtres, mais "ce n'est pas grave, seuls les utilisateurs n'utilisant pas mon superbe et magnifique gestionnaire de fenêtre s'en aperçoivent"…
[^] # Re: Intérêt
Posté par Larry Cow . Évalué à 3.
Quel rapport entre la modalité d'une fenêtre et le fait qu'un traitement trop long puisse geler l'interface entière?
[^] # Re: Intérêt
Posté par freem . Évalué à 2.
Le fait qu'en utilisant uniquement des fenêtre modales, si une tâche liée est longue, on freeze toute l'interface de l'application?
[^] # Re: Intérêt
Posté par cedric . Évalué à 2.
/o\ Euh, juste non. Il n'y a aucun rapport.
Quelque soit le type de fenetre, ca marche toujours avec une boucle principal (main loop) et des callbacks asynchrones sur evenements. Ce qui genere des freezes, c'est quand le temps passe dans les callbacks de ton application ne laisse plus le temps au code de rendu graphique pour faire le dit rendu en moins de 1/60 seconde. Il y a plein de chose qui peuvent generer des freezes en plus de calcul un peu long, acces au disque non asynchrone, acces reseau non asynchrone, rendu inutile, … En mettant le rendu dans un thread separe (meme si il faut le piloter), tu te retrouves a avoir un peu plus de temps entre le dernier moment ou tu l'as piloter et le moment ou tu dois le piloter. Combiner avec des IO asynchrones un peu partout, tu eviteras les freezes et tiendra les 60 fps, si ton second core et le code de rendu en est capable.
[^] # Re: Intérêt
Posté par reno . Évalué à 5.
Si je me souviens bien l'auteur du projet a fait des louvoiements bizarre avec la licence du projet et le projet est mort assez vite.
C'était une bonne idée pourtant: la force de BeOS n'était pas vraiment dans son noyau (un Linux moderne est bien plus performant en multithreading que le noyeau BeOS) mais dans tout le reste (design, couche basse, intégration, etc)..
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 5.
Pour accéder directement au framebuffer, tu peux utiliser une BDirectWindow : http://www.haiku-os.org/legacy-docs/bebook/BDirectWindow.html
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
Il n'y a pas de gestion des utilisateurs : l'utilisateur est uid 1. Donc, pour le serveur, on oublie pour l'instant.
[^] # Re: Intérêt
Posté par Francois Revol (site web personnel) . Évalué à 4.
Perdu, c'est uid 0, c'est plus sympa.
En fait ce n'est pas tout à fait exact.
Le noyau de BeOS avait déjà la notion d'uid/gid, mais ne vérifiait pas toujours correctement, et les applications étaient conçues en supposant pouvoir tout faire. En fait il y avait un code expérimental dans la libroot (qui contient la glibc) pour le multiutilisateurs, probablement pour tester les applications, mais ça n'a jamais été testé.
Pour Haiku, le support est un peu plus avancé, même si pour l'instant on est root par défaut, il est au moins possible de créer des comptes pour un serveur ssh par exemple. Il reste que beaucoup d'applications doivent être corrigées.
[^] # Re: Intérêt
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
Perdu :p Mais je ne me souviens plus du nom d'utilisateur. C'est pour ça que j'avais parlé d'UID 1, il me semblait que c'était root à 1, et non 0, m'est trompé (un peu).
En fait, c'était pour rendre le système POSIX friendly. Mais évidement, l'absence de restriction sur les uid fait que le système n'est finalement pas POSIX.
Mais est-ce que les utilisateurs sont maintenant restreints dans HaikuOS ?
[^] # Re: Intérêt
Posté par inico (site web personnel) . Évalué à 3.
Le root sous BeOS/Haiku s'appelle baron.
[^] # Re: Intérêt
Posté par freem . Évalué à 2.
Ouch… dur. Un tel système, s'il devenait populaire au même niveau que windows, apporterait donc le même lot d'emmerdes… non?
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 5.
T’inquiètes, on a du temps devant nous. ;)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 freem . Évalué à 0.
La seule différence que je vois entre 2 et un nombre tendant vers l'infini, en terme de programmation, c'est que dans le cas ou l'on a que 2, on à un magic number et une allocation statique (ok, je simplifie, j'avoue).
Si on veut un système mono-utilisateur, windows nous a enseigné qu'on va avoir des tonnes d'emmerdes de sécurité (mais à l'époque ou windows s'est répandu c'était moins pire car internet était nettement moins répandu dans les chaumières). Microsoft ont depuis corrigé le tir, progressivement ( abandon de la base DOS, puis renforcement du rôle de l'utilisateur admin, ce qui a été très peu apprécié par les utilisateurs de vista ), et je trouve dommage qu'un OS veuille revenir en arrière.
De plus, je doute également qu'il soit aisé de corriger un design avec un tel manque dans des versions futures.
Tu cites android, mais android utilise le noyau linux. Je n'ai jamais eu le déplaisir de l'utiliser (je ne trouve aucun plaisir a utiliser un smartphone, bien au contraire) donc je peux me planter, mais je serai surpris qu'on ne puisse pas, au travers de hack, ajouter un utilisateur. Peut-être que les applications sont installées en userspace de l'utilisateur en cours en fait? Vu qu'il n'y a "qu'un utilisateur" et qu'on enlève le contrôle de l'ajout des utilisateurs à celui-ci, impossible de voir la différence?
[^] # Re: Intérêt
Posté par claudex . Évalué à 5.
Sur android, chaque application tourne sous un utilisateur différent. Ça permet de renforcer la sécurité en utilisant les permission standard Unix.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
Donc ce que dit pulkomandy (1) est hors de propos?
1:
[^] # Re: Intérêt
Posté par claudex . Évalué à 3.
http://source.android.com/devices/tech/security/#the-application-sandbox
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intérêt
Posté par barmic . Évalué à 2. Dernière modification le 11 novembre 2013 à 16:18.
Ben ça n'a rien avoir lancer chaque programme avec un utilisateur différent par rapport à ce qui se fait sur nos distrib', ça a une tête de gros hack (on distingue les applications via les utilisateurs alors qu'ils sont tous pour le même utilisateur. Ils ont fait quelque chose de simple sans réinventer la roue, mais quand tu pars from scratch tu peux penser les choses différements.
Je pense qu'il voulais par exemple dire de ne créer des utilisateurs que pour des utilisateurs réel de la machine et gérer différement qui est actuellement géré avec des utilisateurs sur unix.
Ce n'est pas parce que tout le monde se mappe avec plus ou moins de succès sur ce qu'unix à créer qu'il n'est pas possible d'avoir d'autre modèle de sécurité (les ACL et les LSM sont là pour le prouver).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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: Intérêt
Posté par Sygne (site web personnel) . Évalué à 10.
La réponse est dans la faq de Haiku:
Toute l'intérêt de Haiku réside donc dans la façon dont il assemble Gnu coreutils, python, la pile wifi de Free BSD, et puis aussi les ports de gnome, QT et X11 : c'est un beau bazar, mais il faut voir que, à la différence de linux, c'est un beau bazar avec une vision unifiée de l'os tout entier.
Voilà, il suffisait de demander.
=>[]
[^] # Re: Intérêt
Posté par Atem18 (site web personnel) . Évalué à 1.
En gros, ce que font déjà les BSD.
[^] # Re: Intérêt
Posté par David Demelier (site web personnel) . Évalué à 10.
Les BSD contrairement à Haiku ne fournissent pas leur propre nagivateur, ni leur propre lecteur de musique, ni leur propre interface graphique, etc.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Intérêt
Posté par eingousef . Évalué à 3.
OpenBSD en a un en développement.
*splash!*
[^] # Re: Intérêt
Posté par gaston . Évalué à 1.
Alors ca, j'aimerais bien avoir plus de détails.
[^] # Re: Intérêt
Posté par eingousef . Évalué à 2.
https://en.wikipedia.org/wiki/Xombrero
*splash!*
[^] # Re: Intérêt
Posté par Pierre Pronchery (site web personnel) . Évalué à 1.
Voir aussi le desktop DeforaOS:
http://www.defora.org/
Disponible dans les ports FreeBSD et NetBSD (et plus via pkgsrc). Supporte deux modes de compilation (normal et embarqué/finger-friendly). Et puis ça fonctionne aussi sur Linux (via hackable:1 pour Debian) et MacOS X (via pkgsrc aussi).
Serviteur.
khorben
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 2.
Il y a aussi plusieurs distributions de BSD…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
Mais rien n'empêcherait plusieurs distributions de HaikuOS, je me trompe?
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 1.
Certes, mais il n’y en a pas pour le moment.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Francois Revol (site web personnel) . Évalué à 2.
C'est juste découragé mais pas interdit par les guidelines (mais ça doit juste plus s'appeler Haiku).
Ca reste du libre.
[^] # Re: Intérêt
Posté par freem . Évalué à 2.
Et?
[^] # Re: Intérêt
Posté par lolop (site web personnel) . Évalué à 9.
Les nostalgiques de BeOS appréciaient sa légèreté et sa réaction immédiate à toute action de l'utilisateur. Je le faisait tourner sur un PowerMac 7300 (voir les specs) et c'était le jour et la nuit par rapport à MacOS à l'époque. Même avec une machine bien chargée (multiples vidéos, calculs d'images fractales…), tu ne te retrouvais jamais devant une interface utilisateur bloquée.
Il y avait aussi le système de fichiers utilisable comme une base de données sur laquelle tu pouvais faire des requêtes sur des attributs - par exemple utiliser ton "explorateur de fichiers" pour faire des recherches dans les emails (fichiers).
Et la possibilité d'encapsuler / déplacer / manipuler les affichages de certaines applications (je ne sais plus comment ils appelaient cette techno).
Les captures d'écran ne rendront jamais la sensation de fluidité de cet OS.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 3.
L'encapsulage d'affichage d'application c'étaient les "replicants"
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par lolop (site web personnel) . Évalué à 4.
Ah, merci, je me disais bien que blade runner et la porte des étoiles n'étaient pas loin.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 7.
Je prend ça pour un très beau compliment :)
Le look de BeOS est daté mais garde le charme de ce qui est profondément élégant, comme NeXT l'est (et par ricochet WindowMaker).
A vrai dire, BeOS c'était génial il y a 15 ans. La légèreté n'est plus un critère et la webification galopante rend la notion d'OS de plus en plus transparente.
BeOS c'était :
- un OS sexy avec son beau fond bleu et ses barres de titres jaunes qui ne prennent pas toute la largeur de la fenêtre
- un OS fulgurapide et toujours "responsive" (merci l'optimisation et le multithreading)
- un OS ou les applis étaient packagées dans de bêtes archives ZIP
- un OS avec un filesystem prodigieux qui permettait de faire plein de trucs chouettes avec les meta-données
Les interfaces graphiques d'aujourd'hui sont tout aussi jolies, nos machines ultra-puissantes s'accomodent de systèmes lourds, les applis proviennent de magasins et leur installation est automatisée, les filesystems du moment permettent eux aussi plein de frivolités geek.
Je suis un fan hardcore de BeOS, je pleurerai toujours sa mort, mais je suis mille fois plus excité aujourd'hui par l'approche innovante de GNOME 3 (et son gnome-shell), par la perfection du concept d'internet appliance (le dernier dada de Be Inc avant sa mort) dans les iPad, et par la modernisation continue de NeXT à travers Mac OS X.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par reno . Évalué à 8.
J'aimerais bien que ça soit vrai..
Mais en fait ça dépend beaucoup du PC: avec un SSD et plein de RAM tout est fluide,
avec un portable avec de la RAM rachitique (4Go c'est peu a l'heure actuelle) et un disque dur lent, les appli rament à fond..
Et malheureusement je pense que c'est vrai quelque soit l'OS: des appli comme Chrome|Firefox super-gourmandes qui te bouffent plusieurs Go de RAM, est-ce ça change quelque chose que l'OS soit léger et bien multi-threadé?
J'aurais tendance à dire que non (et pourtant j'étais un fan de BeOS qui était beaucoup beaucoup plus fluide que Linux ou Windows a l'époque).. Quelqu'un a l'expérience de Haiku pour confirmer/infirmer?
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 xcomcmdr . Évalué à 4. Dernière modification le 06 novembre 2013 à 11:02.
418 Mio, Firefox 25, Archlinux 64 bits, 5 onglets, session de 3 heures.
Ça fait longtemps que FX s'est bien amélioré dans sa gestion de la mémoire. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 4.
Reviens dans quelques jours et ce sera marrant…
[^] # Re: Intérêt
Posté par xcomcmdr . Évalué à 3.
Désolé mais non.
1) Je dors la nuit
2) Rester 48h sur Firefox, bonjour l'utilisation anormale qui vaut rien. :]
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Intérêt
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C'est bien ce qu'il dit Reviens dans quelques jours, et non pas Restes quelques jours. :)
Ça permet l'hibernation ou la veille (ce qui te permet à toi de ne pas veiller). ;)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intérêt
Posté par CrEv (site web personnel) . Évalué à 4.
haha
Comme dit dans le commentaire en dessous, je ne parle pas de rester devant ton firefox pendant plusieurs jours, juste de ne pas le fermer pendant plusieurs jours. Typiquement un ordinateur portable (ou pas d'ailleurs) qui passe son temps entre éveil et mise en veille. Et l'ordi n'est alors plus arrêté pendant plusieurs jours / semaines. Dans cette optique je n'ai pas envie d'avoir à fermer / ouvrir mon navigateur. Et j'ai totalement abandonné firefox pour ça. Très rapidement, et même en fermant tous les onglets, il arrive à mettre à plat une machine basique, prend plus de 1Go de RAM (sans onglets c'est quand même moche) et ralenti tout. Et ça a empiré depuis quelques versions (je saurais pas dire laquelle exactement ça devient tellement le bordel)
[^] # Re: Intérêt
Posté par xcomcmdr . Évalué à 3.
Je dirais que le problème vient de chez toi (une extension ?), je n'ai jamais eu ce problème. Et j'ai des machines avec 1 Go de RAM voire moitié moins.
Mais bon même si je le laisse ouvert pendant plusieurs jours, s'il se met à utiliser de plus en plus de mémoire alors que rien ne se passe c'est qu'il a un grave problème.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Intérêt
Posté par Kioob (site web personnel) . Évalué à 2.
J'aimerais bien pouvoir me contenter d'1Go de RAM ! Quand je vois qu'évolution bouffe 400Mo après moins d'une heure d'activité (et atteint assez souvent le Go de RAM à lui seul) :
~$ ps aux| grep evolution
plug-ol+ 9890 0.0 0.0 10364 920 pts/0 S+ 13:58 0:00 grep evolution
plug-ol+ 30327 0.0 0.3 1039544 12136 ? SLl 13:06 0:00 /usr/lib/evolution/evolution-source-registry
plug-ol+ 30451 0.0 0.6 751684 26712 ? Sl 13:06 0:00 /usr/lib/evolution/3.8/evolution-alarm-notify
plug-ol+ 30542 0.0 0.5 1099592 21028 ? Sl 13:06 0:00 /usr/lib/evolution/evolution-calendar-factory
plug-ol+ 30581 0.0 0.4 1084456 19548 ? Sl 13:06 0:00 /usr/lib/evolution/evolution-addressbook-factory
plug-ol+ 32192 2.6 9.8 4115948 395492 ? Sl 13:18 1:05 evolution
Par contre mon iceweasel dépasse rarement les 400/500Mo, avec des dizaines d'onglets et ce même après plusieurs jours/semaines.
alf.life
[^] # Re: Intérêt
Posté par barret benoit . Évalué à 1.
evolution a "toujours" été un "gouffre" hélas. Donc pas forcément une référence.
Évolutions : moins de bugs cependant.
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 2.
Eeeettttt on a plot dit le met y heure j'eux de maux de l'âne et deux mie le treize!
Note perso: c'est peut-être une bonne manière de retenir des mots de passe…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
Sur un netbook, 1Go de ram me conviens bien. Par contre il n'est pas complètement libre, il utilise opera, et pour lire les doc locales j'avais uzbl (avais, parce que ce truc est d'une lenteur exécrable. Mais il avait le mérite de pas bouffer trop de ram quand je compilais avec GCC à côté. Depuis que j'utilise clang je suis moins regardant cependant.)
[^] # Re: Intérêt
Posté par barmic . Évalué à 3.
uzbl est une bouse niveau performance. Si tu l'aime bien tu peut te tourner vers luakit ou surf qui eux sont véloces.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par freem . Évalué à 2.
En effet, ce truc n'est rien d'autre qu'une bonne idée qui à fini en immondice. En même temps, à vouloir passer par du python pour tout sauf le rendu, ça n'a rien de surprenant.
Je pense que je jetterai un plus gros oeil à surf qu'a luakit par contre. Je préfère restreindre au maximum les logiciels non compilés sur mon système, pour diverses raisons n'ayant rien à voir avec ce sujet :) (allez, au moins une: j'ai nettement plus confiance dans les compilateurs pour détecter les erreurs que dans les programmeurs attentifs doublés d'un interpréteur de commande)
[^] # Re: Intérêt
Posté par barmic . Évalué à 2.
Le problème ça n'est absolument pas python, mais le fait de lancer un nouveau programme pour tout est n'importe quoi, faire un
fork()/exec()à tout bout de champ ça ruine la réactivité.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
Zut, j'ai mis les balises <troll inside> autour de la partie de phrase liée a python… sauf que j'ai pas pensé que linuxfr tenterai d'interpréter et donc ai oublié d'échapper le '<' …
bref: <boulet inside>freem</boulet inside>
[^] # Re: Intérêt
Posté par freem . Évalué à 1.
Hum… en fait non, surf semble être la pire merde des 3…
Méthode de mesure: time avec fermeture du browser lorsque je vois le contenu s'afficher (sans vérifier qu'il s'affiche proprement, je précise, mais vu les exemples…). C'est expérimental parce que basé sur mes réflexes, certes, mais j'ai pas mieux sous la main.
$ time surf www.perdu.com
(surf:5074): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
(surf:5074): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m11.426s
user 0m0.200s
sys 0m0.084s
$ time uzbl www.perdu.com
(uzbl-core:5819): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m12.462s
user 0m0.684s
sys 0m0.148s
$ time luakit www.perdu.com
(luakit:6613): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m11.846s
user 0m0.532s
sys 0m0.104s
Et tant qu'a faire, j'ai fait le même type de mesure avec un fichier local:
$ time uzbl /usr/share/doc/libsdl1.2-dev/docs.html
real 0m1.640s
user 0m0.604s
sys 0m0.128s
$ time luakit /usr/share/doc/libsdl1.2-dev/docs.html
real 0m0.968s
user 0m0.528s
sys 0m0.072s
$ time surf /usr/share/doc/libsdl1.2-dev/docs.html
(surf:6717): libsoup-WARNING **: No feature manager for feature of type 'SoupCookie'
(surf:6717): libsoup-CRITICAL **: soup_message_set_first_party: assertion
first_party != NULL' failedfirst_party != NULL' failed(surf:6717): libsoup-CRITICAL **: soup_message_set_first_party: assertion
(surf:6717): libsoup-CRITICAL **: soup_message_queue_destroy: assertion `queue->head == NULL' failed
real 0m22.505s
user 0m0.232s
sys 0m0.092s
A noter ici que surf n'a même pas réussi a afficher la page:
Unable to load page
Problem occurred while loading the URL http://usr/share/doc/libsdl1.2-dev/docs.html
Cannot resolve hostname (usr)
Dommage, mais surf est en fin de compte le pire des 3, luakit menant haut la main: 59% du temps d'exécution d'uzbl, la différence est énorme.
[^] # Re: Intérêt
Posté par barmic . Évalué à 1.
Je ne comprends pas grand chose à ton test. Des stats que tu montre il est le plus rapide des 3 pour aller voir ce qui se passe sur perdu.com. mais sur tout ton test est presque plus proche d'un benchmark de webkit qu'autre chose, s'ils utilisent tous la même version de webkit alors tu n'a fait que vérifier le quel fait le plus de chose avant son lancement.
Tu parle de ce que tu a l'habitude de faire, mais je doute que tu surf en lançant un navigateur pour acchicher une url pour le fermer derrière (je ne dis pas que ça n'arrive pas juste que ça ne correspond pas à ce que l'on appel du surf (pas de suivi de lien, d'historique, de gestion des favoris, de téléchargement, etc).
Pour les liens local c'est un problème connu, il y a un patch pour ça (c'est des navigateurs de barbus faut se plonger dans le code/la configuration), sinon ça marche quand tu lui donne une url (
file://).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par freem . Évalué à 0.
Oui, quand je n'avais fait que ce test, je pensais aussi que c'était lui le mieux.
Non, puisqu'ils dépendent tous de la même version de webkit. Et puis, midori est bien plus rapide que n'importe lequel d'entre eux.
Je crois que la différence réside dans le fait que le téléchargement des données soit plus long. En fait, j'avoue ne pas savoir le pourquoi du comment: je n'ai pas profilé les binaires, mais en même temps, je ne meurs pas d'envie de comprendre pourquoi l'un est plus lent que l'autre. Ce qui m'intéresse, c'est que l'un est le plus rapide. Point barre.
Si j'ai déjà besoin de plus de 10 secondes pour afficher un truc aussi con que perdu.com (au passage désolé pour le formatage, j'ai toujours du mal a penser que linuxfr interprète ce qui est renvoyé par ma console. Je corrigerai bien, mais malheureusement c'est trop tard :/ ), il y a un sacré souci.
C'est effectivement proche d'un benchmark, à ceci près que je ne suis pas un robot et ait un temps de latence ;) mais pas de webkit: des couches logicielles qui l'exploitent, plutôt.
En effet, ce petit test simple ne représente pas l'entièreté de mon usage internet. Cependant, si des outils ne sont même pas capables d'afficher perdu.com en moins de 5s, ils sont difficilement considérables comme exploitables sur le net. Il reste donc l'affichage de documentation locale, que je fais effectivement généralement en saisissant l'url complète sur la ligne de commande.
Après un nouvel essai avec le préfixe, j'ai:
C'est donc 2 fois plus rapide que luakit, mais bon… devoir taper file:// à chaque fois, c'est gênant.
Pour le suivi des liens, en local, je ne vois aucune différence. A l'usage pour une recherche google, avec des installations par défaut dans une Debian, qui fournit en général des configurations par défaut utilisables, on se tape largement plus de 15s après le clic que le bouton de recherche. J'aurai volontiers accusé JS, mais seul luakit semble l'activer par défaut. Et il est nettement plus rapide a chercher un truc.
Tu m'étonnes que c'est des trucs de barbu: le temps qu'ils affichent la moindre page, tu as une barbe de 3 jours qui a le temps pousser.
Ah, un nouveau détail fun: avec surf, encore et toujours, aller sur www.duckduckgo.com affiche le code de la page. Pas la page, non, juste le code. Youpi. Sur ce site, uzbl n'affiche que la moitié des choses, et encore une fois luakit gagne haut la main en affichant correctement les choses. Il prend son temps, mais il marche.
Je ne parlerai pas du fait que surf ne respecte pas la gestion des fenêtres: il affiche la barre d'URL sur toute la largeur de l'écran, et non de sa fenêtre personnelle. Très mauvais point ça. Idem pour ses raccourcis (mais ça, ça dois être configurable) en CTRL+truc. Genre CTRL+g pour ouvrir une URL, c'est quand même tout sauf intuitif. uzbl et luakit ici sont plus malins, un simple "o" suffit. "o" comme ouvrir/open, ce qui est utilisé partout depuis que je connais l'informatique ( même sous dos, on avait alt+f pour le menu fichier, puis o pour ouvrir… ). J'imagine que le "g" sers pour go, mais bon…
Je veux bien être barbu, mais il y a des limites, sinon j'utiliserai directement wget et un script perl fait main en guise de navigateur.
Surf est, définitivement, le pire (quel âge à le patch? Si c'est plus d'un mois, il me semble difficilement admissible qu'il ne sois pas encore mergé…). Et je n'ai plus l'intention de me faire chier à trouver des excuses aux mauvais logiciels, catégorie à laquelle ils appartiennent tous les 3. J'ai perdu assez de temps. Être libre et ne faire qu'une seule chose mais bien, ne vaut rien si c'est trop long.
Non, si je veux prêcher pour un navigateur utilisable et léger, je reste pour le moment sur midori ou opera. Dillo, à la rigueur, bien qu'il ne supporte que le html pur et dur (pas d'images, ni de script, ni de style donc, on dirait. Mais au moins c'est rapide. Je crois que je vais l'adopter d'ailleurs, pour les doc techniques…).
[^] # Re: Intérêt
Posté par barmic . Évalué à 2.
Je ne sais pas ce que tu as testé, mais ce n'est pas surf. surf n'a pas d'interface, il utilise dmenu, mais tu peux choisir d'utiliser ce que tu veux.
Ton test je ne le comprends pas parce qu'il n'y a que firefox dans ces pires moment qui met plus 5s à démarrer et à afficher perdu.com.
Tu l'a installé comment ? Tu as récupéré les sources où ? Tu as appliqué quel patch ? Tu dis que c'est embêtant de devoir tapper l'url local complète, tu peut très bien le configurer pour ne pas avoir à le faire.
Je crois surtout que tu as utiliser un logiciel sans chercher à comprendre de quoi il s'agit. Surf est un logiciel de la communauté suckless, comme une bonne partie de leur logiciel, il se configure via les sources, tu applique un patch ou tu modifie à la main les sources, tu recompile et t'a ton navigateur. J'ai bien dis que c'est un navigateur de barbu.
Je présume que tu as installé une version binaire de ta distribution je ne sais pas ce qu'ils ont appliqué et quel version de surf ils utilisent, mais ce n'est pas prévu pour être utilisé comme ça, si tu veux configurer surf c'est par les sources (ça tombien puisque tu apprécie ce qui est compilé en navtif).
Parler de la vitesse de téléchargement sui serait discriment pour télécharger perdu.com (une seule requête de 204o sans compter les entêtes http), c'est juste rigolo.
Je viens de voir que tu as essayé le package de Debian. Je viens d'essayer la version stable et elle n'est pas comparable à ce que tu présente en terme de vitesse.
Que surf ne te convienne pas ça je l'ai bien compris (mais ne t'inquiète pas les développeurs s'en foutent), mais essaie de comprendre les logiciels dont tu parle avant de leur cracher dessus (j'immaginais que tu te renseignais un peu avant d'installer tout et n'importe quoi sur ta machine).
luakit ou jumanji sont très bien peut être qu'il te conviendront mieux (épargne nous les bench farfelus qui comptabilisent la vitesse de tes cliques par contre).
J'ai jamais compris comment c'est possible. linuxfr t'oblige à prévisualiser, tu ne te relis pas ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par freem . Évalué à -1.
En effet, je n'étais pas sur que c'était dmenu ou pas.
Je ne connais pas la raison des résultats, je ne connais que les résultats. Debian stable à 95%, amd64.
#aptitude install surf
(enfin, non, en fait j'utilise l'interface ncurses d'aptitude, mais ça reviens strictement au même). 0 changement de configuration.
Ca me paraît aussi très étrange, vu que je connais la taille de cette page, moi aussi. Mais par téléchargement, j'entendais également les étapes du genre résolution de nom DNS et tout le reste. Qui sont une partie du téléchargement, tel que je l'entendais. Ce n'était peut-être pas super explicite, je te l'accorde. Mais encore une fois, comme je l'ai dis, je n'ai pas passé valgrind dessus, je ne sais pas quelle étape rends tout cela si long.
La seule chose que je constate, c'est la lenteur impressionnante de cette opération (l'affichage est immédiat, donc ce n'est pas le moteur de rendu) avec chaque navigateur minimaliste basé sur webkit que j'ai testé (dillo n'as pas ce souci, mais n'est pas basé sur webkit). Cela n'inclue pas juste les 3-4 en question.
Ca ne peut être la faute de webkit, puisque chromium lui possède la vitesse habituelle. Que cela te froisse, je m'en fiche autant que le fait que les développeurs de ces outils se fichent que ceux-ci ne me conviennent pas.
Bah… je ne prends pas 2H par logiciel que j'aie envie de tester, je l'admets bien volontiers. Sinon, il me faudrait 2 ans avant d'avoir un système exploitable…
En général, je lis les descriptions (ainsi que les debtags & dépendances, c'est souvent instructif) que me fournit mon gestionnaire de paquet (je n'utilise pas LFS justement parce que je n'ai pas envie de faire tout le boulot moi-même), et si il y a un souci que je constate sur un outil que j'estime utilisable et le meilleur de ceux que je teste (généralement j'en teste plusieurs en même temps, pour me faire une première opinion avant de me plonger dans les configurations et autres doc), je vais jeter un oeil sur la page officielle du site.
Celle dédiée a surf est très clean, mais aussi très exempte d'informations. Y compris au sujet du patch que tu cites (ou alors il n'a pas un nom évocateur, je ne sais pas).
Donc, oui je me renseigne un peu avant. Mais non, je n'y passe pas 2H et je ne le ferais pas, sauf si c'est vraiment nécessaire. Dans le cas des navigateurs web, c'est loin, très loin, de l'être.
Toi seul appelle cela un bench. Pour ma part, je n'aurais jamais l'outrecuidance de qualifier de benchmark des tests aussi peu poussés et soumis à l'erreur humaine. Sans parler du fait que la quantité de situations testée est ridiculement réduite. Mais permets malgré tout de s'apercevoir qu'il y a un souci.
En plus, je n'ai effectué aucun clic dans cette opération.
Je relis. Avant de pré-visualiser. Quand j'ai un doute sur ce que j'ai utilisé, c'est à dire quand j'utilise des choses comme le format pour le code source, je pré-visualise réellement. Si je ne fais que taper et copier/coller du texte, non.
Il semble d'ailleurs qu'une de mes erreurs soit liée au # qui transforme toute la ligne en titre, alors que l'aide mémoire indique qu'un titre doit être encadré par ce caractère. Comme j'ai l'habitude d'indiquer si j'exécute une commande en tant que root ou user, je mets les $ et # correspondant habituellement à cette distinction.
[^] # Re: Intérêt
Posté par barmic . Évalué à 1.
Excuse-moi, il fallait lire :
.
Probablement parce qu'il a était intégré upstream en mars dernier.
Pour le reste, même pour uzbl ce ne sont pas des résultats normeaux soit tu te penche sur le problème soit tu utilise d'autres navigateurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Intérêt
Posté par Jean-Baptiste Faure . Évalué à 3.
Ce sera probablement pareil. Mon Firefox avec une douzaine d'onglets ouverts sur Ubuntu 13.10 64 bits n'atteint jamais le Go de RAM. Même après une semaine sans redémarrer le portable.
[^] # Re: Intérêt
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Il faudra que vous m'expliquiez… Au boulot j'ai une Debian 32bit, avec un Firefox dessus (en fait j'utilise parfois Iceweasel, mais souvent la Nightly, donc Firefox), je n'ai que 3 Go de ram, et je peux avoir 8 fenêtres de 40 onglets chacun.
Chez moi j'ai deux machines sous Ubuntu 13.10 (c'était déjà vrai avant), en 64 bit, j'atteint le Go avec quelques onglets (je ne parle même pas du cas extrême possible dans l'autre situation). Surtout, il y a une espèce d'allocation de la mémoire en fonction de celle disponible : si j'ai 3Go de mémoire, Firefox va vite prendre 2.5 Go parce que c'est ce qui reste à peu près quand le reste tourne. Si j'ai plus de 8 Go de mémoire, il va en prendre 8, parce qu'il peut. En fait dans ce cas précis il pourrait prendre plus mais c'est moi qui l'arrête là, j'explique après.
Donc, j'ai ces différences pour la même utilisation, dans les trois cas, les mêmes sites, chez moi, au boulot, quelque soit les machines. Au début je pensais que Firefox était particulièrement gourmand en 64 bit (la même chose prendrait de 700Mo à 1Go voire 2 Go au pire sur ma machine 32 bit), mais vos messages me contredisent.
Là, le Firefox duquel j'écris, il tourne depuis 24h, il me bouffe déjà 5 Gio. J'ai Gmail, Facebook (les plus gourmands j'imagine), DLFP et des articles de presse ou des forums à l'ancienne (du genre de ceux qui étaient déjà lisible quand Firefox s'appelait Firebird).
À un moment il prendra 8 Go, il faudra que je le tue. En fait j'ai 32 Go de ram, mais Firefox de toute manière ne sait pas brasser plus de 8 Go (et c'est pas ce que je lui demande, j'ai pas acheté la ram pour Firefox). Donc même si je ne swap jamais, quand Firefox dépassera les 8 go et qu'il restera plus de 20 Go de libre, il sera tout lent.
Par exemple quand je commence à compter les secondes entre l'affichage de chaque caractère quand j'écris dans un
textarea, c'est un signal qui me dit « t'as dépassé les 8 Go coco ».Heureusement Firefox est un très bon crash-only-software. Le killall firefox & firefox est un très bon garbage collector.
Note : je n'utilise pas beaucoup d'extensions à part adblock, flashblock et quelques trucs utiles de ce style (voire memchaser, ironie). Et de tout manière j'ai les mêmes dans iceweasel et firefox 32 bit, sans souci. Et de toute manière j'ai testé sans extension.
Oui j'ai Flash, puisque j'utilise Flashblock (ou l'inverse, j'utilise Flashblock parce que j'ai Flash), mais donc j'ai une utilisation de Flash mesurée.
Alors j'ai une machine de course (8 cœurs à 4 GHz, 32 Go de ram à 1.6 GHz), je peux compiler des programmes aussi vite qu'on chargerai une machine virtuelle pour les exécuter, je peux assembler des trentaines d'images avec Hugin en très peu de temps sans entendre le ventilo se réveiller parce que le proco n'atteint pas les 45° (haha), je peux coder des grosses vidéos sans frémir, je peux même m'amuser à jouer à Unvanquished en Full HD avec un rendu OpenGL complètement logiciel (llvmpipe) avec le moteur Legacy et avec une résolution moindre avec le moteur OpenGL3 et tous les effets au max, et ce juste avec un proco générique.
SAUF QUE, là mon Firefox fait déjà 5.7Go, bientôt 6, et la rédaction de ce commentaire dans le textarea de DLFP commence à ne pu être vraiment réactive.
Et j'aurai la même utilisation avec un Core2duo à 1.6GHz et 3Go de ram : je ne prendrai pas 6 Go mais 2 Go, et je commencerai à sentir les ralentissements. Il y a un espèce de proportionnalité. Il faudrait pouvoir mentir à Firefox, lui faire croire qu'il ne peut pas allouer plus.
Ah et puis, pendant que Firefox titube comme une loutre bourrée, le reste tourne très bien.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intérêt
Posté par lasher . Évalué à 4.
Tu as essayé de lancer FF dans une VM Windows? C'est qu'à moitié une blague en fait. On avait déjà eu des surprises, du genre FF-Win-dans-VM (ou p'tet Wine ?) qui va plus vite que FF-natif-Linux (y'avaient de « bonnes » raisons, telles que la profile-guided optim activée dans la version MSVC++, mais quand même). Et apparemment ils avaient mieux optimisés FF-Linux. J'aimerais bien savoir sur FF-Win-dans-Linux a le même comportement RAMophage.
[^] # Re: Intérêt
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C'est une bonne idée, il faudra aussi que j'essaie avec un Firefox 32 bit pour voir si ça joue aussi (ma première supposition).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Intérêt
Posté par freem . Évalué à 3.
Ce n'était pas plutôt thunderbird, qui s'appelait firebird, et dont le nom à été changé parce qu'un SGBDR l'utilisais déjà?
jolie expression, j'aime
[^] # Re: Intérêt
Posté par Moonz . Évalué à 4.
Non, c’est bien firefox qui s’appelait firebird. Et phoenix avant ça.
[^] # Re: Intérêt
Posté par freem . Évalué à 2.
Ah oui. Merci de l'info alors.
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 4.
Enfin 5 onglet c'est le grand minimum pour moi. ;)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Ces chiffres ne veulent rien dire. La quantité de RAM occupé par un navigateur dépend des sites qui sont affichées. Une simple page html avec trois paragraphes va demander beaucoup moins de mémoire qu'une appli comme google mail ou twitter, qui chargent des tonnes de JS et génèrent des milliers d’éléments HTML.
Et quand vous avez un navigateur avec plusieurs onglets ouverts, qui ne fait rien, et qui semblent prendre de plus en plus de mémoire, interrogez-vous si ce n'est pas un des sites ouverts qui "travaillent". Ex google mail: des mails arrivent, donc forcément, la liste des mails affichées s'allongent. et donc prend de plus en plus de mémoire.
[^] # Re: Intérêt
Posté par dinomasque . Évalué à 3.
Un bouzin obèse et codé avec le cul comme Android a bien fini par être fluide sur un smartphone ;)
Avec 4Go de RAM sur des ordis de 2008, je ne vois plus grand chose de lent que ce soit sous Mac OS X, Unity, GNOME 3 ou Windows 7. C'est pas aussi fluide et instantané que iOS, mais c'est déjà très bon.
BeOS le faisait il y a 20 ans !
[^] # Re: Intérêt
Posté par Astaoth . Évalué à 4.
Faut pas exagérer, sur mon "portable avec de la RAM rachitique", j'arrive à surfer correctement, et à aller sur Youtube, tout en ayant d'autres logiciels lancés à côté, avec un Opera qui a plus de 70 onglets ouverts et chargés (NB : Opera charge un onglet dès qu'il est ouvert et non quand l'utilisateur clique dessus, contrairement à Firefox).
Emacs le fait depuis 30 ans.
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 0.
Tous les gouts sont dans la nature, m’enfin après on s’étonne que les projets libres ne soient pas très populaires auprès du grand public! Bon je rigole, je sais que ce n’est pas la cible, c’était juste pour dire que pour moi l’apparence est importante: je ne suis pas complètement rigide, mais si je ne me sens pas à l’aise dans mon environnement, c’est un critère qui penche pas mal dans la balance (même si c’est pas logique, on est d’accord).
C’est pour ça que j’évite autant que possible: les interface graphiques Java… avec l’apparence Java, GNOME Shell (même si évidemment le fait que je trouve ça plutôt moche n’est qu’un des tas des choses que je n’aime pas dans GNOME Shell), les trucs genre LXDE (même si on peut mettre un thème c’est pas OpenBox peut avoir une apparence sympathique), etc.
Bon c’est moins pire qu’avant où je cherchais à tout prix à avoir un environnement totalement Qt ou totalement GTK (surtout côté Qt car GTK sous KDE c’est très chiant des fois). Mais l’apparence c’est très important, au moins lors du premier contact. C’est d’ailleurs ce qui m’a détourné de nombreuses distributions type «grand public» (c’est à dire avec installateur plus ou moins sympathique et tous les logiciels utiles aux tâches de base inclus). Notamment openSUSE et Fedora (Xfce de base, c’est assez moche je trouve).
Même maintenant j’accorde de l’importance à l’apparence, même si je préfère utiliser les thèmes présent de base: Oxygen (Plasma, icônes et thème Qt avec le thème de couleur Oxygen Cold — je trouve ça trop gris de base) pour KDE (j’arrive pas à trouver mieux qui s’intègre bien dans KDE) et Clearlooks (même si ça m’est arrivé d’utiliser autre chose, je trouve toujours des défauts au final) avec les icônes Elementary pour Xfce.
Et pire, je n’aime pas certaines distributions à cause d’un thème d’icône en particulier: Faenza. C’est magnifique, je ne dis pas le contraire. Mais toutes les icônes sont carrés, et c’est vraiment difficile de trouver le fichier que je cherche, ou le bouton de barre d’outils quand tout est uniforme (surtout les petites icônes d’ailleurs). Alors qu’un thème avec des icônes de taille et de forme variées est parfait pour exploiter la mémoire visuelle.
Bref, tout ça pour dire que quand la première image que je vois, c’est un truc tout gris qu’on dirait tout droit d’une époque que je n’ai pas connu, bah forcément ça me donne pas super envie. D’autant plus que souvent, une apparence soigné cache un bon logiciel. Bon l’interface «Modern» de Windows 8 je trouve ça tout moche, bah c’est tout pourri. Ubuntu, même si Unity ne fais pas l’unanimité, on ne peut pas nier qu’il y ai de bonnes idées.
D’ailleurs vous croyez que je m’attaque à Haiku, mais vous avez tord. Je m’adresse, par ce commentaire ouvert, à tous les libristes. Pourquoi MacOS a autant de succès? Parce que c’est quand même vachement classe.
Toujours à se plaindre les jeunes, hein? :p
Je vois pas trop l’intérêt.
Ahlala, tout ce que j’aime pas, tu m’étonnes qu’on ai pas les même gouts. Et c’est «GNOME Shell», GNOME tout en majuscule comme le nom du projet, Shell avec une majuscule au début, les deux mots séparés par une espace. C’est pas compliqué non? :p
Ah, je tenais à rajouter que le placement du menu de Haiku me semble vraiment bizarre. Pourquoi est-il placé là? Il serait beaucoup plus accessible à gauche non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par fravashyo (site web personnel) . Évalué à 3.
bof, je trouve ça plus sobre, c'est pas si mal
lequel ? ios6 ou ios7 ? je trouve le look pseudo réel (skeuomorphisme) d'osx assez moyen. Dans ios6 je trouve ça à vomir, sur le bureau os x ça passe encore. Idem que pour windows 8, ios7 ça ne me choque pas, même si les couleurs acidulées j'aime moyen.
bref les goûts et les couleurs.
Et j'adore par dessus tout le look de nextstep (windowmaker) et d'Haiku. Haiku est un modèle de simplicité d'utilisation et de sobriété.
dans ce cas là, pourquoi ne le déplaces-tu pas sur la gauche, ou en bas, ou en haut, ça redevient une barre plus classique ? Il faut cliquer et déplacer sur la zone entre les 2 barres, près de l'heure.
Par contre dans unity ça me gave un peu qu'on ne puisse pas déplacer la barre ailleurs (à droite par exemple)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Intérêt
Posté par ariasuni . Évalué à 1.
On parle bien de ce qui s'est prénommé «interface Metro»? Le truc fait pour le tactile? Parce que c'est juste le contraire de la sobriété.
MacOS c'est pas iOS, on est d'accord? En tout cas j'aime pas du tout iOS 7 je déteste les couleurs «acidulées» comme tu dis, et tout est de la même, genre la barre d'état/notification qui se confond avec l'interface de l'appli, le bouton «retour» dans les applis à peine visible, etc.
J'ai pas essayé Haiku à vrai dire. Si on peut la bouger c'est bien, juste que j'aimerais savoir pourquoi cette disposition par défaut.
C'est bien pour ça que je l'utilise pas. ^
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Intérêt
Posté par Letho . Évalué à 6.
Le skeuomorphisme s'attache moins à l'apparence qu'au concept. A ce titre, on ne saurait le réduire au fait d'avoir une apparence réaliste, ce qui est d'ailleurs complètement accessoire. Il s'agirait plutôt d'une transposition des concepts du monde réel.
Ton environnement de bureau est quasiment-certainement basé sur une approche skeuomorphique : un "bureau", des "fichiers", lesquelles se rangent dans des "dossiers", une "corbeille", le "couper/coller", le fait "d'appuyer" sur des "boutons", etc.
Rien à voir ici avec le look de l'application qui est plutôt une affaire de (mauvais) goût ;)
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . É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 lolop (site web personnel) . Évalué à 7.
Pour info, sous KDE (kwin) ça tourne aussi, en utilisant le clic du milieu sur la barre de titre et le glisser/déposer, on peut l'accrocher sur une autre fenêtre comme un onglet.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Intérêt
Posté par eingousef . Évalué à 7.
En même temps l'OS est en version alpha, donc les personnes lambda, hein…
*splash!*
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Intérêt
Posté par yann-kaelig . Évalué à -8. Dernière modification le 07 novembre 2013 à 14:52.
Alors qu'il suffit de sortir dans la rue pour conter Haïku.
Et c'est bien là où je veux en venir, libérer du code ne libère pas la créativité. Hors toute la force de l'environnement Amiga à été de libérer l'imagination, d'ouvrir les portes à la créativité pour tous alors que le code lui n'était pas libre.
Venant aussi du monde Amiga, lorsque j'ai découvert le libre après une période transitoire dans l'environnement µsoft, j'ai cru que le libre, gnu/linux plus exactement était le prolongement à la libération de la créativité, un mouvement qui aurait plus que libéré les outils à la création.
Je me suis trompé. Gnu/Linux est un monde ou l'on se donne du code, du pauvre binaire avec des blagues binaire. Où est l'Art dans cette informatique ? Il n'y en a pas.
Et c'est bien là, toute la différence, et c'est mon ressenti avec Haïku.
A suivre car il pourrait dans un futur proche remplacer mon système gnu/linux et OSEF de la licence.
[^] # Re: Intérêt
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Quel rapport entre la licence et la créativité ?
Le mec ne doit probablement pas savoir comment est fait, par exemple, le noyau linux et à quels challenges techniques il a été confronté mais il donne son avis sur les "logiciels libres".
Un avis bien gras, bien non argumenté et qui lui permet de se faire des idées bien arrêtées basées sur rien.
Quel raisonnement bas de plafond…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6. Dernière modification le 07 novembre 2013 à 16:23.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Intérêt
Posté par yann-kaelig . Évalué à -5.
Oui, pas beau.
Oui, cependant je parlais bien de l'utilisateur final et uniquement de son point de vue en faisant une comparaison à cette période fleurissante de la micro informatique et plus particulièrement en prenant appui sur la communauté Amiga.
Mais je 'nai pas connu que cette machine, entre autre aussi Apple2+/2e, Sinclair Zx spectrum, Commodore 64, Amstrad CPC64, Macintosh, Thomson Mo5/To7, Amiga500, Atari520St, MacII
Mon point de vue n'engage que mes acquis dans le milieu musical completé par la MAO et je comprends que le libre n'a pas de lien direct, ou quelque chose comme ça avec la créativité de l'utilisateur final.
J'ai cherché une correspondance entre ces deux périodes pensant trouver ces mouvements affranchis du code fermé. Rien de méchant dans mes propos, je respecte tout travail, je donne mon ressenti de mon point de vue.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 07 novembre 2013 à 19:18.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Intérêt
Posté par yann-kaelig . Évalué à -4. Dernière modification le 07 novembre 2013 à 19:36.
Tu vas pas le croire mais c'est bien la nostalgie qui m'envahit. Et le contacte humain là dedans ?
Les échanges de disquettes ;) tout les dimanches, entassés dans cet hangar, milles et un tubes cathodique dans ta tronche, toutes ces machines au service de l'imaginaire, la dernière demo qui tue sortie d'un freeware à deux balles, mais qu'est ce qu'on s'amusait koa !
Entrée libre :)
J'avais pas saisi la subtilité. GG
[^] # Re: Intérêt
Posté par lolop (site web personnel) . Évalué à 4.
Essaie de rentrer dans un fablab, dans un club de robotique, dans un lug… partout où il y a encore des contacts directs "H2H".
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Intérêt
Posté par freem . Évalué à 0.
Ben, justement, l'art… y'en a, et ça foisonne. Il suffit de voir la quantité de thèmes graphiques. Après, certains considèrent qu'une application artistique, si tu risque de la perdre a chaque fois que tu mets la disquette dans le lecteur (référence à un autre de tes messages) ça ne vaut pas le coup, et qu'il vaut mieux avoir un truc un poil plus fiable, genre un cdrom.
Si tu veux toujours de l'art, regarde dans les jeux. Même si ça a du mal dans le libre, il en existe tout de même plusieurs qui intègrent des graphismes, histoires et musiques intéressants (je pense surtout à wesnoth ici, et toutes les campagnes officielles)
[^] # Re: Intérêt
Posté par barmic . Évalué à 4.
Ton commentaire est sacrément violent… Je suis sincère c'est pas du troll. Qu'entends-tu pars libération de la créativité (je ne connais rien à l'Amiga) ?
Personnellement, j'ai une imagination inexistante, ma créativité est à peu prêt au même niveau, aurais-je un jour autre chose que ton mépris ? Car c'est clairement ce que je ressens quand je lis ton commentaire.
Mais tu fais bien ce que tu veux, on s'en fout (sincèrement), tu peux passer à QNX ou ReactOS, ça ne nous changera rien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par Adeimantos . Évalué à 3. Dernière modification le 08 novembre 2013 à 13:14.
Moi aussi, je fais partie de ceux qui passaient leurs nuits à compiler des noyaux pour prendre en charge la carte son et l'imprimante; j'ai même utilisé OS2 avant qu'il ne devienne OS2/Warp, puis eCOM Station et j'ai essayé BeOS lorsque Jean-Louis Gassée en fut l'initiateur.
Je me demande si, au lieu de faire traîner les choses pendant 10 ans, le temps de coder pour l'ajout de tel ou tel module, il ne serait pas plus judicieux de faire appel à une levée de fonds collaborative, pour aider à salarier des codeurs, en publiant une roadmap et en indiquant les coûts tranche par tranche.
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par Larry Cow . Évalué à 5.
C'est ce qu'ils font assez régulièrement, si je ne m'abuse. C'est même en gros sur leur page d'accueil.
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par Adeimantos . Évalué à 1.
Il suffisait de se rendre sur le site, en effet ! Mais personne ne m'a paru avoir soulevé ce point dans les commentaires. Ou bien, faut-il que je me procure de nouvelles lunettes ? Le but de l'équipe de Haiku-OS est de lever 35000 US$…
Question : l'équipe ne verrait-elle pas trop grand en visant un tel montant ? Avec pareille somme peut-on salarier 1 codeur pendant 1 an, 2 codeurs pendant 6 mois, etc. ?
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par lasher . Évalué à 2.
35000 USD / an (bruts) c'est même pas le prix d'un codeur junior dans la plupart des états US… Disons que pour 6-8 mois de travail, oui, ça te paie un programmeur à plein temps.
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par Adeimantos . Évalué à 1.
je me réponds à moi-même à propos de l'emploi des sommes collectées; je cite la page d'accueil : "Because of their efforts and generosity (il s'agit des donateurs), we are able to finance another month of contractual development for both Adrien and Pawel!"
[^] # Re: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par pulkomandy (site web personnel, Mastodon) . É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: A fundraising for HAIKU - Une levée de fonds pour HaIku ?
Posté par Adeimantos . Évalué à 1.
Oui, ça ne fait pas des masses de salaire, ni non plus beaucoup de fonds levés et par voie de conséquence, peu de codeurs rétribués. C'est dommage … Il faudrait passer à une levée de fonds de grande ampleur (du genre de celle initiée par Canonical l'été dernier !).
# Haiku sur AMD64 ?
Posté par Adeimantos . Évalué à 1.
J'ai tenté d'installer Haiku sur une partition de 4 Go sur une machine AMD64 double cœur : j'ai un "kernel panic" au démarrage et je rentre automatiquement dans une console qui me propose une palanquée de commande sous "kdebug". En cherchant un peu, je vois qu'on peu compiler la distro pour x86_x64, mais je n'ose pas me risquer là-dedans ;-(
[^] # Re: Haiku sur AMD64 ?
Posté par Adeimantos . Évalué à 1.
Il existe des "nightly build" de Haiku pour x64 qui ne sont pas supportées.
[^] # Re: Haiku sur AMD64 ?
Posté par pulkomandy (site web personnel, Mastodon) . É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.
[^] # Faites un don par Paypal pour Haiku !
Posté par Adeimantos . Évalué à 2.
Les objectifs de levée de fonds pour financer la campagne 2013 de codage de Haiku s'avèrent insuffisants.
Pulkomandy(Adrien Destugues) vient d'achever ses 2 mois de travail sur WebPositive, alors que les besoins excèdent largement quelques centaines d'heures par mois. En prenant un abonnement mensuel, via Paypal, à la levée de fonds de Haiku, quelques dizaines d'euros par mois (20, 30, 40, 50, etc.) permettrait d'insuffler un peu plus d'énergie à ce projet. Pour donner de l'argent, c'est ici.[^] # Re: Haiku sur AMD64 ?
Posté par Adeimantos . Évalué à 1.
Je me réponds à moi-même, mais ça peut servir à d'autres : le lancement de Haiku sur le disque dur est possible à partir du CD d'installation. Je l'ai testé sur AMD64.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.