Re: Implementierung von malloc und free unter FreeBSD

Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> On Mon, Sep 13, 2004 at 02:40:06PM +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.

Was für Leistung? Für ein Programm in einer ML-Sprache
brauchst Du nicht mehr (elektrische) Leistung als für ein
Programm, das in C geschrieben wurde.

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

Ja, könnte man sicherlich.

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

Ein integrierter Prozessor mit 12 oder 16 Mhz ist kein
»Hochleistungsrechner«. Und es wird nicht mehr lange
dauern, bis sowas Standard bei einem Kühlschrank ist.

> Schließlich erwarte ich vom Kühlschrank nicht, dass er Apfelmänchen
> berechnet.

Das vielleicht nicht, aber er könnte z.B. seinen Inhalt in
einer Datenbank erfassen und mich informieren, wenn ich
neue Milch kaufen muß, oder wenn beim Bierschinken das MHD
abgelaufen ist. Es gibt bereits Kühlschränke, die das tun.

> Das Dingen muss doch letzlich nur die Temperatur überwachen,
> ein paar Schalter abfragen und den Motor schalten.

Dafür braucht man keinerlei Elektronik, auch keinen dummen
Controller.

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

Wäre mir jedenfalls lieber als Windows. Und das _wird_
kommen, verlaß Dich drauf.

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

Das sehe ich überhaupt nicht so. Überall, wo man C ver-
wenden kann, kann man ebesogut eine besser designte Sprache
verwenden. Möglicherweise ist das am Ende sogar billiger,
weil man beim Debuggen und im Bereich Q/A sowie bei der
Pflege viel Zeit sparen kann.

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

Das ist nur eine Frage der Zeit. In zehn Jahren haben Mäu-
se ihre eigene IPv6-Adresse (weil _alles_ eine hat), und
da bietet es sich doch an, daß da ein eigenes OS drauf
läuft. Vermutlich kostet ein kompletter Prozessor dann
nur noch ein paar Cent.

In meiner real-existierenden Maus daheim läuft aber auch
nichts, was in C geschrieben ist.

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

Ob man DRAM nimmt oder etwas anderes (SRAM, Flash, sonst-
was), hängt von der jeweiligen Anwendung ab. Die Wahl des
Speichers schränkt dann aber noch lange nicht die Auswahl
der möglichen Programmiersprachen auf C ein.

> DRAM funktioniert nämlich beweisbar eben nicht zuverlässig

Naja, nicht die übertakteten Non-name-DIMMs vom Kisten-
schieber an der Ecke, da gebe ich Dir recht. Aber hoch-
wertige DRAMs sind schon hinreichend verläßlich.

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

Hardware (insbesondere mit mechanischen Komponenten) unter-
liegt Verschleiß und kann somit immer ausfallen, wenn sie
nicht redundant ist. Das ist aber kein Grund, daß man bei
der Software ebenfalls Fehler in Kauf nehmen muß.

Ich dachte eigentlich bisher immer, daß sich diese Fatalis-
mus-Mentalität überwiegend bei den Windows-Usern verbreitet
hat ... »Ach Gott, Software hat nunmal Fehler, da kann man
nix machen, außer Reboot, und wenn's sein muß, Neuinstalla-
tion.« Ich dachte, wir BSDler wüßten es besser, und nehmen
es nicht als gottgegeben hin, daß Software Bugs hat und man
seine Crashes und Reboots mit stoischer Geduld ertragen muß.

Sorry, wenn das jetzt ein bißchen theatralisch wurde, aber
im Prinzip ist es doch so.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"IRIX is about as stable as a one-legged drunk with hypothermia
in a four-hundred mile per hour wind, balancing on a banana
peel on a greased cookie sheet -- when someone throws him an
elephant with bad breath and a worse temper."
        -- Ralf Hildebrandt
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message