1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Unix: Ein Betriebssystem in 8 KByte

Der schrecklich lange Erfolg kurzfristiger Designs

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Der schrecklich lange Erfolg kurzfristiger Designs

    Autor: abufrejoval 23.06.20 - 15:04

    Schon die Überschrift ist wohl falsch bzw. irreführend: Heute ist 'Byte' eine feste 8-Bit Größe, aber diese frühen Rechner leisteten sich nicht den Luxus so vieler Zeichen und beschränkten sich auf binary digits mit sechs Stellen. Vier von diesen, in Summe 18, ergaben bei der PDP-7 ein Maschinenwort und davon hatte der Rechner 8192 Stück, also 147456 Bits oder 18,5 Kilobyte nach heutiger Rechnung.

    Ziemlich klar ist, daß man da nicht wie Fernando Corbató bei Multics auf den viel eleganteren direkt addressierbaren und praktisch meist virtuellen Speicher setzt: Ich sage gern daß Unix 'adress bus envy' hat und deswegen alles über file system abstractions kompensiert.

    Multics hingegen, wie später die IBM i-Series, betrachtete alles, auch Dateien, als direkt addressierbaren Speicher, weshalb mich mmap() immer ironisch zucken läßt. Muß ich da erwähnen, daß die tollsten und neuesten Fabrics wie CCIX für die größten Supercomputer auf die direkte Adressierung setzen?

    Nur wenige Jahre später mit dem Aufkommen von Netzwerken haben die Unix Designer ja selbst verstanden, daß Unix asozial (it has a God complex) und diese Dateisystemerei überholter Blödsinn sind und die Unix-Badewanne mit Plan-9 auskippen wollen, eines der schönsten Beispiele, wie wenig Chance generalüberholtes Design gegenüber Popularität hat.

    Das Thema setzt sich bei 4004, 8008, 8080, 8086, 80286, 80386 und AMD64 fort, aber immerhin ist bei RISC-V abzusehen, daß gründlich entwickelte Neuanfänge selbst in der IT gelegentlich erfolgreich sein können.

    Zu Linux kann ich nur sagen, daß ich den riesigen Overhead von Task-State-Segments schon bemerkt hatte, bevor ich aus Versehen mein eigenen Multitasker darauf implementierte.

    Das ist Herrn Torvalds aber wohl bis heute so peinlich, daß er seither genau auf die Qualität und Leistungsfähigkeit des Codes achtet, der vor ihm Revue passiert. Und selbst µ-Kernel kommen hier und da wieder auf, gerüchteweise steckt in jedem iPhone neben Mach auch noch ein L4.

    Jochen Liedtke hätte es sicher gefreut, während Andrew Tannenbaum sich ggf. mehr darüber ärgert, daß Minix zwar auf mehr PCs und Servern läuft als Windows und Linux zusammen, aber leider kaum von dem komprimittierten wie kompromittierenden Serviceprozessor aktueller Intel-Chips getrennt werden kann, die damit betrieben werden.

    In welchem Grade die evolotionäre Fortentwicklung viel zu kurzfristig angelegte Designs kompensieren kann, ist immer wieder erstaunlich. Gelegentlich wünsche ich mir trotzdem, daß auch größere und bessere Würfe sich mal durchsetzten.

  2. Re: Der schrecklich lange Erfolg kurzfristiger Designs

    Autor: EWCH 23.06.20 - 15:46

    > Nur wenige Jahre später mit dem Aufkommen von Netzwerken haben die Unix
    > Designer ja selbst verstanden, daß Unix asozial (it has a God complex) und
    > diese Dateisystemerei überholter Blödsinn sind und die Unix-Badewanne mit
    > Plan-9 auskippen wollen,

    klingt aber eher so als haetten sie die Bedeutung des Filesystems ausgebaut:

    Under Plan 9, UNIX's everything is a file metaphor is extended via a pervasive network-centric filesystem, ...

  3. Re: Der schrecklich lange Erfolg kurzfristiger Designs

    Autor: dangi12012 23.06.20 - 17:51

    Das beste System wäre everything is memory mapped über unique Namen. die dahinterliegenden api calls müssen dann nur eine page auf den Prozess Mappen.

    Filesystem access ist gleich wie ram und Netzwerk und Peripherie.
    Das OS abstrahiert alles.

  4. Re: Der schrecklich lange Erfolg kurzfristiger Designs

    Autor: abufrejoval 23.06.20 - 18:36

    EWCH schrieb:
    --------------------------------------------------------------------------------
    > > Nur wenige Jahre später mit dem Aufkommen von Netzwerken haben die Unix
    > > Designer ja selbst verstanden, daß Unix asozial (it has a God complex)
    > und
    > > diese Dateisystemerei überholter Blödsinn sind und die Unix-Badewanne
    > mit
    > > Plan-9 auskippen wollen,
    >
    > klingt aber eher so als haetten sie die Bedeutung des Filesystems
    > ausgebaut:
    >
    > Under Plan 9, UNIX's everything is a file metaphor is extended via a
    > pervasive network-centric filesystem, ...

    Ja, das hätte weniger in einen Topf schmeißen sollen. Plan-9 wurde "sozial" oder kooperativ und da kann man nicht einfach so einen verteilten virtuellen Adreßraum verwenden. Das "Filesystem" wird dort zu einer Art "URL" und das hat sich ja weit entwickelt.

    Die großen Supercomputeranwendungen können aber nur dann skalieren, wenn sie Kommunikation über zur Laufzeit im Adreßraum festgezurrte Puffer z.B. über MPI erledigen können. Und dort teilen sich eben auch zunemend CPUs, GPUs, ASICs oder FPGAs einen Adreßraum, der physisch dann schon wieder ziemlich weit verteilt werden kann, aber eben dann auch mit 64-Bit Adressen schon eng wird.

    Wenn ich mal mit-trace, was so ein normaler Prozeß an "Dateien" in /sys oder /proc aufmacht, um sich ein wenig umzuschauen, frage ich mich schon, ob es da nicht bessere Schnittstellen geben könnte, irgendwas tupeliges zum Beispiel.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Limbach Gruppe SE, Heidelberg
  2. Westernacher Solutions GmbH, Berlin, Heidelberg
  3. Hays AG, Mannheim
  4. SEG Automotive Germany GmbH, Stuttgart-Weilimdorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de