Unterschiede von Linux und Windows - Suche Vergleich der Architektur

[#Schlangenöl]

Hi,

ich suche eine Gegenüberstellung von Linux und Windows, die die Kernunterschiede in der Architektur aufzeigt. Mir geht es dabei nicht um das Lizenzmodell oder die Usability, sondern eher um Kernelaufbau, HAL, Granularität etc.

Was ich bisher gefunden habe stellt meist auf einen der Punkte ab, die mich nicht interessieren. Hier geht's um Betriebssystemarchitektur. Vielleicht kenn jemand in drei oder vier Sätzen mal die Unterschiede erklären.

 

[foofoobar]

Ich hab meine Zweifel, dass Tanenbaum der "Erfinder" des Microkernels war. Er hat den monolithischen Kernel (und damit Linux) als obsolet dargestellt und lag damit gnadenlos falsch.

Ein µ-Kernel ist schon eine schicke Sache, es ist allerdings schwierig bis unmöglich diesen durch die Isolation bedingten notwendigen Context-Switches, memcpys, etc. performant zu kriegen, insbesondere in den Zeiten von Spectre & Co.
Im Userspace wäre das grob damit zu vergleichen auf verschiedene Prozessen anstatt Threads zu setzen.

Allerdings muss man Tanenbaum zugestehen, dass sein Minix auf wesentlich mehr x86-basierten Intel-Rechnern läuft als Linux.

Das wäre ja mal was Neues, hast du was am Start um das zu belegen?

 

[Pummeluff]

https://linuxnews.de/minix-in-der-intel-management-engine/

 

[foofoobar]

Ist das überhaupt eine X86-CPU?

 

[mike78sbg]

Es ist ein Mikrocontroller in den Intel CPUs. Quasi eine CPU in der CPU.

 

[nullPtr]

Ist das überhaupt eine X86-CPU?

Ja, Intel nutzt in der ME afaik Quark
https://en.wikipedia.org/wiki/Intel_Quark

 

[andy_m4]

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.

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.

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.

/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.

/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>

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.

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.

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.

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.

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. ;-)

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).

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%

 

[foofoobar]

sudo ist eher zu unterkomplex um da richtig wasserdichte Regeln bauen zu können, andererseits wäre eine Beschreibung die wasserdichte Regeln ermöglicht für den User zu komplex und damit wieder fehleranfällig.

Ein µ-Kernel der alles zwischen verschieden Teilen kopieren muß (jeweils immer mit Kontext-Switch) wäre recht lahm. Zähl das einfach mal für einen Platten-Zugriff durch bis das Zeug im User-Space ankommt.

 

[andy_m4]

sudo ist eher zu unterkomplex um da richtig wasserdichte Regeln bauen zu können

Das kann man so sehen. Trotzdem werden die Möglichkeiten von sudo nicht richtig ausgeschöpft bzw. so wie es verwendet wird, kann man auch (sicherere) Alternativen einsetzen.

Ein µ-Kernel der alles zwischen verschieden Teilen kopieren muß (jeweils immer mit Kontext-Switch) wäre recht lahm.

Ich hab ja auch nicht behauptet, das Mikrokernel keine Nachteile haben. Ich habe lediglich erklärt, wie ein Mikrokernel grob aufgebaut ist.
Mal abgesehen davon, das man den Overhead durchaus optimieren kann.
Letztlich ist es ja auch eine Frage, was einem wichtig ist. Sicherheitsfeatures gehen nicht selten auf Kosten der Performance. Und genauso wie man das in anderen Bereichen akzeptiert und damit lebt, kann man natürlich auch beim Mikrokernel eine solche Betrachtung machen.

Schon allein deshalb ist ein pauschales "ist lahm" völlig fehl am Platze.

 

[mike78sbg]

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.

Wer behauptet, dass Module eine Eigenschaft für einen monolithischen Kernel sind?
Der Linux Kernel ist ein monolithischer Kernel. Das hat nichts mit den Modulen zu tun, die noch zusätzliche Möglichkeiten bieten.

Naja. Ob das was man unter /etc so alles findet jetzt wirklich übersichtlicher ist, darüber lässt sich streiten.

Was fehlt dir den unter /etc ?
Als Beispiel die Config von ssh, iptables (firewall rules), fstab für die Festplatten.
shadow, passwd oder group für die Userverwaltung.
Nur um ein paar Beispiele zu nennen. Einfach lesbar mit einem Texteditor deiner Wahl.
Aber gut, du schreibst es eh schon selber ganz gut, was die Vorteile von /etc/<configs> sind.

Die Trennung hast Du auch unter Windows. Dort liegen die Home-Verzeichnisse unter C:\Users\<username>

Ja, dann versuch mal dieses C:\Users\<username> auf eine andere Partition zu verschieben.
Und Vergleich mal die Unterverzeichnisse zwischen dem /home/user Linux und dem unter Windows.
Ich sag dir gleich, bei einem Backup und zurück spielen des Backups verlierst du unter Windows.
Ich pack mein /home/user auf eine eigene Partition, da brauch ich gar nichts machen, wenn ich neu aufsetze. Backup sollte man aber sowieso immer haben.

Naja. Auch das ist wieder so ein pauschaler Punkt. Gerade die früheren Linux-Distributionen aus der Zeit waren alles andere das restriktiv.

Wir leben aber nicht im früher, wir leben im jetzt. Ich schreibe ja auch nicht von Windows 98 über die Berechtigungen, sondern hab hervorgehoben, dass MS seit Windows XP stark dazu gelernt hat. 😉

Inzwischen gibt es sowohl ein (eingeschränktes) sudo und zuvor kannte man schon ein runas.

Ja, ich weiß, es gibt endlich ein sudo für Windows, welches aber ein Witz ist.

Da wird für die Eingabe deines Userpassworts einfach ne Blanko-Vollmacht ausgestellt.

Ähm, wenn der User etwas verhaut, kann das System nichts dafür. Den ganzen langen Text hättest dir jetzt echt sparen können. 😉
Mal abgesehen davon, dass ich kaum einen User kenne, der in der sudo config Datei groß was ändert.

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.

Oja, der MS Store. Wieder mal schlecht kopiert von Apple und Google.
Taugt der mittlerweile? Wennn ja, ists ja gut. Als ich noch Win10 arbeiten musste war der schlichtweg unbrauchbar.

Auf der anderen Seite gibts im Bereich der Linux-Paketmanager ein ziemlich großes Durcheinander. So gibt es verschiedene Package-Systeme mit unterschiedlichen Formaten.

Ja, es gibt unterschiedliche Paketsysteme, aber das funktioniert heutzutage schon sehr gut.
Wenn du auf einer Plattform (deb, rpm, arch) unterwegs bist, hast du in der Regel alles was du brauchst. Ausnahmen gibts immer, und 100% Perfekt ist nichts.
Aber für das große Durcheinander hätte ich gerne ein paar explizite Beispiele. 😉

Dafür das Du ne Allergie gegen Chaos hast, nimmst Du das ziemlich gelassen hin. ;-)

Weil ich unter Manjaro kein Chaos hab. Ich finde alles im Paketmanager. Offizielle Quellen oder AUR.
Bitte um explizite Beispiele. 😉

 

[andy_m4]

Wer behauptet, dass Module eine Eigenschaft für einen monolithischen Kernel sind?

Das hat niemand behauptet.
Zur Klarstellung: Ich habe Dein Posting so gelesen, das Linux kein monolithischer Kernel ist, weil es ja ladbare Module gibt. DEM habe ich widersprochen.
Wenn Du das anders gemeint hast, dann habe ich Dich falsch verstanden.

Was fehlt dir den unter /etc ?

Es ist nicht so, das mir etwas fehlt.
Ich hab nur die beiden Varianten gegenüber gestellt und versucht die spezifischen Vor- und Nachteile herauszustellen. Einfach um aus der eindimensionalen Darstellung a-la "Reigstry ist doof und /etc ist cool" rauszukommen.
Du kannst es auch so lesen, das ich Deinen Einwurf dazu komplettieren wollte. :-)

Ja, dann versuch mal dieses C:\Users\<username> auf eine andere Partition zu verschieben.

Da hast Du nicht Unrecht. Deswegen hatte ich ja auch insofern eingeschränkt und gesagt: Wenn Du alles auf einer Platte/Partition hast, ist es bei Linux wie bei Windows.
Abgesehen davon hast Du natürlich auch die Möglichkeit bei Windows zu verschieben.
Aber ja. Bei Linux geht es sicher eleganter/leichter.

Ich sag dir gleich, bei einem Backup und zurück spielen des Backups verlierst du unter Windows.

Ich finde Backups unter Windows auch eher anstrengend.

An der Stelle will ich noch mal generell gesagt haben:
Ich will hier Windows nicht als das bessere System hinstellen oder so. Es ging mir nur darum Deine Kritik zu relativieren und auch mal ein wenig einzuordnen, weil mir das zu einseitig war.
Mir ist es immer lieber, man macht eine ehrliche Betrachtung. Übertriebene Einseitigkeit wirkt immer so ein bisschen wie Fanboy-Gequatsche.

Wir leben aber nicht im früher, wir leben im jetzt.

Naja. Ich kam ja darauf, weil Du Windows XP ins Feld geführt hast.
Das ist ja nun auch nicht gerade bleeding-edge. :-)

Ja, ich weiß, es gibt endlich ein sudo für Windows, welches aber ein Witz ist.

Ja. Wobei das, was üblicherweise(!) mit sudo unter Linux gemacht wird Du auch gut mit den entsprechenden Windows-Mechanismen hinkriegst.

Ähm, wenn der User etwas verhaut, kann das System nichts dafür.

Klar kann das System nichts dafür. Aber es ist ja auch nicht der User der das so konfiguriert, sondern es ist die Default-Konfiguration vieler Distributionen. Und die darf man dann schon mal kritisch betrachten.
Und ja. Man kriegt ein Linux sicherer konfiguriert (als der default). Aber man kriegt auch ein Windows sicherer konfiguriert (als der default).

Den ganzen langen Text hättest dir jetzt echt sparen können. 😉

Nein. Das war ein wertvoller Bildungsbeitrag. Der war keineswegs umsonst. :-)

Mal abgesehen davon, dass ich kaum einen User kenne, der in der sudo config Datei groß was ändert.

Na um so berechtigter ist ja dann meine Kritik.

Taugt der mittlerweile?

Es lässt sich schon ziemlich viel darüber installieren.
Ich wollte auch nur dem Eindruck entgegentreten, als gäbe es für Windows gar kein Software-Management.

Aber für das große Durcheinander hätte ich gerne ein paar explizite Beispiele. 😉

Naja. Im Grunde nennst Du das ja schon selbst. Warum haben wir überhaupt RPMs, DEBs und Co und uns nicht einfach mal auf ein Paketformat geeinigt ?
Dafür gibts eigentlich kein rationalen Grund außer "historisch gewachsen".

Wir haben auch an vielen anderen Stellen das Problem, das Sachen unterschiedlich gemacht werden ohne das es einen direkten Nutzen hat. Auf der anderen Seite gibts aber natürlich auch gewisse Vereinheitlichungsbestrebungen. Man muss ja nicht alles vereinheitlichen. Verschiedene Ansätze haben ja auch ihre individuellen Vorteile und führen außerdem zu einem Wettbewerb, um eine gute Lösung zu finden. Aber da, wo letztlich eh alle so ziemlich das gleiche machen, da kann man auch den Schritt gehen zu sagen, das man das halt überall wirklich gleich macht. Weil das Aufwand minimiert und das Fehlerpotential senkt.

Weil ich unter Manjaro kein Chaos hab.

Ja. Unter Deiner Distribution und wenn Du das distributionsspezifische Repository nutzt, dann merkst Du natürlich kein Chaos. Wenn man mal über die gesamte Linux-Landschaft drüber guckt, dann ist das halt ein riesiger Flickenteppich.
Das führt dann letztlich auch dazu, das viele Ressourcen dabei drauf gehen um letztlich redundante Arbeiten zu machen.

 

[foofoobar]

Das kann man so sehen. Trotzdem werden die Möglichkeiten von sudo nicht richtig ausgeschöpft bzw. so wie es verwendet wird, kann man auch (sicherere) Alternativen einsetzen.

Butter bei die Fische, werde konkret.

Ich hab ja auch nicht behauptet, das Mikrokernel keine Nachteile haben. Ich habe lediglich erklärt, wie ein Mikrokernel grob aufgebaut ist.
Mal abgesehen davon, das man den Overhead durchaus optimieren kann.
Letztlich ist es ja auch eine Frage, was einem wichtig ist. Sicherheitsfeatures gehen nicht selten auf Kosten der Performance. Und genauso wie man das in anderen Bereichen akzeptiert und damit lebt, kann man natürlich auch beim Mikrokernel eine solche Betrachtung machen.

Wie kann man Context-Switche und kopieren optimieren?

Ergänzung (21. März 2024)

Oja, der MS Store. Wieder mal schlecht kopiert von Apple und Google.
Taugt der mittlerweile? Wennn ja, ists ja gut. Als ich noch Win10 arbeiten musste war der schlichtweg unbrauchbar.

Und noch schlechter von Debian (since 1995) kopiert.

 

[Pummeluff]

Wobei jetzt noch mal interessant zu wissen wäre, was da bei den AMD x86-CPUs zum Einsatz kommt.

Steht im selben Artikel:

Auch AMD ist keine sichere Bank in dieser Hinsicht. Die neuen Ryzen-Chips enthalten mit dem AMD Platform Security Process ebenfalls »ein schwarzes Loch«. Minnich machte eindrücklich klar, dass er es Ernst meint, wenn er sagte: »Wenn ihr jetzt noch keine Angst habt, dann hab ich das schlecht erklärt. Ich jedenfalls habe Angst.«

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%

Inwiefern? Intel hat mit der IME eine Backdoor geschaffen, mit der am OS und sogar an der CPU vorbei eine Hardwarekontrolle möglich ist, auf die der Nutzer keinen Einfluss hat. Das dürfte wenig mit dem Marktanteil zu tun haben.

Gab im Film "Snowden" so eine schöne Szene, als die bei der NSA bei einem ausgeschalteten Notebook die Webcam angezapft hatten. Ich würde grob davon ausgehen, dass mit der IME genau solche Dinge möglich sind. Wie schon im o.g. Artikel dazu stand:

Das System hat Zugriff auf die TCP/IP-Netzwerk-Schicht, das Dateisystem, auf Treiber und Web-Server. Es kann zudem die Firmware des Rechners selbst im ausgeschalteten Zustand ändern. Auch kann es selbst-modifizierenden Code einfügen, der selbst in einem stromlosen Rechner erhalten bleibt.

 

[mike78sbg]

Naja. Ich kam ja darauf, weil Du Windows XP ins Feld geführt hast.
Das ist ja nun auch nicht gerade bleeding-edge. :-)

Ja, darum hab ich eben geschrieben, man hat damals dazugelernt, weil man mit XP ziemlich auf die Nase gefallen ist. Heutzutage drückst du meist einen "Ja" Knopf, und dann ist der Virus auch schon wieder drauf. 😁
Ok, das war jetzt überspitzt. 😉
Worauf ich hinaus will, es ist nicht Konsistent. Manchmal drück ich den "Ja" Knopf, manchmal brauch ich ein Kennwort, und wenn du im System was ändern willst, klickst du dich oft im Kreis, und ein anderes mal musst du dich extra als Admin umloggen.
Mag sein, dass es unter Win11 besser geworden ist, aber unter Win10 war ich oft am Fluchen.

Naja. Im Grunde nennst Du das ja schon selbst. Warum haben wir überhaupt RPMs, DEBs und Co und uns nicht einfach mal auf ein Paketformat geeinigt ?
Dafür gibts eigentlich kein rationalen Grund außer "historisch gewachsen".

Ja, mir ist klar, dass es den gibt. Aber der Paketmanager unter Linux ist halt doch etwas mehr als nur Anwendungen zu installieren.
Und ein Update mit dem Paketmanager bedeutet max. schnell einen Neustart und fertig.
MS will wieder mal die Neustarts verringern nach Updates. 🤨

Ja. Unter Deiner Distribution und wenn Du das distributionsspezifische Repository nutzt, dann merkst Du natürlich kein Chaos. Wenn man mal über die gesamte Linux-Landschaft drüber guckt, dann ist das halt ein riesiger Flickenteppich.

Eben, daher sehe ich hier kein Chaos darin. Du hast eine Distribution, und unter der läuft es.

Klar kann man die unterschiedlichen Paketmanager kritisch sehen, aber andererseits fördert es in gewisser Weise den Wettbewerb untereinander es besser zu machen. Und Vielfalt ist ja nichts schlechtes.

Ich sehe also kein Chaos unter Manjaro. Und wenn ich Ubuntu nutze sehe ich auch kein Chaos.

Und noch schlechter von Debian (since 1995) kopiert.

Zustimmung, das wollte ich mir aber verkneifen. 😁

 

[foofoobar]

Ja, mir ist klar, dass es den gibt. Aber der Paketmanager unter Linux ist halt doch etwas mehr als nur Anwendungen zu installieren.
Und ein Update mit dem Paketmanager bedeutet max. schnell einen Neustart und fertig.
MS will wieder mal die Neustarts verringern nach Updates. 🤨

Windows hat allerdings das Problem das man im laufenden Betrieb keine *.so bzw. *.dll austauschen kann.

Damit wäre der nächste wesentliche Architekturunterschied gefunden: Das Filessystem.

 

[foofoobar]

Inwiefern? Intel hat mit der IME eine Backdoor geschaffen, mit der am OS und sogar an der CPU vorbei eine Hardwarekontrolle möglich ist, auf die der Nutzer keinen Einfluss hat. Das dürfte wenig mit dem Marktanteil zu tun haben.

Wo ist der Angriffsvektor Ethernet/Netzwerk bei AMD?

 

[mike78sbg]

Damit wäre der nächste wesentliche Architekturunterschied gefunden: Das Filessystem.

Korrekt, hier fällt mir zusätzlich Case Sensitive ein.

Linux unterscheidet in Groß und Kleinschreibung, Windows nicht.
Außerdem ist Linux wesentlich flexibler bei Sonderzeichen in Dateinamen.

Und Windows hat, zumindest bis Windows 10, Probleme mit USB Sticks, die Partitioniert sind. Ohne extra tools geht da nichts. Keine Ahnung, ob das mittlerweile funktioniert.

 

[andy_m4]

Butter bei die Fische, werde konkret.

Was willst Du genau wissen?
Die sichere Alternative hatte ich genannt.

Wie kann man Context-Switche und kopieren optimieren?

Kopieren kann man beispielsweise damit optimieren, das man nicht kopiert. Wenn es sich z.B. um Readonly-Memory-Pages handelt gibt es ja keinen Grund die zu kopieren, sondern man kann sie einfach im Addressraum des entsprechenden Prozesses einblenden.
Ich will jetzt hier aber keinen Vortrag zu Mikrokernel-Optimierungen machen, weil es dazu viel Material im Internet gibt.
Mal abgesehen davon, das Du viel von mir zitierst aber dann überhaupt nicht darauf eingehst.
Wäre schön, wenn man mal vernünftig miteinander redet und nicht nur versucht irgendwie destruktiv reinzugrätschen.

Manchmal drück ich den "Ja" Knopf, manchmal brauch ich ein Kennwort, und wenn du im System was ändern willst, klickst du dich oft im Kreis, und ein anderes mal musst du dich extra als Admin umloggen.

Ja. Das die Bedienung nicht konsistent ist und auch manchmal eher ungünstig in bezug auf Security ist, das würde ich ja auch nicht bestreiten.

Klar kann man die unterschiedlichen Paketmanager kritisch sehen, aber andererseits fördert es in gewisser Weise den Wettbewerb untereinander es besser zu machen. Und Vielfalt ist ja nichts schlechtes.

Sehe ich im Grundsatz auch so. Aber irgendwann sollte man sich mal auf gewisse Dinge einigen, wenn man merkt, man hat da eigentlich ne gute technische Lösung gefunden. Das heißt ja dann auch nicht, das es alle so machen müssen. Aber unnötigerweise vom anderen abweichen, obwohl man nix besser macht ist doof, weils halt Aufwand bedeutet.
In anderen Bereichen gibt es das ja auch. Schlicht und ergreifend der Umstand, das wir ein Linux-Kernel benutzen und nicht jeder irgendwie seinen eigenen Kernel rein packt (höchstens Variationen davon mit Patches; aber im Grunde ändert sich da nix). Oder das wir CUPS als Drucksystemstandard haben (auch das ist ja nicht durchgehend so, aber +90% aller Distributionen nehmen das halt). usw.
Im Desktop-Bereich gibts das ja auch. Die Standards von freedesktop.org beispielsweise.

Und das war ja mein Punkt. Es geht mir ja nicht darum, Vielfalt wegzunehmen. Es geht mir darum da wo letztlich eh alle das Gleiche machen, das man sich dann auch auf was einigt.

Ich sehe also kein Chaos unter Manjaro. Und wenn ich Ubuntu nutze sehe ich auch kein Chaos.

Ja. Das war aber nicht das, was ich meinte. Und ich dachte, das hatte ich deutlich gemacht.

Windows hat allerdings das Problem das man im laufenden Betrieb keine *.so bzw. *.dll austauschen kann.

Kann man schon. Das Problem hängt nicht an irgendwelchen Dateiendungen, sondern das Windows ein exclusive-lock kennt. Das heißt, ein Prozess kann quasi eine Datei sperren. Deshalb auch das eigentliche Update nach Neustart, weil da keine (bzw. kaum) Prozesse da sind, die die betreffende Datei sperren könnten.

Noch eine ergänzende Bemerkung dazu:
Unter UNIX/Linux gibts diesen Mechanismus so nicht. Dort arbeitet man gerne mit Lock-Dateien, die sozusagen eine Markierung darstellen. Diese Lösung hat natürlich auch ihre Probleme, weil es kein Enforcement gibt, sondern es lediglich Konvention. Außerdem ist es ein Problem, das man diese Lock-Dateien verwalten muss, damit sie einem nicht versehentlich im Weg stehen (z.B. wenn wegen eines Programmabsturz' die Lockdateien nicht weggeräumt werden können).

Beides hat halt so seine spezifischen Vor- und Nachteile.

Linux unterscheidet in Groß und Kleinschreibung, Windows nicht.
Außerdem ist Linux wesentlich flexibler bei Sonderzeichen in Dateinamen.

Das hängt aber auch ein bisschen vom verwendeten Dateisystem ab. FAT z.B. kennt keine Groß-/Kleinschreibung. Wenn Du also unter Linux ein FAT-System mountest, kannst Du nicht die Dateien "TEST" und "TeST" anlegen, wie Du es beispielsweise unter ext4 kannst.

Teilweise kannst Du das Handling auch durch Mountoptionen beeinflussen, wie z.B. bei NTFS.

Auch bei Nicht-Windows-Dateisystemen wie z.B. ZFS kannst Du das Verhalten konfigurieren.

 

[mike78sbg]

Und das war ja mein Punkt. Es geht mir ja nicht darum, Vielfalt wegzunehmen. Es geht mir darum da wo letztlich eh alle das Gleiche machen, das man sich dann auch auf was einigt.

Klar wäre ein Paketmanager besser. Und aus Sicht eines SW-Entwicklers ist es eher mühsam für untersch. Distrus zu paketieren.

Aber im Gegensatz zu den Anfangszeiten hat man das heute schon sehr gut im Griff. Und da wird sich auch nichts mehr ändern.
Für mich als User hingehen spielt es keine Rolle.

Das hängt aber auch ein bisschen vom verwendeten Dateisystem ab. FAT z.B. kennt keine Groß-/Kleinschreibung. Wenn Du also unter Linux ein FAT-System mountest, kannst Du nicht die Dateien "TEST" und "TeST" anlegen, wie Du es beispielsweise unter ext4 kannst.

Ja, ist schon richtig. Per default, vermutlich auch historisch, ist Windows aber nicht case Sensitive.
Und wer nutzt heutzutage noch ernsthaft Fat32, außer auf nem USB Stick oder ähnlichem?

Und was Sonderzeichen betrifft, ist Linux ebenfalls wesentlich flexibler.
Geht das unter Windows als Filename: "T*est(⁄.txt".
Sonderzeichen können manchmal doch ganz praktisch sein.

 

[andy_m4]

Aber im Gegensatz zu den Anfangszeiten hat man das heute schon sehr gut im Griff. Und da wird sich auch nichts mehr ändern.

Du meinst, die progressive Linux-Community die Windows immer vorgeworfen hat, das die nicht in der Lage sind alte Zöpfe abzuschneiden hängt an alten Zöpfen? :-)

Und wer nutzt heutzutage noch ernsthaft Fat32, außer auf nem USB Stick oder ähnlichem?

Danke das Du die praxisrelevanten Beispiele gleich mitlieferst. :-)

Ansonsten:
Das mit der Case-In-sensitivität ist ja nicht grundsätzlich was Schlechtes. Ich finde es gar nicht so verkehrt, wenn sich in einem Verzeichnis in dem eine Datei "test.txt" nicht einfach noch eine Datei "teSt.txt" anlegen lässt, weil in 99% der Fälle wo ich das will, wird es sich um ein Versehen handeln. So wie es Windows (bei vFAT und NTFS) handhabt, das man zwar Groß- und Kleinbuchstaben verwenden kann und der Dateiname auch so ausgegeben wird, wie ich ihn gespeichert hab (also "Test.txt" bleibt so und wird nicht zu "test.txt " oder "TEST.TXT"), finde ich erst mal grundsätzlich als Vorgehensweise keinen schlechten Kompromiss.
Von mir aus kann man das ja noch konfigurierbar machen (wie z.B. bei dem genannten ZFS aber auch NTFS), damit auch die Leute abgeholt werden die partout strenge Case-Sensititivät haben wollen.

Und was Sonderzeichen betrifft, ist Linux ebenfalls wesentlich flexibler.
...
Sonderzeichen können manchmal doch ganz praktisch sein.

Ich würde das jetzt aber auch nicht überdramatisieren. Bestimmte Sonderzeichen wie * oder | sind schlicht verboten, weil sie auch noch andere Bedeutungen innerhalb der Shell haben.
Und es ist ja in der Praxis schon an einfacherer Stelle ein Problem. Ich glaub jeder Linux-Admin ist schon mal sein Bash-Skript um die Ohren geflogen weil da ein Leerzeichen im Dateinamen war.
Klar kann man durch richtiges "quoten" mit solchen Problemen umgehen. Aber Du schaffst Dir halt potentielle Stolpersteine.
Möchte nicht wissen, wie viele Programme man durch entsprechende Wahl eines Dateinamens durcheinander bringen kann.
Und das alles nehme ich in Kauf, damit ich irgendwie auch ein Sternchen im Dateinamen packen kann. Gut. Mache ich nie, aber ich möchte es wenigstens machen können oder wie? :-)

Wobei Sternchen ich sogar noch einsehe. Wegen gendern und so. :-)

 

[foofoobar]

Was willst Du genau wissen?
Die sichere Alternative hatte ich genannt.

Kann doas folgende Regel?
User A soll eine beliebige Datei als User B in ein in der Regel festgelegtes Zielverzeichnis kopieren können?
Mal die üblichen Probleme mit "..", Quouting, Dateinamen die mit "-" anfangen, usw. außen vor gelassen.

Kopieren kann man beispielsweise damit optimieren, das man nicht kopiert. Wenn es sich z.B. um Readonly-Memory-Pages handelt gibt es ja keinen Grund die zu kopieren, sondern man kann sie einfach im Addressraum des entsprechenden Prozesses einblenden.
Ich will jetzt hier aber keinen Vortrag zu Mikrokernel-Optimierungen machen, weil es dazu viel Material im Internet gibt.
Mal abgesehen davon, das Du viel von mir zitierst aber dann überhaupt nicht darauf eingehst.
Wäre schön, wenn man mal vernünftig miteinander redet und nicht nur versucht irgendwie destruktiv reinzugrätschen.

Probleme zu benennen ist alles andere als destruktiv.

Read-only Pages lösen nicht das Problem, wenn der Erzeuger korrupte Daten (Pointer in die Botanik, fehlende abschließende Bytes mit 0) erzeugt jagt dieser den Konsumer gleich mit in den Absturz. Ggf.brauchen Erzeuger und Empfänger auch eine Synchronisierung.
Wenn man nur serialisierte Daten reinlegt kann man das verhindern allerdings bekommt man dann wieder einen quasi memcpy().

Kann man schon. Das Problem hängt nicht an irgendwelchen Dateiendungen, sondern das Windows ein exclusive-lock kennt. Das heißt, ein Prozess kann quasi eine Datei sperren. Deshalb auch das eigentliche Update nach Neustart, weil da keine (bzw. kaum) Prozesse da sind, die die betreffende Datei sperren könnten.

Noch eine ergänzende Bemerkung dazu:
Unter UNIX/Linux gibts diesen Mechanismus so nicht. Dort arbeitet man gerne mit Lock-Dateien, die sozusagen eine Markierung darstellen. Diese Lösung hat natürlich auch ihre Probleme, weil es kein Enforcement gibt, sondern es lediglich Konvention. Außerdem ist es ein Problem, das man diese Lock-Dateien verwalten muss, damit sie einem nicht versehentlich im Weg stehen (z.B. wenn wegen eines Programmabsturz' die Lockdateien nicht weggeräumt werden können).

Die Lösung unter Unix sind inodes ohne Directoryeintrag, deswegen gibt es die Symlinks unter /lib schon ewig und 3 Tage.
Und seit ein paar Jahren gibt es einen Systemcall der die Inode für einen Directoryeintrag atomar austauschen kann.

Das Konzept der Inodes gibt es unter Windows nicht oder wurde nur halbherzig umgesetzt.