News Pop!_OS („Cosmic“): System76 arbeitet am neuen Desktop auf Basis von Rust

[Nighti123]

Ich programmiere mein Leben lang in C, war meine erste Sprache und ich kann eigentlich nicht verstehen, wo die Leute da Probleme mit haben.

Kommt sehr stark auf die Komplexität der Anwendung an. Bugs gehören zur SW dazu und mit RUST versucht man diese weniger in der Anzahl und Schwere halten.

 

[pseudopseudonym]

Was die Welt braucht, ist noch einen Linux-Desktop

Ja, definitv. Ich weiß, wo ich zuhause bin. Aber neuen Input braucht es auch da,

 

[Brrr]

Dennoch faszinierend wie man einfach ein Profit orientiertes Unternehmen gründen kann dass auf Linux basiert. Schlau schlau diese Murikaner

Du weisst das System76 das Geld mit der Hardware macht? Die machen nicht wirklich Geld mit Gnome.

 

[GutGilliganHyde]

Dennoch faszinierend wie man einfach ein Profit orientiertes Unternehmen gründen kann dass auf Linux basiert. Schlau schlau diese Murikaner

???

Suse, Red Hat, IBM, Microsoft und tausende andere?

Es gibt millionen von kommerziellen Produkten die Linux nutzen.

 

[Meta.Morph]

Bei meinen wenigen Stunden mit Pop_OS hat mir gefallen, das sie mit ihren Gnome-Addons versucht haben, den Workflow eines Tiling Window Managers in den Gnome-Desktop einzufügen.
Das funktionierte eher mäßig und man sah dem Desktop diese behelfsmäßige Lösung deutlich an.

Ich hoffe, dass sie mit ihrem neuen Desktop genau dorthin wollen (nur eben nativ/besser). Irgendwie fehlt bislang ein TWM der modern und zugänglich ist. Es ist schön, sich nicht mehr um die Fenster kümmern zu müssen...

 

[Caramon2]

Das ist generell (imo) einer der besten Sachen an systemd: Man kann viele individuelle Skripte und Programme schreiben, die Distroübergreifend automatisiert werden können.

Letzteres ist nicht ganz richtig:

Ich bin z. B. mit LinuxMint 17.1 angefangen, habe es aber nur bis 18.3 genutzt, weil sich mir systemd bei LinuxMint 19 schon zu tief ins System eingegraben hatte: Das fing schon damit an, dass das automatische trimmen nicht mehr ein Cronjob war und ich erst per Google suchen muaste, ob LinuxMint überhaupt noch regelmäßig trimmt und falls ja, wie ich es auf täglich ändern kann:

Statt einfach nur das fstrim-Skript per mv nach cron.daily zu verschieben, musste ich aufwändig den systemd-Timer per Editor bearbeiten.

Als ich später das gleiche bei Solus machen wollte, musste ich erst wieder suchen, weil dort die fstim.timer woanders lag. - syatemd wird also noch nicht mal einheitlich umgesetzt.

Ich will mit solchem Quatsch nicht mehr zu tun haben und nutze deswegen auch kein Windows mehr (XP war mein letztes Windows). - Stattdessen nutze ich inzwischen schon seit fast drei Jahren Artix-Runit. Das ich klar, übersichtlich und einfach: KISS in Reinform.

Wenn es Distroübergreifend sein soll, dann richtig, also reines Linux.

 

[Tanzmusikus]

😜

---

Btw. Ich freue mich schon jetzt auf die irgendwann fertige in Rust geschriebene COSMIC-DE. 😊
Dann wird sie geprüft, getestet, beäugt und "geschunden".

Wenn sie dann nach ein paar Bugfixes gut funktioniert & aussieht, bin ich nochmals froh.

 

[Lan_Party94]

Ui! Das mit den Workspaces ist ja mal mega geil! Scheint leider POP!OS exklusiv zu sein?
Egal, ausprobieren würde ich das OS nun doch mal gerne. =)

 

[JunkScore]

Ich will mit solchem Quatsch nicht mehr zu tun haben und nutze deswegen auch kein Windows mehr (XP war mein letztes Windows). - Stattdessen nutze ich inzwischen schon seit fast drei Jahren Artix-Runit. Das ich klar, übersichtlich und einfach: KISS in Reinform.

Wenn es Distroübergreifend sein soll, dann richtig, also reines Linux.

SystemD ist zugegebenermaßen recht kompliziert, es ist nunmal eine komplexe Lösung für ein komplexes Problem. Analog hier die Meinung desjenigen, der früher bei Arch die Init-Skripte organisiert hat, der sollte es ja wissen. Dass es vereinzelt Probleme gibt ist natürlich blöd (aber Zitat BSD-User Benno Rice: "it's software"), es hat aber schon seinen Grund, dass die meisten gängigen Distros systemd eingebaut haben. Selbst bei Gentoo ist der default mittlerweile systemd (wobei default bei Gentoo eher was formelles ist). Zumal das von dir beschriebene Problem eher ein Problem von Mint ist und Ubuntu/Mint generell nicht bekannt dafür sind, bei point releases eine stabile Upgradeerfahrung zu liefern.

 

[Rossie]

Als ich später das gleiche bei Solus machen wollte, musste ich erst wieder suchen, weil dort die fstim.timer woanders lag. - syatemd wird also noch nicht mal einheitlich umgesetzt.

Es gab schon immer kleinere oder größere Unterschiede zwischen Distros, was mitunter zusätzliche Mühe bedeuten mag.

Wenn man die empfohlene Methode nutzt, um Änderungen durchzuführen, hat man das beschriebene Pfadproblem aber schon mal nicht:

$ sudo systemctl edit fstrim.timer

 

[Caramon2]

@Rossie :

Ok, aber dazu muss man das 1. wissen und 2. wie automatisiert man das in einem Skript? - Ich hatte mir alles als Befehlszeilen gesammelt, die ich nach einer Neuinstallation (bei mir und im Bekanntenkreis) einfach nur ins Terminal kopiere und dann quasi in einem Rutsch gleich die fertige Installation hatte.

Als ich damals als Linux-Neuling in cron.weekly das fstrim-Skript endeckt haben, in dem "fstrim --all" ausgeführt wird, war mir sofort klar, dass damit die SSD wöchentlich getrimmt wird und dass ich es nur nach cron.daily verschieben muss (zuerst per Dateimanager als Systemverwalter), um sie täglich trimmen zu lassen.

Wieso soll ich mich erst aufwändig in systemd einarbeiten, nur um etwas so einfaches wie obiges viel umständlicher zu ändern?

Und das ist ja nur ein Beispiel: systemd zieht einen ganzen Rattenschwanz hinter sich her, was dadurch alles unübersichtlicher und umständlicher wird:

Man muss kryptische Befehle lernen, bei denen nicht ersichtlich wird, was wo erstellt oder geändert wird: Man wird mutwillig vom eigentlichen System fern gehalten und der Lerneffekt ist dadurch nahe Null.

Ich nutze Linux aber genau deswegen: Um zu lernen und auch selbst etwas umsetzen oder anpassen zu können, was von den Machern vielleicht nicht bedacht wurde.

Z. B. hatte ich ursprünglich "zramen-runit" installiert und da bei runit alles so schön übersichtlich ist, war es kein Problem, das für mich interessante in den Skripten zu finden und es weiter zu vereinfachen, damit es jeder nutzen kann, unabhängig von der Distribution:

https://www.computerbase.de/forum/threads/zswap-vs-zram-vs-zram-disk.2107871/

 

[Rossie]

Ok, aber dazu muss man das 1. wissen und 2. wie automatisiert man das in einem Skript?

SYSTEMD_EDITOR=tee systemctl edit fstrim.timer <<EOF
[Timer]
OnCalendar=
OnCalendar=daily
EOF

Als ich damals als Linux-Neuling in cron.weekly das fstrim-Skript endeckt haben, in dem "fstrim --all" ausgeführt wird, war mir sofort klar, dass damit die SSD wöchentlich getrimmt wird und dass ich es nur nach cron.daily verschieben muss (zuerst per Dateimanager als Systemverwalter), um sie täglich trimmen zu lassen.

Das Timer Konzept finde ich jetzt auch nicht wirklich schwierig zugänglich, zumal wenn man cron kennt. Man könnte die Override Datei auch an systemd vorbei erstellen, aber das erscheint mir fehlerträchtiger als der offizielle Pfad.

Wieso soll ich mich erst aufwändig in systemd einarbeiten, nur um etwas so einfaches wie obiges viel umständlicher zu ändern?

Die Antwort gibst du unten (beinahe) selbst: "Um zu lernen und auch selbst etwas umsetzen oder anpassen zu können [...]"

Man wird mutwillig vom eigentlichen System fern gehalten und der Lerneffekt ist dadurch nahe Null.

Ich denke nicht, dass einen jemand davon abhielte nachvollziehen, was die systemd Werkzeuge genau bewerkstelligen. systemd hat zu mehr Standardisierung geführt. Für meine Zwecke ist das praktisch.

Aber das ist hier ja eher offtopic, wobei es insofern vielleicht doch wieder passt, dass einige Stimmen einen weiteren Desktop beklagen. Als ob es nur einen Weg geben sollte oder könnte 🤔

 

[kim88]

Und das ist ja nur ein Beispiel: systemd zieht einen ganzen Rattenschwanz hinter sich her, was dadurch alles unübersichtlicher und umständlicher wird:

Der Punkt ist das eben auch Vorteile gibt. Einer dieser Vorteile nennt sich Parallelisierung, da nun mehrere Prozesse gleichzeitig gestartet werden können.


Ein anderer Vorteil - gerade auf mobilen Geräten mit Akkus spannend - ist das Event basierte starten. Du kannst z.b. Docker Event basiert starten lassen -> so läuft das Ding nicht permanent im Hintergrund -> startet aber automatisch sobald du was mit Docker machst.

Egal ob es um den Bootloader geht (systemd-boot), NTP und Zeitsynchronisierung (timesyncd), Netzerkprozessoe wie DHCP, etc (networkd) und vieles mehr - kommt ja laufend neues hinzu -> alls das läuft quasi über systemd.
All das konfiguriert man über systemd, mit einem einheitlichen Syntax und nicht über 30 verschiedene Dienste wie früher wo man 30 unterschiedliche Dokumentationen lesen musste.

SystemD hat viel Kritik erfahren, dennoch wurde es der Quasi Standard und alle kommerziellen und auch die meisten Hobby-Distributionen nutzen es.
Der einzige nennenswerte Fork den es gab war Devuan (die sich von Debian gespalten haben).

 

[Caramon2]

SYSTEMD_EDITOR=tee systemctl edit fstrim.timer <<EOF
[/QUOTE]
[QUOTE="Rossie, post: 27597144, member: 525491"]
[Timer]
OnCalendar=
OnCalendar=daily
EOF

Statt "mv /etc/cron.weekly/fstrim /etc/cron.daily" …

Aber das ist hier ja eher offtopic, wobei es insofern vielleicht doch wieder passt, dass einige Stimmen einen weiteren Desktop beklagen. Als ob es nur einen Weg geben sollte oder könnte 🤔

Großartig viel zu sagen gibt es zu systemd sowieso nicht mehr: Wenn man damit klar kommt, oder sich nicht damit beschäftigen will (für die, die den PC einfach nur nutzen wollen), ist es sicherlich nicht schlecht, da es sich ja sonst nicht so verbreitet hätte, aber mir ist es zu umständlich und unübersichtlich.

Wie schon geschrieben: Es geht mir nicht nur um den Timer (das war nur das erste, wo mir systemd unangenehm aufgefallen ist), sondern um den ganzen Rattenschwanz, der damit zusammenhängt.

@kim88: Das hört sich plausibel an, aber ich habe dafür keinen Bedarf. Und genau das "es kommt ja laufend was dazu" stört mich am meisten: Systemd wird vermutlich scherzhaft schon länger als Betriebsystem im Betriebssystem bezeichnet: Wie groß soll das denn noch werden?

 

[Brrr]

Als ich später das gleiche bei Solus machen wollte, musste ich erst wieder suchen, weil dort die fstim.timer woanders lag. - syatemd wird also noch nicht mal einheitlich umgesetzt.

Einmal systemctl status fstrim.timer und es hätte dir gesagt wo das File liegt. Ausser auch der Name ist anders. Dass der Service auf verschiedenen Distris anders heisst ist wohl kaum Systemd anzulasen. Genauso gut kann es mit der cron verschieden gelöst sein. Es könnte beim Root-Benutzer abgelegt sein, es könnte in /etc/crontab abgelegt sein, wenn es in /etc/cron.d abgelegt wäre, könnte es wieder verschieden benammst sein.

Schön wenn du etwas gefunden hast was dir zusagt. In meiner Wahrnehmung hat Systemd die Administration über die verschiedenen Distributionen aber sehr vereinheitlicht und vieles auch zuverlässiger gemacht als mit SysV vorher.

Ein anderer Vorteil - gerade auf mobilen Geräten mit Akkus spannend - ist das Event basierte starten. Du kannst z.b. Docker Event basiert starten lassen -> so läuft das Ding nicht permanent im Hintergrund -> startet aber automatisch sobald du was mit Docker machst.

Oder wenn du es mit udev koppelst, kannst du einen Dienst automatisch starten, wenn ein bestimmtes Gerät angeschlossen wird. Etc. etc. Ich wüsste nicht, wie ich solche Dinge noch mit alten Skripten gescheit umsetzen würde. Vermutlich würde ich im Hintergrund ständig die Hardware pollen.