mikrocontroller.net

Forum: Compiler & IDEs SDCC 4.0.0 release candidate 1


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 Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
7 lesenswert
nicht lesenswert
Demnächst wird SDCC 4.0.0 erscheinen. Es gibt nun einen Release
Candidate 1, am üblichen Ort unter 
https://sourceforge.net/projects/sdcc/files/.
Dies ist die letzte
Gelegenheit, noch Bugs in der aktuellen Version zu finden, bevor 4.0.0
erscheint. Besonders schwerwiegende oder einfach zu behebende Bugs
könnten dann noch rechtzeitig vor 4.0.0 behoben werden.

In SDCC 4.0.0 wurden gegenüber 3.9.0 viele Bugs behoben und einige neue
Features implementiert. Das ChangeLog findet sich unter
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.9.0-pre1/sdcc/ChangeLog

Die bedeutendsten neuen Features sind:

* The pdk15 backend now passes the regression tests (both with and 
without --stack-auto), and is thus considered stable.
* New in-development pdk13 backend for Padauk µC with 13-bit wide 
program memory.
* C2X memccpy(), strdup(), strndup().
* Better tail call optimization.
* Many fixes in the pic14 backend.
* C2X u8 character constants.
* C2X bool, static_assert, alignof, alignas.
* C2X attributes on statements.
* C2X attribute declarations.
* Support for extended ASCII characters in sdas, sdld.
* Compiler support for UCNs and non-ASCII utf8 in identifiers.

Philipp Klaus Krause
SDCC 4.0.0 Release Manager

: Bearbeitet durch User
von Abyssaler Resonanzspürer (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Hoffentlich gibt es zum 4.0.0 auch eine einer Version 4.0.0
angemessene Installationsanleitung.

- Welche Environmentvariablen müssen gesetzt werden.
- Was kommt Wohin
...

Das war ja in der Vergangenheit eher immer ein Gerätsel.
Und Rätseln tue ich mir nicht an. Da warten dann die kommerziellen
Versionen die O.O.B. funktionieren.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
2 lesenswert
nicht lesenswert
Abyssaler Resonanzspürer schrieb:
> Hoffentlich gibt es zum 4.0.0 auch eine einer Version 4.0.0
> angemessene Installationsanleitung.
>
> - Welche Environmentvariablen müssen gesetzt werden.
> - Was kommt Wohin
> ...
>
> Das war ja in der Vergangenheit eher immer ein Gerätsel.
> Und Rätseln tue ich mir nicht an. Da warten dann die kommerziellen
> Versionen die O.O.B. funktionieren.

Diesbezüglich sind mir keine Änderungen seit 3.9.0 bekannt.

Aber abgesehen von Windows sollte das unproblematisch sein ("make 
install" installiert, soweit nichts anderes angegeben wird, nach 
/usr/local/bin, wie es eben üblich ist).
Soweit ich weiß, nutzen die meisten SDCC-Entwickler hauptsächlich 
GNU/Linux; entsprechend werden Bugs und Probleme dort schneller bemerlt. 
es wäre sicher gut, jemand zu haben, der sich darum kümmert, dass SDCC 
auf Windows gut läuft und es keine Windowsspezifischen 
Dokumentationslücken gibt.

Wer Patches zur Verbesserung (z.B. der Dokumentation) hat: 
https://sourceforge.net/p/sdcc/patches/

Philipp

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert

von W.S. (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Aber abgesehen von Windows sollte das unproblematisch sein ("make
> install" installiert...

"sdcc-4.0.0-x64-setup.exe"

Sowas kann ich überhaupt nicht leiden.

Warum geht das offensichtlich nicht, so ein Programmpaket als eine 
simple Zip-Datei auszuliefern, die man in irgend ein Verzeichnis seiner 
eigenen Wahl entpackt und dort schlicht und einfach benutzt?

Braucht SDCC es denn, in den Eingeweiden des OS herumzuwühlen, womöglich 
sogar noch nach Admi-Rechten zu fragen, um sich installieren und 
benutzen zu lassen?

W.S.

von ggg (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Du kannst die exe mit einem Packer öfnnen und damit so vorgehen, wie du 
es für richtig hältst.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Philipp Klaus K. schrieb:
>> Aber abgesehen von Windows sollte das unproblematisch sein ("make
>> install" installiert...
>
> "sdcc-4.0.0-x64-setup.exe"
>
> Sowas kann ich überhaupt nicht leiden.
>
> Warum geht das offensichtlich nicht, so ein Programmpaket als eine
> simple Zip-Datei auszuliefern, die man in irgend ein Verzeichnis seiner
> eigenen Wahl entpackt und dort schlicht und einfach benutzt?

Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen 
einen Installer.

Bei den täglichen Snapshots gibt es auch .zip:

Das dem Stand des 4.0.0-Release entsprechende .zip für 64-Bit Windows 
ist dieses:

http://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32/sdcc-snapshot-x86_64-w64-mingw32-20200128-11528.zip/download

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
5 lesenswert
nicht lesenswert
Falls jemand eine kurze Einführung zu SDCC, und den Rest der freien 
Toolchain für Padauk-µC wünscht, und den Vortrag heute auf der FOSDEM 
verpasst hat: Es gibt eine Aufzeichnung:

https://fosdem.org/2020/schedule/event/paduak_toolchain/

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Sowas kann ich überhaupt nicht leiden.

Das interessiert jetzt wen?
Compiliers dir eben selber wenns dir nicht passt:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Das interessiert jetzt wen?

Er hat ja nicht unrecht.
Bei manchen Installern aus "indischer" Softwareproduktion wird
fuer jede versch.ssene Datei ein Registryeintrag erzeugt, damit
der Uninstaller aber auch nichts uebersieht.
Die Eintraege werden bei einer Deinstallation natuerlich nicht
entfernt.
Ein so installierter GCC erzeugt so voellig unnoetigen Overhead.
Macht z.B. die gewesene Firma Raisonance, heute Keolabs so.

Das muss einem nicht gefallen. Zumal andere Softwareprojekte
es durchaus schaffen, parallel ein Zip-Archiv anzubieten.

Wenn durch den Installer dann wenigstens die Environmentvariablen
gesetzt wuerden...

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Larry schrieb:
> Das muss einem nicht gefallen. Zumal andere Softwareprojekte
> es durchaus schaffen, parallel ein Zip-Archiv anzubieten.

Die ZIP-Datei existiert und wurde verlinkt. Zufrieden?

von Larry (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Die ZIP-Datei existiert und wurde verlinkt. Zufrieden?

Ja.
Ausserdem war ich nicht der erste der geklagt hat.
Den muesstest du fragen.

Ich habe den Installer auf einer Virtualbox-WXP-Instanz
laufen lassen und mir selber ein (Nano-)Zip erzeugt.
Allerdings von der 32 bittigen Version.
Die wollte ich in den naechsten Tagen mal testen.

Aber trotzdem danke der Nachfrage.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
1 lesenswert
nicht lesenswert
Larry schrieb:
> Das muss einem nicht gefallen. Zumal andere Softwareprojekte
> es durchaus schaffen, parallel ein Zip-Archiv anzubieten.

Der Tonfall machts eben und der Tonfall von W.S. ist eben mal wieder ... 
daneben.
Man kann ja Fragen warums das nicht gibt, aber muss man direkt 
rummotzen?

@Philipp Klaus K:
Sachma wie würdest du den Aufwand Einschätzen dem SDCC ein MIPS1 Backend 
zu verpassen?
Bzw ist der SDCC noch klein genug um auf einem RTOS wie FreeRTOS zu 
laufen?
Irgendwie habe ich den größenwahnsinnigen Gedanken, dass auf dem MIPS 
TTL Rechner unbedingt ein C Compiler rauf muss!

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
2 lesenswert
nicht lesenswert
Mw E. schrieb:
>
> @Philipp Klaus K:
> Sachma wie würdest du den Aufwand Einschätzen dem SDCC ein MIPS1 Backend
> zu verpassen?

Vom Aufwand her wäre es machbar, aber GCC und LLVM dürften für eine 
solche RISC-Architektur besseren Code generieren.

> Bzw ist der SDCC noch klein genug um auf einem RTOS wie FreeRTOS zu
> laufen?
> Irgendwie habe ich den größenwahnsinnigen Gedanken, dass auf dem MIPS
> TTL Rechner unbedingt ein C Compiler rauf muss!

SDCC ist der (Small Device) C Compiler, nicht der Small (Device C 
Compiler). Wenn der Compiler selbst klein sein soll, wäre TinyCC 
naheliegend (der hat aber bisher auch kein MIPS-Backend).

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen
> einen Installer.

Nicht nur die sondern auch und ganz besonders die Linuxer.
Es gibt nichts schlimmeres als einen tar-Klumpen dessen Inhalt ich, am 
Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Le X. schrieb:
> Nicht nur die sondern auch und ganz besonders die Linuxer.
> Es gibt nichts schlimmeres als einen tar-Klumpen

Nein.

> dessen Inhalt ich, am
> Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss.

Nein.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
3 lesenswert
nicht lesenswert
Le X. schrieb:
> Philipp Klaus K. schrieb:
>> Gehen würde es schon, aber die bei weitem meisten Windowsnutzer wünschen
>> einen Installer.
>
> Nicht nur die sondern auch und ganz besonders die Linuxer.
> Es gibt nichts schlimmeres als einen tar-Klumpen dessen Inhalt ich, am
> Besten noch an der Paketverwaltung vorbei, irgendwo hinkopieren muss.

Meiner Erfahrung nach wollen GNU/Linux-Nutzer meist:

1) Ein Paket, dass sie über den Paketmanager ihrer Distribution 
installieren können. Am besten gleich von der Distribution 
bereitgestellt, wie bei SDCC 
(https://repology.org/project/sdcc/versions).

2) Einen Tarball und ein öffentlich zugängliches Quellcoderepository, 
die Quellcode enthalten, den sie auf üblichem Weg bauen, und dann per 
"make install" installieren können.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich einen Tarball mit Binaries bekommen kann (wie Eclipse zum 
Beispiel) den ich einfach irgendwo in meinem home entpacken und starten 
kann dann hab ich da kein Problem damit. Das selbe gilt für AppImage.

Abgehangenes Zeug oder Standard-Kram installier ich mir aus den 
Repositories der Distribution.

Aber sobald ich irgendwo bleeding edge brauche weil es zum Beispiel die 
betreffende Software vor 2 Jahren noch gar nicht gab oder wenn ich 
händeringend auf ein neues Feature warte das jetzt endlich implementiert 
wurde kann ich mit der abgehangenen Version aus den Repositories nichts 
anfangen. Dann bleibt nur noch ppa (Ubuntu), Tarball mit Binaries, 
AppImage oder Snap oder selber kompilieren.

Das gibt (mit Ausnahme von ppa, deshalb nehm ich da auch zunehmend 
Abstand von) auch keine Konflikte mit der Paketverwaltung, insofern ist 
die Formulierung "an der Paketverwaltung vorbei" nicht zutreffend 
solange man die Finger von den Ordnern lässt die der Paketverwaltung 
gehören(!) und stattdessen lokal installierte Software nur an Orten 
installiert die genau für sowas vorgesehen sind (~/.local, /usr/local, 
/opt) oder ein Tarball oder AppImage irgendwo ins eigene home, oder ein 
snap. Da ist dann genau nichts "an der Paketverwaltung vorbei" sondern 
das ist der normale vorgesehene Weg.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Dann bleibt nur noch ppa (Ubuntu), Tarball mit Binaries,
> AppImage oder Snap oder selber kompilieren.

Der übliche Weg ist "selber kompilieren".

Die von dir gewünschten Binaries landen dann standardmäßig in 
/usr/local/ - und ja, das ist "an der Paketverwaltung vorbei". Ob das 
Probleme auslöst oder nicht, kann die Paketverwaltung nicht wissen und 
deswegen macht man das üblicherweise nicht.

Binaries sind nicht portabel (d.h. SDCC müsste mindestens x86, x86_64, 
arm64 und armhf/armel ausliefern), zudem ist nicht garantiert, dass sie 
überhaupt funktionieren. Selbst glibc ist nicht binärkompatibel 
(deswegen kompiliert NVidia die Grafiktreiber gegen echt antike 
glibc-Versionen). Statisch linken gegen glibc ist übrigens "highly 
discouraged" (u.a. weil glibc selbst dlopen() benutzt).

Was du also willst ist, dass jemand seine C-Programme für dich gegen 
eine fremde oder veraltete libc kompiliert, nur damit du dir den Aufwand 
sparst. Ziemlich verlangend. Von den anderen Abhängigkeiten mal 
abgesehen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> /usr/local/ - und ja, das ist "an der Paketverwaltung vorbei

Nein, ist es nicht denn die Paketverwaltung hat nichts in /usr/local, 
deshalb muss man dort auch nicht an ihr "vorbei". Dieser Ort gehört ganz 
allein dem Eigentümer der lokalen Maschine zur freien Verfügung und 
nicht der Paketverwaltung. Im Gegenzug lässt man selbst die Finger von 
/usr denn das wiederum gehört allein dem Paketmanager und sonst 
niemandem. Und schon kommt sich niemand in die Quere.

> Was du also willst ist, dass jemand seine C-Programme für dich gegen
> eine fremde oder veraltete libc kompiliert

Die meisten schaffen es es zu vermeiden gegen irgendwelche Bleeding Edge 
Versionen zu linken oder irgendwas zu verwenden das es erst in 2 Jahren 
bei Otto Normalverbraucher geben wird, dann läuft das Zeug auch überall. 
Und wenn nicht dann würd ichs bei mir mit meiner 2 Jahre alten libc 
sowieso auch selber nicht gelinkt bekommen.

Und wenn ich alles immer selber kompilieren wollte würde ich Gentoo 
benutzen. Das hab ich mal ein Jahr lang gemacht, da war ich noch jung 
und genauso drauf wie Du, dann ist mir das irgendwann zu blöd geworden. 
Wenn ich mir heute was installiere will ichs meist am selben Tag noch 
benutzen und nicht erst in 6 Stunden.

Wenn der Softwareanbieter Binaries anbietet (in welcher Form auch immer) 
dann benutze ich die dankbar und gerne! Beispiel: arm-none-eabi-gcc 
(Tarball), avr-gcc (Tarball), vscode (Snap), Eclipse (Tarball), Pycharm 
(Tarball), Blender (Snap), Prusa Slicer (AppImage), FreeCAD¹ (AppImage), 
etc...

Nichts davon kommt dem Paketmanager in die Quere weil es nicht an diesem 
vorbei sondern völlig getrennt(!) davon installiert wurde. Seit ich 
aufgehört habe dem Paketmanager irgendwelche inoffizielle Quellen 
unterzujubeln in der irrigen Annahme das wäre der richtige Weg und 
stattdessen sowas strikt komplett separat(!) an separaten(!) Orten 
installiere lauft jedes 6-Monatige Ubuntu-Upgrade wie am Schnürchen und 
ohne Schluckauf durch.

__
¹) allein beim Gedanken daran sowas wie zum Beispiel FreeCAD mit seinen 
zwölfunddreißig Abhängigkeiten (oder sowas wie Eclipse oder dergleichen) 
selber kompilieren zu müssen bekomme ich Gänsehaut, allein beim Gedanken 
daran...

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
>> /usr/local/ - und ja, das ist "an der Paketverwaltung vorbei
>
> Nein, ist es nicht denn die Paketverwaltung hat nichts in /usr/local,
> deshalb muss man dort auch nicht an ihr "vorbei".

Du Witzkeks. "Unabhängig von der Paketverwaltung" ist dasselbe wie "an 
der Paketverwaltung vorbei". Beispiel: Ich installiere ein paar Binaries 
in /usr/local/bin, aber die Paketverwaltung installiert das gleiche 
Paket wegen bestimmter Abhängigkeiten in /usr/bin, dann bekomme ich voll 
lustige Probleme, weil beide (a) existieren und (b) gleiche Dateien 
benutzen. Wenn nicht in /etc, dann vielleicht im Homeverzeichnis. Super, 
sowas.

Bernd K. schrieb:
> Die meisten schaffen es es zu vermeiden gegen irgendwelche Bleeding Edge
> Versionen zu linken oder irgendwas zu verwenden das es erst in 2 Jahren
> bei Otto Normalverbraucher geben wird, dann läuft das Zeug auch überall.

Heißt: Du verlangst tatsächlich, dass die Binaries bevorzugt gegen ein 
RedHat 6.2 kompiliert werden. Ich staune.

Bernd K. schrieb:
> Und wenn ich alles immer selber kompilieren wollte würde ich Gentoo
> benutzen. Das hab ich mal ein Jahr lang gemacht, da war ich noch jung
> und genauso drauf wie Du, dann ist mir das irgendwann zu blöd geworden.

Tut mir Leid, aber im Gegensatz zu Dir ich sehe ich einen klitzekleinen 
Unterschied zwischen "ich muss alles selbst kompilieren" und "wenn ich 
Bleeding Edge will, dann baue ich die halt selber".

Und insbesondere SDCC zählt jetzt nicht gerade zu den Projekten, wo ich 
mit drölfundvierzig Webpaketen aus in Javascript, Python und PHP 
zusammengewürfelten Abhängigkeiten kämpfen muss.

Bernd K. schrieb:
> Beispiel: arm-none-eabi-gcc (Tarball), avr-gcc (Tarball), [...]

$ sudo apt install gcc-arm-none-eabi gcc-avr

funktioniert bei mir prächtig (die anderen Programme nutze oder kenne 
ich nicht).

Achso, du wolltest Bleeding Edge fahren.

Naja, ich entnehme deinem Rant einfach mal, dass du gerne Windows mit 
seinen Installern und der DLL-Hölle wiederhättest, aber der Ansatz, 
einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap, 
AppImage), deine vollumfängliche Zufriedenheit findet - und lasse das 
Thema ruhen.

Die Welt bewegt sich da ohnehin hin.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> aber der Ansatz,
> einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap,
> AppImage)

Das Prinzip hat sich auch beim Deployen von Webanwendungen und anderen 
Cloud-Diensten mit Pauken und Trompeten durchgesetzt (Docker) weils so 
viel endloses Nervenaufreiben komplett vermeidet.

Und zwar das Nervebaufreiben das man immer hat wenn man versucht fremden 
Code in seinem eigenen System zu integrieren ohne was kaputt zu machen 
oder tonnenweise dev-Pakete und libs von denen man noch nie was gehört 
hat zu installieren.

Wenn es gelingt Binaries zu machen die überall einfach so laufen ohne 
mit irgendwas in die Quere zu kommen oder irgendwas besonderes an meinem 
System zu verlangen dann soll mir das nur recht sein. Und wenn das 
erfordert daß der Softwareanbieter ein bisschen aufpasst gegen was er 
linkt und auch auf anderen Maschinen testet als nur seiner eigenen dann 
soll das gerne so sein.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> S. R. schrieb:
>> aber der Ansatz,
>> einfach pro Anwendung ein eigenes Betriebssystem zu installieren (Snap,
>> AppImage)
>
> Das Prinzip hat sich auch beim Deployen von Webanwendungen und anderen
> Cloud-Diensten mit Pauken und Trompeten durchgesetzt (Docker) weils so
> viel endloses Nervenaufreiben komplett vermeidet.

Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder 
Tester, der das Zeug einmalig schnell zusammenfrickeln will.

Dem Administrator, der diesen Mist dann über Jahre hinweg stabil und vor 
allem auf aktuellem Sicherheitspatchlevel halten muss, bereitet es 
schlaflose Nächte.

Da helfen nur Pakete vom Paketmanager der Distribution. Oder für das, 
was dort nicht vorhanden ist, ein eigenes Repository mit den Quellen und 
Bauanleitungen (z.B. .spec-Dateien) von allen Abhängigkeiten.

: Bearbeitet durch User
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder
> Tester, der das Zeug einmalig schnell zusammenfrickeln will.
>
> Dem Administrator, der diesen Mist dann über Jahre hinweg stabil

Nein, der Entwickler ist gleichzeitig der Administrator seines eigenen 
Images. Der klickt einmal mit der Maus und sein Image wird mit allen 
altuellen libs neu gebaut und verteilt.

Der Administrator des Hosts sorgt nur dafür daß seine Dockerfarm läuft, 
das ist sein Job und mehr nicht. Mit dem was in den Images innendrin ist 
hat der exakt nichts am Hut, da kann er auch nichts machen, da ist 
jemand anders zuständig und er hat demzufolge auch NULL Nervenaufreiben 
damit weil an der Stelle für ihn absolut nichts zu tun ist.

Jeder hat weniger Stress und Konfliktpunkte. Win-Win.

Dementsprechend muß ich mir wenn ich ein Snap installiere auch nicht die 
Nerven aufreiben um mein System irgendwie passend hinzubiegen denn das 
Snap bringt alles mit was es braucht.

Das Paketsystem ist gut für das Grundsystem, für die Infrastruktur in 
der nicht mehr viel Bewegung ist. Für alles was darüber hinausgeht, für 
alles schnellebige ist das vollkommener Wahnsinn und praktisch nicht 
mehr zu beherrschen, das hat man jetzt mittlerweile gelernt nach zig 
Jahren gescheiterten Versuchen das irgendwie mit dem Paketsystem 
hinzubekommen.

: Bearbeitet durch User
von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Gerd E. schrieb:
>> Nein, es vermeidet das endlose Nervenaufreiben nur dem Entwickler oder
>> Tester, der das Zeug einmalig schnell zusammenfrickeln will.
>>
>> Dem Administrator, der diesen Mist dann über Jahre hinweg stabil
>
> Nein, der Entwickler ist gleichzeitig der Administrator seines eigenen
> Images.

Wenn Entwicklung und Betrieb des Images in einer Firma laufen - 
meinetwegen, da kannst Du die Aufgabengebiete definieren wie Du willst.

Aber wenn die Entwicklung außer Haus bei einer anderen Firma ist kannst 
Du das in sehr vielen Fällen vergessen weil Du Dich auf die was das 
Thema Sicherheit angeht nicht verlassen kannst.

> Der klickt einmal mit der Maus und sein Image wird mit allen
> altuellen libs neu gebaut und verteilt.

Und woher weiß er daß er mit der Maus klicken muss? Also wie ordnet er 
die ganzen Security Advisories, die da jeden Tag rauskommen, der Liste 
seiner Abhängigkeiten (und deren Abhängigkeiten, rekursiv) zu?

> Der Administrator des Hosts sorgt nur dafür daß seine Dockerfarm läuft,
> das ist sein Job und mehr nicht. Mit dem was in den Images innendrin ist
> hat der exakt nichts am Hut, da kann er auch nichts machen, da ist
> jemand anders zuständig und er hat demzufolge auch NULL Nervenaufreiben
> damit weil an der Stelle für ihn absolut nichts zu tun ist.

Der Admin ist normalerweise auch dafür zuständig die Sicherheit des 
Gesamtsystems sicherzustellen. Da muss er einen Sicherheitspatch machen 
können, auch wenn der Entwickler grad an einem anderen Projekt dran ist 
oder sonstwas.

> Jeder hat weniger Stress und Konfliktpunkte. Win-Win.

Nur wenn man das Thema Sicherheit ausblendet vielleicht.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
>> Jeder hat weniger Stress und Konfliktpunkte. Win-Win.
>
> Nur wenn man das Thema Sicherheit ausblendet vielleicht.

Nein, ich sehe nicht wo das die Sicherheit nachteilig beeinflussen 
sollte. Im Gegenteil: Weil Updates stressfreier und mit weniger 
Nebenwirkungen verbunden sind können sie zügiger geschehen.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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