Wo siril richtig schlecht ist (-> für Freaks)

fuetti

fuetti

Aktives Mitglied
Ich habe heute versucht siril 1.4.1 auf OpenSuSE 15.5 zu kompilieren, um meine dort sauber installierte NVIDIA-Karte nutzen zu können.
Da diese inzwischen angelaufene Distro bei Siril 1.2 stehen geblieben ist, musste ich also selbst kompilieren, was ich schon oft erfolgreich machen konnte.
Z.B. das neueste stellarium war hier völlig schmerzlos, aber siril1.4 wurde ein absoluter Albtraum.

git clone FA / Siril · GitLab
cd siril
meson setup _build --buildtype release

und dann kamen Fehlermeldungen.
Nach Nachinstallation zahlreicher Bibliotheken bin ich fast an lcms2 gescheitert, weil meine Version veraltet war.
Also habe ich den Sourcecode heruntergeladen und in /opt installiert. Alles nochmals gut gegangen!
Doch dann scheiterte ich, da die glibc nicht aktuell genug war.

Nebenbemerkung: Die 15.5 ist wirklich nicht sehr alt, bis vor kurzem war die 15.6 die aktuellste Version, gerade ist 16.0 rausgekommen.

Jetzt ist es hier gescheitert und hat den Header nicht gefunden:
#include <filesystem>
^~~~~~~~~~~~
Also habe ich den Standard-C- und C++- Compiler auf Version 10 gesetzt und der Fehler verschwand.
Dann wollte er eine merkwürdige Biblio für ein exotisches Kameraformat: xisf. Das habe ich manuell (!) aus meson.build entfernt,
denn ich werde dieses Format nie verwenden. Warum erkennt das meson Skript das nicht, und bereitet das Kompilieren entsprechend vor?
Normalerweise sollten optionale Biblios automatisch durch if-Abfragen im meson-Script geprüft und entsprechend ausgeschlossen.
Der User sollte davon nichts merken - Pustekuchen!
Schließlich sollte man doch wählen könne welche optionalen Features man mitnehmen möchte, so ist das jedelfalls gedacht.

Dann machte opencv4 Probleme - ich hatte nur V3. Eigentlich sollte es auch ohne opencv funktionieren,
denn siril ist kein stellarium oder Game, in dem der Screen ultraschnell gerendert werden muss.
Ich hatte es also nicht installiert, V3 scheint nicht zu passen (warum?) und eigentlich sollte auch hier das Skript das erkennen
und automatisch das Makefile entsprechend einrichten.
Wie sollte das sein?

Im meson.build findet man:

some_target = executable('foo', sources, dependencies: opencv_dep)

Besser wäre demnach:

if opencv_dep.found()
some_target = executable('foo', sources, dependencies: opencv_dep)
else
some_target = executable('foo', sources)
endif

D.h. wenn opencv nicht installiert ist, fährt er automatisch ohne diese Lib weiter - easy-peasy!

So gab es eine harte Fehlermeldung und ich konnte nicht fortschreiten mit ninja -C _build -j4.
Diese Bibliothek war nicht nachzuinstallieren, ohne das ganze System zu beschädigen.
Also versuchte ich alles opencv4 aus dem meson-Skript zu entfernen, doch bestrafte mich meson mit Fehlermeldungen, es gab keinen Ausweg mehr.
Nach 4 Stunden musste ich aufgeben.

Ich klassifiziere daher dieses Installationsskript als mangelhaft und User-feindlich.
Das Durchgehen des Source-Codes habe ich mir erspart, ich hoffe, dass er wenigstens sauber modular aufgebaut ist.
Die Entwickler haben nicht auf Rückwärts-Kompatibilität geachtet, was eigentlich Industriestandard ist.
Ich erwarte ja keine Kompatibilität mit OpenSuSE 10.2 von vor 10 Jahren oder noch älter, aber die zweitneueste Distro sollte schon noch funktionieren.

Fazit: Das Meson-Script ist unausgereift, ja schlampig erstellt, denn es erlaubt nicht, die Kompilation sauber zu konfigurieren,
z.B. unnötige oder ungewünschte Komponenten abzuschalten, was eigentlich der Sinn von meson ist.

Thumbs down, liebe siril-Entwickler!
Claus
 
Zuletzt bearbeitet:
Hallo Claus,
wir (ich) sind zwar keine "Freaks".

Aber Siril ist als flatpack verfügbar und lässt sich ohne Kompilation installieren.

Hier die lektorisch aufbereitete Anleitung vom künstlichen Besserwisser.


## 1. Flatpak installieren

Auf Ubuntu, Linux Mint, Debian, ...

```bash
sudo apt update
sudo apt install flatpak
```

Auf Fedora:

```bash
sudo dnf install flatpak
```

Auf openSUSE:

```bash
sudo zypper install flatpak
```

Flathub registrieren

```bash
sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
```


## 2. Siril 1.4 als Flatpak installieren

```bash
flatpak install flathub org.siril.Siril
```


## 3. Siril Flatpack starten

```bash
flatpak run org.siril.Siril
```


Gruß
 
Hallo Claus,

Ich finde Deinen Rant hier komplett unangebracht.

Siril ist ein OpenSource Tool, das von einem sehr kleinen Team von Leuten in deren Freizeit kostenlos zur Verfügung gestellt wird.

Die meisten Anwender werden Siril nicht selbst kompilieren, sondern fertige Binaries, Distributionspakete, Flatpaks oder AppImages herunterladen. Das Kompilieren von Sourcecode hat als Verbreitungsweg daher nicht die höchste Priorität.
Trotzdem ist es machbar (ich mache das täglich auf Debian Stable, was auch nicht den Ruf einer hyperaktuellen Entwicklerplatform hat) und es ist auch gut dokumentiert. Offensichtlich hast Du Dir aber noch nicht einmal das README.md durchgelesen, in dem die nötigen Befehle dokumentiert sind.

Dort steht auch z.B.:
Using meson to build siril requires all optional dependencies to be available or explicitly disabled on the meson command line adding -Dexiv2=false for example.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Es ist also durchaus möglich, nicht benötigte Abhängigkeiten (wie libXISF) abzuschalten.
Hint: schau mal in die Datei meson.options.

Mache Dich außerdem damit vertraut, wozu bestimmte Abhängigkeiten benötigt werden, beispielsweise opencv für Image-Transformations - so etwas kann man einem Programm, welches Bilder aufeinander registriert und ausrichtet doch zugestehen?

Wenn Du die Situation tatsächlich verbessern möchtest, dann hilft es nicht, sich in einem deutschen Astronomieforum auszulassen.
Der richtige Weg wäre ein Merge-Request mit Deinen Verbesserungsvorschlägen.

Grüße,
Steffen
 
Das Problem mit unterschiedlichsten Libraries hat mich nach 15 Jahren intensiver Linux Nutzung vor einigen Jahren dermaßen abgenervt, dass ich Linux kaum noch nutze. Gerade die neusten Softwareversionen wollen oft die neusten Libraries und womöglich noch eine neue glibc. Dann kann man sein System gleich neu installieren...

Meine diversen Windowsrechner funktionieren hingegen seit vielen Jahren völlig problemlos, auch mit komplexen Installationen. So überzeugt ich frührer von Linux war, so muss ich heute sagen, dass die Unmengen an Linuxdistributionen nicht wirklich einen Fortschritt gebracht haben, sondern nur die Komplexität gesteigert und die Kompatibilität verringert haben.

Eine Ubuntu Installation, die ich frisch installiert hatte, aber etwa ein Jahr nicht genutzt hatte, brach beim normalen Update gleich mit Fehlermeldungen ab. Eine Neuinstallation war dann der pragmatische und schnellere Lösungsweg. Ich habe einfach keine Lust mehr, solche Fehler stundenlang zu analysieren und zu fixen. Und Ubuntu ist sicher keine wenig genutzte Distribution.

Es gibt immer noch spezielle Einsatzgebiete für die ich Linux besser finde, speziell bei gehärteten, sicherheitsrelevanten Systemen und embedded Systems, aber nicht mehr für den generellen Einsatz und schon gar nicht für den Einsatz als Astrorechner. Kstars/Ekos kommt mit N.I.N.A. einfach nicht mehr mit und die allgemeine Astrosoftwareauswahl ist unter Windows einfach besser.

Klar, es gibt auch Dinge, die mich an Windows nerven, wie die Installation von irgendwelchen Mist bei Systemupdates, oder die Ungewissheit, was da so an Microsoft an Informationen zurückfließt. Aber auch unter Linux hat man eigentlich nur theoretisch die Möglichkeit, den Quellcode auf Merkwürdigkeiten zu analysieren. Das ist schon aufgrund der schieren Masse an Quellcode unmöglich .

Aber jeder kann ja frei entscheiden, was er persönlich bevorzugt. Und das ist ja auch gut so.

Und Siril finde ich richtig gut!

Viele Grüße,

Günther
 
Zuletzt bearbeitet:
Claus,
Deine Anmerkung, dass die Source Distribution über meson buggy ist, ist sicher zutreffend.

Aber seit Linux Software hauptsächlich per paketmanager, ppa, flatpak, snap, Appimage und docker container ausgerollt wird, ist die Source Distribution einer Linux App zu einem old-school legacy feature geworden. Das nutzen eigentlich nur noch Entwickler. Meistens hat die Installation from Source noch nicht Mal eine Deinstallationsroutine ...

Das ist bei anderen Linux Apps auch nicht anders.

Die Zeit geht weiter, die Methoden ändern sich. Nicht immer zu besten.
 
Danke für eure Reaktionen.
Hier meine Antworten:

Thomas, das ist mir natürlich bekannt, sonst hätte ich nicht kompilieren müssen. Tumbleweed habe ich auch, ist jedoch nicht so stabil. Ich habe schon öfter neu installieren müssen. Außerdem wird es nicht von den NVIDIA-Treibern unterstützt. Dieser Computer ist für meine Arbeit, da will man ein stabiles Umfeld, welches 15.X und jetzt 16 bietet. Warum wollte ich siril 1.4 auf 15.5? Weil 15.X NVIDIA-Unterstützung hat, ganz einfach. Die angesprochenen Probleme sind jedoch genereller Natur, die seit Jahren bekannt sind, aber nicht gelöst werden, obwohl sie lösbar wären.

Flatpak ist eine virutelle Umgebung. D.h. die Libraries werden dort mitgeliefert. Die Systemlibraries werden nicht mehr unbedingt genutzt.
Flatpaks lassen die Dateigrößen anschwellen: Siril -> Installed Size~290.4 MiB, Download Size102.46 MiB
Die Konsequenz wäre, dass man alle Libraries aus den Distros entfernt -> Jedes Flatpak-Programm bringt seine Libraries mit -> Redundanz der Libraries -> Endlose Speicherverschwendung und Verschwendung von Prozessorleistung.
Besser wäre es, die Schnittstellen zwischen den Libs zu standardisieren, auch wenn man etwas Performance verliert.

Zitat aus: Schritt-für-Schritt-Anleitung zum Erstellen eines Flatpak-Pakets unter Linux
"Verpackungskomplexität: Die Erstellung eines gut gemachten Flatpak-Pakets, insbesondere für die Bereitstellung auf Flathub, kann viel aufwendiger sein, als es zunächst scheint, vor allem im Hinblick auf Abhängigkeiten und Metadaten."
D.h. die Komplxität ist mit Flatpaks nicht verringert, sondern erhöht und verschoben - > keine echte Problemlösung, verstößt gegen Unix-Regeln. Wenn man bei flatpak-Packaging schlampt, und das wird geschehen, ist es NOCH schwerer zu debuggen. Außerdem wird man von flatpak abhängig. Wenn die Anfangen Gebühren zu verlangen, ist das Chaos perfekt. Das Ganze erinnert an den Turm von Babel.

Das ist eine Pervertierung der Library-Idee, die ja eingeführt wurde, um Speicher zu SPAREN, und damit Programmierer das Rad nicht jedesmal neu erfinden müssen und die Lösung eines Problems nur einmal geschrieben werden muss und dann geteilt werden kann.

Außerdem: Wozu OpenSource, wenn man Kompilierung praktisch unmöglich macht, es sei denn man hat zufällig das richtige System und die richtige Release?

Die Philosophie von Unix war einmal: KISS
Oder detaillierter: Unix-Philosophie – Wikipedia (sehr lesenswert)

Flatpaks sind also ein Workaround und können keine definitive Lösung des Installtationschaos sein.

Zu WIndows: Das ist für mich keine Alternative, trotz aller Vorteile eines Systems aus einem Guss. Windows ist seit jeher intransparent, von einem dubiosen Konzern hergestellt und vertrieben, d.h. absolute Abhängigkeit von der Konzernführung und deren Eingebungen, Es war lange ziemlich instabil. Heute ist es voller Spyware, früher von Hackern illegal eingebaut, heute von Microsoft legal selbst eingebaut. Es ist wahnsinnig schwierig Windows abzuriegeln. Ich empfehle Windows ausschließlich in Virtuellen Maschinen oder auf netzgetrennten Maschinen laufen zu lassen. Windows geht bei mir nie, nie, nie ans Netz.

Ich verwende fast ausschließlich Linux seit vielen Jahren und bin damit grundsätzlich zufrieden, was jedoch nicht heißt, dass alles Gut ist.
Wie gesagt: stellarium konnte ich ohne große Probleme kompilieren, wie auch andere Software, warum nicht siril? Weil es unausgereift ist und den Anforderungen guten Softwaredesigns nicht genügt. Auch Freizeitprogrammierer können das, wie die unzähligen anderen Opensource Programme beweisen.

Grüße, Claus
 
Zuletzt bearbeitet:
Ja, die aktuellen Ausroll-Strategien von Linux Apps verstoßen gegen den Open Source Gedanken, erschweren den Code-Review und die Reproduzierbarkeit. Letztlich schaden sie wahrscheinlich auch die Sicherheit von Linux Software.

Aber seit jede Linux-Distro sein eigenes Paketmanagement mitbringt, hat noch nicht Mal Linux Torvalds selbst mehr Lust, eine Software für jede Linux Distribution separat durchzutesten und im Endeffekt für 6 Distros entwickeln zu müssen. Dadurch entstanden im Desktop Bereich Flatpak, Snap und Appimage und im Headless Bereich Docker.

Geh es pragmatisch an. Du suchst eine Entwicklungs- und Testumgebung für den Siril Deconvolution-PSF-Filter. Die ganze App ist zum größten Teil in Python geschrieben. Es gibt mit Sicherheit eine Möglichkeit, sich so etwas einzurichten. Frag am besten direkt bei den Siril Entwicklern nach, wie es am einfachsten geht. Sicherlich werden sie sich über einen (partiellen) Mitstreiter sehr freuen und Dein Vorhaben unterstützen.

Aber Widerstand Kritik an der Linux-Entwicklungsphilosophie in einem Astroforum ist zwecklos. Für mich zumindest.
 
Zuletzt bearbeitet:
Ja, diese Vielfalt ist kontraproduktiv und überlastet nicht nur die Freizeitprogrammierer.

Die OpenSuSE wird also seit 13 Monaten nicht mehr unterstützt. Das ist für mich noch eine sehr neue Release.
Muss man ständig an den Libs - das Herz jedes Systems - rumschrauben?
Nein, allein Sicherheitslücken finde ich akzeptabel, wie neulich die zlib.

Das Problem ist auch: Ich würde schon kleine Software Beiträge leisten (habe ich auch schon vor langer Zeit), aber ich habe weder Lust noch Zeit mich in immer neue Entwicklungstools, wie meson und ninja einzuarbeiten. Ich finde das lenkt ab und frisst kostbare Zeit. Ich bin noch auf dem Stand von Makefile und das war/ist schon ein sehr umfangreiches und ausgefuchstes System.

Ja, man virtualisiert gerade alles und jeden. Das ist der heilige Gral (Grab?) der IT. So gibt es appimage und jetzt flatpak, aber auch noch andere.
So wird Code auf Code gestapelt, und man verspricht Lösungen alter IT-Probleme - ach und natürlich mehr Sicherheit, das will ja jeder!
Nein, die Probleme kommen durch die Hintertür wieder rein. Wie oft in der Medizin werden Symptome behandelt und nicht die Ursachen beseitigt.
Mehr Komplexität schafft nämlich auch mehr Lücken und Fehler (Eines der Unix-Gruindsätze).

Ja, es gibt flags für meson, ein einziges ist als Beispiel im README dokumentiert.
D.h. ich muss meson.build (716 Zeilen) aufmachen und versuchen zu vestehen, was dort passiert: Dort aber sind aber duzende von -D Optionen über das ganze Skript verteilt:
# Call CMake with `-DBUILD_SHARED_LIBS=OFF` das ist ein cmake-Flag
siril_cpp_flag += '-DHAVE_LIBRTPROCESS' das ist ein c++-Flag
siril_c_flag += '-DHAVE_FFTW3F_OMP' das ist ein gcc-Flag

Das ist eine schiere Zumutung für jemand, der das in seiner Freizeit macht!

Kommen wir zu opencv4:
Im meson-Skript finde ich schließlich ohne jede weitere Erklärung:

enable_openmp = get_option('openmp')
enable_libcurl = get_option('libcurl')
enable_exiv = get_option('exiv2')
enable_libraw = get_option('libraw')
enable_libtiff = get_option('libtiff')
enable_libjpeg = get_option('libjpeg')
enable_libpng = get_option('libpng')
enable_libheif = get_option('libheif')
enable_libXISF = get_option('libXISF')
enable_ffms2 = get_option('ffms2')
enable_ffmpeg = get_option('ffmpeg')
enable_criterion = get_option('criterion')
enable_libjxl = get_option('libjxl')
enable_libgit2 = get_option('libgit2')

Das scheinen Optionen zu sein, und tatsächlich wird -Dlibjxl geschluckt.
Aber: Kein opencv4 abschaltbar oder downgradebar?

Und überhaupt, warum so kompliziert?:
meson -> ninja -> cmake -> make -> endlich! Kompilierung

Das nenne ich einen wahrhaften Turm von Babel!
Ja, das Make-System ist cryptisch und ziemlich mächtig, aber das hier ist mindestens genauso cryptisch.
Dann setze ich mich lieber hin und lerne einfach mal fürs Leben, wie Make funktioniert, und fertig.

Ja, da bin ich erzkonservativ und vollkommen innovationsfeindlich.
Innovation muss ein Problem lösen oder zumindest Komplexität reduzieren.
Hier aber werden Probleme hin- und hergeschoben und dabei mehr und mehr Komplexität geschaffen.

Verzeiht meinen polemischen Ton, aber es wird Zeit, dass Linux Komplexität reduziert und so auch für Hobbyfreaks
wieder attraktiv wird und siril ist symptomatisch.

Vergessen wir nicht Multics, das allumfassende doch unbrauchbare Betriebsystem, es ist aufgegeben worden.
Als dessen Antwort wurde das schlanke und modulare Unix geschaffen und war bisher ziemlich erfolgreich.

Claus
 
Zitat von fuetti:
Windows geht bei mir nie, nie, nie ans Netz
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Hallo Claus,

Bitte sei Dir da nicht so sicher, dass Linux so viel besser geschützt ist, gerade, wenn Du nicht auf den letzten Update Level bist.

Ich sitze bei uns in der Firma im IT Security Board, wo wir jede Woche die neusten Vulnerabilities durchgehen. Da ist auch immer wieder Linux betroffen. Wir treiben einen sehr hohen Aufwand, um unsere Netzwerke mit tausenden Rechnern zu sichern mit State of the Art Equipment für sehr viel Geld und auch sehr teurem externen Support. Dennoch haben wir jede Woche neue Vulnerabilities.

Das Problem bei OpenSource ist, dass eben auch der versierte Hacker den Code nach Schwachstellen scannen kann. Bei proprietären, geschlossen Systemen ist das weitaus schwieriger. Das führt dazu, dass bei uns z.B. SFTP grundsätzlich verboten ist. Es ist das Nummer 1 Tool für den Datenklau, wenn sich jemand Zugriff verschafft hat.

Unser ehemaliger Mutterkonzern wurde vor ein paar Jahren gehackt und sensible Daten wurden gestohlen. Das hat dem Konzern viele Millionen gekostet und ihm einen schweren Stand in der Öffentlichkeit beschert mit massiven Kursverlusten an der Börse.

In der heutigen Welt mit staatlich geförderten IT Terroristen ist IT Sicherheit leider ein immer größeres Problem. Mit AI wird das Problem sicher noch gewaltig wachsen, gerade auch um OpenSource Code auf Schwachstellen zu scannen. Ich gehe davon aus, dass schon etliche uns feindlich gesinnte Akteure mit Freude an AI gestützer Intrusion arbeiten werden...

Viele Grüße,

Günther
 
Zitat von fuetti:
Wozu OpenSource, wenn man Kompilierung praktisch unmöglich macht, es sei denn man hat zufällig das richtige System und die richtige Release?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Hallo Claus,

Mal abgesehen von den sicherheitsrelevanten Themen in meinem vorherigen Post, bin ich ein Befürworter für quelloffene freie Software. Die Gründe sind vielfältig und könnten hier etliche Zeilen füllen. Man kann einfach nicht erwarten, dass die Entwickler die Zeit aufwenden die Compilation auf etlichen Systemen zu testen, sie sollem sich auf Ihre Kernkompetenzen bei der Software Entwicklung beschränken dürfen und wir alle sollten sie da unterstützen! Dazu gehört auch, dass man sich bei Problemen direkt an die Entwickler wendet, sie sind auf Feedback angewiesen. Ich habe das schon öfter gemacht und teste derzeit auch aktiv bei einer aktuellen OpenSource Entwicklung.

Viele Grüße,

Günther
 
Zuletzt bearbeitet:
Hallo Günther,

herzlichen Dank für Deinen wertvollen Beitrag. So deutlich wird das leider selten gesagt, Deine Argumente sind stichhaltig.
Jetzt weichen wir allerdings vom Thema ab. Aber wichtig ist das hier leider auch.

Es ist sogar schlimmer: Jeder kann im Prinzip am Code mitschreiben, die zlib-Geschichte ist hier eine Lehre.
Um so mehr muss man unbedingt auf Schlankheit und Lesbarkeit von Code achten, denke ich, auch bei siril ;-)

Zu KI habe ich mich früher hier ausführlich geäußert: Alles was KI ausspuckt muss geprüft werden (QM). Kritische Software oder Entscheidungen müssen definitiv von erfahrenen Menschen kommen. Das wird auch in Zukunft so bleiben. Wenn Hacker KI nutzen, können das auch die Programmierer: Patt Situation, also kein Vorteil für eine Seite. Übrigens würde ich KI zum Scannen von (für Menschen fast unlesbaren) Binaries empfehlen, KI wird da viel eher einen Durchbruch ermöglichen, als bei Sourcecode. Das wird Microsoft & Co in große Schwierigkeiten bringen, wenn das mal gemacht wird. Mwmöglich könnte KI sogar effizient für Reverse-Engineering von Binaries gut funktionieren?

Hier die Antwort von ChatGTP:

Kannst Du Reverse-Engineering von Binaries

ChatGPT:​

Kurzantwort: Ja – ich kann dir beim Reverse Engineering helfen, aber nur in einem legalen und ethisch sauberen Rahmen.

✅ Wobei ich helfen kann​

  • Analyse von eigenen Programmen
  • Verständnis von Open-Source-Binaries
  • Reverse Engineering zu Lernzwecken
  • Analyse von Malware
  • Verständnis von:
    • ELF / PE / Mach-O Struktur
    • Disassembly (x86, ARM)
    • Ghidra / IDA / Radare2 Nutzung
    • Strings, Symbols, Sections
    • Debugging mit gdb
    • ARM (z. B. Raspberry Pi) Reverse Engineering
  • Passwort-/Hash-Verständnis (nicht Cracken fremder Systeme)
  • Firmware-Analyse eigener Geräte

❌ Wobei ich nicht helfen darf​

  • Kopierschutz umgehen
  • Lizenzmechanismen cracken
  • DRM entfernen
  • Softwarepiraterie
  • Sicherheitsmechanismen fremder Systeme aushebeln
  • Fremde Accounts oder Systeme kompromittieren
---------------

Bestimmt wird das im Augenblick bereits gemacht. Ganz sicher in Russland und China, würde mich sehr wundern, wenn nicht ;-)

Die Lösung, die ich vorschlage: Betriebssysteme sind heute Teil der kritischen Infrastruktur. Daher muss sie staatlich finanziert werden, insb. wenn Hacker staatlich finanziert werden. Auch die Prüfung auf Backdoors sollten finanziell unterstützt werden. Aber nicht von Behörden oder Ministerien, sondern von geprüften freien Programmierern, die wie Richter unabhängig vom Staat sein müssen.

Open Source ist dennoch besser als Closed Source. Beide sind Angriffen ausgesetzt. Closed Source ist kein Vorteil mehr. Microsoft hat außerdem keinen guten Ruf und mehrfach Backdoors schon jahrelang bestehen lassen, das ist dokumentiert. Wohingegen Open Source Communities extrem schnell reagieren, z.B. zlib oder diese Lücke in den Intel-CPUs - hab den Namen vergessen.
Das schlimme dabei: Microsoft Windows hackt leider mehr und mehr selbst ihre User und klaut deren Daten.
Wenn der Bock zum Gärtner wird, ist halt das geringere Übel immernoch Open Source.

Warum ist sftp unsicher? Es basiert auf ssh und das gilt als das sicherste Protokoll. Ich kenne nichts Besseres, und Du?
Man kann ja noch ssh-keys und VPN dazuschalten und fail2ban und ftables, http für e-Mails deaktivieren, etc.
Was ist in dem Konzern passiert, wenn ich fragen darf? Würde mich sehr interessieren.
Oft sind ja unaufmerksam auf Buttons klickende Mitarbeiter das Problem.


Viele Grüße
 
Zuletzt bearbeitet:
Zitat von steffens:
Genau, weil opencv4 eine "mandatory build dependency" ist, nicht optional.
Auch das ist in der README.md dokumentiert.

Ich bin dann hier raus.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ja, das stimmt. Also lässt man 13 Monate alte Betriebssysteme einfach unberücksichtigt.
Du meinst also, dass es in Ordnung ist, wenn man Rückwärtskompatibilität opfert?
Nun, ist es nicht genau das, warum MS bis heute und trotz aller schwerwigender Probleme, erfolgreicher als Linux ist?
Bibliotheken zu ändern ist dramatisch für viele Sofwaren, die darauf beruhen. Ich finde, dass da zu leichtfüßig vorgegangen wird.
Das entspricht auch nicht der good practice in der Industrie.
 
Zitat von fuetti:
Warum ist sftp unsicher?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Hallo Claus,

Das Thema geht jetzt sehr off topic, aber mal zu Beginn, es gibt nicht mal ein gültiges RFC für SFTP, nur einen uralten Draft. Der letzte mir bekannte Draft ist datiert Oktober 2001, immerhin schon in diesen Jahrhundert. Das bedeutet, es gibt keinen einheitlichen Standard für die SFTP Implementierung. Das ist per se eigentlich schon ein Ding der Unmöglichkeit. Nun wird ja ein SSH Tunnel genutzt, der bei der Übertragung schon Sicherheit gewährleistet, aber wie gesagt, wenn eine Intrusion stattgefunden hat und SFTP schon verfügbar ist, gibt es für einen Hacker nichts besseres um Daten unbemerkt nach draußen zu schicken. Das ist das Hauptproblem. Das bekommt man im Regelfall gar nicht mit und deshalb ist das bei uns verboten.

Für sensiblle Daten nutzen wir sogenannte managed File Transfers, die auf beiden Seiten kontrolliert werden. Die zu kompromittieren ist ohne Backdoor praktisch nicht möglich. Eine Nutung durch einen Intruser ist ebenfalls praktisch ausgeschlossen. Die Transfer Protokolle sind nicht öffentlich verfügbar. Die Systeme sind durch mehrstufige DMZs und Perimeter Server abgeschirmt, nicht mal unsere Admins kommen da ohne physischen Zugang direkt an die Server ran. Mehr Sicherheit geht dann irgendwann nicht mehr. Nur ein krimineller Akteur im Inneren auf beiden Seiten könnte da noch Schaden anrichten. Das alles ist extrem teuer und aufwändig, aber in bestimmten Bereichen geht es dann nicht anders.

Nun ist bei uns Privatanwendern meist nichts zu holen und wir sind deshalb ja normalerweise nicht im Fokus. Ich wollte hier nur Sensibilisieren, dass fast nichts im Netz wirklich sicher ist. Mit den Risiken muss man am Ende leben.

Viele Grüße,

Günther
 
Zuletzt bearbeitet:
Zitat von fuetti:
Ich habe heute versucht siril 1.4.1 auf OpenSuSE 15.5 zu kompilieren, um meine dort sauber installierte NVIDIA-Karte nutzen zu können.
Da diese inzwischen angelaufene Distro bei Siril 1.2 stehen geblieben ist, musste ich also selbst kompilieren, was ich schon oft erfolgreich machen konnte.
Z.B. das neueste stellarium war hier völlig schmerzlos, aber siril1.4 wurde ein absoluter Albtraum.

git clone FA / Siril · GitLab
cd siril
meson setup _build --buildtype release

und dann kamen Fehlermeldungen.
Nach Nachinstallation zahlreicher Bibliotheken bin ich fast an lcms2 gescheitert, weil meine Version veraltet war.
Also habe ich den Sourcecode heruntergeladen und in /opt installiert. Alles nochmals gut gegangen!
Doch dann scheiterte ich, da die glibc nicht aktuell genug war.

Nebenbemerkung: Die 15.5 ist wirklich nicht sehr alt, bis vor kurzem war die 15.6 die aktuellste Version, gerade ist 16.0 rausgekommen.

Jetzt ist es hier gescheitert und hat den Header nicht gefunden:
#include <filesystem>
^~~~~~~~~~~~
Also habe ich den Standard-C- und C++- Compiler auf Version 10 gesetzt und der Fehler verschwand.
Dann wollte er eine merkwürdige Biblio für ein exotisches Kameraformat: xisf. Das habe ich manuell (!) aus meson.build entfernt,
denn ich werde dieses Format nie verwenden. Warum erkennt das meson Skript das nicht, und bereitet das Kompilieren entsprechend vor?
Normalerweise sollten optionale Biblios automatisch durch if-Abfragen im meson-Script geprüft und entsprechend ausgeschlossen.
Der User sollte davon nichts merken - Pustekuchen!
Schließlich sollte man doch wählen könne welche optionalen Features man mitnehmen möchte, so ist das jedelfalls gedacht.

Dann machte opencv4 Probleme - ich hatte nur V3. Eigentlich sollte es auch ohne opencv funktionieren,
denn siril ist kein stellarium oder Game, in dem der Screen ultraschnell gerendert werden muss.
Ich hatte es also nicht installiert, V3 scheint nicht zu passen (warum?) und eigentlich sollte auch hier das Skript das erkennen
und automatisch das Makefile entsprechend einrichten.
Wie sollte das sein?

Im meson.build findet man:

some_target = executable('foo', sources, dependencies: opencv_dep)

Besser wäre demnach:

if opencv_dep.found()
some_target = executable('foo', sources, dependencies: opencv_dep)
else
some_target = executable('foo', sources)
endif

D.h. wenn opencv nicht installiert ist, fährt er automatisch ohne diese Lib weiter - easy-peasy!

So gab es eine harte Fehlermeldung und ich konnte nicht fortschreiten mit ninja -C _build -j4.
Diese Bibliothek war nicht nachzuinstallieren, ohne das ganze System zu beschädigen.
Also versuchte ich alles opencv4 aus dem meson-Skript zu entfernen, doch bestrafte mich meson mit Fehlermeldungen, es gab keinen Ausweg mehr.
Nach 4 Stunden musste ich aufgeben.

Ich klassifiziere daher dieses Installationsskript als mangelhaft und User-feindlich.
Das Durchgehen des Source-Codes habe ich mir erspart, ich hoffe, dass er wenigstens sauber modular aufgebaut ist.
Die Entwickler haben nicht auf Rückwärts-Kompatibilität geachtet, was eigentlich Industriestandard ist.
Ich erwarte ja keine Kompatibilität mit OpenSuSE 10.2 von vor 10 Jahren oder noch älter, aber die zweitneueste Distro sollte schon noch funktionieren.

Fazit: Das Meson-Script ist unausgereift, ja schlampig erstellt, denn es erlaubt nicht, die Kompilation sauber zu konfigurieren,
z.B. unnötige oder ungewünschte Komponenten abzuschalten, was eigentlich der Sinn von meson ist.

Thumbs down, liebe siril-Entwickler!
Claus
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Claus,

I'm going to be frank with you here. While I appreciate detailed feedback, your assessment is largely unfair to the development team.

You're right about one thing: OpenCV has indeed become a mandatory dependency in Siril 1.4.1. We made that decision because core features now rely on it - it's not just about "ultrafast screen rendering." However, your broader complaints about the build system are still off the mark.

Optional features CAN be easily disabled - you just need to understand how Meson works. You can run meson configure _build to see ALL available options, or check the meson_options.txt file. Want to disable XISF? Use -Denable-libxisf=false. It's literally that simple. Instead of manually hacking meson.build (which is guaranteed to break things), you should have taken 2 minutes to read the documentation or check the available options.

You're complaining about a problem YOU created by manually removing dependencies from the build files. That will obviously cause cascading failures - that's not the script being "sloppy," that's you breaking the build configuration.

Regarding your platform: OpenSUSE 15.5 is from mid-2023 with packages frozen from that era. Yes, OpenCV 4 is required now - that's not unreasonable for software released in 2025. The build system successfully compiles on countless distributions, macOS, and Windows. If it were truly "deficient" as you claim, that wouldn't be possible.

Finally, this is an open-source project. If you can improve things, pull requests are welcome. But don't confuse your specific compatibility issues with a "sloppy" build system.

Cyril
 
Oh, and one more thing I forgot to mention:

If Meson is really such a nightmare for you, we STILL support Autotools for building Siril. You can use the traditional ./configure & make approach if you prefer. So you had options all along - you just chose to spend 4 hours manually butchering the Meson build files instead of either:

  1. Learning how to use Meson's configuration options properly
  2. Switching to the Autotools build system that's still maintained
But sure, it's our build system that's the problem.

Cyril
 
Zitat von lock042:
Oh, and one more thing I forgot to mention:

If Meson is really such a nightmare for you, we STILL support Autotools for building Siril. You can use the traditional ./configure & make approach if you prefer. So you had options all along - you just chose to spend 4 hours manually butchering the Meson build files instead of either:

  1. Learning how to use Meson's configuration options properly
  2. Switching to the Autotools build system that's still maintained
But sure, it's our build system that's the problem.

Cyril
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Cher Cyril, merci beaucoup de ta reponse. Je continuerai en anglais afin de ne pas exclure les autres lectrices et lecteurs.

Yes I was a bit too harsh, I admit. I am honest, thats all. I mainly critizied recent linux policy. But thats not for you, indeed.

However, coming to Siril:
1. Why meson? Is it really needed? I never compiled programmes with meson before. The make and cmake-system has been doing the job very well at least for 30 years. Do not confuse people with meson and cmake and make - stay KISS. The chain meson -> ninja -> cmake -> make -> compile seems to me a dinosaur and over-engineered. I refuse to learn meson and ninja as Make provides everything needed to compile complex software in a convenient way. I also refuse Flatpak, Snap, Appimage and Docker as a workaround to the badly organized library infrastructure. This is Microsoft-Thinking: Is there a Problem? Don't solve it properly, build a workaraound and keep it. I opt for solving it properly.

4. Why does the meson script not sort out, which optional libraries are present or not? cmake is able to do that.

5. Why opencv4, if opencv3 seems to fullfill the requirements as well as V4 as far as I found after a quick research?
Usually new distributions allow installing older libraries but not the inverse.

6. You suggest to contribute? I think you do not really wish that. I am missing documentation in your source code a lot.
E.g. take src/core/siril.c:
This piece of software has 527 lines
> cat siril.c | wc -l
527
from which 12 begin with "/*", i.e. its a comment line:
> cat siril.c | grep '\/\*' | wc -l
12

This is ok only, if the variable names talks to the reader and reveals its role sufficiently.
However, I find functions as "visu" or "loglut" or "ddp". Very enigmatic to me, sorry.
Lets have a closer look into src/core/siril.c into function ddp:

C: 
int ret = copyfits(a, &fit, CP_ALLOC | CP_COPYA | CP_FORMAT, -1);
    if (!ret) ret = unsharp(&fit, sigma, 0, FALSE);
    if (!ret) ret = soper(&fit, l, OPER_ADD, TRUE);
    if (!ret) ret = nozero(&fit, 1);
    if (!ret) ret = siril_fdiv(a, &fit, l, TRUE);
    if (!ret) ret = soper(a, coeff, OPER_MUL, TRUE);
[/CODE]

What does "ret" mean? Is it "success" or "failed"?
Further I would structure it in a more lisible standard way:
C: 
    ret = unsharp(&fit, sigma, 0, FALSE);

    if ( !ret ) {
        ret = soper( &fit, l, OPER_ADD, TRUE );
        if ( !ret ) {
            ret = nozero( &fit, 1 );
            if ( !ret ) {
                ret = siril_fdiv( a, &fit, l, TRUE );
                if ( !ret ) {
                    ret = soper( a, coeff, OPER_MUL, TRUE );
                }
            }
        }
    }
}

I use siril, however I do not understand at all whats going on here and I do not spend another 4 hours to find out.

Hope you take it as a humbel constructive contribution.
Documentation and lisibility saves time and avoids errors and allows to hire new motivated volunteers for this imressive project I fully acqnowledge herewith.

Cheers and amicalement, Claus
 
> 1. Why meson? Is it really needed?

I'm sorry, but I'm going to be a little blunt. Who are you? Who are you to tell us what technical choices we should make?
Meson was chosen for reasons of modernity and speed. Meson compiles quickly on Windows, whereas autotools takes a very long time and compilation time is CPU time on GitLab or on our machine (not yours). For example GIMP uses meson.
And as I said, we decided to keep autotools, even though we no longer use it.

> The chain meson -> ninja -> cmake -> make -> compile seems to me a dinosaur and over-engineered.

Yes. Seems to you. Does it mean you are universal?
And I would like to remind you that we offer binaries in various formats, but none of them suit you. I think the problem is definitely not the way we build our builds.

> 4. Why does the meson script not sort out, which optional libraries are present or not? cmake is able to do that.

Before attempting to read and modify the code, read the documentation first: Installation from source code — Siril 1.4.1 documentation

> Why opencv4, if opencv3 seems to fullfill the requirements as well as V4 as far as I found after a quick research?
> Usually new distributions allow installing older libraries but not the inverse.

Projects that can afford to manage multiple versions of libraries surely have greater resources.
 
As an open-source developer myself, I’ll admit I’m honestly pretty ashamed of how harsh such comments can be. Anyone who’s tried to ship cross-platform binaries knows how hard and painful that process is. It’s real work, and it’s rarely appreciated.

Comments like these sometimes make me wonder why I even keep my projects open on GitHub at all. So genuinely: great work, and thanks for pushing this forward @lock042

Best
Stefanie
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben