Aujourd'hui, Haïku peut démarrer et est relativement stable pour une version de développement. Les principaux travaux chantiers actuels sont la couche réseau et la pile USB.
Le projet Haïku utilise la licence MIT qui est semblable à la BSD.
BeOS était un système d'exploitation propriétaire développé par Be. Ce système était connu pour sa réactivité, sa légèreté et son API objet en C++ très simple à utiliser. Suite au rachat de Be par Palm, le développement de BeOS fut stoppé, mais rapidement, des groupes se sont formés visant à recréer BeOS. Certains avaient des approches jugées comme pragmatiques, en se basant sur un noyau solide, plutôt que de repartir de zéro. C'est ainsi que des projets ont vu le jour avec pour objectif de porter l'API et l'apparence de BeOS sur des noyau BSD ou Linux. Mais ces projets sont aujourd'hui à l'abandon, le seul qui reste est Haïku, qui est de loin le plus ambitieux.
Son objectif est de fournir une version R1 presque identique à la dernière version distribuée par Be, en redéveloppant tout de zéro. Le "presque à l'identique" signifie que bien que la compatibilité binaire soit assurée (un exécutable BeOS tourne sans problème sous Haïku), il y a tout de même quelques différences :
- la couche réseau est celle que Be était en train de développer, fournissant des services identiques à ceux proposés par Linux ou les BSD
- une pile USB prenant en charge les dernières version de la norme
- une API claire pour ajouter de nouveaux CODEC
Pour tester sans devoir l'installer, vous pouvez utiliser QEMU avec les images fournies par l'équipe d'Haïku.
Aller plus loin
- Site officiel (9 clics)
- Haïku sur Wikipédia (5 clics)
- Copie d'écran sur Commons (2 clics)
- BeOS sur Wikipédia avec un historique (1 clic)
- Image d'Haïku fonctionnant avec QEMU (3 clics)
# question
Posté par ploum (site web personnel, Mastodon) . Évalué à 6.
En avance il y a 10 ans. Si Haïku réussit à sortir une version parfaitement identique au dernier BeOS, comment cela va-t-il supporter la comparaison avec les Linux/Windows/MacOSX de maintenant ?
aussi, n'ayant jamais utilisé beos, j'ai souvent entendu qu'il était révolutionnaire mais je n'ai jamais trouvé "pourquoi". Quels sont les avantages de BeOS et qu'ai-je à gagner à utiliser Haïku plutôt que Linux ?
Ce sont des questions sincères, je ne cherche pas à critiquer le travail de l'équipe. Ils font ce qu'ils veulent et une réponse de type : "Non, t'as rien à y gagner, ils font ça pour le plaisir et parce qu'ils aimaient bien BeOS" est entièrement satisfaisante.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: question
Posté par Jean-Marc Leroy . Évalué à 4.
Ça, plus le fait que BeOS était orienté multimédia, devait donner de meilleures performances pour les carrioles utilisées à l'époque.
Un Live CD serait chouette à obtenir, mais pas moyen de faire fonctionner leur moteur de recherche interne pour avoir ne serait-ce qu'une démo stable, et pas une nightly build...
[^] # Re: question
Posté par Mildred (site web personnel) . Évalué à 1.
Ah, ça, je l'attend depuis pas mal de temps ... avec mon système GNU/Linux. Cela pourra-t-il venir un jour, quelqu'un sait ? Parce que parfois la libmagic se trompe ...
Je crois que Mac OS le fait mais il me semble aussi que parfois, il y a des problèmes et on a toutes les peines du monde a mettre le bon mime type.
Il m'est arrivé de modifier un fichier maple sur Mac OS X avec la ligne de commande mais Mac OS n'a plus jamais voulu le réouvrir. Le fichier était utilisé par maple sur l'environnement classic et le fichier était stoké sur un dossier samba, ca joue peut être.
[^] # Re: question
Posté par sanao . Évalué à 5.
* support des types MIME (les types MIME sont définis par un démon qui tourne et analyse les fichiers)
* support illimité des méta-donnée, on peut en ajouter autant qu'on le désir. Un exemple d'application, StyleEdit, le petit éditeur de texte de BeOS utilise les méta-donné pour stocker la mise en page d'un fichier texte (couleur, alignement, taille de la police) et si on lit le fichier texte sur un autre système, le fichier reste lisible, mais sans la mise en page
* live query, des requêtes de recherches dynamiques, cela permet ainsi de lister tous les fichiers qui nous intéresse suivant un certains critères et ce résultat est mis à jour dynamiquement (couplé au méta-donnés cela peut donner des trucs très intéressant.
Il est à noter que le OpenBFS de Haïku est un des composants qui a actuellement atteint le stade de la bêta.
[^] # Re: question
Posté par Jean-Marc Leroy . Évalué à 1.
Haiku risque de rester un OS intimiste, à la AmigaOS, et c'est dommage pour la diversité.
[^] # Re: question
Posté par lolop (site web personnel) . Évalué à 10.
Son design a été prévu dès le début pour supporter le multithreading de façon très intensive, en prévoyant que (rapidement) on utiliserais des machines multiprocesseurs.
Ce qui en fait (en faisait) un système très réactif - tu n'étais *jamais* bloqué dans l'interface à cause d'une opération en cours (un clic pour dérouler un menu lançait un nouveau thread chargé d'afficher et contrôler ce menu, chaque application avait un thread correspondant dans le système graphique...). Même sur des machines moyennes, tu pouvais sans problème jouer plusieurs films/musiques en même temps, tu sentais que les ressources de la machine étaient exploitées au maximum (j'ai souvent du mal à sentir ça sous Windows ou Linux).
Côté file-system, le BeFS et l'utilisation importante des attributs associés aux fichiers - et ce dès le début, intégré à l'OS - était vraiment génial pour faire des recherches, ou pour simplement visualiser des fichiers et leurs caractéristiques associées sans avoir à ouvrir une appli tiers.
Côté graphique, il y avait aussi le système des répliquants (des composants graphiques pouvant avoir une indépendance par rapport à leur fenêtre d'origine).
Et bien sûr, l'API objet de BeOS, vraiment sympa.
Vraiment dommage que ça n'ait pas pû être open-sourcé lorsque Be Inc. a fermé.
Malheureusement, actuellement, aucun AMA (enfin, si, avec un QEmu, tu peux l'installer et voir par toi-même ce qu'il en est).
On retombe dans le problème de l'avancée du projet, dans le problème de support de matériels très divers (déjà qu'avec Linux c'est pas toujours gagné), des applis disponibles (il y avait une bonne communauté autour de BeOS, et des applications commençaient à arriver).
C'est dommage, j'ai récemment balancé tout le matériel de cette époque (CDs, livres) que j'avais sur BeOS...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: question
Posté par Mildred (site web personnel) . Évalué à 1.
Et comment cela se passait pour résoudre les problèmes qu'on peut voir lorsqu'on fait du multithread ? corruption de données en cas d'accès concurrent quoi.
C'est juste que je trouve les mutex pas très pratiques a utiliser, mais peut être que cela devient très facile avec plus d'expériance. Alors je me demande si ils avaient une meilleure solution...
[^] # Re: question
Posté par lolop (site web personnel) . Évalué à 9.
Il n'y avait rien de plus que des choses connues: mutex, sémaphores ; et en plus haut niveau: mémoire partagée, files de messages, ports de communication.
Tout ça se retrouve maintenant dans les APIs de n'importe quel OS digne de ce nom. Mais... BeOS c'était à l'époque [*] où MacOS ne connaissait pas la mémoire protégée ni le multithreading préemptif, Windows était une surcouche de DOS, Linux était un Unix en développement avec une couche XFree pas toujours légère sur de petites config.
BeOS c'était une façon intelligente et légère d'utiliser ces différents mécanismes (entre/dans les applications, avec les différents serveurs).
Voir le BeBook... http://www.beunited.org/bebook/index.html
Et plus spécifiquement:
http://www.beunited.org/bebook/The%20Kernel%20Kit/index.html
[*] Sauf erreur, la machine qui était vendue par Be Inc., c'était à l'origine un Bi-PPC603e à 166MHz... moi je tournais sur un PowerMac 7300 à 180MHz avec 80Mo de RAM, et c'était plus réactif qu'un PIV à moult gigagertz et plus de 1Go de RAM de maintenant.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: question
Posté par golum . Évalué à 0.
[^] # Re: question
Posté par lolop (site web personnel) . Évalué à 3.
Je n'ai dû voir OS/2 tourner qu'une seule fois, et s'il avait bonne réputation sur sa fin (entre autre une très bonne stabilité vs le Win95 de l'époque), ce n'était pas le cas des premières versions livrées.
http://fr.wikipedia.org/wiki/OS/2
Ils devaient quand même se taper toute une couche de compatibilité pour les applis DOS puis les applis Windows 3.x... pas sûr que ça ait été génial pour améliorer le côté technique.
Où on voit encore que se battre dans la cour de Microsoft, c'est dur, très dur. Et plus encore pour du source fermé réalisé initialement en collaboration avec Microsoft (ce qui semble une des raisons du non-open-sourcing d'OS/2 d'après la page de Wikipedia).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Sur la BeBox
Posté par lolop (site web personnel) . Évalué à 2.
Et en plus, elle avait un vrai look: http://www.bebox.nu/images.php?s=images/ppcbebox
Ah, c'était 133MHz, pas 166. Et c'était en 1995... il y a 11 ans.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Sur la BeBox
Posté par Miod in the middle . Évalué à 1.
Malheureusement, qu'elles soient à 2x66 ou 2x133, le gros défaut des BeBox PPC, c'est l'absence de cache L2, qui pénalise énormémement les applications quelles qu'elles soient. C'est ainsi qu'un modèle 2x66 est tout juste capable de lire un fichier mp3 à 44 KHz sans sauts, le bus mémoire étant sollicité en permanence...
[^] # Re: Sur la BeBox
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Sur la BeBox
Posté par ZeroHeure (site web personnel) . Évalué à 1.
Dis moi, n'es-tu pas la personne qui m'a racheté ma BeBox pour porter NetBSD dessus ? La livraison de la machine avait été problématique, à ma grande honte.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: question
Posté par Thomas Douillard . Évalué à 0.
[^] # Re: question
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Pour rappel, Be au départ voulait faire comme Apple, vendre du matos et l'os qui va avec; ce qui n'etait pas étonnant vu que le patron de Be était Jean Louis Gassée, un ancien d'Apple (pdg d'apple france, puis n° 2 d'apple monde).
Bref, donc la Bebox. Je me rappelle qu'à l'époque, c'était la première machine bi-proc relativement accessible au publique. Et en plus elle n'était pas moche du tout, avec ses deux chenillards sur le devant qui indiquait l'occupation de chacun des deux procs (google est votre ami pour les photos). Avec des ports entrées-sorties sons d'origine, port PCI etc (tout ceci n'était pas forcément en standard dans les PC, pour le son sur les PC, fallait acheter des cartes additionnelles etc...)
Pour les développeurs, les geeks, c'était donc une superbe machine à l'époque, avec un superbe OS temps réèl etc.. Voilà en partie pourquoi BeOS fut devenu un OS "culte".
Malheureusement, les ventes n'ont pas été à la hauteur (surtout à cause de la compatibilité de l'os avec rien). Ils ont donc arrété la vente de la machine au bout de 2 ans (1997 je crois), et continué juste à développer l'OS.
[^] # Re: question
Posté par Ontologia (site web personnel) . Évalué à 6.
Au milieu de cette page : http://www.espace-cubase.org/page.php?page=bepouraudio , tu trouveras pas mal d'infos.
La gestion du shedduling, du switch entre taches et threads, l'accès à tout ce qui est flux de données (DD, vidéo, son) le rendait particulièrement adapté au multimédia (ce pour quoi il a été conçu). Il avait une conception assez orienté objet, on devrait plutôt dire composant. Un peu comme think
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: question
Posté par sanao . Évalué à 2.
Sinon le fait que l'API est à 99% objet et qu'il a une architecture client/serveur doit y jouer au niveau de son aspect en forme de composant.
[^] # Re: question
Posté par sanao . Évalué à 4.
* les translators : des modules fournissant des fonctions permettant de lire et écrire des fichiers, cela permet ainsi de les réutiliser dans n'importe quelle application
* l'utilisation intensive des méta-donnés. Avec comme exemple concret StyleEdit (l'éditeur de texte de BeOS) qui utilise les méta-données pour stocker la mise en page des fichiers textes (couleur, alignement, police). Si un autre programme lit un fichier de StyleEdit, il le pourra, mais n'aura que le texte sans la mise en page
* les live query, des requêtes de recherches de fichiers dynamiques, qui associées avec les méta-données permettent de faire des choses assez intéressante
* les réplicants, qui sont des sortes de KParts. Ainsi, NetPositive (le navigateur Web de BeOS) peut être facilement embarqué dans n'importe quelle application
[^] # Re: question
Posté par sanao . Évalué à 1.
[^] # Re: question
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
[^] # Re: question
Posté par Francois Revol (site web personnel) . Évalué à 6.
C'est assez utile en effet pour ajouter le support de nouveaux formats...
Et quelques trucs plus amusant, comme Gocr http://www.bebits.com/app/4098 qui converti une image en texte. Toute appli peut donc utiliser Gocr. De même j'ai converti une application de scannage (Sanity) en translator, qui permet à toute appli sachant ouvrir une image de scanner directement :)
[^] # Re: question
Posté par reno . Évalué à 1.
Très bien à mon avis: la réactivité des GUI sous BeOS était bien supérieur a un Linux/Windows/MacOSX de maintenant (et accessoirement sur la vitesse de boot aussi), ce qui est *très* agréable.
Maintenant il restera toujours le probleme du manque d'appli..
# petite erreur
Posté par Nicolas P. . Évalué à 0.
# NewOS, Syllable
Posté par fredix . Évalué à 1.
A une époque un projet similaire avait fait un peu de bruit, Atheos ( http://www.atheos.cx/ ) . Quand est-il est Haiku+NewOS face à feu Atheos et son remplacant Syllable ( http://www.syllable.org/ ) ?
Quoi qu'il en soit je suis convaincu que le libre a tout à gagner a posséder un OS conçu pour le Desktop. Bonne continuation.
[^] # Re: NewOS, Syllable
Posté par B16F4RV4RD1N . Évalué à 2.
http://fr.wikipedia.org/wiki/MultideskOS http://en.wikipedia.org/wiki/AtheOS
En plus le gars est également développeur de jeux, il a participé au jeu "Longest Journey" :
http://www.mobygames.com/developer/sheet/view/developerId,14(...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: NewOS, Syllable
Posté par mickabouille . Évalué à 1.
Ben non c'étaient pas des destop, mais des écritures d'api, un peu comme gnustep quoi.
Après que ça puisse devenir un desktop, je ne le nie pas...
Enfin bon, de toutes façon, ils ne sont pas allés très loin.
[^] # Re: NewOS, Syllable
Posté par monseigneur . Évalué à 2.
L'intérêt des projets qui étaient basés sur le noyau Linux c'était de profiter de sa grande compatibilité hardware. et de sa robustesse réputée.
Mais, à mon avis, Linux a l'inconvénient d'évoluer trop vite. Sur un projet de la taille des BeOS-like, c'est trop consommateur de temps que d'essayer de suivre les multiples version du noyau... (déjà GCC lui-même...)
Syllable suit son cours. J'ai un peu perdu pied depuis quelques mois mais il a l'avantage sur Haiku d'être utilisable : les drivers sont nombreux, le réseau fonctionne bien, le système est stable (l'API aussi, ce qui est bon pour les devs), le système de fichiers est très bon (il ne manque que les live queries, prévues mais pas encore développées)
Le gros manque, comme partout, ce sont les applications "utilisateur" : pas de bureautique, pas de mozilla...
Le petit manque de Syllable, c'est l'optimisation du système : le multitâche n'est pas optimal en termes de rapidité mais il est stable, ce qui est déjà bien.
[^] # Re: NewOS, Syllable
Posté par fredix . Évalué à 2.
Je ne suis pas d'accord, car Linux n'est clairement pas orienté Desktop et c'est tant mieux. Par contre un noyau multithread qui intègrerait même une GUI serait un coup de boost énorme pour un OS Desktop, et cela se ressentirait sur le résultat final.
C'était l'avantage de BeOS.
Le gros manque, comme partout, ce sont les applications "utilisateur" : pas de bureautique, pas de mozilla...
Un portage de GTK+ et Qt serait envisageable ?
[^] # Re: NewOS, Syllable
Posté par sanao . Évalué à 3.
Et puis c'est un boulot monstre, dont le temps serait très certainement mieux rempli et le boulot plus gratifiant pour les développeurs, à concevoir des applications spécialement dédiées à l'OS.
[^] # Re: NewOS, Syllable
Posté par golum . Évalué à 1.
En quoi Linux n'est il pas orienté desktop ?
[^] # Re: NewOS, Syllable
Posté par fredix . Évalué à 2.
[^] # Re: NewOS, Syllable
Posté par dinomasque . Évalué à 1.
Alors à quoi servent les tas de serveurs (ApplicationServer, WindowServer, etc.) ?
BeOS le faisait il y a 20 ans !
[^] # Re: NewOS, Syllable
Posté par monseigneur . Évalué à 1.
Si tu parles bien de Syllable, oui c'est envisageable mais rien n'est fait pour l'instant, à part des "portages" partiels pour quelques applications... C'est même fortement déconseillé par les développeurs principaux : il faut des applis natives pour aider au développement du système.
Côté BeOS, GTK+ existe bien mais requiert l'installation d'un serveur X. Il n'y a pas de version native.
Au final, on perd un grand intérêt du système hôte si on n'y fait tourner que des applis "portées". Et le mélange avec des applis natives pose forçément des problèmes d'ergonomie, de compatibilité, d'intégration...
[^] # Re: NewOS, Syllable
Posté par fredix . Évalué à 3.
Certe mais en attendant un portage GTK+ et Qt permettrait d'utiliser le système au quotidien, sinon ca se mord un peu la queue. Enfin on blablate, même un portage ne doit pas être simple à faire, il n'y a qu'à voir celui de GTK+ sur MacOS...
[^] # Re: NewOS, Syllable
Posté par sanao . Évalué à 3.
Pour le portage de GTK, il me semble que c'est une vieille version, du style 1.2. Niveau portage, je ne sais pas si c'est vraiment utilisable. Même chose pour Qt, c'est une version 2.x.
[^] # Re: NewOS, Syllable
Posté par reno . Évalué à 2.
# pas si intégristes que ça \o/
Posté par Francois Revol (site web personnel) . Évalué à 10.
# Le Commentaire Obligatoire
Posté par inico (site web personnel) . Évalué à 3.
=> http://linuxfr.org/topics/Be.html
[^] # Re: Le Commentaire Obligatoire
Posté par sanao . Évalué à 2.
[^] # Re: Le Commentaire Obligatoire
Posté par Arthur Accroc . Évalué à 1.
C'est normal, il vient d'être supprimé pour "inactivité" (voir http://linuxfr.org/2006/08/21/21220.html ).
Pas de bol, l'article arrive trois jours trop tard pour sauver la rubrique...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Précisions
Posté par Francois Revol (site web personnel) . Évalué à 10.
- "rachat de Be par Palm" : pas tout à fait, Palm a racheté la propriété intellectuelle de Be, pas la société elle-même.
- "la couche réseau est celle que Be était en train de développer" : pas exactement, BONE est toujours fermé. Mais en effet la couche réseau de Haiku lui est similaire (modulaire et dans le noyau) contrairement à BeOS R5 qui utilisait "net_server" dans l'espace utilisateur, connu pour être buggué et lent, pas tellement parce que tournant en mode utilisateur mais surtout parce qu'écrit en une semaine.
- "une API claire pour ajouter de nouveaux CODEC" : En effet, l'interface pour les codecs n'a jamais été documenté par Be, malgré les promesses, un peu dommage pour le "Media OS".
- le noyau est un fork de NewOS, mais il a bien changé depuis.
- BeOS était en effet en avance sur son temps, et a encore de l'avance sur certains domaines. C'est incroyable le nombre de choses qui ont été copié... même si ça n'est pas toujours BeOS qui les a inauguré il les a mise à la porté du grand public. Le support SMP, la préemption dans le noyau, les attributs étendus (en moins bien), un devfs hiérarchique, des modules noyau hiérarchisés et chargés automatiquement (enfin presque), le tick-less kernel (si, ça existait bien avant cette année !) sont autant de choses que Linux n'a que depuis peu. Les WinFS, Beagle, Spotlight n'existaient pas il y a peu. Les frameworks multimédias explosent en ce moment (GStreamer...) pourtant il n'y a pas tant de nouveautés que ça.
En parlant des LiveCD, tout le monde prétent avoir inventé le concept, pourtant les CDs d'installation de BeOS sont tous Live, il suffit de relancer le bureau (Ctrl-Alt-Del, Relaunch desktop). La gestion des types mime est un vrai bonheur. Il n'y a pas de raison de laisser l'utilisateur chercher l'appli si le système sait le faire. Des choses très simples comme le 'X-ray nav', la navigation depuis le menu contextuel semblent si évites qu'on peste dès qu'on se retrouve ailleurs sans elles. BeOS utilisait beaucoup des plugins, les rendant publics pour d'autres applications (reuse), et pouvait inclure une application dans une autre bien avant les ActiveX et autres, même si cela n'a jamais été suffisamment exploité.
Sur le multi-threading, avoir un thread par fenetre c'est tellement mieux. Un peu plus compliqué certes. Il faut utiliser des mutex et autres bénaphores. Mais c'est transparent dans une certaine mesure, en utilisant les BMessages, conteneur bien plus flexibles que ce qu'utilise GTK pour les évènements. Par exemple pour supporter les roulettes des souris ou la pression des tablettes graphiques aucun besoin de rajouter un membre à la structure et la rendre incompatible, l'addon (ici encore) de l'input_server ajoute un membre "wheel_x" et y... de type float. C'est bien pratique d'avoir le typage des données sans devoir connaitre sa signification. On peut les manipuler quand même un minimum. C'est pareil pour les attributs étendus du fs. Ils ont un type, ce qui permet (sauf une minorité de structures binaires) de les afficher et modifier (par script ou utilisateur) sans connaitre l'application qui l'utilise.
Les interfaces de scripting étaient également présentes depuis le début, mais également sous-utilisées.
Je pense parfois que si Be avait bréveté tout ça on serait bien dans la merde, y compris Microsoft :D
Sur OS/2, c'est vrai qu'OS/2 avait un certain nombre d'intéret, y compris les attributs étendus sur HPFS. Visiblement ça et le poids d'IBM n'a pas suffit à l'imposer non plus.
Oulala mais j'ai de quoi faire un livre, j'ai surement oublié des choses.
Pour revenir à Haiku, il reste beaucoup de bugs, y compris des sérieux dans la VM, mais ça fait du bien de le voir booter :)
[^] # Re: Précisions
Posté par monseigneur . Évalué à 2.
Tout à fait. Je l'ai installé il y a quelques semaines, via Qemu puis très vite sur une partition dédiée. Malheureusement, il manque encore la stack réseau dans les builds... Et je n'ai pas trouvé le moyen de monter d'autres partitions, du coup c'est pas facile de partager des données...
Bref, pas encore utilisable mais à suivre. De près.
Pour ceux qui veulent tester, c'est plus simple qu'il n'y parait :
http://www.haiku-os.org/wiki/index.php?title=Using_Haiku_Ima(...)
Un ex-utilisateur régulier de BeOS 5 PE
# problèmes des drivers
Posté par Mildred (site web personnel) . Évalué à 3.
Je me demande si ce serait possible d'avoir avant l'OS une couche qui prenne en charge tout les problèmes materiels, gestion des drivers, ... et qui permettrait de lancer l'OS de mon choix qui n'aura plus a se soucier des drivers.
Est-ce possible ?
[^] # Re: problèmes des drivers
Posté par Larry Cow . Évalué à 7.
C'était le boulot du BIOS, à la base. Il était prévu pour fournir des routines pour les tâches les plus courantes demandées au matériel (la fameuse interruption 13, si mes souvenirs sont bons). Le seul hic, c'est qu'avec le temps, les besoin ont évolué. Et, si on prend l'exemple des disques durs : le support de l'IDE fourni par le BIOS est rapidement devenu inutilisable : incapable de supporter les disques de grande capacité, etc. La conséquence est qu'aujourd'hui plus aucun OS "sérieux" (sauf erreur de ma part) ne passe par le BIOS pour ce genre d'opération.
Un autre exemple de fonctionnalités qui "sortent" du BIOS et deviennent compétence de l'OS : la gestion d'énergie qui est passée d'APM (boulot fait par le BIOS sous le contrôle de l'OS) à ACPI (boulot fait par l'OS lorsque le BIOS en éprouve le besoin).
Une alternative séduisante est EFI, qui permet apparement de pousser le principe des drivers du BIOS plus loin.
[^] # Re: problèmes des drivers
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Pas forcément la meilleure solution, mais déjà une avancée.
# Le futur du desktop?
Posté par Maclag . Évalué à 4.
Le projet est très jeune, alors je pose la question:
- qui aurait dit 5 ans après la naissance de Linux qu'il aurait le succès qu'il a aujourd'hui?
j'aimerais bien retrouver les commentaires de l'époque "utilisable, réservé aux experts", ou "projet qui comporte plein de trucs intéressants si vous voulez étudier ça ou ça", etc.
Alors, Haïku, futur Linux-killer sur desktop? (ouai, j'ai dit Linux-killer, parce que d'ici 10ans, windows aura disparu des desktops, hein! :D)
[^] # Re: Le futur du desktop?
Posté par Erwan . Évalué à 2.
Slackware et RedHat etait bien installees, Debian existait deja. Sur le bureau Afterstep venait apporter un peu de eye candy par rapport a fvwm et le developpement de Gimp demarrait.
5 ans apres sa naissance, je peux te garantir que Linux etait utilisable, avait une base d'utilisateurs solide, et 2-3 ans plus tard (KDE, Gnome) on commencait deja a pronostiquer la chute imminente de Windows ! (on a ete un peu trop optimistes la-dessus).
[^] # Re: Le futur du desktop?
Posté par Ph Husson (site web personnel) . Évalué à 7.
dans Haiku ils reprogramment un peu tout,
Linux y a que le noyau
XFree existait déjà
Tous les outils GNU aussi, (essayez Linux sans GNU pour rire...)
[^] # Re: Le futur du desktop?
Posté par Sylvain Sauvage . Évalué à 2.
Oh l'aut' eh ! ¹
¹ : ceci est une proposition de variante du « trop gros, passera pas »
[^] # Re: Le futur du desktop?
Posté par Erwan . Évalué à 2.
D'ailleurs, si ca peut te rassurer dans "mon fvwm est mieux que ton wm", Afterstep etait au depart un hack de fvwm.
[^] # Re: Le futur du desktop?
Posté par Sylvain Sauvage . Évalué à 2.
Mais en qui concerne 199x, AfterStep non plus n'avait pas de thèmes ni de transparence...
Et puis, beaucoup de wm sont dérivés de Fvwm, lui-même issu de twm (cf. http://fr.wikipedia.org/wiki/Fvwm où l'on trouve un joli arbre généalogique).
# API BeOS sur système GNU/Linux
Posté par Mildred (site web personnel) . Évalué à 2.
En fait ce que je rêve, c'est une telle API bien intégrée pour mon OS favori, et de préférence utilisée. Actuellement, chaque environnement de bureau fournit ses propres mécanismes, j'aimerais bien que ce soit normalisé (freedesktop ?).
[^] # Re: API BeOS sur système GNU/Linux
Posté par dinomasque . Évalué à 2.
http://en.wikipedia.org/wiki/Blue_Eyed_OS
http://www.blueeyedos.com/
BeOS le faisait il y a 20 ans !
[^] # Re: API BeOS sur système GNU/Linux
Posté par Nicolas P. . Évalué à 1.
Et Google ne donne pas le moindre indice d'un quelconque paquet à télécharger.
[^] # Re: API BeOS sur système GNU/Linux
Posté par sanao . Évalué à 2.
[^] # Re: API BeOS sur système GNU/Linux
Posté par Francois Revol (site web personnel) . Évalué à 3.
Il était prévu qu'il soit passé sous GPL, mais on attend toujours.
Par contre il existe différentes implémentation de l'API Be sous windows par ex. Gobe en a fait une pour porter Productive, et quelqu'un en a fait une pour tester les applis Haiku il y a qq années, mais je ne sais pas ou ça en est.
Dans le svn de Haiku il y a une petite couche de d'émulation pour faire tourner certaines applis nécessaire à la cross compilation (rc pour compiler les resources, ...) peut-être qu'en partant de là c'est possible.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.