*BSD-Linux-„Mischformen“

kraileth

kraileth

Steht noch ganz am Anfang
Es gibt ja immer wieder mal Projekte, die versuchen, *BSD und Linux irgendwie zu „mischen“. Nicht zuletzt die Systemd-Debatte von Debian hat mal wieder deutlich gezeigt, wie die Linux-Gemeinde mit diesem Thema umgeht: Überwiegend mit Unverständnis und Gleichgültigkeit („Nutzt das denn überhaupt jemand ernsthaft?“ „Auf die paar Leute muß man wirklich keine Rücksicht nehmen!“ usw.). Mich würde nun mal interessieren, wie damit von BSD-Seite umgegangen wird!

Bei mir persönlich ist es so, daß mir Debian/kFreebsd immer mal wieder in Erinnerung gerufen hat, daß es *BSD auch noch gibt und ArchBSD hat mir schließlich den Anlaß gegeben, es endlich einmal wirklich auszuprobieren. Inzwischen habe ich normale FreeBSDs am laufen, das aber in erster Linie, weil ich mit diesem System halbwegs systematisch vertraut werden möchte. Insofern sehe ich diese Mischprojekte schon mal positiv in dem Sinne, als daß sie in der Linuxwelt immer mal wieder BSD-Neuigkeiten platzieren können.

Daher meine Fragen:

Was haltet ihr von den verschiedenen Projekten, (wo) seht ihr deren Sinn und was glaubt ihr können sie bewirken?

Hier mal eine knappe Beschreibung von vier Projekten (wahrscheinlich gibt es mehr, bitte gerne ergänzen, wer möchte!):

Debian/kFreebsd: Nach meiner Einschätzung sehr, sehr stark an Linux angepaßt. Natürlich kommt Debians Paketsystem zum Einsatz, aber für diese Plattform sind vergleichsweise wenige Pakete vorhanden. So weit ich weiß, bleibt praktisch von FreeBSD nur der Kernel übrig; das Userland ist ganz normal GNU, sogar die glibc wird verwendet. Wahrscheinlich für Leute gedacht, die mit der GPL kein Problem haben, die funktionsreicheren GNU-Werkzeuge verwenden wollen und trotzdem ZFS/DTrace/... benötigen. Wie aktuell das Projekt ist, weiß ich nicht, da der Kernel eine eigene Benennung bekommt. Geht auch durch die Debian-Philosophie von Freier Software eher sehr stark von BSD weg. Aus meiner Sicht eher nichts, was neue Leute zu *BSD bringen dürfte.

Gentoo/FreeBSD: Nimmt einige Anpassungen vor, wodurch die vollständige Binärkompatibilität mit FreeBSD nicht gewahrt werden kann. Das System wird mit Gentoos OpenRC gestartet, es kommt die Gentoo-Toolchain zum Einsatz und natürlich Portage zum Verwalten der Pakete. Ansonsten erhält man ein vollständiges FreeBSD-System. Allerdings stehen längst nicht alle Pakete aus dem Portage-Baum auch wirklich zur Verfügung. Das Projekt scheint mir an Personalmangel zu leiden und entsprechend nicht besonders aktuell zu sein: Für i386 steht nur ein veraltetes System auf Basis von FreeBSD 9.0 bereit (das sich aber wohl aktualisieren läßt) und für amd64 gibt es FreeBSD 9.1. Version 9.2 ist maskiert im Portage-Baum aufgeführt, gilt aber offenbar nicht aus einsatzbereit und ist Ende des Jahres ja genauso tot wie 9.1. Wer Gentoo nutzt, weiß wohl zumindest die Möglichkeit zu schätzen, Pakete so anzupassen, wie man sie haben möchte und ebenfalls die Fähigkeit des Systems, unterschiedliche Versionen eines Programmes parallel zu installieren. Wie attraktiv da FreeBSD wirkt, bin ich aber unsicher.

ArchBSD: Ein relativ junges Projekt (inzwischen 2 Jahre alt), das sich im Prinzip „FreeBSD mit Pacman“ auf die Fahnen geschrieben hat. Hier hält man sich relativ nahe an das Original an und hat sich nur zu ein paar strukturellen Kompromissen durchgerungen (/usr als Standardpräfix). Das früher optional auswählbare OpenRC als Initsystem wurde wieder aufgegeben. Allgemein ist das Projekt recht aktuell (derzeit ist das System offiziell auf Stand 10.0, allerdings ist 10.1 bereits im abs vorhanden und dürfte in absehbarer Zeit zur Verfügung stehen). Die Paketanzahl ist natürlich viel geringer als bei Arch Linux, aber nach meinem Empfinden leisten die Jungs wirklich gute Arbeit. And FreeBSD mit Pacman ist für einen begeisterten Anhänger der Art, wie Arch Pakete baut und verwaltet, schon verführerisch... Und dank Binärpaketen ist es schnell mal aufgesetzt - für Arch-Nutzer durchaus eine Möglichkeit sich mal was anderes anzusehen und dabei doch die vertrauten Werkzeuge nutzen zu können.

MirOS BSD: Hier haben wir einen ursprünglichen OpenBSD-Fork vor uns, der sich in verschiedene Richtungen geöffnet hat und auch mal in Richtung einer möglichst gemeinsamen Plattform von BSD und Linux gedriftet sein soll. Aus dem ganzen Projekt bin ich nicht völlig schlau geworden, um ehrlich zu sein. Aber das wird auch nichts sein, wodurch man zu *BSD kommt, sondern man dürfte viel eher mal darüber stolpern, wenn man sich für BSD interessiert.
 
Ich persönlich halte von solchen Mischformen nicht allzu viel. Man setzt dann doch eher auf ein zukünftig totes Projekt (siehe Debian/kFreeBSD)... GNU Tools kann ich mir auch in FreeBSD installieren. Debian verbaut sich ja mittlerweile auch immer mehr, ein System mit variablem Kernel zu sein. Dazu werden einfach zu viele Projekte Linux-Only.

Die Wahl die man hier trifft ist rein der Paket-Manager und auch wenn ich Pacman unter meinem Desktop-ArchLinux schon wegen der Einfachheit sehr mag, macht pkg in FreeBSD schon deutliche Schritte vorwärts und ich vermisse schon bald nichts mehr. Ist halt nur noch deutlich zu komplex von den Paketbeschreibungen, aber naja.

Meiner Meinung nach bewirken diese Projekte auch eher negative Meinungen über die BSDs. Man kommt von *Linux und nimmt dessen Basis-System, tauscht es mit dem *BSD Kernel aus und stellt fest, dass die Hardware-Unterstützung schlechter ist ohne, dass sich irgendetwas ändert oder bessert. Den Rest vom *BSD sieht man dann ja überhaupt nicht.

Würde lieber mal sowas wie ein L4/BSD sehen. Leider fehlt den ganzen offenen L4-Kerneln da draußen einfach die Man-Power und sind mehr Forschungsprojekt und die professionelle Anwendung ist geschlossen und kommerziell.
 
Gibts im FreeBSD Status Report keinen Abschnitt zu Debian kFreeBSD? So unwichtig ist es für die nicht.
Aber ich hab bisher keine Notwendigkeit gesehen jemals eine Chimäre nutzen zu müssen.
 
Auch ich kann mich nicht für die Mischformen begeistern oder mich mit Ihnen anfreunden, so reizvoll das auch scheint. Deshalb bevorzuge ich auch das pure native FreeBSD. Das gilt auch für PC-BSD, da nehme ich doch lieber gleich das Original. Da muß ich mich mit Allem auseinandersetzen, das ist auch gut und richtig so. Den wirklichen Sinn dieser Mischformen hat sich mir auch nicht wirklich erschlossen.
 
Paldium schrieb:
Da gibt es eine recht weit verbreitete Distribution:

Android - Baut auf dem Linux-Kernel auf, verwendet aber zu einigen Teilen BSD-Code im Userland. Da wäre zum Beispiel die C-Bibliothek "bionic", die viele OpenBSD-Quelltexte in sich trägt. Es kommen sogar Beiträge zurück! :)
Zum Vergrößern anklicken....

Ahh, ja, ein nettes Beispiel dafür, daß es auch „andersherum“ geht, sich also nicht ein BSD anpaßt und linuxartiger wird, sondern ein Linux BSD-Code enthält (sicher, weil Google damit lizenzmäßig freier agieren kann). Und als Beispiel auch deswegen schön, weil es mal Open statt wie meist Free ist.

-Nuke- schrieb:
Ich persönlich halte von solchen Mischformen nicht allzu viel. Man setzt dann doch eher auf ein zukünftig totes Projekt (siehe Debian/kFreeBSD)... GNU Tools kann ich mir auch in FreeBSD installieren. Debian verbaut sich ja mittlerweile auch immer mehr, ein System mit variablem Kernel zu sein. Dazu werden einfach zu viele Projekte Linux-Only.
Zum Vergrößern anklicken....

Wie gesagt, in Bezug auf Debian teile ich diesen Eindruck. kFreebsd ist absolute Nische - und wird gefühlt noch weiter an den Rand gedrängt. Wobei es um Hurd ja noch schlechter steht.

Die Wahl die man hier trifft ist rein der Paket-Manager und auch wenn ich Pacman unter meinem Desktop-ArchLinux schon wegen der Einfachheit sehr mag, macht pkg in FreeBSD schon deutliche Schritte vorwärts und ich vermisse schon bald nichts mehr. Ist halt nur noch deutlich zu komplex von den Paketbeschreibungen, aber naja.
Zum Vergrößern anklicken....

Findest Du? Ich denke, Pacman ist im Falle von ArchBSD bestenfalls die halbe Miete. Was Arch zumindest für mich seinen großen Reiz verleiht sind makepkg und das abs. Mal eben ein PKGBUILD schreiben ist völlig im Bereich des Möglichen. Ob man ebenso leicht einen Port aus dem Ärmel schütteln kann, bin ich skeptisch. Aber ich muß gestehen, daß ich mir die Ports-Infrastruktur erst flüchtig angesehen habe und auch mit make noch nicht wirklich per Du bin. Vielleicht ist das viel simpler als ich im Moment denke.

Meiner Meinung nach bewirken diese Projekte auch eher negative Meinungen über die BSDs. Man kommt von *Linux und nimmt dessen Basis-System, tauscht es mit dem *BSD Kernel aus und stellt fest, dass die Hardware-Unterstützung schlechter ist ohne, dass sich irgendetwas ändert oder bessert. Den Rest vom *BSD sieht man dann ja überhaupt nicht.
Zum Vergrößern anklicken....

Zugegeben: Nachdem mein erstes ArchBSD lief, habe ich meinen Eindruck auch scherzweise so zusammengefaßt: „Bootet länger und man kann Kommandozeilenoptionen nicht mehr einfach nachträglich hinten anhängen.“ ;) Abgehalten, damit etwas zu basteln, hat mich das aber nicht. Kann aber gut sein, daß das vor allem meiner Neugier geschuldet war, sowie dar Tatsache, daß ich freieren Lizenzen zugetan bin.

Würde lieber mal sowas wie ein L4/BSD sehen. Leider fehlt den ganzen offenen L4-Kerneln da draußen einfach die Man-Power und sind mehr Forschungsprojekt und die professionelle Anwendung ist geschlossen und kommerziell.
Zum Vergrößern anklicken....

Ja, die L4-Kernel sind bestimmt interessant. Aber ich sehe da in absehbarer Zeit auch wenig Chancen dafür, daß sich da etwas lebenstaugliches zu regen begänne.

darktrym schrieb:
Aber ich hab bisher keine Notwendigkeit gesehen jemals eine Chimäre nutzen zu müssen.
Zum Vergrößern anklicken....

„Müssen” klingt ja nicht besonders positiv. *g* Ich denke nicht, daß es viele Fälle gibt, bei denen man tatsächlich auf eine Mischform angewiesen ist. Aber ich fand's eben spannend, daß es sie trotzdem gibt - und ganz offensichtlich manche Leute Zeit hinein investieren.

ralli schrieb:
Auch ich kann mich nicht für die Mischformen begeistern oder mich mit Ihnen anfreunden, so reizvoll das auch scheint. Deshalb bevorzuge ich auch das pure native FreeBSD. Das gilt auch für PC-BSD, da nehme ich doch lieber gleich das Original. Da muß ich mich mit Allem auseinandersetzen, das ist auch gut und richtig so. Den wirklichen Sinn dieser Mischformen hat sich mir auch nicht wirklich erschlossen.
Zum Vergrößern anklicken....

Gerade die letzte Aussage kann ich nur unterschreiben. Ich denke, wenn ich bei ArchBSD stehengeblieben wäre, hätte ich es nicht zu lange genutzt. Denn dadurch, daß einem vieles abgenommen wird, kommt man nicht tief genug in FreeBSD rein, um mit dem eigentlichen System ausreichend vertraut zu sein. Und wenn das nicht gegeben ist, bleibt „FreeBSD + Pacman“ eine nette Spielerei und nicht mehr. Aber wenn man beide Systeme halbwegs kennt, denke ich, kann es im Sinne von „best of both worlds“ durchaus ein sinnvolles System sein.
 
Für meinen persönlichen Geschmack sind diese Mischformen durchgehend "falsch herum". Übertrieben gesagt versucht man die schlechteren Kernel mit dem schlechteren Userland zu verbinden. Viel interessanter fände ich eine Mischung, die den in Sachen Hardwaresupport und Unterstützung wirklich dicker Kisten (Free)BSD überlegenen Linux-Kernel mit dem gegenüber GNU und Abkömmlingen wesentlich konsistenteren BSD-Userland kombiniert. Aber wahrscheinlich ist es einfach zu viel Aufwand, da dass BSD-Userland sehr eng gegen den jeweiligen Kernel gestrickt ist.
 
Mit Verlaub, aber ich sehe so gar nicht, dass der linux kernel besser ist. Ja, bei linux gibt's deutlich mehr unterstützte hardware und ja, linux hat so einiges an Fortschrittlichem im kernel, was FreeBSD (noch) nicht hat.

Aber - und das ist ein großes Aber: linux hat auch immens mehr Mist im kernel und nicht selten über einen längeren Zeitraum mehrere Versionen und Varianten von Mist, bis man dann mal was Brauchbares hat.

Ich sehe es so: Wenn man ans "democratic bazaar" Modell glaubt und wenn man ständig das Neueste will, auch wenn das nicht immer glückliche Experimente bedeutet, dann ist man mit linux richtig (aber wer so tickt, der wird auch im userland von FreeBSD nichts so viel für sich Besseres sehen). Wer dagegen eher zum "experienced core" Modell neigt und zum sauberen engineering, der wird locker auf die Experimente von linux verzichten (und auch im FreeBSD userland weitgehend eine befriedigende, vielleicht sogar die bessere Variante sehen. Und mit systemd in nahezu allen linux Distributionen ist linux für mich eh auf den Status "nur wenn's unbedingt sein muss" gefallen.

Mischformen halte ich für unsinnig und zwar, weil ja nicht nur technische sondern insbesondere ideologische und grundsätzliche Unterschiede bestehen.
 
rmoe schrieb:
Mit Verlaub, aber ich sehe so gar nicht, dass der linux kernel besser ist. Ja, bei linux gibt's deutlich mehr unterstützte hardware und ja, linux hat so einiges an Fortschrittlichem im kernel, was FreeBSD (noch) nicht hat.
Aber - und das ist ein großes Aber: linux hat auch immens mehr Mist im kernel und nicht selten über einen längeren Zeitraum mehrere Versionen und Varianten von Mist, bis man dann mal was Brauchbares hat.
Zum Vergrößern anklicken....

Nunja. Das was im Linux-Kernel Mist ist, muss man aber auch nicht nutzen. Der FreeBSD-Kernel kriegt ja eher schleichend neue Features und entsprechend werden diese auch erst mal separat entwickelt und dann eingepflegt wenn es größtenteils fertig ist. Aber so Sachen wie Treiber sind bei FreeBSD jetzt nicht unbedingt besser, wenn überhaupt vorhanden.

Du hast ja auch nicht nur einen Bleeding-Edge Kernel. Du hast zusätzlich zum Hauptzweig noch 2.6, 3.2, 3.4, 3.10, 3.12, 3.14. Alles LTS Kernel. Such dir das Featureset aus was du brauchst und du hast schon einen sehr reifen Kernel. Bei FreeBSD hofft man doch schon eher auf einen neuen Kernel, weil endlich Bugs behoben werden oder essentielle Features/Treiber hinzukommen.

Wie Yamagi auch schon angesprochen hat. Das Userland bei Linux wird immer mehr große Grütze. udev, systemd, pulseaudio, networkmanager um nur ein paar zu nennen. Und das ist auch der Grund was mich auf dem Server zu FreeBSD treibt.
 
Sorry, -Nuke-,

vermutlich habe ich mich missverständlich ausgedrückt.

Ich halte herzlich wenig vom linux userland und denke keineswegs, dass es irgend besser ist als FreeBSD. Und, auch da stimme ich zu, klar ist das linux sound system ein einziges hässliches Geschwür.

Was den kernel angeht, liegen wir wohl etwas auseinander. Vermutlich deshalb, weil mich primär Zuverlässigkeit und gutes engineering interessiert (und ich das bei linux nicht so sehe).

Weil ich's eben noch weiter oben entdeckte: L4.
Ich verstehe ja, dass man hierzulande mächtig stolz ist, auch mal was Nennenswertes auf die Reihe gekriegt zu haben im Bereich IT. Und ich schätze Prof. Liedtke sehr hoch und würdige seine ausdauernde und wegweisende Arbeit.
Nur, der gängige Ansatz (z.B. beim merkel-handy) "L4 plus Linux inner VM drauf" ist keineswegs der Weisheit letzter Schluss. Liedtkes Ziel und großer Verdienst war nicht Sicherheit sondern einen wirklich leistungsfähigen Microkernel hinzukriegen (also einen, der nicht wie vorher üblich frappierend langsamer war als ein Monolith).

Ich persönlich verspreche mir da mehr von Prof. Tanenbaums Minix 3 (das wiederum sicher noch ein paar Tricks von L4 lernen kann). Übrigens haben die Minix Leute ihre aktuelle Version mittlerweile weitgehend netBSD userland kompatibel hingekriegt.
Aber im Grunde ist diese ganze Diskussion weitgehend witzlos, weil das wirkliche Problem im Hinblick auf Sicherheit, aber durchaus auch in Sachen performance nur zum kleinen Teil beim OS liegt. Weitaus kritischer und schwerwiegender sind da die Faktoren Sprache (C, Java, ...) und Ideologie/Philosophie. Entsprechend ist Linux, ziemlich egal welche lustigen Verrenkungen man da macht, eh gef*ckt (in Sachen Sicherheit); da ist jede Bemühung um Sicherheit letztlich ein sinnloser Sisyphos Job während die BSDs da in einer um Längen besseren Position sind.
 
Yamagi schrieb:
Viel interessanter fände ich eine Mischung, die den in Sachen Hardwaresupport und Unterstützung wirklich dicker Kisten (Free)BSD überlegenen Linux-Kernel mit dem gegenüber GNU und Abkömmlingen wesentlich konsistenteren BSD-Userland kombiniert.
Zum Vergrößern anklicken....

Alles Totprojekte, weil's keiner haben will:
http://www.phoronix.com/scan.php?page=news_item&px=MTI4MzI

Was L4 angeht: Das ist jetzt der wie vielte Versuch, den "endgültigen" Hurd-Kernel zu entwickeln? Da kommt bestimmt noch was Neues.
Neu ist die Idee aber auch nicht: http://bsdstep.sourceforge.net/
 
rmoe schrieb:
Nur, der gängige Ansatz (z.B. beim merkel-handy) "L4 plus Linux inner VM drauf" ist keineswegs der Weisheit letzter Schluss. Liedtkes Ziel und großer Verdienst war nicht Sicherheit sondern einen wirklich leistungsfähigen Microkernel hinzukriegen (also einen, der nicht wie vorher üblich frappierend langsamer war als ein Monolith).
Zum Vergrößern anklicken....

Das macht man aber nur, weil die Man-Power fehlt. Das Userland Linux (oder L4Linux) hat hier auch nur ca. 1% Overhead, gegebüber einem nativen Call. Entsprechend spart man sich, aufgrund der fehlenden Man-Power, hier für jeden Kram die Treiber noch mal zu schreiben. Sie laufen ja schon, nur halt durch den Linux-Kernel als Zwischenschicht. Das Grundkonzept "alles läuft im Userland" bleibt dabei. Es ist halt nur philosophisch etwas "unsauber".

MiniX hingegen wird immer ein OS für die Lehre bleiben. Das ist für den Alltag viel zu langsam und hat auch sonst fast nur Nachteile.

CrimsonKing schrieb:
Was L4 angeht: Das ist jetzt der wie vielte Versuch, den "endgültigen" Hurd-Kernel zu entwickeln?
Zum Vergrößern anklicken....

Hurd hat nichts mit L4 zu tun. Hurd ist nur ein GNU Microkernel, ich glaube auf Mach-Basis.

Außerdem sind L4-Kernel durchaus weit verbreitet. Nur halt nicht auf dem 08/15 Computer. Im Echtzeit-Bereich versagen ja die Standard-Betriebssysteme und die Echtzeit-Patches für Linux sterben auch aus. Hier regieren die Microkernel-Systeme.
 
Ich hatte das so verstanden, dass Hurd gezielt auf L4 als "Hauptkernel" portiert wurde, oder?
 
CrimsonKing schrieb:
Wieder was gelernt.
Zum Vergrößern anklicken....
Geht mir nach jedem einloggen hier so :)

Zu den "Mischformen" :

Vermutlich wird da schon auch handfeste Vorteile geben. Über die ich technisch aber nicht Bescheid wüsste.
Einer davon könnte alleinig schon der KnwoHow Transfer sein. Zwar sind Kernel und Userland unterschiedliche Ebenen, aber je nach Projekt bzw deren Entwickler kann das u.U. vlt schon Sinn machen.

An was ich auch schon dachte : Aspekt Sicherheit.
Android wäre diesbezüglich natürlich ein eher schlechtes Beispiel.

Zudem : "Mischform" impliziert natürlich "bereits Bestehendes" und halt nicht "Neues" wie zB etwa eine Abspaltung à la NetBSD-OpenBSD usw
 
-Nuke- schrieb:
Das macht man aber nur, weil die Man-Power fehlt. Das Userland Linux (oder L4Linux) hat hier auch nur ca. 1% Overhead, gegebüber einem nativen Call. Entsprechend spart man sich, aufgrund der fehlenden Man-Power, hier für jeden Kram die Treiber noch mal zu schreiben. Sie laufen ja schon, nur halt durch den Linux-Kernel als Zwischenschicht. Das Grundkonzept "alles läuft im Userland" bleibt dabei. Es ist halt nur philosophisch etwas "unsauber".
Zum Vergrößern anklicken....

Das mögen L4 Fans so sehen, aber man kann es auch anders sehen. Zum Beispiel mit der Frage im Blick, wo denn die meisten Sicherheitsprobleme auftauchen -> In Treibern (mal abgesehen vom userland).
Anders ausgedrückt: Die Logik, dass man so schon mal jede Menge Treiber hat heisst zugleich, dass man so schon mal jede Menge Sicherheitslücken hat.

Und bitte, wozu dann noch Mikrokernel? Damit man eine weitestgehend formale Grenzlinie zwischen kernel und Treibern hat? Sorry, dann kann man's auch lassen.

Und was die fehlende man-power angeht, bestätigst du im Grunde, was ich über Linux sagte. Denn die man-power hat man aus einem einfachen Grund nicht, dem nämlich, dass man die Vorteile eines Mikrokernels a) nicht kapiert, b) ideologisch ablehnt (-> Linus vs. Prof. Tanenbaum), c) gpl Hype und das 758. linux Fan Magazin für wichtiger hält.

-Nuke- schrieb:
MiniX hingegen wird immer ein OS für die Lehre bleiben. Das ist für den Alltag viel zu langsam und hat auch sonst fast nur Nachteile.

Hurd hat nichts mit L4 zu tun. Hurd ist nur ein GNU Microkernel, ich glaube auf Mach-Basis.

Außerdem sind L4-Kernel durchaus weit verbreitet. Nur halt nicht auf dem 08/15 Computer. Im Echtzeit-Bereich versagen ja die Standard-Betriebssysteme und die Echtzeit-Patches für Linux sterben auch aus. Hier regieren die Microkernel-Systeme.
Zum Vergrößern anklicken....

Da erlaube ich mir, klar zu widersprechen.

Minix ist inzwischen eine der sehr, sehr wenigen wirklichen Alternativen. Eine weitere (aber monolithische) allerdings weit weniger weit ausgereifte kommt von der Uni Prag. Einige L4 Implementationen sind eine weitere.

Und von wegen "regieren" im Echtzeit Bereich ... sorry, nein. Regieren tun dort (meist recht simple) RT Lösungen, die häufig - aus gutem Grund - Meilen von Betriebssystemen entfernt sind. Und in dem Bereich, in dem L4 eine Rolle spielt, ist das eine eher kleine.

Macht nichts, denn Lx (heutzutage L4) war ja auch gar nicht darauf angelegt, ein OS zu werden, sondern darauf das Thema Mikrokernel - und zwar im Hinblick auf 1 Aspekt, nämlich Performance - prinzipiell in den Griff zu bekommen. Und das hat Prof. Liedtke auch gut hingekriegt. L4 ist das, was andere dann, Pardon ungekonnt, daraus gemacht haben, indem sie mit virtual machines und Linux Mist im Grunde gegen den raison d'etre von L4 gearbeitet haben.

Nur am Rande: Wenn L4 wirklich sooo rasend schnell ist und sozusagen als Linux Turbo genutzt werden kann, dann stellt sich doch die Frage, ob Tanenbaum nicht von Anfang an recht hatte - da linux doch trotz dem 100+ fachen an Geldern und Entwicklern offensichtlich als Monolith nicht mithalten kann.
 
rmoe schrieb:
Das mögen L4 Fans so sehen, aber man kann es auch anders sehen. Zum Beispiel mit der Frage im Blick, wo denn die meisten Sicherheitsprobleme auftauchen -> In Treibern (mal abgesehen vom userland). Anders ausgedrückt: Die Logik, dass man so schon mal jede Menge Treiber hat heisst zugleich, dass man so schon mal jede Menge Sicherheitslücken hat. Und bitte, wozu dann noch Mikrokernel? Damit man eine weitestgehend formale Grenzlinie zwischen kernel und Treibern hat? Sorry, dann kann man's auch lassen.
Zum Vergrößern anklicken....

Die Sicherheit bei Microkerneln kommt nicht alleine daher, dass alles im Userspace läuft. Das alles im Userspace läuft ist schlicht eine Grundvoraussetzung für vielerlei weiterer Sicherheitskonzepte die darauf aufbauen. Dein Treiber braucht keinerlei Dateien? Gut, dann kriegt er eben keine Verbindung zum Filesystem Service... saubere, lupenreine Sandbox schon rein vom Grundkonzept her, ohne Aufsatz und Lücken.

Das kriegst du so in einem Monolithen nicht ohne weiteres hin. Da braucht es sehr sehr sehr viel Overhead.

Und klar ist hier der ganze "Linux-Stack" hier prinzipiell unsicher. Aber um den geht es dabei auch nicht. Es geht dann hier um 2 Bereich "Trusted" und "Non-Trusted" Zonen.

rmoe schrieb:
Und was die fehlende man-power angeht, bestätigst du im Grunde, was ich über Linux sagte. Denn die man-power hat man aus einem einfachen Grund nicht, dem nämlich, dass man die Vorteile eines Mikrokernels a) nicht kapiert, b) ideologisch ablehnt (-> Linus vs. Prof. Tanenbaum), c) gpl Hype und das 758. linux Fan Magazin für wichtiger hält.
Zum Vergrößern anklicken....

Microkernel haben schlicht den Ruf prinzipiell langsam zu sein. Und schon hat man das Henne-Ei Problem.

rmoe schrieb:
Und von wegen "regieren" im Echtzeit Bereich ... sorry, nein. Regieren tun dort (meist recht simple) RT Lösungen, die häufig - aus gutem Grund - Meilen von Betriebssystemen entfernt sind. Und in dem Bereich, in dem L4 eine Rolle spielt, ist das eine eher kleine.
Zum Vergrößern anklicken....

Also ich halte Systeme wie QNX jetzt nicht für ein "simples, quasi-kein" Betriebssystem. ;)

rmoe schrieb:
Macht nichts, denn Lx (heutzutage L4) war ja auch gar nicht darauf angelegt, ein OS zu werden, sondern darauf das Thema Mikrokernel - und zwar im Hinblick auf 1 Aspekt, nämlich Performance - prinzipiell in den Griff zu bekommen. Und das hat Prof. Liedtke auch gut hingekriegt. L4 ist das, was andere dann, Pardon ungekonnt, daraus gemacht haben, indem sie mit virtual machines und Linux Mist im Grunde gegen den raison d'etre von L4 gearbeitet haben.
Zum Vergrößern anklicken....

Wie gesagt. Keiner der L4-Entwickler >will< einen Linux-Kernel laufen haben. Aber die Man-Power fehlt. Rede einfach mal mit den Entwicklern dieser Kernel. Die haben auch oft schon Ports von Mesa, SDL, LLVM und Co. alle da. Aber leider fehlt Zeit und auch (wie gesagt) Man-Power um hier ordentliche Patches für ein Mainline in das Hauptprojekt zu machen.

Selbst große Projekte wie FreeBSD haben Probleme hier mit Linux-Anforderungen mitzuhalten. Wie soll das da ein System schaffen was schon für den Kernel um jede Hilfe ringt?

rmoe schrieb:
Nur am Rande: Wenn L4 wirklich sooo rasend schnell ist und sozusagen als Linux Turbo genutzt werden kann, dann stellt sich doch die Frage, ob Tanenbaum nicht von Anfang an recht hatte - da linux doch trotz dem 100+ fachen an Geldern und Entwicklern offensichtlich als Monolith nicht mithalten kann.
Zum Vergrößern anklicken....

Wie sagte doch einer der Entwickler von Fiasco.OC mal in die Runde... "Mit all den Zeilen Code von SELinux und Co, kann man einen Microkernel schreiben der all die Probleme nicht hat".
 
Ich habe das nie so richtig verstanden, wofür man ein Betriebssystem bei Echtzeitsystemen braucht. Ich habe das nie vermisst. Damit werden auch keine neuen Features umgesetzt. Da sind dann einfach dickere Prozessoren drin als man sonst bräuchte.
 
Hatte Tanenbaum recht? Würde ich teilweise mit "Ja" und teilweise "Nein" beantworten. Allerdings würde ich nicht in erster Linie technisch, stattdessen historisch argumentieren. Unix in fast allen Formen nutzt hauptsächlich monolithische Kernel, da solche in den 1970er Jahren State of the Art waren und man später nicht Zwecks Wechsel der Softwarearchitektur die Arbeit vieler Jahre wegwerfen wollte. Die zu erlangenden Vorteile standen einfach in keinem Verhältnis zu dem notwendigen Aufwand. Linus begann aber 1990 auf einem weißen Blatt Papier und hätte die Möglichkeit gehabt, aus Unix Fehlern und den Erkenntnissen anderer Systeme (VMS, MACH, etc.) zu lernen:
  • Es wäre definitiv sinnvoll gewesen nicht mit zwei Ebenen zu arbeiten, stattdessen wie z.B. Windows mit vier Ebenen. Innerer Kernel -> Treiber -> Subsysteme -> Userland.
  • Definierte Schnittstellen mit Versionierung zwischen einzelnen Subsystemen, anstelle eines Haufens sich laufend ändernder Funktionsaufrufen.
  • Generell so wenig wie möglich auf den Kernel-Ebenen umsetzen, stattdessen im Userland. Eine Lektion, die man bis heute nicht gelernt hat. Siehe z.B. KDBus.
Das alles hätte Linux bei weitem nicht zu einem Microkernel gemacht. Aber immerhin zu einem deutlich modularerem Projekt, was eine ganze Reihe Vorteile gebracht hätte:
  • Durch die damit einhergehende Kapselung der einzelnen Komponenten wäre das System wesentlich dynamischer als ein monolithischer Block.
  • Es wäre robuster, da man Teile selektiv neu starten könnte.
  • Sicherheitskonzepte ließen sich einfacher umsetzen.
  • Und nicht zuletzt wären 3rd-Party-Komponenten einfacher zu integrieren.
Aber wie so oft wollte man nicht zuhören. Man war nicht einmal bereit eine Diskussion zu führen, bügelte sie mit dem Argument "Microkernel sind Murks" ab. Das man nicht man mal einen echten Microkernel hätten bauen müssen, stattdessen nur die Fehler seiner Vorfahren nicht wiederholen, sah man nicht. So haben wir heute knappe 13 Millionen Zeilen Code, die einen technisch zwar beeindruckenden, aber auch eng zusammenhängen, monolithischen Kernel mit all seinen Nachteilen formen. In Sachen Architektur ist Linux in meinen Augen kein Bisschen besser als UNIX/v32, das darauf basierende 4BSD, sein Klon in Form von Unix System V und nicht zuletzt alle darauf basierenden Abkömmlinge. Was sehr, sehr Schade ist.
 
-Nuke- schrieb:
Die Sicherheit bei Microkerneln kommt nicht alleine daher, dass alles im Userspace läuft. Das alles im Userspace läuft ist schlicht eine Grundvoraussetzung für vielerlei weiterer Sicherheitskonzepte die darauf aufbauen. Dein Treiber braucht keinerlei Dateien? Gut, dann kriegt er eben keine Verbindung zum Filesystem Service... saubere, lupenreine Sandbox schon rein vom Grundkonzept her, ohne Aufsatz und Lücken.

Das kriegst du so in einem Monolithen nicht ohne weiteres hin. Da braucht es sehr sehr sehr viel Overhead.
Zum Vergrößern anklicken....

Ich sagte nicht, Sicherheit bei MK käme alleine daher, dass alles im User Space läuft. Was du da beschreibst von wegen keine Verbindung zum File System hat zunächst mal nichts mit MK zu tun sondern mit einem ganz anderen Konzept, Capabilities.
Geht bei einem Monolithen kaum? -> Capsicum. Hier auf FreeBSD.

Im übrigen sind Dateisysteme (und das Arbeiten damit) weit weg, weit oberhalb von dem Thema, um das es da geht; in Sachen Sicherheit geht es auf dieser tiefen Ebene im wesentlichen um 2 Bereiche: Speicher (RAM) und I/O. Und genau da liegen jede Menge Sicherheitsprobleme. Da geht es z.B. darum, dass irgendein Developer in Taiwan unter Zeitdruck ("Die neue Karte muss raus in die Läden!") schlampt und wer weiss wohin schreibt (z.B. auf die I/O ports des Chip Vorgängers ...) oder aus "Performance" Gründen in den (vermuteten) Speicherbereich im User Space.

Und das kann ihm in einem Monolithen nicht untersagt werden weil er mit vollen kernel Rechten hantiert.

-Nuke- schrieb:
Und klar ist hier der ganze "Linux-Stack" hier prinzipiell unsicher. Aber um den geht es dabei auch nicht. Es geht dann hier um 2 Bereich "Trusted" und "Non-Trusted" Zonen.

Microkernel haben schlicht den Ruf prinzipiell langsam zu sein. Und schon hat man das Henne-Ei Problem.
Zum Vergrößern anklicken....

Den Ruf hatten sie - vor u.a. Prof. Liedtkes wichtiger und bedeutender Arbeit. Weil das Problem durchaus verstanden, damals aber erstmal "doof" angegangen wurde. Wobei man zu "doof" fairerweise Folgendes anmerken muss: Sicherheit war damals noch weitgehend ein Nischenbedarf. Im Consumer-Markt ging es fast ausschließlich um Performance. Für das, was normale (durchaus auch Firmen) User unter Sicherheit verstanden, war irgendwie vage das OS zuständig.
Wirkliche Sicherheit war nur in wenigen Bereichen wichtig. Und dort war sie so wichtig, dass Performance im Zweifel eben durch Hardware Skalierung erkauft wurde; Hauptsache, das System war sicher. Anders ausgedrückt: In diesen Bereichen war der Nachteil der MK nur ein Ärgernis,das man aber gerne in Kauf nahm für Sicherheit.

-Nuke- schrieb:
Also ich halte Systeme wie QNX jetzt nicht für ein "simples, quasi-kein" Betriebssystem. ;)
Zum Vergrößern anklicken....

Das sagte auch niemand. Aber es mag dir vielleicht argumentativ gelegen sein es so (miss) zu verstehen.

-Nuke- schrieb:
Wie gesagt. Keiner der L4-Entwickler >will< einen Linux-Kernel laufen haben. Aber die Man-Power fehlt. Rede einfach mal mit den Entwicklern dieser Kernel. Die haben auch oft schon Ports von Mesa, SDL, LLVM und Co. alle da. Aber leider fehlt Zeit und auch (wie gesagt) Man-Power um hier ordentliche Patches für ein Mainline in das Hauptprojekt zu machen.

Selbst große Projekte wie FreeBSD haben Probleme hier mit Linux-Anforderungen mitzuhalten. Wie soll das da ein System schaffen was schon für den Kernel um jede Hilfe ringt?

Wie sagte doch einer der Entwickler von Fiasco.OC mal in die Runde... "Mit all den Zeilen Code von SELinux und Co, kann man einen Microkernel schreiben der all die Probleme nicht hat".
Zum Vergrößern anklicken....

Linux-Anforderungen? Damit (und einigem anderen, as du so schreibst) hast du das Problem ungewollt gut beschrieben. Und bestätigt, dass die L4 Leute ihr eigenes Kern-Thema vergessen haben. Linux ist das Problem, nicht die Lösung!

Auch FreeBSD ist da betroffen, wenn auch insofern unschuldig, als man nicht wie linux die Welt revolutionieren wollte. FreeBSD wollte einfach ein geiles, womöglich für viele Bereiche sogar das Beste OS open source aufgreifen und weiterführen.

Gleichwie, heute müssen die Monolithen immer neue Trick-Kisten aufmachen, um die heilige Performance zu bieten; oft indem man noch mehr user land in den kernel holt und/oder Treiber mit noch mehr features verfettet. Wobei FreeBSD, den Seitenhieb gönne ich mir jetzt mal, auch hier mal wieder deutlich professioneller, gekonnter, weniger hirntot und nuttig vorgeht als Systeme 20-Jähriger, die meinen, sie könnten Professoren belehren ...

Minix ist mir eigentlich schnurz. Ich würde auch Ixix oder ÜpsBSD sehr interessiert und erfreut aufgreifen, wenn sie das Richtige täten. Aber es ist nunmal gerade Minix (3), das den einzigen bisher bekannten brauchbaren Ansatz, nämlich MK, umsetzt und dabei eine Schnittstelle zu einem vorhandenen und reichhaltigen userland (netBSD) bietet. Wer einen besseren und pragmatisch nutzbaren Ansatz kennt, möge ihn nennen; ich bin interessiert, weiss aber keinen.

Noch bezahlt man die sehr geilen Features mit 5% - 10% Performance. Na und? Das ist ein Mäusefurz im Vergleich zu früher, damit kann man gut leben in Zeiten, in denen schon die nächste Prozessorgeneration das ausgleicht und in denen Multicores üblich sind.
Aber jeder Profi-Entwickler weiss, dass das richtige Konzept und die richtige Grundumsetzung entscheidend sind. Performance ist - mit dem richtigen Konzept - nur tuning. Und auch Treiber sind dann nur Fleissarbeit. Immerhin kann ich Minix3 hier und heute auf diversen Büchsen laufen haben.

Und die Jungs haben - wie auch die FreeBSDler - noch etwas Kluges gemacht; sie haben kapiert, dass es ein gigantischer Sicherheitsgewinn wäre, wenn man immerhin die server mal halbwegs dicht kriegen würde. Der große Vorteil? Man kann erst mal auf den ganzen Graphikmist (der den L4'ern so wichtig ist ...) schei*en und sich auf wirklich Wichtiges konzentrieren ... DNS, router und all die vielen server da draussen.
 
Kamikaze schrieb:
Ich habe das nie so richtig verstanden, wofür man ein Betriebssystem bei Echtzeitsystemen braucht. Ich habe das nie vermisst. Damit werden auch keine neuen Features umgesetzt. Da sind dann einfach dickere Prozessoren drin als man sonst bräuchte.
Zum Vergrößern anklicken....
Das sehe ich persönlich anders, zumindest sobald man mehrere Ausführungspfade gleichzeitig verfolgen möchte.
Natürlich muss man nicht gleich ein komplettes Linux auf einen AVR32 schmeißen, aber spätestens wenn USB gefordert ist, dann ist ein kleines RTOS schon sehr nett.
Ich habe an der FH mal einen Treiber, der mit Hilfe von FreeRTOS geschrieben wurde, auf Anweisung meines Betreuers hin ohne RTOS recyclet.
Später hat sich dann herausgestellt, dass das doch keine so tolle Idee war und ich wurde angemault, weil ich einen schlechten Rat befolgt habe.

Und bevor das ganze komplett OT wird: wenn die Funktion eines Echtzeitsystems komplex werden, dann möchte man schon ein RTOS,
aber höchstwahrscheinlich kein mal eben auf RT-gepatchtes GPOS.
 
Kamikaze schrieb:
Ich habe das nie so richtig verstanden, wofür man ein Betriebssystem bei Echtzeitsystemen braucht.
Zum Vergrößern anklicken....
Bei einem modernen Auto nimmt die Anzahl der Funktionen zu, bei gleichbleibender Anzahl an Microcontrollern. Folglich muß auf ein Microcontroller meist mehrere Funktionen erfüllen. Dafür braucht man dann sowas, wie ein (rudimentäres) Betriebssystem.
 
chaos schrieb:
Bei einem modernen Auto nimmt die Anzahl der Funktionen zu, bei gleichbleibender Anzahl an Microcontrollern. Folglich muß auf ein Microcontroller meist mehrere Funktionen erfüllen. Dafür braucht man dann sowas, wie ein (rudimentäres) Betriebssystem.
Zum Vergrößern anklicken....
Ich sehe die Kausalität hier nicht. Die Kombination aus FSMs, Timern, Event-Polling und IRs skaliert ziemlich gut.

Ich persönlich bin hier der Meinung, dass es sich um eine Mitigation-Taktik für Inkompetenz handelt. Die Echtzeit-Problematik ist nicht kompliziert.
 
Kamikaze schrieb:
Ich sehe die Kausalität hier nicht. Die Kombination aus FSMs, Timern, Event-Polling und IRs skaliert ziemlich gut.

Ich persönlich bin hier der Meinung, dass es sich um eine Mitigation-Taktik für Inkompetenz handelt. Die Echtzeit-Problematik ist nicht kompliziert.
Zum Vergrößern anklicken....

Es ist allerdings bequemer, wenn man das Ding nicht komplett selber bauen muss, sondern wie eine Library reinlinken kann.
Ist dann auch leichter und schneller erweiterbar.
Und USB ist *sehr* empfindlich, was Zeitverzögerungen angeht, da kommen ziemlich häßliche FSMs raus.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben