Haiku ist auf jedenfall eine unterstützenswerte Sache! Die Entwickler haben gutes geleistet und sind extrem motiviert, ein richtig schlankes opensource BS, das gerade für multimediaplattformen sehr interessant werden kann und keine altlasten mit sich trägt. Ich spende 100. Ein witzbetrag ich weiss, aber mehr kann ich bis 29. nicht entbehren.
es ist ein freier nachbau von beos mit binary kompatibilität - zu gebrauchen (vom enduser) noch nicht wirklich, aber auf dem besten wege dahin... aber die entwickeln selber schon auf haiku - es läuft also schon auf (ausgewählter) hardware.
haiku hat keine rechtlichen probleme -es ist ein konsequenter nachbau und es ist auch kein problem existierende beos programme auf haiku einzusetzen... Zeta war eine übele geschäftemacherei ohne basis und community. rtl-shop war deren finanzierungsmodell, dh arme rentner zu verarschen mit unfertigen.
Existieren alle niocht mehr, wie mein Vorposter schon schrieb. Zuletzt war noch mal der Versuch unternommen worden, BlueEyedOS wieder aufleben zu lassen. Ist aber auch nichts draus geworden.
BeUnited (dessen Ziel es war, für die unterschiedlichen BeOS-Clone zusammenzufinden, damit die unterschiedlichen Entwicklungen nicht zu sehr auseinandergehen) hatte daher auch vor über einem Jahr seine Aktivitäten eingestellt: http://www.beunited.org/.
Bleibt somit nur noch Haiku übrig, das früger mal OpenBeOS hieß und aus rechtlichen Gründen später umbenannt wurde(soviel dazu, daß Du OpenBeOS seperat erwähnst).
ich habs zwar nie wirklich eingesetzt (hab auch noch nie von jemandem gehört, der das getan hat oder gar täte), aber mir hat BeOS damals schon sehr gut gefallen! leider haben sich viele der extrem innovativen ansätze nie weiterentwickelt. wenn damals die softwareauswahl nicht so enorm beschränkt gewesen wäre... es wäre die wesentlich bessere alternative zu windows 2000 gewesen!!
ich hoffe, dass die jungs was zu stande bringen und werd gleich mal ein sümmchen spenden...
Hier, hallo. Ich hatte damit mal ne Zeitlang entwickelt: 1999. BeOS5. War da auch auf meinem Rechner das Haupt OS. Interessant war es ja.
Problem ist halt das innovative Ansätze nur was bringen wenn sie Rückwärtskompatibel sind und das war BeOS nicht. Die hätten parallel zu BeOS ein BeToolkit für MacOSX/Windows/X11 rausbringen sollen was die portable Entwicklung ermöglicht. Dann wäre das was geworden. Hatte selbst an sowas gearbeitet und nach dem Todesstoss von Palm aufgegeben.
Erstens wüßte ich nicht was an seinem/ihrem Kommentar den Ton in dieser Antwort verdient hat und zweitens glaube ich die Antwort ohne weitere Information nicht. Welches Qt-Feature wäre denn in BeOS nicht umsetzbar gewesen?
um mal ähnlich zu antworten: das ist schwachsinn was du sagst... wahrscheinlich würdest du das gleiche von MacOS X behaupten, wenn Qt auf dieser plattform nicht gäbe. "ist doch in ObjC geschrieben, wie soll das denn gehen?"
Von zack-klatsch-baeem am So, 25. Mai 2008 um 11:55 #
ja, warum schon wieder ein OS ? Sieht mir wieder nach verschwendeter Manpower aus. Die sollen lieber Linux Patches bauen die Linux mehr-multimedia-faehig machen, falls es in der Hinsicht noch grosse Verbesserungen geben kann.
ein BeOS kompartibilitätswrapper, ähnlich wine wäre doch eine Möglichkeit, die BeOS Programme unter Linux nutzen zu können, man könnte auch BFS nach Linux portieren, afaik war BeOS doch auch ein unix? Was ist denn überhaupt das Alleinstellungsmerkmal von BeOS, was war damals so inovativ? (und wenn es damals inovativ war, ist es das heute immer noch?) - Ließen sich die Features nicht in Linux oder FreeBSD einbauen, andere Projekte sollten doch eher con guten Konzepten profitieren als das neu erfundene Rad, in dem die konzepte eingebaut werden
Falsch, in monolithischen Kerneln lassen sich beispielsweise nicht im Betrieb nachträglich Treiber nachladen oder so. Willst du einen Treiber in einem klassischen reinen monolithischen Kernel dazu haben, compilierst du ihn neu. Dann wird der immer geladen, und du kannst ihn auch nicht entladen.
Na ja immerhin viel viel sinnvoller als >4 BSD Derivate zu pflegen. BeOS ist wenigstens mal was neues und nein es war kein Unix, hatte aber eine Posix kompatibilitäts Library. Und es war konsistent und entmistet und auf Desktop getrimmt, keine Eierlegendewollmilchsau.
>Und es war konsistent und entmistet und auf Desktop getrimmt, keine Eierlegendewollmilchsau. Warscheinlich war dass das Problem - was kann/konnte BeOS besser als Windows, MacOS und Linux?
Die GUI war vollständig mit Threads gemacht. Jedes Menu, jedes Fenster, jedes Element auf dem Desktop hatte einen eigenen Thread. Was bedeutet, dass man nicht wie in KMail oder Outlook darauf warten muss, dass die Aufmerksamkeit auch mal wieder dem User gilt. Das sorgt für echte Interaktivität, ohne dass es Quad-Cores braucht, um unter 100ms ne Reaktion zu bekommen.
Das Filesystem hatte damals schon durchsuchbare Tags. Versuche wie ReiserFS und WinFS sind ja bisher eher als gescheitert anzusehen. Lösungen wie Sherlock oder Nepomuk sind eher im nativen Stadium. Mir schien BeOS da weiter gewesen zu sein.
Insbesondere die erstere Idee wäre Gold wert. Selbst die besten Toolkits erlauben das nicht auf einfache Art und Weise bisher, muss man alles selbst programmieren und passiert deshalb nie.
Aber hilft es wirklich, wenn man Teile des GUI noch benutzen kann, wenn das Hauptprogramm gerade nicht mehr reagiert? Klar, man könnte die IPC Aufrufe in eine Warteschlange schicken und sie vom Programm abarbeiten lassen, wenn es wieder reagiert. Das ganze klingt für mich aber nach recht viel Overhead. Die Datei Tags sind ja inzwischen auch Dateisystemunabhängig mit Tracker/Beagle verfügbar, dass Reiser4 wohl nichts mehr wird liegt nicht (nur) am Konzept sondern auch an Hans Reiser selbst, vor allem seiner Verurteilung. Und was inovative Dateisystemkonzepte angeht hat da zfs wohl die Nase vorn.
diese Warteschlange ist bei allen Toolkits selbstverständlich schon existent. Leider ist es aber eben so, dass die Menus, Fenster, etc. sich alle eine teilen müssen, und deshalb stets nur 1 Sache zur Zeit geht.
Threading hat immer Overhead, das eigentliche Problem ist, dass es sehr schwer ist, keine Fehler beim Zugriff auf gemeinsame Resourcen zu machen. Ich bin total gegen Threading normal, aber für eine GUI scheint es mir eher ein Muss, dass diese niemals blockiert, weil ein Menu etwa noch nicht aufgebaut wird. Das war unter BeOS wohl besser. Die konnten vor zig Jahren schon demonstrieren, dass sie mehrere Videos abspielen und mit dem User interagieren konnten.
Was den Overhead angeht, an der Stelle. Für mich ist es dann Overhead, wenn mein Prozessor zig Millionen Instruktionen pro Sekunde kann, aber für mich nur verzögert Zeit hat.
Ich denke, das wäre was für Qt5.
Und Dateisystem, das BeOS Dateisystem und ZFS haben praktisch keine Schnittmenge. Das Dateisystem als Datenbank war und ist eine geniale Idee gewesen, der wir uns nur langsam annähern. Und Beagle/Tracker sind Nachbesserungen, die nicht im Dateisystem integriert sind.
Unter BeOS hat jedes Programm selbst wohl gleich die Tags gesetzt, wofür es natürlich am kompetentesten ist. Beim Tracker wird versucht Datenmüll hinterher wieder zu verstehen und verfolgbar zu machen, was mehr oder weniger gut geht, und mit einem "mv" u.U. schon sein Ende findet.
Die Innovationen von ZFS sind besonders grosse Dateisysteme, robust gegen Korruption, gut für Clustering von vielen Disks, Servern und so weiter. Das BeOS Dateisystem war gut für den Desktop, ZFS taugt dafür garnicht (besonders), oder?
Von Anonymous Coward am So, 25. Mai 2008 um 15:58 #
Na ja immerhin viel viel sinnvoller als >4 BSD Derivate zu pflegen. Im Gegensatz zu Haiku werden diese 5 BSDs aber tatsächlich verwendet, es gibt Software dafür und auch durchaus Innovation. Man schaue sich nur FreeBSDs GEOM an, und auch bei DragonFlyBSD finden sehr spannende Sachen statt, ohne OpenBSD gäb's kein OpenSSL usw. Auch wenn manche Leute das zu glauben scheinen, so heißt Innovation nicht, gleich alles bestehende über den Haufen werfen zu müssen.
Das BSD-Zeug spielt doch nur im Netz/Embeddedbereich eine Rolle. Haiku zielt auf den Desktop ab, beide kann man überhaupt nicht miteinander vergleichen.
DragonFly wird garantiert niergendwo verwendet. NetBSD vielleicht irgendwo im Embedded noch. OpenBSD bei einigen Geeks die meinen sie wären so cool. Nur FreeBSD und MacOSX sind verwendete BSD's.
Und ohne OpenBSD gäbs halt ein anderes SSL Projekt das das geleistet hätte. Die Library ist halt zu wichtig als das sie nie geschrieben wäre. Wir haben OpenBSD also nichts wirkliches zu verdanken. Wie wenig das genutzt wird sieht man doch schon das z.B. der Boehm-Weisser GC nicht portiert wurde (ja ja als mini Single Thread läuft ab-und-zu version).
selten so ein blödsinn gehört. grad was open- und netbsd angeht, aber da du sowieso irgendwie auf heise-niveau argumentierst, braucht man net wirklich was zu sagen.
Ein bedeutender Unterschied ist beispielsweise, dass Haiku zum Großteil, wenn nicht sogar komplett, in C++ geschrieben wurde. Besonders der Kernel soll dadurch, laut den Entwicklern, deutlich sauberer und wartungsärmer sein.
Ich kann euch nur empfehlen, das Haiku-Image von der Webseite des Projektes herunterzuladen. Ihr könnt es mal in Qemu oder VMWare testen.Falls Ihr mehr sehen wollt, bzw. mehr Programme testen wollt, dann geht mal auf http://haikuware.com und ladet euch bitte die Inoffizielle Haiku-Image "senryu-personal-edition" herunter. Diese Imagedatei ist gleich mit einer Entwicklungsumgebung und andere interessante Sache gefüllt. Ptobiert es einfach mal aus.
ich kenne mich da ja nicht aus, aber Linus hat mal ein paar Worte darüber verloren, warum ein Kernel nicht in C++ geschrieben werden sollte und warum er mit C++ Entwicklern nichts zu tun haben will.
Früher oder später wird man auch unter haiku an den reichen Schatz an Open Source Anwendungen heran wollen. Da wird man sicher nicht jede Anwendung einzeln auf haiku portieren, sonder es gezwungenermaßen dann eben Linux/X kompatibler machen und damit ist der Vorteil der Optimierung für Multimediaanwendungen auch dahin, wenn er im Kompatibilitäts-Layer hängen bleibt.
Was verbirgt sich eigentlich hinter dieser ominösen "besseren Multimediaunterstützung"? Ist ja nicht so, dass ich mit Linux nicht auch musik und filme in x Formaten und größen wiedergeben könnte, selbst in Verbindung mit compiz alles kein Problem. Was Haiku da verbessern will (ohne an die selben Probleme mit restricted formats und (De)CCS/HDCP zu stoßen ist mir schleierhaft. Konzepte, die vor 10 Jahren noch neu und inovativ waren sind heute doch schon übernommen worden, wenn sie wirklich gut waren.
Auf beos hatte man schon 1998 konzepte, die langsam erst auf linux einzug halten, OSX teilweise verwirklicht hat und auf windows (würg)...
zum beispiel das audio volle priorität geniesst (eher stürzt die oberfläche ab als das der pcm stream aufhört) und das natürlich bei niederiger latenz, auf jeder soundkarte, dabei kann man die streams von applikation zu applikation schicken (routen). konzepte wie das modulare JACK für Linux haben das später aufgenommen.
Berühmt ist auch ein demo von 98, wo ich auf einem >P2 400mhz 256mb ram< 20 verschiedene videos ruckelfrei laufen liess. Ab vom sinn einer solchen aktion so zeigte es doch, das selbst auf schwacher hardware bei priorisierung von multimedia einiges mehr drin ist. Selbst bei heftigster belastung war ist beos noch flüssig zu bedienen und immer zugänglich - und speicherschutz in vollendung.
Ein grundsätzlicher Fehler ist schonmal die Verwendung der Sprache C für die Entwicklung.
Das bedeutet letztendlich, dass keine funktionale und keine objektorientierte Entwicklung (es sei denn über eine aufwändige und umständliche API) möglich ist.
Weiterhin hat das System dann auch dieselben potentiellen Schwachstellen, wie jedes C-Programm: - schlechte Lesbarkeit - umständliche Pointer Programmierung - Stacktraces werden nur mit Debugger geliefert - Bufferoverflows werden wieder möglich
Naja.
Es hat in der Vergangenheit mehrere Versuche gegeben, Programmiersprachen-Betriebssysteme zu entwickeln, wie zb Java-OS, ADA-OS und einige andere, aber am besten gefällt mir die Idee eines Lisp-OSses, da der Common Lisp Standard derart massiv fortgeschritten ist, dass eigentlich keine denkbare andere Programmiersprache diesen Fundus an Ausdrucksmöglichkeiten und Paradigmen bieten kann.
Es gibt da ein Projekt, welches ich gerne gefördert gesehen hätte, das ist:
http://common-lisp.net/project/movitz/
Dieses Projekt hätte mal einen Schub an Entwicklern nötig.
Immerhin kann man schon ein floppy-image per qemu starten:
BeOS konnte zwar Multimedia und Grafik auf der CPU, aber leider wurde am Markt vorbei entwickelt, denn der späte schon längst in Richtung 3d Grafikkarten deren Fähigkeiten mangels OpenGL auf BeOS damals nicht genutzt werden konnnten.
Ich habe Beos und danach, nach einer kleinen Pause, Zeta eingesetzt. Beos lief eigentlich nur auf der eigens dafür (Fehler???) konstruierten BeBox richtig gut. Ein OS, getrimmt auf Multimedia. Ein OS nur für eine Hardware zu coden, war wahrscheinlich die Crux an der Sache. Nachdem be.inc das Geld fehlte schnappte sich Palm die Rechte an dem Code. Leider hatte Palm aber nicht die Absicht es weiterzuführen, sondern schlafen zu legen, damit kein Anderer das OS auf Hardware portiert, so wie sie Palm einsetzt. Die genialen Programmierer von Be.inc verstreuten sich in alle Winde. Ein B.Korz schnappte sich Beos und machte Zeta draus. Palm war es egal, solange keiner damit Handhelds und ähnliches auszurüsten versuchte. Man ging immer davon aus, das die, von B. Korz gegründete yellowtab Firma die Rechte an dem Beos Code hätte. Diesen Nachweis ist er, glaube ich, heute noch schuldig. Man versuchte dann, Zeta auf handelsüblicher Hardware zum Laufen zu bekommen und das gelang auch recht gut. Die Eigenschaften des Microkernels machten sich im Speed bemerkbar. Du konntest eine fette Datei kopieren, ein Programm kompilieren lassen, eine DVD encoden und gleichzeitig 5 Filme gucken. RAM vorausgesetzt. Das Ziel war, mit Zeta so lange zu schwimmen wie irgends möglich, bis Haiku fertig ist, denn dann hätte man kein Problem mehr mit den Rechten gehabt. Innerhalb des Umfeldes von B.Korz und yellowtab gab es aber Schwierigkeiten, die Rede, dass der unbekannte 3. Mann den bereits portierten Code von Beos teilweise vernichtet oder mitgenommen hätte etc. Dass es keine Community gab ist falsch. Beos und auch zeta hatten eine sehr gute Fan-Gemeinschaft, die viel unternahm um Zeta und letztendlich Beos am Leben zu erhalten. Am Ende wurde zeta an einen Software-Distributor "verkauft". Dieser brachte nochmal eine aktualisierte Version heraus. Allerdings immer noch ohne Software-Kracher wie eine funktionierende Office Lösung, an OpenOffice soll gearbeitet worden sein, aber keiner weiß es so richtig. Einige Programmierer haben richtig gute Software herausgebracht, sie setzten aber leider auf das falsche Pferd. Nachdem dem Distributor die Sache zu heiß wurde, nahm er Zeta aus den Regalen. Insgesamt ist die Geschichte eine sehr traurige, denn durch die gemeinsame POSIX Verwandtschaft wäre eine beos/Zeta im Client Bereich und Linux im Server Bereich Konstellation mit richtigen Anwendungen der Kracher geworden und hätte VISTA/MS Server um Längen geschlagen. Aber wie so oft gewinnt hier nicht der Bessere.
Gruß Jemand der jetzt Linux im Client/Server Bereich einsetzt.
Ist Haiku das letze Überbleibsel von BeOS?
BeUnited (dessen Ziel es war, für die unterschiedlichen BeOS-Clone zusammenzufinden, damit die unterschiedlichen Entwicklungen nicht zu sehr auseinandergehen) hatte daher auch vor über einem Jahr seine Aktivitäten eingestellt: http://www.beunited.org/.
Bleibt somit nur noch Haiku übrig, das früger mal OpenBeOS hieß und aus rechtlichen Gründen später umbenannt wurde(soviel dazu, daß Du OpenBeOS seperat erwähnst).
wers nicht glaubt: www.openbeos.org
wenn damals die softwareauswahl nicht so enorm beschränkt gewesen wäre... es wäre die wesentlich bessere alternative zu windows 2000 gewesen!!
ich hoffe, dass die jungs was zu stande bringen und werd gleich mal ein sümmchen spenden...
War da auch auf meinem Rechner das Haupt OS. Interessant war es ja.
Problem ist halt das innovative Ansätze nur was bringen wenn sie Rückwärtskompatibel sind und das war BeOS nicht.
Die hätten parallel zu BeOS ein BeToolkit für MacOSX/Windows/X11 rausbringen sollen was die portable Entwicklung ermöglicht. Dann wäre das was geworden. Hatte selbst an sowas gearbeitet und nach dem Todesstoss von Palm aufgegeben.
womit arbeitete man bei Be eigentlich, C/C++?
Aber du kanst die BeOS API portieren.
Systemsprache war C++.
das ist schwachsinn was du sagst... wahrscheinlich würdest du das gleiche von MacOS X behaupten, wenn Qt auf dieser plattform nicht gäbe.
"ist doch in ObjC geschrieben, wie soll das denn gehen?"
Sieht mir wieder nach verschwendeter Manpower aus.
Die sollen lieber Linux Patches bauen die Linux mehr-multimedia-faehig machen, falls es in der Hinsicht noch grosse Verbesserungen geben kann.
aber bestimmt nächstes Jahr.
BeOS ist wenigstens mal was neues und nein es war kein Unix, hatte aber eine Posix kompatibilitäts Library.
Und es war konsistent und entmistet und auf Desktop getrimmt, keine Eierlegendewollmilchsau.
Warscheinlich war dass das Problem - was kann/konnte BeOS besser als Windows, MacOS und Linux?
besser war (angelesen):
Die GUI war vollständig mit Threads gemacht. Jedes Menu, jedes Fenster, jedes Element auf dem Desktop hatte einen eigenen Thread. Was bedeutet, dass man nicht wie in KMail oder Outlook darauf warten muss, dass die Aufmerksamkeit auch mal wieder dem User gilt. Das sorgt für echte Interaktivität, ohne dass es Quad-Cores braucht, um unter 100ms ne Reaktion zu bekommen.
Das Filesystem hatte damals schon durchsuchbare Tags. Versuche wie ReiserFS und WinFS sind ja bisher eher als gescheitert anzusehen. Lösungen wie Sherlock oder Nepomuk sind eher im nativen Stadium. Mir schien BeOS da weiter gewesen zu sein.
Insbesondere die erstere Idee wäre Gold wert. Selbst die besten Toolkits erlauben das nicht auf einfache Art und Weise bisher, muss man alles selbst programmieren und passiert deshalb nie.
Gruss,
Kay
Die Datei Tags sind ja inzwischen auch Dateisystemunabhängig mit Tracker/Beagle verfügbar, dass Reiser4 wohl nichts mehr wird liegt nicht (nur) am Konzept sondern auch an Hans Reiser selbst, vor allem seiner Verurteilung.
Und was inovative Dateisystemkonzepte angeht hat da zfs wohl die Nase vorn.
diese Warteschlange ist bei allen Toolkits selbstverständlich schon existent. Leider ist es aber eben so, dass die Menus, Fenster, etc. sich alle eine teilen müssen, und deshalb stets nur 1 Sache zur Zeit geht.
Threading hat immer Overhead, das eigentliche Problem ist, dass es sehr schwer ist, keine Fehler beim Zugriff auf gemeinsame Resourcen zu machen. Ich bin total gegen Threading normal, aber für eine GUI scheint es mir eher ein Muss, dass diese niemals blockiert, weil ein Menu etwa noch nicht aufgebaut wird. Das war unter BeOS wohl besser. Die konnten vor zig Jahren schon demonstrieren, dass sie mehrere Videos abspielen und mit dem User interagieren konnten.
Was den Overhead angeht, an der Stelle. Für mich ist es dann Overhead, wenn mein Prozessor zig Millionen Instruktionen pro Sekunde kann, aber für mich nur verzögert Zeit hat.
Ich denke, das wäre was für Qt5.
Und Dateisystem, das BeOS Dateisystem und ZFS haben praktisch keine Schnittmenge. Das Dateisystem als Datenbank war und ist eine geniale Idee gewesen, der wir uns nur langsam annähern. Und Beagle/Tracker sind Nachbesserungen, die nicht im Dateisystem integriert sind.
Unter BeOS hat jedes Programm selbst wohl gleich die Tags gesetzt, wofür es natürlich am kompetentesten ist. Beim Tracker wird versucht Datenmüll hinterher wieder zu verstehen und verfolgbar zu machen, was mehr oder weniger gut geht, und mit einem "mv" u.U. schon sein Ende findet.
Die Innovationen von ZFS sind besonders grosse Dateisysteme, robust gegen Korruption, gut für Clustering von vielen Disks, Servern und so weiter. Das BeOS Dateisystem war gut für den Desktop, ZFS taugt dafür garnicht (besonders), oder?
Gruss,
Kay
Im Gegensatz zu Haiku werden diese 5 BSDs aber tatsächlich verwendet, es gibt Software dafür und auch durchaus Innovation. Man schaue sich nur FreeBSDs GEOM an, und auch bei DragonFlyBSD finden sehr spannende Sachen statt, ohne OpenBSD gäb's kein OpenSSL usw. Auch wenn manche Leute das zu glauben scheinen, so heißt Innovation nicht, gleich alles bestehende über den Haufen werfen zu müssen.
Haiku zielt auf den Desktop ab, beide kann man überhaupt nicht miteinander vergleichen.
Und ohne OpenBSD gäbs halt ein anderes SSL Projekt das das geleistet hätte. Die Library ist halt zu wichtig als das sie nie geschrieben wäre. Wir haben OpenBSD also nichts wirkliches zu verdanken. Wie wenig das genutzt wird sieht man doch schon das z.B. der Boehm-Weisser GC nicht portiert wurde (ja ja als mini Single Thread läuft ab-und-zu version).
grad was open- und netbsd angeht, aber da du sowieso irgendwie auf heise-niveau argumentierst, braucht man net wirklich was zu sagen.
Student erstes Informatik-Semester? Wahrscheinlich nicht mal sonst hättest du den Spruch nicht gebracht.
Ich kann euch nur empfehlen, das Haiku-Image von der Webseite des Projektes herunterzuladen.
Ihr könnt es mal in Qemu oder VMWare testen.Falls Ihr mehr sehen wollt, bzw. mehr Programme testen wollt, dann geht mal auf
http://haikuware.com und ladet euch bitte die Inoffizielle Haiku-Image "senryu-personal-edition" herunter. Diese Imagedatei ist gleich mit einer Entwicklungsumgebung und andere interessante Sache gefüllt.
Ptobiert es einfach mal aus.
ich kenne mich da ja nicht aus, aber Linus hat mal ein paar Worte darüber verloren, warum ein Kernel nicht in C++ geschrieben werden sollte und warum er mit C++ Entwicklern nichts zu tun haben will.
Herrlich.
Gruss,
Kay
zum beispiel das audio volle priorität geniesst (eher stürzt die oberfläche ab als das der pcm stream aufhört) und das natürlich bei niederiger latenz, auf jeder soundkarte, dabei kann man die streams von applikation zu applikation schicken (routen). konzepte wie das modulare JACK für Linux haben das später aufgenommen.
Berühmt ist auch ein demo von 98, wo ich auf einem >P2 400mhz 256mb ram< 20 verschiedene videos ruckelfrei laufen liess. Ab vom sinn einer solchen aktion so zeigte es doch, das selbst auf schwacher hardware bei priorisierung von multimedia einiges mehr drin ist. Selbst bei heftigster belastung war ist beos noch flüssig zu bedienen und immer zugänglich - und speicherschutz in vollendung.
Das bedeutet letztendlich, dass keine funktionale und keine objektorientierte Entwicklung (es sei denn über eine aufwändige und umständliche API) möglich ist.
Weiterhin hat das System dann auch dieselben potentiellen Schwachstellen, wie jedes C-Programm:
- schlechte Lesbarkeit
- umständliche Pointer Programmierung
- Stacktraces werden nur mit Debugger geliefert
- Bufferoverflows werden wieder möglich
Naja.
Es hat in der Vergangenheit mehrere Versuche gegeben, Programmiersprachen-Betriebssysteme zu entwickeln, wie zb
Java-OS, ADA-OS und einige andere, aber am besten gefällt mir die Idee eines Lisp-OSses, da der Common Lisp Standard derart massiv fortgeschritten ist, dass eigentlich keine denkbare andere Programmiersprache diesen Fundus an Ausdrucksmöglichkeiten und Paradigmen bieten kann.
Es gibt da ein Projekt, welches ich gerne gefördert gesehen hätte, das ist:
http://common-lisp.net/project/movitz/
Dieses Projekt hätte mal einen Schub an Entwicklern nötig.
Immerhin kann man schon ein floppy-image per qemu starten:
http://common-lisp.net/project/movitz/files/
Gruß
http://aros.sourceforge.net/
BeOS konnte zwar Multimedia und Grafik auf der CPU,
aber leider wurde am Markt vorbei entwickelt, denn der späte schon längst in Richtung 3d Grafikkarten deren Fähigkeiten
mangels OpenGL auf BeOS damals nicht genutzt werden konnnten.
Gruß
Jemand der jetzt Linux im Client/Server Bereich einsetzt.