News Alternative zu Windows?: Hast du Linux mal ausprobiert und wie war so die Erfahrung?

[BeBur]

Aber es lässt sich wegscripten... Wenn gewünscht.

Was genau scriptest du weg?

immer noch weniger Arbeit als bei der üblichen Windowssuppe.

Da hab ich zwiespältige Erfahrungen gemacht, eine zentrale Paketverwaltung ist halt eine Schicht Komplexität die dir auch Probleme machen kann/wird. Linux ist erst Recht eine "Suppe" sobald du nicht nur die Distro-Repos verwendest, sondern fremdrepos, snaps, appimages, ... und das ist heute im Desktop Bereich eher die Norm, quasi aus der Not heraus, weil apt und co. sich halt nicht als die Eierlegende Wollmilchsau entpuppt haben, sondern eine Qual sind für package maintainer.
Vor 10-20 Jahren waren die Einzelupdates bei Windows vllt. noch eine Qual, heutzutage kriegen das die Programme ziemlich gut hin im Hintergrund das Update einzuspielen.

 

[elgorro]

yay und chocolatey sind vergleichbar und empfehlenswert (Wer nicht selber scripten möchte). Aber zwecks PPAs hat man in spezielleren Fällen gleich unendlich Theater (z.B. große "Versionssprünge", fliegt aus dem offiziellen Pool, man benötigt ein Programm in neuerer Version, das wiederum neuere Abhängigkeiten braucht und was Altes eben nicht...). Deswegen sollte man sich bewusst sein, dass Ubuntu und Mint eigentlich so ausgelegt sind, wie sie "Fertig" daherkommen. Wers mag.

Edit: Zusätzlich zum einfacherern Updaten hat man auch eine Gewissheit, dass da nichts im Hintergrund rumdümpelt, was veraltert ist bzw. durch Bugs nicht automatisch geupdated wurde. Lohnt sich.

 

[Kuristina]

Dafür hast du "nach hinten raus" mehr Arbeit, wenn Software nicht in den Paketquellen enthalten ist

Ich hab Arch. Da ist alles drin. Snap, flatpak & co brauche ich da nicht.

 

[Fuchiii]

nicht nachvollziehen kann, ist, wie sie Windows kennen gelernt haben?

Es ist meist Bequemlichkeit. Mein Vater hat MS-Dos und später Windows in allen Versionen genutzt. Dadurch bin ich mit den Microsoft-Systemen aufgewachsen und hab von klein auf alles Step-by-step mit gelernt.

Wenn man dann mit 30 Auf Linux wechselt, ist das erstmal natürlich sehr unbequem - schließlich weis man fast nix während man in Windows einen großen Haufen Wissen abrufen kann, denn man über viele Jahre gelernt hat.

Für mich persönlich war ein großes Manko immer das Gaming, das lief einfach unter Windows deutlich besser. Jetzt wo sich das deutlich ändert, auch oder vor allem Dank Steam(Proton) und Einführung des Steamdecks, sieht die Sachlage ganz anders aus.

Ich habe einige male probiert auf Ubuntu und Derivate davon zu wechseln, und es wollte nie so 100% klappen.
Jetzt nachdem ich Manjaro installiert habe musste ich feststellen, dass ich Ubuntu einfach nicht mag

Spielen, Arbeiten, surfen - alles funktioniert wunderbar. Ja es gibt hier und da noch Spiele die nicht oder nicht zufriedenstellend laufen, aber das betrifft bei mir derzeit etwas 1 von 10 installierten Spielen.

Jedenfalls ist Windows bei mir nicht mehr auf dem Rechner, einfach weil ich kein Dual-Boot haben möchte.
Und im Prinzip lerne ich Linux gerade wie ich auch Windows gelernt habe - step by step.

Das Windows weniger Problempotential hat möchte ich allerdings deutlich zurückweisen. Wenn ich überlege was ich manchmal an Stunden am PC verbracht habe um einen Fehler zu beseitigen, oder etwas zum laufen zu bekommen, oder einen fucking 5.1 Kopfhörer zur korrekten Funktion zu überreden unter Windows....

Da nehmen sich die verschiedenen Betriebssysteme nicht viel wenn mal etwas nicht out-of-the-Box funktioniert.

 

[obtar]

Angefangen mal mit OpenSuse, hatte eine Stunde gedauert da habe ich die Oberfläche zerschossen. Die Grafikkarte wollte nicht auf 1024x768 umschalten, das war im damaligen nvidia Treiber nicht enthalten. Config Dateien selbst anlegen. Das war sehr viel gebastel.
Danach Debian benutzt, war für mich "unschlagbar" wegen den Paketabhängigkeiten. Da gab es auch ein Java basiertes Webinterface womit man Datei-/Druckerfreigaben verwalten konnte. Einziges Problem war: max Auslösung war 1024x768 wurde der Browser größer gemacht --> Ist java unter Windows abgestürzt. heutzutage bekommt man bei jeder NAS ein ganz normale Weboberfläche geboten.

Ubuntu ausprobiert, sieht bunt aus. Leider fehlt gefühlt immer was. Ist aber mMn ein sehr gutes
Einsteigerlinux.

Bin mittlerweile am Überlegen wann ich meinen SpielePC auf SteamOS oder anderes Linux mit Proton umstelle. Denn es ist wieder ein optionales Update in der Warteschlange was Ärger macht.

Auf der Arbeit läuft ein Debian Rechner (i7/3060) mit BricsCAD --> dagegen ist Autocad+Windows chancenlos geworden. Das sah 2018 noch komplett anders aus.
Hatte Autocad niemals mit WinE zum laufen bekommen, egal welche Version :-D

 

[Deklest]

Es ist meist Bequemlichkeit. Mein Vater hat MS-Dos und später Windows in allen Versionen genutzt. Dadurch bin ich mit den Microsoft-Systemen aufgewachsen und hab von klein auf alles Step-by-step mit gelernt.

Wenn man dann mit 30 Auf Linux wechselt, ist das erstmal natürlich sehr unbequem - schließlich weis man fast nix während man in Windows einen großen Haufen Wissen abrufen kann, denn man über viele Jahre gelernt hat.

Genau diese Punkt vermisse ich jedoch, wenn Windows-User meinen, Linux wäre zu frickelig und Windows wäre so einfach. Denn jeder, der sich an einen Rechner oder sonst was setzt, muss das OS erlernen. Das mag mit jüngeren Jahre tatsächlich einfacher sein, aber es ist nicht unmöglich, auch im etwas höheren Alter neue Dinge zu erlernen.

 

[andy_m4]

Da hab ich zwiespältige Erfahrungen gemacht, eine zentrale Paketverwaltung ist halt eine Schicht Komplexität die dir auch Probleme machen kann/wird.

Naja. Ein gehörigen Teil der Funktionalität hast Du auch unter Windows. Nur das da eben jedes Programm (welches nicht aus dem App-Store kommt) selbst seinen Installer/Deinstaller/Updater bastelt. Insgesamt dürfte da die Komplexität sogar höher sein als unter einem System mit Paketmanagement.

Linux ist erst Recht eine "Suppe" sobald du nicht nur die Distro-Repos verwendest, sondern fremdrepos, snaps, appimages, ... und das ist heute im Desktop Bereich eher die Norm, quasi aus der Not heraus, weil apt und co. sich halt nicht als die Eierlegende Wollmilchsau entpuppt haben, sondern eine Qual sind für package maintainer.

Es wäre natürlich nicht schlecht, wenn man sich auf ein (oder zumindest wenige) Paketverwaltungen einigen könnte. Im Grunde ist es ja Wahnsinn das quasi jede Distribution ihr eigenes Repository vorhält.
Das man es da nicht schafft mehr oder weniger mal die Sachen zu vereinheitlichen bedingt ja erst die Notwendigkeit von Flatpak und Co.

Aber klar. Du hast Recht. Der Ist-Zustand ist so wie er nun mal ist und das ist tatsächlich nicht wirklich optimal.

 

[BeBur]

Insgesamt dürfte da die Komplexität sogar höher sein als unter einem System mit Paketmanagement.

Bei Windows sind die Abhängigkeiten der Programme untereinander geringer, da diese benötigte Abhängigkeiten meist selber mitliefern anstatt sich diese mit anderen Programmen zu teilen. Das dadurch eine zentrale Verwaltungsinstanz entfällt verringert zusätzlich noch die Komplexität.
Also ich will definitiv nicht sagen, dass der gewohnte Linux-Ansatz schlechter ist, aber er bedingt mehr Komplexität und Komplexität neigt dazu, Fehler zu produzieren. Und wie wir ja schon festgestellt haben (flatpak, snap, appimage, ...) entwickelt sich Linux gerade auch in diese Richtung.
Wenn auch aus anderen Gründen, denn soweit ich weiß (Torvalds hat das paar mal erwähnt) ist das bauen und maintainen von repo Packages sehr viel Aufwand. Zusätzlich ist die Redundanz bzw. der Festplattenplatz heute kein Thema mehr. "Self contained" Programme sind schlicht weniger komplex und damit für alle Beteiligten weniger Aufwand.

Ich bin mir aber sicher, jemand wird "flatpak shares" bauen mit dessen Hilfe Programme sich flatpak Abhängigkeiten teilen können... .

 

[andy_m4]

Bei Windows sind die Abhängigkeiten der Programme untereinander geringer, da diese benötigte Abhängigkeiten meist selber mitliefern anstatt sich diese mit anderen Programmen zu teilen.

Ja. Wobei das auch nicht unbedingt dabei hilft die Komplexität zu verringern, sondern im Gegenteil. Den einzigen Vorteil den es bringt, das Du halt besser getrennt updaten kannst ohne das z.B. ein Library-Update ein Impact auf weitere Programme hast.
Auf der anderen Seite hat aber auch das seine negativen Aspekte. Um mal beim Library-Beispiel zu bleiben, das die dann teilweise gar nicht geupdatet werden und wir somit in aller Regelmäßigkeit Sicherheitslücken bestaunen dürfen die allein darauf zurückzuführen sind, das das betroffene Programm noch mit irgendeiner uralt-Version von irgendeiner Lib herum läuft.

Der zentrale Ansatz forciert da so ein bisschen das so etwas nicht so einfach durchkommt.

Und wie wir ja schon festgestellt haben (flatpak, snap, appimage, ...) entwickelt sich Linux gerade auch in diese Richtung.

Ja. Wenig überraschend mit den gleichen Problemen.
Ich möchte das auch gar nicht generell verteufeln oder so. Man muss sich bewusst sein das beide Vorgehensweisen ihre Vor- und Nachteile haben.

Ich nutze beides und versuche es möglichst so zu machen, das im jeweiligen Szenario die Vorteil-Nachteil-Ratio möglichst günstig ausfällt. Ich würde nicht sagen, das das eine klar besser als das Andere ist.

Wenn auch aus anderen Gründen, denn soweit ich weiß (Torvalds hat das paar mal erwähnt) ist das bauen und maintainen von repo Packages sehr viel Aufwand.

Es geht wenn man möglichst nah am Upstream ist. Die Probleme gehen dann los, wenn man Distributionseigene Patches hat. Oder hat verschiedene Versionsstände die nicht ganz kompatibel miteinander sind.
Das große Problem ist, das das Linux-Ökosystem halt sehr heterogen ist. Du hast es mit vielen Einzelprojekten zu tun, wo es in dem Sinne keine übergeordnete Koordination gibt. Hier und da gibt es das schon aber ist insgesamt natürlich zu wenig.

Zusätzlich ist die Redundanz bzw. der Festplattenplatz heute kein Thema mehr.

Wie gesagt. Du fängst Dir andere Probleme ein. Und ja. Plattenplatz hat man eigentlich genug. Aber auch hier ist es nicht völlig egal weils halt bestimmte Dinge (Systembackup etc.) ein bissl schwieriger macht und auch der Ressourcenbedarf ist natürlich höher wenn geladene Bibliotheken plötzlich nicht mehr zwischen Programmen geteilt werden können.

Ich bin mir aber sicher, jemand wird "flatpak shares" bauen mit dessen Hilfe Programme sich flatpak Abhängigkeiten teilen können... .

Je nach Distribution gibt es das sogar schon. Bei Flatpak sind das sogenannte Runtime-Flatpaks.

 

[PHuV]

Auf der Arbeit läuft ein Debian Rechner (i7/3060) mit BricsCAD --> dagegen ist Autocad+Windows chancenlos geworden.

BricsCAD ist aber auch nicht gerade billig (klar erheblich günstiger als AutoCAD). Wie ist es von der Bedienung, Workflow etc.? Vergleichbar, besser, schlechter...?

 

[PeterDresden]

Vor Jahren habe ich mit SuSE angefangen, dann wieder längere Zeit Windows. Mittlerweile seit knapp einem Jahr nur noch Linux, erst Ubuntu, jetzt Fedora, und seit Version 36 „Silverblue“ (stark verbesserte System-Sicherheit, da hier das Basis-System im laufenden Betrieb nur „read-only“ eingehängt ist). Außerdem setzt diese Variante verstärkt auf flatpak, was ich auch gut finde, da sich so die Trennung zwischen Basis-System und Anwendungen gut realisieren lässt. Einiges ist dafür aber auch umständlicher, z. B. GDM ein Hintergrundbild zu verpassen 🙈 - das geht unter Silverblue nur über ein selbsterstelltes rpm-Paket. Aber auch dafür gibt es bereits Anleitungen im Internet, wie fast immer eigentlich.

Letztendlich soll jeder das Betriebssystem nehmen, was ihm am meisten zusagt. Darüber diskutieren zu wollen ist sinnlose Verschwendung von Lebenszeit. 😉

 

[obtar]

BricsCAD ist aber auch nicht gerade billig (klar erheblich günstiger als AutoCAD). Wie ist es von der Bedienung, Workflow etc.? Vergleichbar, besser, schlechter...?

Du kannst dir bei Bricsys eine Testversion runterladen und dir direkt selbst ein Bild machen.
Bis zur 19er Version war Autocad eindeutig im Vorteil, ab der 20er Version hat sich Bricscad ganz einfach vorbeigemogelt. Wenn du Dialogfelder magst, die wirst du bei Brics nicht bekommen, das geht über die Befehlszeile.
Anders ist die Layersteuerung, die Layerfilter sind nicht da.
Es gehen keine Dynamischen Blöcke, die werden nur angezeigt. Da hab ich noch meine wehwehchen mit.
Brics war von der Oberfläche her früher wie Autocad 2006, jetzt musst du oben links schauen welches Programmsymbol da ist.
Exportlayout = Acad quält sich einen ab, bei Brics ist das gefühlt wie eine PDF drucken.
Ein Riesenvorteil (für mich empfunden) ist das Brics keinen Zores mit den Schriften macht, bei Acad hast du mittlerweile sehr oft den Fall das in den Textstilen ein @Arial auftaucht und dir das kopieren zwischen Zeichnungen verwehrt.
3D-Orbit mit Konzeptionell war bei Brics früher ganz krass langsamer, ist nicht mehr der Fall.
Ich benutze das überwiegend im 2D Modus (Acad+Cats im TGA), die Dateien werden schon um die 50-150MB gross. Ab ca. 20MB Datei wird Acad schon langsamer, es fängt dann mit sehr vielen zwischenspeichern an zu nerven. Bei Brics ist das nicht.
Pdfimport = macht Autocad eher eine schöne importshow, Brics machts einfach.
Von der Performance ist Bricscad eiskalt an Autocad vorbeigezogen.
Für den reinen privaten Einsatz ist das natürlich zu teuer, aber wenn du Preise für das reine Autocad Subscription Paket vergleichst. Da fühlt sich Brics wie geschenkt an.

 

[andy_m4]

Die Profi-CADler werden jetzt bestimmt lachen, aber ich für meine bescheidenen Ansprüche greife zu OpenSCAD. Dort werden Zeichnungen rein programmatisch erstellt was ich ziemlich cool finde. Vor allem da Du auf den Quelltext dann alle üblichen Edit-Tools draufwerfen kannst und auch die Möglichkeit der Metaprogrammierung hast.

Etwas nachteilig ist allerdings der fehlende Multithreading-Support. Gerade wenn die Konstruktionen komplexer sind dauert der Rendering-Prozess etwas. Da würde man sich schon manchmal wünschen, der würde die CPU-Kerne die man hat auch nutzen.

 

[obtar]

Nö, CAD ist ein breit gestreutes Feld. Bin im TGA Bereich mit c.a.t.s unterwegs. Würde OpenSCAD damit laufen, wäre es schon bei mir auf dem Schirm. =)
Da steht halt bei mir Acad/Brics an erster Stelle.

 

[LochinSocke]

Was genau scriptest du weg?

Ich jetzt nichts. Ich habe jetzt ne weile Arch und da ist alles mit yay zu finden.

Je nachdem, wie viel du mit der Zeit hinzufügst kann das immer mal ein wenig Arbeit sein (Aktualisieren von repo/keys/.., versionskonflikte, ..), zusätzlich wird heute eben oft zusätzlich snap, appimage und Co. verwendet, d.h. oft hat man am Ende Paketverwaltung + eigene Repos + snaps + Appimage.

Früher habe ich viel "weggesciptet". "Git/anderesVCS -> compilen -> paketieren -> installieren", "Binaries runterladen -> paketieren -> Installieren" und "Flatpack runterladen -> installieren". Das alles einmal die Woche ausgeführt wo das Pythonscript prüft ob es neue Pakete gibt... Lässt sich alles wegscripten.

Ist zwar im Grunde auch scheiße, wie schon rausgearbeitet wurde... Aber der Aufwand über die Zeit, lässt sich bei Linux schon reduzieren.

Ergänzung (8. September 2022)

Auf der Arbeit läuft ein Debian Rechner (i7/3060) mit BricsCAD --> dagegen ist Autocad+Windows chancenlos geworden. Das sah 2018 noch komplett anders aus.

Sehr Interessant...

Kennst du Inventor oder SolidWorks und kannst vergleichen? Auch in Bezug auf Dateimanagement? Das sind ganz klar 3D-CAD Programme, du sagst ja, du nutzt es mehr 2D. Vielleicht weißt du es ja...

Hintergrund: Ich arbeite in der Konstruktion seit ewig hauptsächlich mit IV und habe von einem ehemaligen Arbeitgeber eine alte unbegrenzte 2016 Lizenz privat gebraucht gekauft. Das läuft sang und klanglos in einer VM mit 3D-Maus und Vault Basic zum Dateihandling in einer zweiten VM.

Das mit Wine und Co habe ich die letzten 20Jahre oft probiert und nehme für Windowsprogramme seit langem grundsätzlich immer eine VM. Das schont einfach Nerven...

 

[jenzen]

Ich hab Arch. Da ist alles drin. Snap, flatpak & co brauche ich da nicht.

Ja, zumindest sehr selten, was auch OK ist. Ich bevorzuge auch die Arch-Pakete. Flatpak ist aber nicht so verkehrt im Vergleich zu Snap. Flatpak ist auch stark im Aufwärtstrend. Es gibt inzwischen einige Programme, die primär als Flatpak bereitgestellt werden, und auch welche, wo die Flatpak-Version sogar qualitativer ist als die Distri-Pakete (hab ich zumindest gelesen. OBS soll so eins sein, was von manchen Distris nicht richtig konfiguriert wird, wo dann manche Features nicht gehen). Und dass Flatpak nun etabliert ist und tatsächlich brauchbar ist, ist auch sinnvoll zu erwähnen gegenüber Entwicklern, die ansonsten vielleicht aufgrund der vielen Paketformate gar kein Linux-Paket bereitstellen würden. Linus Torvalds selbst hatte damals für seine Hobby-Tauch-App kein Linux-Paket selbst bereitgestellt, sondern hat das andere machen lassen, weil er keine Lust hatte, mehrere Pakete zu maintainen. Die Existenz von Flatpak (zusätzlich) löst also schon ein größeres Problem der Vergangenheit und bringt den Linux-Desktop overall einen größeren Schritt nach vorne, weil es ein attraktiveres und populäreres Ziel wird, und davon profitieren letztendlich alle, auch diejenigen die gar keine Lust auf Flatpaks haben.

 

[andy_m4]

Die Existenz von Flatpak (zusätzlich) löst also schon ein größeres Problem der Vergangenheit

Naja. Das Problem ist nicht erst seit Flatpak oder Snappy gelöst.
Es gibt schon seit Jahrzehnten die Möglichkeit Programme statisch zu kompilieren (sprich: statt shared-Libraries zu verwenden diese einzukompilieren). Oder auch das Programm selfcontained zu machen. Teilweise gibts dafür auch Tools wie AppImage. Das Praktische dabei ist das diese Lösungen funktionieren ohne das dafür das System darauf vorbereitet sein muss.

Das was Flatpak und Co noch hinzufügen ist eine gewisse Organisation. Quasi eine Art Paketmanager für solche Programme.
Außerdem hast Du Sandbox-Funktionalität der Sicherheit zuträglich ist.

 

[obtar]

Kennst du Inventor oder SolidWorks und kannst vergleichen? Auch in Bezug auf Dateimanagement? Das sind ganz klar 3D-CAD Programme, du sagst ja, du nutzt es mehr 2D. Vielleicht weißt du es ja...

Vom Namen her ja :-D
Die sind mehr im Maschinenbau + Konstruktion unterwegs, Inventor hatte ich mal 2008 ausprobiert. Weil es auch eine Rohrleitungs+ Armaturenbibliothek hat, aber das ist überwiegend 3D ausgerichtet. Die Art der Programme sind richtige Modellierer, da kommt Acad nicht ran.
Im TGA Bereich hast du einen mix aus 3D Komponenten und Symbolen.
Da ist das Rohr maximal als 3D Volumenmodell dargestellt, die Armatur ist aber keine echte Armatur in dem Sinne. Die ist dann ein 3D Symbol Mix. Von Oben und der Seite sieht die dann wie ein Armaturensymbol aus, in der Isometrie sieht man da 2 spitz aufeinander zulaufende Kegel. Wäre das eine tatsächlich dargestellte Armatur nach VDI3805, dann würde mir der Rechner nach der 20ten Armatur schon die Qualmwolken zeigen.

Ein paar Architekten verwenden Solidworks als Designprogramm für Renderings. Nutzen später dann wieder Archicad/Nemetschek/Spirit für die Grundriss und Schnitte.

 

[elgorro]

Außerdem hast Du Sandbox-Funktionalität der Sicherheit zuträglich ist.

Note:[/B] If AppArmor is not enabled in your system then all snaps will run in [I]devel[/I] mode which mean they will have the same unrestricted access to your system as apps installed from Arch Linux repositories. snaps