Login
Newsletter
Werbung

Thema: Bassi: Dev versus Ops - Linux-Paketsysteme in der Krise

76 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Jan2 am Fr, 18. August 2017 um 11:18 #

http://www.fedora-blog.de/flatpak-und-snap-sind-nicht-die-loesung-
des-problems-sondern-machen-es-noch-schlimmer

Für Entwickler vielleicht möglich, ich als Anwender möchte aber nicht auf rpm- oder deb-basierende Verwaltung verzichten.

Jan

[
| Versenden | Drucken ]
  • 0
    Von auch als entwickler am Fr, 18. August 2017 um 13:14 #

    Dem verlinkten Artikel kann ich nur zustimmen.
    Für mich ist der OpenSUSE Buildservice momentan die Lösung für die Unterstützung vieler Distributionen.

    Evtl. könnte ich mir als Entwickler, der hauptsächlich auf Qt setzt vorstellen, dass die Qt Bibliotheken schon von der Distribution vorinstalliert wären.
    Das würde allerdings voraussetzen, dass "meine-anwendung" mit einer Qt Version gebaut wurde, die kleiner als die installierte Qt Version ist.
    Und es setzt voraus, dass die betreffenden Qt Versionen binär (aufwärts) kompatibel sind.

    Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre.
    Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.

    [
    | Versenden | Drucken ]
    • 0
      Von who knows am Fr, 18. August 2017 um 14:47 #

      „Oder, das ich in meinem Paket ein "Requires" auf die entsprechende Qt Version drin wäre.
      Was zur Folge hätte, dass mehrere Qt Versionen installiert wären.“

      Genau das fängt man sich mit Flatpak, Snappy und Co. Dazu kommt noch der Aufwand, die verwendeten Bibliotheken selbst aktuell zu halten. Vorausgesetzt man will das...
      Flatpak, Snappy und Co haben nur einen Vorteil, wenn der Entwickler Bibliotheken verwendet, die so selten genutzt werden, dass die Distribution sie nicht von sich aus enthält. Man könnte diese Biblitheken, dann auch als separates Paket anbieten, riskiert damit aber Kollisionen mit den Paketen anderer Anbieter. Hier wäre ein alternativer Ansatz, die Information über solche Bibliotheken über die Distributoren mit anderen Entwicklern zu teilen. Also das, was open source ausmacht: Kooperation. Dazu muss aber die zugrunde liegende Denkweise in die Köpfe so mancher Entwickler dringen...

      who knows

      [
      | Versenden | Drucken ]
      • 0
        Von Rudi123 am Fr, 18. August 2017 um 15:02 #

        ... oder man schmeißt diese einzelne, selten verwendete Bibliothek einfach direkt mit ins Anwendungspaket. Das Problem lässt sich auch ohne Flatpak, Snappy & Co. lösen - womit man alles nur unglaublich viel schlimmer macht.

        [
        | Versenden | Drucken ]
        • 0
          Von who knows am Fr, 18. August 2017 um 17:48 #

          Wenn diese Bibliothek ausserhalb des Suchpfades für Bibliotheken, also zum Beispiel unter /opt/... landet und damit für andere Anwendungen „unsichtbar“ bleibt, ist das natürlich auch eine Lösung.

          who knows

          [
          | Versenden | Drucken ]
    0
    Von Anonymous am Fr, 18. August 2017 um 13:16 #

    Die gleichen Probleme haben klassische Pakete auch:
    Spotify: libcef.so (121,6 MB, ist ja im Prinzip Chrome, gilt für jede Electron basierte Anwendung)
    AfterShot 3: Qt5 (insgesamt über 140 MB an Bibliotheken, einige sind jedoch bestimmt auch AfterShot 3 spezifisch)

    Sobald etwas nicht in der Distribution vorausgesetzt werden kann, muss es vom Software-Entwickler ausgeliefert werden. Und in RHEL/CentOS (aber auch Fedora), als RPM basierte Distributionen, fehlt so einiges.

    Drittanbieter Repositories sind auch keine Lösung, weil RPMFusion nicht mit Russian Fedora oder UnitedRPMS zusammenarbeiten wird.
    Ob die Pakete überhaupt ausreichend aktualisiert werden, ist noch eine ganz andere Frage (bei Ubuntu Universe, zum Beispiel, sieht es ja eher schlecht aus). Abgesehen davon hat man damit das gleiche Problem:

    die Anwender damit zwingt darauf zu vertrauen, das Dritte – von denen man im Grunde nicht weiß, wie vertrauenswürdig sie sind – ihre Hausaufgaben machen!
    Wobei: Wenn der Entwickler nicht vertrauenswürdig ist, warum sollte man dessen Software nutzen?

    [
    | Versenden | Drucken ]
0
Von Nix and Guix FTW am Fr, 18. August 2017 um 12:01 #

Ich würde mir als Lösung eher etwas wie die Paketmanager Nix oder Guix wünschen.

[
| Versenden | Drucken ]
1
Von Criena am Fr, 18. August 2017 um 12:15 #

Entwickler mögen reproduzierbare Umgebungen wollen, gleichzeitig ist ihnen aber auch das Bibliothekenmanagement ein Graus. In Kombination mit Flatpak und Co. führt das meines Erachtens dann dazu, dass die PCs der Anwender mit Dutzenden veralteten Versionen ein und derselben Bibliothek verseucht sein werden. Der Entwickler einer Anwendung will sich um seine Anwendung kümmern, nicht zusätzlich noch regelmäßig prüfen ob seine verwendeten third-party Bibliotheken Sicherheitslücken aufweisen und entsprechende Updates des Anwendungspakets herausgeben.

Da gefällt mir das derzeitige System diesen Job den Distributionen zu überlassen bedeutend besser. Die Distributoren reagieren im Fall der Fälle flott und das komplette System ist mit einem einzigen Update wieder "sicher".

Optimal ist auch dieses System nicht, aber für mich persönlich das derzeit beste verfügbare.

[
| Versenden | Drucken ]
  • 0
    Von auch als entwickler am Fr, 18. August 2017 um 13:01 #

    Auch als Entwickler meine ich, dass wir bei RPM und DEB bleiben sollten.
    Wenn ich auf dem OpenSUSE Buildservice meine sourcen.tar.gz + die notwendigen SPEC Dateien für RPM und DEB zur Verfügung stelle,
    kann ich auf dessen Farm für alle relevanten Distributionen/Versionen Bauen.

    [
    | Versenden | Drucken ]
    • 0
      Von Klaus R. am Fr, 18. August 2017 um 13:24 #

      Als Entwickler kann ich meinen Vorrednern nur anschließen. deb und rpm müssen bleiben - von mir aus Flatpack zusätzlich für die weniger versierten Anwender. Aber Flatpack alleine ist sicher keine sinnvolle Lösung und würde den Linuxgedanken zunichte machen. Da könnte man dann auch bei Windows bleiben, das hat die dann entstehenden Krankheiten bereits.

      [
      | Versenden | Drucken ]
      0
      Von DrMcCoy am Fr, 18. August 2017 um 19:33 #

      Hmm, also die Idee von OBS find ich eigentlich richtig gut... Aber die Realisierung nervt. Ich hatte das mal zeitweilig für eines meiner Projekte ausprobiert, und irgendwie schmiss mir da OBS immer Steine in den Weg.

      Zum Beispiel: das Projekt benutzt Boost, und einige Boost-Libraries (Boost.Atomics, zB) sind in Ubuntu aus irgendeinem Grund im Universe-Repository. Universe ist aber in OBS nicht drin (und das laut der Mailingliste auch anscheinend absichtlich, wegen rechtlichen Fragen (Patente auf Codecs)). Also muss ich Boost selbst in OBS bauen. Wer Boost schon mal selbst kompiliert hat, weiß dass das Arbeit ist.

      Ebenso ist deren Skriptmagie, das aus Templates die "echten" Debian-/Ubuntu-Packetdateien zusammenwurschtelt doch etwas seltsam. Mir ist schon mehr als einmal vorgekommen, dass es genau das Falsche tut, und dann die Dateien kaputt sind und die Debianpackettools rummeckern.

      Wenn man ein existierendes Paket nur leicht ändern will, und sich das Sourcearchiv beim Paket bauen von OBS neu zusammenbauen lassen will, dann muss man auch komplett neu ein ganzes Set an diesen Templates anlegen. In den existieren Dateien passen ja dann die Checksummen nicht mehr, und ein Mix aus existierenden Packetdateien und Templates geht nicht.

      Lange Rede, kurzer Sinn: mich als Entwickler hat OBS richtig genervt. Ich hab da ziemlich viel Zeit reinstecken müssen, um am Ende Distributionspakete rauszubekommen und ein halbes Jahr kamen neue Releases der Distributionen, und ich hab im Projekt die Bibliothekenversionen angehoben, und die Arbeit mit OBS war für die Katz.

      [
      | Versenden | Drucken ]
    0
    Von #! am Fr, 18. August 2017 um 18:06 #

    Reproduzierbar ist die Entwicklung auch, indem man Rolling Release verwendet.
    Für den Desktop und mit ausreichender Internetbandbreite funktioniert das.


    Für den Mehraufwand sorgen doch Distributionen, die veraltete Libs bereitstellen.

    [
    | Versenden | Drucken ]
    0
    Von naja am Sa, 19. August 2017 um 08:26 #

    Genau das Thema Sicherheit ist der Punkt bei dem klassische Paketsysteme die Nase weit vorn haben. Flatpak & Co bringen nur neue Probleme in Sachen Sicherheit mit sich. Auch was genutzte Bandbreite betrifft. Man stelle sich nur mal vor die Qt-Bibliothek bekommt ein Sicherheitsupdate. Man hat 10 Anwendungen installiert die die Qt-Bibliothek verwenden. Beim klassischen Paketsystem muss nur einmal Qt aktualisiert werden. Bei Flatpak & Co 10mal.

    [
    | Versenden | Drucken ]
1
Von Pulsnitzer am Fr, 18. August 2017 um 13:20 #

Na toll! Soll denn nun jeder Linux-User sich sein Zeuch selber zusammenfrickeln? Mannomann! Ich bin Anwender und wil das "Linux" einfach nur benutzen. So wie bisher und ich habe mit Deb, gerade als Metapaket/Treiberpaket/Browserpaket/etc. nur gute bis sehr gute Erfahrungen gemacht!

Deb = :up:
Rpm = kenn ich zuwenig

Konsole/Frickelei = :down:

[
| Versenden | Drucken ]
  • 0
    Von who knows am Fr, 18. August 2017 um 15:00 #

    Im Großen und Ganzen kann ich dir zustimmen.

    Deb und rpm sind aus Anwendersicht durchaus gleichzusetzen und werden von diesen im Allgemeinen nicht direkt verwendet. Zum Einsatz kommen Frontends, von denen Du offensichtlich die Grafischen bevorzugst. Aber lass dir gesagt sein: Die CLI-Frontends sind auch recht komfortabel. Wer sich etwas mit apt, zypper und Co befasst hat, wird dies bestätigen können. Für alle anderen bleibt immer noch das distributionsabhängige GUI-Frontend. Über diese kann man natürlich trefflich streiten. Das läuft am Ende aber in der Regel auf Geschmacksfragen hinaus...

    who knows
    Edit: typo, Wortwahl

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Aug 2017 um 15:02.
    [
    | Versenden | Drucken ]
1
Von hallo am Fr, 18. August 2017 um 13:36 #

Sind weitere Systeme neben systemd nicht ein "sterbendes Modell"?

[
| Versenden | Drucken ]
0
Von hoschi am Fr, 18. August 2017 um 13:41 #

http://kmkeen.com/maintainers-matter/index.html

Die Arbeit des Maintainers erfordert Fleiss, weil Ordnung halten immer Handarbeit ist und kontinuierlich erfolgen muss. Und genau das macht es Anwendern so angenehm, dieser Fleiss führt zu schlanken und leicht wartbaren Systemen. Irgend jemand muss die Arbeit machen und sie dem Entwickler aufzuhalsen, weil der einmal mit dem Maintainer nicht zufrieden war, ist nicht die Lösung sondern eine altes Windowsproblem (DLL-Hell?). Eine Paketverwaltung sorgt dafür, das dynamische Libraries den Hauptspeicher und Festspeicher entlasten und Sicherheitslücken gobal behoben werden.

Flatpak kann vieles vereinfachen im Gebiet der Sicherheit und Anwendungsdistribution, aber Maintainerarbeit auf Entwickler zu verlagern lässt die Arbeit nicht verschwinden. Anwendungsentwickler sind denkbar schlecht im kontinuierlichen Pflegen von Libraries, dann haben wir Sicherheitslücken. Und je mehr Flatpaks man installiert um so mehr Speicher geht verloren, weil die zwangsläufig häufig die gleichen Libraries mitliefern müssen. Ich habe als Entwickler gar keine Lust mich mit den Fixes JSONCPP zu beschäftigen, so lange die API-Stabil bleibt ist alles gut! Weder bin ich Admin, Datenbankadministrator noch Servicemitarbeiter - es gibt dafür mit gutem Grund eigene Berufe und Aufgabenbereiche (Devops sehe ich daher auch nicht als Lösung...).

Auch die Paketverwaltung hat ihre Problem, ist ein Paket mal nicht vorhanden wird das bequeme Leben sehr anstrengend - selbst wenn alle Abhängigkeiten erfüllt sind, kann man eigentlich nur Programmieren den einfachen Dreisatz zumuten (configre && make && make install). Das wirkt auf Windowsanwender dann erstmal anstrengend, gerade auf die Sorte "ich lade mir die Nvidia-Binärtreiber selbst herunter" - welche die Paketverwaltung also nicht verstanden haben.

Und am Ende eine Warnung:
Wer meint wild Flatpaks auf die Anwender loszulassen, erlebt sind zweites Windows (Viren) oder schlimmer - sein zweites Android (nix gepatched, alles offen wie eine Scheunentor). Paketverwaltungen sind eine Whitelist und die funktionieren ganz gut, man vertraut sowieso grundsätzlich der Distribution.

http://www.stickycomics.com/wp-content/uploads/update_for_your_computer.jpg
Linux ist bequem, ich verwende es weil Updates überwiegend angenehm sind.

Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Aug 2017 um 13:48.
[
| Versenden | Drucken ]
  • 0
    Von who knows am Fr, 18. August 2017 um 15:16 #

    Dem kann ich mich anschließen.
    Für Entwickler bleibt unter Verwendung des Paketmanagements nur der Mehraufwand, in allen zu unterstützenden Distributionen unter den kompatiblen Versionen der Wunschbibliothek, diejenige mit dem kleinsten Featureset herauszusuchen und auf Eignung für das eigene Projekt zu prüfen. Ist diese geeignet, so sollte auch damit entwickelt werden. Ist sie es nicht, könnten Flatpaks für einzelne Distributionen eine Lösung sein, aber wie wir alle wissen siegt am Ende die Faulheit / Gewinnmaximierung und oben genannter Mehraufwand wird gar nicht erst in Erwägung gezogen...

    who knows

    [
    | Versenden | Drucken ]
    0
    Von cs am Sa, 19. August 2017 um 18:11 #

    > altes Windowsproblem (DLL-Hell?)...

    Die DLL-Hell Problem existiert auf Windows schon seit mindestens 15 Jahren nicht mehr. So what's the point?

    [
    | Versenden | Drucken ]
    • 0
      Von skinnie am So, 20. August 2017 um 14:14 #

      Die DLL-Hölle unter Windows gibt es, seit es unter Windows DLL gibt. Aber offensichtlich muss ja unbedingt überall Windows kopiert werden. Ich will kein vermeintlich besseres Windows. Ich nutze Linux, weil ich Linux will und eben nicht Windows.

      Wenn immer mehr nur noch Windows kopiert wird, kann ich gleich bei dem Gefrickel aus Redmond bleiben, bzw. dorthin wieder zurückkehren. Ich bin froh, dass Linux eben nicht wie Windows ist, sondern sein eigenes Konzept verfolgt.

      [
      | Versenden | Drucken ]
      • 0
        Von cs am So, 20. August 2017 um 14:50 #

        Nochmal, deine Argumentation hinkt schon bei der Definition von DLL-Hölle. Die DLL-Hölle ergibt sich aus dem überschreiben von DLLs mit anderen gleichnamigen Libraries, die aber eine andere Schnittstellen-Spezifikation haben. Das führt zu nicht funktionierenden Anwendungen, Abstürzen etc. Bitte nochmal informieren, was die DLL-Hölle wirklich ist. Was du als solche bezeichnest hat eben nichts mit der DLL-Hölle zu tun.

        [
        | Versenden | Drucken ]
        • 0
          Von skinnie am So, 20. August 2017 um 15:02 #

          Ich habe 20 Jahre lang Windows (von Win95 bis Win7) genutzt und es wäre nicht das erste mal, dass sich, von Programmen parallel installierte, verschiedenen Versionen von DLLs beißen und Ärger machen. Das ist ebenso ein Teil der DLL-Hölle, wie das von dir beschriebene Problem.

          [
          | Versenden | Drucken ]
0
Von Rudi123 am Fr, 18. August 2017 um 14:25 #

Emmanuele Bassi wirft freudig alles durcheinander, mal spricht er aus Benutzer-, mal aus Entwicklersicht. Der Verweis auf die Paketverwaltungen diverser Programmiersprachen ist so ein Beispiel: Aus Sicht eines Nutzers sind diese vollkommen irrelevant. Sein Argument, dass Linux auf dem Desktop scheitere weil es zu wenige Pakete gebe, ist daher auch vollkommen unsinnig - kein Nutzer möchte die 528. Implementierung einer isArray()-Funktion für NodeJS herunterladen können. Nutzer möchten Anwendungen herunterladen und installieren, Libraries sind nur Mittel zum Zweck - und für mich als langjähriger Nutzer von Linux auf dem Desktop kann berichten, dass ich noch nie Probleme hatte meine gewünschte Anwendung in der Paketverwaltung zu finden. Das Argument geht an der Realität vollkommen vorbei.

Nichts desto trotz, wie die Libraries bereitgestellt werden ist dem Nutzer an und für sich egal, insofern spielt es auch keine große Rolle ob nun Snappy, Flatpak oder ein anderes, im Trend liegendes und gehyptes Konzept zum Einsatz kommt, oder die klassische Paketverwaltung der Distribution. Beides funktioniert. Es gibt nur zwei Dinge auf die versierte Nutzer achten: Belegt es nicht unnötig Speicherplatz und bekomme ich Sicherheitsaktualisierungen. Gerade aber bei diesen beiden elementaren Faktoren sind Snappy, Flatpak und wie sie alle heißen eine reine Katastrophe.

Insofern: Nein, hier gibt es keine Krise, zumindest nicht aus technischer Sicht. Snappy, Flatpak usw. sind eine dumme Idee.

[
| Versenden | Drucken ]
  • 1
    Von rem am Fr, 18. August 2017 um 17:56 #

    "Belegt es nicht unnötig Speicherplatz..."

    über wieviel speicher - hauptspeicher und festplatte - reden wir?

    [
    | Versenden | Drucken ]
    • 0
      Von Anonymous am Fr, 18. August 2017 um 20:17 #

      Spielt heute eh keine Rolle mehr, ob es nun 1 oder 20 GB sind, die auf der Platte liegen, und bei 4GB RAM ist es auch egal, ob nun 0,5 oder 2 davon belegt sind.

      Aber man muß ja was zum meckern haben :D

      [
      | Versenden | Drucken ]
      • 0
        Von Verfluchtnochmal am Fr, 18. August 2017 um 23:30 #

        Wegen Leuten wie dir ist unsere Hardware heute um ein vielfaches leistungsfähiger als vor 10 Jahren nur effektiv ankommen tut recht wenig

        Ahnungslose Deppen die Software zusammenstümpern und keine Ahnung von Optimierung haben

        Und das sagt dir jemand der seine über Jahre gepflegte Codebase im letzten Jahr großflächig optimiert hat und plötzlich um den Faktor 5 bis 25 leistungsfähiger bei weniger RAM Verbrauch ist

        [
        | Versenden | Drucken ]
        0
        Von blablabla233 am Sa, 19. August 2017 um 09:36 #

        Sag das mal dem Raspberrypi ob 0.5 oder 2 GB ram belegt sind ganz egal ist.
        Wer nicht optimiert kann auch gleich VW-Diesel-Motoren entwickeln.

        [
        | Versenden | Drucken ]
        • 0
          Von homer am Sa, 19. August 2017 um 10:05 #

          Wer nicht optimiert kann auch gleich VW-Diesel-Motoren entwickeln.
          Trotz des Skandals darf man VW-Entwicklern generell eine gewisse Entwicklungskompetenz bescheinigen (z.B. Weiterentwicklung von Unit Injector Systems mit VTG-Lader). Mit dem Vergleich zu den "Bloatware-Proggern" tust Du den VW-Ingenieuren unrecht.

          [
          | Versenden | Drucken ]
          • 0
            Von blablabla233 am Sa, 19. August 2017 um 18:47 #

            Stimmt, das Problem liegt wie fast immer eher beim Marketing und Management....die ING machen wohl wie überall einen guten Job (inklusive der IT)

            [
            | Versenden | Drucken ]
    0
    Von cs am Sa, 19. August 2017 um 17:31 #

    > Emmanuele Bassi wirft freudig alles durcheinander, mal spricht er aus Benutzer-, mal aus Entwicklersicht. Der Verweis auf die Paketverwaltungen diverser Programmiersprachen ist so ein Beispiel: Aus Sicht eines Nutzers sind diese vollkommen irrelevant.

    Auch Entwickler sind Anwender, von Programmiersprachen, Compilern, Buildsystemen, Tools, IDEs usw... und da ist die Frage wie sich solche Tools in heutige Distributionen integrieren, wenn sie selbst ein eigenes Pakagetmanagment mitbringen, schon berechtigt.

    > Sein Argument, dass Linux auf dem Desktop scheitere weil es zu wenige Pakete gebe, ist daher auch vollkommen unsinnig - kein Nutzer möchte die 528. Implementierung einer isArray()-Funktion für NodeJS herunterladen können.

    Hä? Was hat das nicht runterladen wollen der 528. NodeJS Funktion mit zu wenig Paketen von Endanwendersoftare zu tun. Der Satz folgt der Logik einer Chewbacca-Verteidigung.

    > Belegt es nicht unnötig Speicherplatz ... Gerade aber bei diesen beiden elementaren Faktoren sind Snappy, Flatpak und wie sie alle heißen eine reine Katastrophe.

    Gibt es dafür empirische Fakten?

    [
    | Versenden | Drucken ]
    0
    Von da-real-lala am So, 20. August 2017 um 13:22 #

    Die Krise von der Bassi spricht, hat wenig mit den Programmen zu tun, die aus der Community kommen. Es geht eher um die Programme, die dem Linux Desktop weiter zum Mainstream Erfolg verhelfen sollen.

    Die andere Zielgruppe sind Anwender, die z.B. gerne und dringend Version foo von Paket bar auf ihrem Debian oder Ubuntu LTS hätten, aber wissen, dass dies eine Menge Arbeit bedeuten würde, diese mal eben per Backports oder PPA zu bewerkstelligen.

    Da eignen sich AppImage, Flatpak, Snap gut. Wenn ich aber keine Distro wie Fedora oder Suse haben will, wo es normal ist, dass der Desktop oft abschmiert oder sich die Bugs häufen, will ich auch eine Distribution, die z.B. wie Debian eine extra Testinstanz ist. Manchmal braucht es eben ein paar extra Augen und objektive Entwickler, die die Fehler sehen, die im Upstream einfach keine Beachtung finden, weil die Arbeit an anderen Ecken zu groß ist.

    [
    | Versenden | Drucken ]
    • 0
      Von skinnie am So, 20. August 2017 um 14:24 #

      Wie kommst du darauf, dass bei Opensuse dauernd der Desktop abschmiert? Von welchem DE redest du überhaupt? Auch unter Opensuse hast du die volle Auswahl. Ich nutze z.B. seit XFCE und kann mich an keine Abstürze des DE erinnern.

      Mit Fedora habe ich keine Erfahrung, aber auch da hast m.W. die Wahl zwischen verschiedenen DEs. Und groß von ewigen Abstürzen der DE habe ich von Fedora auch nichts gelesen.

      Es lebe das Bashing.

      [
      | Versenden | Drucken ]
      • 1
        Von da-real-lala am So, 20. August 2017 um 22:21 #

        Es ist kein Bashing. Ich bin Hobby-Distrohopper und probiere gern jede Version der großen Distri aus. Opensuse weist nach meinem Geschmack zu viele Bugs auf im Vergleich zu Debian. Klar sind diese bei Xfce oder LXDE in einem deutlich geringeren Umfang da, als bei Gnome oder KDE, das ist ja auch bei Debian so. Opensuse ist, wie gesagt, für meinen Geschmack zu unausgereift. Fedora ebenso. Ich respektiere jedoch beide Distri sehr. Vielleicht seid ihr in eurer Community nicht so empfindlich was Bugs und vor allem nervige kleine Papercuts angeht, aber ich bevorzuge eben eine etwas abgehangene Distro.

        [
        | Versenden | Drucken ]
2
Von Anonymous am Fr, 18. August 2017 um 15:02 #

... möchte ich gerne mit verschiedenen Programmen arbeiten.
Es ist schon passiert, das ein Programm andere Libs haben möchte als ein anderes.
Dann bin ich als Normaluser machtlos; ich will weder skurile Verlinkungen setzen noch irgendwelche Kompilierungen vornehmen.

Plattenplatz ist heute eh kein Problem mehr.

Da hätte ich am Liebsten monolithische Programme, die statisch gelinkt sind und keine Abängigkeiten nach aussen haben!

Ausserdem sind mir die Distributoren manchmal einfach zu langsam, was dazu führt, dass ich viele Fremdquelle nutze.

Was noch ganz wichtig ist, ich kann ein monolithisches Programm jahrelang nutzen, und bin nicht auf den guten Willen der Entwickler angewiesen, ihre Programme an neue Libs anzupassen!

Mir würde es ausreichen, wenn eine Distribution ein minimales System zur Verfügung stellen würde, und die Software-Verwaltung einfach nur Links zu den Programmen beinhaltet.

Gruß Jörn

[
| Versenden | Drucken ]
  • 2
    Von Portable-Fan am Fr, 18. August 2017 um 16:26 #

    Hallo Jörn,

    das sehe ich ganz genauso und manchmal möchte man sogar mit verschiedenen Versionen von ein und
    demselben Programm arbeiten oder ein Programm vom USB-Stick oder Netzlaufwerk auf verschiedenen
    Rechnern benutzen, ohne es erst groß installieren zu müssen.
    Unter Windows habe ich da jede Menge Programme als Portable-Apps genutzt. Für Linux habe ich mich
    daher gefreut, dass immer mehr Programme als Appimage angeboten werden. Ein einziges File, einfach
    als ausführbar markieren und starten! Um Updates für die Programme muss man sich im Moment noch selber
    kümmern, aber bei manchen kommt wenigstens eine Meldung, wenn eine neuere Version verfügbar ist (z.B. Etcher).
    Hier wäre es natürlich schön, wenn noch inkrementelle Updates mit eingebaut würden.

    Gruß Stefan

    [
    | Versenden | Drucken ]
    • 0
      Von skinnie am So, 20. August 2017 um 14:41 #

      Mit Verlaub, aber wenn du das Konzept von Windows so toll findest, warum nutzt du es nicht? Linux soll gar kein vermeintlich besseres Windows sein, sondern eine echte Alternative mit einem eigenständigen Konzept. Mir geht daas immer mehr umsichgreifende Nachäffen von Windows einfach nur noch gehörig auf den Senkel.

      Außerdem gibt es auch unter Linux von vielen Programmen eine portable Version (Neusprech Ääppimmitsch). Die schiebst du einfach auf einen USB-Stick und kannst sie ohne Installation auf jedem Rechner mit Linux verwenden - sofern dies nicht aus Sicherheitsgründen unterbunden ist. Dies ist auch mitnichten eine Erfindung aus Redmond.

      Ich würde schon aus Sicherheitsgründen nicht wollen, dass jeder mit einem USB-Stick bewaffnet, irgendwelche Programme auf meinem Rechner ausführen kann.

      [
      | Versenden | Drucken ]
      • 0
        Von Ano am Mo, 21. August 2017 um 15:38 #

        >> ... eine echte Alternative mit einem eigenständigen Konzept.

        Aber was soll der Sinn an einem eigenständigen _schlechten_ Konzept sein? Ich möchte gerne einige wenige Programme auf dem jeweils neusten Stand haben und mein OS dafür 3-4 Jahre lang nur mit Sicherheitsupdates versehen wissen.

        Ist unter Linux aktuell kaum möglich. Entweder ich bin mit LTS oder Debian stable in der Zeit eingefrohren für alle Programme oder ich darf jedes halbe bis Jahr die Axt an das OS legen.

        Kein gutes Konzept auf dem Desktop.

        [
        | Versenden | Drucken ]
        • 0
          Von Verfluchtnochmal am Di, 22. August 2017 um 17:57 #

          Ja und weil du möchtest soll ich mir anständige Distributionen versauen lassen? Bei Fedora denken sie ja jetzt schon laut drüber nach langfristig Desktopanwendungen NUR MEHR als Flatpak zu integrieren - Ach leckt mich mit Verlaub am Arsch, nach 11 Jahren Fedora am Desktop brauch ich das so dringend wie einen Kropf

          [
          | Versenden | Drucken ]
        0
        Von Portable-Fan am Mo, 21. August 2017 um 18:14 #

        Hallo skinnie,

        das höre ich jetzt das erste mal, dass portable Anwendungen das Konzept von Windows sein sollen...
        Und das die das erfunden haben, hab ich auch nirgends behauptet. Ich glaube, das Prinzip ist schon sowas von
        uralt, wahrscheinlich musste man schon die allerersten Programme nur starten und nicht erst installieren...

        Ich finde es halt praktisch, auch mehrere, verschiedene Versionsstände einer Software parallel auf dem Rechner
        zu haben und starten zu können. Kommt bei mir sogar des öfteren vor...

        Du hast bei Dir auf dem Rechner das Ausführen von Appimages unterbunden? Oder nur das mounten von
        USB-Datenträgern?

        Viele Grüße,

        Stefan

        [
        | Versenden | Drucken ]
      0
      Von Verfluchtnochmal am So, 20. August 2017 um 15:10 #

      Wenn du das Konzept von Windows willst installiere Windows, wenn du das Konzept von OSX willst kauf dir einen Mac - So einfach ist das und genau darum gibt es verschiedene Betriebssysteme

      Ich bin 2006 finally zu Linux gewechselt WEGEN DEM PAKETMANAGER genauso wie er ist

      [
      | Versenden | Drucken ]
      • 0
        Von Big_M am Mo, 21. August 2017 um 12:43 #

        Nein, du(!) verwendest Linux offenbar wegen dem Paketmanager, es soll aber auch Leute geben die Linux primär nutzen wegen der GPL, oder wegen der Konfigurierbarkeit, oder aus sonstigen Gründen. Und diese "dann geh doch nach drüben" Mentalität nervt nur.

        [
        | Versenden | Drucken ]
        • 0
          Von Verfluchtnochmal am Mo, 21. August 2017 um 13:48 #

          Und was ändert das an der Tatsache dass es der falsche Weg ist wenn Linux sich anbiedert weil "Die anderen machen das auch so" anstatt verdammt nochmal ein eigenständiges OS zu sein dass du so nehmen kannst wie es ist oder eben nicht das richtige für dich ist?

          Wenn jemand meint man müsse den zentralen Paketmanager der sicherstellt dass wenn eine Library ein Sicherheitsproblem hat EIN Update selbiger automatisch ALLE Anwendungen die diese benutzen fixt korrupieren nur weil er meint mehrere Versionen einer Anwenung zu wollen oder eine ältere/neuere Version dann hört bei mir jedes Verständnis auf

          Es ist schlicht und ergreifend nicht möglich alle Vorteile ohne die jeweiligen Nachteile in einem System zu vereinigen und dieses dauernd nach "potentiellen Usergruppen" schauen und denen in der Arsch kriechen ist der falsche Weg weil deswegen noch lange nicht gesagt ist dass die umsteigen du aber gute Chancen hast die bestehende Userbase masiv zu nerven bis hin zu vergraulen und dann hast du genau gar nichts gewonnen

          [
          | Versenden | Drucken ]
          • 0
            Von Big_M am Mo, 21. August 2017 um 18:41 #

            Naja, du sagst es ja selbst, jedes System hat seine eigenen Vor- und Nachteile. Ich spüre bei dir jetzt bisschen die Angst dass die jetzigen Paketsysteme in Zukunft aufgegeben werden könnten, aber ehrlich gesagt glaube ich das nicht. Sie haben ja definitiv ihre Vorteile, und deshalb werden sie auch weiter bestehen. Es ist meiner Ansicht nach aber nicht falsch Alternativen zu entwickeln, und diese zu testen. Und das ist ja einer der großen Vorteile von Linux, seine Diversität. Wer weis, vielleicht gibts in ein par Jahren RPM, DEB und(!) Flatpak basierte Distributionen. Vielleicht etabliert sich Flatpak und co. auch nur für Anwendungssoftware. Oder gar nicht. Aber so lange es Leute gibt die eine reine RPM/DEB Distribution wollen, solange wirds die auch geben. :)

            [
            | Versenden | Drucken ]
          0
          Von Ano am Mo, 21. August 2017 um 15:40 #

          Zustimmung!

          [
          | Versenden | Drucken ]
    0
    Von Verfluchtnochmal am So, 20. August 2017 um 15:18 #

    Schon mal auf die Idee gekommen dass Linux einfach das falsche OS für dich ist?

    Linux hat niemals den Anspruch gestellt für JEDEN das perfekte OS zu sein oder irgendein anderes existierendes OS nachzuäffen

    Genau das gleiche unterstelle ich den Schwachköpfen von Entwicklern die ernsthaft erwägen die größte Stärke einer Linux Installation nämlich ein zentraler und konsistenter Paketmanager zu korrupieren

    Was diese ganzen Deppen vor allem mit ihrem einer theoretischen Zielgruppe nachzulaufen übersehen ist dass sie eine praktische Zielgruppe die Linux aktiv benutzt und sich
    dafür entschieden hat weil es genau so ist wie es ist vor den Kopf stoßen

    [
    | Versenden | Drucken ]
0
Von Potz Blitz am Fr, 18. August 2017 um 16:21 #

Bei Programmen für die sich kein Maintainer findet, oder bei denen der Entwickler selbst eine Installationsquelle bereitstellen möchte, sind Flatpack & Co. m.E. eine sehr gute Lösung. Und ich denke, dass das für ziemlich viele Programme zutrifft. Aber die Vorteile eines Paketsystems wie apt oder yum sind natürlch auch nicht von der Hand zu weisen. Dies betrifft meines Erachten insbesondere den Bereich der Standardsoftware. Natürlich gibt es da Überschneidungen. Aber wenn ein Programm per Paket oder Flatpack verfügbar ist, finde ich das auch nicht schlimm. Im Gegenteil, insbesondere neue Versionen können so leichter verfügbar gemacht und getestet werden. Letztlich sollte immer der Anwender entscheiden dürfen, aus welcher Quelle er installieren möchte. Die Freiheit der Wahl, war schon immer einer der Hauptvorteile von Linux und freier Software.

[
| Versenden | Drucken ]
  • 0
    Von Rudi123 am Fr, 18. August 2017 um 16:46 #

    Dem schließe ich mich an. Allerdings gibt es aktuell Bestrebungen "echte" Paketverwaltungen wie deb und rpm abzuschaffen und mit Snappy, Flatpak & Co. zu ersetzen. Das halte ich für äußerst problematisch. Beides kann koexistieren und, vorausgesetzt Snappy, Flatpak & Co. sind mehr als nur ein aktuell überhyptes und im Trend liegendes Thema, muss koexistieren.

    [
    | Versenden | Drucken ]
    • 0
      Von Potz Blitz am Fr, 18. August 2017 um 18:42 #

      ... gibt es aktuell Bestrebungen "echte" Paketverwaltungen wie deb und rpm abzuschaffen ...

      Warten wir mal ab. Nichts wird so heiß gegessen, wie's gekocht wurde. Sollte eine Distribution ganz auf die traditionelle Paketverwaltung verzichten, würden ihr vermutlich einige Anwender davonlaufen.

      [
      | Versenden | Drucken ]
1
Von oldmcdonald am Fr, 18. August 2017 um 16:29 #

Der Mensch mag ja recht mit seiner Kritik haben, aber das System der Paketverwaltungen als veraltet darzustellen, ist geradezu grotesk.
Ganz im Gegenteil: Sowohl Apple als auch Microsoft eifern mit ihren App-Stores den traditionellen Linux-Distributionen mit ihren Paketverwaltungen nach! Man muss die Betriebssysteme Android geradezu umprogrammieren, um Pakete außerhalb des dafür vorgesehenen Repositoriums "Play-Store" nutzen zu können.
Ein zentraler Ort, an dem alle Programme zu haben sind, ist sowas von im Trend! Fertich!

[
| Versenden | Drucken ]
  • 1
    Von Anonymous am Fr, 18. August 2017 um 16:42 #

    Was Du das schreibst, ist völlig nicht richtig!
    Der Playstore von Google ist einfach nur eine Sammelstelle für Apps, die rudimentär auf Viren und andere Schadsoftware geprüft wird.
    Google selber macht gar nichts mit den Apps.

    Bei Apple sieht es genauso aus.

    Mit Paketen a'la Linux hat das NULL zu tun, eher mit Snaps etc!

    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Fr, 18. August 2017 um 17:07 #

    Was Du das schreibst, ist völlig nicht richtig!
    Der Playstore von Google ist einfach nur eine Sammelstelle für Apps, die rudimentär auf Viren und andere Schadsoftware geprüft wird.
    Google selber macht gar nichts mit den Apps.

    Bei Apple sieht es genauso aus.

    Mit Paketen a'la Linux hat das NULL zu tun, eher mit Snaps etc!

    [
    | Versenden | Drucken ]
    0
    Von cs am Sa, 19. August 2017 um 17:08 #

    > Ganz im Gegenteil: Sowohl Apple als auch Microsoft eifern mit ihren App-Stores den traditionellen Linux-Distributionen mit ihren Paketverwaltungen nach!

    Die Appstores von Apple, Android und Co. und die Paketmanager der Distributionen sind zwei paar Schuhe. Das eine folgt einem Downstream-Modell und das andere ein Upstream-Modell. Wenn man nicht weiß wovon man redet, sollte man es lieber sein lassen...

    [
    | Versenden | Drucken ]
1
Von auch als entwickler am Fr, 18. August 2017 um 16:44 #

der bestimmen könnte, wo es lang geht,

dann könnten wir eine Liste von Bibliotheken anlegen,
die auf jeder Distribution installiert sein MÜSSEN.
In der Liste würden auch die Versionsstände der Bibliotheken festgelegt.
(Die Liste wird jedes Jahr geupdated und die alten Versionen bleiben auch verfügbar)

Dann könnten wir ganz einfach (schlanke) DMG Dateien für die Benutzer anbieten, mit der Sie sich Ihre app auf den Desktop schieben.

Aber das wird es bei Linux NIE geben.

[
| Versenden | Drucken ]
  • 1
    Von wolfgang-p am Fr, 18. August 2017 um 19:37 #

    Moin,

    da sprichst du genau ein zentrales Problem von Linux an! Es gibt keine gemeinsame Vision, jeder macht sein eigens Ding. Das ist der eigentliche Grund, weshalb es mit Linux auf dem Desktop nix wirdl

    [
    | Versenden | Drucken ]
    0
    Von Gibt es am Sa, 19. August 2017 um 13:31 #

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

    [
    | Versenden | Drucken ]
    • 0
      Von cs am Sa, 19. August 2017 um 16:55 #

      Ich find es immer wider lustig wie diese alten Kamellen rausgehölt werden. Über die LSB wurde schon genug diskutiert. Kurz zusammengefasst: Die LSB ist tot und konnte nie wirklich das einlösen was sie verspricht.

      [
      | Versenden | Drucken ]
      • 0
        Von who knows am Sa, 19. August 2017 um 22:55 #

        Immer diese selbsternannten Experten...
        Du scheinst auch zu glauben, man müsse ein Gerücht nur oft genug verbreiten, damit es wahr wird. In keinem deiner Kommentare lieferst Du irgend etwas anderes als Behauptungen.
        https://wiki.linuxfoundation.org/lsb/lsb-50

        who knows

        [
        | Versenden | Drucken ]
        • 0
          Von da-real-lala am So, 20. August 2017 um 13:26 #

          LSB ist echt putzig! Z.B. hält sich Google Chrome ja der Einfachheit halber an die LSB in Fedora. Resultat: Als Abhängigkeit wurde z.B. Qt3 installiert, weil die Version des LSB Standards, der da benutzt wurde, eben dies vorschrieb. Und das bei einem Programm, das nichts mit Qt3 zu tun hat. :)

          [
          | Versenden | Drucken ]
          • 0
            Von XYZ am So, 20. August 2017 um 19:57 #

            Das ist nicht ganz richtig.

            Chrome verlangt (oder verlangte ... doch dazu später) nur das Paket "lsb". Fedora hat dort qt3 als Abhängigkeit mit beigefüht.

            Neuere Versionen von Chrome (unstable) benötigen jetzt nur noch redhat-lsb-core, was die Abhängigkeiten um ein Vielfaches reduziert hatte. Auch wurden zahlreiche statische Libraries nun abgelöst, was die Installation (von ursprünglich ca 300mb) auf nur noch 150mb verkleinert.

            Weiterhin konnte man ein leeres Stub SPEC generieren, wo man einfach ein "lsb" paket mit 0 Files erstellte... Das hat für Chrome damals immer gereicht und es wurde nix weiteres installiert.

            [
            | Versenden | Drucken ]
            0
            Von who knows am So, 20. August 2017 um 20:37 #

            „Z.B. hält sich Google Chrome ja der Einfachheit halber an die LSB in Fedora. Resultat: Als Abhängigkeit wurde z.B. Qt3 installiert, weil die Version des LSB Standards, der da benutzt wurde, eben dies vorschrieb.“

            1).
            Das ist offensichtlich ein Fehler des Maintainers von Chrome.
            2).
            Deine Behauptung ist falsch. Das Aktuelle Chrome-Paket hat in seiner Abhängigkeitsliste LSB >= 4.0
            Verfügbar ist LSB5, was auch installiert wird.
            LSB5 hat in seinen Abhängigkeiten Teile von QT4

            - Dein Wissensstand ist veraltet.
            - Die Bequemlichkeit eines externen Maintainers führt zu unsinnigen Abhängigkeiten. Das ist kein Fehler der LSB.
            - Qt4 ist aus Anwendersicht nicht veraltet. Neue Qt-Basierte Projekte sollten natürlich die Version 5 verwenden.

            [
            | Versenden | Drucken ]
          0
          Von cs am So, 20. August 2017 um 14:38 #

          Na dann schau dir die LSB doch mal an. Die aktuelle Version ist über 2 Jahre alt. Qt ist immer noch auf Version 4. Von der Aktualität anderer Teile möchte ich erst gar nicht sprechen. Entwicklungen wie Wayland und andere APIs scheinen an der LSB komplett vorbeizugehen. Dazu kommen ungenügende Testsuiten. Man kann Programme bauen, die die zwar die LSB Konformität bestehen, aber trotzdem immer noch nicht Distributionsunabhängig sind.
          Debian und Ubuntu unterstützen die LSB nur noch stark eingeschränkt. Wenn du als Entwickler mit solchen Limitationen leben musst, kannst du es auch gleich sein lassen. Wer heute Upstream Entwicklung für Linux machen will, geht sowieso den AppImage oder Flatpak Weg. Die LSB hat - wenn überhaupt noch - eine extrem rudimentäre Bedeutung.

          [
          | Versenden | Drucken ]
          • 0
            Von who knows am So, 20. August 2017 um 20:55 #

            „Na dann schau dir die LSB doch mal an. Die aktuelle Version ist über 2 Jahre alt. Qt ist immer noch auf Version 4. Von der Aktualität anderer Teile möchte ich erst gar nicht sprechen. Entwicklungen wie Wayland und andere APIs scheinen an der LSB komplett vorbeizugehen. Dazu kommen ungenügende Testsuiten. Man kann Programme bauen, die die zwar die LSB Konformität bestehen, aber trotzdem immer noch nicht Distributionsunabhängig sind.“

            Das ist bei Industriestandards normal. Es werden nur etablierte und stabile Versionen aufgenommen. Darüber hinaus werden Standards auch nicht im Jahreszyklus aktualisiert. Man kann und sollte sich dort auch keine Schnellschüsse erlauben. Darüber hinaus definiert die LSB nur Mindestanforderungen.

            Und wieder heiße Luft:
            „Debian und Ubuntu unterstützen die LSB nur noch stark eingeschränkt.“

            https://wiki.debian.org/LSB
            https://lists.debian.org/debian-lsb/

            Noch mehr heiße Luft:
            „Wer heute Upstream Entwicklung für Linux machen will, geht sowieso den AppImage oder Flatpak Weg. Die LSB hat - wenn überhaupt noch - eine extrem rudimentäre Bedeutung.“

            Wie gehabt: Nichts als Behauptungen und diese zum Teil auch noch nachweislich falsch!

            [
            | Versenden | Drucken ]
            • 0
              Von cs am So, 20. August 2017 um 22:13 #

              Ach wie süß, ich hatte schon öfter mit Linux-Lappen wie dir zu tun. Viel Pseudowissen und Informationen die mal vor der Industrialisierung des Abendlandes aktuell waren. Check mal deine Fakten mein Herzchen...

              > Das ist bei Industriestandards normal. Es werden nur etablierte und stabile Versionen aufgenommen.
              > Darüber hinaus werden Standards auch nicht im Jahreszyklus aktualisiert.
              > Man kann und sollte sich dort auch keine Schnellschüsse erlauben.
              > Darüber hinaus definiert die LSB nur Mindestanforderungen.

              Aktuelle Entwicklungen macht nun kaum noch jemand mit Qt4. Du kannst Technologie von vorgestern nicht als aktuellen Stand der Dinge verkaufen. Dazu ist die Industrie viel zu schnell und kurzlebig. Wir reden hier von _moderner_ Deskop Software die distributionsunabhängig verteilt werden soll.

              > https://wiki.debian.org/LSB

              LOL, der verlinke Artikel wurde im Jahre 2009 das letzte mal aktualisiert und bezieht sich auf die Version 3.1. Willst du mich verscheißern?
              Mal was Aktuelleres für dich:
              https://en.wikipedia.org/wiki/Linux_Standard_Base#Limitations_on_Debian
              https://lwn.net/Articles/658809/

              Fakt ist, die LSB war nie wirklich beliebt bei Entwicklern. Gab sogar mal hier auf PL nen Artikel, warum Debian volle LSB Konformität aufgegeben hat: Es gab keine interessierten Maintainer für alle LSB Module. Such mal nach lsb deskop Paketen in ner aktuellen Ubuntu oder Debian Version...

              [
              | Versenden | Drucken ]
              • 1
                Von who knows am Mo, 21. August 2017 um 12:27 #

                „Ach wie süß, ich hatte schon öfter mit Linux-Lappen wie dir zu tun. Viel Pseudowissen und Informationen die mal vor der Industrialisierung des Abendlandes aktuell waren. Check mal deine Fakten mein Herzchen...“

                Das ist die typische Reaktion eines Trolles, dem die Argumente ausgehen. Du erinnerst mich an Tims Katze. Der dreht auch ständig die Implikationen um und behauptet dann Unfug.

                „Aktuelle Entwicklungen macht nun kaum noch jemand mit Qt4. Du kannst Technologie von vorgestern nicht als aktuellen Stand der Dinge verkaufen. Dazu ist die Industrie viel zu schnell und kurzlebig. Wir reden hier von _moderner_ Deskop Software die distributionsunabhängig verteilt werden soll.“

                Du drehst mir das Wort im Munde herum. Natürlich werden für neue Entwicklungen Bibliotheken verwendet, die einen möglichst langen Supportzeitraum haben. Das ist aber Entwicklersicht. Für Anwender ist Qt4 immernoch aktuell. Die „Industrie“ ist alles andere als kurzlebig. Das mag für die Hersteller von Livestyleartikeln wie zum Beispiel Smartphones gelten. So ziemlich alle anderen Bereiche - und hier rede ich von Anwendern - bevorzugen möglichst lange Supportzeiträume, denn wer ohne schwerwiegende Gründe ein Systemupgrade macht, der verschwendet einfach nur Zeit. Und bevor Du mir in gewohnter Trollmanier das Wort im Munde herumdrehst: Ich habe das Wort Upgrade verwendet - nicht Update. Das sind zwei paar Schuhe.

                „> https://wiki.debian.org/LSB“
                Warum sollten Debians Maintainer einen Artikel aktualisieren, der immer noch seine Gültigkeit hat. Und weil Du das genau weißt hast Du auch den zweiten Link auf die recht aktive Mailingliste unterschlagen. So etwas nennt man ein Zitat inhaltsverfälschend verkürzen. Das ist ein ausgesprochen schlechter Diskussionsstil, wie er von Trollen sehr gerne verwendet wird, da sie in der Regel ohnehin keine echten Argumente haben. Ich reiche also den zweiten Link nach:
                https://lists.debian.org/debian-lsb/

                „https://en.wikipedia.org/wiki/Linux_Standard_Base#Limitations_on_Debian
                https://lwn.net/Articles/658809/

                Fakt ist, die LSB war nie wirklich beliebt bei Entwicklern. Gab sogar mal hier auf PL nen Artikel, warum Debian volle LSB Konformität aufgegeben hat: Es gab keine interessierten Maintainer für alle LSB Module. Such mal nach lsb deskop Paketen in ner aktuellen Ubuntu oder Debian Version...“

                Da hast Du also zwei Artikel in denen auf einen Debian-Maintainer verwiesen wird, der ankündigt, den Support für LSB zu minimieren, da sich dafür kein Maintainer findet. Eine offizelle Stellungnahme auf Seiten des Debianprojektes lieferst Du nicht. Daraus folgere ich nur, das die Aktivität aufgrund von Personalmangel minimiert wurde. Ein Desinteresse von Entwicklern die LSB als Grundlage für die Paketauswahl zu verwenden erkenne ich daraus nicht. Gleiches gilt für Ubuntu. Außerdem wird im zweiten Artikel darauf verwiesen, dass das LSB-Package auf unstable verschoben wurde. Das geschah offensichtlich infolge des fehlenden Maintainers. Ein Abschied von der LSB sieht anders aus. Was Du oder die Autoren der Artikel dort hineininterpretieren ist in diesem Zusammenhang uninteressant. Deine persönliche Meinung zu äußern steht dir zu, nicht aber daraus auf die Allgemeinheit der Entwickler zu schließen und das dann als Tatsache zu verkaufen...
                Vielleicht solltest Du einen Blick hierauf werfen:
                https://www.linuxfoundation.org/members/corporate
                Dort ist unter Anderem auch Canonical gelistet.
                Bezüglich Qt5 / gtk3 möchte ich nocheinmal darauf hinweisen, dass die LSB Mindestanforderungen stellt. Allerdings befürchte ich, dass diese Aussage bei dir bereits kurz hinter dem Sehnerv auf einen für unangenehme Tatsachen undurchdringlichen Wall treffen wird...

                [
                | Versenden | Drucken ]
                • 0
                  Von cs am Mo, 21. August 2017 um 14:49 #

                  ROFL, benenn dich um in "'who knows' knows nothing".

                  Hättest du mal den lwn.net Artikel gelesen, speziell den Kommentarbereich, hättest du dir nicht die Finger wund schreiben müssen. Dort kommen Leute zu Wort, die _selbst_ an der LSB gearbeitet haben und sagen, dass die LSB zu viele Schwächen und Probleme hat und sich letztlich totgelaufen hat. Chronisch veraltet, mangelnde Unterstützung seitens der Distributionen, sind dort nur einige Sachen. Du nennst das dann in deinem Neusprech "Stellen von Mindestanforderungen", köstlich. Übrigens ist die Behauptung von "Mindest" so oder so schwachsinnig, denn das würde bedeuten Qt >= 4 (mindestens 4). Tut es aber nicht. LSB 5.0 sagt genau Qt == 4. Etwas anderes wird dort nicht definiert. In der Spec gibt es kein einzigen Symbol-Entry für Qt 5. Wie es sich mit der Relation "mindest" verhält, sollte man schon wissen...

                  Ich zitier hier einfach mal, weil du es mit dem Lesen nicht so hast:

                  No one seems interested in checking those details in the Debian packages, he noted, adding that "I've held an LSB BoF last year at DebConf, and discussed src:lsb with various people back then, and what I took back was 'roughly no one cares'." Just as importantly, though, the lack of interest does not seem to be limited to Debian:

                  The crux of the issue is, I think, whether this whole game is worth the work: I am yet to hear about software distribution happening through LSB packages. There are only _8_ applications by 6 companies on the LSB certified applications list, of which only one is against LSB >= 4.

                  Ein wirklich lebendiger Standard!

                  Ein Projekt, dass angeblich so wichtig für Linux ist und von der Linux-Foundation durch all seine Goldmember gefördert wird, findet keine Maintainer mehr in Debian/Ubuntu um es aktuell zu halten und schiebt dann die meisten LSB-Module auf die Resterampe?!
                  http://www.pro-linux.de/news/1/22814/
                  debian-ist-nicht-mehr-konform-zur-linux-standard-base.html
                  Du bist wirklich gut darin, dir die Realität mit Euphemismen schön zu quatschen. Offizieller als "fliegt raus" geht halt nicht mehr. In der Praxis gibt es kaum noch Bedarf für die LSB.

                  Oder wie viele LSB 5.0 zertifizierte Distributionen/Software gibt es denn? Ein Tipp, hier findest du sie nicht:
                  https://wiki.linuxfoundation.org/en/LSB_Distribution_Status

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von who knows am Di, 22. August 2017 um 01:40 #

                    „ROFL, benenn dich um in "'who knows' knows nothing".“
                    Das kommt dabei heraus, wenn man keine Argumente mehr hat...

                    „Hättest du mal den lwn.net Artikel gelesen, speziell den Kommentarbereich, hättest du dir nicht die Finger wund schreiben müssen. Dort kommen Leute zu Wort, die _selbst_ an der LSB gearbeitet haben und sagen, dass die LSB zu viele Schwächen und Probleme hat und sich letztlich totgelaufen hat. Chronisch veraltet, mangelnde Unterstützung seitens der Distributionen, sind dort nur einige Sachen.“

                    Autsch. Dort sind zwei Kommentare, deren Autoren von sich behaupten als individual bzw im Kommitee an der LSB mitgearbeitet zu haben. Deine Interpretation des Textes ist sehr großzügig - um es freundlich zu formulieren.

                    „Du nennst das dann in deinem Neusprech "Stellen von Mindestanforderungen", köstlich. Übrigens ist die Behauptung von "Mindest" so oder so schwachsinnig, denn das würde bedeuten Qt >= 4 (mindestens 4). Tut es aber nicht. LSB 5.0 sagt genau Qt == 4. Etwas anderes wird dort nicht definiert. In der Spec gibt es kein einzigen Symbol-Entry für Qt 5. Wie es sich mit der Relation "mindest" verhält, sollte man schon wissen...“

                    Und hier hast Du dich komplett vergaloppiert. Mindestanforderung bedeutet hier, das die gelisteten Pakete in der Distribution enthalten sein müssen. Das bedeutet weder, dass diese Pakete installiert sein müssen, noch schließt es die Existenz neuerer Versionen aus. Möglicherweise solltest Du an deinem Hang die Implikationen umzudrehen arbeiten...

                    „Ich zitier hier einfach mal, weil du es mit dem Lesen nicht so hast:

                    No one seems interested in checking those details in the Debian packages, he noted, adding that "I've held an LSB BoF last year at DebConf, and discussed src:lsb with various people back then, and what I took back was 'roughly no one cares'." Just as importantly, though, the lack of interest does not seem to be limited to Debian:

                    The crux of the issue is, I think, whether this whole game is worth the work: I am yet to hear about software distribution happening through LSB packages. There are only _8_ applications by 6 companies on the LSB certified applications list, of which only one is against LSB >= 4.

                    Ein wirklich lebendiger Standard!“

                    Und in typischer Trollmanier hast Du mal wieder ein Zitat sinnentstellend verstümmelt. Ich ergänze:

                    Furthermore, the LSB continues to grow; the 4.1 release (the most recent when Debian "jessie" was released) consisted of "1493 components, 1672 libs, 38491 commands, 30176 classes and 716202 interfaces," he said. No one ...

                    Das lässt tief blicken...

                    „Ein Projekt, dass angeblich so wichtig für Linux ist und von der Linux-Foundation durch all seine Goldmember gefördert wird, findet keine Maintainer mehr in Debian/Ubuntu um es aktuell zu halten und schiebt dann die meisten LSB-Module auf die Resterampe?!“

                    Gibt es diesen Satz auch in verständlich?
                    Was meinst Du mit „Projekt“?
                    Mögliche Interpretationen:
                    LSB: Warum sollte ein Projekt seine Module innerhalb einer Distribution selbst auf „die Resterampe“ verschieben?
                    Debian: Welche „Goldmember“ sollten das sein?
                    https://www.debian.org/partners/

                    Und was die „Resterampe“ angeht:

                    Debian Unstable (also known by its codename "Sid") is not strictly a release, but rather a rolling development version of the Debian distribution containing the latest and greatest packages which have been introduced into the Debian system. If you are a hardcore developer or tester you should use this release. If you are a power user you might also consider using Debian Testing. The best practices described below are applicable to testing users as well.

                    Da Du dich hier selbst ins Knie geschossen hast, darfst Du die Quelle auch selbst suchen...

                    „http://www.pro-linux.de/news/1/22814/
                    debian-ist-nicht-mehr-konform-zur-linux-standard-base.html“

                    Das ist bedauerlich, aber auch nur eine Folge der
                    fehlenden Maintainer. Zitat aus dem verlinkten Artikel:

                    Debian hat die Konformität zur Linux Standard Base aufgegeben. Die Gründe, die aus einer Diskussion auf Debians Entwicklerliste hervorgehen, sind ein weitgehendes Desinteresse an diesem Standard im Projekt.

                    Dir sollte eigentlich klar sein, dass „Desinteresse“ und „Ablehnung“ zwei verschiedene Begriffe sind...

                    „Du bist wirklich gut darin, dir die Realität mit Euphemismen schön zu quatschen. Offizieller als "fliegt raus" geht halt nicht mehr. In der Praxis gibt es kaum noch Bedarf für die LSB.“

                    Wenn da irgendwo „fliegt raus“ stünde müsste ich dir zustimmen. Da dem aber nicht so ist, kommen von dir wieder nur Behauptungen und heiße Luft...

                    „Oder wie viele LSB 5.0 zertifizierte Distributionen/Software gibt es denn? Ein Tipp, hier findest du sie nicht:
                    https://wiki.linuxfoundation.org/en/LSB_Distribution_Status“

                    In der Tat, da haben die Webdesigner seit 2008 tief und fest geschlafen...
                    This page was last modified on 18 January 2008, at 15:47.

                    Eine aktuelle Liste findet man hier:

                    http://www.linuxfoundation.org/lsb-cert/productdir.php?by_lsb

                    Aber google zu befragen ist dir vermutlich zu schwer. Oder hat das Resultat dir einfach nicht gefallen und Du präsentierst mal wieder ein Ergebnis, das völlig veraltet ist, aber besser in dein Weltbild passt...

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von cs am Di, 22. August 2017 um 15:25 #

                      Autsch. Dort sind zwei Kommentare, deren Autoren von sich behaupten als individual bzw
                      im Kommitee an der LSB mitgearbeitet zu haben. Deine Interpretation des Textes ist sehr großzügig
                      - um es freundlich zu formulieren.

                      Es sind sogar 3: Einer war bei der LF angestellt, einer im Kommitee als er bei Cannonical beschäftigt war und einer als "Private Individual".
                      Beim sinnverstehenden Lesen warst du offenbar noch nie gut. Ich zitiere mal einige Auszüge, weil du das ja nicht schaffst:


                      ... The LSB has had these problems for years.

                      The crux of the problem is that the LSB is a trailing standard and that it has (or had, I honestly can't say for certain if this is still the case) a heavy corporate interest.
                      This creates a situation where the LSB is always REACTING to the changing Linux distro universe, which means it can never, really, be relevant as it is always just a bit out of date.
                      In turn, this creates problems for distros wanting to be LSB compliant as they, essentially, have to have these backwards shims in place to keep the LSB checkers happy.

                      ... On paper, this sounds good. However, in practice it's absolutely miserable.

                      The only solution to these problems is to ditch the "LSB by committee" approach and, instead, have the LSB be semi auto-magickally generated based upon what REAL distros are doing.

                      Anyway, while it makes me sad to see the LSB fall further into obscurity (it really was a good idea and had noble goals) this doesn't exactly surprise me because it was something
                      easily predictable as far back as 2008.

                      weiter als Bestätigung dazu...


                      Yep. I was heavily involved in the LSB as a private individual way back when. And I felt it was addressing the wrong target.
                      ...
                      LSB was completely unrealized value. The challenge is that if a vendor produces an LSB-using binary, they *still* have to test across each distribution on which they intend to
                      be used
                      and face a support burden if a customer installs it on a random other distro that happens to be LSB-certified.

                      Das hat nix mit großzügiger Interpretation zu tun, sondern hier wird nur festgestellt, dass die LSB schon lange nicht mehr das leistet, was sie vorgibt zu leisten.


                      Furthermore, the LSB continues to grow; the 4.1 release (the most recent when Debian "jessie" was released) consisted of "1493 components,
                      1672 libs, 38491 commands, 30176 classes and 716202 interfaces," he said. No one ...
                      Das lässt tief blicken...

                      Ja, das lässt wirklich tief blicken. Wie geht der Satz "No one ..." weiter und inwiefern relativiert das mein Zitat?
                      Wenn du auch noch den vorherigen Abstatz gelesen hättest, wüsstes du, dass dein Zitat negativ vom Autor konotiert ist,
                      weil bei dieser schier wachsende Anzahl an Schnittstellen/Symbolen keiner mehr die Muse zeigt sie zu checken.
                      Es gibt schlicht kein Interesse und der Aufwand lohnt sich im Vergleich zu niedrigen Adaptionsrate von Anwendungssoftware, die LSB konform sind, auch nicht.

                      Summa Summarum, Leseverständnis ist bei dir ne klatte 6!

                      Hier noch ein paar weitere Artikel:
                      Linux-Magazin
                      und
                      Golem

                      Zitat:

                      "... Damit kann die LSB 5.0 bereits jetzt als veraltet betrachtet werden."
                      Das war 2015. Bis heute sind die meisten Distributionen - wenn überhaupt - sogar max. auf 4.1.

                      Und hier hast Du dich komplett vergaloppiert. Mindestanforderung bedeutet hier,
                      das die gelisteten Pakete in der Distribution enthalten sein müssen. Das bedeutet weder,
                      dass diese Pakete installiert sein müssen, noch schließt es die Existenz neuerer Versionen aus.
                      Möglicherweise solltest Du an deinem Hang die Implikationen umzudrehen arbeiten...

                      Ja klar, du kannst alles mögliche auf deiner Kiste installiert haben oder eben auch nicht.
                      Die LSB selbst kann aber nur Kompatibilität _BIS_ zu einem bestimmten Versionsstand von einem Set an APIs garantieren.
                      Deine Anwendung kann kein höheres API Level nutzen, als der Standard vorgibt. Machst du es trotzdem, bist du nicht mehr voll kompatibel zu den Vorgaben des Standards.
                      Wenn sich ein 12 Jähriger im Mediamarkt ein Spiel kaufen, dann steht da auf der Packung immmer etwas wie:

                      Mindesanforderungen: ab Windows 7, Intel Core i3, min. 2 GB RAM, NVIDIA GeForce blablabla, ab DirectX 10

                      Wenn der Rechner aber max. nur DirectX 9 unterstützt, kann er es offenbar nicht spielen.
                      Bei Mindestanforderung spricht man von Anforderungen der Anwenungssoftware an die Hardware bzw. Middleware. Umgekehrt kann eine Middleware (zu der auch die LSB gehört) nur _bis_ zu dem installierten Versionsstand Kompatibilität garantieren.
                      Selbst Kids haben das Konzept Mindestanforderung verstanden. Du offenbar nicht!
                      Wenn ich nur DX 9 hab, laufen nicht automatisch auch höhere Versionen auf meiner Kiste. Will ich ne modernere Anwendung bauen, die z.B. Qt 5 verwendet, bekomm ich die nie LSB 5.0 konform,
                      da ich Schnittstellen nutze, die die LSB nicht spezifiziert. Der Konformitätstest schlägt fehl, weil nur eine Kompatibilität mit Qt 4 sichergestellt werden kann.
                      Deine Verwendung des Begriffs Mindestanforderung ist deshalb komplett widersinnig.
                      Auch das Problem des "veraltet seins" wurde in diesem Kontext schon in einem obigen Zitaten aufgegriffen.

                      http://www.linuxfoundation.org/lsb-cert/productdir.php?by_lsb
                      Die einzige LSB 5.0 Distribution hier ist EulerOS V2.0. Wo sind denn die anderen relevanten LSB 5.0 Distributionen? Fedora, Debian/Ubuntu + Derivate, Suse, Kali, Arch usw. sind es nicht.
                      Offenbar gibt es kein großers Interesse mehr an aktueller LSB Konformität. Und umgekehrt, wieviel aktuell LSB zertifizierte Software gibt es denn?

                      Das ist bedauerlich, aber auch nur eine Folge der
                      fehlenden Maintainer. Zitat aus dem verlinkten Artikel:
                      Debian hat die Konformität zur Linux Standard Base aufgegeben. Die Gründe,
                      die aus einer Diskussion auf Debians Entwicklerliste
                      hervorgehen, sind ein weitgehendes Desinteresse an diesem Standard im Projekt.
                      Dir sollte eigentlich klar sein, dass „Desinteresse“ und „Ablehnung“ zwei verschiedene Begriffe sind...

                      Na, was denn nun? Erst waren es doch nur die fehlenden Maintainer, jetzt ist es wieder fehlendes Interesse? Fehlende Maintainer und fehlendes Interesse an einer Sache sind zwei unterschiedliche Dinge. Im Artikel ist klar von "lack of interest" und nicht von "lack of maintainers" die Rede!
                      Fassen wir zusammen:

                      • Ein Standard für den sich niemand interessiert,

                      • chronisch veraltet ist,

                      • eine der wichtigsten Distributions-Familien, die sich nicht mehr Konform zu diesem Standard verhält,

                      • so gut wie keine Distribution, die aktuelle LSB-konformität anstrebt

                      • Wenig Anwendungungen die sich an diesen Standard orientieren,

                      macht diesen Standard für Entwickler und Nutzer genau wie relevant?

                      „Oder wie viele LSB 5.0 zertifizierte Distributionen/Software gibt es denn? Ein Tipp, hier findest du sie nicht:
                      https://wiki.linuxfoundation.org/en/LSB_Distribution_Status“
                      In der Tat, da haben die Webdesigner seit 2008 tief und fest geschlafen...
                      This page was last modified on 18 January 2008, at 15:47.

                      Ja, bei der LSB schlafen sehr viele Leute, nicht nur die Webdesigner...

                      Ich dachte erst, dass bei dir Starrsinn und Rechthaberei ne besonders armselige Allianz eingegangen sind.
                      Inzwischen bin ich aber überzeugt, dass es sogar noch viel schlimmer bei dir ist: Du bist schon im Stadium präseniler Renitenz.

                      [
                      | Versenden | Drucken ]
0
Von Trux am Fr, 18. August 2017 um 22:13 #

Die Vorteile von AppImage, Snappy und Flatpak sehe ich ausschließlich in folgenden Bereichen. Für poprietäre Anbieter, die auch in einer heterogenen Distributionslandschaft von Linux garantieren möchten, dass ihre Anwendung absolut gleich läuft.
Kommerzielle IoT kann mittels Snappy updates bekommen.
Und es könnte so manche freien Anwendung auf diese Weise auch mehr beta Tester erreichen.

Es gibt aber keinen Grund das bewährte Paketsystem abzuschaffen. Solle man dies tun, wird man sehen, dass DLL-Hell, Addware und Spyware die automatischen Folgen sein werden.

Ich kann nur hoffen, das Comunity Distributionen wie Debian und Arch Linux bei ihren bewährten Maintainer Strukturen bleiben und den Rest in Ruhe abwarten.
Denn schliesslich basiert Sicherheit auch auf einem Vertrauensmodell zwischen Menschen.
Die neuen Formate haben hier keine Struktur die das ersetzen könnte.

[
| Versenden | Drucken ]
0
Von Shalok Shalom am Fr, 18. August 2017 um 23:01 #

.. bauen sie alle auf Halblösungen statt auf Lösungen wie Habitat zu setzen ^-^

Die Geschichte wiederholt sich

[
| Versenden | Drucken ]
0
Von jb_ am Sa, 19. August 2017 um 22:03 #

Ich finde die Entwicklung von snap, Flatpak etc. eigentlich ziemlich cool, möchte aber auch nicht auf die Paketverwaltung verzichten.

Meine Erwartungen an ein System gehen dahin, dass ich ein solides Grundsystem haben möchte, wolle alle systemnahen Tools bereitgestellt werden, auch Compiler usw.. Allerdings möchte ich die Möglichkeit haben neueste Software nutzen zu können, wie z.B. Natron, Blender, verschiedene Browser, oder die neusten PHP/Apache/nginx Versionen. So was kann ich mir sehr gut vorstellen als snap Paket zu nutzen. Oder wenn ich mal kurz einen anderen Desktop ausprobieren möchte, ist doch viel praktischer ein geschnürtes Paket zu haben, was man auch wieder schnell entsorgen kann.

Wegen den doppelten Abhängigkeiten in den einzelnen Paketen könnte man ja gut Abhilfe schaffen, mit einem Dateisystem welches De-duplizieren beherrscht.

[
| Versenden | Drucken ]
mehr CI
0
Von anfredus am So, 27. August 2017 um 11:26 #

Schon mal was von CI gehört?

Richtig, jeder Commit ein neuer Build.

Paketieren ist nur beim ersten Mal das Problem, weil man die Guidelines einhalten muss.

[
| Versenden | Drucken ]
0
Von Stefan K. am Fr, 1. September 2017 um 11:30 #

"Vielleicht war das Festhalten an diesen Paketsystemen eine der wesentlichen Ursachen für den Mangel an Software und damit für den Misserfolg des Linux-Desktops."

Misserfolg verstehe ich so, dass sehr viele User einen Linux-Desktop probiert und sich dann doch umentschieden haben.

Ich sehe allgemein eher die seltene Verbreitung des Linux-Desktops. Wobei das kein Problem oder Misserfolg in diesem Sinne ist.
ich persönlich kenne viele Linux (Server) Admins, die folgerichtig Linux zum Arbeiten benutzen. Alle anderen lassen sich von Windows nerven ;)
GNU/Linux ist doch eher ein Server OS .. folglich kann man es mit Windows nicht vergleichen, weil selbiges doch eher ein Frontend OS für Leute ist, die eine graphische Oberfläche -brauchen- ... Admins brauchen zur Not keine GUI .. telnet/ssh bzw. Konsolenkabel reichen zur Not auch.

Gruß
STK

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung