foofoobar schrieb:
Ein paar Daemons/Services und ein paar Shared-Libs bzw. DLLs verkehren einen Monolithen nicht ins Gegenteil.
Naja. Es geht dabei weniger um Daemons oder Sharedlibs. Sondern darum, das zum Beispiel auch Treiber teilweise in einer anderen Berechtigungsstufe laufen und damit eine Isolationsschicht zum "Kernelmode" existiert. Das ist ja eine der Ideen beim Mikrokernel. Das man sagt, man macht nur das absolut Notwendigste in den Kernel und der Rest läuft im Usermode und wird nur durch entsprechende Schnittstellen/Gates miteinander verknüpft. So ein System überlebt dann z.B. sogar auch ein Treiberabsturz.
Windows ist natürlich weit weg von dem stringenten Modell eines Mikrokernels. Es ist aber auch kein All-in-one monolithischer Kernel.
foofoobar schrieb:
Ach ja, wer sowas wie ein HAL unter Linux vermisst sollte mal beim C-Compiler suchen.
HAL ist lediglich ein Workaround um ein closed-source Konstrukt aufrecht zu erhalten.
HAL ist vor allem ein Mechanismus,um von der darunter liegenden Hardware zu abstrahieren.
Sagt schon der Name: HAL = Hardware abstraction layer
Wie gut das funktioniert oder nicht funktioniert, darüber kann man natürlich streiten. HAL macht halt noch jede Menge mehr, was es dann natürlich relativ komplex macht.
Anyway, die Praxisbedeutung ist inzwischen eher gering, da der Ersatz deutlich besser funktioniert.
Insofern ist es ja auch nicht so, das Linux kein HAL hat, sondern einfach nur durch andere Mechanismen (udev usw.) ersetzt hat.
mike78sbg schrieb:
Linux hat einen monolithischen Kernel ist somit schon mal falsch.
Es ist ein monolithischer Kernel. Allerdings kann man ihn mit Modulen erweitern, welche bei Bedarf geladen und entladen werden können.
Offenbar bestehen Unklarheiten darüber, was monolithischer Kernel bedeutet.
Ladbare Module ist keine hinreichende Eigenschaft dafür, ob es sich um einen monolithischen Kernel handelt oder nicht. Wesentlich für die Betrachtung ist, ob es eine Isolation zwischen den Kernelbestandteilen/Treibern gibt.
Ums mal ganz simpel zu formulieren: Bei einem monolithischen Kernel kann ein (fehlerhafter) Treiber den Kernel crashen. bei einem Mikrokernel-Design geht das nicht.
mike78sbg schrieb:
/ect sind die ganzen config dateien als textfiles untergebracht, ganz im Gegensatz zur unübersichtlichen registry in Windows.
Naja. Ob das was man unter /etc so alles findet jetzt wirklich übersichtlicher ist, darüber lässt sich streiten.
In der Registry hast Du eine saubere hierarchische Struktur. Es gibt Mechanismen/Konventionen die verhindern, das sich zwei Konfigurationen versehentlich in die Quere kommen.
Sprich: Haben unter Linux zwei Programme eine Konfiguration mit dem selben Namen, hast Du ein Problem (i.d.R. kümmert sich da die Distribution drum, so das Du davon nichts merkst).
Auf die Registry kannst Du auch in einer einheitlichen Art und Weise drauf zugreifen. Wenn man sich dagegen die Konfigrationsdateien unter Linux anguckt, dann ist da eine Konfigurationsdatei im INI-Style, die nächste hat irgendwie JSON oder auch XML. Oder man hat sowas wie die
/etc/passwd, wo dann Fields mit Doppelpunkt separiert sind usw. Einheitlicher Standard? Fehlanzeige.
Die Registry ist zudem eine Datenbank, was den Zugriff schneller machen kann, wenngleich das auf moderner Hardware kaum ins Gewicht fällt.
Aber ja. Die Registry hat auch ganz klare Drawbacks. Man kann nicht so einfach reingucken wie bei einer Textdatei, sondern braucht dann ein spezielles Tool (Registry-Editor) für. Und sowieso die ganzen Texttools die man hat funktionieren nicht auf der Registry.
Zudem hat man die Möglichkeit Kommentare zu schreiben, wenn man eine Textdatei als Konfigurationsdatei hat. Und viele Einstellungen werden ja auch auf die Art und Weise dokumentiert.
Auch das Backup-Handling ist sehr viel einfacher als bei einer (monolithischen) Registry. Man kann schnell mal Einstellungen testen, was bei einer Registry eher unhandlich ist.
mike78sbg schrieb:
/home ist das Verzeichns für die User "/home/<username>" Somit hat man eine viel sauberere Trennung zwischen User und System.
Die Trennung hast Du auch unter Windows. Dort liegen die Home-Verzeichnisse unter C:\Users\<username>
mike78sbg schrieb:
Unter Windows liegt alles auf "C:".
Naja. Wenn Du es nicht gerade separierst, hast Du bei Linux auch alles auf einem Laufwerk. Die Bezeichnungen sind anders aber im Grunde ist es das gleiche.
mike78sbg schrieb:
Und besonders im Verzeichnis C:\Windows\ herrscht in der Regel Chaos.
Das kann man aber auch bei Linux sagen.
Zum Beispiels das Programme i.d.R. alle unter /usr/bin landen. Oder überhaupt die Tatsache, das installierte Programme übers Dateisystem verstreut werden statt alles zusammen in ein Verzeichnis zu packen.
Es lässt sich ja auch gut begründen, warum das so gemacht wird. Es gibt auch gute Gründe das anders zu machen.
Man kann ja von mir aus trotzdem sagen, das es unter Windows schlimmer ist. Aber diese einseitige Betrachtung die suggeriert, das unter Linux alles super ist und unter Windows alles doof, das ist mir dann doch ein bisschen zu dünn und zu eindimensional.
Wenn wir schon mal ein Thread mit dem Titel haben, sollte man sich vielleicht mal nicht irgendwelchem undifferenzierten Herumgebashe hingeben.
mike78sbg schrieb:
Auch die Berechtigung unter Linux ist viel restriktiver. MS hat hier mittlerweile einiges übernommen aus der UNIX Welt, nachdem sie mit XP und davor doch sehr oft massiv auf die Nase geflogen sind,
Naja. Auch das ist wieder so ein pauschaler Punkt. Gerade die früheren Linux-Distributionen aus der Zeit waren alles andere das restriktiv. Da war es üblich, das irgendwelche Daemons liefen die zudem noch auf 0.0.0.0 gelauscht hatten. Firewall musste man erst mal von Hand konfigurieren.
mike78sbg schrieb:
Ein "sudo" fehlt schlichtweg.
Inzwischen gibt es sowohl ein (eingeschränktes)
sudo und zuvor kannte man schon ein
runas.
Aber ich will dazu eher was anderes anmerken.
sudo ist ja eigentlich eher ein Tool, mit dem man differenziert und gezielt besimmte Rechte vergeben kann. So wird das aber bei den meisten Linux-Distribution gar nicht per default genutzt. Meist hat man ne Konfiguration a-la
%sudo ALL=(ALL:ALL) ALL
Sprich: Da wird für die Eingabe deines Userpassworts einfach ne Blanko-Vollmacht ausgestellt. Hier wird einfach Bequemlichkeit und einfache Umsetzung gegenüber Sicherheit vorgezogen.
Mal davon abgesehen, das
sudo ein relativ komplexes Programm ist und dementsprechend gab es auch schon etliche Sicherheitslücken. Was natürlich besonders doof ist. Auf der einen Seite nutzt man die Features und Möglichkeiten von sudo nicht. Auf der anderen Seite zieht man sich sicherheitsgefährdende Komplexität rein.
Für die meisten Sachen die so gemacht werden, könnte man das auch mit Hilfe des simpleren
doas realisieren. Das stammt originär aus OpenBSD und die haben ja den Ruf, sehr sicherheitsbewusst zu sein. Nicht umsonst finden ja viele Tools aus OpenBSD ihren Weg zu anderen UNIX-Derivaten.
mike78sbg schrieb:
Dann der Paketmanager. Während man unter Windows irgendwelche .exe dateien installiert, gibt es für so ziemlich jede Distribution einen Paketmanager (deb, rpm, ...), und der kümmert sich um die ganze Software.
Ja. Ne setup.exe aus dem Internet zu ziehen war und ist immer noch üblich. Allerdings gibt es schon seit ein paar Jahren den
Microsoft Store, der Ähnlichkeiten zu einem Paketmanager hat.
Auf der anderen Seite gibts im Bereich der Linux-Paketmanager ein ziemlich großes Durcheinander. So gibt es verschiedene Package-Systeme mit unterschiedlichen Formaten. Das hat früher mal Sinn gemacht. Heutzutage haben aber 90% der Paketmanager zu 90% identische Features. Da gäbe es schon Potential für Vereinheitlichungen.
Wenigstens in der Benutzung.
Dann gibts noch die Problematik, das es schwierig wird distributionsübergreifend Programme publizieren zu wollen. Die werden dann durch AppImage, Snappy, Flatpak und Co addressiert.
Dafür das Du ne Allergie gegen Chaos hast, nimmst Du das ziemlich gelassen hin. ;-)
Pummeluff schrieb:
Ich hab meine Zweifel, dass Tanenbaum der "Erfinder" des Microkernels war.
Da hast Du vollkommen recht. Die Ursprünge liegen (wie vieles was heute in der modernen Computerei etabliert ist) in den 60er/70er Jahren.
Lustigerweise war ja der für GNU angedachte Kernel ebenfalls ein Microkernel (
GNU Hurd ; abgeleitet von dem Mach-Kernel der ja letztlich in einer stark modifizierten Form auch in Mac OS X verwendet wird).
Pummeluff schrieb:
Allerdings muss man Tanenbaum zugestehen, dass sein Minix auf wesentlich mehr x86-basierten Intel-Rechnern läuft als Linux.
Der Einwurf gefällt mir. :-)
Wobei jetzt noch mal interessant zu wissen wäre, was da bei den AMD x86-CPUs zum Einsatz kommt. Und dann kann da auch noch mal reinspielen, welchen Marktanteil AMD bei x86 hat. Ich würde mal schätzen, Intel liegt da bei ca.80%