Shift13mi - Erfahrungen mit anderen Linux - Distributionen

blingbling

Original poster
Beta Tester
10 Oktober 2017
103
Hallo Gemeinde,

mich würde interessieren, was für andere Distributionen neben Ubuntu schon von euch probiert wurden und mit welchem Ergebnis hinsichtlich Gebrauchsfertigkeit. Ubuntu haut mich jetzt nicht vom Hocker, was touch angeht. Vielleicht auch gern mit Einschätzung ob für Anfänger/Fortgeschritten, wo es noch hakt, was besser als bei ubuntu läuft etc.
Icht bestimmt auch eine gute Orientierung für so manchen Nutzer*in.

Mit Besten Grüßen
 
Ubuntu selbst hat mit "Touch" nur begrenzt zu tun. Die Touch-Unterstütung ist vor allem eine Frage der Arbeitsumgebung bzw. der verwendeten Software. Und das ist (wenn ich das ungern sage) in Gnome angeblich noch mit am besten. Und zwar egal in welcher Distribution.
Ich habe hier Garuda-Linux mit KDE Plasma laufen. Da würde mir jetzt auch einiges einfallen, was verbesserbar wäre - aber ich arbeite auch nur sporadisch mit Touch. (Zum Video gucken habe ich hier MPV mit einem LUA-Script im Einsatz, mit dem man mit Touch spulen kann.)

Und warum Garuda? Warum würde man überhaupt von Ubuntu zu einer anderen Distribution wechseln wollen?

In Anbetracht der großen Verbreitung von Ubuntu ist die Entscheidung von Shift, das Shift13mi mit Ubuntu auszuliefern absolut nachvollziehbar. Das hätte ich als Hersteller auch nicht anders entschieden!

Ubuntu kommt jedoch für meinen Geschmack mit einigen Designentscheidungen, die ich für mich als sehr problematisch einstufe. Das ist vor allem eine Frage der persönlichen Vorlieben, Ansprüche und Prioritäten, die man in Bezug auf ein Betriebssystem hat:

  • Hauptversionen: Ubuntu muss regelmäßig auf eine neue Hauptversion aktualisiert werden. In der Vergangenheit hat kam es bei mir (wegen proprietärer Treibern) regelmäßig zu Problemen, die letztlich immer eine vollständige Neuinstallation erforderten. Das ist sind beim Shift13mi (das komplett OpenSource-Treiber nutzt) recht unwahrscheinliche Probleme, aber es bleibt ein Zeitaufwändiger und lästiger Vorgang, bei dem durchaus einiges schiefgehen kann.
    Bei LTS-Versionen ist das zwar ein seltenerer Prozess, aber das wird dann zu dem Preis erkauft, dass die Software schon bald in vielen Teilen veraltet ist. Neue Funktionen kommen dann erst teilweise nach Jahren beim Nutzer an. Gnome war auf dem Shift nach der ersten Aktualisierung bei mir Gnome 3.36.9. Aktuell ist 3.43.1. Da dürfte auch hinsichtlich der Touch-Funktionalität einiges zwischen liegen.

  • Die Installation von „inoffiziellen“ Programmpaketen in Ubuntu empfinde ich als sehr umständlich. Für jede Quelle muss ein eigenes PPA hinzugefügt werden.

  • Snap: Ubuntu hat eine Softwareverwaltung über apt (die Paktverwaltung von Debian, von dem Ubuntu abstammt) und Snap. Snap ist dabei so etwas wie der „Amazon-App-Store“. Eine proprietäre Platform, auf der Canonical (der Hersteller von Ubuntu) schalten und walten kann – und dem man vertrauen muss. Das ist derselbe Hersteller, der es mal für eine gute Idee gehalten hat, alle Eingaben im Programmstarter an Amazon zu verkaufen. Nein danke!
    Hinzu kommt, dass Snap schon fast wieder die „Windowisierung“ von Linux ist: Jedes Programm wird alle möglichen Abhängigkeiten nochmals auf das System, obwohl andere Programme sie schon drauf gemacht haben.
    Gut, Snap hat auch Vorteile, aber keine, die (für mich) die Nachteile aufwiegen.

  • Dateisystem: Der Standard bei Ubuntu ist eine Installation auf dem ext4-Dateisystem. Das ist zwar ein gutes Dateisystem, es fehlt (mir) aber eine sehr wichtige Funktion: Dateisystem-Snapshots. Das sind „quasi eingefrorende Abbilder“ des Dateisystems, auf die man das Dateisystem wieder zurücksetzen kann, wenn man beim Ausprobieren das System kaputt gemacht hat. (Das ist nicht das gleiche wie Timeshift auf ext4-Dateisystemen!) Ein solches Dateisystem ist „Btrfs“. Ubuntu kann man zwar auch auf Btrfs installieren, aber wenn es dafür schon neu installieren müsste, dann könnte man natürlich auch die vorherigen Probleme gleich mit beheben.

Eine Lösung würde also ein System erfordern, dass:
  • das System keine Hauptversionierung hat, sondern ein sogenanntes „rolling release“-System hat (man spielt einfach Updates ein, das war es),
  • Software tatsächlich im Kern über ein zentrales Paketmanagement verwaltet und
  • auf einem Dateisystem installiert wird, dass Dateisystem-Snapshots kann.
Arch Linux wäre eine solche Distribution. Arch Linux ist auch eine ganz hervorragende Wahl, wenn man wirklich systematisch lernen will, wie ein Linux aufgebaut ist und die Funktionsweise verstehen will. Wenn man aber a) wenig Ahnung hat und/oder b) eine komfortable Installation will, kann man einfacher auf eines der zahlreichen „Derivate“ ausweichen, die zwar auf Arch Linux basieren, aber über einen angenehmen grafischen Installer verfügen.

So ein Derivat ist „Garuda Linux“, auf das meine Wahl gefallen ist. Garuda fällt vor allem mit zahlreichen nutzerfreundlichen Vorkonfiguationen auf. (Je nach gewähltem Installationsimage aber auch durch mehr oder weniger Bloatware.)

Eine besonders wichtige davon sind automatische Dateisystem-Snapshots beim Installieren oder Entfernen von Software. Das fängt damit auch den größten Nachteil des „rolling release“ auf: Wenn was schiefgeht, kann es richtig schiefgehen. Das ist mir zwar bei Updates noch nicht passiert, aber FALLS was passiert, kann man ein System leicht zurückrollen. (Wo mir das aber schon öfter passiert ist, ist beim „rumfrickeln in Konfigurationsdateien“; da erweist sich das dann als extrem hilfreich.)

Und ja, das kann man auch mit Gnome installieren. Ich mag nur Gnome (aus vielen Gründen) nicht. Deshalb läuft hier KDE. (Ergändzend: Ich mag auch das Latte-Dock nicht, was mit Garuda dragonized KDE kommt. Das ist mir zu Apple-Like. Das kann man aber halt auch leicht wegmachen.)

[Edit: Wenn ich mal dazu komme, meine Installations-Notizen auch für andere Verständlich zu überarbeiten, werde ich die wahrscheinlich auch ins Forum stellen.)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: blingbling
Hallo zusammen,
gibt es Erfahrungen hinsichtlich der Akkulaufzeit unter anderen Linux-Distributionen? Leider wurde ich mit der Forensuche und im Ubuntu-Thread nicht fündig.
Ich brauchte unter vanilla Debian ca. 20-25% Akku / Stunde zum Surfen (YouTube) unter Firefox und etwas Python-Scripting mit bis zu 100% CPU-Auslastung, wobei
Bluetooth an,
WLAN an,
USB C Hub für externen Bildschirm via HDMI angeschlossen,
interner Bildschirm ausgeschaltet war.
 
@Dagaz und ist garuda linux eher für gamer geeignet? Zumindest habe ich das gelesen. Nicht, dass das eine sehr ressourcenhungrige Distro ist, was ich zum Zocken nicht brauche. Klingt aber recht gut, zumindest deine Begründungen dafür. Ein Tutorial, was du angeboten hast, würde ich mir auf jeden Fall anschauen und probieren.

Vielleicht gibt es auch noch mal eine Anpassung von ubuntu an shift, denn so läuft es echt nicht gut. Das wurde ja in einem anderen thread beschrieben. Ich hoffe, es kommt mal eine Meldung von shift.

Gibt es sonst noch andere Erfahrungen?
 
@Dagaz und ist garuda linux eher für gamer geeignet?

Das richtet sich an Gamer. Entsprechen auch eher an Leute mit aktueller Hardware. Was das Shift13mi ist.

Zumindest habe ich das gelesen. Nicht, dass das eine sehr ressourcenhungrige Distro ist, was ich zum Zocken nicht brauche. Klingt aber recht gut, zumindest deine Begründungen dafür.

Die Default-Einstellungen sind in Garuda durchaus "auf Leistung" getrimmt. Die haben jedoch einen sehr netten "Garuda Assistent", wo man viele der Einstellungen direkt ändern kann. Da nimmt man entsprechend die Performance-Sachen raus und wählt die Energiespar Tweaks an, die man haben will.

Hier mal ein Screenshot von meinem PC, wo ich die wegen der aktuellen Strompreise auch aktiviert habe. (Nicht von den Farben irritieren lassen. Das ist ein von mir gewähltes Theme; ein Standard-Garuda sieht anders aus.)

1668726859594.png

Der Assistent bringt aber noch deutlich mehr an Einstellungen mit:

1668727140338.png

[Edit: Was es auch noch gibt ist ein Setup-Assistent, der vieles an Softwareinstallation abnimmt. Das dürfte dann gerade für Game mit Steam, wine etc. nett sein. Da ich aber eher nicht zu der Gruppe gehöre, kann ich da nicht wirklich viel zu sagen.]

Ein Tutorial, was du angeboten hast, würde ich mir auf jeden Fall anschauen und probieren.

Das wäre weniger ein Tutorial und mehr meine Installations-Notizen. Aber ich habe im Moment einfach echt viel zu tun und komme kaum zum Überarbeiten.
 
Das wäre weniger ein Tutorial und mehr meine Installations-Notizen. Aber ich habe im Moment einfach echt viel zu tun und komme kaum zum Überarbeiten.
das meinte ich natürlich.

scheinbar bist du mit gurada aber deutlich zufriedener oder treten hardwareseitig weiterhin Probleme auf?

Auf der Status-Seite von shift ist auch immer noch die Rede von Linux-Anpassungen, was auch immer das heißen soll und keine Ahnung, ob es denn überhaupt schon eine gegeben hat!?
 
das meinte ich natürlich.

scheinbar bist du mit gurada aber deutlich zufriedener oder treten hardwareseitig weiterhin Probleme auf?

Wenn man davon ausgeht, dass "Zufriedenheit" das Verhältnis von Erwartetem zu Bekommenem ist, dann könnte das evtl. daran liegen, dass ich eine andere Erwartungshaltung habe als einige andere.

Ich bin jetzt seit gut 17 Jahren auf Linux und weiß, dass das nicht primär ein Touch-System ist und dementsprechend auch die Touch-Unterstützung sowohl in Gnome als auch in KDE noch eher in den Kinderschuhen steckt.

Abgesehen davon gibt es durchaus auch Punkte, mit denen ich eher unzufrieden bin. Aber die würde ich nur zum Teil Shift bzw. dem Gerät anlasten.

Ich habe das Gerät verschlüsselt. Entsprechend brauche ich derzeit noch immer die Tastatur am Kabel, damit ich die Systemverschlüsselung nach dem Herunterfahren oder Suspend entschlüsseln kann. (Daher auch die Frage, ob hier jemand einen Mini-Dongle mit USB-C-Anschluss und eigenem Pairing kennt, weil das Pairing dafür da sein muss, bevor irgendein System startet.) Ich hätte da auch gern eine Bildschirmtatstatur. Aber wie man die in das Grub Core Image bekommt habe ich noch nicht herausgefunden. Das ist aber nichts, wofür ich Shift oder das Gerät verantwortlich mache. (Gut, man hätte - theoretisch(!) - vermutlich(!) auch ein On-Screen-Keyboard ins BIOS integrieren können, wie das beim M$ Surface der Fall zu sein scheint - aber ob Shift es sich leisten könnte, ein derart angepasstes Custom-BIOS zu bezahlen - [hier Zweifel einfügen])

Mir fehlt auch der Zugriff auf den Neigungssensor. Ich bin mir da jetzt nicht sicher, ob das ein Problem ist, was man durch einen properitären Treiber lösen muss. Und ja, das ist eine Sache, wo Shift liefern müsste. Aber ich finde das jetzt auch nicht soooo überlebenswichtig (weil es mit xinput einen zwar lästigen aber funktionierenden Workaround gibt). Da kann ich mich noch in Geduld üben.

Auch das Handling des Powermanagements in KDE ist noch "dringend anpassungsbedürftig". (MPV kann zwar gut verhindern, dass während der Wiedergabe der Biildschirm ausgeht, Firefox tut das aber nicht.)
Andererseits kann ich das Problem mit dem Einfrieren bei Youtube-Videos nicht reproduzieren. (Vielleicht sind aber auch 25 Minuten nicht lang genug für das Problem?)

Was mich wirklich nervt, ist die Ladesteuerung. Da vermute ich, dass die früher oder später durch ein BIOS-/Firmware-Update gelöst werden muss. Das scheint ja aber auch kein Linxu-Problem zu sein und auch unter Windows aufzutreten.

Und das Flexcase ist im Liegen (euphemistisch ausgedrückt) "eher etwas instabil". Da habe ich auch noch keine wirklich akzeptable Lösung für.

Auf der Status-Seite von shift ist auch immer noch die Rede von Linux-Anpassungen, was auch immer das heißen soll und keine Ahnung, ob es denn überhaupt schon eine gegeben hat!?

Tja - das wird Dir vermutlich außer Shift niemand sagen können. Ich hatte keine Anpassungen gefunden.
Ich vermute allerdings, dass zumindst eine x11-config kommen wird, die Screen Tearing verhindert. (Ich hatte dazu im anderen Thread eine Lösung gepostet.)
 
Zuletzt bearbeitet:
Ich hätte da auch gern eine Bildschirmtatstatur. Aber wie man die in das Grub Core Image bekommt habe ich noch nicht herausgefunden.
Ich fürchte, dafür bräuchte Grub erst mal Touch-Unterstützung. Die scheint es nicht zu geben. Ich habe mir den rEFInd Bootmanager installiert, um per Touch verschiedene Betriebssysteme booten zu können. Für Grub habe ich da keine Lösung gefunden.
Mir fehlt auch der Zugriff auf den Neigungssensor.
Wie wahr. Habe schon intensiv /dev und Unterverzeichnisse durchforstet auf der Suche nach Verdächtigen, die man auslesen und beim Bewegen des 13mi beobachten könnte. Bisher vergebens. Und die Suchmaschinen geben da nicht viel her. Oder ich bin zu blöd zum Suchen.
Oder hat vielleicht jemand eine Distri gefunden, bei der die automatische Drehung tut??
Das Problem mit dem Laden/Nichtladen hatte ich komischerweise nur in den ersten zwei Tagen. Seitdem tut es wie gewünscht.
Auf der Status-Seite von shift ist auch immer noch die Rede von Linux-Anpassungen, was auch immer das heißen soll und keine Ahnung, ob es denn überhaupt schon eine gegeben hat!?
Ich habe nur zwei Wallpaper gesehen ;-)
Wünschen würde ich mir:
automatische Drehung
verbesserte automatische Helligkeitssteuerung
ein ordentliches Onscreen_Keyboard, möglichst Kontextsensitiv (also z.B. Ziffernblock, wenn nur Zahleneingabe möglich ist - das wird aber wohl von Gnome oder KDE kommen müssen)
 
Ich fürchte, dafür bräuchte Grub erst mal Touch-Unterstützung. Die scheint es nicht zu geben. Ich habe mir den rEFInd Bootmanager installiert, um per Touch verschiedene Betriebssysteme booten zu können. Für Grub habe ich da keine Lösung gefunden.
Es gibt in Arch das Paket osk-sdl, was man als Modul ins initramfs aufnehmen kann. Das Problem ist nur, dass einem das nicht hilft, wenn /boot verschlüsselt ist.
Ich habe das auch durchaus schon in Aktion gesehen - auf dem Pinephone. Wo allerdings entweder a) mit uboot gestartet wird und ich bin mir nicht sicher, ob /boot dort auch verschlüsselt ist.
Man kann auch grundsätzlich in Grub ein eigenes Core Image erstellen. Ich habe es aber noch nicht hinbekommen, da ein OSK einzubinden. Alle Beispiele dafür sind auch nur für "ich will ein anderes Keyboard-Layout". (Wenn ich mehr Zeit habe, werde ich mal bei den Grub-Entwicklern nachfragen, ob so etwas an sich überhaupt geht.)

Wie wahr. Habe schon intensiv /dev und Unterverzeichnisse durchforstet auf der Suche nach Verdächtigen, die man auslesen und beim Bewegen des 13mi beobachten könnte. Bisher vergebens. Und die Suchmaschinen geben da nicht viel her. Oder ich bin zu blöd zum Suchen.
Oder hat vielleicht jemand eine Distri gefunden, bei der die automatische Drehung tut??
Es gibt einen proprietären eGalax-Treiber. Wenn man den manuell installiert, fragt der, ob das Drehen-Feature gewollt ist. Allerdings scheint das nur mit light-dm als Session-Manager zu arbeiten (laut Installations-Script). Will man Gnome, ist das vermutlich unproblematisch. (Außer natürlich, dass man dann einen proprietären Treiber drauf hat.)

Für Arch gibt es auch das AUR-Paket "xf86-input-egalax". Das habe ich aber nicht wirklich konfiguriert bekommen. (Gut, ich hatte auch nicht die Zeit, mich da wirklich mit zu beschäftigen; mal eben kurz hat es jedenfalls nicht geklappt. Ich vermute vage, dass man in /etc/X11/xorg.conf.d eine entsprechende Konfiguration anlegen muss.

Aber erst mal hat der Stift nicht mehr richtig funktioniert, als ich das ausprobiert hatte. Dann habe ich das halt erst einmal direkt wieder weggemacht.

Das Problem mit dem Laden/Nichtladen hatte ich komischerweise nur in den ersten zwei Tagen. Seitdem tut es wie gewünscht.
Ich habe das im Moment immer wieder unregelmäßig. Vor allem, wenn man was mit Audio macht, ist das extrem lästig...

Ich habe nur zwei Wallpaper gesehen ;-)
Ich würde mir wünschen, dass die Anpassungen selbst öffentlich zugängig wären. Dann kann man das auch leichter auf andere Distributionen portieren.

Wünschen würde ich mir:
automatische Drehung
verbesserte automatische Helligkeitssteuerung
ein ordentliches Onscreen_Keyboard, möglichst Kontextsensitiv (also z.B. Ziffernblock, wenn nur Zahleneingabe möglich ist - das wird aber wohl von Gnome oder KDE kommen müssen)
Das qt5-virtualkeyboard (was plasma-bigscreen verwendet) kann man zwar für den Login in SDDM nehmen, aber ansonsten ist das vollkommen unbrauchbar. Gnome scheint da weiter zu sein. Derzeit nutze ich in Plasma "onboard". Das beißt sich allerdings mit Touchegg.
 
  • Like
Reaktionen: ggrosskopf
Es gibt in Arch das Paket osk-sdl, was man als Modul ins initramfs aufnehmen kann. Das Problem ist nur, dass einem das nicht hilft, wenn /boot verschlüsselt ist.
Ich habe das auch durchaus schon in Aktion gesehen - auf dem Pinephone. Wo allerdings entweder a) mit uboot gestartet wird und ich bin mir nicht sicher, ob /boot dort auch verschlüsselt ist.
Man kann auch grundsätzlich in Grub ein eigenes Core Image erstellen. Ich habe es aber noch nicht hinbekommen, da ein OSK einzubinden. Alle Beispiele dafür sind auch nur für "ich will ein anderes Keyboard-Layout". (Wenn ich mehr Zeit habe, werde ich mal bei den Grub-Entwicklern nachfragen, ob so etwas an sich überhaupt geht.)
Mega gut :) ich habs grad versucht, das anstelle von meinem Seit gestern funktionierenden Plymouth-encrypt zu installieren und es taugt out of the Box. Ich bin begeistert, der Text und die Tastatur sind noch nicht Deutsch, und Das Design kann noch nen Shift-logo vertragen und es meckert anfangs über fehlende Module aber es startet, und ich kann on-screen mein verschlüsselungspasswort eingeben. Ich hab dafür extra zum ausprobieren eine zweite /boot partition erstellt, meine /efi ausgehängt und sie so gelasen damit ich mich nicht vollständig auslocke, aber jetzt funktioniert auch das :D ich schau nachher noch mal rum ob ich das noch aufgehübscht bekomme :) vielleicht kann mir ja jemand von Shift bescheid sagen falls die nen Plymouth theme für grafischen Boot unter Linux haben wollen :D
 
nein, das kunstwerk hab ich jetzt nicht probiert, das krieg ich nichtmal mit grafischem passwort eingeben über plymouth-encrypt hin
 
Jemand mal das elementary OS versucht zum Laufen zu bringen, v.a. in hinsichtlich touch-Funktion?
Ein update für ubuntu seitend shiftphone scheint leider sehr lang auf sich warten zu lassen...