Das deutsche Python-Forum

Also mal eine kleine Geschichte aus dem Leben:

meinem Vater gehört eine mittlere Arztpraxis. Ich glaube seit 1992 oder so. Zu dieser Zeit wurde da auch ein Computersystem angeschaft. Zu jener Zeit wohl ungefähr das übliche. Als Server ein 386 und an den Arbeitsplätzen eine art Slim-Client (so eine Art Monitor mit Bildspeicher, also kein eigenere Rechner). Das ganze lief unter Unix und alle waren zufrieden. Die software war einfach aber zweckmäßig, und alles war über shortcuts zu bedienen und wer diese vieleicht 20 an der Zahl kannte, war damit auch noch ungeheuer schnell. Für das System gab es regelmäßige Softwareupdates (was an Arztsoftware so ziemlich das wichtigeste ist, da sich die richtlinien ständig ändern). Die Hardware machte eigentlich auch keine Probleme, sowas wie einen CPU Lüfter gabs zu der zeit ja noch garnicht.
Aber irgendwann letzes Jahr hat der Softwarehersteller beschlossen, dass es in Zukunft keine Updates für das Unix System gibt. Also die einzige Lösung: Auf Windows migrieren. Nun denn... erst mal einen richtig schnellen Rechner... so 2,5 Ghz und 512 Ram damit das Arbeiten auch richtig spaß macht.

Doch als dann alles installiert ist, stellt man als erstes fest, wie schwierig GUIs zu bedienen sein können.

Früher hies es: drücken sind F1, dann F7, geben sie die daten ein und bestätigen sie mit Enter. Heute ist kämpft man mit den Tücken der GUIs, sucht Minutenlang nach Schaltflächen und erreicht doch das gleiche.

Doch dann stellt man auch noch fest: Das System ist nicht unbedingt schneller.
Tja, das GUI ist mit Visual Basic gemacht, die Datenbank mit FoxPro und als Textverarbeitung hat man Microsoft Office eingebunden, und das zu starten dauert erst mal.

Was ich damit sagen will: Schnellere Computer führen eigentlich nur zu fauleren Programmieren. Die aussage ist: das Programm läuft doch garnicht mal langsam - wenn man min 3Ghz hat.

sonium hat geschrieben:Also mal eine kleine Geschichte aus dem Leben:

meinem Vater gehört eine mittlere Arztpraxis. Ich glaube seit 1992 oder so. Zu dieser Zeit wurde da auch ein Computersystem angeschaft. Zu jener Zeit wohl ungefähr das übliche. Als Server ein 386 und an den Arbeitsplätzen eine art Slim-Client (so eine Art Monitor mit Bildspeicher, also kein eigenere Rechner). Das ganze lief unter Unix und alle waren zufrieden. Die software war einfach aber zweckmäßig, und alles war über shortcuts zu bedienen und wer diese vieleicht 20 an der Zahl kannte, war damit auch noch ungeheuer schnell. Für das System gab es regelmäßige Softwareupdates (was an Arztsoftware so ziemlich das wichtigeste ist, da sich die richtlinien ständig ändern). Die Hardware machte eigentlich auch keine Probleme, sowas wie einen CPU Lüfter gabs zu der zeit ja noch garnicht.
Aber irgendwann letzes Jahr hat der Softwarehersteller beschlossen, dass es in Zukunft keine Updates für das Unix System gibt. Also die einzige Lösung: Auf Windows migrieren. Nun denn... erst mal einen richtig schnellen Rechner... so 2,5 Ghz und 512 Ram damit das Arbeiten auch richtig spaß macht.

Doch als dann alles installiert ist, stellt man als erstes fest, wie schwierig GUIs zu bedienen sein können.

Früher hies es: drücken sind F1, dann F7, geben sie die daten ein und bestätigen sie mit Enter. Heute ist kämpft man mit den Tücken der GUIs, sucht Minutenlang nach Schaltflächen und erreicht doch das gleiche.

Doch dann stellt man auch noch fest: Das System ist nicht unbedingt schneller.
Tja, das GUI ist mit Visual Basic gemacht, die Datenbank mit FoxPro und als Textverarbeitung hat man Microsoft Office eingebunden, und das zu starten dauert erst mal.

Was ich damit sagen will: Schnellere Computer führen eigentlich nur zu fauleren Programmieren. Die aussage ist: das Programm läuft doch garnicht mal langsam - wenn man min 3Ghz hat.

Ja, ist schon erstaunlich, wie langsam Software auf aktueller
Hardware läuft. Daß man auf einer 2-GHz-Maschine mit 512MB RAM
immer noch Verzögerungen merkt, bis ein Menü mit seinen paar
Pixels herunterklappt...

Meiner Ansicht nach gehören Betriebssysteme -- wohl mit die
größten Performancefresser -- sowieso auf lange Sicht gesehen
der Vergangenheit an.
Es ist doch längst machbar, daß die einzelnen Hardware-Baugruppen
eines PCs ihre
Treiber selbst speichern und gelegentlich mit updates aus
dem Internet aktualisieren. Sind die Treiber dann eine
Angelegenheit der Hardware, fielen fast alle Aufgaben, die heute
noch von Betriebssystemen erledigt werden, weg.

Übrig bliebe lediglich der Bedarf nach einer Benutzeroberfläche,
die es ermöglicht, Programme im Multitasking zu starten/stoppen und
die I/O (Maus, Keyboard, Grafik) an die entsprechenden Fenster zu leiten.
Ein kleines Progrämmchen also, das vielleicht auf eine Floppy-Disk
passen würde anstelle von Schubern mit 10 CDs und Anleitungen,
die dicker als das Telefonbuch von London sind.

Damit wäre das Problem des immer weiter steigenden
Performance-Bedarfs doch gelöst, Betriebssysteme wären (bis auf einen simplen Fenstermanager) obsolet,
Computer wären wieder so schnell wie die Programme, die gerade
laufen, das DLL-Problem wäre gelöst, Computer wären billiger, jede Software würde zu jedem System kompatibel sein (Betriebssysteme sind
ja heute die Haupt-Kompatibilitätsbremse) und alle wären glücklich und zufrieden.

Ach, wär das schön.

Irgendwie vermisse ich in Deiner Beschreibung, dass so ein Betriebssystem dazu da ist den Überblick über all die Hardware und ihre Treiber zu behalten. Caches müssen verwaltet werden, Speicher geschützt, Prozesse und Threads auf Prozessoren verteilt werden, und so weiter.

Und dynamisch ladbare Bibliotheken abschaffen, bedeutet grössere Programme.

Hallo

ganz einfach: so wie jede Hardware-Baugruppe hat natürlich
auch das Mainboard einen Treiber, der von diesem selbst
verwaltet und in zB. einem EEPROM gespeichert wird.
Dieser Mainboard-Treiber verwaltet natürlich die Chips und
Anschlüsse, die auf dem Mainboard eingelötet sind, also
IDE, ATAPI, USB, evtl. onboard-Sound usw....

Betriebssysteme sind ja eine Erfindung der 50er Jahre,
damals hatte man Bitschalter als Input und Fernschreiber
oder Lochstreifen als Ausgabe - da brauchte man natürlich
ein Betriebssystem, um die "dumme" Hardware zu verwalten.
Aber heute ? Jedes CD-Drive hat viele KBytes an Firmware
eingebaut, da ist also auch noch Platz für einen Treiber.

Es bliebe lediglich noch ein Fenstermanager übrig - und
einen einfachen Fenstermanager könnte man auch als
EEPROM in die Grafikkarte integrieren. Dann bliebe
von den riesigen Performance-verschlingenden heutigen
BS-Monstern nichts mehr übrig. So wie einst von den
alles beherrschenden Dinosaurieren, den heutigen Vögeln.

Betriebssysteme lösen ja vorwiegend Probleme, die
es ohne sie gar nicht gäbe. Auch eine Methode, eine
Industrie lebendig zu halten.

Grüße

(unintent'ly left blank) hat geschrieben:Es bliebe lediglich noch ein Fenstermanager übrig - und einen einfachen Fenstermanager könnte man auch als
EEPROM in die Grafikkarte integrieren. Dann bliebe von den riesigen Performance-verschlingenden heutigen BS-Monstern nichts mehr übrig. So wie einst von den alles beherrschenden Dinosaurieren, den heutigen Vögeln.

Und alle müssen das dann nutzen, egal ob sie es mögen oder nicht?

Schon mal ein altes AMI-BIOS gesehen? Das hat Maussupport und richtige, Win 3.1 ähnliche s/w-Fenster. Das erste mal habe ich recht blöd geguckt als das gestartet hat.

Leonidas hat geschrieben:

(unintent'ly left blank) hat geschrieben:Es bliebe lediglich noch ein Fenstermanager übrig - und einen einfachen Fenstermanager könnte man auch als
EEPROM in die Grafikkarte integrieren. Dann bliebe von den riesigen Performance-verschlingenden heutigen BS-Monstern nichts mehr übrig. So wie einst von den alles beherrschenden Dinosaurieren, den heutigen Vögeln.

Und alle müssen das dann nutzen, egal ob sie es mögen oder nicht?

Schon mal ein altes AMI-BIOS gesehen? Das hat Maussupport und richtige, Win 3.1 ähnliche s/w-Fenster. Das erste mal habe ich recht blöd geguckt als das gestartet hat.

Das Ding, was bei mir nie funktioniert hat? Ich war so sauer, weil meine Maus nicht wollte. Da hatte ich so ein tolles BIOS aber nichts ging

Leonidas hat geschrieben: Und alle müssen das dann nutzen, egal ob sie es mögen oder nicht?

Dürfen, nicht müssen. Ich denke, die Vorteile sollten überzeugend
genug sein, um auf Betriebssysteme, wie sie bei einer PDP-11 vor
40 Jahren mal nötig waren, weil ein Lochstreifenstanzer einfach
nicht intelligent genug ist, um seinen Treiber selbst zu verwalten,
heutzutage zu verzichten.

*n*x, L*n*x, w*n*o*s und wie sie alle heißen: eigentlich schlichtweg überflüssig, wenn man die Sache mal von Grund auf neu durchdenkt und
Hardware bauen würde, deren Eigenintelligenz die schon heute
vorhandenen technischen Möglichkeiten nutzen würde.

(unintent'ly left blank) hat geschrieben:*n*x, L*n*x, w*n*o*s und wie sie alle heißen: eigentlich schlichtweg überflüssig, wenn man die Sache mal von Grund auf neu durchdenkt und
Hardware bauen würde, deren Eigenintelligenz die schon heute
vorhandenen technischen Möglichkeiten nutzen würde.

Hallo,

deine Utopie hat viele gewaltige Haken. Somit wär jeder gezwungen das zu betreiben, was der Hardwarehersteller vorgibt und die Wahl (auf Userebene) wäre völlig dahin. Wenn jeder das haben wollen würde, was einem vorgegeben wird, dann gäbe es kein Linux, BSD, Unix, Windows usw..
Nicht zu vergessen, dass es dafür auch einen Standard geben müsste. Da würde jeder Hersteller sein eigenes Süppchen kochen. Da sich das aber wirtschaftlich nie durchsetzen kann, wird deine Vorstellung auf ewig eine Utopie bleiben.

Gruß
ello

Treiber für RAM-Chips in RAM-Chips!?

Und zu dieser komischen Aussage das Betriebssysteme der Grund für Inkompatibilitäten sind: Nur durch ein halbwegs POSIX-kompatibles Betriebssystem + C-Compiler mit Standard-Bibliothek ist es überhaupt möglich portable Programme zu schreiben.

Ich sehe auch nicht wie man das Betriebssystem loswerden kann wenn man "Treiber" in Geräte einbaut. Irgendwas muss mit diesen "Treibern" doch kommunizieren. Und für diese Schnittstelle braucht man dann einen Treiber. Treiber um "Treiber" anzusprechen. Häh?

Das Betriebssystem ist dazu da um die Mittel die ein Rechner zur Verfügung stellt zu verwalten, z.B. RAM, Hintergrundspeicher, Prozessorzeit, Netzwerk, Drucker etc.

Wer sollte denn Deiner Meinung nach den Speicher und die Prozessorzeit verwalten, wenn nicht ein Betriebssystem? Oder mal ganz konkret: Wie komme ich ohne Treiber auf Daten einer Festplatte? Und wie kann ich verschiedene Dateisysteme darauf anlegen und verwalten? Wo steckt diese "Intelligenz"?

Und GUI ist nicht die Aufgabe eines Betriebssystems. Das kann prima als Benutzerprogramm laufen, oder auch gar nicht, z.B. auf Servern.

BlackJack hat geschrieben:Treiber für RAM-Chips in RAM-Chips!?

Und zu dieser komischen Aussage das Betriebssysteme der Grund für Inkompatibilitäten sind: Nur durch ein halbwegs POSIX-kompatibles Betriebssystem + C-Compiler mit Standard-Bibliothek ist es überhaupt möglich portable Programme zu schreiben.

Ich sehe auch nicht wie man das Betriebssystem loswerden kann wenn man "Treiber" in Geräte einbaut. Irgendwas muss mit diesen "Treibern" doch kommunizieren. Und für diese Schnittstelle braucht man dann einen Treiber. Treiber um "Treiber" anzusprechen. Häh?

Das Betriebssystem ist dazu da um die Mittel die ein Rechner zur Verfügung stellt zu verwalten, z.B. RAM, Hintergrundspeicher, Prozessorzeit, Netzwerk, Drucker etc.

Wer sollte denn Deiner Meinung nach den Speicher und die Prozessorzeit verwalten, wenn nicht ein Betriebssystem? Oder mal ganz konkret: Wie komme ich ohne Treiber auf Daten einer Festplatte? Und wie kann ich verschiedene Dateisysteme darauf anlegen und verwalten? Wo steckt diese "Intelligenz"?

Und GUI ist nicht die Aufgabe eines Betriebssystems. Das kann prima als Benutzerprogramm laufen, oder auch gar nicht, z.B. auf Servern.

Hallo

"was heute noch unmöglich scheint wird morgen schon Alltag sein", hieß es
doch vor Jahrzehnten mal in einer TV-Serie. Das gilt auch für Computer.
Computer werden erst dann wirklich connectible sein, wenn die
Hardware ihre eigenen Treiber speichert und verwaltet - solange der PC
die Treiber zentral verwaltet, wird sich nie ein unbekanntes oder
neues Gerät A an einen PC B anschließen lassen.

Die Kommunikation muß über *standardisierte* Befehlssätze erfolgen,
d.h. statt daß das Anwenderprogramm eine BS-Funktion, diese
dann den Treiber oder das BIOS und das BIOS letztendlich die
Hardware anspricht, gibt das Anwenderprogramm direkt den
High-level-Befehl open("testdatei.abc") an's Mainboard, das
Mainboard sucht die passende Festplatte E: und schickt an
IDE-Port "E:" den Befehl open("E:testdatei") - nur mal als Beispiel.
Ist technisch alles kein Problem, schon heute nicht.

Speicher und Prozessorzeit werden vom Mainboard-Treiber verwaltet;
das Anwenderprogramm schickt ans Mainboard den Befehl
new_process(...), das Mainboard fügt dann einen neuen Prozess in
die Prozeß-Liste für die CPU ein und der CPU-Treiber arbeitet die Schedule
dann zeitscheibenweise oder parallel ab. Geht alles, man muß nur von Grund auf neu auf die Sache blicken.
Dateisysteme kann die HD auch selbst verwalten, da hat die CPU
gar nichts mit zu tun. (Das konnte die Commodore-64-Floppy schon
vor 25 Jahren)

Der Grund, warum OS so viel Zeit, Resourcen und Inkompatibilität
kosten, ist wahrscheinlich einfach der: sie sind heute überflüssig.
Wie der Blinddarm. Der war vor 10000 Jahren auch mal nötig, heute
ist er überflüssig und macht im Zweifelsfalle Ärger.

Und das Problem, daß man dann ja nicht mehr zwischen
w*n*o*s und l*n*x (dieses Wildcard Theater nervt langsam...auch
ein Zeichen, daß da was überflüssig ist)
wählen kann, erledigt
sich von selbst - wenn Du kein OS mehr brauchst, ist die Wahl
desselben obsolet. Es ist so einfach, daß niemand außer mir
darauf zu kommen scheint. Dennoch ist das die plausibelste Lösung
für diese Realsatire.

Immer noch unklar ? Dann stellle Dir mal vor, ein Haushalt wäre
so organisiert wie ein heutiger PC:
In der Küche steht ein Kühlschrank. Dessen Temperaturregelung
(BIOS-Funktion)
wäre aber nicht etwa im Kühlschrank selbst eingebaut, sondern in
einem Zentralrechner irgendwo in der Abstellkammer.
Willst Du nun den Kühlschrank durch ein anderes Fabrikat
ersetzen, hast Du Kompatibilitätsprobleme.

Zum Glück ist die Temperaturregelung des Kühlschranks heute
im Kühlschrank selbst eingebaut, sodaß man jedes Fabrikat
in jedem Haushalt einsetzen kann.
Und genauso sollte (und wird) es auch mit PCs sein - die
Steuersoftware der Harddisk (inkl. Dateisystem) muß komplett
in der Harddisk enthalten sein, und weder auf dem Mainboard
noch im BIOS noch gar im OS verstreut sein. Dann kann man jede beliebige HD mit jedem beliebigen Mainboard ansprechen, an- und abstöpseln
usw. Die Harddisk an sich muß dann nur noch mit High-Level-Befehlen
wie "list_dir", "open file(...)" ... angesprochen werden - und zwar
vom Anwenderprogramm oder Fenstermanager aus, nicht vom
OS. Das OS ist dann überflüssig.

Obwohl das alles technisch machbar ist (mit EEPROMs oder Flash-Bausteinen, die die notwendige Software im Gerät selbst
speichern), ist wohl noch ein langer Weg dahin, aber langfristig
wird es keine Alternative geben. Die Situation mit heutigen
OS (Inkompatibilität, Nicht-Konnektivität, nahezu null intuitive Bedienbarkeit, gigantischer Resourcenbedarf, Sicherheitsprobleme,...)
zeigt, daß hier ein ganz grundsätzliches Problem vorliegt, dessen
einfachste Lösung darin besteht, das OS einfach wegzulassen.

Das wäre ein wahrhaft objektorientierter Ansatz: alle Steuersoftware wird da
gespeichert wo sie hingehört, und nicht über BIOS, OS, Treiber
verstreut.

(unint'lly left blank) hat geschrieben:Dessen Temperaturregelung
(BIOS-Funktion)
wäre aber nicht etwa im Kühlschrank selbst eingebaut, sondern in
einem Zentralrechner irgendwo in der Abstellkammer.

Nein, das wäre eine Firmwarefunktion.

Und genauso sollte (und wird) es auch mit PCs sein - die
Steuersoftware der Harddisk (inkl. Dateisystem) muß komplett
in der Harddisk enthalten sein

Ist sie auch. Das "Dateisystem" sind die Sektoren, und ansprechen kannst du sie mit ATA Befehlen. Nur ist dies umständlich, und Programme, die ATA Befehle senden, würden bei einer SATA oder SCSI-Platte schon nicht mehr laufen. Deshalb gibt es das Betriebssystem, das ein portables Interface bereitstellt.

Dann kann man jede beliebige HD mit jedem beliebigen Mainboard ansprechen, an- und abstöpseln

Jede beliebige ATA Platte... siehe oben.

usw. Die Harddisk an sich muß dann nur noch mit High-Level-Befehlen
wie "list_dir", "open file(...)" ... angesprochen werden - und zwar
vom Anwenderprogramm oder Fenstermanager aus, nicht vom
OS. Das OS ist dann überflüssig.

Und was ist, wenn das Dateisystem nicht mit großen Dateien auskommt? Oder nicht für Datenbanken optimiert ist? Oder keine Links kann?

Obwohl das alles technisch machbar ist (mit EEPROMs oder Flash-Bausteinen, die die notwendige Software im Gerät selbst
speichern),[...]
Das wäre ein wahrhaft objektorientierter Ansatz: alle Steuersoftware wird dagespeichert wo sie hingehört, und nicht über BIOS, OS, Treiber
verstreut.

Siehe oben: gibt es, heißt Firmware.

Nochmal, BS sind sozusagen die Bürokratie, die dafür sorgt, dass alles (im Idealfall) reibungslos läuft und zusammenarbeitet.

Du hättest trotzdem ein Betriebsystem. Der Kernel ist bei Dir im Mainboard und die Treiber in den Geräten. Damit hast Du nichts gewonnen. Dir geht nur Flexibilität verloren.

Man kann auch heute schon in sinnvollen Grenzen einfach Geräte an den PC anstöpseln. Massenspeicher per USB oder eine LAN-Storage Lösung sind kein Problem. Für die meisten Schnittstellen gibt es Standardlösungen. VGA/VESA für Grafik, AC'97 für Sound, die ganzen USB Spezifikationen für EIngabegeräte und Massenspeicher usw.

Dateisysteme in die Platten einzubauen ist ziemlicher Unsinn. Da fällt die Wahl, je nach Einsatzzweck, völlig flach. Und Logical Volume Management in die Platten hineinverlegen ist auch ziemlicher Unsinn.

Der PC in seiner heutigen Form ist so verdammt erfolgreich, weil das Zusammenstellen von unterschiedlichen Hardwarekomponenten so unkompliziert geht, und weil es ein Betriebssystem gibt, das eine Abstraktionsschicht darüberlegt, damit auch die unterschiedlichsten Rechner für den Programmierer "gleich" aussehen.

Wo setzt Dein Rechner ohne BS an, wenn man gerne ein im Netz verteiltes, verschlüsseltes Dateisystem hätte? Das fällt weder in die Verantwortung der Festplatten noch der Netzwerkkarte. Dazu braucht man Software die "ausserhalb" steht und die einzelnen Komponenten sinnvoll verbindet.

BlackJack hat geschrieben:Du hättest trotzdem ein Betriebsystem. Der Kernel ist bei Dir im Mainboard und die Treiber in den Geräten. Damit hast Du nichts gewonnen.

Doch. Nämlich mindestens 3 überflüssige Hierarchie-Ebenen (OS, Treiber, BIOS) entfernt, zwischen Anwendung und Hardware. Dazu fällt der
größte Verursacher von Inkompatibilität und Sicherheitslücken weg
(das OS), Geräte werden mit meinem Konzept erstmals wirklich
Plug-and-Play-fähig. Und so soll's sein. Eine PC-Festplatte darf nicht
mehr Installations-Aufwand erfordern als das Anschließen eines
Kühlschranks, und das geht nur, wenn die Festplatte wie der Kühlschrank
seine Systemsoftware komplett an Bord hat.

>> Dir geht nur Flexibilität verloren.<<

Im Gegenteil: s.o.

>>Man kann auch heute schon in sinnvollen Grenzen einfach Geräte an den PC anstöpseln. Massenspeicher per USB<<

Stimmt. Du siehst also selbst: der Trend geht in die von mir skizzierte
Richtung.

>>Dateisysteme in die Platten einzubauen ist ziemlicher Unsinn.<<

Das ist genauso wie wenn Du sagst: Eine Temperatur-Regelungs-Software
in einen Kühlschrank einzubauen ist Unsinn, wir können doch den
Kühlschrank an einen externen Zentralrechner anschließen, der den
Kühlschrank ansteuert. Daß das auf unabsehbare Zeit nicht funktioniert, siehst Du am OS-Schlamassel der vergangenen zwei Jahrzehnte.

Im Gegenteil: eine Festplatte ohne eingebautes Dateisystem ist
kein vollständiges Gerät. Mit einem EEPROM für wenige cents könnte man
die Systemsoftware dahin bringen, wo sie eigentlich hingehört, in die
Geräte selbst.

>>Und Logical Volume Management in die Platten hineinverlegen ist auch ziemlicher Unsinn.<<

Genau. Für LVM ist nämlich das Gerät zuständig, das die Harddisk-Anschlüsse zu verwalten hat, also das Mainboard oder
der RAID-Adapter.

>>Der PC in seiner heutigen Form ist so verdammt erfolgreich, weil das Zusammenstellen von unterschiedlichen Hardwarekomponenten so unkompliziert geht, und weil es ein Betriebssystem gibt, das eine Abstraktionsschicht darüberlegt,<<

Nein, der PC ist so erfolgreich, weil die Hardware und viele
Anwendersoftware so verdammt gut ist und immer besser wird.
Das OS ist eher ein Hemmschuh, der für Inkompatibilität (siehe
w*n*o*s vs. *n*x), Mehraufwand (siehe Treiber-Verwaltung, DLL-Problem),
Sicherheitslücken, Performance-Verschwendung sorgt.

>>damit auch die unterschiedlichsten Rechner für den Programmierer "gleich" aussehen.<<

Dafür braucht man kein OS, lediglich eine standardisierte Funktionsaufrufe-Syntax.

>>Wo setzt Dein Rechner ohne BS an, wenn man gerne ein im Netz verteiltes, verschlüsseltes Dateisystem hätte?<<

Das ginge genauso gut wie es mit heutigen PCs geht. Nur die
Treiber-Software sitzt dann dezentral. Letztendlich braucht man dazu
nicht mal einen PC, eine Anzahl Festplatten im eigenen Gehäuse mit
jeweils einem Netzwerk-Anschluß könnte das schon bewerkstelligen,
dazu eine Verteiler-Box am Netz, die zur Konfiguration da ist.

Weißt Du, welche CPU in Deinem Autoradio steckt ? Na eben. Der heutige
PC zwingt einen dagegen ständig, sich mit Dingen zu befassen, die
den Anwender eigentlich gar nichts anzugehen brauchen.
Das wird nachhaltig verbessert, wenn auch die Hardware objektorientiert
wird in dem Sinne, daß jede (Steuer-)Software da gespeichert und
verwaltet wird, wo sie gebraucht wird und nicht über's ganze System
verstreut ein unwartbares Chaos aus Treibern, DLLs, BIOS und OS
bildet.

Nichts für ungut aber deine Idee ist in meinen Augen schwachsinn und wird nie realität sein!!!

Schon gar nicht weil microsoft sich dagegen wehren würde keine betriebssysteme mehr zu verwenden.Da würden ja milliarde verloren gehen

Ich denke der PC ist nur so erfolgreich, weil es billig ist. Das die Hardware kompatibel ist, ist dafür zwingend notwendig, damit man über die Masse den Preis drücken kann...
Man kann auch sehen, das exotische Hardware wie z.B. SCSII Platten <-> normale IDE Platten, unverhältnissmäßig teuer ist.

Der Vergleich mit dem Autoradio hinkt einwenig. Denn in bin mir ziemlich sicher, das dort, auch eine Art Betriebssystem drauf ist.

Was vielleicht noch am nächsten an die Vorstellung rankommt, sind die Pläne vom vernetzten Haus, bzw. die Home-Cinema-Streaming-MP3-überall-guck-Pläne... Da gab es mal in der c't ein Artikel drüber. Ein Standard für Netzwerkgeräte (HDD-Netz-Storage, Streaming-Clients usw.) die alle miteinander kommunizieren sollen...

Das ein kompletter PC so aufgebaut werden soll/kann, halte ich auch nicht wirklich für denkbar... Zumal das auch nicht in die Struktur der PC-Industrie passt. Ich meine die Hardware Hersteller sind keine Software-Programmierer

Was vielleicht auch in die Richtung geht, sind Drucker, an die man direkt eine Digi.Cam anschließen, Bilder auswählen und direkt drucken kann ohne Rechner...

Das das Betriebssystem vollkommen weg fällt, glaube ich nicht. Allerdings ist es schon interessant. Warum nicht in der Grafikkarte quasi direkt die Treiber implementieren und die geschaffene Schnittstelle direkt mit Linux/Windows nutzen???

Warum das nie gehen wird, wird wohl daran liegen, weil die Industrie sich einfach nicht auf Standards einigen kann... Das sah man bei BetaMAX vs. VHS oder bei DVD-R vs. DVD+R und das sieht man nun wieder an Blueray <-> DVD-HD...

(unintent'lly left blank) hat geschrieben:

BlackJack hat geschrieben:Du hättest trotzdem ein Betriebsystem. Der Kernel ist bei Dir im Mainboard und die Treiber in den Geräten. Damit hast Du nichts gewonnen.

Doch. Nämlich mindestens 3 überflüssige Hierarchie-Ebenen (OS, Treiber, BIOS) entfernt, zwischen Anwendung und Hardware. Dazu fällt der größte Verursacher von Inkompatibilität und Sicherheitslücken weg
(das OS),

Diese "überflüssigen" Ebenen stellen gerade die Kompatibilität sicher. Du verschiebst das OS nur auf's Mainboard und die Treiber in die Geräte. Und machst damit unter anderem alles aufwendiger und langsamer. Und alles muss Deinen Standardschnittstellen gehorchen, die es noch gar nicht gibt. Und zwar auf Hardware-Ebene! Solche Schnittstellen auf Softwareebene sind viel flexibler weil man so auch total unterschiedliche Hardware über die gleiche Schnittstelle zugänglich machen kann. Eben über einen Treiber.

Geräte werden mit meinem Konzept erstmals wirklich
Plug-and-Play-fähig. Und so soll's sein. Eine PC-Festplatte darf nicht
mehr Installations-Aufwand erfordern als das Anschließen eines
Kühlschranks, und das geht nur, wenn die Festplatte wie der Kühlschrank
seine Systemsoftware komplett an Bord hat.

Also meine letzte Festplatteninstallation sah so aus: Rechner auf, Platte eingeschraubt, hochgefahren, den Vorschlag vom BIOS (Plattengeometrie) abgenickt und fertig. Ich durfte dann Gott sei Dank noch selbst entscheiden welche Dateisysteme auf welchen Partitionen liegen. Oder ob ich eine grössere Partition "raw" der Datenbank auf dem Rechner zur Verfügung stelle. Und mit welchem Algorithmus die Datenpartition verschlüsselt werden soll.

>> Dir geht nur Flexibilität verloren.<<

Im Gegenteil: s.o.

Ich könnte nicht mehr auswählen welches Dateisystem meine Platte "spricht". Da alles fest "verdrahtet" ist, müsste ich wahrscheinlich das mit eingebautem DRM nehmen was die Filmindustrie dann durchgedrückt hat. Sehr flexibel!

>>Man kann auch heute schon in sinnvollen Grenzen einfach Geräte an den PC anstöpseln. Massenspeicher per USB<<

Stimmt. Du siehst also selbst: der Trend geht in die von mir skizzierte
Richtung.

Standardisierte Treiberschnittstellen!? Dagegen sage ich ja nichts. Letztendlich ist das aber auch nicht mehr als der IDE Befehlssatz bietet.

>>Dateisysteme in die Platten einzubauen ist ziemlicher Unsinn.<<

Das ist genauso wie wenn Du sagst: Eine Temperatur-Regelungs-Software
in einen Kühlschrank einzubauen ist Unsinn, wir können doch den
Kühlschrank an einen externen Zentralrechner anschließen, der den
Kühlschrank ansteuert. Daß das auf unabsehbare Zeit nicht funktioniert, siehst Du am OS-Schlamassel der vergangenen zwei Jahrzehnte.

Du willst die Temperaturregelung eines Kühlschraks mit Dateisystemen vergleichen!? Nicht Dein Ernst, oder? Dateisysteme sind ein ganz klein wenig komplexer und man hat viel mehr Auswahl und Einstellungsmöglichkeiten. Versuch mal den Code für ein ordentliches Dateisystem auf der Hardware eines Kühlschranks unterzubringen. Wenn überhaupt ein Mikrokontroller mit vielleicht einem Megahertz und 256 Bytes RAM.

Im Gegenteil: eine Festplatte ohne eingebautes Dateisystem ist
kein vollständiges Gerät. Mit einem EEPROM für wenige cents könnte man
die Systemsoftware dahin bringen, wo sie eigentlich hingehört, in die
Geräte selbst.

Womit sie dann ziemlich unflexibel wäre, weil fest eingebaut. Zur Laufzeit müsste man die Software dann von dort in den Hauptspeicher kopieren. Damit hättest Du einen ladbaren Treiber der nicht von der Platte sondern aus dem Gerät kommt. Ich sehe den Gewinn nicht.

>>Und Logical Volume Management in die Platten hineinverlegen ist auch ziemlicher Unsinn.<<

Genau. Für LVM ist nämlich das Gerät zuständig, das die Harddisk-Anschlüsse zu verwalten hat, also das Mainboard oder
der RAID-Adapter.

Das heisst ich bräuchte dafür extra Hardware? Und Dir ist schon klar, das ich bei LVM auch beliebigen Code zusammenstecken kann, der zwischen Blockanfordern und dem realen physischen Speicher liegt und zum Beispiel das Verteilen über's Netzwerk, Verschlüsseln, (Ent)Kompromieren etc. übernehmen kann!? Wo soll denn so ein Code stecken und wie willst Du den so flexibel machen? Es gibt mehr Anwendungsfälle als Du Dir ausdenken kannst.

Es gibt einen Treiber, der das Google-Mail-Postfach als Dateisystem zur Verfügung stellt. Welches "Gerät" wäre dafür denn verantwortlich?

>>Der PC in seiner heutigen Form ist so verdammt erfolgreich, weil das Zusammenstellen von unterschiedlichen Hardwarekomponenten so unkompliziert geht, und weil es ein Betriebssystem gibt, das eine Abstraktionsschicht darüberlegt,<<

Nein, der PC ist so erfolgreich, weil die Hardware und viele
Anwendersoftware so verdammt gut ist und immer besser wird.
Das OS ist eher ein Hemmschuh, der für Inkompatibilität (siehe
w*n*o*s vs. *n*x), Mehraufwand (siehe Treiber-Verwaltung, DLL-Problem),
Sicherheitslücken, Performance-Verschwendung sorgt.

Gute Anwendungssoftware gab es für andere Rechnersysteme auch. Der PC hat sich wegen seiner Modularität durchgesetzt, weil damit jeder Steckkarten nach gewissen Spezifikationen herstellen konnte, die durch Konkurrenzdruck und Massenherstellung günstig sind. Wenn es nur auf Qualitativ gute Software und Hardware ankommen würde, dann hätte Apple ein besseres Standbein haben müssen.

>>damit auch die unterschiedlichsten Rechner für den Programmierer "gleich" aussehen.<<

Dafür braucht man kein OS, lediglich eine standardisierte Funktionsaufrufe-Syntax.

Die das BS zur Verfügung stellt. Genau dazu braucht man es.

>>Wo setzt Dein Rechner ohne BS an, wenn man gerne ein im Netz verteiltes, verschlüsseltes Dateisystem hätte?<<

Das ginge genauso gut wie es mit heutigen PCs geht. Nur die
Treiber-Software sitzt dann dezentral. Letztendlich braucht man dazu
nicht mal einen PC, eine Anzahl Festplatten im eigenen Gehäuse mit
jeweils einem Netzwerk-Anschluß könnte das schon bewerkstelligen,
dazu eine Verteiler-Box am Netz, die zur Konfiguration da ist.

Solche Boxen gibt es. Die laufen fast alle mit Linux. Du willst Hardware für Sachen einsetzen die viel günstiger und flexibler in Software lösbar sind.

Weißt Du, welche CPU in Deinem Autoradio steckt ? Na eben. Der heutige
PC zwingt einen dagegen ständig, sich mit Dingen zu befassen, die
den Anwender eigentlich gar nichts anzugehen brauchen.

Mal davon abgesehen, das ich kein Auto besitze, so ein Autoradio kann man sich nicht aus Einzelkomponenten zusammenstellen, da kommt alles aus einer Hand inklusive Software die drauf läuft. Selbst in solchen Geräten gibt es kleine Betriebssysteme.

Ein PC ist wesentlich komplexer und wird auch für viele, unterschiedliche Anwendungen eingesetzt.

Und was für ein Prozessor da drin werkelt ist mir auch fast egal solange es eine MMU und einen ISO-C Compiler gibt. Dann bekomme ich auch Linux oder *BSD drauf zum laufen.

Das wird nachhaltig verbessert, wenn auch die Hardware objektorientiert
wird in dem Sinne, daß jede (Steuer-)Software da gespeichert und
verwaltet wird, wo sie gebraucht wird und nicht über's ganze System
verstreut ein unwartbares Chaos aus Treibern, DLLs, BIOS und OS
bildet.

Ich sehe besagtes Chaos jetzt nicht so ganz. Kann es sein das Du da von einem bestimmten Betriebssystem redest? Probier mal MacOS, da bekommst Du abgestimmte Hard- und Software und eine schicke bedienerfreundliche Oberfläche.

Ich habe den Verdacht das Du wenig bis keine Ahnung vom Thema hast. Das fängt damit an, das Betriebssysteme eingeführt wurden, damit so etwas wie Mehrbenutzerbetrieb (damals noch im Stapelverarbeitungsmodus) möglich wurde. Die Anforderungen in diesem Bereich der Betriebsmittelverwaltung sind eher noch gestiegen, heute müssen in "Echtzeit" mehrere Programme auf verschiedene Prozessoren verteilt werden. Damit werden Betriebssysteme absolut nicht überflüssig. Du schlägst im Grunde bloss vor ein starres Einheitsbetriebssystem ins Mainboard zu "giessen".

jens hat geschrieben:Das das Betriebssystem vollkommen weg fällt, glaube ich nicht. Allerdings ist es schon interessant. Warum nicht in der Grafikkarte quasi direkt die Treiber implementieren und die geschaffene Schnittstelle direkt mit Linux/Windows nutzen???

Das geht per Definition nicht, da Treiber die Software darstellen, die zwischen Hardware und Betriebssystem/Programmen vermitteln. Die kann man nicht wirklich in die Hardware verlegen weil sie dann keine Treiber mehr sind. Man bräuchte dann einen Treiber der mit der Software auf der Grafikkarte über die "standardisierte" Schnittstelle kommuniziert. Und schon hätte man wieder Treiber.

Ein ganz einfacher Grund dagegen ist zum Beispiel, dass man gerne eine Schnittstelle für den Programmierer zur Verfügung stellt, die mehr bietet als die Hardware der Grafikkarte leistet. Diesen fehlenden Teil kann man dann in Software nachbilden. So kann ein Programm die OpenGL-Schnittstelle benutzen ohne das sich der Programmierer Gedanken machen muss, was die Karte in Hardware unterstützt und was nicht. Und Kartenhersteller können sich überlegen ob sie eine Karte für den Desktop, Spiele oder CAD-Bereich bauen, die alle unterschiedliche Anforderungen stellen.

blackjack:

Zur Flexibilität:
Treiber, die in das Gerät verlegt würden, wären genauso
flexibel oder unflexibel wie solche, die zum OS gehören -
schließlich ist ein EEPROM oder ein FLASH kein ROM.
Aber wichtiger ist noch: niemand sollte täglich das Bedürfnis
haben, das Dateisystem seiner Platten zu wechseln, wenn dieses
etwas taugt.
Irgendwann
müßte selbst diese Technik ausgereift sein; die Patchflut
heute zeigt doch, wie unausgereift und voreilig solche
Sachen auf den Markt geworfen werden im Vertrauen "der User
kann unsere Produkte doch selbst warten, das spart uns
Entwicklungszeit und kostet nur seine Zeit".

Blackjack, insgesamt (leider habe ich nicht so viel Zeit, um
auf jeden Deiner Einwände gezielt zu antworten) kann ich
aber unter deinen Einwänden kein echtes Gegenargument
entdecken, das dafür spräche, den benutzerunfreundlichen,
inkompatiblen bisherigen
Ansatz mit dem OS als zentrale Steuersoftware beizubehalten.
Es ist schlicht unnötig komplex, wenn man Steuersoftware
für die HD über Firmware,BIOS,Treiber,OS verstreut.
Das hat meiner Ansicht nach historisch bedingte Gründe aus
der Computer-Welt vergangener Jahrzehnte, aber die
Geschichte zeigt, daß in der Regel der technische
Fortschritt gegen historisch bedingte Gewohnheiten gewinnt -- sofern
ein annähernd fairer Wettbewerb verschiedener Konzepte
besteht.

Grüße

Ich glaube, wir reden hier aneinander vorbei...

(unintent'lly left blank) hat geschrieben:Treiber, die in das Gerät verlegt würden, wären genauso
flexibel oder unflexibel wie solche, die zum OS gehören -
schließlich ist ein EEPROM oder ein FLASH kein ROM.

Jedes Gerät stellt ein Interface bereit, womit die andere Hardware/Software mit ihm kommunizieren kann. IDE Geräte das ATA Interface, VGA-kompatible Grafikkarten das VGA Interface (bringen ihr eigenes BIOS mit und sind teilweise registerkompatibel)
Wenn du nun dein Programm für VGA Karten geschrieben hast, müsstest du es für Herculeskarten umschreiben.
Um das zu vermeiden, würdest du dir eine Bibliothek zusammenstellen, die die von dir benötigten Operationen für verschiedene Grafikkarten unterstützt, dein Programm würde nur noch die Bibliotheksfunktoinen aufrufen. Mit anderen Worten: du hast einen Treiber geschrieben.

Der riesen Fortschritt bei CP/M war doch, dass dieses BS als Vermittler zwischen Hardware und Software auftrat. Ein CP/M Programm, das für Z80 Prozessoren geschrieben war, lief unter (fast) jedem Z80 basierten Rechner, der CP/M hatte, weil das Programm eben nur noch die Funktion "schreibe die Zeichenfolge ... auf den Bildschirm" und nicht mehr direkt in irgendwelche Speicheradressen geschrieben hat.

Noch zu Windows 95 Zeiten musste Microsoft selbst viele Treiber schreiben, und alten Programmen gestatten, wild in irgendwelchen Registern rumzuschreiben, weil das eben die alte Methode war, mit der Hardware zu kommunizieren. Ein Großteil der Instabilität kommt gerade daher.

Der große Vorteil bei WXP ist ja, dass die Programme nur noch auf standardisierte Funktionen zugreifen, die dann die Treiber der Hersteller in entsprechende Anweisungen umwandeln.

Aber wichtiger ist noch: niemand sollte täglich das Bedürfnis
haben, das Dateisystem seiner Platten zu wechseln, wenn dieses
etwas taugt.

Aber vielleicht das jährliche? Nicht jeder nutzt IDE-Platten in PCs. Und Serverdateisysteme haben u.U. andere Bedingungen zu erfüllen.

Der große Vorteil vom Schritt weg zur direkten Kommunikation zur, wie du es nennst, Treiberkommunikation ist ja, das das System einfacher zu programmieren ist und weniger fehleranfällig.

Du kannst mir glauben, zu DOS Zeiten war das nicht gerade angenehm. Du hast einen Monat gebraucht, um dir einen eigenen "Treiber" für die Soundblaster zu programmieren z.B.
Und ja, die Soundblaster hat einen "Hardwaretreiber" mit dem Befehl: "spiele diese Daten an dieser Position im Ram mit dieser Geschwindigkeit ab". Nur musst du erstmal die Daten dort reinschreiben

Irgendwann
müßte selbst diese Technik ausgereift sein; die Patchflut
heute zeigt doch, wie unausgereift und voreilig solche
Sachen auf den Markt geworfen werden im Vertrauen "der User
kann unsere Produkte doch selbst warten, das spart uns
Entwicklungszeit und kostet nur seine Zeit".

Und wieso sollte das bei deinem Modell anders sein?

Blackjack, insgesamt (leider habe ich nicht so viel Zeit, um
auf jeden Deiner Einwände gezielt zu antworten) kann ich
aber unter deinen Einwänden kein echtes Gegenargument
entdecken, das dafür spräche, den benutzerunfreundlichen,
inkompatiblen bisherigen
Ansatz mit dem OS als zentrale Steuersoftware beizubehalten.

Inkompatibel ist der Ansatz ohne OS! Ob du nun den Hersteller zwingst, kompatibel mit einem High-Level-Interface zu sein, in dem du ihn eine CD ausliefern lässt, oder ob es in einem Chip ist, ist egal. Nur das die Sache mit dem Chip nicht gut funktioniert. Wie willst du denn z.B. Code mit Code in einem Chip linken?
Im übrigen spricht sich moderene Hardware ja schon ab. Zu IDE-Bus zeiten musstest du ja noch selbst mittels Jumpern interrupts und portadressen einstellen, seit PCI und Plug'n'Play sprechen sich die Karten selber ab und sagen dir auch noch, welche Werte sie jetzt gewählt haben.

Es ist schlicht unnötig komplex, wenn man Steuersoftware
für die HD über Firmware,BIOS,Treiber,OS verstreut.

Nein, es macht die Sache einfacher und ist auch logischer, wenn jedes Teil genau eine Funktion hat, die UNIX-Philosophie: "do only one thing, but do it right". Deshalb gibt es z.B. unter Linux ein Programm, das ISOs brennt, ein Programm, das ISOs erstellt, und ein Programm, das eine GUI zum CD brennen bereitstellt. Wenn dir eines der Programme nicht gefällt, kannst du es gegen ein anderes austauschen. Unter Windows muss ein Programm alle drei Sachen beherrschen.
Auf die Hardware bezogen: Eine Festplatte soll Daten speichern, nicht mehr und nicht weniger. Sie soll nicht irgendwelche Forderungen stellen, wie die Daten auszusehen haben ("Dateinamen dürfen nur 215 Buchstaben enthalten"). Wenn ich nun eine gewisse Struktur für diese Daten brauche, um sie zu organisieren, bette ich die wahren Daten z.B. in ein Dateisystem ein, oder in eine Datenbank. Oracle-Datenbanken können z.B. direkt auf Partitionen schreiben, da eine Datenbankdatei selbst wieder eine Art Dateisystem enthält, also unnötig Platz verschwendet.

Das hat meiner Ansicht nach historisch bedingte Gründe aus
der Computer-Welt vergangener Jahrzehnte, aber die
Geschichte zeigt, daß in der Regel der technische
Fortschritt gegen historisch bedingte Gewohnheiten gewinnt -- sofern
ein annähernd fairer Wettbewerb verschiedener Konzepte
besteht.

Eben, und das abstrakte Gebilde setzt sich durch, ebenso wie man heute nicht mehr unbedingt in Assembler/C programmiert, sondern in Hochsprachen, da es dort viel schneller und fehlerfreier geht. Ich stimme dir zu, dass die modernen GUIs eher kontraproduktiv sind, aber darum geht es hier ja gar nicht.

Bei modernen PCs steckst du eine neue Karte rein, installierst den Treiber und das Ding läuft. Früher musstest du noch Jumper einstellen, ein Update für das Programm, mit dem du arbeitest kaufen, damit die Hardware angesprochen werden kann, etc.