Zuverlässigkeit Raspi o.ä.

[Manuel Reimer]

On 1/24/19 9:38 AM, Stefan wrote:

Da hat der Kollege nicht ganz unrecht, aber seitdem ich vor einigen
Jahren privat ein wenig mit dem Raspberry gespeilt habe und dabei einige
SD-Karten geschrottet habe, bin ich da aber etwas skeptisch.

Ich habe mittlerweile 2 Raspis 24/7 am Laufen. Einer davon schon 3 Jahre
im Dauerbetrieb.

Das Zauberwort heißt "Readonly". Für den Linux-Laien vielleicht etwas
schwer umzusetzen, aber man kann den Raspi so konfigurieren, dass
Logging nur ins RAM läuft. Und die Daemons, die sich garnicht ausreden
lassen nach /var zu schreiben, habe ich auf eine RAM-Disk verbogen.

Soll heißen, dass kein Programm unter keinen Umständen irgendwas auf die
SD-Karte bekommt. Mit dem zusätzlichen Vorteil, dass das Teil nach einem
Stromausfall immer im gleichen definierten "Werkszustand" wieder kommt.

Gruß

Manuel

 

[Edzard Egberts]

olaf wrote:

Mal ein Beispiel aus der Praxis: Vor vielen Jahren hab ich mal ein
Messgeraet entwickelt das einen Rechner auf Win98 Basis fuer
Steuerung und Visualisierung der Daten hatte. Bei nur einem Kunden
blieben mehrere der Geraete immer um drei Uhr morgens stehen.

Win98 - die solide Basis fĂźr anhaltenden Microsoft-Hass:

Bei allen unseren Kunden stürzte meine Software unregelmäßig ab und die
Automaten blieben stehen. Damit bin ich monatelang gequält worden, bis
wir auf NT4 umgestiegen sind, wo meine Software plĂśtzlich anstandslos
durchlief: Win98 hatte einen Fehler in der Speicherverwaltung, der bei
der Reservierung vieler kleiner Objekte zuschlug - dem Logging der Maschine.

20 Jahre später habe ich den Eindruck, dass es sich Microsoft immer noch
richtig leicht macht, "Fragen Sie ihren PC-Hersteller oder
Administrator". Warum fĂźr eigene Fehler geradestehen, wenn man das doch
auf Dritte abwälzen kann, die auf den Monopolisten angewiesen sind...

 

[Thorsten BĂśttcher]

On 27.01.2019 18:52, Manuel Reimer wrote:

Ich habe mittlerweile 2 Raspis 24/7 am Laufen. Einer davon schon 3 Jahre
im Dauerbetrieb.

Das Zauberwort heißt "Readonly". Für den Linux-Laien vielleicht etwas
schwer umzusetzen, aber man kann den Raspi so konfigurieren, dass
Logging nur ins RAM läuft. Und die Daemons, die sich garnicht ausreden
lassen nach /var zu schreiben, habe ich auf eine RAM-Disk verbogen.

Ich hab einen Bananapi zu Hause stehen, als Owncloud- und
Seafile-Server. Nebenbei misst er noch ein paar Temperaturen und logt
den Stromverbrauch mit.
Da wäre es kontraproduktiv, wenn er nichts schreiben dßrfte.

Soll heißen, dass kein Programm unter keinen Umständen irgendwas auf die
SD-Karte bekommt. Mit dem zusätzlichen Vorteil, dass das Teil nach einem
Stromausfall immer im gleichen definierten "Werkszustand" wieder kommt.

Ich kann mich an kein Projekt der letzten Jahre erinnern, wo nicht
mindestens ein EEprom verbaut war, um irgendwelche Konfigurationsdaten
zu speichern.
Keiner unserer Kunden mÜchte nach jedem Start das Gerät komplett neu
konfigurieren.

Es mag Fälle geben wo RO hilfreich ist, aber manchmal gehts halt nicht
ohne was zu speichern.

 

[Hergen Lehmann]

Am 28.01.19 um 10:01 schrieb Edzard Egberts:

20 Jahre später habe ich den Eindruck, dass es sich Microsoft immer noch
richtig leicht macht, "Fragen Sie ihren PC-Hersteller oder
Administrator". Warum fĂźr eigene Fehler geradestehen, wenn man das doch
auf Dritte abwälzen kann, die auf den Monopolisten angewiesen sind...

In die Position der Abhängigkeit haben sich diese Dritten aber aus
eigener Initiative begeben.

Gerade bei deinem Beispiel mit den Automaten (also Spezial-Hardware mit
individuell erstellter Software darauf) liegt der Einsatz eines
*ix-Derivats oder eines industriellen Echtzeitbetriebssystems mehr als
nahe. Absolut nichts, außer Gewohnheit, spricht dafür, dort ein als
serviceintensiv und resourcenhungrig bekanntes Desktop-Betriebssystem
eines phĂśsen Monopolisten einzusetzen. ^_-

Hergen

 

[Gerrit Heitsch]

On 1/28/19 10:42 AM, Thorsten BĂśttcher wrote:

On 27.01.2019 18:52, Manuel Reimer wrote:

Ich habe mittlerweile 2 Raspis 24/7 am Laufen. Einer davon schon 3 Jahre
im Dauerbetrieb.

Das Zauberwort heißt "Readonly". Für den Linux-Laien vielleicht etwas
schwer umzusetzen, aber man kann den Raspi so konfigurieren, dass
Logging nur ins RAM läuft. Und die Daemons, die sich garnicht ausreden
lassen nach /var zu schreiben, habe ich auf eine RAM-Disk verbogen.

Ich hab einen Bananapi zu Hause stehen, als Owncloud- und
Seafile-Server. Nebenbei misst er noch ein paar Temperaturen und logt
den Stromverbrauch mit.
Da wäre es kontraproduktiv, wenn er nichts schreiben dßrfte.

Soll heißen, dass kein Programm unter keinen Umständen irgendwas auf die
SD-Karte bekommt. Mit dem zusätzlichen Vorteil, dass das Teil nach einem
Stromausfall immer im gleichen definierten "Werkszustand" wieder kommt.

Ich kann mich an kein Projekt der letzten Jahre erinnern, wo nicht
mindestens ein EEprom verbaut war, um irgendwelche Konfigurationsdaten
zu speichern.
Keiner unserer Kunden mÜchte nach jedem Start das Gerät komplett neu
konfigurieren.

Dazu reicht es wenn man nach der erfolgten Konfiguration das fragliche
Filesystem kurz r/w mounted, die Config schreibt und danach wieder r/o
schaltet.

Es mag Fälle geben wo RO hilfreich ist, aber manchmal gehts halt nicht
ohne was zu speichern.

Das kann man ja auch einem USB-Stick erledigen. Wenn der platt ist ist
er schnell gewechselt.

Gerrit

 

[Ralph A. Schmid, dk5ras]

olaf <olaf@criseis.ruhr.de> wrote:

Bei Windows hat man das Problem, dass ich haufen unnützen Code
mitnehmen muss und bei Linux konnte ich das OS auf den relevanten
Code reduzieren.

Dazu muss aber jemand das sein der das auch kann.

Ist bei Windows genauso. Man muß es können, und man muß es machen -
dann kann man sich eine embedded-Version maßschneidern, die stabil
läuft und die man nie mehr anfassen muß.


-ras

--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Ralph A. Schmid, dk5ras]

Edzard Egberts <news@edzeg.net> wrote:

20 Jahre später habe ich den Eindruck, dass es sich Microsoft immer noch
richtig leicht macht, "Fragen Sie ihren PC-Hersteller oder
Administrator". Warum für eigene Fehler geradestehen, wenn man das doch
auf Dritte abwälzen kann, die auf den Monopolisten angewiesen sind..

Erlebe ich bei embedded so nicht, der Support war bisher immer
dramatisch gut.


-ras

--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[aioe usenet]

On 24/01/2019 16:23, Thorsten BĂśttcher wrote:

On 24.01.2019 09:38, Stefan wrote:

Aus meiner Sicht gibt es noch ein paar andere Argumente gegen den
Raspbi. zum einen liefere ich die bisherigen Baugruppen und habe da
sicherlich eine bessere Marge, als wenn ich Raspbies liefere. Außerdem

Klar, aber da hat der Kunde natĂźrlich das entgegengesetzte Interesse.

sehe ich das Problem, dass da der ein oder andere Endkunde auf die Idee
kommen kĂśnnte, da selber dran herumzufummeln, z.B. Ersatzteile selbst zu
beschaffen oder die Daten von der SD-Karte zu manipulieren.

Durchaus mĂśglich.
Wenn der im Netzt ist, braucht er natürlich regelmäßige
Sicherheitsupdates. Das muss auch gepflegt werden.
Man sollte auch noch den rechtlichen Aspekt beachten, wenn man Code
benutzt der unter der GPL lizenziert ist. Dann steht die Software auch
unter der GPL.

Das stimmt so nicht. Wenn GPL software modifiziert wird ist der
Modifizierer verpflichtet diese Modifikationen oeffentlich zugaenglich
zu machen.

Die selbst entwickelte Software ist davon nicht betroffen, siehe Android.

Die STM32 Baugruppen kann der Endkunde und auch die Zwischenhändler nur
als Ersatzteil bei meinem Kunden kaufen.

Kunden von uns setzten den Raspi als Compute-Modul ein, auf selbst
entwickelter Hardware.

Je nachdem wie viel Peripherie man noch hat, ist das eine Überlegung wert.

 

[olaf]

Hergen Lehmann <hlehmann.expires.5-11@snafu.de> wrote:

individuell erstellter Software darauf) liegt der Einsatz eines
*ix-Derivats oder eines industriellen Echtzeitbetriebssystems mehr als
nahe. Absolut nichts, außer Gewohnheit, spricht dafür, dort ein als
serviceintensiv und resourcenhungrig bekanntes Desktop-Betriebssystem
eines phösen Monopolisten einzusetzen. ^_-

Doch. Du wirst keine Mitarbeiter finden die damit umgehen
koennen. Weder auf Kundenseite noch fuer deinen eigenen Service.


Olaf

 

[Gerrit Heitsch]

On 1/24/19 10:23 AM, Thorsten BĂśttcher wrote:

Kunden von uns setzten den Raspi als Compute-Modul ein, auf selbst
entwickelter Hardware.

Je nachdem wie viel Peripherie man noch hat, ist das eine Überlegung wert.

Seit heute gibt es den 3+ als CM.

https://www.raspberrypi.org/products/compute-module-3-plus-32gb/

Hat 32GB eMMc Flash.

Gerrit

 

[Thorsten BĂśttcher]

On 28.01.2019 15:54, aioe usenet wrote:

Wenn der im Netzt ist, braucht er natürlich regelmäßige
Sicherheitsupdates. Das muss auch gepflegt werden.
Man sollte auch noch den rechtlichen Aspekt beachten, wenn man Code
benutzt der unter der GPL lizenziert ist. Dann steht die Software auch
unter der GPL.

Das stimmt so nicht. Wenn GPL software modifiziert wird ist der
Modifizierer verpflichtet diese Modifikationen oeffentlich zugaenglich
zu machen.

Es geht nicht darum GPL-Software zu modifizieren, sondern sie in dem
eigenen Projekt einzusetzen.
Damit fällt die eigene Software auch unter die GPL.

> Die selbst entwickelte Software ist davon nicht betroffen, siehe Android.

Wenn man es schafft komplett auf den Einsatz von Software unter GPL zu
verzichten.
Das geht natĂźrlich, macht die Sache aber nicht einfacher.

 

[Edzard Egberts]

Ralph A. Schmid, dk5ras schrieb:

Edzard Egberts <news@edzeg.net> wrote:

20 Jahre später habe ich den Eindruck, dass es sich Microsoft immer noch
richtig leicht macht, "Fragen Sie ihren PC-Hersteller oder
Administrator". Warum fĂźr eigene Fehler geradestehen, wenn man das doch
auf Dritte abwälzen kann, die auf den Monopolisten angewiesen sind..

Erlebe ich bei embedded so nicht, der Support war bisher immer
dramatisch gut.

DarĂźber haben wir uns schon einmal unterhalten und ich glaube Dir das
auch. Embedded ungleich Konsumer-Windows, geht klar. Die zentralen
Fragen wären fßr mich aber, wie teuer das denn ungefähr fßr eine Firma
ist und ob auch Privatkunden die MĂśglichkeit haben, auf diesen Service
zuzugreifen?

 

[Edzard Egberts]

Hergen Lehmann schrieb:

Am 28.01.19 um 10:01 schrieb Edzard Egberts:

20 Jahre später habe ich den Eindruck, dass es sich Microsoft immer
noch richtig leicht macht, "Fragen Sie ihren PC-Hersteller oder
Administrator". Warum fĂźr eigene Fehler geradestehen, wenn man das
doch auf Dritte abwälzen kann, die auf den Monopolisten angewiesen
sind...

In die Position der Abhängigkeit haben sich diese Dritten aber aus
eigener Initiative begeben.

Gerade bei deinem Beispiel mit den Automaten (also Spezial-Hardware mit
individuell erstellter Software darauf) liegt der Einsatz eines
*ix-Derivats oder eines industriellen Echtzeitbetriebssystems mehr als
nahe.

Das war 1998 und weil es nach dem Studium wegen der Wiedervereinigung
keine Ingenieursstellen mehr gab, hatten sich drei Akademiker
zusammengerottet und selbstständig gemacht (ich habe ja nicht studiert,
um Plastikflaschen vom Fließbank in einen Karton zu packen.
Schaufellader fahren war aber okay, Schiffe be- und entladen auch ;o).

Ich war fßr die Technik zuständig und habe das Betriebssystem genommen,
das die Kunden haben wollten (damals noch Win95). Das war alles recht
neu und ich hatte fĂźr dieses Projekt das gerade erschienene C++ statt
des gewohnten Turbo-Pascal genommen Von Unix hatte ich mal gehĂśrt,
irgendetwas mit Großrechnern. War schwer genug, den Kunden dann Win-NT
anzudrehen.

Der zentrale Punkt ist aber, dass ich als armes WĂźrstchen fĂźr Fehler
gerade stehen musste, die ein Milliardenkonzern nicht nur verbockt hat,
sondern an denen er auch noch mit Support und Updates verdiente und fĂźr
die er als Ansprechpartner sowieso nicht zur VerfĂźgung stand. Also der
pure Neid - so gut wollte ich es auch haben, statt dessen war ich an
jedem Fehler Schuld, weil ich ja derjenige war, der die Maschine gebaut
hat. ;o(

Absolut nichts, außer Gewohnheit, spricht dafür, dort ein als
serviceintensiv und resourcenhungrig bekanntes Desktop-Betriebssystem
eines phĂśsen Monopolisten einzusetzen. ^_-

Bist Du Dir da immer noch sicher? ;o)

Zur Zeit hat dieser arrogante und schon oft kriminelle Konzern die
Masche, den gewĂśhnlichen Abschaum als Betatester zu benutzen und
fröhlich experimentelle Änderungen 'rauszuhauen. Win10-Home kann die
Updates nicht kontrollieren, Win10-Pro und Firmenkunden kĂśnnen die
verzĂśgern und Detail einstellen. Wen interessiert da schon, wenn
irgendwelche User ihre Daten verlieren, oder Hardware zwischendurch mal
gebrickt wird? Fragen Sie ihren PC-Händler oder Systemadministrator, uns
geht alles am Arsch vorbei, Microsoft as a Service!

 

[Hergen Lehmann]

Am 28.01.19 um 15:49 schrieb olaf:

individuell erstellter Software darauf) liegt der Einsatz eines
*ix-Derivats oder eines industriellen Echtzeitbetriebssystems mehr als
nahe. Absolut nichts, außer Gewohnheit, spricht dafür, dort ein als
serviceintensiv und resourcenhungrig bekanntes Desktop-Betriebssystem
eines phĂśsen Monopolisten einzusetzen. ^_-

Doch. Du wirst keine Mitarbeiter finden die damit umgehen
koennen. Weder auf Kundenseite noch fuer deinen eigenen Service.

Komisch. Netzwerk-Infrastruktur (Router/etc) läuft zu 100% unter
speziellen Echtzeitsystemen oder Linux/BSD-Derivaten. Ähnliches gilt für
Smartphones, IoT, elektronisch gesteuerte Haushaltsgeräte,
Fahrzeugtechnik, Luft-/Raumfahrt und viele andere Embedded-Anwendungen.
Auch bei (Cloud-)Servern liegt Linux deutlich vorne, hat selbst im
Microsofts eigener Azure-Cloud kĂźrzlich die 50%-Marke durchbrochen.

FĂźr all das bekommt man scheinbar problemlos sowohl Servicetechniker als
auch Programmierer. Und der Kunde bekommt das Betriebssystem eh nie zu
Gesicht.

Was ist in der Automatenbranche so speziell, das dort stur die großen
Windows-Scheuklappen aufgesetzt werden mĂźssen, obwohl der Monopolist
doch sooo furchtbar bĂśse ist?

Hergen

 

[Michael Schwingen]

On 2019-01-28, Thorsten BĂśttcher <thorsten_nospam@gmx.net> wrote:

Das stimmt so nicht. Wenn GPL software modifiziert wird ist der
Modifizierer verpflichtet diese Modifikationen oeffentlich zugaenglich
zu machen.

Nein. Er muss sie dem Kunden, dem er das binary verkauft hat, auf Anfrage
zugänglich machen. VerÜffentlichen ist nicht erforderlich.

Der Kunde darf die Sachen natĂźrlich weitergeben/verĂśffentlichen, aber das
muss er erstmal wollen ...

Es geht nicht darum GPL-Software zu modifizieren, sondern sie in dem
eigenen Projekt einzusetzen.
Damit fällt die eigene Software auch unter die GPL.

Nur, wenn Deine Software direkt von dem GPL-Teil abgeleitet ist und zusammen
ein Programm ergibt.

Du kannst problemlos z.B. einen Raspi nehmen, samba, apache etc.
'draufpacken und das mit einem (getrennt gelinkten) closed-source-Programm
von Dir kombinieren und verkaufen - und musst niemandem die Sourcen Deines
Programmes geben.

Wenn man es schafft komplett auf den Einsatz von Software unter GPL zu
verzichten.

Jein. Du musst auf *libraries* unter GPL verzichten, die zu Deinem Programm
dazugelinkt werden - das ist normalerweise kein Problem. Sonstige
Systemkomponenten, die als getrennte user-space-Prozesse laufen, kĂśnnen
problemlos GPL-Komponenten sein, ohne Einfluss auf die Lizenz Deines
Programmes.

cu
Michael

 

[Thorsten BĂśttcher]

On 28.01.2019 23:01, Michael Schwingen wrote:

On 2019-01-28, Thorsten BĂśttcher <thorsten_nospam@gmx.net> wrote:

Das stimmt so nicht. Wenn GPL software modifiziert wird ist der
Modifizierer verpflichtet diese Modifikationen oeffentlich zugaenglich
zu machen.

Nein. Er muss sie dem Kunden, dem er das binary verkauft hat, auf Anfrage
zugänglich machen. VerÜffentlichen ist nicht erforderlich.

Der Kunde darf die Sachen natĂźrlich weitergeben/verĂśffentlichen, aber das
muss er erstmal wollen ...

Es geht nicht darum GPL-Software zu modifizieren, sondern sie in dem
eigenen Projekt einzusetzen.
Damit fällt die eigene Software auch unter die GPL.

Nur, wenn Deine Software direkt von dem GPL-Teil abgeleitet ist und zusammen
ein Programm ergibt.

So wars gemeint. Man bindet Libraries ein, oder Ăźbernimmt direkt Teile
aus dem Source Code.

Jein. Du musst auf *libraries* unter GPL verzichten, die zu Deinem Programm
dazugelinkt werden - das ist normalerweise kein Problem. Sonstige
Systemkomponenten, die als getrennte user-space-Prozesse laufen, kĂśnnen
problemlos GPL-Komponenten sein, ohne Einfluss auf die Lizenz Deines
Programmes.

Das ist teilweise garnicht so einfach, wenn man nicht alles neu
schreiben mĂśchte.
Wenn man z.B. WiringPi einsetzt um einen Port zu schalten, hat man schon
GPL dabei.
Und so ist das bei vielen anderen Libraries auch.
NatĂźrlich kann man alles nochmal programmieren, aber dann kann ich auch
gleich beim STM32 bleiben.
Ich hab teilweise relativ lange gesucht, um LĂśsungen zu finden, die
nicht unter der GPL stehen.

 

[Ralph A. Schmid, dk5ras]

Edzard Egberts <news@edzeg.net> wrote:

Die zentralen
Fragen wären für mich aber, wie teuer das denn ungefähr für eine Firma
ist und ob auch Privatkunden die Möglichkeit haben, auf diesen Service
zuzugreifen?

Für Privatkunden wohl nicht zugänglich, und unsere Kosten, naja, halt
die paar EUR pro Lizenz-Bapper, den wir in die Geräte kleben, und ich
glaube, damals noch einmalig ein eher moderater Preis für die
Entwicklungsumgebung. Ansonsten keine weiteren Serviceverträge.


-ras

--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Andreas Weber]

Am 28.01.19 um 16:37 schrieb Thorsten BĂśttcher:

Es geht nicht darum GPL-Software zu modifizieren, sondern sie in dem
eigenen Projekt einzusetzen.
Damit fällt die eigene Software auch unter die GPL.

VĂśllig richtig. Wobei auch das dazu linken einer Bibliothek als von ihr
abgeleitetes Werk zählt. Daher sind viele Bibliotheken (z.B. die libc)
unter der LGPL, welche das dynamische linken erlauben (statisch verbieten).

Oft hat man aber ganz schnell mal viele projektspezifischen Lizenzen mit
dabei: FTL, fontconfig, MIT, MPL, PCRE2, bzip2, cairo, expat, libpng,
zlib uvm...

Wenn man es schafft komplett auf den Einsatz von Software unter GPL zu
verzichten. Das geht natĂźrlich, macht die Sache aber nicht einfacher.

Ja, das stimmt natĂźrlich. Wobei genau das ja im Sinne von RMS und
denjenigen, die GPL verwenden ist: Du profitierst von freiem Code, dann
mach deinen Code gefälligst auch frei!

-- Andy

 

[Michael Schwingen]

On 2019-01-29, Thorsten BĂśttcher <thorsten_nospam@gmx.net> wrote:

Nur, wenn Deine Software direkt von dem GPL-Teil abgeleitet ist und zusammen
ein Programm ergibt.

So wars gemeint. Man bindet Libraries ein, oder Ăźbernimmt direkt Teile
aus dem Source Code.

Jein. Du musst auf *libraries* unter GPL verzichten, die zu Deinem Programm
dazugelinkt werden - das ist normalerweise kein Problem. Sonstige
Systemkomponenten, die als getrennte user-space-Prozesse laufen, kĂśnnen
problemlos GPL-Komponenten sein, ohne Einfluss auf die Lizenz Deines
Programmes.

Das ist teilweise garnicht so einfach, wenn man nicht alles neu
schreiben mĂśchte.
Wenn man z.B. WiringPi einsetzt um einen Port zu schalten, hat man schon
GPL dabei.
Und so ist das bei vielen anderen Libraries auch.

Die muss man ja nicht benutzen. Ohne das Linux unten 'drunter mĂźsste man
*alles* selber schreiben.

Linux stellt reichlich Infrastruktur zur VerfĂźgung (Netzwerkstack,
Multitasking, ...), ohne daß die eigene Software GPL-"infiziert" wird.

Man kann auch reichlich fertige Komponenten benutzen, ohne die zum eigenen
Code dazuzulinken - z.B. FTP/WWW/Samba-Server, deren Aquivalent
programmierst Du auf dem STM32 nicht "mal eben" selber.

NatĂźrlich kann man alles nochmal programmieren, aber dann kann ich auch
gleich beim STM32 bleiben.
Ich hab teilweise relativ lange gesucht, um LĂśsungen zu finden, die
nicht unter der GPL stehen.

Man bekommt halt nicht alles geschenkt - da muss man halt den richtigen
Mittelweg finden. Controller wie der STM32 sind nett fĂźr kleinere
Anwendungen, fĂźr die ein komplettes Linux Overkill ist, oder fĂźr
Echtzeitanforderungen.

Sobald komplexere Protokolle wie SMB oder SIP gefordert sind, fĂźr die es
fertige Dienste im Userspace gibt, verschiebt sich das.

cu
Michael

 

[Thorsten BĂśttcher]

On 01.02.2019 22:59, Michael Schwingen wrote:

On 2019-01-29, Thorsten BĂśttcher <thorsten_nospam@gmx.net> wrote:

Nur, wenn Deine Software direkt von dem GPL-Teil abgeleitet ist und zusammen
ein Programm ergibt.

So wars gemeint. Man bindet Libraries ein, oder Ăźbernimmt direkt Teile
aus dem Source Code.

Jein. Du musst auf *libraries* unter GPL verzichten, die zu Deinem Programm
dazugelinkt werden - das ist normalerweise kein Problem. Sonstige
Systemkomponenten, die als getrennte user-space-Prozesse laufen, kĂśnnen
problemlos GPL-Komponenten sein, ohne Einfluss auf die Lizenz Deines
Programmes.

Das ist teilweise garnicht so einfach, wenn man nicht alles neu
schreiben mĂśchte.
Wenn man z.B. WiringPi einsetzt um einen Port zu schalten, hat man schon
GPL dabei.
Und so ist das bei vielen anderen Libraries auch.

Die muss man ja nicht benutzen. Ohne das Linux unten 'drunter mĂźsste man
*alles* selber schreiben.

Ich hab je nicht geschrieben dass man die nehmen *muss*. Man sollte sich
nur darĂźber im klaren sein, dass es u.u. schon reicht einen Portpin zu
schalten oder einen I2C-Sensor abzufragen, und schon hat man GPL-Code in
seinem Projekt.

Wenn man hardwarenah programmiert, geht das sehr schnell.
Nutzt man den Raspi eher um 'nur' Anwendungen laufen zu lassen, die nur
die Standardschnittstellen nutzt, hat man es leichter.