• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[Linux Mint] Selbst compilierte Binary wird nicht ausgeführt

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Nur mal so generell:

Dieses "Lade XY von Webseite Z runter und frickel das ins System rein" ist ein Relikt aus der Windows-Denke. Das hat in Linux, zumindest in einer vernünftigen großen Distro wie Debian, nichts zu suchen. Zwei Gründe:

1. Die Abhängigkeiten im System werden damit aufgebrochen und verschiedene nicht aufeinander abgestimmte Softwareversionen müssen ungetestet zusammenarbeiten. Das fördert nicht die Stabilität des Systems und frustriert ziemlich schnell, wenn mal wieder dann was nicht mehr funktioniert, weil Software XY gestern fünf Libraries geupdated hat, mit denen die Version von Systemd nicht zurechtkommt. Hatten wir erst mit einem Kundensystem mit PHP aus Fremdquellen, die dann hergegangen sind und die Cryptolibrary geupdated hat, was dann das Upgrade verhindert hat und einen inkonsistenten Softwarestand nach sich zog, den ich nur mit Brutalität und einer Zitterpartie wieder hingebogen hab (weil das ja nicht länger als ne Minute ausfallen durfte!).

2. Fremdquellen sind nicht vertrauenswürdig. Auch bei Windows kommt ein nicht unerheblicher Teil der Schadsoftware aus Internetquellen, die absichtlich angezapft wurden. Über den Updatemechanismus des Betriebssystems selbst kommt seltenst was rein. Daher ist es sinnvoller, das System bei Linux aus einer Hand zu beziehen, d. h. den Paketmaintainern der Distro.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #42
Also mal zum Stand:

Ich habe mir jetzt von codeblocks.org die Binarys für meine Distribution runtergeladen. Erhalten habe ich ein Archive mit ca. 20 deb-Paketen mit unterschiedlichen Abhängigkeiten. Mit dabei war auch eine *.buildinfo. Ich habe nun via dpkg die Pakete aus dem Archiv installiert. Dabei bekam ich natürlich die Meldunng, dass da einige Abhängigkeiten nicht aufgelöst werden konnten und habe dann rausgefunden, dass man das im Nachhinein noch mit apt-get -f install fixen kann. Ist natürlich nicht die sauberste Lösung, aber so hat es jetzt erstma funktioniert.

Nun also ein paar Fragen:

1.) Ist nicht die *.buildinfo dazu gedacht, dass ich damit ein vernünftiges Skript erstellen kann, das mir dann alle Pakete inkl. Abhängigkeiten installiert? Habe leider noch nicht rausgefunden wie :unknown:
2.) Auf codeblocks.org ist auch eine Angabe zu einem halboffiziellen Repository, in dem die aktuellste Version von CB zur Verfügung gestellt wird. (Leider komme ich grade nicht auf die Seite drauf, keine Ahnung, wo da das Problem liegt.) Wie füge ich denn andere Repos zu meiner Liste hinzu?

Ich danke euch vielmals für eure vielen Ratschläge! Habe vor, in einiger Zeit auch produktiv auf Linux umzusteigen und muss mich da einfach in viel reinarbeiten. Aber das wird schon :T

[EDIT:]
Im Übrigen wäre mir natürlich auch ein Repo als Quelle lieber. Alleine schon wegen der Updates. Nur doof halt, dass in den offiziellen Repos eine veraltete Version liegt :unknown:
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Kenobi van Gin: Neue Repos hinzufügen: Datei in /etc/apt/sources.list.d/ werfen, und den Key fürs Repo in den Keystore importieren. Wenn du deb-Pakete fertig kompiliert bekommst, machen die das oft selbst.

Jetzt noch die eine Frage: Wozu brauchst du die neueste Version einer Software?

- Du vermisst eine Funktion, die du unbedingt benötigst - das ist ein äußerst seltener Fall für den normalen Programmierer.
- Es wurde eine Sicherheitslücke gefunden, und die Debian-Version ändert sich nicht - das ist ein beliebter Anfängerfehler; die Sicherheitspatches werden bei Debian äußerst schnell eingepflegt, die Softwareversion ändert sich aber nur nach dem Plus, weil nur der Sicherheitspatch eingebaut wurde, nicht die neuen Funktionen, welche die Stabilität gefährden könnten.
- Du willst immer den neuesten Scheiß, ohne konkrete Gründe zu haben - dann bist du bei Debian falsch. Debian kann Stabilität und Sicherheit. Neuer Scheiß ist nicht stabil und selten sicher. Das ist genau das Gegenteil von dem, was Debian erreichen will. Nutz Ubuntu oder Mint, das ist Debian für Pfuscher und notorische bleeding-edge-Hipster.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #44
Nutz Ubuntu oder Mint, das ist Debian für Pfuscher und notorische bleeding-edge-Hipster.

Wird da etwa jemand grantig? :D
Ich war immer davon ausgegangen, dass aktuelle Software unter anderem eine der Grundlagen einer sicheren Arbeitsumgebung ist. Selbst die Version auf der Homepage von Code::Blocks ist das letzte Mal 2018 upgedatet worden. Insofern wundert mich das sowieso schon, warum das nicht im offiziellen Repository drin ist.

Dein Fazit also: Du würdest die einfache Updatebarkeit durch die offiziellen Repos einer neuen Major-Version vorziehen?
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@Kenobi van Gin: Schau dir mal "checkinstall" an wenn du von der Quelle kompilierst.

Etwas darüber steht hier:

https://forums.linuxmint.com/viewtopic.php?t=230142

For compiling to work build-essential must be installed. Install it from Software Manager or with [kw]apt install build-essential[/kw].

Most compilation instructions will say to run the command [kw]sudo make install[/kw] to install the software after compiling. You should instead use the command [kw]sudo checkinstall[/kw]. That does the same thing but will make the software and its files known to your package managers (e.g. Software Manager and apt ) so that you can easily remove the software or replace it with a newer version. For this you will first have to install checkinstall. Install it from Software Manager or with the command: [kw]apt install checkinstall[/kw].

Also wären die Schritte wie folgt um die Quelle zu kompilieren und installieren:
[src=text]./configure
make
sudo checkinstall[/src]

chekcinstall anstelle von "make install".

[kw]man checkinstall[/kw]:
checkinstall is a program that monitors an installation procedure (such as make install, install.sh ), and creates a standard package for your distribution (currently deb, rpm and tgz packages are supported) that you can install through your distribution's package management system (dpkg, rpm or installpkg).

Note that for most useful actions, checkinstall must be run as root.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #46
Hm :confused: Er sagt mir, build-essential wäre bereits installiert und aktuell. Den Befehl checkinstall findet er aber nicht. Ebenso wenig wie den Befehl ./configure. Gebe ich make als make-Datei die *.buildinfo mit, beschwert er sich über ein falsches Format.
Ich finde ja, wenn sie auf der Seite schon Binarys zum Download anbieten, könnten sie zumindest dazu schreiben, wie man die installiert. Offenbar liegt es ja zumindest nicht nur daran, dass ich ein Linux Newbie :dozey:
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@Kenobi van Gin: "checkinstall" ist ein extra Paket. Das musst du zusätzlich installieren.

Schau mal in die "BUILD" (Build steps introductions) die mit in dem Quellcode Download von Sourceforge zu finden ist.

PS: Den Source Code habe ich von hier: http://www.codeblocks.org/downloads/25 und dann direkt von Sourceforge.

PS: Auszug aus der "BUILD"-Datei, Anleitung zu Kompilieren:
Unix build instructions:
------------------------
You need a working autotools environment (autoconf, automake, libtool, make, etc).
In a terminal, go to the top level folder.
If you fetched the sources from SVN, you need to bootstrap the program first. So type:

./bootstrap

This will adapt the project's configuration file to your environment. This only needs to be done once: the first time you checkout the SVN version.

After this, type the following:

./configure --with-contrib-plugins=all
make
make install

For the last step you must be root.
That's it.

Und anstelle von "make install" rufst du "checkinstall" auf.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Wird da etwa jemand grantig? :D
Das auch, liegt aber nicht an dir, sondern an dem Rotz, den ich von unseren Zulieferern teilweise bekomme, weil die lieber agile-Bullshit liefern als stabile, ausführlich getestete Versionen. Früher nannte man die Agile-Hipster-Scheiße "Bananensoftware" - weil reift beim Kunden. Heute ist das der heiße Scheiß, und keiner außer die Developer und die Bullshit-Bingo-Salesmanager wissen, was daran gut sein soll. Bug? Ach, kein Problem, liefern wir ne neue Version aus, am Besten in nodejs, mit 10k Fremdquellen, die alle auch agile deployen und das ist alles dann ganz sicher viel besser und stabiler, weil... die Upstream-Entwickler sicher die Bugs, die ich in meiner Verwendung der Library nie getriggert habe, zur Kompilingzeit gefixt haben, und in keinem Fall da dann neue Bugs eingebaut haben, die ich nie testen konnte, weil die Version bei meinem Compiling noch nicht existiert hat.

So hat Sicherheit und Stabilität schon immer funktioniert! Compiling against a moving target, what else!

Du missverstehst etwas den Debian-Ansatz. Debian Stretch kam im Juni 2017 raus, Buster wird jetzt in der ersten Juliwoche rauskommen. Für Buster hat der soft-freeze im Januar begonnen - ab diesem Zeitpunkt durften von den Paketmaintainern nur noch Bugfixes eingespielt werden, keine neuen Funktionen mehr. Dieser Softwarestand wird die nächsten zwei Jahre für Debian Buster gehalten werden. Die einzigen Änderungen daran sind minor changes und Bugfixes, und dafür hat Debian eine eigene Versionierung:

2.3.4-5+deb9u4

2.3.4-5 ist die letzte Version, die der Paketmaintainer von Upstream vollständig gezogen hat.
deb9u4 ist das 4. Update dieser Version für Debian 9. Diese Updates sind Bugfixes oder Sicherheitspatches, neue Funktionen werden nicht eingeführt, weil diese die Paketstabilität beeinträchtigen könnten bzw. weitere Abhängigkeiten nach sich ziehen würden, welche die Testergebnisse, die während der Frozen-Phase vor Release gesammelt wurden, nichtig machen würden. Das schlägt der Fokus auf Stabilität voll zu.

Das bedeutet für dich als Anwender: Du nutzt Software, die rigoros getestet wurde. Fehler sind selten, meist Cornercases, und das Zusammenspiel der Libraries ist weitestgehend vorhersehbar. Das erkaufst du dir damit, dass du bis zum Release der Nachfolgeversion 2,5 Jahre alte Software einsetzt, sofern sie nicht aus Sicherheitsgründen ein Update notwendig macht (zum Beispiel weil ein Cryptoalgorithmus gebrochen wurde).

Um diesen Nachteil etwas abzufedern, gibt es die Backports. Hier wird eine neue Softwareversion, wie sie aktuell im Testing-Zweig genutzt wird, für eine Stable-Version gepackt und mit allen Abhängigkeiten ausgeliefert. Eine Installation aus den Backports muss aber erzwungen werden, und mit dem Erzwingen nimmst du stillschweigend hin, dass Probleme auftreten können, weil die Tests natürlich nicht so umfangreich waren.

Dein Fazit also: Du würdest die einfache Updatebarkeit durch die offiziellen Repos einer neuen Major-Version vorziehen?
Jederzeit. Ich hab schließlich schon erlebt, was Fremdrepos so anrichten können, selbst wenn sie nicht böswillig manipuliert waren, sondern halt nur 'agile' gebaut wurden. Da kann man schon mal ne kritische Systemkomponente ersetzen...
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #49
Okay, danke dir schonmal für die vielen Erklärungen. Ich werde mir das in Ruhe nochmal ansehen. Das klingt doch nach mehr Arbeit als gedacht. Aber wie gesagt, am Ende lerne ich ja was dabei :T

Auch dir vielen Dank für deine Mühe! Ich werde mich jedenfalls mal ernsthaft mit dem Gedanken auseinandersetzen, dann demnächst nochmal Debian drüber zu installieren. Ich bin zwar eigentlich schon ein Fan davon, regelmäßig Updates zu installieren. (Allerdings eher, weil mir das das Gefühl gibt, auch sicherheitstechnisch etc. immer auf dem neuesten Stand zu sein.) Aber notwendig scheint das ja nicht unbedingt zu sein.
 

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
Insofern wundert mich das sowieso schon, warum das nicht im offiziellen Repository drin ist.
Kein Maintainer.

Es gibt niemanden, der neue Versionen von Code::Blocks für Debian paketiert. Solange sich keine Freiwilligen finden, die das mal machen, wird es in den offiziellen Debian Repos keine neue Version geben,

---- manuell zusammengeführter Beitrag ----

Wenn jetzt jemand damit anfängt und die Sache gut macht, dann wird es die Major-Version Herbst 2020 im Sommer 2021 im Debian Stable Repository geben. Dann die Community der IDE überzeugen jene Version als LTS zu behandeln und es kommen vielleicht noch ein paar wichtige Patches durch die "muh integrity" Verteidigung in das Repo.

---- manuell zusammengeführter Beitrag ----

@Shodan: Nur, dass ich das richtig verstehe: Man läd zur Laufzeit oder zur Compiling-Zeit irgendwelchen Schlonz aus dem Internet nach, von Leuten, die man nicht kennt, von Repos, die jeder Hanswurst aufsetzen kann, ohne dass das Leute überprüft haben
Joa so funktioniert das mit dem Distributieren von Open Source Quellcode und deren binary packages. :rolleyes:

Ich will Flatpack ja nicht empfehlen, es wurde im Thread halt angesprochen, als Quelle einer neueren Version. Ich schaffe lediglich Informationen herbei. Ansonsten siehe theSplit für 'ne ordentliche Quelle.

Flatpack ist ein bisschen app-isolation, die Dependencies der App von denen anderer Services des Betriebssystems isoliert, statt zu versuchen einen Konsens über die zu installierenden Versionen zu finden.

Das ist die Modularisierung der Dependency Hell: man baut einen neuer Layer ein, ab dem die darunterliegende Software, die Primärfunktion, die der User will, priorisiert wird und daher über die Library-Versionen bestimmen kann. Ab dem Layer gibt es dann viele Versionen der Libs gleichzeitig im Speicher um etwas umzusetzen, was ich als "mutli tenant" bezeichnen will, halt nicht für "User" oder "Kunden" sondern für Prozesse / Anwendungen als "Bewohner" des Systems.

In dem Pack ist auch wxWidgets drin. Siehe http://forums.codeblocks.org/ Da wird fleißig getestet und gefixt und wenn das sauber aussieht, kann die lib um eine minor Version auf 3.1 erhöht werden. Ohne sich dabei über andere Nutzer der lib Gedanken machen zu müssen. Wenn es andere Nutzer der Lib gibt und wenn die zufällig die selbe Version einsetzen, dann ist es ein Fall für die Data Deduplication.

Zum Inhalt des verlinkten Repos von cosimoc, Es gibt zu "--share=ipc" eine Fußnote[/URL] im Kontext von --socket=x11.
"--filesystem=home" ist auch so 'ne Config, die schön zeigt, dass es nicht um Sicherheit gegen bösartige Maintainer geht.
"--allow=devel" ändert das "syscall filtering" damit der Debugger der IDE funkioniert. ( https://docs.flatpak.org )
Sieht jetzt nicht nach Schlonz aus,


Diese Form von "Desktop-App-Sand-Box" kann man als ganzes natürlich für absurd halten.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home

Shodan

runs on biochips

Registriert
14 Juli 2013
Beiträge
661
Ort
Citadel Station
@Metal_Warrior: Du möchtest Kenobi etwas helfen und nebenbei am Linux Stammtischdiskussionen Dampf ablassen in Form genervte Rants über die Geschwindigkeit der modernen Softwareentwicklung und die Menge an Dependencies moderner Systeme. Doch das hab ich verstanden.

Dein Fazit also: Du würdest die einfache Updatebarkeit durch die offiziellen Repos einer neuen Major-Version vorziehen?
Nicht in diesem konkreten Fall!

Die Changelog in den offiziellen Repos:
codeblocks (16.01+dfsg-2.1) unstable; urgency=medium

* Non-maintainer upload.
* Apply patch from upstream svn to fix FTBFS with GCC 7.1

Sat, 30 Sep 2017

codeblocks (16.01+dfsg-2) unstable; Tue, 14 Jun 2016
codeblocks (16.01+dfsg-1) unstable; 23 May 2016

https://packages.debian.org/buster/codeblocks [edited for brevity]


Das bedeutet für dich als Anwender: Du nutzt Software, die rigoros getestet wurde. Fehler sind selten, meist Cornercases, und das Zusammenspiel der Libraries ist weitestgehend vorhersehbar. .
Du bist ein Idealist und Generalist. Die Code::Blocks IDE, um die es hier geht, wird in den offiziellen Debian Repositories nicht maintained.
Oldstable ist das neue newstable. Automatisch übertragen und umdeklarierte. Das hat mit rigorose testen gar nichts zu tun, die Issues verrotten da im Bugtracker,
Ich kann echt nicht nachvollziehen, wie du hier das Paradigma über den Use Case stellen kannst.

Die offiziellen Debian Repos sind für diese konkrete Software keine gute Quelle. Es wäre schön, wenn es so wäre, aber es ist so halt nicht.

Es ist auch die Quelle, die das Linux Mint Tessa vom Kenobi einbindet. Weder Mint noch Ubuntu distributen die IDE.
Die Community die sie schreibt distributed selbst. :T
Und in den nightly-build-threads in deren Forum hängt auch jemand rum, der die nightlies auf Debian Stretch einsetzt und Probleme mit seiner libwxgtk 3.0.2+dfsg-4 berichtet, die dann gefixt werden. Open Source halt.

Das klingt doch nach mehr Arbeit als gedacht. Aber wie gesagt, am Ende lerne ich ja was dabei :T

Selbst kompilieren :beer:

Du brauchst noch die erwähnte libwxgtk3.0

Mint Tessa verteilt die "Ubuntu Bionic Variante" libwxgtk3.0-0v5 (3.0.4+dfsg-3) :unknown:

Debian Buster hat eine 3.0.4+dfsg-8,
(imho the optimal package version)
wxwidgets3.0 (3.0.4+dfsg-5) unstable; urgency=medium

* Cherry-pick three patches from upstream WX_3_0_BRANCH branch to fix warnings
from GCC8 when building applications using wxWidgets.

wxwidgets3.0 (3.0.4+dfsg-4) unstable; urgency=medium

* Update team email address due to alioth retirement (Closes: #899727)

https://salsa.debian.org/freewx-team/wx/blob/wx3.0-debian/debian/changelog

Süß. "cherry picked commits" aus der unveröffentlichten 3.0.5, die es noch in den Buster Freeze geschafft haben.

Das verlinkte Flatpack Repo zieht eine libwxgtk 3.0.4 (upstream stable) in Reinform,

Debian Stretch nutzt 3.0.2+dfsg-4




@Metal_Warrior zu die PHP Entwickler sollen "PHP Rewrite-DOT-zero EOL Edition" benutzen, weil der OS-Distributor nur das liefert.:
Erfahrene PHP Entwickler fragen im Bewerbungsgespräch nach der Versionsnummer der Laufzeitumgebung.
Mal ehrlich Metal_Warrior, stell dir mal vor du sitzt in so einem Gespräch als Bewerber für 'nen Debian-Admin Gig.

Die sagen dir, sie kaufen Server-Hardware[SUp](* also das umschließende System)[/SUp] mit Vendor-Locked-OS und deswegen gibt es für dich nur einen Fork von einer alten Debian Version, statt 'nem ordentlichem Stable von Debian.org

Denn nur diese "nicht die aktuelle upstream stable" Version hat der Hardwarehersteller angeblich rigoros gegen das Gesamtsystem getestet, um sie dann selber als "stable" zu bezeichnen, Dann hat er sogar das Patch Level vom Upstream abgekappt um stattdessen ein eigenes Patch Cherry Picking zu betreiben.

Aber der Gig dreht sich eigentlich um 'ne banale Anwendungsschicht, die sich einen scheiß für die Hardware interessieren, statt etwa um medizinische Roboterarme für Herzoperationen oder sowas.

Da geht dein Blick doch auch zur Tür.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Kenobi
Wenn du Debian einsetzt, solltest du dich drauf einstellen, dass der Programmierstil, den du grade verfolgst, nicht sauber funktionieren wird. Debian ist auf Stabilität ausgelegt, und eine Programmiersprache, die ständig das Neuste Buildkit erfordert, weil sie grundsätzlich gegen ein moving target aus tausenden Internet-Abhängigkeiten compiled, wird da mit hoher Wahrscheinlichkeit nicht gut laufen.

@Metal_Warrior: Du möchtest Kenobi etwas helfen und nebenbei am Linux Stammtischdiskussionen Dampf ablassen in Form genervte Rants über die Geschwindigkeit der modernen Softwareentwicklung und die Menge an Dependencies moderner Systeme. Doch das hab ich verstanden.
Ja und nein. Wenn Kenobi ein Debian einsetzen möchte, soll er wissen, was das bedeutet. Und warum es grundsätzlich ne schlechte Idee ist, tausende Abhängigkeiten zu haben, weil es sowohl Stabilität als auch Sicherheit beeinträchtigt. Das kann durchaus bedeuten, dass er seinen Code zukünftig in einer anderen Sprache schreiben sollte, weil er denn wenige bis keine Abhängigkeiten zu Fremdquellen hat, was Stabilität und Sicherheit zugute kommt.

Die Code::Blocks IDE, um die es hier geht, wird in den offiziellen Debian Repositories nicht maintained.
Oldstable ist das neue newstable. Automatisch übertragen und umdeklarierte. Das hat mit rigorose testen gar nichts zu tun
Richtig, und das aus vermutlich wirklich gutem Grund, weil der Maintainer schon keinen Bock mehr auf ein moving target hat. Das ist genau das Problem, an dem wir hier auseinander driften: Die Developer arbeiten in eine Richtung, die durch Admins nicht mehr eingesetzt werden kann, weil die Fehler und Sicherheitslücken sich mehren und der Frustrationsgrad astronomische Höhen erreicht. Wenn aber die Admins die Software der Devs nicht mehr einsetzen können, dann müssen die Admins selbst wieder Software schreiben, und was die Devs dann abliefern, nutzt dann wer?

Nein, Stretch, das aktuelle stable, wird zu oldstable, bei dem nur noch Sicherheitslücken gefixt werden. Testing, d. h. Buster, wird zu stable. Der Weg ist Sid -> Testing -> Stable -> Oldstable (-> Oldoldstable). Das hat was mit Testroutinen zu tun, und zwar ganz massiv.

Die offiziellen Debian Repos sind für diese konkrete Software keine gute Quelle.
Sofern du dir sicher sein kannst, dass die Software, die du einsetzt, nicht aus ihren Repos Kernkomponenten des Systems antastet, kannst du ein Fremdrepo einbinden.

Süß. "cherry picked commits" aus der unveröffentlichten 3.0.5, die es noch in den Buster Freeze geschafft haben.
Ja, sowas kommt raus, wenn du für die nächsten 2,5 Jahre Software maintainen willst, die ein Verfallsdatum wie unbehandelte Kuhmilch hat. Dann nimmst du dir das Neueste und hoffst, dass die Probleme in den nächsten 2,5 Jahren nicht so astronomisch werden würden, wie sie es wären, wenn du die aktuelle Veröffentlichung nutzt, die ja schon älter ist. Das Problem ist die Software an der Stelle, und der Entwicklungstrend, nicht das Debian, denn das läuft seit mittlerweile 20 Jahren mit diesem Releasezyklus und wird deshalb auch auf ziemlich vielen Servern eingesetzt (neben SLES und RHEL, bei denen es übrigens nicht viel anders läuft; wir setzen beide Systemtypen auch bei uns im Team ein, und ich kann dir sagen, dass ein SLES 11.4 nur noch mit viel Überredungskunst zum Beispiel TLS 1.3 spricht, und das ist KEIN moving target).

@Metal_Warrior zu die PHP Entwickler sollen "PHP Rewrite-DOT-zero EOL Edition" benutzen, weil der OS-Distributor nur das liefert.:
Debian Stable liefert üblicherweise kein EOL-Zeug aus, sofern nicht die Entwickler Kuhmilch produzieren, die schneller schlecht wird, als du Buildchain sagen kannst.
Der Knackpunkt bei PHP aus den offiziellen Repos der PHP-Entwickler war, dass die irgendwann die libcrypt des Systems (in diesem Fall Oldstable, weil die Kunden-Entwickler, die das System eingesetzt haben, genauso agile arbeiten, aber zu blöd sind, ihr eigenes fucking System zu kennen) ersetzt haben, und insofern MASSIV ins Betriebssystem eingegriffen haben, was dann natürlich zu einem inkonsistenten Abhängigkeitsbaum geführt hat und apt aus guten Gründen alles weitere verweigert hat. Ja, ich hab das beim Upgrade gelöst bekommen, hat nur 2 Stunden gedauert und hat vermutlich auch dem ein oder anderen dieser saublöden Entwickler den Code zerschossen, weil ich dann nämlich nicht mehr PHP-nightly als Repo drin hatte, sondern PHP-debian-stable. Das ist grassierende Inkompetenz bei den Entwicklern gewesen, und zwar sowohl auf Kundenseite (man setzt kein Oldstable ein, wenn man mit aktuellem Code arbeiten will) als auch auf PHP-Devs-Seite (man liefert als Entwickler keine System-Kernkomponenten aus, und zwar NIE!), wenngleich unsere Kunden der Auslöser für den Fuckup waren.

Wenn du glaubst, das ist nen singulärer Vorfall, guck dir das mal an: https://www.folio.org/
Build agile on Ubuntu Xenial (Release: April 2016), kommt daher mit Debian Stretch (Release: Juni 2017) nicht zurecht.

Der Punkt, um das nochmal ganz deutlich zu sagen, ist Folgender: Agile Builds sind mit stabilen Betriebssystemen oder IT-Sicherheit nicht vereinbar. Hört auf, agile Scheiße zu schreiben - Instabilen unsicheren Quatsch gibts genug da draußen.

Und für denjenigen, der jetzt sagt, das wäre auf Clients ja kein Problem: Wenn einer deiner 200 Abhängigkeiten-Entwickler irgendeinen Fehler baut oder sein Paket irgendeinem Malware-Entwickler gibt, und auf einen Schlag massiv Daten aus dem System abfließen oder der Code auf einmal eine Tür öffnet, dann ist das ein Problem.

"Aber so funktioniert OpenSource - tausende Entwickler schreiben, und du kannst dir alles anschauen."
Ja und nein. FOSS als Konzept sieht vor, dass du VOR dem Build den kompletten Code ansehen kannst, und dir daher sicher sein kannst, dass nicht irgendjemand Scheiße gebaut hat. Wie funktioniert das in einem agilen Umfeld? Gar nicht. Im Moment des Builds wird der ganze Schmodder vom Entwickler gezogen. Selbst wenn du dann den Build abbrichst, dir den ganzen Code durchsiehst, keinen Fehler findest, und dann den Build nochmal anstößt, zieht er von 20 Abhängigkeiten eine neuere Version, die du NICHT gesehen hast. Brichst du dann wieder ab, liest den Scheiß, stößt den Build wieder an und hast wieder neuen Code, ... Merkst du was? Das komplette Konzept am Arsch, weil du gegen ein moving target arbeitest. Damit ist das Argument "Du kannst ansehen, was du dir da zusammenbaust" nicht mehr gegeben, und damit die Säule, auf der sich die Sicherheit aufbaut, beim Teufel. Rocketchat (der Server) zum Beispiel zieht irgendwas um die 50-100 Abhängigkeiten. Ist ja nur eine Server-Software, was soll da schon schief gehen... Ach, und weil wir mittlerweile unüberschaubar kurze Releasezyklen haben, arbeiten wir am Besten mit Kubernetes und Docker, wenn da was gehackt wird, kann man es einfach wegschmeißen und neu aufsetzen. Vorausgesetzt, wir erkennen das. Und dieser Hacker bricht nicht aus dem Container aus und infiziert den Host. Dann sind wir nämlich am Arsch, weil alles so komplex ist, dass es nicht mehr wartbar ist. Wird schon nicht passieren? http://lmgtfy.com/?q=mongodb+hacked
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #54
@Kenobi
Wenn du Debian einsetzt, solltest du dich drauf einstellen, dass der Programmierstil, den du grade verfolgst, nicht sauber funktionieren wird.
Okay? Ich weiß nicht, inwiefern man bei mir überhaupt schon von Programmierstil sprechen kann, stehe da ja noch ziemlich am Anfang. Aber ich schreibe in C++, was ja schonmal prinzipiell ziemlich portabel ist. Dass ich jetzt im vorliegenden Fall beim Compilieren statisch linken musste, war ja alles andere als gewünscht und in erster Linie ein Workaround, der wiederum weder mit der C::B-Version aus den offiziellen Repos, noch mit der aktuellsten Version, die ich jetzt gerade installiert habe, nötig sein sollte. Abhängigkeiten haben meine Binarys ansonsten bislang keine, weil ich keinerlei außergewöhnlichen Librarys einbinde.

Insofern verstehe ich gerade nicht ganz, worauf sich deine Aussage konkret bezieht.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Kenobi van Gin: Programmierstil im Sinne von "Ich brauch immer den neusten Scheiß"

C++ wird nativ natürlich unterstützt (ich würde schätzen, der Großteil aller Pakete wurde in der Sprache geschrieben), und es gibt soweit ich das so sehe eine metrische Tonne an IDEs für jeden Geschmack, auch in Debian. Insofern: Warum C::B?
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #58
DevC++ gut gefallen...

Hatte ich auch mal probiert. Kann mich nicht mehr erinnern, ob mir das am Ende gefallen hat. Da gabs allerdings das letzte Update 2014, wenn ich das richtig sehe. Da frage ich mich dann doch, ob da nicht irgendwann auch Funktionalität flöten geht. Zum Beispiel wenn es um neue Sprachstandards geht.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Kenobi van Gin: C++ ist uralt, da kommt nicht jedes halbe Jahr ein neuer Standard. Hält sich eh keiner dran, da die meisten Leute das schon jahrzehntelang so nutzen. Insofern ist auch ältere Buildsoftware nicht problematisch, und auch die Compiler-Optionen dürften sich nicht so stark geändert haben bzw. so stark optimiert worden sein, dass dir das groß was rausreißt. Zumindest dann nicht, wenn du es mal mit NodeJS oder ähnlichem vergleichst.
 

Kenobi van Gin

Brillenschlange

Registriert
14 Juli 2013
Beiträge
3.620
Ort
.\
  • Thread Starter Thread Starter
  • #60
Okay, sehe ich ein. Obwohl Code::Blocks zumindest laut Compiler-Einstellungen bis C++17 unterstützt. Naja, wie auch immer. Mir gefällt halt auch die IDE gut und in dem Sinne spricht ja auch nix dagegen. Werde mir dann bei Gelegenheit vielleicht nochmal Debian angucken und dort dann ggf. das inoffizielle Repo hinzufügen. Ist eben doch angenehmer, als Updates ggf. per Hand installieren zu müssen. (Das ist jedenfalls schonmal eine Sache, die ich bei Linux sehr angenehm finde.)
 
Oben