quo vadis software?

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 29. November 2005, 17:24

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Dienstag 29. November 2005, 22:36

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

Dienstag 29. November 2005, 22:49

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

Mittwoch 30. November 2005, 07:45

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

Mittwoch 30. November 2005, 14:55

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

Mittwoch 30. November 2005, 16:04

Joghurt hat geschrieben:Ich glaube, wir reden hier aneinander vorbei...
Seh' ich auch so. Aber ich weiß nicht warum, meine Aussage ist
doch einfach und klar.

>>Wenn du nun dein Programm für VGA Karten geschrieben hast, müsstest du es für Herculeskarten umschreiben.<<

Eben nicht. Der Treiber der Graifkkarte wäre dann so
programmiert, daß das Mainboard direkt Op*nG* oder D*r*c*X
-Kommandos an die Grafikabteilung senden könnte.
Kommt eine neue Version von D*r*c*tX heraus, wird nur der
Treiber aktualisiert, oder er tut das selber (auch nicht schwierig).

Und, wichtig: Ich will die Treiber ja nicht abschaffen. Das geht
gar nicht. Nur anders verteilt müssen sie werden: nämlich
stets in das jeweilige Gerät eingebaut.

>>Der riesen Fortschritt bei CP/M war doch, dass dieses BS als Vermittler zwischen Hardware und Software auftrat.<<

Richtig.

>>Ein CP/M Programm, das für Z80 Prozessoren geschrieben war, lief unter (fast) jedem Z80 basierten Rechner, der CP/M hatte,<<

Sicherlich in der Theorie. In der Praxis gab es verschiedene
Versionen C*/M1.4, C*/M2.2, C*/M3.0, M*/M, die nicht ganz
kompatibel waren. Dazu undokumentierte Z80-Befehle.
Ein etwas größeres Programm, das auf Rechner A geschrieben
war, auf Rechner B zum Laufen zu bringen, war schwer, schon wegen
der unterschiedlichen Floppy-Formate. Aber bei kleineren Programme
wie k*rm*t oder d*t ging es -- der Überlieferung nach -- wohl.

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

Daran ändert sich an meinem Konzept kein gar nichts - die Treiber
sind nur woanders gespeichert und werden dezentral verwaltet.

>>Du kannst mir glauben, zu DOS Zeiten war das nicht gerade angenehm.<<

Glaube ich Dir ja.
Inkompatibel ist der Ansatz ohne OS!
Im Gegenteil. Es fallen 3 oder 4 Hierarchiestufen weg, durch
die sich heute ein Systemaufruf wie "show file selector dialogue" quälen muß, und wo nichts ist, sind auch keine Kompatibilitätsprobleme.

>>Im übrigen spricht sich moderene Hardware ja schon ab.<<

Das ist das Beginn eines Trends, der genau in die Richtung zielt,
die ich beschrieben habe. Damals DIP-Schalter und handinstallierter
Treiber, heute USB und Treiber von CD und morgen Hardware mit
eingebauter Treiberverwaltung und echtem Pl*g'n'Pl*y.

>>wenn jedes Teil genau eine Funktion hat, die UNIX-Philosophie: "do only one thing, but do it right".<<

Dieses Prinzip ist großartig. Nur sollte es auch auf OS angewandt
werden, denn diese erfüllen tausend Funktionen.
Eine Festplatte mit eingebauten Dateisystem und High-Level-Ansteuerung
wäre ja die Richtung "do one thing 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<<

Ich habe gar nichts gegen L*n*x, im Gegenteil. L*n*x hätte es
viel leichter, wenn die Treiber in die Hardware verschoben
würden, dann fiele nämlich einer der Haupttnachteile von L*n*x ggü.
W*n*o*s weg, die Treiber-Auswahl.

>>Eben, und das abstrakte Gebilde setzt sich durch, ebenso wie man heute nicht mehr unbedingt in Assembler/C programmiert, sondern in Hochsprachen,<<

Eigentlich wird heutzutage meist in C/C++ programmiert. Das ist nicht
gerade Welten entfernt von Assembler, nur eben portabel.

Grüße
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 30. November 2005, 16:12

Also dann ändert sich ja nicht wirklich viel. Zwar fallen einige Zwischenschichten weg, aber jedes mal wenn heute ein Treiber in einer neuen Version raus ist, den ich "nur" installieren muss, muss ich, wie ein BIOS update, beim jeweilige Gerät eine neue Firmware flashen???

Und was ist daran besser insgesamt besser? Ich denke deine Argumente stimmen da nicht wirklich, von wegen weniger Komplexität. In Wirklichkeit sind nur die Schnittstellen anders verteilt. Halt aus dem OS raus und in die Hardware rein.

Außerdem wir jede Hardware wesentlich teurer. Weil sie halt intelligenter werden müsste. Halt für sich genommen autonom. Also sie braucht quasi einen eigenen Prozessor, RAM und Flash-Speicher...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
(unintent'lly left blank)

Mittwoch 30. November 2005, 17:28

jens hat geschrieben:aber jedes mal wenn heute ein Treiber in einer neuen Version raus ist, den ich "nur" installieren muss, muss ich, wie ein BIOS update, beim jeweilige Gerät eine neue Firmware flashen???
Im Prinzip ja. Nur daß ein Mainboard intelligent genug sein
kann, selbst im Internat nach neuen Treibern zu suchen und
an die einzelnen Geräte zu verteilen. Da hat der User dann gar
nichts mit zu tun.
jens hat geschrieben:Außerdem wir jede Hardware wesentlich teurer. Weil sie halt intelligenter werden müsste.
Das ist richtig. Nur ist in der modernen Technik fast nichts billiger
als Elektronik, und eine kleine CPU mit einigen MB Flash oder RAM
würde das Gerät vielleicht um einen Euro oder ein paar Cents,
verteuern. Da Treiber sowieso entwickelt werden, wären die
Software-Entwicklungskosten nicht viel höher, nur für das
High-Level-Interface (Dateisystem in Massenspeichern) entstünden
Entwicklungskosten. Aber die spart man dann ja wieder beim OS ein.

Grüße
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Mittwoch 30. November 2005, 19:39

(unintent'lly left blank) hat geschrieben:Im Prinzip ja. Nur daß ein Mainboard intelligent genug sein
kann, selbst im Internat nach neuen Treibern zu suchen und
an die einzelnen Geräte zu verteilen. Da hat der User dann gar
nichts mit zu tun.
Und moderene BS können das schon heute. Was spricht also dagegen, meinetwegen per Windows-Update neue Treiber zu installieren?

Langsam glaube ich, dass wir hier einen Troll füttern...
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 30. November 2005, 20:10

Joghurt hat geschrieben:Langsam glaube ich, dass wir hier einen Troll füttern...
Na also bitte! Es ist halt eine visionäre Idee! Ob sie durchführbar ist, ist eine andere Frage...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Mittwoch 30. November 2005, 20:50

Ich find den ganzen Thread hier phantastisch.

Nur habe ich das Gefühl, das (unintent'lly left blank) im Vergleich zu Joghurt und BlackJack weniger Fachwissen mitbringt. Manchmal ist jedoch ein frischer Blick nötig, jedoch habe ich eigentlich mit der aktuellen Situation wenig Probleme, zumindest weniger als ich vermutlich mit (unintent'lly left blank)s Vision hätte.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
(unintent'lly left blank)

Donnerstag 1. Dezember 2005, 07:29

Du hast recht, Leonidas, dein Hinweis auf mein angeblich mangelndes
Fachwissen ist noch das beste deiner Gegenargumente. Leider wird es
auch durch Wiederholung noch lange nicht gut.
Besser ich patentiere die Idee, dann wirst du in 20 Jahren mit jeder PC-Hardware, die du kaufst, Lizenzgebühren an mich zahlen. :lol: :lol: :lol:
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 1. Dezember 2005, 17:25

(unintent'lly left blank) hat geschrieben:Du hast recht, Leonidas, dein Hinweis auf mein angeblich mangelndes
Fachwissen ist noch das beste deiner Gegenargumente. Leider wird es
auch durch Wiederholung noch lange nicht gut.
Dann beweise mal dieses Wissen. Labern kann jeder.
(unintent'lly left blank) hat geschrieben:Besser ich patentiere die Idee, dann wirst du in 20 Jahren mit jeder PC-Hardware, die du kaufst, Lizenzgebühren an mich zahlen. :lol: :lol: :lol:
Bäh! Auch noch Patente ins Spiel bringen! Wenn dies eintreffen sollte, dann mache ich es wie Mark Pilgrim. Dann wäre ich von dem Fortschritt der Computerwelt wirklich bitter enttäuscht, wenn ich Leuten Patentgebühren zahlen sollte die nur Ideen haben, aber keine Ahnung.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
(unintent'lly left blank)

Donnerstag 1. Dezember 2005, 19:09

@Leonidas:

>>Dann beweise mal dieses Wissen.<<

Na gut. Wußtest Du, daß der Elefant das einzige Lebewesen ist, das genau
vier Knie hat -- ?

>>Bäh! Auch noch Patente ins Spiel bringen!<<

Ja was haben wir denn da -- einen Software-Patente-Gegner ?
:o :o
Ich bin überrascht.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 1. Dezember 2005, 19:15

(unintent'lly left blank) hat geschrieben:>>Dann beweise mal dieses Wissen.<<

Na gut. Wußtest Du, daß der Elefant das einzige Lebewesen ist, das genau
vier Knie hat -- ?
Toll! Jetzt noch Fachwissen dass zu dieser Diskussion passt.
(unintent'lly left blank) hat geschrieben:>>Bäh! Auch noch Patente ins Spiel bringen!<<
Ja was haben wir denn da -- einen Software-Patente-Gegner ?
:o :o
Ich bin überrascht.
Warum?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten