Forum: Mikrocontroller und Digitale Elektronik Fertige Bibliothek oder selber schreiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 0815 (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Hi,

was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen 
drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller 
verwenden oder selber schreiben? Was ist gängig in der Industrie?

Gruß

von N. M. (mani)


Bewertung
0 lesenswert
nicht lesenswert
Das kann man so pauschal nicht sagen.

Es gibt mehrere Faktoren wie personeller Zeitaufwand vs. Performance vs. 
Speicherbedarf.

Um hohe Performance zu erreichen braucht es oft viel personellen 
Zeitaufwand. Zusätzlich ist es oft gebunden an eine Plattform da evtl in 
ASM.
Und Performance steht immer in Konkurrenz mit Speicher. Da gilt es 
alleine schon abzuwägen wie Performant darf es denn sein und wieviel 
Speicher steht zur Verfügung.

Selbst bei verhältnismäßig leistungsstarken Systemen hat man oft die 
Wahl. Nehme ich zum Beispiel ein glibc oder ein uClibc für mein Embedded 
Linux?

von Orikson (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Definiere "besser". Meistens bedeutet besser, dass es mit wenig 
Zeitaufwand gut und stabil laufen soll. Deshalb, und da Zeit deutlich 
teurer ist als Speicher, werden die fertigen Bibliotheken in den meisten 
Fällen eingesetzt. Außerdem wurden diese schon ausgiebig getestet, da 
tausendfach genutzt.

von Olaf (Gast)


Bewertung
-16 lesenswert
nicht lesenswert
> Was ist gängig in der Industrie?

Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man 
Bibliotheken einsetzen.

Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein. Wegen 
Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in 
Libaries. Und ganz wichtig, du weisst nicht wie eine fremde Libary mit 
deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder 
Speicher braucht.

Allerdings sammeln sich in Firmen mit der Zeit auch eigene Libaries an 
welchen den internen Standards entsprechen. Sowas setzt man natuerlich 
gerne eine.

Ausnahmen sind dann noch Libaries die man von Fremdfirmen einkauft. Die 
werden aber dann auditiert und bekommen den Arsch aufgerissen wenn es 
Probleme gibt. Soll heissen es gibt da jemanden der sich verantwortlich 
fuehlt.


Olaf

von Βιβλιοθηκονόμος (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Man sollte zumindest zum Lernen eine Bibliothek selbst geschrieben oder 
zumindest angefangen/konzipiert haben, weil man IMHO so am besten 
mitbekommt was in eine Bibliothek gehört und was nicht.

Und wenn man eine vorgefertige Bisbliothek übernimmt dann ist immer noch 
eine zur Pflege, Überprüfung und Anpassung der selben zu benennen. Auch 
bei einer Standardbibliothek muss man wissen was man tut.

von Irgendwer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
> Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h)

Wenn du damit die Funktionen meinst die ganz offiziell zum 
Sprachstandart der verwendeten Sprache gehören sind diese natürlich 
immer vorzuziehen.

Bei komplexeren Funktionen sieht es schon etwas differenzierter aus. Da 
stellt sich immer die Frage nach den Kosten für die Selbstentwicklung 
gegenüber dem Zukauf. Wenn man was bestimmtes öfters benötigt und die 
Eigenentwicklung auch nicht zu aufwendig ist kann sich das selber machen 
aber durchaus rechnen weil man diese meist recht schnell nach den 
eigenen Bedürfnis eines neuen Projektes anpassen kann und man auch nicht 
so schnell Probleme mit irgend welchen Lizenzsachen bekommt.

von Βιβλιοθηκονόμος (Gast)


Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
> Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h)

Auch Standardbibliotheken sind bekannt für Sicherhheitslücken
https://en.wikipedia.org/wiki/C_standard_library#Concepts,_problems_and_workarounds

schon deswegen sollte man eine Optimierung an das eigene System nicht 
ausschliessen. Oft lauern die Lücken in Codeabschnitten, die man nicht 
wirklich braucht.

von Falk B. (falk)


Bewertung
14 lesenswert
nicht lesenswert
0815 schrieb:
> Hi,
>
> was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller
> verwenden oder selber schreiben? Was ist gängig in der Industrie?

Was ist besser? Standardschraube für wenig Geld aus dem Baumarkt oder 
selber Eisen und Kohle schürfen, schmelzen, schmieden und ne Schraube 
draus machen?

von Falk B. (falk)


Bewertung
13 lesenswert
nicht lesenswert
Olaf schrieb:
>> Was ist gängig in der Industrie?
>
> Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man
> Bibliotheken einsetzen.
>
> Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein.

Was für ein Käse! Da kannst du ja gleich SÄMTLICHE Framewoks als QT etc. 
wegwerfen!

Schon mal was von Modularisierung und Wiederverwendung gehört?

> Wegen
> Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in
> Libaries.

Nicht jeder baut Raketen, die zum Mars fliegen sollen.

> Und ganz wichtig, du weisst nicht wie eine fremde Libary mit
> deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder
> Speicher braucht.

Alles gaaaanz schlimm.

> Allerdings sammeln sich in Firmen mit der Zeit auch eigene Libaries an
> welchen den internen Standards entsprechen. Sowas setzt man natuerlich
> gerne eine.

Jaja, der übliche, selbstgestrickte halbgare Quark.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
0815 schrieb:
> Was ist gängig in der Industrie?

Es werden natürlich die Bibliotheken des Compilerbauers (z.B. IAR, Keil) 
verwendet. Man zahlt ja schließlich gutes Geld dafür und kriegt sie auch 
kaum effizienter selber geschrieben. Nur was man da nicht findet, macht 
man selber.

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
Olaf schrieb:
>> Was ist gängig in der Industrie?
>
> Fuer irgendwelche Bastelsachen, Pruefaufbauten oder aehnliches kann man
> Bibliotheken einsetzen.
>
> Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein.

Ich seh's anders rum: Als Bastler kann man sich (so man will) die Zeit 
nehmen, alles selber zu basteln, aber wer das professionell macht, kann 
sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die 
eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss 
der Standardbibliothek.

> Wegen Coderules/Styles, SIL, Zertifiziertung, Dokumentation, Fehler in
> Libaries. Und ganz wichtig, du weisst nicht wie eine fremde Libary mit
> deiner eigenen Soft harmoniert. Also wann sie wieviel Rechenzeit oder
> Speicher braucht.

Dann musst du aber auch so konsequent sein und den Compiler auch selber 
schreiben, denn der erzeugt auch Code, der Fehler haben könnte oder mit 
deiner Software nicht harmonieren könnte. Am besten dann auch gleich 
noch den Prozessor selber bauen, denn wer weiß, welche Hardware-Bugs der 
so mitbringt?

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Dann musst du aber auch so konsequent sein und den Compiler auch selber
> schreiben, denn der erzeugt auch Code, der Fehler haben könnte oder mit
> deiner Software nicht harmonieren könnte.

Das musst du nicht. Schliesslich hast du dem Compilerhersteller schon 
xxxxxEuro gegeben damit er garantiert das sein Compiler solche Probleme 
nicht hat. Und wenn du doch mal eines feststellt dann behebt er das 
auch.

Schau mal hier:

https://www.iar.com/iar-embedded-workbench/certified-tools-for-functional-safety/certified-tools-faq/


Olaf

von Volle (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und 
einhalten.
Das kann eine Rechtsabteilung schon gut Beschäftigen und den Anhang zur 
Dokumentation recht lang machen.

Wenn man Pech hat steht dirn das man den Eigene Code dann auch open 
Source machen muss.

von W.S. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
0815 schrieb:
> was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h)

Was willst du mit stdio.h auf einem Mikrocontroller?
Da hast du erstmal fopen, fclose und andere File-Funktionen, die nur 
dann greifen, wenn du auch ein Betriebssystem mit drauf hast.

Ein gleiches gilt für die Einzelzeichen wie fgetc, fputc und Konsorten. 
Hast du dazu denn überhaupt eine Art Stream-Verwaltung auf deinem µC? 
Vermutlich nicht.

Dann hast du printf und scanf - und die entweder voll aufgeblasen oder 
eingekürzt, aber trotzdem Speicherfresser - auch durch die vielen 
Formatstrings.

Also, der ganze Krempel ist OK für das Programmieren von PC-Programmen, 
aber auf einem Mikrocontroller sieht da Ganze recht deplaziert aus.

Mach dir lieber dein Zeugs selbst und passe es an die Verhältnisse auf 
dem µC an.

W.S.

von W.S. (Gast)


Bewertung
-7 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Als Bastler kann man sich (so man will) die Zeit
> nehmen, alles selber zu basteln, aber wer das professionell macht, kann
> sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die
> eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss
> der Standardbibliothek.

Das klingt mir aber nicht nach einem fähigen Programmierer, sondern nach 
einem, der nicht weiß, wie man die einfachsten Dinge schreibt - oder 
nach einem, der sich ganz einfach davor scheut. Also genau so wie die 
vielen Möchtegerns, die fleißig ihre ST-InitStruct's befüllen, um zu 
vermeiden, ein Hardwarebit, was sie setzen wollen, SELBST zu setzen. Und 
dabei geht jede Performance zu Boden - und einfacher oder 
übersichtlicher oder zuverlässiger wird's dadurch auch bloß nicht.

W.S.

von Falk B. (falk)


Bewertung
7 lesenswert
nicht lesenswert
W.S. schrieb:
> Rolf M. schrieb:
>> Als Bastler kann man sich (so man will) die Zeit
>> nehmen, alles selber zu basteln, aber wer das professionell macht, kann
>> sich das gar nicht leisten. Da muss man sich drauf konzentrieren, die
>> eigentliche Funktionalität einzubauen und nicht den 10.000sten Aufguss
>> der Standardbibliothek.

Eben!

> Das klingt mir aber nicht nach einem fähigen Programmierer, sondern nach
> einem, der nicht weiß, wie man die einfachsten Dinge schreibt - oder
> nach einem, der sich ganz einfach davor scheut.

Jaja, erfinde dein Rad immer wieder neu und fühl dich als Held!

> Also genau so wie die
> vielen Möchtegerns, die fleißig ihre ST-InitStruct's befüllen, um zu
> vermeiden, ein Hardwarebit, was sie setzen wollen, SELBST zu setzen. Und
> dabei geht jede Performance zu Boden - und einfacher oder
> übersichtlicher oder zuverlässiger wird's dadurch auch bloß nicht.

Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP 
etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!

von Peter D. (peda)


Bewertung
6 lesenswert
nicht lesenswert
Ich hab zu Anfang auch vieles selber geschrieben. Mit zunehmender 
Programmiererfahrung lernt man aber die Bibliotheken zu schätzen. Die 
wurden nämlich von Profis geschrieben, d.h. es ist schwer, das gleiche 
Niveau zu erreichen.

Es gibt natürlich im Internet auch viele Bibliotheken zum Download, die 
von Anfängern geschrieben wurden. Die kann man bestenfalls als Idee 
benutzen, um es dann richtig zu machen. Man muß immer im Hinterkopf 
behalten, daß absolut jeder etwas im Internet veröffentlichen darf.

Auch bei Programmbeispielen von den MC-Herstellern (Michrochip, NXP, ST, 
TI usw.) muß man immer daran denken, daß es nur Beispiele sind, also 
weit entfernt von einer ausgereiften Bibliothek.

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Der TE bleibt ja leider sehr vage darin, welche Bibliothek er meint 
wenn er schreibt:

0815 schrieb:
> Bibliothek(wo halt die elementaren Sachen drin stehen, also die Stdio.h)

Vermutlich meint er damit die libc. Und die kommt im Zweifelsfall mit 
der Toolchain (vulgo: dem C-Compiler). Deren Hersteller für gewöhnlich 
nicht der Hersteller des µC ist. Insofern ist die Frage:

0815 schrieb:
> vom Hersteller verwenden oder selber schreiben?

auch nicht so richtig präzise zu beantworten.

Dazu kommt noch, daß gerade stdio.h auf embedded Systemen eine relativ 
geringe Relevanz hat, weil die meisten der Funktionen daraus auf 
embedded Systemen nicht verfügbar sind. Die libc an sich wird hingegen 
durchaus gebraucht. Z.B. für Strings. Oder gar nur für die Definitionen 
der Datentypen aus stdint.h.

Die Antwort ist, daß man bevorzugt die Bibliotheksfunktionen verwenden 
sollte. Wer glaubt, der Toolchain-Hersteller sei zu inkompetent für eine 
korrekte Implementierung der libc, der sollte zunächst mal die Frage 
beantworten, warum er ihm dann im Gegenzug die Kompetenz für die 
Implementierung des Compilers zugesteht.

In Einzelfällen kann es sinnvoll sein, die Funktionalität (oder auch nur 
Teile davon) von Bibliotheksfunktionen selber zu implementieren. Ein 
klassisches Beispiel ist eine Funktion zur formatierten Ausgabe von 
Zahlen analog printf() - aber nur mit dem Umfang, der tatsächlich 
gebraucht wird. Denn printf() braucht typisch viel Code (weil es 
umgekehrt auch sehr mächtig ist). Wenn man nun bspw. gar keine 
Unterstützung für Fließkomma braucht, kann man Speicher sparen indem man 
eine abgespeckte Variante selber baut. Aber wie gesagt, das sind 
Einzelfälle.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mal zur Erinnerung:

"Der Heartbleed-Bug ist ein schwerwiegender Programmfehler in älteren 
Versionen der Open-Source-Bibliothek OpenSSL, durch den über 
verschlüsselte TLS-Verbindungen private Daten von Clients und Servern 
ausgelesen werden können. ... Ein großer Teil der Online-Dienste, 
darunter auch namhafte Websites wie auch VoIP-Telefone, Router und 
Netzwerkdrucker waren dadurch für Angriffe anfällig "


Das eine Bibliothek von extern erstellt wurde und weltweit verbreitet 
ist, ist kein Qualitätsmerkmal. Eine xterne Bibliothek muss genauso 
kritische behandelt werden wie selbst erstellter Code. Zumal der 
Heartbleed-Bug kein besonders "komplizierter" Bug ist sondern auf simple 
Faulheit grundlegende Programmierregel, wie die Überprüfung von pointern 
anzuwenden, rückführbar ist. Und der Heartbleedprogrammer war kein 
frühreifes Computerkid sondern ein Promotionsstudent an der Fakultät 
Informatik einer Hochschule der am Thema „Strategien zur Sicherung von 
End-zu-End-Kommunikation" arbeitete....

von S. R. (svenska)


Bewertung
2 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Mal zur Erinnerung:

Und wer seine eigene Krypto-Bibliothek schreibt, ohne wirklich *richtig 
viel* Ahnung davon zu haben, im Detail, gehört standesrechtlich 
erschossen. Ende.

Die libc kommt von der Toolchain und ist damit mindestens so 
vertrauenswürdig wie die Toolchain selbst (allerdings ist es auch in 
Ordnung, sich auf ein Subset zu beschränken). Für alle anderen 
Bibliotheken muss man abwägen.

Bei uns in der Firma sind GPLv3 und LGPLv3 strikt verboten (wenn solcher 
Code drin wäre, dürften wir unsere Geräte nicht verkaufen). Alle anderen 
Open Source-Lizenzen sind grundsätzlich erlaubt.

von Vincent H. (vinci)


Bewertung
1 lesenswert
nicht lesenswert
Ich benutze keine Autos. Die meisten Fabrikanten haben zwar bald ein 
Jahrhundert an Erfahrung und tausende von Ingenieuren die sich 
tagtäglich 8h mit nichts anderem als ihrem Schwerpunkt beschäftigen... 
Aber ich weiß trotzdem einfach alles besser.

von N. M. (mani)


Bewertung
1 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Mal zur Erinnerung:

Jeder der schon einmal ernsthaft programmiert hat weiß dass keine 
Software 100% fehlerfrei ist.
Zu glauben so etwas kompliziertes wie OpenSSL selbst zu schreiben und 
dann noch besser zu sein ist in meinen Augen größenwahnsinnig oder 
ignorant.

Denn das schreiben der Bibliothek und der eigenen Applikation ist die 
kleine Aufgabe, wenn man 100% Fehlerabdeckung haben möchte.
Für einen vernünftigen Test, braucht es um einiges mehr Aufwand als der 
eigentliche Code und zusätzlich viel Verständnis über übliche 
Verfahren/Lücken in der Softwareentwicklung.

Zusätzlich muss man in der erwähnten Software auch noch nebenbei ein 
Experte in Kryptographie sein.

Kein Problem, macht man kurz in der Kaffeepause.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Ein sehr schönes Beispiel für die Fehleinschätzung der eigenen 
mathematischen Fähigkeiten ist Detlef Granzow mit seiner 
Vollbitverschlüsselung.

Achtung, Augenkrebsgefahr:
https://web.archive.org/web/20140517202802/http://kryptochef.net/

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Ein sehr schönes Beispiel für die Fehleinschätzung der eigenen
> mathematischen Fähigkeiten ist Detlef Granzow mit seiner
> Vollbitverschlüsselung.
>
> Achtung, Augenkrebsgefahr:
> https://web.archive.org/web/20140517202802/http://kryptochef.net/

Oder es ist einfach Satire ala DMHO.org. Oder Bauernfängerei ala 
Atomstromfilter, audiophile Technik etc.

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
Bevor ich ne Lib selbst schreibe schaue ich erstmal was es gibt und ob 
es meinen Anforderungen genügt. Das ist eigentlich sehr häufig der Fall. 
Ich sehe ehrlich gesagt gar kein Problem damit, fremde Libs zu nutzen. 
Das wertvollste, dass ich habe, ist Zeit und eine Lib selbst zu 
schreiben frisst Zeit. Das habe ich an meiner Lib für die SSD1306/SH1106 
Displays gesehen.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Oder es ist einfach Satire ala DMHO.org. Oder Bauernfängerei ala
> Atomstromfilter, audiophile Technik etc.

Nein, das meinte der Typ wohl ziemlich ernst. Es gab ja nicht nur seine 
Webseite, sondern er war auch ansonsten missionarisch unterwegs. Das 
ganze verursachte damals in verschiedenen Medien (auch uC...) ziemlich 
hohe Wellen.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
N. M. schrieb:
> Axel Zucker schrieb:
>> Mal zur Erinnerung:
>
> Jeder der schon einmal ernsthaft programmiert hat weiß dass keine
> Software 100% fehlerfrei ist.

Ja, auch ich hege den Verdacht das der TO noch nie ernsthaft 
programmiert hat, sonst würde er wissen das es sowas wie eine "fertige 
bibliothek" wie im Threadtitel dummfresch behauptet nicht gibt.


> Zu glauben so etwas kompliziertes wie OpenSSL selbst zu schreiben und
> dann noch besser zu sein ist in meinen Augen größenwahnsinnig oder
> ignorant.

Genauso wie die Annahme eine Bibliothek "von draussen" wäre irgendwie 
fertig und man könne sie einsetzen und vergessen ohne sich um Updates 
etc. zu kümmern. Und da wären noch die Alternativen zu OpenSSL:
https://www.netzwelt.de/alternative-zu/6937-openssl.html

Oder man ist so ehrlich und gesteht ein, das es sowas wie eine sichere 
Übertragung nicht gibt und findet ne Möglichkeit ohne Übertragung 
senitiver Informationen auszukommen.
Und eben nur die Funktionen zu implementieren und anzubieten die man 
selbst beherrscht um gegebenfalls dem kunden bei der fehlersuche 
behilflich sein zu können.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Aber niemand schreibt eine Lib für USB

Nicht immer von sich auf andere schließen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Nicht immer von sich auf andere schließen.

Nicht immer sinnentstellend zitieren.

von Axel Zucker (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Frank M. schrieb:
> Bernd K. schrieb:
>> Nicht immer von sich auf andere schließen.
>
> Nicht immer sinnentstellend zitieren.

Genau! Voller heist es:
"Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"

Und dem ist zu widersprechen, es kann schon sinnvoll sein eine lib 
selber zu schreiben, insbesonders wenn man nur ein schmales subset an 
Funktionen braucht und nicht die HW-resourcen hat den der volle 
Funktiumsumfang erfordert. beispielsweise statt volles Fat einen single 
file reader.

Oder als kompromiss eine fremde lib aufs brauchbare runterkürzen, was 
IMHO auch eine Art "selber schreiben" ist auch wenn der überweigende 
Teil der Arbeit dabei aus Lesen und Wegschmeissen besteht.

von Andreas W. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Das ist doch sicher ein Thread zum ködern von Trolls oder?

Manche schreiben ja sinnige Antworten. Also abgespeckte Libs schreiben 
die nur einen Teil der Funktion haben ist doch durchaus sinnvoll wenn es 
für einen reicht.

Außerdem gibt es in der Informatik mehr Themen als man überhaupt lernen 
kann. Wie soll die Menschheit überhaupt weiter kommen, wenn jeder von 
Vorn anfängt.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> insbesonders wenn man nur ein schmales subset an
> Funktionen braucht und nicht die HW-resourcen hat

Zum Beispiel den MKL26 der mit 32kB Flash und USB Peripherie verkauft 
wird.

Der vom Hersteller mitgelieferte Codegenerator (weil simplen 
Beispielcode mitzuliefern mit dem man zur Abwechslung mal was anfangen 
könnte ist ja neuerdings aus der Mode gekommen) spuckt für dieses Target 
einen Bloatbrocken von 35kB aus wenn man ein leeres Hello-World USB-HID 
Projekt haben will. Und wenn man auf Kompilieren drückt sagt einem der 
Linker daß das 35k Code logischerweise nicht in 32k Flash passen.

Ein selber geschriebener USB-Treiber mit HID Endpoint braucht nur etwa 
2500 Byte. Wenn man das nicht machen würde könnte man diese Peripherie 
in diesem Controller in der Form wie er von NXP verkauft wird überhaupt 
nicht nutzen, die ganze Existenz dieses Dings wäre vollkommen sinnlos!

: Bearbeitet durch User
von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
Solche Bilbliotheken wie stdio etc., also die libc, kommen in der Regel 
vom Compiler den du benutzt. Der kann vom Hersteller des Chips kommen, 
muss aber nicht.
Eine Implementierung, die für embedded Systeme sehr beliebt ist, ist die 
newlib (https://sourceware.org/newlib/). Diese kommt zum Beispiel mit 
dem arm-none-eabi-gcc. Du kannst dir den Code mal anschauen. Sicher ist 
auf jeden Fall, dass man das nicht mal eben so schnell runtercodet.

Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik 
wäre jetzt ein Beispiel dafür -- dann musst du je nach 
"Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und 
Libraries verwenden. Teilweise sind die dann noch viel schlechter, als 
alles, was du auf github bekommst. Sind aber halt zugelassen...

Gerade im Embedded-Bereich ist es häufig üblich, auf die libc, sprich 
stdio.h etc. zu verzichten, da diese einen erheblichen Rattenschwanz mit 
sich bringt. Werden trotzdem Funktionen wie printf() etc. benötigt, 
implementiert man in einem solchen Fall eine eigene, teils abgespeckte, 
Variante à la my_printf().
Viele Betriebssysteme für embedded (RTOS, etc...) bringe auch teils ihre 
eigenen Standardfunktionen mit. Inklusive einer unendlichen Flut von 
Typedefs. Wenn du n Libraries in deinem Projekt hast, dann hast du 
schätzungsweise e^n typedefs für einen 32 bit unsigned integer...

Hier greift jetzt natürlich wieder das, was vorhin schon gesagt wurde: 
Coding Style. Wenn du eine Library verwendest, nutzt diese nach Murphy 
natürlich nie den Coding Style, den du nutzt. Ansich kann man damit 
leben, dass der Style in verschieden Files anders ist. Aber das aufrufen 
von Funktionen der Library in deinem Programm führt dann aufgrund des 
anderen coding Styles zu einem unglaublich widerlichen Mischmasch. Egal 
welchen Coding Style man bevorzugt: Mischen sollte man auf keinen Fall. 
Das kann keiner mehr lesen.

Der Linux Kernel, als Beispiel, bietet intern auch Funktionen wie 
malloc, free etc. an. Diese sind allerdings in einer eigenen Variante 
(kmalloc, kfree, ...) selbst implementiert. Zum einen aus dem Grund, 
dass diese Funktionen teils noch weitere Parameter fressen, als die 
Standardfunktionen. Zum anderen sorgt das aber auch dafür, dass der Code 
in sich komplett ist und keine Abhängigkeit zu einer weiteren Library 
besteht.

Als Nurtzerapplikation auf PC ist eine eigene Implementierung meist 
nicht sinnvoll. Außer man braucht eben auch hier eine spezielle 
Zertifizierung, aus welchem Grund auch immer.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik
> wäre jetzt ein Beispiel dafür -- dann musst du je nach
> "Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und
> Libraries verwenden. Teilweise sind die dann noch viel schlechter, als
> alles, was du auf github bekommst. Sind aber halt zugelassen...

Ja, das ist teilweise ziemlich bitter. Auch bei Halbleitern gibt es 
solch einen Mist. Aus einem Projekt kenne ich einen Mikroprozessor, der 
Unmengen an Fehlern aufweist. Kaum ein Peripherieblock funktioniert 
einwandfrei. Auf massiven Druck meines damaligen Kunden meinte der 
Hersteller, genau diese Maskenversion sei für einige 
sicherheitskritische Anwendungen zertifiziert und dürfe deswegen nicht 
mehr angefasst werden. Dieser Kunde setzte sowohl die Standardversion 
als auch eine Sonderausführung mit angepasstem On-Chip-Bootloader ein, 
wobei ich aber nicht weiß, ob selbiger während der Chipfertigung per OTP 
oder über eine eigene Maske eingebracht wurde.

von HyperMario (Gast)


Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
> Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller
> verwenden oder selber schreiben?

Am besten ist es mangels eigener Fab einen Prozessor mit ladbarem 
Mikrocode zu nehmen und diesen von scratch neu zu schreiben.

Da hast du dann die Möglichkeit alle Fehler die seit der Entwicklung des 
ersten Prozessors gemacht wurden zu wiederholen und noch ein paar neue 
hinzuzufügen.

Wenn du damit nächste Woche durch bist kommt das 0815 C dran, die paar 
Millionen Zeilen Code in den libs und deren Reifung machst du dann 
nebenbei ;-).

von M. H. (bambel2)


Bewertung
0 lesenswert
nicht lesenswert
HyperMario schrieb:
> Am besten ist es mangels eigener Fab einen Prozessor mit ladbarem
> Mikrocode zu nehmen und diesen von scratch neu zu schreiben.

Absoluter Schwachsinn. Wir leben doch nicht mehr im Mittelalter. Er soll 
einen FPGA nehmen.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Und wenn man auf Kompilieren drückt sagt einem der
> Linker daß das 35k Code logischerweise nicht in 32k Flash passen

Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus? 
Gute Libraries sollten so strukturiert/modularisiert sein, dass 
Funktionalität, die nie aufgerufen wird, beim kompilieren verschwindet. 
Alternativ macht man es manuell, wie bei lwIP, wo man über eine Menge 
Makros genau definieren kann, was man haben möchte.

von Vincent H. (vinci)


Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus?

Bei -O0 vermutlich nicht. :p

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Bei -O0 vermutlich nicht. :p

--gc-sections funktioniert auch bei -O0 ...

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus?

Lib-Funktionen werden erst dann eingebunden, wenn man sie auch aufruft, 
z.B. printf().
Wenn man allerdings keine vorcompilierte Lib erzeugt, sondern Quelltext 
einbindet, dann belegt der auch Speicherplatz, wenn er nicht aufgerufen 
wird.

von Martin (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Olaf schrieb:
> Alles was zu Kunden rausgeht muss zu 100% selbst geschrieben sein.

Das war mal. Heutzutage setzt sich die Erkenntnis durch, dass man das 
Rad nicht immer und immer wieder neu erfinden muss. Das kostet nur Zeit 
und Geld. STM beispielsweise hat CubeMX und die dazugehörigen 
HAL-Bibliotheken nicht für den Bastler im stillen Kämmerlein geschaffen 
sondern zur Anwendung im professionellen Umfeld. Wenn bei uns ein 
Entwickler eingestellt wird ist es ein wichtiges Kriterium ob er mit den 
aktuellen Bibliotheken umgehen kann. Alles selbst machen gibts bei uns 
schon lange nicht mehr.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wenn man allerdings keine vorcompilierte Lib erzeugt, sondern Quelltext
> einbindet, dann belegt der auch Speicherplatz, wenn er nicht aufgerufen
> wird.

Aber nur wenn man die Compiler/Linker-Optionen zum Löschen ungenutzten 
Codes explizit aus den Projekteinstellungen entfernt, wo die meisten 
Projekt-Erzeugungs-Wizwards/Tools sie schon automatisch eintragen.

: Bearbeitet durch User
von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
M. H. schrieb:
> Wenn du in einer sicherheitskritischen Ecke arbeitest -- Bahntechnik
> wäre jetzt ein Beispiel dafür -- dann musst du je nach
> "Sicherheitsstufe" teilweise auch speziell zertifizierte Compiler und
> Libraries verwenden. Teilweise sind die dann noch viel schlechter, als
> alles, was du auf github bekommst. Sind aber halt zugelassen...

Das hat dann wieder versichungstechnische Aspekte: Wenns abbrennt, dann 
halt zumindest Normgerecht und wenn man nix aus der Norm genommen hat 
wirds teuer und die Versicherungen freuen sich...auch wenns besser war, 
was man genommen hat.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Und der Compiler/Linker schmeißt nicht benötigte Funktionen nicht raus?
> Gute Libraries sollten so strukturiert/modularisiert sein, dass
> Funktionalität, die nie aufgerufen wird, beim kompilieren verschwindet.

Ja. Und der Linker schmeißt alles raus was er rausschmeißen kann. Und 
wenn danach immer noch auf der höchsten Optimierungsstufe und mit allen 
diesbezüglichen Flags die mir bzgl. Codegröße einfallen immer noch 35kB 
Code ausspuckt dann wirkt die Aussicht darauf jetzt Wochen damit 
verbringen zu dürfen in dem 35kB Misthaufen von generierten Codeabfällen 
herumzustochern um zu sehen warum das passiert und zu versuchen die 3kB 
eigentliche Funktionalität zu finden, zu verstehen, zu isolieren und 
herauszuoperieren ohne sie kaputt zu machen weitaus weniger motivierend 
als die Aufgabe sich hinzusetzen und die selben zwei Wochen darin zu 
investieren das Gewünschte sauber und from scratch selbst zu 
implementieren, das hat auch den Vorteil daß man es hinterher zu 100% 
verstanden hat und auch sein API so gestalten kann wie es einem angenehm 
ist und gut mit dem restlichen Code harmoniert.

Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den 
Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten 
stinkenden Codemisthaufen herumstochern will um das irgendwie notdürftig 
zum Laufen zu bringen. Ich will sauberen eleganten Code. Ich bin 
vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich 
eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und 
Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt 
noch lösbar macht, andernfalls gäbs überhaupt keinen Grund es überhaupt 
zu versuchen weil nicht ansatzweise Konkurrenzfähig. Das ist also das 
exakte Gegenteil von "wir schmeißen einfach mehr und teurere Hardware 
drauf weil die Legosteine aus denen wir bauen alle so groß und unförmig 
sind" das in anderen Bereichen getrieben wird wo es nicht so eng zugeht.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
M. K. schrieb:
> wenn man nix aus der Norm genommen hat
> wirds teuer und die Versicherungen freuen sich

Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche 
Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.

Ebenso stehen die Bedürfnisse der Reichen über denen der Armen, weil 
unser Land von reichen regiert wird.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche
> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.

Und solche Leute verstehen dann auch nicht, dass man die Kirchhoffschen 
oder Maxwellschen Gesetze nicht einfach per Gesetzgebungsverfahren 
ändern kann.

von Falk B. (falk)


Bewertung
3 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> M. K. schrieb:
>> wenn man nix aus der Norm genommen hat
>> wirds teuer und die Versicherungen freuen sich
>
> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche
> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.

Wer sollte sie sonst machen? Wurstfachverkäufer?

> Ebenso stehen die Bedürfnisse der Reichen über denen der Armen, weil
> unser Land von reichen regiert wird.

Welche Land wird erfolgreich von Armen regiert? Nordkorea?
Reichtum ist eine Manifestation von Macht.

von Falk B. (falk)


Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:

> herauszuoperieren ohne sie kaputt zu machen weitaus weniger motivierend
> als die Aufgabe sich hinzusetzen und die selben zwei Wochen darin zu
> investieren das Gewünschte sauber und from scratch selbst zu
> implementieren, das hat auch den Vorteil daß man es hinterher zu 100%
> verstanden hat und auch sein API so gestalten kann wie es einem angenehm
> ist und gut mit dem restlichen Code harmoniert.

Das mag in einigen und auch diesem Fall so sein, allgemeingültig ist es 
nicht.
Wenn man ein Problem lösen will, dann schaut man IMMER erstmal, ob es 
fertige Lösungen oder Zutaten dazu gibt. Erst wenn es keine gibt oder 
deren Qualität zu schlecht ist, baut man selber was. Das gilt nicht nur 
für Software und Ingenieursarbeit sondern so ziemlich alle 
Lebensbereiche.

> Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den
> Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten
> stinkenden Codemisthaufen herumstochern will um das irgendwie notdürftig
> zum Laufen zu bringen.

Klingt verständlich.

> Ich will sauberen eleganten Code.

Der kann dir bei Bibliotheken und anderen Black Boxes egal sein.

> Ich bin
> vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich
> eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und
> Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt
> noch lösbar macht,

Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für 
Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und 
warum? Weil Speicher und CPU Power verdammt billig geworden sind.

> andernfalls gäbs überhaupt keinen Grund es überhaupt
> zu versuchen weil nicht ansatzweise Konkurrenzfähig.

Baust du so preissensitives Zeug im Massenmarkt?

> Das ist also das
> exakte Gegenteil von "wir schmeißen einfach mehr und teurere Hardware
> drauf weil die Legosteine aus denen wir bauen alle so groß und unförmig
> sind" das in anderen Bereichen getrieben wird wo es nicht so eng zugeht.

;-)

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Ich bin
> vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich
> eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und
> Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt
> noch lösbar macht, andernfalls gäbs überhaupt keinen Grund es überhaupt
> zu versuchen weil nicht ansatzweise Konkurrenzfähig.

Das ist ein schöner Ansatz, den ich praktisch genauso vertrete. Und das 
schon seit ich überhaupt programmiere. Die Demoszene auf dem C64 hat 
mich wohl geprägt :)

Das Problem nennst du aber selber im letzten Halbsatz: so ein Ansatz ist 
im professionellen Umfeld nur seltenst durchzuziehen, weil nicht 
konkurrenzfähig. Entwicklerzeit ist nun mal so viel teurer als Silizium, 
daß jeder Betriebswirtschaftler auf teuren Chip und billigen Entwickler 
setzen wird, statt anders herum. Es gibt wenige Ausnahmen, etwa wenn ein 
Markt mit zig Millionen Stückzahl sicher ist. Aber wie gesagt: Ausnahme.

von W.S. (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
Falk B. schrieb:
> Aber niemand schreibt eine Lib für USB,..

Ähem.. doch.

Ich zum Beispiel. Ist zwar nicht für alle möglichen USB-Verwendungen, 
sondern nur für VCP, aber dafür ist sie klein und handlich und eine 
bessere HAL als alles, was ich von den diversen Herstellern bislang 
gesehen habe. Offenbar bin ich da nicht der Einzige:

Bernd K. schrieb:
> Ich habe in dem konkreten Fall keine 5 Minuten gebraucht um den
> Entschluss zu fassen daß ich keinesfalls in dem lieblos generierten
> stinkenden Codemisthaufen herumstochern will..

Eben, geht mir ähnlich. Anstatt mit Krampf irgendwelche 
"Standard"-Funktionen zu benutzen und diversen Code drumherum zu 
stricken, bloß um sie an das vorliegende Umfeld anzupassen oder sich mit 
aufgeblähtem fehlerträchtigen Code  herumzuplagen, ist es oftmals 
besser, sich seinen Kram selber zu machen.

Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier 
kommen, daß sie das Rad ja nicht nochmal erfinden wollen.

W.S.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Wenn man beruflich ständig mit Gigabytes und Gigahertz nur so um sich 
wirft, verliert man manchmal den Blick fürs Detail.

Meine Hobby-Experimente mit ganz kleinen Mikrocontrollern hatten einen 
wesentlichen Anteil daran, dass ich inzwischen immer dann gerufen werde, 
wenn es Probleme mit Performance und/oder Speicher in Java Anwendungen 
gibt.

Die Spielereien mit kleinen Mikrocontrollern haben also auch was Gutes.

Ich vergleiche das gerne mit einem Tischler oder Zimmermann, der zuhause 
Krippenfiguren schnitzt. Das Große und das Kleine ergänzen sich zu einem 
vernünftigen Gesamtbild, sowohl physisch als auch im Kopf.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Falk B. schrieb:
>> Aber niemand schreibt eine Lib für USB,..
>
> Ähem.. doch.
>
> Ich zum Beispiel. Ist zwar nicht für alle möglichen USB-Verwendungen,
> sondern nur für VCP, aber dafür ist sie klein und handlich und eine
> bessere HAL als alles, was ich von den diversen Herstellern bislang
> gesehen habe. Offenbar bin ich da nicht der Einzige:

Du solltest vollständig zitieren!

"Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"

Die Betonung liegt auf "einfach mal so". Daß man selber sowas machen 
kann und das in einigen Fällen auch sinnvoll ist, hat keiner bestritten. 
Wohl aber die Aussage, daß man immer alles selber machen sollte oder 
muss.

> Eben, geht mir ähnlich. Anstatt mit Krampf irgendwelche
> "Standard"-Funktionen zu benutzen und diversen Code drumherum zu
> stricken, bloß um sie an das vorliegende Umfeld anzupassen oder sich mit
> aufgeblähtem fehlerträchtigen Code  herumzuplagen, ist es oftmals
> besser, sich seinen Kram selber zu machen.

Eben das ist so NICHT allgemeingültig! Denn es sind mal sicher nicht 
alle bestehenden Bibliotheken und Frameworks dermaßen schlecht!

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"

Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern 
bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein 
persönlichen Erbauung, Hubschrauber fliegen lernen, ein Schachprogramm 
schreiben, einen Treiber für USB oder FAT oder TCP/IP, einen 
Betriebssystem-Kernel schreiben weil man seinem ehemaligen Inf-Professor 
das Gegenteil von irgendwas beweisen will, alles weder möglich noch 
sinnvoll? Ich glaube nicht. Die Geschichte ist voll davon. Und Github 
ist voll von Software die irgendwer einfach mal so geschrieben hat, 
entweder aus Jux und Tollerei oder weil er dachte er kann irgendwas 
besser lösen als die dutzend Alternativen für den selben Zweck und 
einige davon sind am Ende wirklich besser.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Die Geschichte ist voll davon.

Ja, sieht man zum Beispiel an Linux :-) Vielfalt und Ausprobieren sind 
die Grundlagen für Innovation. Muss ja nicht jedes Mal ein Erfolg sein.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Falk B. schrieb:
>> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
>> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"
>
> Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern
> bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein
> persönlichen Erbauung, Hubschrauber fliegen lernen, ein Schachprogramm
> schreiben, einen Treiber für USB oder FAT oder TCP/IP, einen

Ja, aus Spaß an der Freud. Da kann man fast alles machen. Im 
produktiven, professionellem Umfeld aber nicht.

> Betriebssystem-Kernel schreiben weil man seinem ehemaligen Inf-Professor
> das Gegenteil von irgendwas beweisen will, alles weder möglich noch
> sinnvoll? Ich glaube nicht. Die Geschichte ist voll davon. Und Github
> ist voll von Software die irgendwer einfach mal so geschrieben hat,
> entweder aus Jux und Tollerei oder weil er dachte er kann irgendwas
> besser lösen als die dutzend Alternativen für den selben Zweck und
> einige davon sind am Ende wirklich besser.

Eben, EINIGE!

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Falk B. schrieb:
>> Aber niemand schreibt eine Lib für USB,..
>
> Ähem.. doch.

Und schon kommt der nächste, der sinnentstellend zitiert.
Aber Falk hat ja eben schon alle Nötige dazu gesagt.


Bernd K. schrieb:
> Falk B. schrieb:
>> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
>> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"
>
> Viele Leute tun Dinge auch einfach mal so. Eiffelturm aus Streichhölzern
> bauen, Einen Kurzwellentransceiver entwerfen und zusammenlöten zur rein
> persönlichen Erbauung ...

Oder auf einen Berg steigen. Einfach weil er da ist. Ja.

<gähn>

Das ist kein Widerspruch. Aber eine USB-Lib, gar auf einem F103 schreibt 
man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf 
einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich 
drängt sich förmlich auf.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das ist kein Widerspruch. Aber eine USB-Lib, gar auf einem F103 schreibt
> man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf
> einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich
> drängt sich förmlich auf.

Weil USB unter den diversen Protokollen ein eher sauberes, genau 
spezifiertes, und gar nicht so unübersichtliches ist? Schnittstellen wie 
die von SD-Karten, WLAN(-Modulen), aber auch solche im Web-Bereich sind 
da oft viel schlimmer. Die USB-Peripherie vom F103 ist noch ganz 
erträglich und logisch aufgebaut. Nur die Adressierung ist etwas schräg. 
Nur weil man keine 587 YouTube-Videos und "Für Dummies"-Bücher zu findet 
muss man sich davon nicht abschrecken lassen.

Daher:

W.S. schrieb:
> Ich zum Beispiel.

Und ich auch: USB-Tutorial mit STM32

Die USB-Library von ST ist wirklich nicht so der Bringer (Bugs, 
ineffizient). Interessant wäre ein Vergleich mit kommerziellen 
USB-Stacks.

: Bearbeitet durch User
von Michael A. (micha54)


Bewertung
6 lesenswert
nicht lesenswert
W.S. schrieb:
>
> Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier
> kommen, daß sie das Rad ja nicht nochmal erfinden wollen.
>
> W.S.

So viel Arroganz lässt sich doch sicher noch steigern ?

Gruß,
Michael

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Die USB-Peripherie vom F103 ist noch ganz erträglich und
> logisch aufgebaut. Nur die Adressierung ist etwas schräg.

Auf mich macht sie eher den Eindruck als ob jemand von ST

a) bestehende Hardwarefragmente aus alten µC möglichst schnell und 
billig zusammen frickeln musste um sagen zu können "jetzt können wir 
auch USB",

oder

b) zu viel Betäubungsmittel eingenommen hat

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Axel S. schrieb:
>> ... eine USB-Lib, gar auf einem F103 schreibt
>> man eher nicht zum Spaß. Genauso wie man zwar vielleicht aus Spaß auf
>> einen Berg steigt, aber nicht auf eine Müllkippe. Und der Vergleich
>> drängt sich förmlich auf.
>
> Die USB-Peripherie vom F103 ist noch ganz
> erträglich und logisch aufgebaut. Nur die Adressierung ist etwas schräg.

Findest du?

> ... ich auch: USB-Tutorial mit STM32

Ja. Eben daher habe ich den Eindruck, daß man den USB low-level Kram auf 
dem F103 besser delegiert. Außer man ist masochistisch veranlagt.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> a) bestehende Hardwarefragmente aus alten µC möglichst schnell und
> billig zusammen frickeln musste um sagen zu können "jetzt können wir
> auch USB",

Ja, die STM32 und viele ähnliche Controller sind nach dem 
Baukastenprinzip aufgebaut.

Axel S. schrieb:
> Findest du?

Kennst du einen Controller mit besserer USB-Peripherie? Die 
"OTG"-Peripherie der größeren STM32 ist noch viel schlimmer.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Kennst du einen Controller mit besserer USB-Peripherie? Die
> "OTG"-Peripherie der größeren STM32 ist noch viel schlimmer.

Umso dankbarer bin ich für deine Anleitung, die Klarheit verschafft.

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
M. H. schrieb:
> Gerade im Embedded-Bereich ist es häufig üblich, auf die libc, sprich
> stdio.h etc. zu verzichten, da diese einen erheblichen Rattenschwanz mit
> sich bringt.

Das ist so allgemein ziemlich immer falsch.
Erstens besteht die libc aus wesentlich mehr als nur stdio.h.
Zweitens steht es dem gcc immer (und nicht abschaltbar!) frei, Aufrufe 
zu mem{cpy,cmp,move,set} zu generieren, und die sind Teil der libc.

Man wird sich im Embedded-Bereich allerdings so ziemlich immer auf ein 
Subset der vollen libc beschränken. Da kann printf drin sein, muss es 
aber nicht. In meinem Fall ist es das immer (außer in reinen 
Assembler-Projekten), weil ich den Nutzen deutlich höher einschätze als 
die (Einmal-)Kosten.

Meine Meinung: Man sollte alles einmal selbst gemacht haben (egal ob 
USB, FAT oder printf), dann aber fertige Bibliotheken (falls existent) 
nutzen. Warum? Weil man erst dann die Qualität dieser Bibliotheken und 
die eigentliche Komplexität des Problems halbwegs sinnvoll einschätzen 
kann.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Meine Meinung: Man sollte alles einmal selbst gemacht haben (egal ob
> USB, FAT oder printf), dann aber fertige Bibliotheken (falls existent)
> nutzen. Warum? Weil man erst dann die Qualität dieser Bibliotheken und
> die eigentliche Komplexität des Problems halbwegs sinnvoll einschätzen
> kann.

Find ich nicht. IMO muss man nicht alles selbst einmal gemacht haben. Es 
ist aber sicher nicht verkehrt auch mal in eine Bibliothek rein zu 
schaun was da drin alles gemacht wird.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Stefanus F. schrieb:
>> M. K. schrieb:
>>> wenn man nix aus der Norm genommen hat
>>> wirds teuer und die Versicherungen freuen sich
>>
>> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche
>> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.
>
> Wer sollte sie sonst machen? Wurstfachverkäufer?

Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das 
Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen 
verstehen.

Falk B. schrieb:
>> Ich bin
>> vorwiegend auf den kleinstmöglichen Controllern unterwegs mit denen sich
>> eine gegebene Aufgabe überhaupt noch lösen lässt, Kreativität und
>> Hirnschmalz ist dort manchmal das einzige was eine Aufgabe überhaupt
>> noch lösbar macht,
>
> Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für
> Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und
> warum? Weil Speicher und CPU Power verdammt billig geworden sind.

Es kommt eben auch immer darauf an, was man macht. Wenn man zuhause als 
Hobyybastler Spaß daran hat, aus möglichst keinen µCs möglichst viel 
rauszuholen, ist das ja ok. Oder wenn man Geräte entwickelt, die nachher 
in sehr großen Stückzahlen gebaut werden und jeder Cent in der 
Produktion eingespart werden soll, auch wenn das vielleicht 100.000 € an 
zusätzlichen Entwicklungskosten bedeutet. Wenn man dagegen 
kundenspezifische Einzellösungen baut, ist es praktisch immer viel 
billiger, den nächstgrößeren Boliden zu kaufen als durch selber 
schreiben irgendwelcher Libs das Programm zu optimieren.

Bernd K. schrieb:
> Falk B. schrieb:
>> "Davon redet keiner. Aber niemand schreibt eine Lib für USB, FAT, TCP/IP
>> etc. "einfach mal so" selber. Das ist weder möglich noch sinnvoll!"
>
> Viele Leute tun Dinge auch einfach mal so.

Ich würde "einfach mal so" hier weniger als "nur so zum Spaß" verstehen, 
sondern eher in der Art "so kurz mal nebenher".

S. R. schrieb:
> Erstens besteht die libc aus wesentlich mehr als nur stdio.h.
> Zweitens steht es dem gcc immer (und nicht abschaltbar!) frei, Aufrufe
> zu mem{cpy,cmp,move,set} zu generieren, und die sind Teil der libc.

Meist wird's aber eher umgekehrt sein, dass gcc einen memcpy-Aufruf 
selber intern umsetzt, statt die libc-Funktion tatsächlich aufzurufen.

> Man wird sich im Embedded-Bereich allerdings so ziemlich immer auf ein
> Subset der vollen libc beschränken. Da kann printf drin sein, muss es
> aber nicht. In meinem Fall ist es das immer (außer in reinen
> Assembler-Projekten), weil ich den Nutzen deutlich höher einschätze als
> die (Einmal-)Kosten.

Wenn man genug Flash dafür übrig hat, warum auch nicht? Da gilt der 
bekannte Satz: Man bekommt vom Hersteller kein Geld zurück für nicht 
benutzten Speicher. Es macht wenig Sinn, krampfhaft auf solche 
Funktionen zu verzichten und dann nachher noch 75% des Flashs ungenutzt 
zu lassen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Wer hier das Wort "Overkill" verwendet, möge bitte mal die Anzahl der 
Glühlampen und Leuchtdioden (insbesondere bei Lichterketten) in seinem 
Haushalt zählen.

Und dann fragen wir mal einen imaginären Vertreter aus dem 18. 
Jahrhundert, ob er elektrisches Licht in dieser Ausbaustufe für 
angemessen hält.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Es macht wenig Sinn, krampfhaft auf solche Funktionen
> zu verzichten und dann nachher noch 75% des Flashs ungenutzt
> zu lassen.

Nun bleibt dann noch die Frage der Updates offen. Wer viel Zeug hat, muß 
sich um viel Zeug kümmern! Mein größte eierlegende Wollmilchsau wollte 
dann täglich frische Updates, was zu echten Plage wurde.

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
Rolf M. schrieb:
>>> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche
>>> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.
>>
>> Wer sollte sie sonst machen? Wurstfachverkäufer?
>
> Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das
> Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen
> verstehen.

Es gibt Fachjuristen.

>> Mag sein, ist aber auch nicht allgemeingültig. Schau dir an, mit was für
>> Overkill und fetter Hardware heute teilweise rumgeworfen wird. Und
>> warum? Weil Speicher und CPU Power verdammt billig geworden sind.
>
> Es kommt eben auch immer darauf an, was man macht.

Sicher.

> Wenn man zuhause als
> Hobyybastler Spaß daran hat, aus möglichst keinen µCs möglichst viel
> rauszuholen, ist das ja ok. Oder wenn man Geräte entwickelt, die nachher
> in sehr großen Stückzahlen gebaut werden und jeder Cent in der
> Produktion eingespart werden soll, auch wenn das vielleicht 100.000 € an
> zusätzlichen Entwicklungskosten bedeutet.

Ja, aber auch da muss man schon GENAU hinschauen und RECHNEN! Einen 
break even point aka Gewinnschwelle kann man schon mal schnell 
abschätzen. Machen nur die Allerwenigsten!

https://de.wikipedia.org/wiki/Gewinnschwelle

Viele Entwickler haben allerdings eine unprofessionelle 
Bastlermentalität und sind verliebt in ihre Spielzeuge ala Compiler, 
Frameworks, CAD-Tools, ICs whatever. Da werden keine nüchternen, 
rationalen, WIRTSCHAFTLICHEN Designentscheidungen getroffen sondern nach 
Herzenslust drauflosgebastelt um ein möglichst episches Kunstwerk zu 
schaffen. Menschlich verständlich aber unprofessionell und TEUER!

> Wenn man dagegen
> kundenspezifische Einzellösungen baut, ist es praktisch immer viel
> billiger, den nächstgrößeren Boliden zu kaufen als durch selber
> schreiben irgendwelcher Libs das Programm zu optimieren.

Das hat mit kundenspezifisch wenig zu tun sondern was mit Stückzahlen. 
Wenn ich 100.000 Euro Entwicklungskosten habe, die meist zum größten 
Teil Personalkosten (=Zeit) sind, ist es halt ein Unterschied ob ich die 
auf 10 oder 10.000 verkaufte Produkte umlegen kann!
Time is Money ist kein leeres Geschwätz sondern Realität.

> Ich würde "einfach mal so" hier weniger als "nur so zum Spaß" verstehen,
> sondern eher in der Art "so kurz mal nebenher".

Genau so war das gemeint.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Tägliche updates auf einem Mikrocontroller?
Das würde ich nicht einmal mit einem Raspberry Pi machen.

von Bernd K. (prof7bit)


Bewertung
-3 lesenswert
nicht lesenswert
Rolf M. schrieb:

> [...] printf [...]
> Es macht wenig Sinn, krampfhaft auf solche
> Funktionen zu verzichten und dann nachher noch 75% des Flashs ungenutzt
> zu lassen.

In den meisten Mikrocontrollerprojekten hat man überhaupt keine 
Verwendung für printf oder Konsorten, dann muss man auch nicht 
krampfhaft darauf verzichten und das Geld für den gesparten Flash 
bekommt man zurück indem man den nächstkleineren bestellt und es gar 
nicht erst bezahlt.

Und ein USB-Stack kostet auch keine 100000€ sondern nur einen einzigen 
engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum 
Beruf gemacht hat und/oder am Gewinn beteiligt oder anderweitig an 
Gedeih oder Verderb der Firma gebunden ist, so jemand zieht den besagten 
USB-Stack an ein paar verregneten Sonntagen zuhause durch wenn er gut 
ist, solche Leute gibts, die Skala für Skill-Level und Leidenschaft ist 
nach oben offen, das können sich zwangsstudierte nine-to-five-Ingenieure 
bei denen der letzten Tropfen Motivation schon vor 15 Jahren endgültig 
ausgesaugt wurde oder gar nie vorhanden war oftmals überhaupt nicht 
vorstellen.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
3 lesenswert
nicht lesenswert
Bernd K. schrieb:

> Und ein USB-Stack kostet auch keine 100000€ sondern nur einen
> engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum
> Beruf gemacht hat

Also ein Nerd und Fachidiot, der sich billig ausbeuten läßt.

> und/oder am Gewinn beteiligt oder anderweitig an
> Gedeih oder Verderb der Firma gebunden ist, so jemand zieht den besagten
> USB-Stack an ein paar verregneten Sonntagen zuhause durch wenn er gut
> ist,

Jaja, der Supermann. Es mag sein, daß es solche Leute gibt, vielleicht 
auch mehr als man denkt. Professionell ist das trotzdem nicht. Vor allem 
weil bei so einem Hackaton der Test und die Validierung arg zu kurz 
kommen, wie fast immer bei Software 8-0

> solche Leute gibts, die Skala für Skill-Level und Leidenschaft ist
> nach oben offen, das können sich zwangsstudierte nine-to-five-Ingenieure
> bei denen der letzten Tropfen Motivation schon vor 15 Jahren endgültig
> endgültig ausgesaugt wurde oder gar nie vorhanden war oftmals überhaupt
> nicht vorstellen.

Doch, kann ich, auch wenn ich eher zur ersteren Gruppe gehöre. Vor 
vielen Jahren hab ich sowas im kleinen Rahmen auch mal gemacht, ist aber 
Geschichte. Dienst ist Dienst und Schnapps ist Schnapps! Adolf Hennecke 
ist lange tot und das ist gut so!

https://de.wikipedia.org/wiki/Adolf_Hennecke

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Falk B. schrieb:
> Jaja, der Supermann. Es mag sein, daß es solche Leute gibt,

Irgendwann fällt er mal aus, und dann packen alle ein und machen den 
Laden zu, oder wie soll das ablaufen?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Falk B. schrieb:
>> Jaja, der Supermann. Es mag sein, daß es solche Leute gibt,
>
> Irgendwann fällt er mal aus, und dann packen alle ein und machen den
> Laden zu, oder wie soll das ablaufen?

Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch 
seinen Weggang sicherlich nicht in Luft auflösen.

Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen 
und müssen davon leben was sie haben, ungefähr so wie Apple.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Und ein USB-Stack kostet auch keine 100000€ sondern nur einen einzigen
> engagierten Mitarbeiter der für die Sache lebt und quasi das Hobby zum
> Beruf gemacht hat

Puh, das ist brandgefährlich für eine Firma. In der Regel halten solche 
"Einzelkämpfer" nichts von Dokumentation, Styleguide und Unit testing. 
D.h. wenn er die Firma verläßt, kann man alles wegschmeißen und neu 
beginnen.
Daher ist es deutlich effizienter, eine Lib zu kaufen, die auch für 
längere Zeit supportet wird.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Während wir hier über Libraries diskutieren, sind die erfolgreichsten 
Firmen dieses Landes schon viel weiter.

Sie setzen zum Beispiel eine Blockchain für die Funkschlüssel ihrer 
Autos ein. Die Idiocracy ist mehr als ein lustiger Fil.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch
> seinen Weggang sicherlich nicht in Luft auflösen.

Code, der nicht wartbar ist, landet unweigerlich in dev/null. Man 
schmeißt schlechtem Geld nicht auch noch gutes Geld hinterher.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Code, der nicht wartbar ist, landet unweigerlich in dev/null.

Es könnte auch wartbarer Code sein. Daß der Code nichts gekostet hat 
sagt nichts über dessen Qualität aus. Wenn derjenige fähig war (was ich 
voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Stefanus F. schrieb:
>> Falk B. schrieb:
>>> Jaja, der Supermann. Es mag sein, daß es solche Leute gibt,
>>
>> Irgendwann fällt er mal aus, und dann packen alle ein und machen den
>> Laden zu, oder wie soll das ablaufen?
>
> Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch
> seinen Weggang sicherlich nicht in Luft auflösen.

Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine 
Weile geht es ohne Pflege. Aber nicht auf Dauer.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Während wir hier über Libraries diskutieren, sind die
> erfolgreichsten Firmen dieses Landes schon viel weiter.
>
> Sie setzen zum Beispiel eine Blockchain für die Funkschlüssel ihrer
> Autos ein. Die Idiocracy ist mehr als ein lustiger Fil.

"Film" sollte das wohl heißen. Aber Blockchain dürfte sicherer sein als 
keyless go. Das hat gerade wieder für viele traurige Überraschungen 
gesorgt.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Das wartbarkeitsproblem kenne ich auch reichlich. Sobald frisches Blut 
kommt werden alte Quellen verworfen und alles neu gemacht, mit anderen 
Ansätzen und neueren Technologien. Und neuen Fehlern und neuen 
Problemen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Puh, das ist brandgefährlich für eine Firma.

Nun, wenn es nur die Wahl gibt das Produkt genau so zu machen weil durch 
eine glückliche Fügung des Schicksals die Nuß geknackt wurde und die 
einzige Alternative lautet es bleiben zu lassen und jemand anderem beim 
Erfolg zuzusehen weil man es mit gekauften Legosteinen niemals hätte 
bauen können, weil Standard-Ings von der Stange nicht kompetent genug 
oder zu langsam und damit zu teuer wären dann ist das nun mal so.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine
> Weile geht es ohne Pflege. Aber nicht auf Dauer.

Dann pflegt man ihn halt weiter, wo ist das Problem?

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn derjenige fähig war (was ich
> voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben.

Bernd K. schrieb:
> Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen

Das widerspricht sich aber.
Guter Code kann sehr wohl von anderen weiter entwickelt werden und ich 
hab das auch mal erfolgreich machen können. Erst dabei merkt man, ob ein 
in sich schlüssiger Ablaufplan dahinter steckt oder ob es nur 
hingerotztes Copy&Paste ist.

von Axel Zucker (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Michael A. schrieb:
> W.S. schrieb:
>>
>> Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier
>> kommen, daß sie das Rad ja nicht nochmal erfinden wollen.

> So viel Arroganz lässt sich doch sicher noch steigern ?

???
Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das 
Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und 
Uninspirierte Technikeinstellung.
Sollte in Entwicklungsabteilung die oben mitspielen wollen ein 
Abmahngrund sein. Schliesslich wurde die Person genau für den Zweck 
eingestellt, ein rad zu erfinden das besser ist als die der mitbewerber 
und perfekt zum Produkt passt.

Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der 
Steinzeit aus einer Mammutrippe schnitzte...

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das
> Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und
> Uninspirierte Technikeinstellung.

Warst du nicht der Lustige der OpenSSL als negativ Beispiel gebracht 
hat? Ich hoffe du arbeitest in der Buchhaltung oder im Verkauf...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der
> Steinzeit aus einer Mammutrippe schnitzte...

Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen 
Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt hat.

Und deshalb widersprichst Du Dir hier selbst. Hätte der Ingenieur ganz 
von vorne anfangen müssen (wie W.S. es will), würde der Porsche 
höchstens auf Kutschenrädern fahren.

Es kann durchaus von Vorteil sein, auf guten Entwicklungen aufzusetzen 
und diese weiterzuentwickeln. Genau das macht die Evolution auch. Wenn 
sie es nicht täte, wären wir noch alle dumme Amöben.

: Bearbeitet durch Moderator
von Axel Zucker (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Axel Zucker schrieb:
>> Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das
>> Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und
>> Uninspirierte Technikeinstellung.
>
> Warst du nicht der Lustige der OpenSSL als negativ Beispiel gebracht
> hat? Ich hoffe du arbeitest in der Buchhaltung oder im Verkauf...

Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner 
Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so 
kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit 
nachzudenken und primitivstes Handwerkszeug ignorierte.

Und dann kommst du vielleicht drauf das ich nicht mit Entwicklungsfernen 
Themen zu tun habe sondern schon so meine Jahrzehnte "Front"-Erfahrung 
mitbringe.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Bernd K. schrieb:
>> Wenn derjenige fähig war (was ich
>> voraussetzte) hat er exzellenten und vorbildlichen Code geschrieben.
>
> Bernd K. schrieb:
>> Die können dann halt nur in Zukunft keine neuen Innovationen mehr machen
>
> Das widerspricht sich aber.

Nein, damit meinte ich wenn die guten Leute weg sind können sie zwar 
noch auf dieser Welle weiter reiten und das Produkt und Variationen 
davon noch jahrelang weiter bauen, sobald aber die Konkurrenz aufgeholt 
hat und wieder eine ganz neue Idee, ein neuer vergleichbarer Stunt nötig 
wäre um wieder was unmöglich geglaubtes aus dem Ärmel zu schütteln wäre 
dann Ende.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Wo W.S. Recht hat hat er Recht, in 99,99% der Fälle ist "Ich will das
> Rad nicht neu erfunden" eine Ausrede für (Denk-)Faulheit und
> Uninspirierte Technikeinstellung.

Oft genug ist Software und ein µC/PC nur Mittel zum Zweck. Da sitzen 
E-Techniker, Physiker oder gar Maschinenbauer die auch noch die SW 
erstellen sollen. Da nimmt man eben was brauchbar aussieht und schnell 
geht...

PS: sollte keine Beleidiung der genannten Berufe sein. Ich kenne auch 
einen Zahnarzt der schreibt bessere SW als manche Informatiker.

: Bearbeitet durch User
von Axel Zucker (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Frank M. schrieb:
> Axel Zucker schrieb:
>> Ein Porsche fährt eben nicht auf Rädern die ein Neandertaler in der
>> Steinzeit aus einer Mammutrippe schnitzte...
>
> Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen
> Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt hat.

Wobei nicht davon auszugehen ist, das der aktuelle Wissenstand zwingend 
in einer externen Bibliothek zu finden ist.

PS:
Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist 
auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes 
Nachdenken hat.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist
> auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes
> Nachdenken hat.

Sei froh, dass Deine Eltern das anders gesehen haben, als sie Dir das 
Sprechen beibrachten. ;-)

Trotzdem hast Du Dich bis heute aus eigener Kraft weiterentwickeln 
können.

P.S.
Du hast mich sinnenstellend zitiert. Ich schrieb "Auf den aktuellen 
Wissenstand aufsetzen und diese weiterzuentwickeln "

: Bearbeitet durch Moderator
von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner
> Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so
> kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit
> nachzudenken und primitivstes Handwerkszeug ignorierte.

Bitte erleuchte mich. Welches primitive Handwerkszeug soll das sein?

Wer ernsthaft behauptet in C/C++ noch nie einen Range-basierten Bug 
produziert zu haben der hat Potential in die Politik zu gehn. Dort sucht 
man immer nach Lügnern.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Axel Zucker schrieb:
>> Na lies mal nach, wofür ich OpenSSL als beispiel genannt habe, kleiner
>> Tipp der Heartbleed-Bug ist keiner der entstand weil das Thema so
>> kompliziert war, sondern weil einer keine Lust hatte bei seiner Arbeit
>> nachzudenken und primitivstes Handwerkszeug ignorierte.
>
> Bitte erleuchte mich. Welches primitive Handwerkszeug soll das sein?

Folge dem Link: 
https://motherboard.vice.com/de/article/kb754w/deutscher-hat-heartbleed-fehler-an-silvester-vor-zwei-jahren-programmiert

Ansonsten dürfte es doch einem Entwickler ein Leichtes sein, das 
entsprechende diff aus dem repo zu holen oder den für ihn 
verständlichsten Kommentar aus dem Internet zu ziehen.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Axel Zucker schrieb:
>> Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist
>> auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes
>> Nachdenken hat.
>
> Sei froh, dass Deine Eltern das anders gesehen haben, als sie Dir das
> Sprechen beibrachten. ;-)
>
> Trotzdem hast Du Dich bis heute aus eigener Kraft weiterentwickeln
> können.

Sorry, ich verstehe nicht was du sagen willst ???

Das Problem an der Phrase ist: "aufsetzen".
Das klingt als ob das auch der ungelernte Möbelschubser kann. Gemeint 
ist aber das man den "Aktuellen Wissensstand" mindestens verstanden 
haben muß um ihn sinnvoll anwenden zu können. Und manches versteht man 
eben am besten, wenn man es (im Ansatz/in Teilen) selber macht. - 
"Learning by doing" eben.

Sonst endet es wieder mal bei wenig hilfreichen: "ich weiss auch nicht 
wo der fehler liegt aber lass uns mal auf das nächste Update warten ..."

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
>> Der Code den er zu Lebzeiten der Firma gespendet hat wird sich durch
>> seinen Weggang sicherlich nicht in Luft auflösen.
>
> Ein verbreiteter Irrtum. Code ist wie Fingernägel. Oder Haare. Eine
> Weile geht es ohne Pflege. Aber nicht auf Dauer.

Interessanter Vergleich!

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> P.S.
> Du hast mich sinnenstellend zitiert. Ich schrieb "Auf den aktuellen
> Wissenstand aufsetzen und diese weiterzuentwickeln "

Doch, ich habe Dich exakt zitiert:
"Und zwar deshalb nicht, weil der Ingenieur auf dem aktuellen
Wissensstand aufsetzte, als er die Räder für den Porsche entwickelt 
hat."

Die untere Zitierfähige Stelle zum Wissenstand habe ich überlesen - die 
klingt für mich aber auch mehr in Richtung Denkvermeidung statt 
Auseinanderstzung/Hinterfragung.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
netzwelt.de, vice

Was kommt als nächstes? bild.de?

Den "Artikel" hab ich jetzt trotz heftigem Brechreiz gelesen. Meine 
Frage bleibt allerdings unbeantwortet stehn. Nach wie vor scheinst nur 
du den heiligen Gral gefunden zu haben mit dem man Buffer-Overflows und 
Konsorten Herr wird.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Sorry, ich verstehe nicht was du sagen willst ???

Okay, dann mal ganz langsam:

1. Man kann auf einer Entwicklung aufsetzen.

Beispiel: Der Porsche-Räder-Entwickler schaut sich den aktuellen 
Wissenstand der Autoindustrie an.

2. Man adaptiert diesen Wissensstand (bzw. diese Bibliothek)

Beispiel: Der Porsche-Räder-Entwickler berechnet die Geometrie, das 
Fahrverhalten (und was noch alles) des Porsche und passt den aktuellen 
Wissensstand, was Räder betrifft, an.

Bis hierher hat man nur dumpf abgekupfert und ein wenig angepasst.

Jetzt kommt aber der entscheidende Schritt, den Du nicht einfach bisher 
nicht nachvollziehst:

3. Man verbessert das Produkt anhand dieser Adaption und gibt diese 
weiter.

Beispiel: Der Porsche-Räder-Entwickler verbessert anhand von Versuchen 
bzw. Computerberechnungen sein Porsche-Rad und veröffentlicht diese 
neuen Erkenntnisse.

Wenn Du Dir Schritt 3. verinnerlichst, magst Du mir nun zustimmen, dass 
man "auf dem aktuellen Wissensstand aufsetzen" nicht pauschal verteufeln 
darf! Ganz im Gegenteil: Man spart eine Menge Entwicklungszeit und kann 
das eigene Produkt wesentlich effizienter weiterentwickeln. Diesen 
letzten Schritt magst Du vielleicht einem schnöden Bibliotheksanwender 
absprechen, aber deshalb sind die Schritte 1 und 2 trotzdem auch für 
einen Entwickler nicht falsch.

Jetzt verstanden? Deine Eltern haben Dir etwas auf den Weg gegeben, 
nämlich "Sprache", die Dir ermöglicht hat, Dich weiterzuentwickeln. 
Hätten sie das nicht getan, wärest Du vielleicht heute erst dabei, das 
Lesen zu lernen.

: Bearbeitet durch Moderator
von Axel Zucker (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> netzwelt.de, vice
>
> Was kommt als nächstes? bild.de?
>
> Den "Artikel" hab ich jetzt trotz heftigem Brechreiz gelesen. Meine
> Frage bleibt allerdings unbeantwortet stehn. Nach wie vor scheinst nur
> du den heiligen Gral gefunden zu haben mit dem man Buffer-Overflows und
> Konsorten Herr wird.

Mit Verlaub, ich mach nicht den Dompteur in deinem Affentheater. Folge 
einfach den Links und du kommst auf die beschreibung:
"In one of the new features, unfortunately, I missed validating a 
variable containing a length."

Dr Seggelmann said the error he introduced was "quite trivial", but 
acknowledged that its impact was "severe"."

Und meiner Erfahrung nach lernt man bereits als Informatikschulbub das 
man die Länge von variablen überprüft um buffer overruns zu vermeiden. 
Also bsplw. strnlen() statt strlen zu verwenden, wenn überhaupt.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist
> auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes
> Nachdenken hat.

Nö, das ist der Grund, warum wir heute dort stehen wo wir stehen, weil 
eben nicht jeder erst das Rad neu erfinden muss, ebenso wir wir das 
Ohmsche Gesetz nicht erst neu entdecken müssen, das ist alles schon da.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Nichts für Ungut, aber "Auf den aktuellen Wissenstand aufsetzen" ist
> auch so ne Hohlphrase die man bringt wenn man keinen Bock auf Eigenes
> Nachdenken hat.

Nö, das ist der Grund, warum wir heute dort stehen wo wir stehen, weil 
eben nicht jeder erst das Rad neu erfinden muss, ebenso wir wir das 
Ohmsche Gesetz nicht erst neu entdecken müssen, das ist alles schon da.

Axel Zucker schrieb:
> Das Problem an der Phrase ist: "aufsetzen".
> Das klingt als ob das auch der ungelernte Möbelschubser kann.

Ich glaube, das verstehst nur du so... Aber ja, um einen Prozessor zu 
verwenden, muss ich tatsächlich nicht verstehen, wie er auf 
Transistorebene funktioniert.

von Axel Zucker (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Frank M. schrieb:
> 2. Man adaptiert diesen Wissensstand (bzw. diese Bibliothek)
>
> Beispiel: Der Porsche-Räder-Entwickler berechnet die Geometrie, das
> Fahrverhalten (und was noch alles) des Porsche und passt den aktuellen
> Wissensstand, was Räder betrifft, an.
>
> Bis hierher hat man nur dumpf abgekupfert und ein wenig angepasst.
>
> Jetzt kommt aber der entscheidende Schritt, den Du nicht einfach bisher
> nicht nachvollziehst:
>
> 3. Man verbessert das Produkt anhand dieser Adaption und gibt diese
> weiter.

Das was du hier als "Schritt" darstellst ist IMHO nur ein rhetorischer 
Kniff um das Auditorium zu blenden. Ich sehe nicht wie aus einer 
"Abkupferei" eine "Adaption" wird, in dem man "Schritt" dazusagt.

Adaption bedeutet Umbau, und um etwas unzubauen muss man es zerlegen, 
und um etwas zerlegen zu konnen muss man verstanden haben wie es 
funktioniert - auf beiden seiten - der eigenen -Porsche- und der anderen 
-Knochenrad-.

Klar kann man auch das Knochenrad mit einer Kohlefasermanchete an den 
Porsche klatschen um dann in der Validierungsphase draufzukommen, das es 
so nicht geht  Iund das man mit ein bißchen nachdenken das vorher hätte 
draufkommen können das Knochen den Porsche nicht trägt.

von Vincent H. (vinci)


Bewertung
2 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Und meiner Erfahrung nach lernt man bereits als Informatikschulbub das
> man die Länge von variablen überprüft um buffer overruns zu vermeiden.
> Also bsplw. strnlen() statt strlen zu verwenden, wenn überhaupt.

Und meiner Erfahrung nach sind arrogante Entwickler die, die den 
schlimmsten Code hinrotzen.

Glücklicherweise sind eben jene Entwickler recht leicht zu 
identifizieren, sie schmeißen nämlich recht gern mit kurzen Phrasen 
umsich.
"Ich hab einen Bug in deinem Code gefunden."
"Ich brauch keine Unit Tests."
"Ich mach keine Logik Fehler."
"Das ist ein Hardware Fehler der noch nicht im Errata steht."

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Das was du hier als "Schritt" darstellst ist IMHO nur ein rhetorischer
> Kniff um das Auditorium zu blenden. Ich sehe nicht wie aus einer
> "Abkupferei" eine "Adaption" wird, in dem man "Schritt" dazusagt.

Sagen wir besser: Du willst es nicht sehen. Oder Du hältst pauschal alle 
Anwender einer Bibliothek für Idioten.

Beides spricht nicht für Dich, egal wie Du es drehst.

von Axel Zucker (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Frank M. schrieb:
> Beides spricht nicht für Dich, egal wie Du es drehst.

Danke, gleichfalls und End of Communication.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Es ist doch ganz einfach: Wenn keine Library existiert die alle 
Anforderungen erfüllt dann muss man selber eine schreiben oder eine 
existierende so umbauen/abspecken/aufbohren daß sie es tut. Jeder hat 
andere Anforderungen, manche haben auch ganz spezielle Anforderungen und 
manchmal gibts einfach nichts von der Stange.

Die gängige deutsche Ingenieursmeinung hier im Forum scheint zu sein 
stattdessen die Anforderungen so lange runterzuschrauben bis die Herren 
Entwickler sich nicht mehr anstrengen müssen. Das ist natürlich auch ein 
Weg den man gehen kann. Andere denken halt anders darüber.

: Bearbeitet durch User
von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Die gängige deutsche Ingenieursmeinung hier im Forum scheint zu sein
> stattdessen die Anforderungen so lange runterzuschrauben bis die Herren
> Entwickler sich nicht mehr anstrengen müssen.

Oder man spart sich die Prüfung der Anforderung komplett, deklariert 
eine beliebige Bibliothek pauschal als "fertig" und versichert sich der 
Unterstützung aus einem Forum durch einen herbeigekasperten Thread ....

PS:
Allerdings bin ich nicht der Meinung, das dies "gängige deutsche 
Ingenieursmeinung" wäre, da ich ansonsten Nationalität und Bildungsweg 
verleugnen müsste  ;-)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Das Genie ist nicht der, der unnützt Zeit damit verschwendet, bereits 
vorhanden Grundfunktionen nachzuprogrammieren und damit zusätzliche 
Fehlerquellen einzubauen.
Sondern das Genie ist der, der möglichst effizient unter Einsatz der 
Bibliotheken die eigentliche Aufgabe löst, d.h. innovativ ist. Dann kann 
man sich voll auf das Problem konzentrieren und ist nicht mit 
irgendwelchem Urschleim abgelenkt.
Ich weiß, wie ich printf verwende, daher muß ich keine Zeit damit 
vergeuden, eigene Ausgabefunktionen zu schreiben.
Wer unbedingt mag, der kann ja Grundfunktionen in seiner Freizeit 
nachprogrammieren und testen, da muß man dann nicht effizient sein.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
Hi

Das ist das schöne, an solchen Grabenkriegen....

Solange man den Kontext nicht klärt, schaut jeder aus sich selber heraus 
auf die Anderen. Damit kommt man dann zu tausend widersprechenden 
Aussagen, die dann alle (mehr oder weniger) wahr sind.

Natürlich macht es Sinn, in der Lernphase, Standard Routinen selber zu 
schreiben.

Ebenso macht es Sinn, wenn die vorhandenen Dinge nicht ausreichen, was 
neues zu bauen.

Und ebenso viel Sinn macht es, sich aus dem Library Baukasten zu 
bedienen, wenn man schnell fertig werden muss/will.

Natürlich spielen dann auch noch die Firmen Richtlinien, und 
irgendwelche notwendigen Zertifizierungen, eine 
tragende/richtungsweisende Rolle.

von W.S. (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Michael A. schrieb:
> W.S. schrieb:
>>
>> Auch wenn Leute, die zu wenig draufhaben, mit der ewigen Ausrede-Leier
>> kommen, daß sie das Rad ja nicht nochmal erfinden wollen.
>>
>> W.S.
>
> So viel Arroganz lässt sich doch sicher noch steigern ?
>
> Gruß,
> Michael

Du verwechselst da etwas. Ich erinnere mal wieder an Adenauer und dessen 
Spruch vom Horizont.

Arroganz ist, wenn jemand nix drauf hat und dennoch so tut, als hätte er 
was drauf und die anderen nicht.

Aber ich habe das drauf, deswegen ist das eben keine Arroganz. Es wird 
nur von Leuten gern verwendet, denen nach Stänkern zumute ist.

So, ich denke, dieses Teilthema wäre damit final geklärt.

Zum Kernthema hier:
Die Ansichten einiger hier, daß man auf biegen&brechen bei irgendwelchen 
Standard-Bibliotheken bleiben soll, deutet mir auf eben eine zu kleine 
entwicklerische Potenz hin. Ebenso die falsche Aussage, daß es für 
ungenutzten Flash kein Geld zurück gäbe. Das Geld kommt nämlich vom 
nächstkleineren Chip.

Richtig ist hingegen, daß man schlichtweg Augenmaß haben sollte, was man 
benutzt und was nicht. Leider ist eben auch richtig, daß Leute, deren 
Fertigkeiten sich auf copy&paste beschränken, gar keine andere Wahl 
haben - es sei denn, sie setzen sich auf ihren Hosenboden und lernen 
dazu (sofern sie können und nicht zu faul sind). Das ist hier vermutlich 
der tiefere Grund all der gehabten Diskussion.

W.S.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Das Geld kommt nämlich vom
> nächstkleineren Chip.

In der Regel sind aber nicht die Libs der Hauptverbraucher an Flash. 
Beim AVR belegt printf ~1kB (ohne float-support).
Wenn ich also ein 20kB Programm habe und nun mühsam das printf 
rausoperiere, dann komme ich vielleicht auf 19,5kB runter, das reicht 
aber nicht für den nächst kleineren Chip.

Der Hauptverbraucher an Flash ist in der Regel eine unüberlegte und 
planlose Programmierung mit riesigen Copy&Paste Sequenzen.
Mit einem durchdachten Programmablaufplan, bevor man überhaupt Code 
schreibt, kommt man dagegen oft auf 50% Einsparung.

von Falk B. (falk)


Bewertung
4 lesenswert
nicht lesenswert
@W.S. schrieb:

> Arroganz ist, wenn jemand nix drauf hat und dennoch so tut, als hätte er
> was drauf und die anderen nicht.

Der geht anders.

Ein hohes Niveau sieht nur von unten wie Arroganz aus. ;-)

> Die Ansichten einiger hier, daß man auf biegen&brechen bei irgendwelchen
> Standard-Bibliotheken bleiben soll, deutet mir auf eben eine zu kleine
> entwicklerische Potenz hin.

Du solltest an deinem Textverständnis arbeiten. Das hat so kein Einziger 
weder formuliert noch gemeint.

> Richtig ist hingegen, daß man schlichtweg Augenmaß haben sollte, was man
> benutzt und was nicht.

Ach ne?

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Ebenso die falsche Aussage, daß es für
> ungenutzten Flash kein Geld zurück gäbe. Das Geld kommt nämlich vom
> nächstkleineren Chip.

Wer nur auf Kante näht, kann bald alles wegwerfen (wenn der Platz für 
Änderungen nicht mehr reicht). Bisher ist mir noch kein Programm 
aufgefallen, was kleiner geworden ist. Es bestand eher der Wunsch, dem 
Kunden noch eine "Verbesserung" zu verkaufen.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
> Hi,
>
> was ist besser. Die fertige Bibliothek(wo halt die elementaren Sachen
> drin stehen, also die Stdio.h) für den Mikrocontroller vom Hersteller
> verwenden oder selber schreiben? Was ist gängig in der Industrie?

Warum oder? Ich kenne das so, dass beides verwendet wird.

Da, wo es schon eine fertige und gut funktionierende Bibliothek für 
etwas gibt (z.B. gmp, libcurl, ...) sollte man das Rad nicht neu 
erfinden.

Freilich erstellen Firmen auch eigene Bibliotheken. Ist ja nicht so, 
dass es für jede Branche und für jedes Produkt schon alle Libs 
vorgefertigt gäbe, die man so brauchen kann.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Falk B. schrieb:
> Rolf M. schrieb:
>>>> Ich finde Schlimm, dass du damit Recht hast. Jura geht über fachliche
>>>> Vernunft, weil unsere Gesetze und Gerichte von Juristen gemacht sind.
>>>
>>> Wer sollte sie sonst machen? Wurstfachverkäufer?
>>
>> Nicht nur Leute, die von Jura Ahnung haben, sondern auch Leute, die das
>> Thema, das gesetzlich geregelt werden soll, wenigstens einigermaßen
>> verstehen.
>
> Es gibt Fachjuristen.

Ja, die müssen dann aber beim Beschließen eines Gesetzes auch anwesend 
sein, und nicht erst nachher, um zu versuchen, in das eigentlich 
unsinnige Gesetz irgendwas brauchbares reinzuinterpretieren.

>> Wenn man dagegen
>> kundenspezifische Einzellösungen baut, ist es praktisch immer viel
>> billiger, den nächstgrößeren Boliden zu kaufen als durch selber
>> schreiben irgendwelcher Libs das Programm zu optimieren.
>
> Das hat mit kundenspezifisch wenig zu tun sondern was mit Stückzahlen.

Deswegen schrieb ich ja das Wort "EINZELLÖSUNGEN" dazu - Stückzahl 
eins. Kennst du da welche, die nicht kundenspezifisch sind?

> Wenn ich 100.000 Euro Entwicklungskosten habe, die meist zum größten
> Teil Personalkosten (=Zeit) sind, ist es halt ein Unterschied ob ich die
> auf 10 oder 10.000 verkaufte Produkte umlegen kann!

Bei dem, was ich tue, gibt's meist kein Produkt, sondern ein Gewerk, von 
dem ich genau 1 verkaufe. Die Personalkosten verteilen sich also nicht. 
Und genau davon sprach ich: Da lohnt es sich nicht selten, etwas 
Fertiges für viel Geld zu kaufen, statt es für noch viel mehr Geld 
selbst zu entwickeln.

> Time is Money ist kein leeres Geschwätz sondern Realität.

Sag ich ja.

von Florian (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
Volle schrieb:
> Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und
> einhalten.

Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht 
vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt.

Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an 
anderer Stelle stehen. Sodass auch das Kompilat sich ändert....

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
Florian schrieb:
> Volle schrieb:
>> Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und
>> einhalten.
>
> Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht
> vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt.
>
> Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an
> anderer Stelle stehen. Sodass auch das Kompilat sich ändert....

Dir wünsche ich aus vollem Herzen eine Klage an den Hals. Unterirdischer 
gehts ja wohl nicht mehr, hier öffentlich zu gewerblichen 
Urheberrechtsverletzungen aufzurufen! Ich glaub mein Schwein pfeift!

Ich möchte Dich mal sehen was Du dazu sagen würdest wenn einer Deinen 
Code klauen und Umsätze damit generieren würde. Aber wahrscheinlich kann 
das gar nicht geschehen weil Du noch nie was selbst geschaffen hast das 
es wert gewesen wäre von jemand anderem zu Geld gemacht zu werden, nur 
so lässt sich so eine kranke Einstellung erklären.

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
Florian schrieb:
> Volle schrieb:
>> Nicht vergessen die Lizenzbedingungen für den Fremdcode prüfen und
>> einhalten.
>
> Wenn man uC wie Stm32 oder AVR programmiert (natürlich lockbits nicht
> vergessen) so kann keiner euch nachweisen welche Libs ihr genommen habt.
>
> Ansonsen Libs nachschreiben bzw so abändern dass einige Funktionen an
> anderer Stelle stehen. Sodass auch das Kompilat sich ändert....

Du empfiehlst also, gegen die Lizenzbedingungen bewusst zu verstoßen und 
das einfach durch diese Maßnahmen zu verschleiern?
Naja, wenigstens ist so die Strafe höher, wenn es dann doch auffliegt.

von Βιβλιοθηκονόμος (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Und ebenso viel Sinn macht es, sich aus dem Library Baukasten zu
> bedienen, wenn man schnell fertig werden muss/will.

Aber man sollte sich auch der negativen Auswirkungen bei dauerhaft 
exzessiven und ausschliesslichem Gebrauch von (zusammengepanschten) 
Bibliotheken auf den Charakter bewusst sein:

-Verlust der Fähigkeit sich in Specs einzulesen oder eigene klar zu 
formulieren
-zunehmende Oberflächlichkeit
-gerät Programmiertechnisch" aus der Übung
-Verleugnen resp. Verharmlosen von Bugs aus ungesichteten Code
-der stete Drang Nachschub in Form von updates zu organisieren lenkt von 
anderen Optionen der "Problemlösung" ab


Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem, 
fett und unsicher über die eigenen Fähigkeit und beschränkt den 
Wettbewerb mit Nachwuchstalenten auf grimmiges Knurren und Verweis auf 
verstaubte Trophäen.

;-)

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:

> Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem,
> fett und unsicher über die eigenen Fähigkeit und beschränkt

Wie oft fährst du mit dem Fahhrad Strecken > 50km?

von Βιβλιοθηκονόμος (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Βιβλιοθηκονόμος schrieb:
>
>> Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem,
>> fett und unsicher über die eigenen Fähigkeit und beschränkt
>
> Wie oft fährst du mit dem Fahhrad Strecken > 50km?

Lange Strecken sind keine akzeptierten Ausreden für totalen 
Bewegungsmangel.

So wie man als Berufsfahrer auch mal Strecken zu Fuß gehen oder radeln 
kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als 
Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren).
Wie heisst es so treffend: "Wer rastet, der rostet" und "Adipositas ist 
keine Berufskrankheit"

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:

> kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als
> Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren).

Hat dis irgenendeiner bestritten oder gar verboten?
Die Argumentation lief die meiste Zeit doch nur gegen das "ich kann 
alles besser, ich mach alles selber".

von Βιβλιοθηκονόμος (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Falk B. schrieb:

> Die Argumentation lief die meiste Zeit doch nur gegen das "ich kann
> alles besser, ich mach alles selber".

Na und dann Argumentieren wir mal zur Abwechslung:
"Ich mach nichts selber, weil das ist mir zu groß und wenn ich 
irgendwann komplett aus der Übung bin, dann ist das unvermeidbar"

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:
> Ist halt wie der Fahrradfahrer der aufs Auto umsteigt - man wird bequem,
> fett und unsicher über die eigenen Fähigkeit und beschränkt den
> Wettbewerb mit Nachwuchstalenten auf grimmiges Knurren und Verweis auf
> verstaubte Trophäen.

Wenn Du aber mit dem Fahrrad zu spät kommst, fragt man Dich, warum Du 
nicht das Auto genommen hast.
Wenn Du die Programmieraufgabe nicht termingerecht löst, fragt keiner 
danach, daß Du printf, Ethernet, USB usw. zu Fuß nachentwickelt hast, 
denn das war nicht Deine Aufgabe. Aber Dein Chef fragt sich, ob er Dich 
abmahnen soll und die Mitbewerber lachen sich ins Fäustchen.

Will man effizient arbeiten, beschränkt man sich nur auf die eigentliche 
Applikation, d.h. man wird schneller fertig und macht weniger Fehler.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Da, wo es schon eine fertige und gut funktionierende Bibliothek für
> etwas gibt (z.B. gmp, libcurl, ...) sollte man das Rad nicht neu
> erfinden.

Wir nutzen auf Arbeit so ein kleines Bibliothekchen namens "Android"... 
und nein, das entwickeln wir nicht selbst. Auch vermeiden wir unter 
großen Schmerzen, daran Änderungen vorzunehmen.

Und das hat Gründe.

von wenn nicht der Weg das Ziel ist... (Gast)


Bewertung
2 lesenswert
nicht lesenswert
0815 schrieb:
> oder selber schreiben?

Natürlich selber schreiben, alles, auch den Compiler, das BS deines PCs, 
alles! :-<<<

Warum das Rad neu erfinden. Konzentriere dich auf das Neue, dein Problem 
und vertraue der Generation vor dir. ;-)

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
-2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wenn Du aber mit dem Fahrrad zu spät kommst, fragt man Dich, warum Du
> nicht das Auto genommen hast.

Dann lautet die Antwort, dass man bei Verwendung eines Auto 
möglicherweise noch viel später angekommen wäre. Warum wird auch in 
diesem Thread die bedingungslose Überlegenheit von Autos postuliert? 
Ach, ich vergaß, dass wir in Deutschland sind.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:
> So wie man als Berufsfahrer auch mal Strecken zu Fuß gehen oder radeln
> kann (Freizeitsport, Weg zur Arbeitsstätte), so kann man auch als
> Entwickler mal ne Funktion selber schreiben, resp. fremde analysieren).

Mal ne Funktion/Lib selbst schreiben ist auch ne andere Hausnummer als 
jede Lib selbst zu schreiben. Nicht hier Äpfel mit Birnen vergleichen 
;)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:
> Aber man sollte sich auch der negativen Auswirkungen bei dauerhaft
> exzessiven und ausschliesslichem Gebrauch von (zusammengepanschten)
> Bibliotheken auf den Charakter bewusst sein:

Ich möchte mal wissen, wie Du herausgelesen hast, daß auch nur ein 
einziger hier so arbeitet. In meinen Augen ist das ein völlig haltlose 
Unterstellung.

Natürlich kauft man im gewerblichen Umfeld einen professionellen 
Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit 
den Bibliotheken, dann wendet man sich an den Support. Man verschwendet 
aber keine Zeit damit, Bibliotheken nachzuentwickeln.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Natürlich kauft man im gewerblichen Umfeld einen professionellen
> Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit
> den Bibliotheken, dann wendet man sich an den Support. Man verschwendet
> aber keine Zeit damit, Bibliotheken nachzuentwickeln.

Genau. Und aus dem selben Grund lässt man im gewerblichen Umfeld auch 
keine ASICs entwickeln für Millionen und Abermillionen sondern klöppelt 
alles aus klobigen Standardbauteilen zusammen, auch wenns dann zwölf mal 
so groß wird und nicht mehr in so ein schnuckeliges kleines Gehäuse 
passt wie das der unverantwortlich selbstfrickelnden Mitbewerber.

Und wer ganz klug ist entwickelt gar nichts mehr, reine 
Zeitverschwendung, schließlich kann man heutzutage alles fertig in China 
kaufen. Nur so wird man zur Hi-Tech Weltmacht.

Was wir also in Zukunft brauchen sind Fachkräfte die Tetris mit 
Lego-Bausteinen spielen können und diese Bausteine fallen bekanntlich 
vom Himmel wie jeder sicherlich weiß.

[Übertreibungen erhöhen die Anschaulichkeit]

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Dir wünsche ich aus vollem Herzen eine Klage an den Hals. Unterirdischer
> gehts ja wohl nicht mehr, hier öffentlich zu gewerblichen
> Urheberrechtsverletzungen aufzurufen! Ich glaub mein Schwein pfeift!

Komm runter von der Palme.

Wenn jemand den Chip von Firma X einkauft und den mit den Lib's von 
Firma X beglückt - welche diese Firma X genau dafür vorgesehen hat - 
dann steckt da überhaupt keine Rechtsverletzung drin.

Aber indem dieser Jemand sich auf die dargebotene Lib von X eingelassen 
hat, hat er sich fröhlich einen Ring durch die Nase ziehen lassen und 
ist nun an der Kette der Firma X.

Wenn es bei der Firma Y nun einen Chip gibt, der für den Jemand 
eientlich besser wäre, dann kann er den nicht benutzen, weil die Libs 
von X partout nicht auf den Chip von Y passen.

Also wäre der Jemand drauf angewiesen, sich in den von Y dargebotenen 
Libs umzusehen und sein ganzes Projekt auf das Zeugs von Y umzustellen. 
Das wäre der Austausch des Rings durch die Nase von X nach Y.

Und: Selbstverständlich kennen die Firmen X und Y sich innig - und so 
achten sie pingelig darauf, daß kein Kunde ohne erheblichen Mehraufwand 
eine Lib vom einen mit dem Chip vom anderen verwenden kann.

Falls es zu den jeweiligen Libs nen Quellcode geben sollte, dann ist der 
so gestaltet, daß das Umschreiben möglichst schön aufwendig ist und 
inhaltlich an eine komplette Neufassung heranreicht.

Linux ist da ein klassischer Fall. Nichts von Unix im juristischen Sinne 
verwendet, sondern alles "selbst und neu" geschrieben. Ähnlichkeiten 
sind rein zufälliger Art. Das übliche Kleingedruckte eben.

Eigentlich ist das Problem klar: Firmen sind bemüht, ihre Kunden an sich 
zu binden und keinen Vorschub zu leisten für Chips anderer Hersteller - 
und Anwender sollten eigentlich bemüht sein, sich nicht freiwillig in 
unnötige Abhängigkeiten zu manövrieren - auch wenn das Dargebotene auf 
den allerersten Blick vorteilhaft aussehen sollte.

Es ist eben ein grundsätzlicher Interessenkonflikt.

W.S.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Und aus dem selben Grund lässt man im gewerblichen Umfeld auch
> keine ASICs entwickeln für Millionen und Abermillionen sondern klöppelt
> alles aus klobigen Standardbauteilen zusammen

Woher nimmst Du diese Gewißheit?
Man sollte immer die Lösungen nehmen, die für das Problem optimal 
passen. Für viele Aufgaben wären ASICs der absolute Overkill.
Und ja, 0201 Kondensatoren mag ich nicht. Ich nehme die "klobigen" im 
0603, die kann ich gerade noch händisch löten. Auf die Gehäusegröße hat 
das eh keinen Einfluß.

Bernd K. schrieb:
> Und wer ganz klug ist entwickelt gar nichts mehr, schließlich kann man
> heutzutage alles fertig in China kaufen.

Schön wärs, wir können uns vor Entwicklungsaufgaben nicht retten, aber 
Elektronikentwickler sind Mangelware.

von Rolf M. (rmagnus)


Bewertung
4 lesenswert
nicht lesenswert
W.S. schrieb:
> Linux ist da ein klassischer Fall. Nichts von Unix im juristischen Sinne
> verwendet, sondern alles "selbst und neu" geschrieben. Ähnlichkeiten
> sind rein zufälliger Art. Das übliche Kleingedruckte eben.

Die Ähnlichkeiten sind nicht "zufällig", sondern nennen sich POSIX und 
sind eine ISO- und IEEE-Norm.
Es gibt auch einen großen Unterschied, ob man eine eigene Implementation 
einer Spezifikation schreibt, oder ob man fremden Code illegal in sein 
Programm einbaut und dann ein paar Sachen ändert und umsortiert, um 
damit diesen Tatbestand zu verschleiern.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Schön wärs, wir können uns vor Entwicklungsaufgaben nicht retten, aber
> Elektronikentwickler sind Mangelware.

Offenbar aber auch wieder nicht so sehr, als dass man bereit wäre, die 
Gehälter ordentlich anzuheben.

Wie war das doch gleich? Wenn die Nachfrage groß ist und das Angebot 
gering, dann steigt entsprechend deutlich der Preis...

Komischerweise soll das für Personalkosten aber nicht gelten. :-/

von Βιβλιοθηκονόμος (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Mark B. schrieb:
> Wie war das doch gleich? Wenn die Nachfrage groß ist und das Angebot
> gering, dann steigt entsprechend deutlich der Preis...
Wenn der Preis allerdings die Mittel des Käufers übersteigt gibts gar 
kein Geschäft und die Mittel des potentialen Käufers sinken weiter. 
Siehe Stadt Berlin, da läuft ohne Zuschuß wie Länderfinanzausgleich 
inzwischen garnichts und die Stadt verkommt zu einer H4-Verwahranstalt.

Peter D. (peda) hinterliess:
>Ich möchte mal wissen, wie Du herausgelesen hast, daß auch nur ein
>einziger hier so arbeitet.

Siehe die Diskussion zu der Behauptung, das keiner eine USB-Bibliothek 
selbst erstellt respektive schon der Gedanke daran dazu reine Blasphemie 
wäre. [Übertreibungen erhöhen die Anschaulichkeit]

Und ausserhalb dieses threads die Hilflösung wenn ein ganz bestimmtes 
Update einer (Arduino-)Bibliothek benötigt wird. Fällt mir persönlich 
regelmäßig beim Lesen der make auf; da wird gross Hintergrundinfo zu 
einem technischen Schmankerl versprochen die dann lediglich auf den 
Verweis auf eine bekantermassen unvollständige und wacklige Bibliothek 
besteht. Bspw.: https://www.heise.de/select/make/2018/1/1519688503646911

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Βιβλιοθηκονόμος schrieb:
> Siehe die Diskussion zu der Behauptung, das keiner eine USB-Bibliothek
> selbst erstellt respektive schon der Gedanke daran dazu reine Blasphemie
> wäre. [Übertreibungen erhöhen die Anschaulichkeit]

Du pickst Dir einzelne Meinungen heraus und unterstellst sie als 
allgemein gültig. Dem ist nicht so. Das hat nichts mit Übertreibung zu 
tun, sondern ist reines Klischeedenken.

Βιβλιοθηκονόμος schrieb:
> Fällt mir persönlich
> regelmäßig beim Lesen der make auf;

Ich bezweifle mal stark, daß hier auch nur ein einziger die make als 
Fachzeitschrift ansieht. Sich auf die make zu beziehen, ist ein Witz. 
Damit nimmt Dich niemand mehr ernst.

Du solltest Dir mal den Unterschied zwischen professionell und 
Hobbybastler klarmachen. Den gibt es nämlich.

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Du solltest Dir mal den Unterschied zwischen professionell und
> Hobbybastler klarmachen. Den gibt es nämlich.

Das vermischen hier viele und wer will es ihnen schon verdenken ;)

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Du solltest Dir mal den Unterschied zwischen professionell und
> Hobbybastler klarmachen. Den gibt es nämlich.

Sicher gibt es den, der hat aber an sich erstmal nichts mit der Qualität 
zu tun - weder in der Ausführung, noch im Ergebnis.

Es gibt aber auf einen Unterschied zwischen ordentlicher Arbeit und 
"works for me". Und zwischen Embedded-Entwicklung und Web-Development 
(und den vorherrschenden Mentalitäten).

Βιβλιοθηκονόμος schrieb:
> [Übertreibungen erhöhen die Anschaulichkeit]

Starke Übertreibungen stellen in erster Linie den Übertreiber als 
inkompetent und/oder böswillig dar. Klassisches Beispiel: Verkäufer.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> mal den Unterschied zwischen professionell und
> Hobbybastler klarmachen. Den gibt es nämlich.


> Natürlich kauft man im gewerblichen Umfeld einen professionellen
> Compiler mit IDE, Bibliotheken und Supportvertrag. Gibt es Probleme mit
> den Bibliotheken, dann wendet man sich an den Support.


Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann, 
dann setzt man es erst nicht ein - das klingt sehrrrrr professionell! 
SCNR

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann,
> dann setzt man es erst nicht ein - das klingt sehrrrrr professionell!
> SCNR

Tipp:
Wenn erkannt wird, dass eine Aussage falsch ist, dann bedeutet das noch 
lange nicht, dass das genaue Gegenteil davon automatisch richtig ist.

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Axel Zucker schrieb:
> Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann,
> dann setzt man es erst nicht ein

Schon wieder eine Aussage, die so niemand getroffen hat.

Wenn eine Lib mit Support angeboten wird, dann sollte man diese 
bevorzugen. Erst wenn etwas dagegen spricht, schaut man sich nach 
anderen Lösungen um oder entwickelt sie selber.
Sei doch mal ein bischen flexibel. Das gehört zu einem guten Entwickler 
einfach dazu.

Es gibt für den Entwickler kein RundUmSorglosPaket. Daher muß er ständig 
abwägen welche Komponente kann er kaufen und welche muß er selber 
entwickeln.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Es gibt für den Entwickler kein RundUmSorglosPaket. Daher muß er ständig
> abwägen welche Komponente kann er kaufen und welche muß er selber
> entwickeln.

Bei dem Erwerb eines RundUmSorglosPakets geht es aber häufig gar nicht 
um eine technisch funktionsfähige Lösung, sondern um die Möglichkeit, 
bei beliebigen Problemen auf einen Dritten zeigen zu können. Wenn man 
dann in solchen Fällen eine juristische Klärung angestoßen hat, hat man 
wieder Zeit gewonnen, um seine eigenen Leichen im Keller wegzuräumen. Ob 
dabei irgendwann ein funktionsfähiges Produkt zu akzeptablen 
Entwicklungskosten entsteht, ist völlig egal. So ist die Denkweise in 
vielen Großunternehmen.

von Axel Zucker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Axel Zucker schrieb:
>> Also falls man es nicht mit Support als RundUmSorglosPaket kaufen kann,
>> dann setzt man es erst nicht ein
>
> Schon wieder eine Aussage, die so niemand getroffen hat.

Keine Aussage, sondern eine these. Oder eine persönliche Zusammenfassung 
was an wahren Gehalt der wohlgefeilten Wortblasen "Professioneller 
Entwicklung" durch Einkauf von 3rd party Produkte hier ankommt.

Andreas S.  schrieb:
"Bei dem Erwerb eines RundUmSorglosPakets geht es aber häufig gar nicht
um eine technisch funktionsfähige Lösung, sondern um die Möglichkeit,
bei beliebigen Problemen auf einen Dritten zeigen zu können."

Na beim "Zeigen auf Dritte" bleibt es meistens nicht, da wird auf 
(unendliche) Nachbesserung gepocht und der Supportvertrag ausgelutscht 
bis zum geht nicht mehr. Deshalb sind solche Verträge auf genau 
umrissene Szenarien beschränkt, typischerweise Installation und 
Demoapplikation, thats it; gern mit deckel auf ein paar Mannstunden oder 
Emailsupport mit nach oben offener Antwortzeit. Alles darüber hinaus 
zählt zu Engineering Dienstleistungen, die extra und auf Stundenbasis 
buchbar sind.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.