Ich setze derzeit auf dem Desktop nur Windows ein, wobei ich ab und an schon das Fluchen bekomme, wenn ich diverse Libs zum Programmieren benötige. GeoDjango unter Windows habe ich aufgegeben zum Laufen zu bekommen.
Ich habe unter Linux alles was ich brauche, mit der Ausnahme von ein paar Programmen und Spielen.
Dafür wiederum läuft auf meinem Linux eine VM mit Windows und PCIe Passthrough für die Grafikkarte.
Obwohl es mir eigentlich mehr um Servereinsatz ging (habe ich aber nicht explizit dazu geschrieben), ist es doch interessant, wie viele Leute Linux auf dem Desktop einsetzen.
Ich setze derzeit auf dem Desktop nur Windows ein, wobei ich ab und an schon das Fluchen bekomme, wenn ich diverse Libs zum Programmieren benötige. GeoDjango unter Windows habe ich aufgegeben zum Laufen zu bekommen.
Beste Suits für eigentich alles unter Windows: https://www.jetbrains.com/
Ich nutze inzwischen tatsächlich für alles (Desktop, Laptop, private Server) Arch Linux - meines Erachtens größte Auswahl an Paketen, aktuelle Versionen und Rolling Release. Und es läuft ziemlich stabil.
desktop: debian, server: debian oder centos/rhel
Server: ausschließlich debian
Desktop: gestartet seinerzeit mit Suse 6.0
und immer mit Mandrake (heute Mandriva)
als Alternative geliebäugelt . Als Suse dann verkauft
und Mandrake kurze Zeit später auch, bin ich dann
auch auf dem Desktop zu debian gewechselt
Auf dem Laptop habe ich ein (K)Ubuntu
aber das nutze ich 2-3 mal jährlich
Beste Suits für eigentich alles unter Windows: https://www.jetbrains.com/
Ich bin mit Visual Studio Code mittlerweile ganz zufrieden, verwende das für fast alles. Wobei die IDEs von Jetbrains sicher in einigen Bereichen noch besser sind.
Aber mein Problem war eher das Installieren der ganzen Abhängigkeiten, die GeoDjango benötigt. Evtl. als Hintergrund, GeoDjango ist eine Erweiterung für das Webframework Django, womit man recht leicht GIS (Geoinformationssysteme) erstellen kann. Wenn man mehr brauch also nur Längen- und Breitengrad, ist das ganz nett. Unterstützt auch direkt postgis. Damit unterstützt dann Postgres die Speicherung von z. B. Polygonen aus GPS Koordinaten und man kann das auch direkt im SQL verwenden, also z. B. direkt Abfragen, ob eine GPS-Koordinate in bestimmten Orten liegt (für die man vorher Polygone definiert hat, oder z. B. von Open Street Map heruntergeladen hat).
Aber das ganze benötigt mehrere Libs und ich habe bei einer immer Fehler bekommen, Den ersten konnte ich beheben, lag an einer dll, die ´nicht die sqlite dll in ihrem eigenen Verzeichnis verwendet hat, sondern die sqlite dll im virtual environment von python... Nachdem ich das behoben hatte, kam es aber zu weiteren Fehlern usw.
Also kein IDE Problem.
Aber genug OffTopic 
Display MoreIch bin mit Visual Studio Code mittlerweile ganz zufrieden, verwende das für fast alles. Wobei die IDEs von Jetbrains sicher in einigen Bereichen noch besser sind.
Aber mein Problem war eher das Installieren der ganzen Abhängigkeiten, die GeoDjango benötigt. Evtl. als Hintergrund, GeoDjango ist eine Erweiterung für das Webframework Django, womit man recht leicht GIS (Geoinformationssysteme) erstellen kann. Wenn man mehr brauch also nur Längen- und Breitengrad, ist das ganz nett. Unterstützt auch direkt postgis. Damit unterstützt dann Postgres die Speicherung von z. B. Polygonen aus GPS Koordinaten und man kann das auch direkt im SQL verwenden, also z. B. direkt Abfragen, ob eine GPS-Koordinate in bestimmten Orten liegt (für die man vorher Polygone definiert hat, oder z. B. von Open Street Map heruntergeladen hat).
Aber das ganze benötigt mehrere Libs und ich habe bei einer immer Fehler bekommen, Den ersten konnte ich beheben, lag an einer dll, die ´nicht die sqlite dll in ihrem eigenen Verzeichnis verwendet hat, sondern die sqlite dll im virtual environment von python... Nachdem ich das behoben hatte, kam es aber zu weiteren Fehlern usw.
Also kein IDE Problem.
Aber genug OffTopic
I See. Hab noch nie damit gearbeitet, bzw. programmiere auch nicht sonderlich viel. Thx fürs aufklären, offtopic hin oder her - haha (Ich fühle mich irgendwie komisch Hecke29 ?)
Kenne das Problem mit den ganzen Libs zum Glück auch nur von meiner Freundin (elastix ITK, etc. unter Mac). Meine Sachen laufen meist out-of-the-box.
Vielleicht, wenn die Libs unter Linux einfacher laufen, wäre nen Linux Subsystem unter Windows auch interessant für dich. Nutze z.B. nen Debian Subsystem für Ansible unter Windows 10, wobei du halt ständig Zugriff auf die Daten hast, von beiden Systemen aus.
Server: früher Debian, heute ArchLinux. Hat sich bei der Systemd-Umstellung so ergeben, es war bei Debian eine Zeit lang nicht klar ob das reibungslos klappt, ArchLinux ausprobiert die das schon länger verwenden und dabei geblieben.
Für Familie, Laptop, ohne große Anforderungen, Hauptsache mal eben schnell ein Linux installiert: Ubuntu.
Eigener Desktop: seit Ewigkeiten Gentoo. Versuche, hier auch auf ArchLinux zu wechseln, sind bislang gescheitert.
Auf der einen Seite brauche ich das, was Gentoo bietet, eigentlich schon lange nicht mehr (Compilerflags und Useflags, geh bitte) und mir gefällt das Paketmanagement bei ArchLinux viel besser (auch Rolling Release aber nicht Ewigkeiten warten bis der ganze Schlamassel compiliert ist).
Auf der anderen Seite renne ich bei ArchLinux als Desktop immer in mysteriöse Probleme. Wenn ich bei einer frischen ArchLinux Installation im Xorg mit xterm/urxvt als allererstes mit vollkommen unlesbar verpixelten Schriften begrüßt werde, habe ich schon fast keine Lust mehr. ArchLinux ist eben mehr so eine Debian debootstrap Minimal-Installation, prädestiniert für Serveranwendungen. Wenn man das auf einen vollen Desktop hochziehen will, hat man was zu tun.
Das hängt natürlich auch damit zusammen, daß ich im GUI-Bereich eklatante Wissenslücken habe. Ich arbeite sehr viel mit dem Terminal und habe mir nie sonderlich die Mühe gemacht, GUI-spezifische Sachen wie fontconfig & Co zu durchschauen. Wenn ich dann auf der grafischen Oberfläche ein Problem mit Schriftdarstellung habe, weiß ich schlichtweg nicht, wo ich da anfangen soll nach der Ursache zu suchen.
Und solange man wieder mit 1 Klick ins alte Gentoo gebootet hat wo der Hase einfach läuft, dann ist die Motivation auch gering, sich damit auseinanderzusetzen.
Wenn man lange eine Distro eingesetzt hat, dann ist man davon abhängiger, als man denkt. Ich bin immer wieder überrascht wenn in anderen Distros irgendein Konzept ein anderes ist (Initramfs, cron, ...). Und Tricks die man in einer Distro kennt, sind eben auf andere nicht so unbedingt übertragbar. Und manche Programme verhalten sich im Detail anders, ohne daß man jetzt unmittelbar weiß, woher das kommt, weil da irgendeine Default-Konfiguration je nach Distro abweicht. Und dann geht die Sucherei eben los...
Auf der Workstation: Solus
Auf dem Laptop: elementaryOS
Auf Servern: Debian
Desktop: Windows 10 + WSL mit Debian
Server: Debian
Meine Server laufen alle mit CentOS 7.
Beruflich hatten wir EC2-Instanzen auf CentOS 6-Basis laufen und als ich dann privat mein NAS aufgesetzt habe, kam grad v7 raus und "veraltete Pakete" war kein Problem mehr.
Server netcup: Debian (aktuell Jessie & Stretch)
Server @Customer: je nach Wunsch, meistens jedoch Debian
Server @Home (3): 2 Debian, 1 RHEL (wegen RedHat-Zertifizierung)
Arbeitslaptop: Debian 9
Workstation (2): Debian 9, Windows 10 (kommt man nicht drum herum)
Damals mit Debian angefangen als ich in Linux eingestiegen bin und hatte nur kurze Ausflüge zu SUSE, RedHat, Ubuntu, Arch Linux und Linux Mint. Am Ende immer wieder bei Debian gelandet.
netcup-Server 1: openSUSE Tumbleweed
netcup-Server 2: openSUSE Tumbleweed
netcup-Server 3: openSUSE Leap
Server bei Anbieter A: Debian 8
Server bei Anbieter B: Debian 9
An openSUSE gefällt mir der Paketmanager (zypper), sowie dass Dienste standardmäßig deaktiviert sind - bei Debian/Ubuntu ist erst mal alles aktiv und auf Autostart, sobald man es installiert hat.
Mit Tumbleweed als Serverbetriebssystem bin ich sehr zufrieden. Für ein Rolling Release ist es sehr stabil und wenn Probleme auftreten sind es meist nur kleine Paketkonflikte.
Beim netcup Server Debian 9, bei den beiden Servern die sich noch woanders befinden, Ubuntu 16.04 LTS, zu Hause hauptsächlich Windows 10, einen Raspberry mit Raspian, auf dem Nuc ein OpenElec mit Kodi. Und ganz früher ein Amiga 3000 mit AMIX und später NetBSD ;).
auf Host-Servern: Ubuntu LTS
in Containern / VMs: Arch oder Alpine
am Desktop: Netrunner
auf (Host-)Servern: Ubuntu LTS
in Containern / VMs: Arch oder Alpine
am Desktop: Netrunner Rolling
Zum Wieso:
Ubuntu LTS: Da Ubuntu offizielle Unterstützung für ZFS hat und ich das gerne benutze. LTS, da ein Server der selbst auf Hardware booten muss eine hohe Verlässlichkeit haben sollte was den Bootvorgang nach Updates angeht. Außerdem sehr gute Unterstützung für LXD und Docker-CE. Das erlaubt dann eventuell fehlende Software (oder zu alte Software) bei Ubuntu ganz einfach durch LXD Container mit Alpine oder Arch auszugleichen.
Alpine: Ein Linux, das auf Größe optimiert ist und sich daher perfekt für den Einsatz innerhalb von Docker oder LXD Containern eignet. Man kann es für seine eigenen Zwecke perfekt zuschneiden und kann sich sicher sein, dass sich keine vorinstallierte Software "einmischt". Falls die reduzierte Softwareauswahl einschränkt, greife ich zu Arch.
Arch: Extrem gute Auswahl an verfügbarer Software, die durch AUR einfach automatisiert zu installieren ist. Wenn ich etwas tun möchte was Alpine nicht out-of-the-box kann, nehme ich gerne Arch. Ich benutze es auch auf Servern, zu denen ich lokalen Zugriff habe. Ich benutze es ungern auf Servern, die direkt von Hardware booten müssen und gleichzeitig nur per SSH administrierbar sind, da die Rolling Updates ab und zu auch mal einen Zustand hinterlassen, wo z.B. das Netzwerk nach reboot nicht mehr geht und man dann per SSH nicht mehr drauf kommt.
Netrunner Rolling: Das ist eine Distro, die auf Manjaro basiert und diese wiederum auf Arch. Arch selbst hat keinen Desktop-Fokus und benötigt daher einiges an Handarbeit für einen Desktop. Manjaro hat Desktop-Fokus und löst dieses "Problem" von Arch sehr gut. Netrunner wiederum fokussiert speziell auf einen KDE-Desktop und ist in dem Bereich noch ein bisschen besser optimiert als Manjaro.
Daily:
HomeLab/Private Datacenter:
QuoteAlpine: Ein Linux, das auf Größe optimiert ist und sich daher perfekt für den Einsatz innerhalb von Docker oder LXD Containern eignet. Man kann es für seine eigenen Zwecke perfekt zuschneiden und kann sich sicher sein, dass sich keine vorinstallierte Software "einmischt". Falls die reduzierte Softwareauswahl einschränkt, greife ich zu Arch.
Alpine Linux ist nicht auf Größe optimiert sondern auf Sicherheit. Primär durch die Struktur welche auf Sicherheit bedacht ist, was bedeutet es wird nur das nötigste genommen und sonst nicht mehr, ist das ganze so schlank. Man sollte halt bedenken das Alpine Linux keine so richtige glibc hat was Java zum Beispiel komplett unmöglich macht. Ansonsten das OS für testing und soll so lange laufe wie möglich.
Alpine Linux ist nicht auf Größe optimiert sondern auf Sicherheit. Primär durch die Struktur welche auf Sicherheit bedacht ist, was bedeutet es wird nur das nötigste genommen und sonst nicht mehr, ist das ganze so schlank. Man sollte halt bedenken das Alpine Linux keine so richtige glibc hat was Java zum Beispiel komplett unmöglich macht. Ansonsten das OS für testing und soll so lange laufe wie möglich.
Alpine hat eine alternative Implementierung zur glibc - die musl-lib-c, welche mehr POSIX-Kompatibilität verspricht, als die glibc.
Warum sollte Java nicht auf POSIX laufen und strikt nur für die glibc funktionieren? Java ist genauso auf BSD und anderen Unices lauffähig, also warum sollte es vor Alpine halt machen? https://pkgs.alpinelinux.org/p…unity/x86_64/openjdk7-jre
debian server
läuft läuft läuft, seit 2012: Inklusive Migrationen von einem Netcup Server auf den nächsten. Gelegentliches Package aufräumen kann zu Spaß führen bei Upgrades, ansonsten super.
KUbuntu desktop
1) hersteller Support für Hardware auf dem System (wifi, dual stack GPU etc)
2) wenn man einmal die Konfigurationsmöglichkeiten & usability von KDE kennen gelernt hat, gibt's kein Zurück mehr
Einzig wer dann SSL linkt braucht für Debian server builds wieder 'ne VM, sonst landet die falsche OpenSSL lib im Linker.. [da war was mit anderen Versionen installieren, bisher mit VM super gefahren]
damit habe ich zwar ziemlichen Standardunterbau aber damit bin ich auch recht gut gefahren, vielleicht tritt mich ja i-wann etwas um mir mal endlich NixOS an zu schauen, womit ich eine exakte Definition des Systems hätte
