Hadmut Danisch

Ansichten eines Informatikers

Hello World

Hadmut
18.5.2015 19:45

Zwischen Melancholie und Nostalgie.

Als ich mit meinen ersten Datenbandkassetten anfing, passten da vielleicht ein paar Kilobyte drauf. Und ich habe da damals drauf bekommen, was ich hatte.

Dann hatte ich die ersten 8-Zoll-Disketten. Keine Ahnung, wieviel da damals drauf passte, wohl so um die 100 Kilobyte. Und es passte auf zwei dieser Disketten alles drauf, was ich damals hatte.

Dann kamen die 5 1/4-Zoll-Disketten. Wieviel passte damals beim C-64 und beim CBM 3032 auf eine Diskette? Waren das nicht sowas um die 170 oder 180 Kilobyte? Ich bin mit ein oder zwei, drei, vier Disketten locker ausgekommen, und es passte alles drauf, was ich damals hatte. Komplette Entwicklungsumbegungen in Assembler oder Forth.

Dann kamen die IBM-PCs, die noch keine Festplatten hatten. Aber wozu auch? Auf eine Diskette passten 360 Kilobyte, doppelseitig sogar 720, und da passte das ganze Betriebssystem (DOS) drauf, sogar Anwendungsprogramme. Textprogramme, Wordstar, Tabellenkalkulationen, Turbo Pascal, passte da alles drauf. Gut, vielleicht nicht alles auf eine, aber eine oder zwei dieser Anwendungen passten zusammen mit dem Betriebssystem drauf.

Dann gab es die 3 1/2-Zoll-Disketten. Beim Amiga passten da 880 Kilobyte drauf, und da hatte ich das Betriebssystem und Textverarbeitung, oder komplette Entwicklungsumgebungen für Assembler (Seka) oder C (Aztec) oder ganze Spielesammlungen. Legendär sind die Fish-Disks, die ganze Software-Universen auf solche Disketten packten.

Kurz darauf gab es die 3 1/2-Zoll-HD-Disketten mit gigantischen 1,44 MByte. Nochmal zum Mitschreiben: 1,44 MByte. Da passte ein ganzes Betriebssystem mit allem drum und dran und Anwendung drauf, sogar frühe Versionen von „Windows”. Selbst heute bekommt man noch DOS-Floppy-Images, die man manchmal braucht, um ein Board unter DOS zu booten und das BIOS zu aktualisieren. Passte alles da drauf.

Ich hatte sogar mal Notboot-Linux. Eine Zeit lang sogar auf nur einer 1,44-MByte-Diskette, dann auf zwei, auf der einen der Kernel, auf der anderen die gesamte Umgebung. Ein komplettes Linux auf zwei Disketten. Naja, nicht ganz komplett, die ersten Linux-Distributionen (SLS Softlanding Linux, Slackware, Debian) habe ich damals noch auf anfangs 15, später ca. 70 dieser Disketten nach Hause getragen. Komplett, mit allem, was es damals an Linux-Software gab. Voll funktionsfähig, einschließlich X11, Web-Browser und so weiter.

Nur um Euch mal ein Gefühl für Größenordnungen von Software zu geben.

Ich kann mich noch erinnern, dass ein ordinäres Hello World


#include <stdio .h>

int main() {
puts("Hello World");
return 0;
}

damals auf einer Sun 3/50 unter SunOS 3.5 compiliert und gestrippt so ungefähr 1 bis 2 kByte belegte, und statisch gelinkt irgendwo bei 7 oder 8 kByte lag (das dynamische Linken wurde damals gerade erst eingeführt).

Mache ich das heute, sieht das zuerst wie in der guten alten Zeit aus:


% gcc -o helloworld helloworld.c
% strip helloworld
% ls -lF helloworld
-rwxr-x--- 1 hadmut hadmut 6240 Mai 18 19:27 helloworld*

Ja mein, 6kByte für ein Hello World, das geht. Mache ich das aber statisch, wird das schon gruselig:


% gcc --static -o helloworld helloworld.c
% strip helloworld
% ls -lF helloworld
-rwxr-x--- 1 hadmut hadmut 795864 Mai 18 19:28 helloworld*

Rund 800 kByte. Da passte beim IBM-PC oder bei Amiga noch das ganze Betriebssystem samt Applikationssoftware rein.

Jetzt probier ich mal die „systemnahe und effiziente” Programmiersprache Go und hole mir von deren Webseite mal deren Hello World:


package main

import "fmt"

func main() {
fmt.Println("Hello, World")
}

Probieren wir es:


% go build
% strip HelloWorld
% ls -lF HelloWorld
-rwxr-x--- 1 hadmut hadmut 1474432 Mai 18 19:35 HelloWorld*

Da passt also ein profanes Hello World nicht mehr auf eine Diskette. Die hat nämlich eine Kapazität von 1474560, das sind zwar gerade noch 128 Byte mehr, aber erstens geht da noch ein Dateisystem ab, also reicht es nicht mehr, und zweitens ist das ja ne alte Version (Ubuntu 14.04), inzwischen sind die bestimmt noch viel größer.

Früher passte ein ganzes Betriebsystem mit Applikationen auf so eine Diskette, heute nicht mal mehr ein simples „Hello World”.

82 Kommentare (RSS-Feed)

Rüdiger Plantiko
18.5.2015 20:13
Kommentarlink

Effizientes, speicherschonendes Programmieren ist so was von 20. Jahrhundert. 🙂

Der Kampf um immer mehr Speicher und immer schnellere Prozessoren (unter Berufung auf das sogenannte “Mooresche Gesetz”) ist ein ewiges Ping-Pong zwischen Hard- und Softwareherstellern, das schon in den 90ern mit dem bonmot

“What Andy giveth, Bill takes away”

umrissen wurde. Gemeint sind Andy Grove (damals Intel-Chef) für die Hardware- und Bill Gates für die Softwareseite.

Für Nostalgiker empfehle ich den Tiny C Compiler von Fabrice Bellard.

Er hat sich auch mit dem Compiler selbst Mühe gegeben (mit der ersten Version des TCC gewann er den Obfuscated Code Contest 2002, weil es ihm gelungen war, den gesamten Quellcode des Compilers auf 2048 Bytes zu beschränken!).

Hier die Doku der aktuellen Version:
http://www.bellard.org/tcc/

tcc.exe benötigt mittlerweile immerhin ca. 130 KB. Aber auch die Kompilate sind klein.

Habe es gerade ausprobiert: Ihr Hallo-Welt-Programm benötigt mit tcc gerade mal 1536 Bytes (dynamisch gelinkt): Wie früher! 🙂


Tux.
18.5.2015 20:14
Kommentarlink

Du könntest es im systemfernen, aber effizienten Common Lisp schreiben. Versuche ich gerade. Macht Spaß.


Hadmut
18.5.2015 20:16
Kommentarlink

> Du könntest es im systemfernen, aber effizienten Common Lisp schreiben. Versuche ich gerade. Macht Spaß.

Lisp geht mir sowas von auf den Sack.


Tacheles
18.5.2015 20:27
Kommentarlink

Mein Lieblingsbeispiel in den Vorlesungen war immer Schach auf dem ZX81.

Wer sich nicht mehr erinnert: Der ZX81 hatte in der Basisversion 1kB RAM, davon gingen im Extremfall 768 Byte fürs DFILE (aka Bildschirmspeicher) drauf. War allerdings dynamisch, eine Zeile wurde nur bis zum Zeilenende und nicht zwingend bis zum 32. Zeichen gespeichert. Leerzeilen waren also nur 1 Byte groß (Endemarker).

Schach. In signifikant weniger als 1kB. Auf einer Maschine, auf der man aufgrund der kostengünstigen Hardware nicht mal die CPU voll ausspielen konnte, da diverse Register mit Systemfunktionen betraut waren.

(Hadmut, 360kB bei DOS war schon doppelseitig (5.25″-DSDD). Die 720kB kamen erst mit den 3.5″-DSDD.)


Hadmut
18.5.2015 20:29
Kommentarlink

> (Hadmut, 360kB bei DOS war schon doppelseitig (5.25?-DSDD). Die 720kB kamen erst mit den 3.5?-DSDD.)

Herrje…


Wolfgang
18.5.2015 20:29
Kommentarlink

Amiga… existiert auch heute noch, und ein Hello world! in C kommt darauf im Normalfall, gestript und statisch gelinkt, auf gut 7KiB. Wobei man dazu sagen muß, daß es mit dem vbcc-Compiler noch etwas kleiner geht. Mit etwas Trickserei (Minimum-Startup, keine Standard-Bibliothek) gehen auch 1,5KiB.

Mir ist der aktuelle “link alles rein, was Du findest! Auch wenn niemand das Zeug gebrauchen kann… egal, rein damit!”-Wahn der aktuellen Programmiersprachen auch schon ziemlich aufgestoßen und hat mich in meiner Entscheidung bestärkt, weiter bei C zu bleiben.

Kurz noch: Amiga-3,5″-Disketten fassen (auch heute noch!) genau 880 KiB, in der HD-Variante 1,76MiB. Gab vor kurzem sogar noch einen Neubau eines externen Amiga-Diskettenlaufwerkes (allerdings auf Basis noch verfügbarer PC-Diskettenlaufwerke).


tigger
18.5.2015 20:34
Kommentarlink

Zwar halb OT aber trotzdem ziemlich cool:

http://www.menuetos.net/

Ein betriebssystem in in assembler geschrieben inklusive browser.
passt auf eine Diskette, braucht allerdings 512 MB RAM…

Hachja… damals…


Phil
18.5.2015 20:37
Kommentarlink

Fedora 21 (64bit):

$ du -sh *
12K helloworld
4,0K helloworld.c
804K helloworld-static

Es geht also noch schlimmer …

mit -Os kann man ja nach Größe optimieren:

$ gcc -Os -o helloworld-optimized helloworld.c
$ ls -la
insgesamt 1640
drwxr-xr-x. 2 phil phil 4096 18. Mai 20:23 .
drwxr-xr-x. 3 phil phil 14 18. Mai 20:12 ..
-rwxr-xr-x. 1 phil phil 8502 18. Mai 20:13 helloworld
-rw-r–r–. 1 phil phil 68 18. Mai 20:13 helloworld.c
-rwxr-xr-x. 1 phil phil 8508 18. Mai 20:23 helloworld-optimized
-rwxr-xr-x. 1 phil phil 822994 18. Mai 20:21 helloworld-static
-rwxr-xr-x. 1 phil phil 822994 18. Mai 20:22 helloworld-static-optimized

Jetzt ist es sogar noch größer.

Der einfache Build mit $ gcc -o helloworld helloworld.c hat schlappe 1KB an Strings drin. Beim static build geht das meiste in .text rein.
Wobei immerhin die Strings nur noch 70K ausmachen. Wobei 70K auch schon fast ein Roman sind.


Schwärmgeist
18.5.2015 20:44
Kommentarlink

Man will eben die Banane haben und bekommt den ganzen Gorilla. Ich blicke auch immer neidvoll auf solche Binaries wie ls und find und bewundere sie ob deren Schlankheit.


Schwärmgeist
18.5.2015 20:53
Kommentarlink

Meine erste Festplatte für den Atari ST hatte wahnsinnige 85 MB. Bill Gates ließ uns ja wissen, daß niemand so viel Speicher braucht. Die Platte war immerhin topmodern SCSI, war laut wie ein Staubsauger und sündhaft teuer: 1399 Mark von irgendeiner süddeutschen Hardwareklitsche. Ich habe dieses Scheißding geliebt, ich habe den ganzen Sommer dafür durchgearbeitet, um mir das leisten zu können. Die Kiddies lachen sich heute darüber tot.


Hadmut
18.5.2015 20:55
Kommentarlink

> Meine erste Festplatte für den Atari ST hatte wahnsinnige 85 MB.

Angeber.

Meine erste Festplatte hatte 10 MB.

Ich hab auch noch eine Compact-Flash-Speicherkarte mit 2 MB.

Aber man brauchte ja laut Gates/Microsoft nie mehr als 640 kB Hauptspeicher. (In zweien meiner PCs habe ich das 25.000-Fache)


Joe
18.5.2015 20:58
Kommentarlink

Vergiß nicht GNU Hello World. ein GPL-lizenziertes*) Hello World, wo der Lizenztext 99% des Source-Tarballs ausmachte, bevor er mit GNU Autoconf noch weiter aufgebläht wurde.

*) Hello World unter GPL ist natürlich ebenso Schwachsinn, schon wegen der fehlenden Schöpfungshöhe.


JM
18.5.2015 20:58
Kommentarlink

Visual Studio 2013.

using System;

namespace Hello
{
class Program
{
static void Main()
{
Console.WriteLine(“Hello World C#!”);
}
}
}

Alle unnoetigen Referenzen/Assemblyinformationen entfernt, kommt die kompilierte exe auf genau 4 KB (kleiner geht es gar nicht mehr).

What Bill gives..


Joe
18.5.2015 21:02
Kommentarlink

Alle unnoetigen Referenzen/Assemblyinformationen entfernt, kommt die kompilierte exe auf genau 4 KB (kleiner geht es gar nicht mehr).

Was nicht schwer ist, wenn die Runtime-Umgebung 8-12 GB groß ist und auf DVD geliefert wird. Statisch linken geht da gar nicht.


jannndh
18.5.2015 21:05
Kommentarlink

Das problem sind die Compiler.

ein Hello World ist nicht wirklich komplexer geworden.
Damit sind die jetzigen Programmierer auch nicht die wirklich schuldigen.

ich würde sagen die schnelligkeit mit der sich insbesondere die i386 entwickelt haben, die sind das problem

In der Demo szene gibt es immer noch leute die wirklich bemüht sind das Optimum rauszuholen.

bei disketten kann ich erst ab3,5 zoll mitreden. da kenn ich noch 720 KB und eben die berühmten ^1,44 MB obwohl es wohl die Japaner heschafft habben das auch noch zu toppen, 2,88MB mit 3,5 Zoll

ich hatte mal ein Mainboards was support für sowas hatte, ( auf mein Laufwerk a wollten trotzdem nur 1,44 passen )

Das problem und gleichzeitig der Vorteil beim PC:

es ist mehr oder minder standadisiert. es läuft theoretrisch alles drauf
mal schneller mal langsamer
es gibt aber auch zuviel Kombinationen an Hardware.
wenn ich mit einem OS nur 3 CPUs und 4 Chipsätze unterstütze, hey dann hab ich es leichter!

Macos lässt sich ja mit tricks auch auf anderer Hardware installieren. und ist dann keinen dfeut besser als Win oddr Linux


Schwärmgeist
18.5.2015 21:18
Kommentarlink

JM, danke für den Kommentar. Microsoft versteckt natürlich auch viel in den DLLs, aber das ist mir auch aufgefallen, daß mit dem Microsoft-Compiler erstellte Binaries angenehm klein sind. Aber ehrlich gesagt, war ich noch nie ein Microsoft-Fan. Der Desktop ist ganz okay, ich benutze ihn ja auch, aber programmieren will ich diesen Mist nicht.


Schwärmgeist
18.5.2015 21:24
Kommentarlink

Ist hier übrigens Joe Merten am Start? Den würde ich nämlich kennen.


ex_pyx
18.5.2015 21:33
Kommentarlink

@Hadmut “Lisp geht mir sowas von auf den Sack”

Hmm – an sich schon, aber als Lisp-Dialekt ist Scheme allererste Sahne (vollständiger Interpreter ab ca. 30kilobyte zu haben).

Syntaktisch und konzeptuell extrem anders als Common-Lisp (bääh) , basiert auf sauberen Lambda-Expressions mit ggf eingebetteten Variablen, Endrekursion ohne Stack. Paradigma ist sozusagen diametral zur Objektorientierung aber – wie gesagt – allerfeinst.

Also: Scheme würd ich von deiner Äusserung definitiv ausschliessen!


Rox
18.5.2015 21:50
Kommentarlink

Oh Mann, meine erste Festplatte (MFM) hat gequietscht wie ein Güterzug beim Rangieren, aber was war ich stolz auf diese sagenhaften 20MB…

Auf der Win95- bis WinME-CD ist eine Date MINI.CAB, die ein komplettes kleines Windows 3.1 enthält. Startet man mit DOSEX.EXE. Dazu muss man in die WIN.INI (SYSTEM.INI???) ein geeignetes kleines Programm eintragen, das gestartet werden soll. PROGMAN.EXE oder was winziges selbst gemachtes. Startet brüllend schnell selbst auf dem 383DX-40 und wenn man sich die Kante gibt und die ausführbaren Dateien mit PKLITE komprimiert, dann kriegt man das ganze Windows inklusive MS-DOS (nur HIMEM-SYS ist wirklich nötig, SMARTDRIVE ist empfehlenswert) auf sagenhafte 800KB geschrumpft. Ein komplett funktionierendes Windows! Man kann noch optimieren indem man in SYSTEM.INI VGA.DRV durch SVGA.DRV oder noch einen anderen Video-Treiber ersetzt, aber das ist ja schon Feinarbeit.

Manchmal frage ich mich, ob die nicht irgendwann endlich mal von Quantität zu Qualität übergehen könnten. Ich meine, diese monströsen müden “modernen” Programme haben doch nichts wirklich Interessantes mehr zu bieten. Ich jedenfalls jage seit geraumer Zeit im Netz nach den Kleinoden irgendwelcher Freeks, die elend lange goldene Handarbeit an ihren Tools geleistet haben. Dann hast du so ein 100%-Assembler-Ding in der Hand, vor dem du verzückt niederknien kannst, wie ein Kunstkenner vor einem Picasso … und all die Deppen da draußen verstehen dich nicht. Böse isse, die Welt 😉


Uwe
18.5.2015 21:50
Kommentarlink

Alles viel zu groß.


/*
SPHINX C-- hello world example program
Run file size: 70 bytes.
*/

? include "WRITE.H--"

main () /* execution always starts at main () */
{
WRITESTR("Hello World!\n"); /* write the string to the screen */
}

/* end of HELLO.C-- */

Gerade kompiliert. Ja, wirklich 70 Byte. Es gibt auch noch eine optimierte Version, die hat nur 41 Byte. Das sind beides com-Dateien.


Rox
18.5.2015 21:51
Kommentarlink

Ups, hätte 386DX-40 heissen sollen


TOPCTEH
18.5.2015 21:51
Kommentarlink

“Mein” damals schon antiker Commodore 8032, mit dem ich ab ca. 1985 die Mitgliederverwaltung für ein Fitness-Center und eine Karateschule gemacht habe, hatte immerhin ein 5 1/4-Zoll-Doppeldiskettenlaufwerk mit fetten 1MB pro Diskette! Da galt auch: in einem Laufwerk war die Mitgliederverwaltungsprogrammdiskette und in den anderen die jeweilige Datendiskette. Mittels Auswahl konnte man dann zwischen Fitness-Center- und Karateschule-Diskette wechseln, um bspw. die Monatsbeitragsabrechnung zu machen (mit einem schweinelangsamen Matrixdrucker auf Lastschrift-Endlospapier; hat Stunden gedauert…). Genauso schweinelangsam war die systemseitige Datensicherung von Diskette zu Diskette.

Zuhause gab’s dann einen Zenith eaZy-PC mit zweimal 3,5-Zoll-720 KB.


Fredi
18.5.2015 21:54
Kommentarlink

Tjoa, und deswegen dienen Disketten heutzutage hauptsächlich als Tassenuntersetzer und nicht als relevante Speichermedien 😀


maSu
18.5.2015 22:21
Kommentarlink

@JM: C# … diese Ausgeburt der Hölle…


Schwärmgeist
18.5.2015 22:41
Kommentarlink

main ist doch eigentlich auch altmodisch und zwanghaft.

Cool wäre doch

stdout << "Hello World\n"

ohne Semikolon. Das muß kompilieren und laufen.

Mir gefällt C++ eigentlich ganz gut, aber was wirklich nicht geht, ist dieser Präprozessorwahnsinn mit #include; man hat überall doppelte Buchführung, das nervt einfach auf Dauer.


Philipp Seeger
18.5.2015 22:51
Kommentarlink

Ja, das ist so heutzutage. Speicherplatz ist halt da.
Wehe wenn man dann mal ein System hat, wo das nicht so ist.

Ich habe das Programmieren bei einem Hersteller für MDE-Geräte gelernt. Da haben wir jedes Byte einzeln umgedreht – nicht nur im Coding, sondern auch in den Datenstrukturen. Ich kann mich noch gut an ein Gespräch mit einem SAP-Berater erinnern, der aus allen Wolken fiel, als ich ihn fragte, wie denn bei dem Kunden die Artikelnummer aufgebaut sei. Für ihn war eine Artikelnummer ein 40-stelliges, alphanumerisches Feld.
Als ich ihm sagte, dass wir das gern so machen können, er dann aber nicht mit den 2 MB Speicher auf dem Gerät auskommt, wenn er irgendwelche Daten erfassen will, wurde ihm klar, dass wir in unterschiedlichen Welten leben.


O.
18.5.2015 22:54
Kommentarlink

Was ist mit diet libc?
Für die Magersüchtigen?


otto
18.5.2015 23:11
Kommentarlink

Hallo,

jaja mein Partner kam mal lachend von der Hannover Messe, eine 2 MB Platte. Lach lach, wer soll das vollschreiben.
HAtte auch sidekick und alles auf 1 Diskette, habe jetzt beim Umzug ca. 300 CD/DVD in den Müll getan.
Eine 1 GB Platte für 3500 DM, vom Kunden nach Jahren zurückgenommen, diente mir lange Zeit als Türstopper. ( Der Kunde musste noch einen SCSI ADapter kaufen für 450 DM )
Unser erstes Netzwerk-KIT 2 Karten 4500 DM Händlereinkauf, jeder nur 1 KIT ( nur ein Kreuz, für die Nicht- Religiösen … ) aber mit software und Steckern. Meine Frage war damals: Warum verbindet man Computer? Für den Preis kann ich ja auch einen kaufen.

Letztendlich hat aber die fortschreitende technik für Wirtschaftswachstum und Produktivitätssteigerung gedient, auch wenn einzelne Personen davon nicht profitieren.
Und Digitalkameras und Smartphone möchte ich nicht missen. Ic weiss nur, dass ich nach der WEnde bei den Expeditionen im Osten froh war, bei Rückkehr eine funktionierende Telefonzelle vorzufinden ( naja vollgepinkelt aber es ging )

Wenn ich jetzt Fotos mache, speichere ich die jpg Datei auch als nef ab, um da später Verbesserungen o.ä. vornehmen zu können. Platte ist noch nicht voll, was soll´s

gruß otto


Jürgen
18.5.2015 23:23
Kommentarlink

>> Dann kamen die IBM-PCs, die noch keine Festplatten hatten

Die IBM-PCs hatten anfangs nicht mal Diskettenlaufwerke, zumindest nicht in der Basisausstattung. Ich habe ein paar alte Prospekte aufgehoben. In der Beschreibung des “IBM Personal Coputers 01” vom Dezember 1984 ist als Ausstattung unter anderem aufgeführt:
– 64kb Hauptspeicher
– ein Anschluss für ein Kassettengerät
– Raum für ein oder zwei Diskettenlaufwerke


Bill
18.5.2015 23:46
Kommentarlink

das Windows 8.1 auf dem Tablet hier hat rd. 10 GB. Und ist noch viel nerviger (weil es versucht, mich zu bevormunden) als ein altes Win XP oder ein m.E stabiler laufendes Win2000.
Meine erste Festplatte war satte 20 MB gross….


ReinerH
18.5.2015 23:48
Kommentarlink

Als ich endlich meinen Amiga 2000 hatte, hochgemotzt auf 4MB und dann noch eine 50MB SCSI-Festplatte, da hatte ich alles, was ich brauchte und war glücklich. Naja, ein Flickerfixer musste dann auch noch her, die 50 Hz waren doch recht ermüdend.

Plötzlich schrie einer: “Ich hab Windows! Ich hab Windows!” Na und, sagte ich, hab ich alles schon lange, nur dass es bei mir auch funktioniert. Und wenn ich fertig bin, dann schalte ich einfach den Computer aus und gut iss.

Ich war glücklich und zufrieden. Dann kam einer, so Anfang/Mitte der 1990er, der studierte Informatik und sagte, er habe sich jetzt eine Festplatte mit einem GIGAbyte gekauft. Mir viel die Kinnlade runter und ich hatte ihn für verrückt erklärt. Er brauche das, meinte er, er mache das professionell.


Nobby
19.5.2015 0:18
Kommentarlink

Ihr seid alle so jung:
Ich hab 1964 meine Banklehre bei einer kleinen Raiffeisenbank begonnen.
Das war der Beginn der EDV. Lochkarte war angesagt! 80 Spalten!
Ich war sofort der EDV Fachmann. Ganz toll, Belege ablochen.
Dann mit dem Fahrrad den Karton zum fünf Kilometer entfernten Rechenzentrum bringen. Hoffentlich fällt er nicht runter!
Saldendaten mit Bewegungsdaten mischen Rums Rums. Drucker druckt neue Kontoauszüge, ratatratarata. Das ganze ca. Zwei Stunden.
Es war einfach klasse, da trafen wir uns Junge von den andren Bänkchen und hatten unseren Spaß.

Wieviel Lochkarten bräuchte man heut für ein hochauflösendes Foto?
Mag jetzt nicht mehr rechnen. Ein Lkw ?


Re:
19.5.2015 0:56
Kommentarlink

Nicht nur die Informatiker werden immer fetter… lol


FB
19.5.2015 1:21
Kommentarlink

> Lisp geht mir sowas von auf den Sack.
Wissen wir. Aber was sind deine Argumente?


Heavy
19.5.2015 2:04
Kommentarlink

@Hadmut:

[flame]
Du solltest das Hello World Programm in Ruby schreiben. Da braucht es bestimmt nur ein paar Bytes.
[/flame]

Es gibt mehrere Gründe dafür, dass das Programm so groß ist.

Erstens: Der verwendete Compiler Gc (Ubuntu/Debian Paket golang) erzeugt in diesem Beispiel ein statisch gelinktes Binary. Das heißt, es gibt keinerlei Abhängigkeit zu irgend einer Systembibliothek. Die einzige Systemvoraussetzung ist der Linux-Kernel in einer halbwegs aktuellen Version (ich glaube irgendwo ab 2.6.20; einige noch supportete RedHat Versionen kommen mit 2.6.18 und sind nicht supported). Es ist kinderleicht, ein solches statisch gelinktes Programm zu deployen; Entwicklungssystem und Produktionsserver brauchen sich kein bisschen ähnlich zu sein. In vielen Blogartikeln, in denen Firmen ihre Beweggründe für den Wechsel von irgend einer Skriptsprache oder von Java zu Go schildern, wird die einfache Deploybarkeit als einer der Hauptvorteile von Go genannt. Im Gegensatz zu deinem C-Beispiel enthält ein Go-Programm auch die Runtime mit einem Garbage Collector und dem Scheduler für die Goroutinen.

Der andere offizielle Compiler, GccGo, erzeugt per Default deutlich kleinere Compilate, die dafür von den üblichen Linux-Libraries (libc, libm, libpthread) sowie von der zu GccGo gehörenden libgo abhängen; letztere enthält die komplette Standardbibliothek und die Runtime. Wenn ich vor hätte, die ganzen GNU Utilities nach Go zu portieren, wüde ich dafür GccGo nehmen, damit die Vorteile der Shared Libraries unter Linux genutzt werden.

Zweitens: das Programm importiert die Bibliothek “fmt” für Formatierte Ein-/Ausgabe (etwa vergleichbar mit stdio.h in C oder iostream in C++). Diese Biblithek ist sehr leistungsfähig; man kann ihr Variablen jedwelchen Typs vorwerfen, und sie schafft es, daraus etwas sinnvolles print-fähiges zu machen. Dafür greift sie auf zahlreiche andere Packages der Standardbibliothek zurück; hier ist der Abhängigkeitsgraph: http://godoc.org/fmt?import-graph .
Wenn du das Builtin println() statt fmt.Println() verwenden würdest, fielen diese Abhängigkeiten weg und das Programm wird deutlich kleiner. Bei mir (Go 1.4.2 Linux/amd64) sind das 423 statt 1365 kB (gestrippt). Dafür ist println() deutlich primitiver.

Drittens: einer der Gründe für die große Filegröße ist, dass die Entwickler mit voller Absicht jede Debugging-Information, die das ELF Binärformat erlaubt, in das File packen. Dadurch sind die Stacktraces, die bei einem abgestürztem Go-Programm oder beim Aufruf von panic() erzeugt werden, sehr aussagekräftig. Je mehr man davon wegschneidet, werden die Binaries kleiner, aber die Stacktraces aussageloser. Das bedeutet aber auch, dass längst nicht alles, was in den Files steckt, ausführbarer Maschinencode ist. Im RAM belegt ein Go-Programm nur geringfügig mehr als ein vergleichbares C++ Programm, auch wenn die Filegrößen anderes vermuten lassen. Und deutlich weniger, als ein vergleichbares Java, Ruby oder Python-Programm.

Und Viertens: Dass die Binaries trotzdem zu groß sind, und insbesondere von Go 1.0 bis 1.2 immer größer wurden, ist den Go Entwicklern bekannt. Einige der Ursachen dafür sind bereits identifiziert und beseitigt; z.B. dass in einem Linux/amd64 Binary auch Informationen landeten, die eigentlich nur für Plan9 relevant sind. Mit Go 1.3 hat die Filegröße daher wieder abgenommen. Siehe https://code.google.com/p/go/issues/detail?id=6853


phaidros52
19.5.2015 4:47
Kommentarlink

Jawoll! 10 MB Festplatte und schlappe 5500 DM. Da war man so um die 1982 echt der tollste Technikfreak im Block.


yasar
19.5.2015 6:57
Kommentarlink

> (Hadmut, 360kB bei DOS war schon doppelseitig (5.25?-DSDD). Die 720kB kamen erst mit den 3.5?-DSDD.)

Kam drauf an, ob man single oder double-density hatte, d.h. 40 oder 80-Track. Die 5,25-double density haben 720kB vertragen.


yasar
19.5.2015 7:19
Kommentarlink

Nochmal zum Thema 5,25″-disketten:

Die gab es single oder double-sided mit 40 oder 80 tracks (single oder double density) und dann später mit high density, wo dann mehr sektoren pro track draufpassten.

Beim PC gab es daher folgende Kapazitätsstufen für 5,25″-Disketten

180kB (SS/SD)
360kB (DS/SD oder SS/DD)
720kB (DS/DD)
1,2MB (DS/HD)

Beim AppleII und C64/VC20 hatten die 140kB bzw. 170kB (SS/SD) und mit Diskettenlochern (oder Schere) hat man die Kapazität verdoppelt.

Vei Apple-II und C64 haben noch eine Handvoll Disketten für alles gereicht, was man so wirklich brauchte. Spiele nicht mitgezählt.

Selbst beim Amiga kam man mit zwei Disketten aus. Trotzdem habe ich mir damals eine Seagte mit 80MB für 1200 DM gegönnt.


HF
19.5.2015 7:29
Kommentarlink

Nimm http://www.musl-libc.org/ !
Ein kleiner Pipe-Filter braucht dann wieder nur 4K Daten und 4K Stack, eine ein- oder zweistellige RSS-Anzeige springt geradezu ins Auge.
Das ist kein Spielzeugprojekt, inzwischen laufen Router und Alpine-Linux ohne glibc 🙂
Die Rants auf http://ewontfix.com/ sind auch lesenswert.


Monika
19.5.2015 8:27
Kommentarlink

Immer war früher alles besser. Seit Menschengedenken war man früher jung.


Jens
19.5.2015 8:42
Kommentarlink

“Mir gefällt C++ eigentlich ganz gut, aber was wirklich nicht geht, ist dieser Präprozessorwahnsinn mit #include;”

Vielleicht kommt ja irgendwann http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf


Fredi
19.5.2015 8:59
Kommentarlink

@Nobby: Mein Vater hat in seiner Diplomarbeit auch noch Lochkarten gebraucht. Eine war noch in einem alten Lehrbuch, das ich geerbt habe, und dient jetzt als Lesezeichen. Ich sollte eigentlich, bevor ich mich aus dieser Stadt und von dieser Uni verabschiede, noch zum Rechenzentrum gehen und fragen, ob die damit noch was anfangen können…



Btw: Meine erste Festplatte am Atari ST hatte 20 MB 😛 Dummerweise war die noch nicht über SCSI angebunden, sondern über das Atari eigene ASCI (http://www.atari-wiki.com/?title=ACSI,_SCSI_and_IDE).

Allerdings war das Ganze damals so unzuverlässig, das die HD ca. alle 4 Wochen die Grätsche gemacht hat und komplett neu formatiert werden musste. Aber dann musste man halt wieder 13 3.5″ Disketten von Hand aufspielen.

Ach ja, das war sowas, was ich damals schon gar nicht so toll fand. Nostalgie hin oder her.

PS: Hab das gute Stück heute noch. Hat die Größe von 2 flachen Schuhkartons (http://www.atari-computermuseum.de/pics/systeme/st/megafile.JPG).


Missingno.
19.5.2015 9:50
Kommentarlink

Bin ich froh, dass yasar schon etwas zur Schwabbel-Disketten-Kapazität angemerkt hat. Ich habe schon an meiner Erinnerung gezweifelt. Persönlich habe ich meist mit den 1,2MB zu tun gehabt, aber in meinem Keller finden sich irgendwo sicher auch noch 720KB und vereinzelt 360KB Disketten.

Passend zum Artikel, verlinke ich mal auf diese Hello, worlds. 🙂 Die habe ich irgendwann vor der Jahrtausendwende von einer Computerzeitschrift händisch digitalisiert (und jetzt noch einmal ausgebuddelt).


Slartibartfast
19.5.2015 10:11
Kommentarlink

Herrje… früher-war-alles-besser; das ist nicht einmal IT-spezifisch, sondern passiert eben, da auf den gebräuchlichsten bzw. forderndsten Einsatzzweck optimiert wird. Und der ist sicher nicht ein “Hello World” Programm.
Wie Du schon selber geschrieben hast, ist seit der Einführung von dynamischem Linken die Größe der libc nicht mehr besonders wichtig, da sie nur 1x im Speicher vorgehalten werden muss. Und dann ist es sogar speichersparend, wenn ich viele Funktionen in einer Shared Library habe, statt diese in jedem einzelnen Programm zu kopieren. Und bei einem Update muss ich nur die Shared Library tauschen und nicht alle Programme.

Wenn Du in einem Straßen-Auto mit Klimaanlage, Sitzheizung, Spurassistent, ABS und Sound-System Rennen fährst, beschwerst Du Dich sicher nicht, dass die Karre in diesem exotischen Einsatzfall zuviel Sprit verbraucht bzw. wegen dem unnötigen Zusatzgewicht der Rücksitzbank zu schlecht beschleunigt!


Fritz
19.5.2015 10:15
Kommentarlink

Mein erster Computer war eine Maschine mit der 8080 CPU, das Betriebssystem hatte ich in Buchform und konnte es vollständig durschauen und nutzen. Dann gab es den Atari und zwischenzeitlich mal einen Commodore. Der Beste war der Atari, dazu hatte ich alle verfügbaren Programme auf Diskette in einem kleinen Kinderkoffer. Den Atari hatte ich auch zeitweise am Arbeitsplatz eingesetzt um kleine Berechnungen von elektronischen Schaltungen grafisch auszuwerten und darzustellen. Ein effizientes Werkzeug zumal kleine Routinen für die aktuelle Berechnungen, Widerstandsnetzwerk etc., schnell mal programmiert werden konnten. Das war richtig gut und hat geholfen einige Probleme zu lösen, ein gutes Werkzeug das unauffällig im Hintergrund lief und keine Probleme machte.
Dann bekam ich einen PC und versuchte das gleich mit dem PC zu veranstalten. Es ging einfach nicht.
Der PC löste keine Probleme, er war eines.
Und das ist bis heute so.
Ich habe diverse teure Programmpakete benutzt aber für die geschilderte Art der Anwendung sind diese Programmiersprachen viel zu aufwendig und total überfrachtet.
Es fehlt an einfachen nutzbaren Computer, wie früher Atari.
Besonders für den Mittelstandsbereich in Werkstätten oder Labors könnte diese Geräte gut eingesetzt werden.


Tacheles
19.5.2015 10:52
Kommentarlink

Ne, Yasar, das verwechselst Du was.

Bei 5.25″ sind 180kB entweder SS/DD oder DS/SD. (90kB wären SS/SD.)

Die 1541 war ein SS/DD-Laufwerk (aber nicht SD!), darum dann der Locher für die Nutzbarmachung der zweiten Seite.

Es gab bei 5.25″ dann noch QD mit 96TPI statt der 48TPI von DD, aber außer der SFD1001 bzw. dem CBM8250. wären mir spontan keine QD-Laufwerke bekannt, die größere Verbreitung gefunden hätten. Da waren dann tatsächlich 720kB pro Disk machbar bzw. 360kB pro Seite. Aber das waren Exoten.

Und die “handvoll” Disketten war bei etlichen doch eine gute Sammlung und ging in die Hunderte — zumal erst ab 1985 Schwarzkopieren unter Strafe stand 🙂 Andererseits kostete so ein 10er-Pack 5.25″-Disketten anno 1985 auch noch lockere DM50.

Amiga ging zwar mit Disketten, aber machte mit Festplatte schon mehr Spaß … Genauso wie der Atari.

Die Preise kann sich heute sowieso keiner mehr vorstellen. Wenn ich dran denke, dass die 32kB-Erweiterung für meinen ZX81 bald teurer war als der Rechner selbst … oder was ich Jahre später für den A3000UX samt A2024-Monitor, 18MB-RAM-Vollausbau und 500er-Platte gezahlt habe.

So viel Geld nehmen heute höchstens noch Apple-Enthusiasten für einen Neurechner in die Hand.


Schwärmgeist
19.5.2015 11:17
Kommentarlink

Aah ja, der C64, den hatte ich leider nicht. War aber ‘ne geile Kiste. Ich konnte mir den nicht leisten, den hatten nur Kinder reicher Eltern. Meine Oma hatte dann irgendwann ein Einsehen und mir einen Atari ST geschenkt, auf vier MB habe ich selbst mit meinem Taschengeld aufgerüstet. Ach, das waren noch Zeiten … So langsam werde ich nostalgisch.

Es gab ja auch früher immer zwei Fraktionen. Die einen hatten den Amiga und wollten nur daddeln, die anderen hatten den Atari ST und wollten programmieren. Borland Turbo C auf dem Atari war für damalige Verhältnisse sensationell.


Knut
19.5.2015 11:20
Kommentarlink

Programmiersprachen schleppen schon einiges an Ballast in die Programme. In den 80ern war ich viel mit OS-9(/68k) unterwegs, da haben wir einige Programme direkt in Assembler geschrieben, so dass es mit knapp 100 Byte genug war. Für eine Zeile Text reicht das. Da gibt es dann keinen Argumentparser, keine formatierte Ausgabe und keine Debugsymbole, was allerdings bei einem Modul, was außer Modulheader und dem auszugebenden Text gerade mal 10 Byte oder so Code enthält, leicht zu verschmerzen ist.

Für die Hierarchie der eingebundenen Bibliotheken braucht man heutzutage fast ein Expertensystem. Insbesondere, wenn die Linker nicht intelligent sind, also einzelne Übersetzungseinheiten selektieren können, zieht eine Sonderfunktion in irgendeiner Nische der Bibliothek weitere Bibliotheken rein und so fort. Da lobe ich mir den alten Modula-II-Linker, der hat sogar nicht benutze Funktionen rausgeschmissen.

Es ist schon komisch, das ein Foto als RAW mehr Speicher belegt, als meine erste Festplatte als Betriebsystempartion hatte. Und im Gegensatz zu heute, hat die Größe gelangt und wurde nicht bei jedem Update mehr zugemüllt.


Rox
19.5.2015 12:18
Kommentarlink

Au, einer fällt mir noch ein: Nadeldrucker mit Endlospapier. Ich denk mir, der Text ist so elend lang, da tust du dir den Krach nicht an, starte also den Druckjob erst zum Feierabend (so 22 Uhr) und mache mich aus dem Staub.

Tja, heißer Sommer, Prenzlauer Berg Hinterhof und Fenster offen.

Au, hat das Ärger gegeben.


winselnde altinformatiker sind erbärmlich
19.5.2015 12:54
Kommentarlink

oh je wieder so ne nutzlosdiskussion ala wie gross ist ein hello word in sprache xy, abgespeckte standardlibs,…
sowas begeistert m.e. nur leute die nie grosse software geschrieben haben. wenn man das macht hat man nämlich ganz andere sorgen als “ich konnte das binary um 10kb kleiner machen”.
und darf nat. nicht “ich habe mit heimcoputer xy angefangen, diskettengrössen, meine erste fetplatte hat x bytes”. gesitig wohl alle in der verangenheit steckengeblieben und trauern diesen zeiten auch noch hinterher. ihr seid nicht nicht kaldarisch alt sonder auch geistig, was das schlimmste ist. bin selber mit c64 und 8086 gross geworden aber wen interessiert das? diesen zeiten trauere ich keine sekunde nach und ich finde auch ‘aufgeblasene’ javascriptseiten geil, ist ja auch ein dauerjammerthema hier. “protz meine webseiten kommen ohne jabvascript und tausend libs aus”. ja ganz toll, nur interessiert das keinen, am wenigsten den kunden und anwender die eben gewisse feaures haben wollen/gewohnt sind. könnt ja weiterhin in eurer softwarebaracken aus dem vorigen jahrhundert hausen und jeden softwarekrümel dreimal umdrehen und euch damit aufplustern, interessiert nur keinen, zeitgemässe software sieht nun mal anders aus.


Spruance
19.5.2015 13:21
Kommentarlink

Unser kleines Team hat in den 80ern auf MAI/Basic-Four-Rechnern mit 2x80MB Festplatten und 512 KB Hauptspeichern für ein Firmenkonglomerat Buchhaltung, Färbereisteuerung, Hochregalsteuerung und Lagerhaltung, 8, später 16 Bildschirmarbeitsplätzen, alle verbunden mit einer selbstgebauten DFÜ, geschrieben und betrieben.
Erste Maxime war “Wer einen Datensatz in die Welt setzt, muß auch definieren, wie man ihn wieder los wird”.
Aus dem Basic-IV wurde später BBX, mit dem man auf einem 286er mit 140MB Festplatte locker acht Bildschirmarbeitsplätze betreiben konnte. Sogar mit 80×24-Pixel-Windows. Ha!


Jan Lul
19.5.2015 14:48
Kommentarlink

Es fehlen noch die ersten “Netzwerke”, mit Nullmodemkabeln und x/y/zmodem oder Kermit als Protokoll. Nutze ich heute noch beim Embedded Basteln!

Und wenn du es wirklich winzigst und simpelst haben willst, dann versuche mal einen später vergossenen wireless sensor möglichst energiesparend mit Solarzelle, Goldcap und unter Ausnutzung aller Energiesparmöglichkeiten zu programmieren. Da lässt man jeglichen Anflug von (RT)OS besser gleich weg.


Joe
19.5.2015 15:27
Kommentarlink

Die gab es single oder double-sided mit 40 oder 80 tracks (single oder double density) und dann später mit high density, wo dann mehr sektoren pro track draufpassten.

Der PC unterstützte nie Single-Density-Laufwerke. Der originale IBM-PC wurde bereits (optional) mit DD-Laufwerk ausgeliefert und unterstützte Disketten mit 160/320 KB (40 Spuren mit 8 Sektoren pro Spur). Später wurde das dann softwareseitig nochmal auf 360 KB (9 Sektoren pro Spur) aufgebohrt.
Der IBM AT erhielt dann bereits ein HD-Laufwerk mit 1200 KB (80 Spuren) und damit war die Entwicklung bei 130mm-Disketten abgeschlossen.


Schwärmgeist
19.5.2015 17:22
Kommentarlink

Wenn ich mal angeben darf: Ich habe als Sechzehnjähriger auf dem Schneider CPC 664 ein Schachprogramm geschrieben, das in der Eröffnung total beschissen war, aber im Mittelspiel hat es mich umgehauen. Endspiel, so weit kam ich nie.


nullplan
19.5.2015 17:50
Kommentarlink

Willkommen in der wunderbaren Welt der glibc. Die ist einfach nicht für kleine Programme gedacht. Ich habe mir mal dietlibc und musl installiert und ein helloworld gegen jede der drei Bibliotheken kompiliert, die Symbole extrahiert und das ganze dann gestript. Alles auf AMD64. Ergebnis: Gegen dietlibc gelinkt ist das Ergebnis 2,8k groß und benutzt 53 Symbole, gegen musl gelinkt ist das Ergebnis 5,4k groß und benutzt 95 Symbole, gegen glibc dynamisch ist das Ergebnis 4,4k groß und benutzt 34 Symbole, und gegen glibc statisch sind wir bei 730k und 1955 Symbolen.

Ich bin leicht überrascht über musls schlechtes Abschneiden, aber naja. Dafür fehlen der dietlibc so viele Features…

Oh ja, und go hat natürlich auch noch das Problem, dass es die gesamte Runtime statisch linkt. Und da sind so Kleinigkeiten wie ein Green Thread Scheduler mit drin, etc.


Jan Lul
19.5.2015 18:31
Kommentarlink

wiedergefunden:
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

http://www.muppetlabs.com/~breadbox/software/elfkickers.html

Was für die, die das lernen wollen, irgendwie fehlt, ist irgendwie ein vorgeturntes Beispiel, wie man einen Lader und/oder ein Monitorprogramm programmiert, und wie das mit den Binärformaten ineinander greift.

Ich hatte(/habe?) ein Buch “Rechner modular. Der NDR- Klein- Computer, selbstgebaut und programmiert”, da hat man die ganze “Evolution” einmal durchgeturnt, in der Erstausgabe war sogar das Programmieren mit Kippschalterreihe und PC erhöhen vorgeführt.

Das lernt heute keiner mehr (so wie auch ich nie die CPU von einer PDP-11 auseinandergenommen und repariert habe). Beim Lerncomputer schlechthin, dem Raspberry Pi, ist der Lader auch als closed souce blob mitgeliefert… da sollen wir alle gar nicht hinschauen, denn an dieser Stelle wird uns unsere eigene Hardware irgendwann enteignet werden (per TPM/trusted_boot)


Andreas Leuner
19.5.2015 19:21
Kommentarlink

Hier: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html gibts mal ein Tutorial, wie man die Programme wieder kleiner bekommt 🙂


Andreas Leuner
19.5.2015 19:23
Kommentarlink

@Jan Lul: Oh Mist, Duplikat genau unten drunter gesetzt (Sorry)!


der eine Andreas
19.5.2015 19:51
Kommentarlink

o.T.
Neuer Gesinnungsterror:
Gleichstellung in Passau: Sportstudenten dürfen nicht fensterln
http://www.spiegel.de/unispiegel/studium/uni-passau-gleichstellungsbeauftragte-verbietet-fensterln-a-1034403.html
oder
http://www.welt.de/regionales/bayern/article141071612/Uni-Passau-findet-Fensterln-sexistisch.html

oder

https://www.facebook.com/sportstudenten.passau
Dort auch das Schwanzeinziehen von Prof. Dr. Burkhard Freitag, Präsident der Universität Passau


LeserX
19.5.2015 20:32
Kommentarlink

Kilobytes? Was ist denn das für ne Einheit?

Embedded läuft das mit 80 Bytes Progsize, 1 Byte RAM

main (){

UART1_Write(“Hello World”);
while(1);

}

Embedded C (MikroC for Pic)

Braucht auch keinen PC sondern nur nen Terminal;-)


Horsti
19.5.2015 21:01
Kommentarlink

“Aah ja, der C64, den hatte ich leider
nicht. War aber ‘ne geile Kiste.”

Nee, war er nie. Definitiv nicht, denn den hatten alle. Was uncooleres als einen C64 gab es, abgesehen vom Schneider CPC nicht. Der was auf sich hielt, hatte zu Hause mindestens einen Atari, oder noch viel besser, einen Sinclair stehen, den Computer der Bastler und Programmierer. Für den ZX Spectrum gab’s den ersten Fußballmanager, einen der ersten Ego-Shooter und natürlich Lords of Midnight, ein Grafik-Adventure mit 32000 views, reingestopft in 48 Kilobyte, von denen glaube ich nur 42 zur Verfügung standen. Spiele ich heute noch gerne, da man sich wie in GTA frei bewegen kann.Hab’ damals Z80-Programmierung versucht, war aber zu blöd dafür und bin bei Basic und Turbo-Pascal geblieben. Mein letzter Sinclair war dann der QL mit seinen Microdrives mit jeweils 100 Kilobyte Speicherplatz. Immerhin war damit schon vor 30 Jahren ein kleines Netzwerk möglich, denn man konnte glaube ich bis zu 64 Microdrives gleichzeitig anschliessen und hatte somit unerreichte 6,4 MB externen Speicherplatz. Mir war ein Sinclair immer lieber als ein C64. Letzterer war das Produkt einer Big Business AG aus Übersee mit zweifelhaftem CEO, ein Sinclair das Produkt eines verschrobenen Erfinders aus Cambridge, das hatte, trotz, oder gerade wegen der Hardware-Mängel viel mehr Charme.


nullplan
19.5.2015 21:03
Kommentarlink

@Knut: Anscheinend kennst du heutige Compiler und Linker nicht. Zum einen sind die zum statischen Linken optimierten Libs so geschrieben, dass jede Funktion in einer eigenen Datei ist, weil der Linker beim statischen Linken nur die referenzierten Objektdateien hineinzieht (und glibc ist so grottig gemacht, dass, obwohl nur drei Symbole direkt verwendet werden, insgesamt 1955 Symbole hineingezogen werden), und zum Anderen gibt es beim GCC -ffunction-sections und -fdata-sections, mit denen jede Funktion und jedes öffentliche Datenobjekt seine eigene Sektion bekommt, und beim GNU ld gibt es –gc-sections, was nicht verwendete sections wegwirft.


nochn alter Sack
19.5.2015 23:53
Kommentarlink

wen interessiert dieses C-Gewichse denn? Doch nur wenn man auf Mikrocontroller herummurksen muss. Ansonsten nimmt man sowas wie Java oder Scriptsprachen. Mit letzterem erledigte ich 90% der Allerweiltsaufgaben in einem Bruchteil der Zeit die ich mit C oder dem noch schrottigeren C++ bräuchte.

Die grösse des Binarys oder Scripts interessiert doch kein Schwein, eher der Speicherverbrauch und dann auch nur wenn es was grösseres wird wo mit massig Daten hantiert wird, da geht man dann auch mal ans Optimieren aber sonst? Hauptsache die Anforderungen sind erfüllt, die Tests laufen durch, fertig ist der Lack. Grösse des Binaries? Interessiert mich heute nicht mal mehr auf einem Mikrocontroller weil die genug Speicher haben, die Versionen mit dem maximalen Speicher sind oft noch günstiger weil in höheren Stückzahlen produziert und auch besser lieferbar, da ist die Wahl einfach.


Jan Lul
20.5.2015 9:11
Kommentarlink

@nochn alter Sack:

Mich interessiert es.
Weil wenn man es nicht alles selbst macht, kommen Sachen raus wie die Espressohandhebelmaschine, die das Erreichen der Temperatur nicht bemerkt, wenn man nicht kurz die Dampfdüse aufmacht, weil der PC nur beim Wiederabstellen der Dampfdüsenpumpe an dem if vorbeikommt, was die Temperatur checkt.

Oder die Dampfabzugshaube, deren Bedienfeld sich aufhängt, was ärgerlich ist, weil man den Reset nur mit der Küchensicherung durchführen kann.

Und ja, Größe ist nicht alles, aber Softwareadipositas ist ein einfacher Indikator für mangelnde Sorgfalt und ein ziemliches Indiz dafür, dass in der Softwaremannschaft niemend dabei ist, der das Gesamtsystem überblickt, lauter Subsystem”deppen” mit API-Scheuklappen.

Der Airbus A400M ist sicher auch so entstanden.
Und dann hat es wieder keiner kommen sehen…

Spätestens, wenn wegen so etwas Leute zu Schaden oder umkommen, sollte mal die Projektverantwortlichen einsitzen müssen – der Ingenieur der sich unter Druck setzen ließ, und der MBA der den Druck ausübte!


Wolfgang
20.5.2015 9:45
Kommentarlink

Ich vermute, genau das war der Punkt… für jeden Kleinscheiß wirft der heutige “Informatiker” erst mal Eclipse an, dengelt den Code irgendwie so zusammen, daß es halbwegs funktioniert und fertig. Codequalität? Speicherverbrauch? Sicherheit? Ach was, funktioniert doch!

Bis dann der erste Benutzer mit einer “Allerweltsaufgabe” den Code-Klotz zum Einsturz bringt. Dann heißt es “Willkommen im Tal der Tränen”, weil der Klotz, obwohl eigentlich nicht besonders komplex, kaum entwanzbar ist.


Missingno.
20.5.2015 14:55
Kommentarlink

@Schwärmgeist

Wenn ich mal angeben darf: Ich habe als Sechzehnjähriger auf dem Schneider CPC 664 ein Schachprogramm geschrieben, das in der Eröffnung total beschissen war, aber im Mittelspiel hat es mich umgehauen. Endspiel, so weit kam ich nie.

Ich entnehme dem, dass du ein eher mittelmäßiger Schachspieler bist/warst. 😉


frieslandjogger
20.5.2015 15:44
Kommentarlink

@Jan Lul, @Wolfgang

Genau. Spätestens bei wirklich kritischer Software (und da fallen mir jede Menge wichtige Steuerungen ein) ist Schluss mit “Software by wizard” und ähnlich schönem Spielzeug.

Übrigens war mal per Lizenzbedingungen explizit verboten, Atomkraftwerke mit JRE zu steuern. Warum wohl?


Knut
21.5.2015 10:49
Kommentarlink

@nullplan
Tatsächlich habe ich mich seit mindestens 10 Jahren nicht mehr darum gekümmert, wie es Linker heutzutage machen. Die C-mäßige Aufteilung in Module gab es aber schon immer. In den 90ern gab es schon Linken auf Zwischencodeebene mit nachfolgender Gesamtoptimierung.
Eine sehr gute Methode um genau den Code im Endprodukt (*) zu haben, den man braucht, aber auch eine die Rechenzeit ohne Ende frisst. Ende der 90er noch geeignet Übersetzungsläufe über Nacht machen zu lassen.

(*) Mein Topergebnis: ein int lng = strlen(“DEU”) wurde durch lng = 3 ersetzt. Damit kann man lesbare Software machen, ohne Performanceeinbußen.

Das braucht man alles nicht zu wissen. Das Ergebnis spricht für sich: rund eine Million überflüssige Bytes. Entweder werden die niemals ausgeführt, wurden also auf Grund schlechten Linkerdesigns im Ergebnis abgeladen, oder es wird Code ausgeführt, der zum Ergebnis nicht relevant beiträgt, also Zuckerbäckercode.

Ist die Codegröße nun relevant?
Wenn es einfach tote Masse ist, spielt sie keine Rolle, es ist einfach nur traurig, das der Linker das nicht kann.
Ist es Code, der überflüssige Aktionen auslöst, kann es schon nerven, da dadurch jeder Programmstart ein bisschen verzögert wird. Wenn man auf die Schnelle was skripten will und meist weniger als 1 ms eigener Code läuft, weil das Merkmal nicht vorhanden ist, aber 2 ms ungewollte Initialisierung laufen, ist das unschön.


Missingno.
21.5.2015 10:50
Kommentarlink

Übrigens war mal per Lizenzbedingungen explizit verboten, Atomkraftwerke mit JRE zu steuern. Warum wohl?

Weil es sonst mindestens einen Idioten gegeben hätte, der das macht. Schließlich schaffen es Entscheidungsträger mit einer unglaublichen Sicherheit das falsche Werkzeug zum falschen Zweck zu benutzen und sich zu wundern, wie ihnen alles um die Ohren fliegt. (Was aber egal ist, weil sie dadurch höchstens eine fette Abfindung kassieren.)


Daniel Frey
21.5.2015 11:35
Kommentarlink

Hach ja, der gute alte C64. Ich fand den Klasse. Im übrigen steht der hier neben mir im Büro in ner Kiste und daneben die Diskettenbox mit 20 Disketten. 🙂

Wenn ich nur wüsste an welchen Fernseher ich den anschliessen soll. Meine finden den entsprechenden Kanal einfach nicht. 🙁


Manfred P.
21.5.2015 12:06
Kommentarlink

C-Gewichse interessiert immer dann, wenn es auf die Performance ankommt.

Man überlege sich mal, dass für die alten Airbus-Steuerungen Fortran genommen wurde. Hochgradig performant, und die Teile sind auch geflogen.

Inzwischen macht man das Ganze in C.

Kann aber problematisch werden, wenn man Leute dransitzen hat, die kein Speichermanagement beherrschen.

Ohne tiefgehendes Verständnis der zu steuernden Hardware ist das sowieso ein müßiges Thema. Diese Leute bauen dann eh früher oder später großen Mist.

Die Leute denken scheinbar, ihre dämliche Windows-Kiste auf dem Schreibtisch sei die gesamte Welt des Computing.

Die glauben wohl, der Hochfrequenzhandel an den Börsen wird auf einer Windows-95-Kiste abgewickelt.

Die denken wahrscheinlich, eine Bank erledigt die Buchführung auf einer Windows-Kiste im Keller.

Solche Leute labern dann dumm herum.

Wie so ein verranzter Webentwickler, der mich mal gefragt hat, warum ich eine parallele Optimierungssoftware, die auf einem Cluster laufen sollte, nicht in JavaScript geschrieben habe, sondern das mit C++ mache. Schließlich wären heutige Rechner so schnell, dass man doch alles mit JavaScript im Browser machen könne.

Das war einer, der Physik nicht gepackt hat und dann auf Fachinformatik umgesattelt ist. Jedenfalls hatte ich danach keine Fragen mehr, wieso er Physik geschmissen hat.

Aber was soll’s. Lasst uns doch OpenGL-Treiber in Ruby schreiben, und dann schauen, welche Frameraten die Gamer bekommen.


Manfred P.
21.5.2015 23:23
Kommentarlink

@Daniel Frey

Früher war das Kanal 36, wie der Videorekorder.


Manfred P.
21.5.2015 23:26
Kommentarlink

>Übrigens war mal per Lizenzbedingungen explizit verboten, Atomkraftwerke mit JRE zu steuern. Warum wohl?

Soweit ich weiß, werden die Oberflächen jetzt mit Python programmiert, vermutlich PyQt.

Hat mir zumindest einer erzählt, der für einen großen Hersteller von Kernkraftwerken arbeitet.

Die Steuersoftware selbst ist wohl C oder C++, und unterliegt strengsten Qualitätsauflagen.


Jan Lul
22.5.2015 10:13
Kommentarlink

“Spätestens bei wirklich kritischer Software (und da fallen mir jede Menge wichtige Steuerungen ein) ist Schluss mit…”
Mir wird das alles zu Digital und zu vernetzt in letzter Zeit.
Das IoT wird von mir ja immer als Io0T (Internet of 0wned Things) bezeichnet, weil dereinst jeder Mensch auf diese Kugel 20…50 schlecht oder nicht updatebare Dinge sein eigen nennt auf welchen 3-10 Jahre alte ungefixte Systeme laufen – Mahlzeit. Das wird das Substrat sein, auf welchem die Zecken der Dienste ihren Lebensraum finden.

Und wer entscheidet was “wichtig” ist? Meine Espressomaschine ist sicher nicht wichtig, aber die 2l heisses unter Druck stehendes Wasser da drin können doch einen Menschen verbrühen, erblinden, wenn der Kessel platzt, wohl auch töten.

Und auch Digital muss nicht alles sein: heute wird für jeden Winzsensor eine MCU an den Start gebracht, weil niemand mehr Analogtechnik gelernt hat. Dabei sind die bei gleichem Aufwand oft besser und flinker.
Die Digitalisierung bis ins kleinste wäre in Ordnung, wenn die lokale Intelligenz am Sensor auch noch dessen Drift, Fehler, Ausfall melden würde und das in die Regelung einginge, aber das ist nirgends der Fall, genau diese Funktionen werden von den MBAlern weggespart. Du sollst ja neu kaufen, und nicht das Gerät fragen wo es weh tut und dann das kleine Teil für 2.37€ auswechseln.

“Übrigens war mal per Lizenzbedingungen explizit verboten,
Atomkraftwerke mit JRE zu steuern. Warum wohl?”

Tippe auf die garbage collection, die war in den Anfängen und bei damaligen RAM-Größen übel und hat eine Anwendung schon mal 12 min stillgelegt, wenn ihr danach war, und hat sich durch nichts davon abhalten lassen.

Und ein Atomkraftwerk ist halt mal eine am Explodieren gehinderte Atombombe, in der zwei e-Funktionen gegeneinandergestellt und in einem bestimmten Arbeitspunkt gehalten werden, da entscheiden Millisekunden.

Seit Fukushima mich mal richtig eingelesen und seitdem ich über die Sensorik am Reaktor bzw. deren Indirektion Bescheid weiß, wundert mich, dass nicht schon mehr von den Dingern hochgegangen sind.


Knut
22.5.2015 11:41
Kommentarlink

“Die Steuersoftware selbst ist wohl C oder C++, und unterliegt strengsten Qualitätsauflagen.”

Das würde mich wundern, aber bei Siemens geht halt alles.
Die Qualitätsauflagen sind nichts als ein Eintrittsgeld in den AKW Zuliefererclub. Das übliche ist die Stilkontrolle und dann noch ein paar Punkte in der Semantik. Manchmal überlegt man sich, ob man da nicht jedes Programm mit automatisierter Umformatierung durchbekommt.

Wenn man mal drin ist, dann wird richtig Reibach gemacht. Mein Kollege, der ins AKW gewechselt ist, meinte, unter einem Faktor fünf zu normaler Leittechnik wird da nichts angeboten. Normale Leittechnik == Steuerung Stromverteilnetz Sindelfingen oder Hamburg


Manfred P.
23.5.2015 1:01
Kommentarlink

>Und ein Atomkraftwerk ist halt mal eine am Explodieren gehinderte Atombombe, in der zwei e-Funktionen gegeneinandergestellt und in einem bestimmten Arbeitspunkt gehalten werden, da entscheiden Millisekunden.

Ähm, nein. Das ist vollkommen falsch. Für eine Atombombe braucht man hochangereichertes Uran 235, Reinheitsgrad >95%. In kommerziellen Atomreaktoren ist das U-235 auf 2-3% angereichert. Da ist nichts mit Atombombe.

Das schlimmste, was passieren kann – und das ist schlimm genug – ist, dass die thermische Kontrolle verloren geht und die Brennstäbe schmelzen. Im Sicherheitsbehälter baut sich ein Gasüberdruck auf, der abgelassen werden muss, und dadurch gelangt dann auch Radioaktivität nach außen. So geschehen in Harrisburg und Fukushima.

>Seit Fukushima mich mal richtig eingelesen und seitdem ich über die Sensorik am Reaktor bzw. deren Indirektion Bescheid weiß, wundert mich, dass nicht schon mehr von den Dingern hochgegangen sind.

Dass in Fukushima ein starkes Erdbeben war und ein Tsunami die Notstromversorgung ausgeknockt hat, haste aber schon mitbekommen, oder?

Und was da so spektakulär explodiert ist, waren nicht die Brennstäbe, sondern der Wasserstoff, der sich im Sicherheitsbehälter gebildet hatte und abgelassen werden musste.

Außerdem gab es ein Dampfrecycler, der bei einer Notabschaltung manuell hätte wieder eingeschaltet werden müssen. Das hätte die Zeit, für die Kühlwasser zur Verfügung gestanden hätte, um mehrere Stunden verlängert. Daran dachte aber keiner.

Soviel zum Thema “Man kann ja alles googeln”, vor allem nach Tsunami und Stromausfall.


Manfred P.
23.5.2015 1:04
Kommentarlink

>Das würde mich wundern, aber bei Siemens geht halt alles.
Die Qualitätsauflagen sind nichts als ein Eintrittsgeld in den AKW Zuliefererclub.

Klar, den Ingenieuren ist nämlich überhaupt gar nicht klar, wie gefährlich ein Unfall in einem Kernkraftwerk ist, deswegen pimmeln die nur rum.


Manfred P.
23.5.2015 12:20
Kommentarlink

>Das würde mich wundern, aber bei Siemens geht halt alles.
Die Qualitätsauflagen sind nichts als ein Eintrittsgeld in den AKW Zuliefererclub.

Eigentlich habe ich mich über dieses Gelaber noch nicht genug aufgeregt. Wenn man in der Ostzone lebt und dort keinen Kanalanschluss hat, braucht man eine Kleinkläranlage auf dem Grundstück.

Selbst so ein Teil darf man nicht einfach so einbuddeln, sondern es darf nur eine Anlage mit bauaufsichtlicher Zulassung eingebaut werden, und damit die erteilt wird, muss der Hersteller bei einem von der EU zertifizierten Prüfinstitut einen 38-Wochen-Funktionstest absolvieren, um sicher zu stellen, dass keine Scheiße ungeklärt ins Grundwasser gerät. Bis ein Hersteller so eine Zulassung kriegt, vergehen Monate und meistens 1-2 Jahre.

Aber die Software für ein Kernkraftwerk, die kann man einfach mit indent formatieren und dann einsetzen. Ist klar.

*facepalm*


Knut
23.5.2015 13:34
Kommentarlink

@Manfred P

Ich habe die Software mit der Software für das Stromverteilnetz verglichen. Nur mal ein Tipp: Welche Software kontrolliert denn den Leistungschalter für die 380kV Leitung? Und was passiert, wenn der sich bei Vollast irrtümlich öffnet?

Der Käufer darf das ganze Leitsystem zurückgeben, wenn die Verfügbarkeit nicht erreicht wird oder gar ein Fehler auftritt. Die Kunden summieren übrigens Verbindungsausfälle und sonstige Störungen minutenweise. Die Wartung zählt natürlich mit, die Anlage muss halt gewartet werden, wenn sie läuft.

Der Kollege, der jahrelang im Leitsystembereich gearbeitet hat, hat mir versichert, dass die Technik und SW im AKW nicht fundamental besser ist. Das Zulassungsbrimborium ist aber gewaltig. Das leisten sich nur ein paar Firmen und die haben dann ein Quasimonopol. Die Ingenieure im AKW und auch die der Zulieferer wissen schon um was es geht. Das ist beim Stromverteilnetz aber genauso.

Ein AKW ist ein großer, bürokratischer Betrieb. Dort wird sorgfältig nach den Vorschriften gearbeitet. Das sichert der Software ein gutes Niveau. Es gibt aber nicht die Übermenschen als Programmierer und auch nicht den supergenialen Prozess, der die perfekte Software erzeugt. Das ganze bewegt sich auf guten Industrieniveau, so wie bei vielen anderen Einsatzgebieten auch, wo man für Fehler zahlen muss.


Manfred P.
23.5.2015 15:58
Kommentarlink

@Knut

> Es gibt aber nicht die Übermenschen als Programmierer und auch nicht den supergenialen Prozess, der die perfekte Software erzeugt. Das ganze bewegt sich auf guten Industrieniveau, so wie bei vielen anderen Einsatzgebieten auch, wo man für Fehler zahlen muss.

Das habe ich auch nicht behauptet. Wie Du schon sagst, ist die Zulassung sehr aufwendig und das sichert ein Niveau, das einigermaßen besser ist als eine hingeklierte Software.

Mein Kumpel ist ein ehemaliger Studienkollege von mir, der macht in Simulationen, nichts sicherheitskritisches, aber der meinte, die Steuersoftware für ein AKW abgenommen zu kriegen ist ein riesiger Aufwand.