VSCodium unter Linux Mint will nicht funktionieren

[Der Martin]

Hallo miteinander,

auf vielfache Empfehlung habe ich mir nun zum Ausprobieren auch mal VSCodium installiert. Ich bin dabei nach der hier beschriebenen Art und Weise vorgegangen und habe nun die Version 1.55.2.

Die Installation als solche hat auf meinem Linux Mint 18.2 auch reibungslos geklappt. Als ich VSCodium dann aus dem Programme-Menü aufgerufen habe, erschien zwar ein Fenster mit der VSCodium-Welcome-Message und zahlreichen Quicklinks, aber das Programm reagierte nicht. Nicht auf Klicks auf einen der Quicklinks, nicht auf Klicks in die Hauptmenüzeile, nicht einmal auf einen Klick auf den Maximize-Button des Fensters^[1].

Da gleichzeitig auch der CPU-Lüfter meines PCs hörbar hochdrehte, habe ich mal einen Blick auf die Ausgabe von top geworfen. Da waren zwei codium-Prozesse, von denen jeder einen CPU-Kern zu annähernd 100% beschäftigte.

Beim Klick auf das X zum Schließen des Programmfensters passierte eine Weile nichts, dann kam die bekannte Meldung: VSCodium is not responding. Force Quit?

Nun habe ich eine Weile im Internet gesucht und festgestellt, dass dieses Verhalten an sich wohl keine Seltenheit ist - nur eine Lösung habe ich nicht gefunden. Es gibt anscheinend das eine oder andere VSCode-Plugin, das zur hohen CPU-Last beiträgt, aber das Problem der extrem hohen CPU-Last bleibt auch noch, wenn man VSCodium ohne Plugins startet.

Kennt hier von euch jemand das Problem und vielleicht sogar eine Lösung?

Live long and pros healthy,
 Martin

---

1. Der Window-Manager reagierte wohl und vergrößerte das Fenster, aber das Programm selbst war zu beschäftigt, um den Fensterinhalt an die geänderte Größe anzupassen. ↩︎

[Camping_RIDER]

Aloha ;)

Ich habe mit dem konkreten Installationsprinzip von VSCodium keine Erfahrung, weil ich (bewusst und absichtlich^[1]) VSCode nutze (so halte ich es auch mit Chrome, obwohl es Chromium gibt).

Ich wollte jetzt eben mal versuchen, dein Problem nachzuvollziehen, aber auf der Install-Seite gibt es zwei Optionen. Hast du das Repository und APT genutzt oder die flatpak-Variante? Unter Mint wäre beides denkbar.

Grüße,

RIDER

---

1. Meine persönliche Bereitschaft, proprietäre Binaries, Branding und Telemetriedatenversand zu akzeptieren steigt stark, wenn ich mich dazu völlig freiwillig entscheide. Für mich ist das nahtlos-umsteigen-können zentral. ↩︎

[Der Martin]

n'Abend Janosch,

Ich habe mit dem konkreten Installationsprinzip von VSCodium keine Erfahrung, weil ich (bewusst und absichtlich) VSCode nutze (so halte ich es auch mit Chrome, obwohl es Chromium gibt).

dann stehen wir, was "saubere" Software und Verschlüsselung angeht, auf gegenüberliegenden Positionen.

Ich wollte jetzt eben mal versuchen, dein Problem nachzuvollziehen, aber auf der Install-Seite gibt es zwei Optionen. Hast du das Repository und APT genutzt oder die flatpak-Variante? Unter Mint wäre beides denkbar.

Ähm, ersteres. Den Key und dann das Repository zu meinen Quellen hinzugefügt, dann über apt-get installiert.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Ähm, ersteres. Den Key und dann das Repository zu meinen Quellen hinzugefügt, dann über apt-get installiert.

Hm, bei mir funktioniert genau das reibungslos.

Bei mir läuft ein aktuelles Linux Mint (20.1). Bei dir auch?

Falls schlecht aufgelöste Abhängigkeiten aufgrund eines älteren Systems das Problem verursachen, könnte die Verwendung des flatpak eine geeignete Lösung sein; genau für solche Fälle hat man sowas ja vorgesehen.

Grüße,

RIDER

[Der Martin]

n'Abend,

Ähm, ersteres. Den Key und dann das Repository zu meinen Quellen hinzugefügt, dann über apt-get installiert.

Hm, bei mir funktioniert genau das reibungslos.

Bei mir läuft ein aktuelles Linux Mint (20.1). Bei dir auch?

nee, wie ich schon schrieb, ein 18.2. Wenn ich einen "überflüssigen" PC hätte, auf den ich ein 20er-Mint nebenher installieren könnte, ohne mein aktuelles System plattzumachen, hätte ich das wohl schon längst getan. So aber scheue ich den Aufwand, weil ich genau weiß, dass es dann zwei bis drei Tage dauert, bis das System wieder voll einsatzfähig ist, und zwei bis drei Wochen, bis auch alle Einstellungen wieder so sind, wie ich sie haben möchte.

Denn da ist Linux keinen Deut besser als Windows: Ein großer Teil der persönlichen Einstellungen ist leider doch global und nicht im Benutzerprofil. Individuelle Locales zum Beispiel.

Falls schlecht aufgelöste Abhängigkeiten aufgrund eines älteren Systems das Problem verursachen, könnte die Verwendung des flatpak eine geeignete Lösung sein; genau für solche Fälle hat man sowas ja vorgesehen.

Ja, aber gerade das will ich ja gern vermeiden.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

nee, wie ich schon schrieb, ein 18.2. Wenn ich einen "überflüssigen" PC hätte, auf den ich ein 20er-Mint nebenher installieren könnte, ohne mein aktuelles System plattzumachen, hätte ich das wohl schon längst getan. So aber scheue ich den Aufwand, weil ich genau weiß, dass es dann zwei bis drei Tage dauert, bis das System wieder voll einsatzfähig ist, und zwei bis drei Wochen, bis auch alle Einstellungen wieder so sind, wie ich sie haben möchte.

Ich mache schon seit langem meine Betriebssystemupgrades am laufenden Produktivsystem. Der Upgrade-Assistent funktioniert sehr gut und für den Fehlerfall wird man dazu gezwungen, vorher ein Backup mit Timeshift anzulegen, das sich mit einem einfachen Live-USB-Stick wieder einspielen liese.

Denn da ist Linux keinen Deut besser als Windows: Ein großer Teil der persönlichen Einstellungen ist leider doch global und nicht im Benutzerprofil. Individuelle Locales zum Beispiel.

Eben. Deshalb ist die Möglichkeit, mit extrem überschaubarem Risiko ein Upgrade zu machen, für mich ein echter Gewinn. Vielleicht solltest du das mal ausprobieren.

Falls schlecht aufgelöste Abhängigkeiten aufgrund eines älteren Systems das Problem verursachen, könnte die Verwendung des flatpak eine geeignete Lösung sein; genau für solche Fälle hat man sowas ja vorgesehen.

Ja, aber gerade das will ich ja gern vermeiden.

Nun ja - irgend einen Tod muss man sterben 😉

Vielleicht findest du ja noch eine Möglichkeit, wenn du gezielt nach der Installation von Codium auf Mint 18.2 suchst? Eventuell gibt es auch im Repository ältere Releases, die in Frage kommen.

Grüße,

RIDER

[Der Martin]

Hallo,

Ich mache schon seit langem meine Betriebssystemupgrades am laufenden Produktivsystem. Der Upgrade-Assistent funktioniert sehr gut und für den Fehlerfall wird man dazu gezwungen, vorher ein Backup mit Timeshift anzulegen, das sich mit einem einfachen Live-USB-Stick wieder einspielen liese.

wäre mal eine Überlegung wert. Vorher ein Komplett-Backup ...

Nun ja - irgend einen Tod muss man sterben 😉

Ja, aber ich gebe die Hoffnung nicht auf, dass ich ja doch noch irgendein Hardware-Upgrade-Kit zu einem akzeptablen Preis finde. Mit einem Mainboard, das auch mehr als 4GB kann, aber gleichzeitig auch mit stromsparenden Komponenten aufgebaut ist. Im Idealfall sogar lüfterlos.

Ich hatte ja vor einiger Zeit schon mal gedacht, das wär's - wenn's denn funktioniert hätte.

Eventuell gibt es auch im Repository ältere Releases, die in Frage kommen.

Auch eine coole Idee. Ich gehe morgen mal suchen.

Live long and pros healthy,
 Martin

[Der Martin]

Hallo,

Ich mache schon seit langem meine Betriebssystemupgrades am laufenden Produktivsystem. Der Upgrade-Assistent funktioniert sehr gut und für den Fehlerfall wird man dazu gezwungen, vorher ein Backup mit Timeshift anzulegen, das sich mit einem einfachen Live-USB-Stick wieder einspielen liese.

dazu zwei Fragen:

1. Wo finde ich diesen gut funktionierenden Upgrade-Assistenten? Ich habe auf meinem Rechner schon danach gesucht, aber nichts in der Art gefunden. Nicht in Synaptic, nicht im Control Center, nicht als eigenständiges Programm im Programme-Menü.
2. Was ist Timeshift in diesem Kontext? Eine bestimmte Backup-Software? Nach einem so verbreiteten Schlagwort zu googeln, bringt immer jede Menge Beifang und ist deshalb wenig ergiebig.

Live long and pros healthy,
 Martin

[Auge]

Hallo

2. Was ist Timeshift in diesem Kontext? Eine bestimmte Backup-Software? Nach einem so verbreiteten Schlagwort zu googeln, bringt immer jede Menge Beifang und ist deshalb wenig ergiebig.

Das ist tatsächlich eine Backup-Software. Dies ist eine (etwa vier Jahre alte) Kurzeinführung.

Tschö, Auge

[Camping_RIDER]

Aloha ;)

Genau, Timeshift ist mittlerweile das Standard-Backupprogramm für Linux Mint (auch in 18.2 verfügbar).

Das Upgradetool musst du dir für den Sprung von 18.3 auf 19 noch nachinstallieren, in späteren Versionen funktioniert es "out of the box".

Wie das geht kannst du der offiziellen Upgradeanleitung von 18.3 auf 19 entnehmen. Da findest du auch die Anweisungen zur Installation von Timeshift.

Natürlich musst du zuerst von 18.2 auf 18.3 upgraden. Das ist mit eins der Probleme, wenn man so lang mit einem Upgrade wartet: es gibt kein fast-forward, du wirst also einige Upgrades nacheinander machen müssen.

Das Upgrade auf 18.3 geht sehr einfach direkt über den Update-Manager in Mint.

Die ersten Schritte wären also:

• Timeshift installieren
• Systemsnapshot mit Timeshift erstellen
• für den Fall der Fälle: LinuxLive-USB-Stick mit Mint 18.2 erstellen (zum Backup-Restore im Fehlerfall)
• Upgrade auf Mint 18.3
• Upgrade auf Mint 19

Danach dürfte es dann meiner Erinnerung nach einfacher weitergehen mit den Upgrades.

Grüße,

RIDER

[Der Martin]

Hallo,

Die ersten Schritte wären also:

• Timeshift installieren
• Systemsnapshot mit Timeshift erstellen
• für den Fall der Fälle: LinuxLive-USB-Stick mit Mint 18.2 erstellen (zum Backup-Restore im Fehlerfall)
• Upgrade auf Mint 18.3
• Upgrade auf Mint 19

das riecht dann doch eher nach einem clean install auf einen neuen Datenträger (oder besser sogar neue Maschine).

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Die ersten Schritte wären also:

• Timeshift installieren
• Systemsnapshot mit Timeshift erstellen
• für den Fall der Fälle: LinuxLive-USB-Stick mit Mint 18.2 erstellen (zum Backup-Restore im Fehlerfall)
• Upgrade auf Mint 18.3
• Upgrade auf Mint 19

das riecht dann doch eher nach einem clean install auf einen neuen Datenträger (oder besser sogar neue Maschine).

Ansichtssache. Ich würde mit so einem alten System im Zweifel eher nicht warten wollen.

Aber ja, natürlich wird clean install grundsätzlich empfohlen. Was dagegen spricht ist der Einrichtungsaufwand, den du ja auch schon genannt hast. Das Upgraden kann dir im Zweifel diesen Aufwand ersparen, und falls was schief geht ist das ja immer noch eine Option...

Grüße,

RIDER

[Der Martin]

Hallo,

das riecht dann doch eher nach einem clean install auf einen neuen Datenträger (oder besser sogar neue Maschine).

Ansichtssache. Ich würde mit so einem alten System im Zweifel eher nicht warten wollen.

wer redet von Warten? Ich denke da schon eher kurzfristig und bin mittlerweile intensiv auf der Suche in den Online-Shops der diversen Anbieter. Andererseits: Auf vier Wochen mehr kommt's jetzt auch nicht mehr an.

Aber ja, natürlich wird clean install grundsätzlich empfohlen. Was dagegen spricht ist der Einrichtungsaufwand, den du ja auch schon genannt hast. Das Upgraden kann dir im Zweifel diesen Aufwand ersparen, und falls was schief geht ist das ja immer noch eine Option...

Es ist aber auch eine Chance, alles hinter sich zu lassen, was vielleicht die letzten fünf Jahre schiefgegangen ist. Und der Aufwand ist akzeptabel, wenn ich in der Übergangsphase die alte Kiste noch produktiv weiter nutzen kann, bis der Nachfolger flügge ist.

Auch früher in meiner Windows-Ära habe ich nie ein Upgrade gemacht, sondern immer möglichst lange gewartet, dann aber das Nachfolgesystem "from scratch" frisch aufgesetzt.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Auch früher in meiner Windows-Ära habe ich nie ein Upgrade gemacht, sondern immer möglichst lange gewartet, dann aber das Nachfolgesystem "from scratch" frisch aufgesetzt.

Es bedeutet aber gleichzeitig, dass du zwingend neue Hardware brauchst, selbst wenns die alte noch (mindestens teilweise) täte.

Ich würde dir für die Zukunft ja raten, das System einfach aktuell zu halten. Linux Mint bringt eh nur selten Upgrades raus, etwa vielleicht einmal pro Jahr, und die zeitnah einzuspielen halte ich nicht für besonders anstrengend - und dafür habe ich grundsätzlich aktuelle Softwareversionen und viel weniger Kopfschmerzen dabei, im laufenden Betrieb irgendwo dran zu scheitern, was zum Laufen zu bringen.

Sowas passiert mir regelmäßig immer nur in Altsystemen.

Man kann aus dieser Not auch eine Tugend machen. Ich habe mittlerweile nicht nur ein Daten-Backup (das habe ich schon ewig), sondern ich mache mittlerweile tatsächlich regelmäßige System-Snapshots mit Timeshift, und das habe ich ursprünglich wegen eines Betriebssystemupgrades angefangen. Inzwischen will ich mir das nicht mehr wegdenken. Ich muss mir nicht nur (wie im Daten-Backup) keine Sorgen mehr über Datenverlust machen, sondern ich muss mir jetzt tatsächlich auch keine Sorgen mehr über Aufsetz- und Einrichtungszeit machen.

Sorgenlosigkeit ist nicht immer gut, aber in solchen Dingen ein echtes Wohlfühlplus 😉

Grüße,

RIDER

[Der Martin]

Hallo,

Auch früher in meiner Windows-Ära habe ich nie ein Upgrade gemacht, sondern immer möglichst lange gewartet, dann aber das Nachfolgesystem "from scratch" frisch aufgesetzt.

Es bedeutet aber gleichzeitig, dass du zwingend neue Hardware brauchst, selbst wenns die alte noch (mindestens teilweise) täte.

einerseits: Nein, nicht zwingend. Ich könnte ja auch einen Schnitt machen und auf der vorhandenen Hardware frisch anfangen - ein Daten-Backup existiert. Andererseits: Mit einem Hardware-Upgrade liebäugle ich ja schon lange. Der limitierte Arbeitsspeicher gerät mehr und mehr zum Ärgernis.

Ich würde dir für die Zukunft ja raten, das System einfach aktuell zu halten. Linux Mint bringt eh nur selten Upgrades raus, etwa vielleicht einmal pro Jahr, und die zeitnah einzuspielen halte ich nicht für besonders anstrengend

Das ist jetzt so. In den Pre-18-Versionen war das aber immer eine größere Affäre. Ich kann mich auch noch erinnern, dass es bei Ubuntu damals hieß^[1]: Oh, ein dist-upgrade ist riskant, lass es lieber.

Man kann aus dieser Not auch eine Tugend machen. Ich habe mittlerweile nicht nur ein Daten-Backup (das habe ich schon ewig), sondern ich mache mittlerweile tatsächlich regelmäßige System-Snapshots mit Timeshift, und das habe ich ursprünglich wegen eines Betriebssystemupgrades angefangen. Inzwischen will ich mir das nicht mehr wegdenken. Ich muss mir nicht nur (wie im Daten-Backup) keine Sorgen mehr über Datenverlust machen, sondern ich muss mir jetzt tatsächlich auch keine Sorgen mehr über Aufsetz- und Einrichtungszeit machen.

Das habe ich unter Windows auch noch gemacht: Da habe ich auch alle paar Wochen ein Image der Systempartition gemacht, um selbst bei einem GAU sofort das letzte Image wieder einspielen zu können und so mit einem halbwegs aktuellen Softwarestand weiterzumachen.

Seit ich Linux nutze, habe ich das nicht mehr gemacht, weil ich im Notfall ein neues System in maximal zwei Stunden zumindest so weit aufsetzen kann, dass ich damit wieder arbeiten kann. Dann fehlen erstmal eine Menge individuelle Anpassungen und es macht noch keinen Spaß, aber es geht zumindest schon. Unter Windows hätte ich für so eine Minimalinstallation eher zwei Tage gebraucht.

Sorgenlosigkeit ist nicht immer gut, aber in solchen Dingen ein echtes Wohlfühlplus 😉

Ja, mag schon sein.

Live long and pros healthy,
 Martin

---

1. Von 9.04 bis 11.10 war ich tatsächlich noch auf Ubuntu unterwegs. ↩︎

[Camping_RIDER]

Aloha ;)

Das ist jetzt so. In den Pre-18-Versionen war das aber immer eine größere Affäre. Ich kann mich auch noch erinnern, dass es bei Ubuntu damals hieß[^1]: Oh, ein dist-upgrade ist riskant, lass es lieber.

Da hast du Recht, ich erinnere mich. Zum Glück hat sich da was getan.

Seit ich Linux nutze, habe ich das nicht mehr gemacht, weil ich im Notfall ein neues System in maximal zwei Stunden zumindest so weit aufsetzen kann, dass ich damit wieder arbeiten kann. Dann fehlen erstmal eine Menge individuelle Anpassungen und es macht noch keinen Spaß, aber es geht zumindest schon. Unter Windows hätte ich für so eine Minimalinstallation eher zwei Tage gebraucht.

Stimmt. Mir wären inzwischen aber schon die individuellen Anpassungen ein Ärgernis, das ich vermeiden möchte. Zumindest gilt das für meinen Desktoprechner, auf dem auch wirklich alles-alles an Daten und Software liegt.

Beim Laptop fühle ich mich etwas flexibler; auf dem Laptop tu ich mich mit dem Gedanken, den neu aufzusetzen, nicht ganz so schwer - das liegt wohl daran, dass ich den als optionaler begreife als meinen Desktoprechner... Oder andersrum gesprochen: Solange der Desktoprechner weiterhin alles™️ kann, was ich brauche, ist es für mich okay, wenn die Kompetenzen des Laptops dynamisch mit den konkreten Anforderungen neu hochwachsen 😉

Grüße,

RIDER

[Der Martin]

Hallo nochmal,

einerseits: Nein, nicht zwingend. Ich könnte ja auch einen Schnitt machen und auf der vorhandenen Hardware frisch anfangen - ein Daten-Backup existiert. Andererseits: Mit einem Hardware-Upgrade liebäugle ich ja schon lange. Der limitierte Arbeitsspeicher gerät mehr und mehr zum Ärgernis.

ich habe da in der Zwischenzeit etwas gefunden, was mich zumindest von der Beschreibung und den Spezifikationen her überzeugt: https://www.amazon.de/dp/B08NPM6FQQ/
Leistungsfähig und dennoch stromsparend, zwei digitale Video-Ausgänge (HDMI und DVI), vier SATAN-Anschlüsse, sogar noch echte PS/2-Anschlüsse (ich kann also meine Microsoft Intellimäuse und meine Tastatur ohne Adapeter weiter nutzen und muss nicht zwei USB-Ports verschwenden). Sogar eine echte COM-Schnittstelle hat das Board noch, so dass der USB/Sellerie-Adapter wohl auch nur noch selten zum Einsatz kommen muss^[1]. Dazu 8GB RAM und eine SSD (die habe ich schon), ein 90W-PicoPSU habe ich auch vorrätig.
Und dann kann ich mit Mint 20.1 neu einsteigen, während das alte System unangetastet weiter zur Verfügung steht - einerseits als Fallback, andererseits um all die individuellen Einstellungen zu übertragen.

Ob der Praxiseindruck hält, was die Theorie verspricht, sehe ich dann in ein paar Tagen. Nächsten Dienstag soll es voraussichtlich zugestellt werden, haben sie mir heute Nacht angekündigt.

Live long and pros healthy,
 Martin

---

1. Stimmt nicht, den werde ich weiterhin brauchen - für die meisten Seriell-Anwendungen brauche ich mittlerweile 3.3V-Pegel (zum Beispiel zum Programmieren eines ESP8266). ↩︎

[Rolf B]

Hallo Martin,

es hier zu kaufen wär besser gewesen ;)
https://smile.amazon.de/dp/B08NPM6FQQ

Rolf

[Der Martin]

Hallo,

es hier zu kaufen wär besser gewesen ;)
https://smile.amazon.de/dp/B08NPM6FQQ

ja, das ist mir hinterher auch wieder eingefallen. 😕

Live long and pros healthy,
 Martin

[Der Martin]

n'Abend,

Und dann kann ich mit Mint 20.1 neu einsteigen, während das alte System unangetastet weiter zur Verfügung steht - einerseits als Fallback, andererseits um all die individuellen Einstellungen zu übertragen.

die Basis-Installation hat nicht einmal eine Stunde gedauert, und das neue System ist zumindest gefühlt um Größenordnungen schneller, responsiver als die alte Möhre. Ich hoffe nur, dass das nach ein paar Tagen Uptime mit Browser, Mailclient und Office-Suite auch noch so ist.

Live long and pros healthy,
 Martin

[Raketenheini]

Da gleichzeitig auch der CPU-Lüfter meines PCs hörbar hochdrehte, habe ich mal einen Blick auf die Ausgabe von top geworfen. Da waren zwei codium-Prozesse, von denen jeder einen CPU-Kern zu annähernd 100% beschäftigte.

• codium -s wäre in dieser Situation (also parallel zu gestarteten, eigentlichen codium) eine gute Idee gewesen. Das ist quasi ein Minidebugger für Codium selbst.
• lsof | grep codium | less liefert womöglich auch Informationen. Ist aber „eher schwierig“ diese dann in der Datenwust zu finden…
• Steht was im syslog?

[Der Martin]

Hallo,

• codium -s wäre in dieser Situation (also parallel zu gestarteten, eigentlichen codium) eine gute Idee gewesen. Das ist quasi ein Minidebugger für Codium selbst.

Ausgabe in der Konsole:

[8886:0418/175425.580524:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.

Was sagt mir das? Ganz ehrlich: Nichts.

• lsof | grep codium | less liefert womöglich auch Informationen. Ist aber „eher schwierig“ diese dann in der Datenwust zu finden…

In der Tat. Das ergibt eine mehrere Bildschirmseiten lange Ausgabe. Wonach suche ich?

• Steht was im syslog?

Nichts, was ich mit codium assoziieren könnte.

Live long and pros healthy,
 Martin

[Raketenheini]

sandbox_linux.cc

Könnte demnach sein, dass VSCodium hier irgendwelche CPU-Erweiterungen (Virtualisierung, Threats!) voraussetzt (die Deinem Rechner womöglich fehlen) und dass der Fehler „nicht wirklich gut“ abgefangen wurde.

multiple threads in process gpu-process

Oder versuch mal den Start ohne GPU-Unterstützung:

codium --disable-gpu

Ich bin mal ganz böse: Ist halt trotzdem Code von Microsoft…

[Der Martin]

Hallo,

sandbox_linux.cc

Könnte demnach sein, dass VSCodium hier irgendwelche CPU-Erweiterungen (Virtualisierung, Threats!) voraussetzt

ja, ich hatte auch schon den Eindruck einer Bedrohung.

multiple threads in process gpu-process

Oder versuch mal den Start ohne GPU-Unterstützung:

codium --disable-gpu

Keine Änderung.

Ich bin mal ganz böse: Ist halt trotzdem Code von Microsoft…

Ja. Das könnte eine Erklärung sein. 😉
Bringt mich nur nicht wirklich weiter.

Live long and pros healthy,
 Martin

[Raketenwilli]

Bringt mich nur nicht wirklich weiter.

Hm. Das Problem liegt wohl jenseits meiner Grenzen.

Ich glaube, mit fsopen irgendwelche blockierenden Geschichten zu suchen bringt Dich auch nicht wirklich weiter.

Aber Du kannst versuchen es unter Angabe Deiner Hardware (lshw, lscpu) als Bug melden…

Letzte Idee:

Frage an Dich: Hast Du ggf. die Thread-Unterstützung im Bios abgeschaltet? Es gab da durchaus Nachrichten, denen zu folge das bestimmte Programme beschleunigen würde...

[Der Martin]

Hallo,

Bringt mich nur nicht wirklich weiter.

Hm. Das Problem liegt wohl jenseits meiner Grenzen.

das glaube ich gern, denn Schilderungen des gleichen Symptoms gibt es ja reichlich.
Auch ohne Lösung.

Aber Du kannst versuchen es unter Angabe Deiner Hardware (lshw, lscpu) als Bug melden…

Ich würde das Problem gefühlsmäßig eher bei der Software-Umgebung suchen - aber weiß man's?

Frage an Dich: Hast Du ggf. die Thread-Unterstützung im Bios abgeschaltet?

Nein. Ich wusste bis eben gar nicht, dass es sowas gibt.

Es gab da durchaus Nachrichten, denen zu folge das bestimmte Programme beschleunigen würde...

Ah ja. Kann ich mir kaum vorstellen, aber da wird ja eine Menge Unsinn verbreitet.

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Martin,

sicherlich hast du auch selbst schon die Ente losgeschickt, oder gegoogelt.

Ich finde

https://github.com/microsoft/vscode/issues/90869

Der hat sich das selbst beantwortet mit "Finally it was not a VS code issue. It was because of segfault in libc6 due to a cursor config error."

Was mir nun überhaupt GAR nichts sagt.

Andere haben Probleme, Chrome zu starten, mit der gleichen Fehlermeldung:

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

Es ist demnach nicht unbedingt ein Codium-spezifisches Problem, sondern eins im Mint Umfeld?!

Und ich finde für Chrome noch den Tipp, den Software-Rasterizer abzuschalten

--disable-software-rasterizer

Vielleicht hilft das auch bei Codium?

Rolf

[Der Martin]

Hallo Rolf,

sicherlich hast du auch selbst schon die Ente losgeschickt, oder gegoogelt.

na klar.

https://github.com/microsoft/vscode/issues/90869

Der hat sich das selbst beantwortet mit "Finally it was not a VS code issue. It was because of segfault in libc6 due to a cursor config error."

Was mir nun überhaupt GAR nichts sagt.

Mir auch nicht, wenn ich ehrlich bin.

Andere haben Probleme, Chrome zu starten, mit der gleichen Fehlermeldung:

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

Es ist demnach nicht unbedingt ein Codium-spezifisches Problem, sondern eins im Mint Umfeld?!

Chrome, oder besser gesagt Chromium, läuft bei mir allerdings völlig problemlos.

Und ich finde für Chrome noch den Tipp, den Software-Rasterizer abzuschalten

--disable-software-rasterizer

Vielleicht hilft das auch bei Codium?

Leider nicht:

Warning: 'disable-software-rasterizer' is not in the list of known options, but still passed to Electron/Chromium.

Am eigentlichen Problem, dass Codium 100% CPU beansprucht und nicht mehr reagiert, ändert sich nichts.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Noch ein Vorschlag: Spricht für dich was dagegen, mal das flatpak auszuprobieren?

Dass du das nicht produktiv verwenden willst, habe ich verstanden, aber ein rein experimentelles mal-öffnen könnte vielleicht bei der Fehlersuche helfen.

Denn wenn das flatpak tut und die normale Paketlösung nicht, dann ist mit exorbitanter Wahrscheinlichkeit tatsächlich eine nicht gut aufgelöste Abhängigkeit zu dritt-Paketen das Problem und man könnte dann ggf. in diese Richtung zumindest weitersuchen.

Wenn flatpak auch nicht tut, dann brauchen wir in Richtung Libraries und Drittsoftware als Ursache gar nicht mehr zu schielen.

Grüße,

RIDER

[Der Martin]

Hallo,

Noch ein Vorschlag: Spricht für dich was dagegen, mal das flatpak auszuprobieren?

zunächst mal nur, dass ich keine Ahnung habe, wie das mit flatpak funktioniert, bzw. wie ich meinen System das beibringe.

Denn wenn ich das richtig verstehe, muss ich erstmal irgendwas installieren, was diesen flatpak-Mechanismus realisiert.

Ich denke also frohen Mutes, "Ah, so get das!", probiere es aus, und dann erzählt mir apt-get, dass es kein Paket mit dem Namen flatpak gibt - wohl aber xdg-desktop-portal (der Beschreibung nach ein Desktop-Frontend für flatpak und snap), was seinerseits wieder flatpak referenziert.
Ein genauerer Blick hinter die Kulissen und in die Dependencies von xdg-desktop-portal zeigt unter anderem:

Breaks: flatpak
Replaces: flatpak
Conflicts: xdg-desktop-portal

Nanu? Okay, es ist also ein Ersatz für flatpak - aber ein Paket, das einen Konflikt mit sich selbst hat? Eigenartig. Das lässt mich zögern, dieses Paket einfach so zu installieren.

Denn wenn das flatpak tut und die normale Paketlösung nicht, dann ist mit exorbitanter Wahrscheinlichkeit tatsächlich eine nicht gut aufgelöste Abhängigkeit zu dritt-Paketen das Problem und man könnte dann ggf. in diese Richtung zumindest weitersuchen.

Klingt schlüssig.

Live long and pros healthy,
 Martin

[Camping_RIDER]

Aloha ;)

Eben getestet: Beachte den Halbsatz unter dem Kommandozeilenbefehl (der bei mir übrigens auch funktioniert?).

(https://vscodium.com/#flatpak)

Wenn bei dir der Kommandozeilenbefehl nicht funktioniert, müsste ja trotzdem der Weg über die Mint-Anwendungsverwaltung funktionieren. Dazu einfach das flatpakref-File runterladen und ausführen oder, noch viel einfacher:

Die "Anwendungsverwaltung" (im Terminal heißt die mintinstall) öffnen und nach VSCodium suchen.

Grüße,

RIDER

[Der Martin]

Hallo Janosch,

(https://vscodium.com/#flatpak)

Wenn bei dir der Kommandozeilenbefehl nicht funktioniert

was heißt funktioniert?
flatpack: command not found

müsste ja trotzdem der Weg über die Mint-Anwendungsverwaltung funktionieren. Dazu einfach das flatpakref-File runterladen und ausführen

Ausführen womit? Mein System weiß nicht, was das sein soll, und im Dateimanager wird mir diese Datei als Plain Text File angezeigt (was ja technisch gesehen auch stimmt), und bei Doppelklick im Editor geöffnet.

oder, noch viel einfacher:

Die "Anwendungsverwaltung" (im Terminal heißt die mintinstall) öffnen und nach VSCodium suchen.

Hehe, mintinstall habe ich noch nie benutzt. Okay, Codium gefunden, als Status wird angezeigt "Installed". Das ist dann aber nur die normale deb-Installation, die nicht laufen will.

Flatpack oder sonstwas? Keine Spur davon weit und breit. Scheint meinem Mint völlig fremd zu sein. Wurde womöglich erst in Mint 19+ nativ eingeführt.

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

flatpak

vs.

flatpack

Gruß
Kalk

[Auge]

Hallo

Denn wenn ich das richtig verstehe, muss ich erstmal irgendwas installieren, was diesen flatpak-Mechanismus realisiert.

Genau, nämlich Flatpak.

„Flatpak support is built into Linux Mint 18.3 and newer—no setup required!
If you are using an older version, upgrade to Linux Mint 18.3.“

Welche Mint 18.x benutzt du doch gleich? Mit deinem 18.2 wird das wohl nix mit dem Originalpaket von Flatpak. Wenn ich mich recht entsinne, war Flatpak erst mit Ubuntu 18.04 möglich ^[1] und dein Mint 18.2 basiert noch auf Ubuntu 17.10.

Ich denke also frohen Mutes, "Ah, so get das!", probiere es aus, und dann erzählt mir apt-get, dass es kein Paket mit dem Namen flatpak gibt - wohl aber xdg-desktop-portal (der Beschreibung nach ein Desktop-Frontend für flatpak und snap), was seinerseits wieder flatpak referenziert.
Ein genauerer Blick hinter die Kulissen und in die Dependencies von xdg-desktop-portal zeigt unter anderem:

Breaks: flatpak
Replaces: flatpak
Conflicts: xdg-desktop-portal

Nanu? Okay, es ist also ein Ersatz für flatpak - aber ein Paket, das einen Konflikt mit sich selbst hat? Eigenartig. Das lässt mich zögern, dieses Paket einfach so zu installieren.

Meine Interpretation: xgd-desktop-portal bringt siene eigene Flatpak-Instanz mit, die das Original ersetzt *und daher mit diesem (jedoch nicht mit sich selbst) im Konflikt steht.

Tschö, Auge

---

1. edit: Nein, ich lag falsch. Nativen Support für Flatpak (ohne Fremdquellen) gibt es in Ubuntu erst ab 18.10. Aber vielleicht ist ja das PPA etwas für dich … ↩︎

[Der Martin]

Hi,

Denn wenn ich das richtig verstehe, muss ich erstmal irgendwas installieren, was diesen flatpak-Mechanismus realisiert.

Genau, nämlich Flatpak.

wer hätte das gedacht? 😉

„Flatpak support is built into Linux Mint 18.3 and newer—no setup required!
If you are using an older version, upgrade to Linux Mint 18.3.“

Welche Mint 18.x benutzt du doch gleich? Mit deinem 18.2 wird das wohl nix mit dem Originalpaket von Flatpak. Wenn ich mich recht entsinne, war Flatpak erst mit Ubuntu 18.04 möglich und dein Mint 18.2 basiert noch auf Ubuntu 17.10.

Nein, alle 18.x basieren auf Ubuntu 16.04, die 19er-Mints dann auf 18.04.

Nativen Support für Flatpak (ohne Fremdquellen) gibt es in Ubuntu erst ab 18.10. Aber vielleicht ist ja das PPA etwas für dich …

Wenn ich eins finde^[1], könnte auch das eine Alternative sein. Aber ehrlich gesagt geht mir das so langsam auf den Senkel, dass ich allmählich die Lust verliere. So viel Aufwand für etwas, das ich in Wirklichkeit sowieso ablehne?

Live long and pros healthy,
 Martin

---

1. Ah, hab's gefunden, so zwischen den Zeilen versteckt. ↩︎

[Camping_RIDER]

Aloha ;)

Nein, alle 18.x basieren auf Ubuntu 16.04, die 19er-Mints dann auf 18.04.

Ich denke die einzig nachhaltige Lösung ist das Betriebssystem-Upgrade.

Im Grunde sind wir uns ja einig, dass es trotz LTS keine besonders gute Idee ist, auf ein Betriebssystem zu setzen, das im Grunde schon 5 Jahre alt ist und außer absolut wichtigen Sicherheitsupdates nicht weiter mit neuen Versionen versorgt wird.

Grüße,

RIDER

[Raketenwilli]

Im Grunde sind wir uns ja einig, dass es trotz LTS keine besonders gute Idee ist, auf ein Betriebssystem zu setzen, das im Grunde schon 5 Jahre alt ist und außer absolut wichtigen Sicherheitsupdates nicht weiter mit neuen Versionen versorgt wird.

Nur bei Desktops, deren Anwender „hin- und wieder“ Wert auf neue Funktionen einzelner oder vieler Programme legen.

Bei Servern und „speziell eingesetzten Computern“ (embedded Kram, Industrieanwendungen, …) sieht das ganz anders aus. Da will man vor allem, dass sich nichts, aber auch gar nichts an APIs, Programmoptionen, Konfigurationsdateien (und ~Optionen) und dergleichen ändert. Denn Funktionsupdates haben (wegen der in solchen Systemen üblichen Automatisierung durch „Verskripten“) auch Neben- und Seiteneffekte. Man will also, um die Systemstabilität durch Programmupdates nicht zu gefährden, regelmäßig genau nur die „absolut wichtigen Sicherheitsupdates“.

Wobei jedes Sicherheitsupdate „absolut wichtig“ ist. Deshalb gibt es ja die „Backports“

[Der Martin]

Hi,

Bei Servern und „speziell eingesetzten Computern“ (embedded Kram, Industrieanwendungen, …) sieht das ganz anders aus. Da will man vor allem, dass sich nichts, aber auch gar nichts an APIs, Programmoptionen, Konfigurationsdateien (und ~Optionen) und dergleichen ändert. Denn Funktionsupdates haben (wegen der in solchen Systemen üblichen Automatisierung durch „Verskripten“) auch Neben- und Seiteneffekte.

deswegen laufen bis heute noch zahlreiche Industrie-PCs, die Teil von Maschinensteuerungen sind, oder in Mess- und Prüfgeräte integrierte PCs unter Windows XP. Allerdings sind die dann in aller Regel nicht mit dem Internet verbunden, sondern höchstens mit dem Firmen-Intranet. Sie laufen also innerhalb einer kontrollierten Umgebung.

Live long and pros healthy,
 Martin

[Raketenwilli]

Windows XP

Das kann man nicht wirklich vergleichen. Windows XP bekommt keine Sicherheitsupdates mehr, bei LTS-Versionen der Linux- und BSD-Distros ist genau dieser Punkt (vor Ablauf der Unterstützung) ganz anders.

Deshalb kann man die (sofern alles sauber mit „apt, yum, yast, port & co.“ installiert wurde) auch im Netz lassen…

[Auge]

Hallo

Genau, nämlich Flatpak.

wer hätte das gedacht? 😉

Ja, Käpt'n Obvious war wieder unterwegs. 😅

… ehrlich gesagt geht mir das so langsam auf den Senkel, dass ich allmählich die Lust verliere. So viel Aufwand für etwas, das ich in Wirklichkeit sowieso ablehne?

Tja, schöner wäre natürlich, dass Codium aus dem OS-eigenen Repo verfügbar wäre und einfach so funktionieren würde. Scheint aber für deine OS-Version nicht zu so sein. Ob du diesen Aufwand mit den Fremdquellen, die du bekanntermaßen ablehnst, betreiben willst, nur um zu testen, ob Codium mit paketinterner Auflösung aller Abhängigkeiten störungsfrei funktioniert, musst du wissen. Dass du unter diesen Voraussetzungen wenig Lust dazu hast, kann ich verstehen.

Zum Schluss bleibt die Aussage von Camping_RIDER zum Upgrade des OS übrig. Vermutlich lösten sich einige (wenn nicht alle) der hier aufgekommenen Probleme damit in Wohlgefallen auf.

Tschö, Auge

[Der Martin]

Hallo,

… ehrlich gesagt geht mir das so langsam auf den Senkel, dass ich allmählich die Lust verliere. So viel Aufwand für etwas, das ich in Wirklichkeit sowieso ablehne?

Tja, schöner wäre natürlich, dass Codium aus dem OS-eigenen Repo verfügbar wäre und einfach so funktionieren würde. Scheint aber für deine OS-Version nicht zu so sein.

genau, und der Countdown läuft. Für Mint 18 soll der Support in diesem Monat auslaufen. Die Erfahrung zeigt zwar, dass es danach meist noch für zwei, drei Monate Kulanzupdates gibt, aber der grundsätzliche Weg ist klar.

Ob du diesen Aufwand mit den Fremdquellen, die du bekanntermaßen ablehnst, betreiben willst, nur um zu testen, ob Codium mit paketinterner Auflösung aller Abhängigkeiten störungsfrei funktioniert, musst du wissen.

Es sind gar nicht die Fremdquellen, die ich ablehne; ich benutze ja selbst Fremdquellen, solange sie deb-Pakete zur Verfügung stellen, die ich mit dem distro-eigenen Paketmanagement installieren und aktuell halten kann.

Was ich ablehne, sind vom Konzept der Distro abweichende, völlig andere Arten, Software bereitzustellen und zu verwalten.

Dass du unter diesen Voraussetzungen wenig Lust dazu hast, kann ich verstehen.

Na immerhin. 😉

Zum Schluss bleibt die Aussage von Camping_RIDER zum Upgrade des OS übrig. Vermutlich lösten sich einige (wenn nicht alle) der hier aufgekommenen Probleme damit in Wohlgefallen auf.

Ja, das ist ja auch mein erklärtes Ziel. Nur halt mit gewissen Voraussetzungen. Zum Beispiel ein neues Mainboard oder ein komplett neuer PC mit mehr als 4GB Arbeitsspeicher (ich strebe 8GB an), aber deutlich <100W Leistungsaufnahme. Die "nur" 4GB werden mehr und mehr zum Ärgernis, wenn man beim Switchen von einer Anwendung zur anderen erstmal eine Swap-Orgie >30s abwarten muss.

Live long and pros healthy,
 Martin

[Raketenwilli]

Die "nur" 4GB werden mehr und mehr zum Ärgernis, wenn man beim Switchen von einer Anwendung zur anderen erstmal eine Swap-Orgie >30s abwarten muss.

Das finde ich seltsam. Grund:

~$ free -h
              gesamt      belegt       frei     gemeinsam    Zwischen   verfügbar
Speicher:        31Gi       2,1Gi        23Gi       135Mi       6,0Gi        28Gi
Auslager:       2,0Gi          0B       2,0Gi

Das ist ein voll ausgetatteter XUbuntu-Desktop, mit dem ich heute schon den ganzen Tag „unterwegs“ bin. Was (zum Teufel) frisst bei Dir so viel Speicher, dass es beim „Anwendungsswitch“ zu einer "Swap-Orgie >30s" kommt?

[Der Martin]

Hallo,

Die "nur" 4GB werden mehr und mehr zum Ärgernis, wenn man beim Switchen von einer Anwendung zur anderen erstmal eine Swap-Orgie >30s abwarten muss.

Das finde ich seltsam. Grund:

~$ free -h
              gesamt      belegt       frei     gemeinsam    Zwischen   verfügbar
Speicher:        31Gi       2,1Gi        23Gi       135Mi       6,0Gi        28Gi
Auslager:       2,0Gi          0B       2,0Gi

Das ist ein voll ausgetatteter XUbuntu-Desktop, mit dem ich heute schon den ganzen Tag „unterwegs“ bin. Was (zum Teufel) frisst bei Dir so viel Speicher, dass es beim „Anwendungsswitch“ zu einer "Swap-Orgie >30s" kommt?

die größten Speicherfresser sind Browser, X.org, Mailclient, Office und der Dateimanager Caja. Im Moment ist die Lage gerade entspannt, aber trotzdem mal ein top-Auszug nach Speicher sortiert (M):

top - 15:39:09 up 193 days, 13:46,  1 user,  load average: 0.80, 0.32, 0.43
Tasks: 189 total,   2 running, 187 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.9 us,  3.2 sy,  0.0 ni, 71.9 id, 19.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  3914592 total,   294856 free,  3365892 used,   253844 buff/cache
KiB Swap:  8000508 total,  5235312 free,  2765196 used.   279188 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                 
 1135 root      20   0 1317444 807132   9584 S   4.7 20.6   7015:37 Xorg                                    
31425 mk        20   0 3412632 731524  57388 S   5.3 18.7  47:17.04 palemoon                                
31660 mk        20   0 3794972 606576  21740 S   2.3 15.5 486:22.75 thunderbird                             
29333 mk        20   0 2286308 447132   6180 S   0.0 11.4   1465:15 vlc                                     
 1546 mk        20   0 2071388 291760   8964 S   0.0  7.5 528:12.64 caja                                    
13175 mk        20   0 2219748 155592  25172 S   0.0  4.0 270:29.98 soffice.bin                             
 1600 mk        20   0  778440  24000   3884 S   0.0  0.6  62:04.95 wnck-applet                             
 1578 mk        20   0  686308  17752   1964 S   0.3  0.5  16:01.06 mintmenu                                
19335 mk        20   0 1229100  17572   2468 S   0.0  0.4  15:25.49 xed                                     
 1602 mk        20   0  652908  15724   8904 S   0.3  0.4 619:06.78 clock-applet                            
 1845 mk        20   0  801856  11992   2244 S   0.0  0.3   5:30.98 mintUpdate                              
15052 mk        20   0  589392  11268   5252 S   2.7  0.3  60:56.90 mate-terminal                           
 1703 mk        20   0  541688  10208   5344 S   0.0  0.3  66:17.98 marco                                   
 1527 mk        20   0  597884   7268   2280 S   0.0  0.2  36:02.00 mate-panel                              
 1518 mk        20   0 1010680   6704   3000 S   0.0  0.2  44:11.40 mate-settings-d                         

Die genannten Kandidaten belegen also momentan schon etwa 3GB RAM. Virtuell, also "versprochen, um bei Bedarf darauf zugreifen zu können", kommen sie sogar auf fast 16GB. Bei einem Taskswitch zum geöffneten Office-Dokument nimmt soffice.bin beispielsweise mal eben einen Teil der versprochenen 2GB in Anspruch, es sind aber nur noch knapp 300MB frei, also muss geswappt werden.
Wie gesagt, das ist ein Snapshot in einer relativ ruhigen Phase.

Ich frage mich auch, warum xed, der MATE-eigene Texteditor, über 1GB virtuellen Speicher beansprucht, obwohl er nur eine Textdatei von wenigen kB Größe geöffnet hat. Oder was T-Bird mit fast 4GB virtuellem Speicher will. free -h sagt bei mir übrigens im Augenblick:

              total        used        free      shared  buff/cache   available
Mem:           3.7G        3.3G        226M         10M        250M        212M
Swap:          7.6G        2.6G        5.0G

Live long and pros healthy,
 Martin

[Raketenzielsuchbeauftragter]

Link:

https://www.tecchannel.de/a/festplatten-fuer-linux-im-leistungs-check,3198536,2

[Raketenzielsuchbeauftragter]

Erst

# Zum Testen:
cat 20 | sudo tee /proc/sys/vm/swappiness
sudo swapoff -a
sudo swapon -a

und mit verschiedenen Werten (1 … 100 statt 20) testen. Dann:

#Dauerhaft:
if [ "0" = $(grep "swappiness"  /etc/sysctl.conf | wc -l) ]
then
    echo "swappiness = 20" | sudo tee -a /etc/sysctl.conf;
else
    sudo $EDITOR /etc/sysctl.conf
fi