quo vadis software?

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
sonium
User
Beiträge: 66
Registriert: Mittwoch 27. Oktober 2004, 21:04

Sonntag 27. November 2005, 12:24

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.
- http://bash.org/?400459
(intentionally left blnk)

Sonntag 27. November 2005, 17:14

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

Montag 28. November 2005, 00:39

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.
(unintent'ly left blank)

Montag 28. November 2005, 06:55

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
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 28. November 2005, 15:34

(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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Montag 28. November 2005, 15:46

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 :(
TUFKAB – the user formerly known as blackbird
(unintent'ly left blank)

Montag 28. November 2005, 19:08

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.
ello
User
Beiträge: 14
Registriert: Montag 18. Juli 2005, 16:35
Wohnort: Eberswalde
Kontaktdaten:

Montag 28. November 2005, 23:56

(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
[i]Losing my passport was the least of my worries,
losing a notebook was a catastrophe[/i]
[b]--Bruce Chatwin[/b]
BlackJack

Dienstag 29. November 2005, 00:02

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.
(unintent'lly left blank)

Dienstag 29. November 2005, 07:29

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) :shock:

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.
(unint'lly left blank)

Dienstag 29. November 2005, 08:36

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.
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Dienstag 29. November 2005, 14:55

(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.
BlackJack

Dienstag 29. November 2005, 15:02

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.
(unintent'lly left blank)

Dienstag 29. November 2005, 15:39

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.
Python 47
User
Beiträge: 574
Registriert: Samstag 17. September 2005, 21:04

Dienstag 29. November 2005, 15:57

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
mfg

Thomas :-)
Antworten