Re: Implementierung von malloc und free unter FreeBSD

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Mon, 13 Sep 2004 15:54:42 +0200

On Mon, Sep 13, 2004 at 02:40:06PM +0200, Oliver Fromme wrote:
> Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > On Mon, Sep 13, 2004 at 11:54:06AM +0200, Oliver Fromme wrote:
> > > Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > C ist bestenfalls in anbetracht des heutigen Gigabyte Wahns überholt.
> > Wenn dein Kühlschrank aber zukünftig in was anderem als C oder
> > Assembler programmiert werden soll, dann wird der letzlich auch spürbar
> > teurer - und wird letzlich auch mehr Strom brauchen.
>
> Nein. Er muß weder teurer sein, noch muß er mehr Strom
> ziehen.

Doch natürlich - Leistung gibt es nicht umsonst.
Kühlschränke nutzen sicherlich nicht die Möglichkeiten aus, aber
prinzipiel kann man den durchschnittlichen Strombedarf des Steuerungs-
systems auf 1-2mA oder noch weniger reduzieren.

> Und davon mal ganz abgesehen: Wenn ein Kühlschrank fehler-
> frei funktioniert, wäre ich gerne bereit, dafür etwas mehr
> auszugeben.
>
> Wenn ich die Wahl hätte zwischen einem Kühlschrank für 500
> Euro, der auf Windows-CE basiert und dessen Anwendungen in
> C oder Java geschrieben sind, und einem Kühlschrank für 600
> Euro, der auf (z.B. Net-)BSD basiert und dessen Anwendungen
> in O'Caml oder Haskell geschrieben sind -- was meinst Du,
> welchen ich nehmen würde? Welchen würdest Du nehmen?

Keinen von beiden - ich würde den kaufen in dem ein angemessener
Controller steckt und kein Hochleistungsrechner.
Schließlich erwarte ich vom Kühlschrank nicht, dass er Apfelmänchen
berechnet.
Das Dingen muss doch letzlich nur die Temperatur überwachen,
ein paar Schalter abfragen und den Motor schalten.
Und selbst wenn das Dingen Ethernet und einen Webserver hätte wäre
ein für moderne Hochsprachen oder gar BSD tauglicher Rechner
vollkommen überdimensioniert.
Beides sind nette Sprachen und für viele Anwendungen die bessere
Wahl, aber es gibt einfach Anwendungen für die diese Sprachen
vollkommen untauglich sind, während C wunderbar funktioniert.

> (Und wie gesagt: Es gibt keinen Grund, warum der BSD-Kühl-
> schrank nicht ebenfalls 500 Euro kosten sollte, wenn die
> Hardware sonst technisch identisch ist.)

In deiner Maus läuft doch auch weder Windows-CE, noch BSD, weil
beides einfach nicht angemessen ist.
Letzlich läuft ein heutiger BSD Rechner mit unzähligen Hilfs-
prozessoren, die mit jeweils deutlich kleinerer Hardware erst die
Gesammtleistung des Systems ermöglichen.

> > > C ist einer der Hauptgründe, warum heutige Software so vie-
> > > le Bugs enthält.
> >
> > Sicherlich hilft C wenig um derartige Fehler zu vermeiden, aber die
> > meisten Fehler in C Programmen liegen daran dass viele Programme von
> > unerfahrenen Programmieren geschrieben wurden, die in jeder Sprache
> > ihre Fallen finden würden.
>
> In bestimmten besseren Sprachen kannst Du zahlreiche typi-
> sche Fehler gar nicht machen (auch nicht als Anfänger),
> z.B. Typfehler, unitialisierte Variablen, Pufferüberläufe,
> unbeabsichtigte Seiteneffekte etc. Unter bestimmten Um-
> ständen kann man sogar das korrekte Verhalten von Funktio-
> nen mathematisch beweisen und diesen Beweis vom Compiler
> verifizieren lassen. Von sowas kann C nur träumen.

Ja sicher - nur solange man dann einen Speicherbedarf hat, welcher sich
nur durch DRAM wirtschaftlich decken lässt ist das unwesentlich.
DRAM funktioniert nämlich beweisbar eben nicht zuverlässig und ECC,
womit sich das DRAM Problem deutlich entschärfen lässt ist für einen
Kühlschrank oder gar Maus erst recht vollkommen übertrieben.
Und solange es wahrscheinlicher ist, dass ein Kühlschrank durch Strom-
ausfall, oder Kompressorschaden ausfällt ist es mir ziemlich egal ob
die Software beweisbar Fehlerfrei ist oder nicht.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 13 Sep 2004 - 15:56:13 CEST

search this site