Hallo Liste, von Zeit zu Zeit habe ich meine Monitor mit einem Spyder2 und DisplaCal kalibriert. Nach dem Upgrade auf leap 15.4 ist mir aufgefallen, dass es DisplayCal nicht mehr für diese Version gibt. Es gibt zwar unter https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/[1] ein Community Paket. Dies kann ich aber nicht installieren, da mir python2-numpy fehlt. # rpm -ivh --test DisplayCAL-3.8.9.3-3.2.x86_64.rpm error: Failed dependencies: python2-numpy >= 1.0 is needed by DisplayCAL-3.8.9.3-3.2.x86_64 Liest hier jemand mit der hier Abhilfe kennt? Gruß Herbert -------- [1] https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/
Am 13.02.2023 um 16:32 schrieb Herbert Albert:
Hallo Liste,
von Zeit zu Zeit habe ich meine Monitor mit einem Spyder2 und DisplaCal kalibriert. Nach dem Upgrade auf leap 15.4 ist mir aufgefallen, dass es DisplayCal nicht mehr für diese Version gibt. Es gibt zwar unter
https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/
ein Community Paket. Dies kann ich aber nicht installieren, da mir python2-numpy fehlt.
# rpm -ivh --test DisplayCAL-3.8.9.3-3.2.x86_64.rpm error: Failed dependencies: python2-numpy >= 1.0 is needed by DisplayCAL-3.8.9.3-3.2.x86_64
Liest hier jemand mit der hier Abhilfe kennt?
Gruß
Herbert
Das ging hier Nov/Dez letzten Jahres hier durch die Liste Daran kann sogar ich mich noch erinnern obwohl das Thema mich nicht interessiert. Also, wer suchet der findet Manfred
Am Montag, 13. Februar 2023, 16:39:01 CET schrieb Manfred Kreisl:
Am 13.02.2023 um 16:32 schrieb Herbert Albert:
Hallo Liste,
von Zeit zu Zeit habe ich meine Monitor mit einem Spyder2 und DisplaCal kalibriert. Nach dem Upgrade auf leap 15.4 ist mir aufgefallen, dass es DisplayCal nicht mehr für diese Version gibt. Es gibt zwar unter
https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/
ein Community Paket. Dies kann ich aber nicht installieren, da mir python2-numpy fehlt.
# rpm -ivh --test DisplayCAL-3.8.9.3-3.2.x86_64.rpm
error: Failed dependencies: python2-numpy >= 1.0 is needed by DisplayCAL-3.8.9.3-3.2.x86_64
Liest hier jemand mit der hier Abhilfe kennt?
Gruß
Herbert
Das ging hier Nov/Dez letzten Jahres hier durch die Liste
Daran kann sogar ich mich noch erinnern obwohl das Thema mich nicht interessiert. Also, wer suchet der findet
Manfred Hallo Manfred,
habe ich gefunden. Doch für Leap 15.4 wird keine Lösung, außer vielleicht flatpak angeboten. Doch mit flatpak habe ich mich noch nicht auseinander gesetzt und wer weiß, was ich mir da mit einem Mischbetrieb einhandle. Oder ist flatpak parallel betreibbar und für sich autark Na ja, war mal mutig und habe via Discover das central repository of flatpak application hinzugefügt, mich Kilometer lang nach unten durchgescrollt und DisplayCal installiert. Die Software läuft. Die Ergebnisse der Kalibrierung liegen nun in $HOME/.var/app/net.displaycal.DisplayCAL/ und werden auch gleich installiert. Zumindest zeigt das systemsetting -> Farbkorrekturen so an. Nur der Prozess in der Prozesstabelle verwirrt mich etwas /app/bin/python /app/bin/displaycal unter / gibt es kein /app. Ist das python-like? Gruß Herbert
Am 13.02.2023 um 19:40 schrieb Herbert Albert:
Am Montag, 13. Februar 2023, 16:39:01 CET schrieb Manfred Kreisl:
Am 13.02.2023 um 16:32 schrieb Herbert Albert:
Hallo Liste,
von Zeit zu Zeit habe ich meine Monitor mit einem Spyder2 und DisplaCal kalibriert. Nach dem Upgrade auf leap 15.4 ist mir aufgefallen, dass es DisplayCal nicht mehr für diese Version gibt. Es gibt zwar unter
https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/
ein Community Paket. Dies kann ich aber nicht installieren, da mir python2-numpy fehlt.
# rpm -ivh --test DisplayCAL-3.8.9.3-3.2.x86_64.rpm
error: Failed dependencies: python2-numpy >= 1.0 is needed by DisplayCAL-3.8.9.3-3.2.x86_64
Liest hier jemand mit der hier Abhilfe kennt?
Gruß
Herbert
Das ging hier Nov/Dez letzten Jahres hier durch die Liste
Daran kann sogar ich mich noch erinnern obwohl das Thema mich nicht interessiert. Also, wer suchet der findet
Manfred Hallo Manfred,
habe ich gefunden. Doch für Leap 15.4 wird keine Lösung, außer vielleicht flatpak angeboten. Doch mit flatpak habe ich mich noch nicht auseinander gesetzt und wer weiß, was ich mir da mit einem Mischbetrieb einhandle. Oder ist flatpak parallel betreibbar und für sich autark
Na ja, war mal mutig und habe via Discover das central repository of flatpak application hinzugefügt, mich Kilometer lang nach unten durchgescrollt und DisplayCal installiert. Die Software läuft. Die Ergebnisse der Kalibrierung liegen nun in $HOME/.var/app/net.displaycal.DisplayCAL/ und werden auch gleich installiert. Zumindest zeigt das systemsetting -> Farbkorrekturen so an.
Nur der Prozess in der Prozesstabelle verwirrt mich etwas /app/bin/python /app/bin/displaycal
unter / gibt es kein /app. Ist das python-like?
Nein, das ist so wie Flatpack & Co arbeitet. So recht im Detail kenn ich mich damit auch nicht aus, aber für mich ist Flatpack eine 'VM' für ganz Arme, Docker Container für Arme und dann KVM & Co für die Helden (Also bitte nicht gleich hauen :D) Alle 3 Varianten haben quasi ihr eigenes Root Filesystem, und das siehst du halt in der Prozesstabelle Manfred
On 13.02.23 19:53, Manfred Kreisl wrote:
Am 13.02.2023 um 19:40 schrieb Herbert Albert:
unter / gibt es kein /app. Ist das python-like?
Nein, das ist so wie Flatpack & Co arbeitet. So recht im Detail kenn ich mich damit auch nicht aus, aber für mich ist Flatpack eine 'VM' für ganz Arme, Docker Container für Arme und dann KVM & Co für die Helden (Also bitte nicht gleich hauen :D) Alle 3 Varianten haben quasi ihr eigenes Root Filesystem, und das siehst du halt in der Prozesstabelle
Wer sich das dahnterliegende Filesystem näher anschauen mag, kann das mit nsenter -m -t <pid der anwendung> Viele Grüße Ulf
Am Montag, 13. Februar 2023, 22:48:53 CET schrieb Ulf Volmer:
On 13.02.23 19:53, Manfred Kreisl wrote:
Am 13.02.2023 um 19:40 schrieb Herbert Albert:
unter / gibt es kein /app. Ist das python-like?
Nein, das ist so wie Flatpack & Co arbeitet. So recht im Detail kenn ich mich damit auch nicht aus, aber für mich ist Flatpack eine 'VM' für ganz Arme, Docker Container für Arme und dann KVM & Co für die Helden (Also bitte nicht gleich hauen :D) Alle 3 Varianten haben quasi ihr eigenes Root Filesystem, und das siehst du halt in der Prozesstabelle
Wer sich das dahnterliegende Filesystem näher anschauen mag, kann das mit
nsenter -m -t <pid der anwendung>
Viele Grüße Ulf Hallo Ulf,
schon der Start einer Applikation, wie z. B. DisplayCal ist mehr als kryptisch /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=displaycal net.displaycal.DisplayCAL Bisher einfach nur "displaycal" und fertig. Was müsste ich den bei displacal angeben? nsenter -m -t net.displaycal.DisplayCAL und nsenter -m -t displaycal funktionieren nicht. Also, ob ich mich an das gewöhnen kann ...? Ich glaube so lange es sich vermeiden lässt. lasse ich bis auf unabdingbare Ausnahmen die Finger davon. Gruß Herbert
On 14.02.23 16:52, Herbert Albert wrote:
Am Montag, 13. Februar 2023, 22:48:53 CET schrieb Ulf Volmer:
nsenter -m -t <pid der anwendung>
schon der Start einer Applikation, wie z. B. DisplayCal ist mehr als kryptisch /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=displaycal net.displaycal.DisplayCAL
Warum so kompliziert? Hier reicht ein flatpak run net.displaycal.DisplayCAL Und ein klickbarer Eintrag im Startmenu wird auch mitgeliefert.
Was müsste ich den bei displacal angeben? nsenter -m -t net.displaycal.DisplayCAL und nsenter -m -t displaycal funktionieren nicht.
Die PID der laufenden App! Also das, was pgrep displaycal ausspuckt. Oder gleich sudo nsenter -m -t $(pgrep displaycal) Viele Grüße Ulf
Am Dienstag, 14. Februar 2023, 17:35:42 CET schrieb Ulf Volmer:
On 14.02.23 16:52, Herbert Albert wrote:
Am Montag, 13. Februar 2023, 22:48:53 CET schrieb Ulf Volmer:
nsenter -m -t <pid der anwendung>
schon der Start einer Applikation, wie z. B. DisplayCal ist mehr als kryptisch /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=displaycal net.displaycal.DisplayCAL
Warum so kompliziert? Hier reicht ein
flatpak run net.displaycal.DisplayCAL
Und ein klickbarer Eintrag im Startmenu wird auch mitgeliefert.
Was müsste ich den bei displacal angeben? nsenter -m -t net.displaycal.DisplayCAL und nsenter -m -t displaycal funktionieren nicht.
Die PID der laufenden App! Also das, was
pgrep displaycal
ausspuckt.
Oder gleich
sudo nsenter -m -t $(pgrep displaycal)
Viele Grüße Ulf Hallo Ulf,
ich will das jetzt nicht weiter vertiefen, aber ~> pgrep displaycal 23445 :~> sudo nsenter -m -t 23445 -bash-5.1# oder ~> sudo nsenter -m -t $(pgrep displaycal) -bash-5.1# Anwendung vorher mit flatpak run net.displaycal.DisplayCAL gestartet. Bin wohl zu alt für flatpak. Gruß Herbert
On 14.02.23 17:55, Herbert Albert wrote:
ich will das jetzt nicht weiter vertiefen, aber ~> pgrep displaycal 23445 :~> sudo nsenter -m -t 23445 -bash-5.1#
Jau. Damit hast Du eine Shell in Deiner flatpak Umgebung und kannst weiter forschen. Z.B. zu Deiner Frage, woher Deine App stammt: ls -l /app/bin/displaycal Viele Grüße Ulf
Am Dienstag, 14. Februar 2023, 18:00:42 CET schrieb Ulf Volmer:
On 14.02.23 17:55, Herbert Albert wrote:
ich will das jetzt nicht weiter vertiefen, aber ~> pgrep displaycal 23445
:~> sudo nsenter -m -t 23445
-bash-5.1#
Jau. Damit hast Du eine Shell in Deiner flatpak Umgebung und kannst weiter forschen. Z.B. zu Deiner Frage, woher Deine App stammt:
ls -l /app/bin/displaycal
Viele Grüße Ulf na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden. Gruß Herbert
On 14.02.23 18:24, Herbert Albert wrote:
na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Ja.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden.
Dein Problem war doch, das DisplayCal nicht bzw. nicht brauchbar für 15.4 paketiert worden ist. Flatpak ist da die Lösung, die sich anbietet. Viele Grüße Ulf
Am Dienstag, 14. Februar 2023, 18:56:23 CET schrieb Ulf Volmer:
On 14.02.23 18:24, Herbert Albert wrote:
na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Ja.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden.
Dein Problem war doch, das DisplayCal nicht bzw. nicht brauchbar für 15.4 paketiert worden ist. Flatpak ist da die Lösung, die sich anbietet.
Viele Grüße Ulf ja, das stimmt. Solange sich das nur auf die eine Applikation, die ich eh nur sehr selten brauche, beschränkt, kann ich damit leben. Ich nur, dass sich flatpak nicht in künftigen Versionen von opensuse als Standard durchsetzt.
Gruß Herbert
Am 14.02.2023 um 19:13 schrieb Herbert Albert:
Am Dienstag, 14. Februar 2023, 18:56:23 CET schrieb Ulf Volmer:
On 14.02.23 18:24, Herbert Albert wrote:
na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Ja.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden.
Dein Problem war doch, das DisplayCal nicht bzw. nicht brauchbar für 15.4 paketiert worden ist. Flatpak ist da die Lösung, die sich anbietet.
Viele Grüße Ulf ja, das stimmt. Solange sich das nur auf die eine Applikation, die ich eh nur sehr selten brauche, beschränkt, kann ich damit leben. Ich nur, dass sich flatpak nicht in künftigen Versionen von opensuse als Standard durchsetzt.
Da kannst du sicher sein, dass das kommen wird. DAS wird die (traurige) Zukunft sein, Stichwort ALP(traum) :D Musst du halt wohl nach TW gehen. Manfred
Am 14.02.2023 um 18:24 schrieb Herbert Albert:
Am Dienstag, 14. Februar 2023, 18:00:42 CET schrieb Ulf Volmer:
On 14.02.23 17:55, Herbert Albert wrote:
ich will das jetzt nicht weiter vertiefen, aber ~> pgrep displaycal 23445
:~> sudo nsenter -m -t 23445
-bash-5.1#
Jau. Damit hast Du eine Shell in Deiner flatpak Umgebung und kannst weiter forschen. Z.B. zu Deiner Frage, woher Deine App stammt:
ls -l /app/bin/displaycal
Viele Grüße Ulf na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden.
Ich bin auch kein Freund davon, wenngleich ich zugebe, dass es in manchen Fällen wirklich Sinn ergibt. Aber das als allgemeinen Ansatz zu verwenden finde ich persönlich hanebüchenen Unfug den ich garantiert nicht mitmachen werde. Beispiel dafür: Ein relativ einfaches Python Skript (Certbot) erforderte vor geraumer Zeit den Snap Firlefanz auf Debian. Da dachte ich dann gleich, geht's noch? Manfred
Am Dienstag, 14. Februar 2023, 21:31:15 CET schrieb Manfred Kreisl:
Am 14.02.2023 um 18:24 schrieb Herbert Albert:
Am Dienstag, 14. Februar 2023, 18:00:42 CET schrieb Ulf Volmer:
On 14.02.23 17:55, Herbert Albert wrote:
ich will das jetzt nicht weiter vertiefen, aber ~> pgrep displaycal 23445
:~> sudo nsenter -m -t 23445
-bash-5.1#
Jau. Damit hast Du eine Shell in Deiner flatpak Umgebung und kannst weiter forschen. Z.B. zu Deiner Frage, woher Deine App stammt:
ls -l /app/bin/displaycal
Viele Grüße Ulf
na dann ist das, wie Manfred schon geschrieben hat, eine Art Betriebssystem im Betriebssystem, Container, VM, etc.
Da habe ich den Sinn, ob ich das brauche/will, noch nicht verstanden.
Ich bin auch kein Freund davon, wenngleich ich zugebe, dass es in manchen Fällen wirklich Sinn ergibt. Aber das als allgemeinen Ansatz zu verwenden finde ich persönlich hanebüchenen Unfug den ich garantiert nicht mitmachen werde.
Beispiel dafür:
Ein relativ einfaches Python Skript (Certbot) erforderte vor geraumer Zeit den Snap Firlefanz auf Debian. Da dachte ich dann gleich, geht's noch?
Manfred muss ich mir dann nach 30 Jahren SuSE (anfangs noch SuSE/Slackware) eine neue Linux-Heimat suchen? Machen das nun alle seriösen Distris so? Was ist den an den rpm-basierten System nicht gut genug, so dass es durch flatpak abgelöst werden müsste?
Am Mittwoch, 15. Februar 2023, 12:54:01 CET schrieb Herbert Albert:
muss ich mir dann nach 30 Jahren SuSE (anfangs noch SuSE/Slackware) eine neue Linux-Heimat suchen? Machen das nun alle seriösen Distris so? Was ist den an den rpm-basierten System nicht gut genug, so dass es durch flatpak abgelöst werden müsste?
Wenn du so denkst wie ich, dann wohl leider ja. Ich werde dann wohl auch nach ca. 30 Jahren SUSE verlassen. Nach meiner Meinung nach, ist das nur ein Abgeben von Verantwortung und Arbeit an upstream bzw. andere und somit dann auch die perfekte Möglichkeit Personal einzusparen. Alle machen das wohl bis jetzt nicht. Aber RedHad. Und da Suse in letzter Zeit vermehrt meint RadHat hinterher zulaufen, Suse dann auch. Ich werde den ALP-, Microos-, Imutable-, Faltpack- und Rebootorgien-Mist auch nicht mitmachen. (Ja, für mich ist das einfach Mist und ich möchte es nicht.) Bin mir nur noch nicht schlüssig wohin. Für Desktop entweder Tumbleweed oder gleich Manjaro, da ich eigentlich auch keine Lust mehr habe dann die Marketing- und BWL-Abteilung von SUSE weiter zu unterstützen. Auf dem Server wohl dann Debian. Dafür ist mir Manjaro und vor allem Tumbleweed zu fehleranfällig. Zumindest sind mir die Fehler bei Tumbleweed über die ich hier lese nicht akzeptabel. Gruß Eric
Am Mittwoch, 15. Februar 2023, 13:24:04 CET schrieb Eric Schirra:
Am Mittwoch, 15. Februar 2023, 12:54:01 CET schrieb Herbert Albert:
muss ich mir dann nach 30 Jahren SuSE (anfangs noch SuSE/Slackware) eine neue Linux-Heimat suchen? Machen das nun alle seriösen Distris so? Was ist den an den rpm-basierten System nicht gut genug, so dass es durch flatpak abgelöst werden müsste?
Wenn du so denkst wie ich, dann wohl leider ja. Ich werde dann wohl auch nach ca. 30 Jahren SUSE verlassen. Nach meiner Meinung nach, ist das nur ein Abgeben von Verantwortung und Arbeit an upstream bzw. andere und somit dann auch die perfekte Möglichkeit Personal einzusparen. Alle machen das wohl bis jetzt nicht. Aber RedHad. Und da Suse in letzter Zeit vermehrt meint RadHat hinterher zulaufen, Suse dann auch. Ich werde den ALP-, Microos-, Imutable-, Faltpack- und Rebootorgien-Mist auch nicht mitmachen. (Ja, für mich ist das einfach Mist und ich möchte es nicht.) Bin mir nur noch nicht schlüssig wohin. Für Desktop entweder Tumbleweed oder gleich Manjaro, da ich eigentlich auch keine Lust mehr habe dann die Marketing- und BWL-Abteilung von SUSE weiter zu unterstützen. Auf dem Server wohl dann Debian. Dafür ist mir Manjaro und vor allem Tumbleweed zu fehleranfällig. Zumindest sind mir die Fehler bei Tumbleweed über die ich hier lese nicht akzeptabel.
Gruß Eric Hallo Eric,
aber wird Tumbleweed dann nicht auch mit flatpak gleichziehen? Gruß Herbert
Am Mittwoch, dem 15.02.2023 um 13:24 +0100 schrieb Eric Schirra: Hallo Eric
Für Desktop entweder Tumbleweed
Du glaubst also, dass das dieser Zweig weiter Bestand haben wird? Dass OpenSUSE die ManPower haben wird 2 grundsätzlich verschiedene Funktionsansätze parallel zu pflegen? Ich kann das ehrlich gesagt nicht glauben... -- Klaus B. Klose
Am 15.02.2023 um 14:44 schrieb Klaus Klose:
Am Mittwoch, dem 15.02.2023 um 13:24 +0100 schrieb Eric Schirra:
Hallo Eric
Für Desktop entweder Tumbleweed
Du glaubst also, dass das dieser Zweig weiter Bestand haben wird? Dass OpenSUSE die ManPower haben wird 2 grundsätzlich verschiedene Funktionsansätze parallel zu pflegen? Ich kann das ehrlich gesagt nicht glauben...
Das sind ja jetzt schon zwei vollkommen getrennte Wege, aber wer weiß das schon. Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde Wie die zahlungswilligen Kunden (SLES) das sehen vermag ich allerdings nicht zu beurteilen Manfred
Am Mittwoch, 15. Februar 2023, 15:14:30 CET schrieb Manfred Kreisl:
Am 15.02.2023 um 14:44 schrieb Klaus Klose:
Am Mittwoch, dem 15.02.2023 um 13:24 +0100 schrieb Eric Schirra:
Hallo Eric
Für Desktop entweder Tumbleweed
Du glaubst also, dass das dieser Zweig weiter Bestand haben wird? Dass OpenSUSE die ManPower haben wird 2 grundsätzlich verschiedene Funktionsansätze parallel zu pflegen? Ich kann das ehrlich gesagt nicht glauben...
Das sind ja jetzt schon zwei vollkommen getrennte Wege, aber wer weiß das schon.
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
Wie die zahlungswilligen Kunden (SLES) das sehen vermag ich allerdings nicht zu beurteilen
Auch dazu sind noch einige Fragen offen. Denn die Leute, wie leider mittlerweile überall, kennen nicht die wirkliche Praxis. Denen schweben Sachen vor, die so einfach nicht im größeren Umfang funktionieren. Sie leben alle in ihrem kleinen persönlichen Desktop Universum. Aber nicht in größeren Unternehmen und vor allem nicht in einer Produktion. Aber lassen wir das mal besser hier. Sonst fühlt sich noch jemand angegriffen oder sonst was. Per Mail können wir aber weiter diskutieren wenn du möchtest. :-) Gruß Eric
Am Mittwoch, dem 15.02.2023 um 15:32 +0100 schrieb Eric Schirra: Hallo Eric Hallo Manfred
Sie leben alle in ihrem kleinen persönlichen Desktop Universum. Aber nicht in größeren Unternehmen und vor allem nicht in einer Produktion.
Was den kommerziellen Zweig von SUSE betrifft, da kann ich nicht viel zu sagen. Ganz besonders nicht, welche Anforderungen da bestehen mögen. Was den "Open"-Zweig betrifft, da habe ich mir schon vor Jahren gezwungener Maßen eine nicht gerade positive Meinung gebildet. Und im Gefolge mich gegen OpenSUSE als meine Distribution entschieden. -- Klaus B. Klose
Hallo! Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will. cu Peter
Am Donnerstag, 16. Februar 2023, 17:22:04 CET schrieb Peter Geerds:
Hallo!
Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
cu Peter Hallo Peter,
aber wenn es dann von den Programmen abhängt, dann ist es doch auch bei Debian ein Mix oder Mischmasch von flatpak und dpg. Macht denn so eine Zweigleisigkeit Sinn? Gruß Herbert
Am Donnerstag, 16. Februar 2023, 17:22:04 CET schrieb Peter Geerds:
Hallo!
Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
Unter debian ist es aber kein Zwang. Sondern man kann es _zusätzlich_ nutzen. Das macht sogar manchmal und für ganz wenige Pakete Sinn. Bei Suse, ab > Leap 15.5 wird es aber die Programme dann mehr oder weniger _nur_ noch über Flatpack geben. Das ist ein gravierender Unterschied. Und alles was sonst noch mit dem imutable zeigs zuammen hängt. Aber muss jeder selbst wissen ob er ein "Windo.." im Gewand von Linux möchte. Gruß Eric
Am 16.02.23 um 18:37 schrieb Eric Schirra:
Am Donnerstag, 16. Februar 2023, 17:22:04 CET schrieb Peter Geerds:
Hallo!
Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
Unter debian ist es aber kein Zwang. Sondern man kann es _zusätzlich_ nutzen. Das macht sogar manchmal und für ganz wenige Pakete Sinn. Bei Suse, ab > Leap 15.5 wird es aber die Programme dann mehr oder weniger _nur_ noch über Flatpack geben.
Das halte ich für eine Gerücht. Es würde bedeuten, dass openSUSE die Paketzusammenstellung aus der Hand gibt. Gruß Peter
Am 16. Februar 2023 21:20:59 MEZ schrieb Peter McD <peter.posts@gmx.net>:
Am 16.02.23 um 18:37 schrieb Eric Schirra:
Am Donnerstag, 16. Februar 2023, 17:22:04 CET schrieb Peter Geerds:
Hallo!
Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
Unter debian ist es aber kein Zwang. Sondern man kann es _zusätzlich_ nutzen. Das macht sogar manchmal und für ganz wenige Pakete Sinn. Bei Suse, ab > Leap 15.5 wird es aber die Programme dann mehr oder weniger _nur_ noch über Flatpack geben.
Das halte ich für eine Gerücht. Es würde bedeuten, dass openSUSE die Paketzusammenstellung aus der Hand gibt.
Informiere dich über ALP und MicroOS und was nach Leap 15.5 kommen soll. Gruß Eric
Am 16.02.23 um 21:53 schrieb Eric Schirra:
Am 16. Februar 2023 21:20:59 MEZ schrieb Peter McD <peter.posts@gmx.net>:
Am 16.02.23 um 18:37 schrieb Eric Schirra:
Am Donnerstag, 16. Februar 2023, 17:22:04 CET schrieb Peter Geerds:
Hallo!
Am 15.02.2023 um 15:14 Uhr schrieb Manfred Kreisl:
Ist mir allerdings völlig egal, ich sehe es so wie Eric, denke dass ich mich dann endgültig ganz von openSUSE abnabele und nur noch Debian einsetzen werde
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
Unter debian ist es aber kein Zwang. Sondern man kann es _zusätzlich_ nutzen. Das macht sogar manchmal und für ganz wenige Pakete Sinn. Bei Suse, ab > Leap 15.5 wird es aber die Programme dann mehr oder weniger _nur_ noch über Flatpack geben.
Das halte ich für eine Gerücht. Es würde bedeuten, dass openSUSE die Paketzusammenstellung aus der Hand gibt.
Informiere dich über ALP und MicroOS und was nach Leap 15.5 kommen soll.
Finde Dich damit ab. Es gibt kommerzielle Interessen, wahrscheinlich nicht nur bei SUSE, die Änderungen durchzuziehen aber keine um damit Verluste einzufahren. Außerdem dürfte Leap so lange unterstützt werden, bis die ALP Variante passabel läuft und auf jeden Fall wird genug Zeit sein, jene in eine VM auszuprobieren. Gruß Peter
Am Freitag, 17. Februar 2023, 14:38:39 CET schrieb Peter McD:
Finde Dich damit ab. Es gibt kommerzielle Interessen, wahrscheinlich nicht nur bei SUSE, die Änderungen durchzuziehen aber keine um damit Verluste einzufahren.
Außerdem dürfte Leap so lange unterstützt werden, bis die ALP Variante passabel läuft und auf jeden Fall wird genug Zeit sein, jene in eine VM auszuprobieren.
Du hast es nicht geglaubt. Nicht ich. Und wolltest du das nicht? Aber egal. Ich finde mich dahingehen damit ab, dass ich eben nach ca. 30 Jahren Suse verlasse. Wie wohl so einige andere auch. Die kommerzielle Interessen zielen nur darauf ab Kosten einzusparen und Verantwortung abzugeben. Somit Arbeitsplätze abzubauen. Kommerziell ist das nämlich ein Mist. So automatisch Updates und unnötige Reboots. Kann man in der Produktion nichts mit anfangen und will keiner. Wer auf sowas kommt weiß nicht wie eine Produktion funktioniert. Aber mit dem Unverständniss steht Suse nicht alleine da. Das greift langsam aber sich um sich. Achja. Was soll da solange unterstützt werden.? Die letzte Leap ist 15.5. Und sollte das ALP, MicroOS oder wie auch immer das heißen soll nicht laufen, dann wird halt 15.5 verlängert. Nur was will man da noch verlängern? Das ist jetzt schon uralt und wird bist dahin dann schon verfaulen/verwesen und stinken. Gruß Eric
On 17.02.23 15:18, Eric Schirra wrote:
So automatisch Updates und unnötige Reboots. Kann man in der Produktion nichts mit anfangen und will keiner. Wer auf sowas kommt weiß nicht wie eine Produktion funktioniert. Aber mit dem Unverständniss steht Suse nicht alleine da. Das greift langsam aber sich um sich.
Es ist gute Praxis bei der Nutzung von Enterprise Distros, dass die Applikationsbetreuer dafür sorgen, dass sie ihr eigenes JDP/Python/ruby/whatever mitbringen und sich von den Versionen der Platform unabhängig machen. In der Konstellation ist dann die Verwendung von Containern und die Reduzierung des OS auf die Funktion einer Container Runtime ein vernünftiger Schritt. Das Problen von OpenSuse ist hier aus meiner Sicht zum einen die starke Anlehnung an SLES und zum anderen die starke Fokussierung auf den Desktop. Viele Grüße Ulf
Am 17.02.23 um 15:18 schrieb Eric Schirra:
Am Freitag, 17. Februar 2023, 14:38:39 CET schrieb Peter McD:
Finde Dich damit ab. Es gibt kommerzielle Interessen, wahrscheinlich nicht nur bei SUSE, die Änderungen durchzuziehen aber keine um damit Verluste einzufahren.
Außerdem dürfte Leap so lange unterstützt werden, bis die ALP Variante passabel läuft und auf jeden Fall wird genug Zeit sein, jene in eine VM auszuprobieren.
Du hast es nicht geglaubt. Nicht ich. Und wolltest du das nicht? Aber egal. Ich finde mich dahingehen damit ab, dass ich eben nach ca. 30 Jahren Suse verlasse. Wie wohl so einige andere auch.Also laut <https://en.opensuse.org/S.u.S.E._Linux_4.2> gibt es die Suse Distro seit 1996 es fehlt also noch was zu 30 Jahren :) Seitdem bin ich 'Suse User', seit 1997 hier in der Liste. Ich war immer zufrieden mit Suse, obwohl oder weil ich es beruflich mit red hat und debian zutun hatte. Einer der grössten Pluspunkte ist diese Mailingliste hier. Das Gemecker über suse gibt es auch schon seit 1997. Es kommen und gehen Leute, so what. Flatpak etc ist eine technische Entwicklung, die halt einfach da ist. Mir ist das egal, ich bin in Rente also hab ich beruflich nix mehr damit zu tun. Und ich bin mir sicher, dass es einen Weg geben wird. Ich hab mich für tumbleweed entschieden, da denke ich, ist für mich die Frage, wer wen überlebt :)
Die kommerzielle Interessen zielen nur darauf ab Kosten einzusparen und Verantwortung abzugeben. Somit Arbeitsplätze abzubauen. Kommerziell ist das nämlich ein Mist. So automatisch Updates und unnötige Reboots. Kann man in der Produktion nichts mit anfangen und will keiner. Wer auf sowas kommt weiß nicht wie eine Produktion funktioniert. Aber mit dem Unverständniss steht Suse nicht alleine da. Das greift langsam aber sich um sich.
mimimimi... :(
Achja. Was soll da solange unterstützt werden.? Die letzte Leap ist 15.5. Und sollte das ALP, MicroOS oder wie auch immer das heißen soll nicht laufen, dann wird halt 15.5 verlängert. Nur was will man da noch verlängern? Das ist jetzt schon uralt und wird bist dahin dann schon verfaulen/verwesen und stinken.
Ähhh?
Gruß Eric
-- Gruss Bernd
Am 17. Februar 2023 20:04:17 MEZ schrieb Bernd Obermayr <lists@bobermayr.de>:
Am 17.02.23 um 15:18 schrieb Eric Schirra:
Am Freitag, 17. Februar 2023, 14:38:39 CET schrieb Peter McD:
Finde Dich damit ab. Es gibt kommerzielle Interessen, wahrscheinlich nicht nur bei SUSE, die Änderungen durchzuziehen aber keine um damit Verluste einzufahren.
Außerdem dürfte Leap so lange unterstützt werden, bis die ALP Variante passabel läuft und auf jeden Fall wird genug Zeit sein, jene in eine VM auszuprobieren.
Du hast es nicht geglaubt. Nicht ich. Und wolltest du das nicht? Aber egal. Ich finde mich dahingehen damit ab, dass ich eben nach ca. 30 Jahren Suse verlasse. Wie wohl so einige andere auch.Also laut <https://en.opensuse.org/S.u.S.E._Linux_4.2> gibt es die Suse Distro seit 1996 es fehlt also noch was zu 30 Jahren :) Seitdem bin ich 'Suse User', seit 1997 hier in der Liste. Ich war immer zufrieden mit Suse, obwohl oder weil ich es beruflich mit red hat und debian zutun hatte. Einer der grössten Pluspunkte ist diese Mailingliste hier. Das Gemecker über suse gibt es auch schon seit 1997. Es kommen und gehen Leute, so what. Flatpak etc ist eine technische Entwicklung, die halt einfach da ist. Mir ist das egal, ich bin in Rente also hab ich beruflich nix mehr damit zu tun. Und ich bin mir sicher, dass es einen Weg geben wird. Ich hab mich für tumbleweed entschieden, da denke ich, ist für mich die Frage, wer wen überlebt :)
Die kommerzielle Interessen zielen nur darauf ab Kosten einzusparen und Verantwortung abzugeben. Somit Arbeitsplätze abzubauen. Kommerziell ist das nämlich ein Mist. So automatisch Updates und unnötige Reboots. Kann man in der Produktion nichts mit anfangen und will keiner. Wer auf sowas kommt weiß nicht wie eine Produktion funktioniert. Aber mit dem Unverständniss steht Suse nicht alleine da. Das greift langsam aber sich um sich.
mimimimi... :(
Achja. Was soll da solange unterstützt werden.? Die letzte Leap ist 15.5. Und sollte das ALP, MicroOS oder wie auch immer das heißen soll nicht laufen, dann wird halt 15.5 verlängert. Nur was will man da noch verlängern? Das ist jetzt schon uralt und wird bist dahin dann schon verfaulen/verwesen und stinken.
Ähhh?
Gruß Eric
Soweit ich mich erinnere hatte SuSE damals noch keine eigene Distri. Es gab von SuSE ca. 6 Disketten mit Slackware. Das waren 1993 meine Anfänge mit Linux. https://de.wikipedia.org/wiki/Slackware Gruß Herbert
Am 17. Februar 2023 20:25:05 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Soweit ich mich erinnere hatte SuSE damals noch keine eigene Distri. Es gab von SuSE ca. 6 Disketten mit Slackware. Das waren 1993 meine Anfänge mit Linux. https://de.wikipedia.org/wiki/Slackware
Also jetzt wird's blöd aber auch typisch. Was ist an ein paar Jahren hin und her wichtig. Und wenn ich nach Wikipedia gehe. Gründung 1992. Jetzt haben wir 2023. Na?
Am Freitag, 17. Februar 2023, 22:28:16 CET schrieb Eric Schirra:
Am 17. Februar 2023 20:25:05 MEZ schrieb Herbert Albert <herbert.albert@nefkom.net>:
Soweit ich mich erinnere hatte SuSE damals noch keine eigene Distri. Es gab von SuSE ca. 6 Disketten mit Slackware. Das waren 1993 meine Anfänge mit Linux. https://de.wikipedia.org/wiki/Slackware
Also jetzt wird's blöd aber auch typisch. Was ist an ein paar Jahren hin und her wichtig. Und wenn ich nach Wikipedia gehe. Gründung 1992. Jetzt haben wir 2023. Na? ich hatte nur auf Bernd geantwortet, der die 30 Jahre angezweifelt hat. Damit ist aber auch gut, das müssen wir nicht weiter ausführen.
Am 17.02.23 um 22:21 schrieb Eric Schirra:
Am 17. Februar 2023 20:04:17 MEZ schrieb Bernd Obermayr <lists@bobermayr.de>:
Mir ist das egal, ich bin in Rente also hab ich beruflich nix mehr damit zu tun.
mimimimi... :(
Du willst in Rente sein und verhälst dich so kindisch?
Dir fehlt die Perspektive;-) Wenn man in Rente ist, sind 2 Jahre eine lange Zeit. Sofern ein Rentner sich noch für Linux interessiert, ist die Aussicht auf ALP äußerst attraktiv. Peter
Peter McD schrieb:
flatpak unter Debian ist inzwischen auch "normal" - es hängt von den Programmen ab und was man will.
Unter debian ist es aber kein Zwang. Sondern man kann es _zusätzlich_ nutzen. Das macht sogar manchmal und für ganz wenige Pakete Sinn. Bei Suse, ab > Leap 15.5 wird es aber die Programme dann mehr oder weniger _nur_ noch über Flatpack geben.
Das halte ich für eine Gerücht. Es würde bedeuten, dass openSUSE die Paketzusammenstellung aus der Hand gibt.
Das ist bei MicroOS jetzt schon so - ich habe mir nämlich grade kürzlich eine MicroOS-VM installiert und das mit Erstaunen festgestellt. Allerdings ist glaube ich der Schluss von MicroOS auf OpenSuse Leap 16.0 nur bedingt erlaubt. Da wird sich noch einiges tun müssen. Auf flathub sind ja etliche Anwendungen eben nicht verfügbar. Z.B. finde ich da keinen einzigen Compiler. IDEs ja, aber Compiler nicht?! Aber man kann ja bei flatpak neben flathub beliebig viele "Sources" eintragen (so heißen die Repos da wohl). Ich nehme daher an, dass es im "immutable" OpenSuse auch sowas wie eine OpenSuse-Source geben wird. Es wäre interessant, genau zu dem Themen etwas mehr von Suse zu hören, denn da herrscht viel Verunsicherung, auch in Unternehmen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Manfred Haertel, DB3HM schrieb am 17.02.23 um 06:33:
Auf flathub sind ja etliche Anwendungen eben nicht verfügbar. Z.B. finde ich da keinen einzigen Compiler. IDEs ja, aber Compiler nicht?!
Eine IDE ohne Compiler macht wenig Sinn, was ist nun die logische Schlussfolgerung wenn man eine IDE installiert?
Am 17.02.23 um 08:48 schrieb Volker Kohaupt:
Manfred Haertel, DB3HM schrieb am 17.02.23 um 06:33:
Auf flathub sind ja etliche Anwendungen eben nicht verfügbar. Z.B. finde ich da keinen einzigen Compiler. IDEs ja, aber Compiler nicht?!
Eine IDE ohne Compiler macht wenig Sinn, was ist nun die logische Schlussfolgerung wenn man eine IDE installiert?
Hi, Naja, ich finde das ja auch außerhalb vielleicht denkbarer Nischen ausgemachten Unsinn... aber - das ist dann vielleicht logisch, eine IDE ist ja eher was Systemunabhängiges, am besten auf jedem System möglichst gleich Aussehendes. Ein Compiler muss sich wohl oder übel mit dem System rumschlagen, auf dem seine Software laufen soll, was das ist, weiß der Flatpacker ja nicht... -- cu jth
Volker Kohaupt schrieb:
Manfred Haertel, DB3HM schrieb am 17.02.23 um 06:33:
Auf flathub sind ja etliche Anwendungen eben nicht verfügbar. Z.B. finde ich da keinen einzigen Compiler. IDEs ja, aber Compiler nicht?!
Eine IDE ohne Compiler macht wenig Sinn, was ist nun die logische Schlussfolgerung wenn man eine IDE installiert?
Und wenn ich keine IDE brauche, sondern einfach nur ein Programm compilieren will, muss ich dann sowas wie flatpak --user run --command bash org.kde.kdevelop -c "gcc -o helloworld helloworld.c" machen oder geht das auch "in einfach"? -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 17.02.23 um 11:36 schrieb Manfred Haertel, DB3HM:
Volker Kohaupt schrieb:
Manfred Haertel, DB3HM schrieb am 17.02.23 um 06:33:
Auf flathub sind ja etliche Anwendungen eben nicht verfügbar. Z.B. finde ich da keinen einzigen Compiler. IDEs ja, aber Compiler nicht?!
Eine IDE ohne Compiler macht wenig Sinn, was ist nun die logische Schlussfolgerung wenn man eine IDE installiert?
Und wenn ich keine IDE brauche, sondern einfach nur ein Programm compilieren will, muss ich dann sowas wie
flatpak --user run --command bash org.kde.kdevelop -c "gcc -o helloworld helloworld.c"
machen oder geht das auch "in einfach"?
naja, dafür gibts ja dann doch scripting und Aliase... nimmst Du ja woanders sicher auch... ich sehe da eher Probleme, wenn flatpaks kooperieren sollen, sowas wie Apache aus einem Flatpak und eine webbasierte Anwendung aus einem anderen, die was anderes voraussetzt, als das Apache-FP bietet. Das Problem gibts ja jetzt auch, aber wenn dann jeder seine Flatpak-Insel bauen kann, wird es wohl schlimmer werden, weil ja kein Zwang mehr besteht, irgendwas im Rahmen einer Distri abzustimmen... -- cu jth
Jörg Thümmler schrieb:
Und wenn ich keine IDE brauche, sondern einfach nur ein Programm compilieren will, muss ich dann sowas wie
flatpak --user run --command bash org.kde.kdevelop -c "gcc -o helloworld helloworld.c"
machen oder geht das auch "in einfach"?
naja, dafür gibts ja dann doch scripting und Aliase... nimmst Du ja woanders sicher auch...
Das wäre schon machbar, ist aber für mich als "Boomer" so ein bisschen "von hinten durch die Brust ins Auge". Boomer denken beim Programmieren "Bottom Up". Ich hab ein Programm, ich will das übersetzen, dafür brauch ich einen Compiler und wenn's ganz komfortabel sein soll oder ich eine Struktur reinbringen muss, weil es ziemlich komplex ist, auch eine IDE. Die Generation Y, die ja jetzt das Sagen hat, denkt "Top Down". Ich hab eine IDE, darin habe ich Projekte, irgendwie entsteht Code und was ein Compiler ist, brauch ich nicht zu wissen. Aus meiner Boomer-Sicht ist beides legitim und fallbezogen vielleicht manchmal das eine und manchmal das andere richtig. Aber die Generation Y hat entschieden, dass nur ihre Sicht die richtige sein kann und wenn ich frage warum, heißt es nur "OK Boomer". Die Bemerkungen zum Generationenkonflikt bitte nicht zu ernst nehmen, das ist mehr ironisch mit wahrem Kern gemeint. :-) Und nichts gegen die Container, das ist schon ein interessantes Konzept und macht einige neue interessante Konstrukte möglich. Aber einige alte gewohnte Konstrukte funktionieren nicht mehr und es wird komplizierter und daran muss ich mich "in meinem Alter" auch erst mal gewöhnen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 17.02.23 um 14:06 schrieb Manfred Haertel, DB3HM:
Jörg Thümmler schrieb:
Und wenn ich keine IDE brauche, sondern einfach nur ein Programm compilieren will, muss ich dann sowas wie
flatpak --user run --command bash org.kde.kdevelop -c "gcc -o helloworld helloworld.c"
machen oder geht das auch "in einfach"?
naja, dafür gibts ja dann doch scripting und Aliase... nimmst Du ja woanders sicher auch...
Das wäre schon machbar, ist aber für mich als "Boomer" so ein bisschen "von hinten durch die Brust ins Auge".
Boomer denken beim Programmieren "Bottom Up". Ich hab ein Programm, ich will das übersetzen, dafür brauch ich einen Compiler und wenn's ganz komfortabel sein soll oder ich eine Struktur reinbringen muss, weil es ziemlich komplex ist, auch eine IDE.
Die Generation Y, die ja jetzt das Sagen hat, denkt "Top Down". Ich hab eine IDE, darin habe ich Projekte, irgendwie entsteht Code und was ein Compiler ist, brauch ich nicht zu wissen.
Aus meiner Boomer-Sicht ist beides legitim und fallbezogen vielleicht manchmal das eine und manchmal das andere richtig. Aber die Generation Y hat entschieden, dass nur ihre Sicht die richtige sein kann und wenn ich frage warum, heißt es nur "OK Boomer".
Die Bemerkungen zum Generationenkonflikt bitte nicht zu ernst nehmen, das ist mehr ironisch mit wahrem Kern gemeint. :-)
Und nichts gegen die Container, das ist schon ein interessantes Konzept und macht einige neue interessante Konstrukte möglich. Aber einige alte gewohnte Konstrukte funktionieren nicht mehr und es wird komplizierter und daran muss ich mich "in meinem Alter" auch erst mal gewöhnen.
... jaja, kommt mir bekannt vor... Schönes WE allen ... und in ein paar Jahren kann die Generation "Z" dann sehen, wie sie den Planeten am drehen hält, bis dahin wechsle ich das Universum ;-) -- cu jth
Hallo zusammen, es ist interessant zu lesen, was unter diesem Betreff diskutiert wird ;-) Ich probiere mal einen Subject-Wechsel, auch wenn es in einem kleinen Seitenast dieser Diskussion vermutlich nicht wirklich hilft. Am Freitag, 17. Februar 2023, schrieb Manfred Haertel, DB3HM:
Peter McD schrieb:
Es würde bedeuten, dass openSUSE die Paketzusammenstellung aus der Hand gibt.
Nicht zwingend, denn aus irgendwas müssen die Container ja gebaut werden - und da ist "upstream" nicht immer die gewünschte Option. Auch nicht aus Marketing-Sicht - für eine reine, "nackte" Container-Runtime würden die Kunden vermutlich nicht so viel zahlen wollen als für ein komplettes Betriebssystem mit Vollausstattung ;-) Was man bisher gehört hat, tendiert wohl in Richtung "Container aus den Tumbleweed-Paketen bauen" - ob es wirklich so kommt, wird sich zeigen.
Es wäre interessant, genau zu dem Themen etwas mehr von Suse zu hören,
Genau. Eine offizielle Aussage ist mir bisher noch nicht über den Weg gelaufen, aber immerhin ein paar Hinweise (hauptsächlich auf der Factory- Mailingliste): - ein paar SUSE-Entwickler haben in der Hackweek daran gearbeitet, auf Basis von ALP eine "traditionelle" Distribution zu bauen. Die ist wohl ähnlich wie Leap, wenn auch bisher mit weniger Paketen. Details: https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll - von einem anderen SUSE-Entwickler kam ein Hinweis, dass ALP eine Platform ist und daraus mehrere Produkte entstehen können/werden. Auch da kam ein Hinweis, dass eins dieser Produkte eine "traditionelle" Distribution sein könnte. Ich habe also immerhin ein wenig Hoffnung, dass es sowas wie Leap auch zukünftig geben wird. Sicher ist das aber (leider) nicht.
denn da herrscht viel Verunsicherung, auch in Unternehmen.
Falls diese Unternehmen zahlende SLE-Kunden sind, würde ich mal den Kontakt bei SUSE anrufen und nachfragen. Wenn genügend Leute nach einem "traditionellen" SLE rufen, steigert das die Chancen, dass es den auch gibt ;-) Gruß Christian Boltz -- But a cactus is stable. Have you ever tried to kill a cactus just running against it? [Kim Leyendecker in opensuse-project]
Christian Boltz schrieb:
denn da herrscht viel Verunsicherung, auch in Unternehmen.
Falls diese Unternehmen zahlende SLE-Kunden sind, würde ich mal den Kontakt bei SUSE anrufen und nachfragen. Wenn genügend Leute nach einem "traditionellen" SLE rufen, steigert das die Chancen, dass es den auch gibt ;-)
So wie ich das einschätze, dürfte diese Option in den meisten IT-Abteilungen nicht wirklich zur Debatte stehen. Platt gesagt denkt man in IT-Abteilungen aus Erfahrung so, die Anbieter auf den IT-Markt machen doch eh was sie wollen und das, was wir wollen, interessiert die nicht. Wir können aber ein Produkt wechseln und tun sowas sowieso ständig bei irgendwelchen Produkten. Man stellt sich aber zwei Fragen. Die erste ist, ist der Schmerz wirklich groß genug, um einen Wechsel der Linux-Distri auf dutzenden, in manchen Unternehmen vielleicht sogar hunderten von Systemen mit all seinen Aufwänden und Unwägbarkeiten anzustoßen? Und das kann man im Moment nicht wirklich sagen, weil einfach die Infos fehlen. Ein all zu radikaler Einschnitt in die Struktur der Plattform wird zwar (immer) kritisch gesehen, aber es ist eben - wie auch die Diskussion hier gezeigt hat - noch nicht klar, ob es nicht auch einen "traditionellen Zweig" geben wird - der ja auch eine *allmähliche* Migration zu den Containern ermöglicht, falls das doch für viele Zwecke gut sein sollte. Jetzt ist aber die zweite Frage: Wann läuft uns die Zeit weg für eine Entscheidung? Denn Migrationsprozesse dauern und eigentlich immer sogar länger als in der ersten Worst-Case-Einschätzung. Die Entscheidung läuft also darauf hinaus, wie lange können wir den Informationsmangel aussitzen, bevor wir eine Entscheidung treffen müssen? Man schaut also in die Support-Matrix von Suse und liest dort, dass SLE 15 bis zum 31.7.2028 unterstützt wird. Und dann lehnt man sich als IT-Entscheider erst mal wieder zurück. Für die Unternehmen ist das gut, für Suse schlecht. Denn ich schätze das so ein, dass man in den Unternehmen nach dem Erscheinen von SLE 16 (wenn es denn so heißt) bis auf weiteres auf SLE 15 setzen wird. SLE 16 wird man testen und den Eindruck gewinnen (egal ob richtig oder falsch), dass die Migration von SLE 15 auf 16 AUFWÄNDIGER ist (oder sein könnte) als von SLE 15 auf eine andere traditionelle Distri. Und dann wird man zu einem individuellen Zeitpunkt sagen, jetzt läuft uns bald die Zeit davon, jetzt starten wir die Migration auf eine andere Distri doch - und dann geht es ganz allmählich weg von Suse. Erst dann. Wenn es für Suse zu spät ist, eine falsche Entscheidung zu revidieren. Ein klares Bekenntnis, wir unterstützen auch mit neueren Versionen "bis auf weiteres" eine klassische Distri würde diesen Prozess vermeiden. Aber da sich die IT-Entscheider aufgrund der langen Support-Phase ja zurück gelehnt haben, gibt es keinerlei Druck seitens der Kunden auf Suse, eine solche Aussage zu treffen. Entweder kommt diese Aussage von Suse irgendwann doch mal "freiwillig", dann ist alles gut und alle Migrationen sind gestorben, oder sie kommt nicht, dann kommt es genau so wie eben skizziert. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Perfekter Beitrag. Dem ist fast nichts mehr hinzuzufügen. Außer eine kleine Anmerkung, dass die Entscheider meist nicht diejenigen sind, die nachher wirklich damit arbeiten. Ansonsten aber perfekt und auf den Punkt gebracht. Gruß Eric Am 18. Februar 2023 04:48:48 MEZ schrieb "Manfred Haertel, DB3HM" <Manfred.Haertel@rz-online.de>:
Christian Boltz schrieb:
denn da herrscht viel Verunsicherung, auch in Unternehmen.
Falls diese Unternehmen zahlende SLE-Kunden sind, würde ich mal den Kontakt bei SUSE anrufen und nachfragen. Wenn genügend Leute nach einem "traditionellen" SLE rufen, steigert das die Chancen, dass es den auch gibt ;-)
So wie ich das einschätze, dürfte diese Option in den meisten IT-Abteilungen nicht wirklich zur Debatte stehen.
Platt gesagt denkt man in IT-Abteilungen aus Erfahrung so, die Anbieter auf den IT-Markt machen doch eh was sie wollen und das, was wir wollen, interessiert die nicht. Wir können aber ein Produkt wechseln und tun sowas sowieso ständig bei irgendwelchen Produkten.
Man stellt sich aber zwei Fragen. Die erste ist, ist der Schmerz wirklich groß genug, um einen Wechsel der Linux-Distri auf dutzenden, in manchen Unternehmen vielleicht sogar hunderten von Systemen mit all seinen Aufwänden und Unwägbarkeiten anzustoßen? Und das kann man im Moment nicht wirklich sagen, weil einfach die Infos fehlen.
Ein all zu radikaler Einschnitt in die Struktur der Plattform wird zwar (immer) kritisch gesehen, aber es ist eben - wie auch die Diskussion hier gezeigt hat - noch nicht klar, ob es nicht auch einen "traditionellen Zweig" geben wird - der ja auch eine *allmähliche* Migration zu den Containern ermöglicht, falls das doch für viele Zwecke gut sein sollte.
Jetzt ist aber die zweite Frage: Wann läuft uns die Zeit weg für eine Entscheidung? Denn Migrationsprozesse dauern und eigentlich immer sogar länger als in der ersten Worst-Case-Einschätzung.
Die Entscheidung läuft also darauf hinaus, wie lange können wir den Informationsmangel aussitzen, bevor wir eine Entscheidung treffen müssen?
Man schaut also in die Support-Matrix von Suse und liest dort, dass SLE 15 bis zum 31.7.2028 unterstützt wird. Und dann lehnt man sich als IT-Entscheider erst mal wieder zurück.
Für die Unternehmen ist das gut, für Suse schlecht.
Denn ich schätze das so ein, dass man in den Unternehmen nach dem Erscheinen von SLE 16 (wenn es denn so heißt) bis auf weiteres auf SLE 15 setzen wird. SLE 16 wird man testen und den Eindruck gewinnen (egal ob richtig oder falsch), dass die Migration von SLE 15 auf 16 AUFWÄNDIGER ist (oder sein könnte) als von SLE 15 auf eine andere traditionelle Distri. Und dann wird man zu einem individuellen Zeitpunkt sagen, jetzt läuft uns bald die Zeit davon, jetzt starten wir die Migration auf eine andere Distri doch - und dann geht es ganz allmählich weg von Suse. Erst dann. Wenn es für Suse zu spät ist, eine falsche Entscheidung zu revidieren.
Ein klares Bekenntnis, wir unterstützen auch mit neueren Versionen "bis auf weiteres" eine klassische Distri würde diesen Prozess vermeiden.
Aber da sich die IT-Entscheider aufgrund der langen Support-Phase ja zurück gelehnt haben, gibt es keinerlei Druck seitens der Kunden auf Suse, eine solche Aussage zu treffen.
Entweder kommt diese Aussage von Suse irgendwann doch mal "freiwillig", dann ist alles gut und alle Migrationen sind gestorben, oder sie kommt nicht, dann kommt es genau so wie eben skizziert.
-- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Am 17.02.23 um 20:08 schrieb Christian Boltz:
Hallo zusammen,
es ist interessant zu lesen, was unter diesem Betreff diskutiert wird ;-)
Ich probiere mal einen Subject-Wechsel, auch wenn es in einem kleinen Seitenast dieser Diskussion vermutlich nicht wirklich hilft.
Ja, leider ... Ich habe diesen Beitrag nur gelesen weil er vom Christian kam. Monitorkalibierung interessiert mich so gar nicht. Vielleicht erinnern sich die alteingesessenen mal daran wann in Newsgroups und Mailinglisten sinnvollerweise ein neuer Thread geöffnet wird. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Am Mittwoch, 15. Februar 2023, 14:44:23 CET schrieb Klaus Klose:
Am Mittwoch, dem 15.02.2023 um 13:24 +0100 schrieb Eric Schirra:
Hallo Eric
Für Desktop entweder Tumbleweed
Du glaubst also, dass das dieser Zweig weiter Bestand haben wird? Dass OpenSUSE die ManPower haben wird 2 grundsätzlich verschiedene Funktionsansätze parallel zu pflegen? Ich kann das ehrlich gesagt nicht glauben...
Ob ich das glauben soll? Keine Ahnung. Bis jetzt wird es eben so verlautbart. Und in der Wiki zu Microos bezüglich Pakete steht etwas über Tumbleweed. Glauben tue ich eigentlich auch nicht dran. Das ist ja meiner Meinung auch einer der Gründe von dem Zeug. HR und BWL. :-( Deshalb schwanke ich ja unter anderem auch zwischen Tumbleweed und Manjaro. Gruß Eric
Am Mittwoch, 15. Februar 2023, 15:19:44 CET schrieb Eric Schirra:
Am Mittwoch, 15. Februar 2023, 14:44:23 CET schrieb Klaus Klose:
Am Mittwoch, dem 15.02.2023 um 13:24 +0100 schrieb Eric Schirra:
Hallo Eric
Für Desktop entweder Tumbleweed
Du glaubst also, dass das dieser Zweig weiter Bestand haben wird? Dass OpenSUSE die ManPower haben wird 2 grundsätzlich verschiedene Funktionsansätze parallel zu pflegen? Ich kann das ehrlich gesagt nicht glauben...
Ob ich das glauben soll? Keine Ahnung. Bis jetzt wird es eben so verlautbart. Und in der Wiki zu Microos bezüglich Pakete steht etwas über Tumbleweed. Glauben tue ich eigentlich auch nicht dran. Das ist ja meiner Meinung auch einer der Gründe von dem Zeug. HR und BWL. :-( Deshalb schwanke ich ja unter anderem auch zwischen Tumbleweed und Manjaro.
Gruß Eric wenn man wie ich viele Programme aus der Konsole startet ist das äußerst unkomfortabel mit den flatpak Applikationen. Wie ich in einen Thread geschrieben habe, startet bei mir audacity nicht mehr, ich muss es erst neu installieren, da läuft es bis zum nächsten reboot. Also habe ich mir nun auch mal audacity per flatpak installiert, was auch gleich läuft (allerdings noch keine reboot gemacht). Der Aufruf ist aber wieder anders als bei DisplayCal.
audacity: flatpak run org.audacityteam.Audacity DisplayCal: flatpak run net.displaycal.DisplayCAL Also was soll der Quatsch denn? Das kann ich mir in meinen Alter nicht mehr alles merken :-(. Gruß Herbert
Das Shell-Kommando 'alias' ist dir nicht bekannt? Das gab es doch vor 30 Jahren auch schon, jedenfalls ich habe es damals schon verwendet. Zum Beispiel in ~/.bashrc . Am 17.02.23 um 11:23 schrieb Herbert Albert:
wenn man wie ich viele Programme aus der Konsole startet ist das äußerst unkomfortabel mit den flatpak Applikationen. Wie ich in einen Thread geschrieben habe, startet bei mir audacity nicht mehr, ich muss es erst neu installieren, da läuft es bis zum nächsten reboot. Also habe ich mir nun auch mal audacity per flatpak installiert, was auch gleich läuft (allerdings noch keine reboot gemacht). Der Aufruf ist aber wieder anders als bei DisplayCal.
audacity: flatpak run org.audacityteam.Audacity DisplayCal: flatpak run net.displaycal.DisplayCAL
Also was soll der Quatsch denn? Das kann ich mir in meinen Alter nicht mehr alles merken :-(.
Gruß Herbert
-- Viele Grüße Michael
Am Samstag, 18. Februar 2023, 09:55:58 CET schrieb Michael Behrens:
Das Shell-Kommando 'alias' ist dir nicht bekannt?
Das gab es doch vor 30 Jahren auch schon, jedenfalls ich habe es damals schon verwendet. Zum Beispiel in ~/.bashrc . Am 17.02.23 um 11:23 schrieb Herbert Albert:
wenn man wie ich viele Programme aus der Konsole startet ist das äußerst unkomfortabel mit den flatpak Applikationen. Wie ich in einen Thread geschrieben habe, startet bei mir audacity nicht mehr, ich muss es erst neu installieren, da läuft es bis zum nächsten reboot. Also habe ich mir nun auch mal audacity per flatpak installiert, was auch gleich läuft (allerdings noch keine reboot gemacht). Der Aufruf ist aber wieder anders als bei DisplayCal.
audacity: flatpak run org.audacityteam.Audacity DisplayCal: flatpak run net.displaycal.DisplayCAL
Also was soll der Quatsch denn? Das kann ich mir in meinen Alter nicht mehr alles merken :-(.
Gruß Herbert natürlich kenne ich alias und nutze dies auch. Doch wer Programme viel mit der Konsole startet oder diese via Skripte, dann wir alias schnell voll und übersichtlich, wenn ich für 10, 20, 50 ... Programme eine alias brauche. Für meine jetzt 2 Ausnahmen ist das evtl. ok, aber nicht für die Summe der häufig verwendeten Programme.
Am 13.02.23 um 16:32 schrieb Herbert Albert:
Hallo Liste,
von Zeit zu Zeit habe ich meine Monitor mit einem Spyder2 und DisplaCal kalibriert. Nach dem Upgrade auf leap 15.4 ist mir aufgefallen, dass es DisplayCal nicht mehr für diese Version gibt. Es gibt zwar unter https://download.opensuse.org/repositories/home:/jfrede/15.4/x86_64/[1] ein Community Paket. Dies kann ich aber nicht installieren, da mir python2-numpy fehlt.
# rpm -ivh --test DisplayCAL-3.8.9.3-3.2.x86_64.rpm error: Failed dependencies: python2-numpy >= 1.0 is needed by DisplayCAL-3.8.9.3-3.2.x86_64
Liest hier jemand mit der hier Abhilfe kennt?
Im Nov. war ich an der Suche Thread: Leap 15.4 Problem: DisplayCAL findet python2-psutil nicht Lösung über Flatpack Etwas später, Thread: Tumbleweed und Displaycal was [ Re: Leap 15.4 Problem: DisplayCAL findet python2-psutil nicht] Gruß Peter
participants (14)
-
Bernd Nachtigall -
Bernd Obermayr -
Christian Boltz -
Eric Schirra -
Herbert Albert -
Jörg Thümmler -
Klaus Klose -
Manfred Haertel, DB3HM -
Manfred Kreisl -
Michael Behrens -
Peter Geerds -
Peter McD -
Ulf Volmer -
Volker Kohaupt