|
|
|
|
|
|
|
| | Zitat von hoschi
Ich weiß nicht wie Steam loggt. Vermute mal mit syslog() oder speziell für Journald mit sd_journal_print() ? Wenn das Programm als Service läuft, wird generell jede Ausgabe nach STDOUT/STDERR zu Journald weiter geleitet.
Soweit ich weiß bietet Journald keine Möglichkeit Logmeldungen vor dem eigentlichen Logging wegzufiltern. Ich weiß, dass das andere Logger können. Hier ein paar Ideen, die von den anderen vielleicht ergänzt oder verbessert werden können:
Du könntest das Log Level Beispielsweise auf "alert" senken. Und die Ausgaben an STDOUT/STDERR in in eine Datei umleiten, welche anschließend mit Logrotate behandelt wird. Global kannst du auch Journald anweisen überhaupt keine Logs zu speichern - das würde ich wirklich nicht tun.
Wenn der HLDS in einem Container läuft, könnten die Leute mit Erfahrung über Container (Docker und Konsorten) Dir womöglich weitreichendere Möglichkeiten bieten. Der HLDS wäre dann weitgehend beschränkt, soweit ich weiß auch was Logging betrifft.
IntelliJ ist unter Archlinux derzeit kaputt. Läuft nicht mehr mit OpenJDK 8 (aktuelle Version sowieso inkompatibel), 11 und 15. Ich bin jetzt auf eine Variante von IntelliJ mit integriertem JDK umgestiegen.
Downgrade von IntelliJ schien beim mir auszureichen, aber damit hat es nur einmal gestartet. Verstehe ich nicht. Downgrade von Java sollte dagegen helfen.
https://bugs.archlinux.org/task/69283
| |
Bei IntelliJ nutzt man erfahrungsgemäss sowieso am besten die integrierte JRE und nicht die vom System. Dann hat man auch gleich andere Patches dabei, die wenn überhaupt iiiiirgendwann upstream reinkommen (besseres Filehandling, Fontpatches, sowas). Was dann für Builds, externe Tools (maven, gradle etc.) verwendet wird, lässt sich so oder so nochmal separat konfigurieren.
¤: Und sdkman sollte sowieso immer am Start sein.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 11.01.2021 18:58]
|
|
|
|
|
|
|
|
|
Vielstmöglichen Dank für den Tipp mit sdkman.
Ich muss mich zwar nicht mit IntelliJ o.ä. auseinandersetzen, aber eine wilde Mischung aus gradle-,JDK- und gelegentlich auch Android-SDKs hat mich schon so oft zum leise weinen gebracht, dass das nach manna from heaven klingt ^^
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Dardrai
Live-Boot
| |
Okay habe das System gebooted und denn TTYx Reload beheben können. TLDR ist: Live-Boot macht standardmässig ein autologin im tty und/oder gui -> das kann man deaktivieren mit einem Config file: touch /etc/live/config.conf => live-config.noautologin - wenn das File erstellt wurde, davon eine neue Squash erstellen und booten  -> Login screen erscheint und man kann sich anmelden yay
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Dardrai am 12.01.2021 9:38]
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Bei IntelliJ nutzt man erfahrungsgemäss sowieso am besten die integrierte JRE und nicht die vom System. Dann hat man auch gleich andere Patches dabei, die wenn überhaupt iiiiirgendwann upstream reinkommen (besseres Filehandling, Fontpatches, sowas). Was dann für Builds, externe Tools (maven, gradle etc.) verwendet wird, lässt sich so oder so nochmal separat konfigurieren.
¤: Und sdkman sollte sowieso immer am Start sein.
| |
Danke! Hier wird IntelliJ mit integrierter JRE ab sofort installiert. Und sdkman sollte ich mir mal ansehen, gerade weil wir wieder mehr Linuxanwender geworden. Die Kompatiblitätsprobleme in der Codebasis auf unserere Seite werden leider größer, auch organisatorisch bedingt.
Eine Zeit lang hat hier ein Kollege seine virtuelle Maschinen als Lösung angepriesen, aufwendig und unangenehm. Und letztlich Verschleppung der Probleme.
Ähnlicher Name, völlig andere Aufgabe stdman.
Dadurch habe ich erst realisiert, dass der GCC aus dem Quellcode generierte Man Pages für C++ ausliefert z.B. man std::smart_ptr, man std::vector, std::C++Intro. Die können es nicht mit handgeschriebener Dokumentation aufnehmen, deswegen habe ich auch Cppreference als Devhelp installiert. Wobei mir Zeal vom Konzept besser gefällt als Devhelp.
Die Cppreference könnte eine Basis für bessere Man Pages liefern.
// edit
Und Archlinux hat kernel.dmesg_restrict eingeschaltet. Ich bin mit meinem User in der Gruppe systemd-journal (vgl. "journalctl -k"). Aus Bequemlichkeit, und weil ich die farbliche Hervorhebung mag, habe ich zusätzlich die /etc/sysctl.d/dmesg.conf mit dmesg.restrict=0 angelegt und mir wieder dmesg freigegeben. Sowas wäre ideal um es auf der Homepage kurz zu erwähnen
// edit
Der Maintainer des Archlinux Pakets für IntelliJ erfindet auch neue Versionsnummern, die es (noch) nicht gibt. Bin ich mit meiner Verwunderung allein oder übersehe ich etwas?
Ansonsten finde ich das schlecht. Das ist genau die Art von Paketierung, die einem Upstreamentwickler nicht gefallen dürfte?
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 12.01.2021 15:40]
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
Die bindings sind aber seit Ewigkeiten so ähnlich wie möglich, auch zwischen den verschiedenen desktops. Hab ich auch so drin, es funktioniert prima und umgewöhnen will ich mich auch nicht.
| |
Ich stelle aktuell fest, dass meine Gnome-Installationen tatsächlich benutzbarer sind, als ich das bisher realisiert habe. Ich hab auf den zwei Kisten Pop!_OS druff (hauptsächlich weil dort der abnehmbare Touchscreen meines ollen Netbook-Convertibles anstandslos erkannt wird), dort sind tatsächlich vim-like Tastenkürzen vorkonfiguriert, welche meinen bisherigen garnicht unähnlich sind. Tiling ist in der aktuellen Version auch out of the box dabei, und es gibt sogar ein systray. Mit dash to panel noch dazu ist das garnicht mal so schlecht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 13.01.2021 10:22]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
...und es gibt sogar ein systray.
| |
Das habe ich gesehen 
Das Leben ohne Systray ist so schön. Hat Steam aktuell eigentlich noch eines? Ich sehe das ja nicht.
|
|
|
|
|
|
|
|
|
|
|
Boah, mir fällt hier gleich der Finger ab.
Wieso kann man beim aktuellen kack Plasma.KDE nicht mehr die Mausrad-Geschwindigkeit einstellen?
Benutzen die Entwickler alle dises Hyperscroll oder wie das heißt?
/e: Und wenn ich bei google den Suchzeitraum manuell festlegen will hängen sich die Browser (Firefox Chromium Konqueror) auf.
Wo ist die Technikwelt vor 25 Jahren falsch abgebogen? Warum funktionieren nichtmal die einfachsten Dinge zuverlässig?
Flash?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rootsquash am 17.01.2021 11:51]
|
|
|
|
|
|
|
|
|
Flash? Electron!
Die Technikwelt biegt ständig falsch ab und wiederholt Fehler. Lenovo hat mit der Touch Bar - im damaligen X1 Carbon um 2014 einen Fehler gemacht. Daraufhin hat Apple die F-Tasten entfernt und auch eine Touch Bar in den Mac Books eingebaut. Die unterschiedlichen Eigenschaften von haptischen Tastaturen und Touchscreens sind bekannt. Falls die Gerüchte stimmen hat Apple den Fehler endlich erkannt, die Touch Bar soll in den kommenden Mac Books entfallen. Bin mal gespannt ob man dann auf dem Mac wirklich die F-Tasten wieder bekommt. Ich traue Apple fast alles zu - nur keine guten Tastaturen 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 17.01.2021 19:19]
|
|
|
|
|
|
|
|
|
das falsche an electron ist doch nicht electorn selber sondern wie es eingesetzt wird?
das ist halt jedesmal ne full-blown chromium instanz -> chromium ist nen resourcen biest.
wenn man davon nur eine instanz am laufen hat, mag das gut sein. wenn man davon 12 am laufen hat ist halt doof.
sehe schon den einsatzzweck von electorn, der ist aber viiiiiiel kleiner als das wofür es geschaffen wurde. (quasi nur für kiosk systeme usw...)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 18.01.2021 9:11]
|
|
|
|
|
|
|
|
|
Ich find Electron auch nicht so schlecht. Ja, es ist ein fetter bloat. Aber es löst ein Problem, dass so bisher keiner gescheit in den Griff bekommen: Einfach Cross-Plattform UI Anwendungen die auch benutzbar sind.
Und wehe jetzt argumentiert hier irgend einer mit eine OpenSource UI-Framework wie GTK oder QT. Die sind ja in der Linux-Welt schon so fragmentiert das man nur eingeschränkt von "Cross Plattform" reden kann. Und wenn ich dann daran denke, wie das Zeug unter Windows aussieht 
|
|
|
|
|
|
|
|
|
|
|
|
Außerdem kann es jeder dahergelaufene Student mit grundlegendem Wissen in Websprachen programmieren.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Ich find Electron auch nicht so schlecht. Ja, es ist ein fetter bloat. Aber es löst ein Problem, dass so bisher keiner gescheit in den Griff bekommen: Einfach Cross-Plattform UI Anwendungen die auch benutzbar sind.
| |
Wenn's ja nur so wäre. Wie oft ich da schon über irgendwelche native dependencies gestolpert bin, die unter diesen oder jenen Umständen dann nicht verfügbar sind, mit gyp gebaut werden können sollten aber verrecken, weil dafür eine OpenSSL-Version <= 0.0.0.1.alpha bereit stehen muss; oder irgendwelche binaries zum bauen werden automatisch irgendwo gezogen, wo es aber nur Version y gibt, und die auf dem System wird ignoriert (und Patches werden überschrieben, wenn man versucht, Pfade hinzubiegen, weil yarn versucht, schlauer zu sein(?)).
Besonders schrecklich unter aarch64/arm64: looking at you, Signal: FPM wird grundsätzlich als amd64-bin gezogen, muss man installiert haben und mit Umgebungsvariable overriden, braucht phantomjs (nicht mehr maintained seit 1837?), node-zkgroup braucht laut package.json ein prä-arm64-support-ffi-napi (und zkgroup muss man separat bauen und mit roher Gewalt die gezogene binary überschreiben). libringrtc.node gibt es nur für Android als arm64-binary, also: ringrtc bauen (was einmal webrtc baut), nachdem man daran herumgepatcht hat, um die libringrtc.node-binary auch wieder direkt zu ersetzen, weil es für Linux gar nicht die idee gibt, dass da 'ne andere Architektur sein könnte, so wie es von Signal referenziert/geladen wird.
Oh, und native Wayland support ist natürlich (noch) nicht möglich, weil mit electron > 9 alles verendet.
Man muss natürlich sagen: das ist vermutlich weniger ein Problem von electron selbst, als des node/npm-Ökosystems/Abhängigkeitsmanagements und den jeweiligen Entwicklern der Projekte; es könnte vermutlich alles ganz doll schön cross platform (also: Smartphones natürlich ausgeschlossen, da kommt man mit Electron ja nicht weit  ) sein, wenn man könnte/wollte.
Und auch wenn ich mich jetzt am Beispiel Signal abgearbeitet haben mag: Signal ist ein kleines Team (<30 Leute?) mit vermutlich anderen Prioritäten, das ist dann irgendwie schon nachvollziehbar.
(und leider auch nicht mit einem kleinen PR schnell gemacht, da über x Sub-Projekte verteilt, CI-Build-Systeme zurechtkommen müssen usw.)
|
|
|
|
|
|
|
|
|
|
|
Ein alter Link. Electron ist Flash für den Desktop.
| | Zitat von [KdM]MrDeath
das falsche an electron ist doch nicht electorn selber sondern wie es eingesetzt wird?
das ist halt jedesmal ne full-blown chromium instanz -> chromium ist nen resourcen biest.
wenn man davon nur eine instanz am laufen hat, mag das gut sein. wenn man davon 12 am laufen hat ist halt doof.
sehe schon den einsatzzweck von electorn, der ist aber viiiiiiel kleiner als das wofür es geschaffen wurde. (quasi nur für kiosk systeme usw...)
| |
Electron wird nicht als Systembibliothek verwendet und frisst Ressourcen mehrfach. Das Nutzungsprinzip von Electron läuft dem Ansatz auch zuwider. Kennt ihr den Kiosksysteme mit Electron? Fahrkartenautomaten oder so?
Darf ich das Wort "eingesetzt" aufgreifen und im Zusammenhang mit der Entwicklung verwenden? Eingesetzt wird Electron, wenn man keine effiziente native Entwicklung leisten möchte oder bestehenden Webcode weiterverwenden möchte. Gute Resultate erfordern Fleiß und viel Arbeit. Electron hat die Bedarfslücke gefüllt? Wahrscheinlich könnte man viele der Electronanwendung etwas schlanker machen, aber die grundsätzlichen Probleme lassen sich so nicht lösen.
Auf der anderen Seite bin ich dankbar für mehrere Electronanwendung. Die Installation und Konfiguration von Microsoft Teams war mit Flatpak angenehmer als unter Windows mit dem sogenannten Softwarekatalog. Jetzt nimmt sich Microsoft Teams 605 MB im ruhenden Zustand und lässt sich nichtmal mit Ctrl+Q schließen. Dazu kommt noch Skype als Fallback für Kundenkommunikation. Und die Signal Desktopanwendung, welche zumindest eine aufgeräumte Oberfläche hat.
Erinnert ihr euch an den Beginn von Chrome? Google hat überall die native UI verwendet. Unter Linux Gtk, unter Mac die nativen APIs von Cocoa und unter Windows eine der APIs von Microsoft (scheinbar WTL). Chrome hatte den Ruf als schlanker, schneller Webbrowser der sich ins System einpasst. Inzwischen haben sie ein eigene UI und die Wahrnehmung ist auch anders, wobei andere Entwicklungen ebenso Einfluss hatten. Gelegentlich wird etwas nachgebessert.
Für mich ist die Situation mit Electron irgendwie besser als mit Flash. Aber Electron ist allgegenwärtig. Angeblich soll Chrome inzwischen mit einem alten Pipewire sogar Screensharing unter Wayland können. Mit Geduld sehen wir dass dann irgendwann in Electron. Und dann später in den auf Electron basierenden Webanwendungen.
Mich würde interessieren, wie Steve Jobs reagiert hätte. Er hat öffentlich Flash hingerichtet. Unter iOS sind keine fremden Webbrowserengines erlaubt. Hätte Jobs mit Electron und dem Mac App Store schon ähnlich gehandelt? Apple achtet immer restriktiv auf Effizenz, was sich dann auch auszahlt und so sind die Akkus bei den iPhones kleiner. Der Grund Flash zu verbannen war höhere Akkulaufzeiten für MacBooks. In der jetztigen Situation könnte Apple wohl auch nicht mehr reagieren.
| | Zitat von GH@NDI
Und wehe jetzt argumentiert hier irgend einer mit eine OpenSource UI-Framework wie GTK oder QT. Die sind ja in der Linux-Welt schon so fragmentiert das man nur eingeschränkt von "Cross Plattform" reden kann. Und wenn ich dann daran denke, wie das Zeug unter Windows aussieht
| |
Windows ist doch der Wilde Westen? Jeder tut was sie oder er gerade will. Einschließlich Microsoft.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 18.01.2021 12:14]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Angeblich soll Chrome inzwischen mit einem alten Pipewire sogar Screensharing unter Wayland können. Mit Geduld sehen wir dass dann irgendwann in Electron.
| |
Wayland-Unterstützung muss man momentan noch mit Flags aktivieren:
| |
| Code: |
--enable-features=UseOzonePlatform
--ozone-platform=wayland
--disable-gpu-memory-buffer-video-frames # ohne läuft bei mir (nouveau) sonst kein Video
|
|
Ab Electron 12 ist das (Wayland-Support allgemein) auch in Electron.
|
|
|
|
|
|
|
|
|
|
|
|
Oh gut. Vielleicht sehen wir ja Ende des Jahres erste Anwendungen damit.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 18.01.2021 13:52]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Ich find Electron auch nicht so schlecht. Ja, es ist ein fetter bloat. Aber es löst ein Problem, dass so bisher keiner gescheit in den Griff bekommen: Einfach Cross-Plattform UI Anwendungen die auch benutzbar sind.
Und wehe jetzt argumentiert hier irgend einer mit eine OpenSource UI-Framework wie GTK oder QT. Die sind ja in der Linux-Welt schon so fragmentiert das man nur eingeschränkt von "Cross Plattform" reden kann. Und wenn ich dann daran denke, wie das Zeug unter Windows aussieht
| |
Unter Windows geht das eigentlich (also Gtk nicht, isjaklar), aber unter Linux ist halt das Deployment von $egalwas blankes Kotzen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 18.01.2021 16:21]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
(also Gtk nicht, isjaklar)
| |
Ich komme gleich rüber
Funktioniert erstaunlich angenehm, lediglich libsoup war aufwendig. Apple ist Hölle 
|
|
|
|
|
|
|
|
|
|
|
Was ich mich immer frage wenn ich sowas les:
Wie bau ich unter Linux nen Installer für Mac/Windows der nicht drölf MB groß ist?
Acid
|
|
|
|
|
|
|
|
|
|
|
NSIS funktioniert gut unter Linux. Gewöhnungsbedürftigt historische Konfiguration, aber funktioniert. Damit paketiere ich unsere Terminalanwendung für Windows mit den Bibliotheken, Optionen und und einem Zertifikat für den Zertifikatsspeicher von Windows (Chrome, Edge). Aufwendig ist das Debuggen des Installers unter Windows. Hier ist das Paket im AUR.
Ein komprimierter Installer mit Gtk3 (Gtkmm) und mehreren Bibliotheken kommt hier auf 29 MB, mit 32 Bit und 64 Bit Versionen zusammen. Fast alle Icons von Gtk kann man weglassen, sonst wäre der Installer viel größer. Ein Stolperstein sind die Webengines, bei Gtk3 ist WebKit nicht gelinkt. Laut Kollegin war bei Ihr (damals) unter Windows die Webunterstützung bei Qt5 gelinkt, besser gleich abschalten oder wegkonfigurieren.
Tipps:
- Installer Log erstellen, so ausführlich wie möglich. Welches System, welche Architektur, welcher User, welche Rechte.
- Höhere Rechte anfragen, falls möglich.
- Mit etwas mehr Aufwand. Prüfen ob Bibliothek x in Version y auch vorhanden?
- Oder Windowsstil, gleich die Bibliothek mitliefern (dünnes Eis).
- Mit viel Aufwand, Checksummen der Dateien nach Installation prüfen. So kann man herausfinden ob ein Virenscanner undefiniertes Verhalten verursacht.
Quellcode auf Windows zu portieren ist aufwendiger, aber wenn man die Auslieferung einmal hinbekommen hat ist es ein relativ einfacher Prozess. Das ist bei MacOS viel aufwendiger.
// edit
Kernfragen nach der Größe übergangen.
// edit
Der Post sieht einfach nicht so aus wie ich das möchte.
|
|
[Dieser Beitrag wurde 16 mal editiert; zum letzten Mal von hoschi am 19.01.2021 12:18]
|
|
|
|
|
|
|
|
|
Zufallsfund. Könnt ihr ausmachen, mit was das realisiert ist?
Im amalgamierten JavaScript finde ich JQuery und Bootstrap und ein paar kleinere JavaScript Funktionen. Bei dem Video steht leider nichts. Ich weiß zumindest wie ich die Farben anpassen könnte
|
|
|
|
|
|
|
|
|
|
|
Wer verbricht diesen Mist mit den überdimensionierten Title-Bars, warum schwappt es nach und nach auf meinen XFCE-Desktop und wie werde ich es los?
|
|
|
|
|
|
|
|
|
|
|
Zu sway wechseln. Ich hab einfach keine title bars mehr
/fakeedit
Ist das nicht 'ne theming/xfwm-Sache? Müsste man eigentlich in den xfce4-settings irgendwo anpassen können.
|
|
|
|
|
|
|
|
|
|
|
Ne, die Themeing-Geschichten beeinflussen nur die Fenster der linken Art.
Nachdem ich jetzt aber noch ein paar Dialogfenster ohne Titel und Fensterkontrollen, dafür mit regulären Abbrechen/Speichern Buttons auf gegenüberliegenden Seiten der Titteleiste gesehen habe bin ich sicher: Gnome ist irgendwie schuld!1
Ich kauf mir ne Schreibmaschine.
|
|
|
|
|
|
|
|
|
|
|
Das… ist gut möglich. Ich habe dunkle Erinnerungen daran, dass gtk2/3-/qt-/whatever-theming irgendwie gleichförmig sauber hinzubekommen immer ein mittelgroßer Krampf war, und es irgendwann einfach aufgegeben \o/
…habe aber eine grobe Erinnerung an https://github.com/ZaWertun/gtk3-nocsd.
Ist im AUR, falls unter Arch. War bei mir auf dem PBP in der vorkonfigurierten Wayland-/Sway-Installation dabei, weshalb ich's beim Umstieg auf dem Hauptrechner auch einfach dazugeworfen hatte, ohne weiter danach zu schauen, ob ich's brauche.
Könnte zu deiner Problematik passen, könnte aber auch völlig daran vorbei sein – ich übernehme keinerlei Haftung für irgendwas
|
|
|
|
|
|
|
|
|
|
Gerade noch gtk3-classic in den Repos entdeckt, das wohl noch mehr Unfug rückgängig macht.
Morgen mal in Ruhe testen, wenn der Puls wieder unten ist.
|
|
|
|
|
|
|
|
|
|
|
Aw yiss \o/
Gute Sache, dass es dann doch die richtige Richtung war ^^
|
|
|
|
|
|
|
|
|
|
|
|
Die Dinger suchen das Land unter dem Namen "Gtk+ Client Side Decorations" heim.
|
|
|
|
|
|
|
|
|
|
|
|
Wenn bei sway noch so viele bugs sind würde ich auf dray warten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
