Gut, an der Hardware, die ich habe, bin selbst schuld - Ryzen, Polaris-Grafik (RX460), Gigabyte board. Im Prinzip alles recht schön. Aber die Software ist unfertig (hoffentlich nur die).
Zusammen ist das Ganze derzeit kaum zu schlagen. Bisher gut 500mal kernel panic. Aber der kernel 4.11.3-1 hat heute immerhin einen harten Belastungstest überstanden (ein paar Stunden Vollast, alle Kerne ziemlich vollbeschäftigt, mindestens 6-8 der threads zu 100%). Na gut, eine Stunde danach folgte ohne jede Last ein Absturz.
Möble gerade ein uraltes C++ Programm von mir auf, u.a. parallelisieren. Auf dem Ryzen könnte laufen, was vor 32 (Pascal) bis zuletzt vor ~10 Jahren (C++) noch chancenlos war.
Schön langsam verstehe ich es auch wieder - u.a. C++ zwang ja schon lange zu abenteuerlichen Verrenkungen: Templates-Klassendefinition-Speicherverwaltung-Inline-Verhau mit Start i.w. aller Leistungen durch OpenGL..). Wobei pthreads auf meinem alten Monoprozessor auch Probleme schufen - aber andere.
Verblüfft war ich schon, als ich feststellte, daß der g++ (4.8) der 42.2 zu alt war für mein antikes C++-Programm (im Gegensatz zum g++ 5.0 von Tumbleweed).
Aber geschockt hat mich heute etwas anderes: die C++-Stream-Eingabe ist immer noch nichteinmal in der Lage, Daten von Standarddatentypen, die die identische Version der C++-Stream-Ausgabe aktuell ausgegeben hat, wieder einzulesen.
Genauer gesagt: sie war es vor 10 Jahren nicht ohne Bauchaufzug und ist es heute eher noch weniger als damals.
Nur weil zufällig ganz am Anfang normale komplexe Werte wie (inf,inf) (6.26463137970409399049e+00,-inf) 2539 1399 drinstehen.
Da werden großzügig ein paar Werte überlesen und dann alles falsch zugeordnet ...
Ist aber auch kein Wunder, solange sich Benutzer alles gefallen lassen. Nicht nur Nassauer wie ich, die gern kostenfreie Software nutzen, sondern erst recht die, die saumäßig viel blechen. Die letzteren lassen sich übrigens aus voller Überzeugung alles gefallen. Genauer gesagt die zuständigen Manager. Und nutzen deshalb übrigens weit lieber kostenpflichtige Betriebssysteme. Genauer gesagt sie drücken sie ihren Mitarbeitern auf.
Denn nach alter und aller Erfahrung ist Software umso wertvoller, je schlechter sie ist.
Werterhöhend sind:
- schlechte Doku
- schwierige und teure Einarbeitung
- schlechte Bedienbarkeit
- schlechter Aufbau
- Softwarefehler
- Beschreibungsfehler
Zumindest solange, solange mit dieser Software Erfahrene damit noch zurechtkommen.
Das ist ganz einfach zu erklären. All dies hebt ungemein den Wert derer, die das schaffen.
Natürlich braucht man immer gute Fachleute - denn natürlich bedienbar ist Software sowieso nicht.
Derart wertvolle Software braucht eine weit größere Zahl an zudem besser bezahlten Experten, und die sind wiederum dringend auf all obigen Qualitäten angewiesen:
- Softwareersteller
früher galt: 90% der Kosten für Software fallen nach der Markteinführung an - Schulungsexperten
was täten die, wenn Software einfach, einheitlich und logisch klar zu bedienen wäre? - Berater
für die fängt das Geschäft damit an, daß Produktbeschreibungen weit, weit unter der Aussagekraft von Abstracts sind.
wesentlich ist zudem, daß für jedes Produkt mindestens mehrere Monate Einarbeitung nötig sind, bis man erkennt, daß es für den Einsatzzweck völlig ungeeignet ist, optimal, wenn dies erst nach Einarbeitung der ersten tausend Firmenmitarbeiter erkannt wird - Softwaredienstleister
wovon würden die leben, wenn jeder das Ganze bedienen und vielleicht sogar am Laufen halten könnte - Verkäufer
was sollten die verkaufen, gäbe es nur einfach bedienbare, fehlerfreie, für den Einsatzzweck passende Software gäbe?
und all das auf verschiedenen Levels.
Gute Dokumentation zu erstellen geht zudem saumäßig ins Geld.
Zudem ist für unterschiedliche Zielgruppen Unterschiedliches gut:
- exakte Produktanforderungen (Außer Mode gekommen: Viel zu teuer! Lassen keinen Raum für 'wertsteigernde' Firmenspezialitäten!)
für Produktersteller perfekt, für Anwender völlig ungeeignet. Wozu auch? Ein Compilerschreiber z.B. braucht keine Ahnung von der Programmiersprache zu haben - außer bei einem Bootstrapcompiler - Schnittstellenkataloge/Pflichtenhefte mit genügend unverbindlichem Spielraum für u.a. firmensspezifische Interpretation und wertsteigernde, da kompatibilitätsverhindernde Zusätze
Letzteres ist so ziemlich alles, was heute an Doku vorhanden ist. Am effizientesten entsteht diese automatisch beim Basteln an einer Modellimplementation. Hat den Vorteil, daß sie niemand außer höchstens der Implementierer wirklich versteht
Bisher ist nichts für Anwender geeignetes dabei. Das kommt jetzt: - Verkaufsprospekte
für den Anwender als Glanzpapier zum Ködern geeignet - Einführende Werke
je nach Adressaten: für Softwareerfahrene möglichst dünn, knackig und informativ, für Anfänger vom pädagogisch erfahrenen Fachkenner aufbereitet
vor 45 Jahren bewarb ich mich auf eine Stelle bei einem englischsprachigen Rechnerhersteller. Erst beim Einstellungsgespräch stellte es sich heraus, daß die Aufgabe Anwenderdokuerstellung war. Gesucht waren Grundschullehrer ohne Ahnung von DV - damals billig, da viele arbeitslos - 6 Wochen Einschulung, danach Handbucherstellung im Seitenakkord. Damals habe ich erfahren, warum (damals nur englischsprachige) Einführungen so gewichtig sind. Bis heute wirken sie dank inzwischen immer höherer homöopathischer Inhaltsverdünnung immer effizienter - Handbücher
Nachschlagewerke, so aufbereitet, daß möglichst jede Frage so knapp wie exakt beantwortet wird, so aufbereitet, daß Randomzugriff möglich ist. Mit allen nötigen Verweisen, denen jedoch kaum je nachgegangen werden muß.
Braucht zur Erstellung nicht nur exzellente Spezialisten mit hervorragender Analysefähigkeit, Produktübersicht und klarer Ausdrucksweise.
das letzte echte Handbuch habe ich vor über 35 Jahren gesehen. Ein dicker Leitzordner mit exakter Schnittstellenbeschreibung, nach der ich ein Tool für ein neues System programmieren mußte, 2 Monate Arbeit, keinerlei Testumgebung vorhanden. Anforderung: Produkt einsatzfähig unmittelbar nach Lieferung des Systems. Hat fast auf Anhieb geklappt (zwei Stunden Probelauf im Singleusermode, eine Woche Nacharbeit, 2. Test o.k.).
Erfahrungsgemäß drücken sich Softwareersteller gern vor der leidigen Aufgabe der Dokumentationserstellung. Da schließe ich mich durchaus selbst mit ein.
Softwareersteller sind in der Regel höchstens bereit und in der Lage, Doku für Eigenbedarf zu erstellen - also nichteinmal vollwertige Entwicklerdoku.
Im Bereich kommerzieller Software begann also vor 45-50 Jahren ganz langsam die Optimierung im Hinblick auf Werthaltigkeit von Software.
Schön langsam kulminiert diese Entwicklung.
Das ergibt extrem werthaltige Software. Denn sie fördert immer neue Sicherheitslöcher, damit die Notwendigkeit, sich täglich damit auseinanderzusetzen, die Software upzudaten. Und weckt zudem das vertriebsfördernde Bewußtsein, daß Software sich ständig ändern muß. Überaus förderlich ist das für das Kostenbewußtsein - also die extrem hohen Kosten - in Bereichen wie z.B. Kranbau und Flugzeugkonstruktion, in denen z.T. noch nach 50 Jahren vor Gericht der Nachweis erbracht werden muß, daß die ursprüngliche Konstruktion fehlerfrei nach dem damaligen Stand der Technik war.