Software ausführen kann ohne den User Space
HALT!
Das ist ein Sicherheitsrisiko. Gerade weil man haben möchte, dass
die Maschinen nicht sofort gerootet werden können
ist es wichtig, möglichst viele Dienste, bei denen es möglich ist, in einem Userspace laufen zu lassen, der abgetrennt vom root arbeitet - wird ein Dienst übernommen, ist nicht gleich sofort root kompromittiert.
Dein Problem ist, dass du eigentlich nicht wirklich weißt, was du willst. Du willst Linux verstehen - glaub mir, dafür reicht es, Pakete zu verwenden und zu konfigurieren. Schon bei Munin musst du anfangen, Dienste miteinander "reden" zu lassen, zum Beispiel smartmontools mit dem Sensors-Plugin von Munin, damit bekommst du automatisch ein Gefühl dafür, wie das System so arbeitet. Wie gesagt, wenn du programmieren willst, bist du 90% der Zeit nicht mit dem System beschäftigt, sondern mit deinem Code - das bringt dir also eigentlich wenig bis gar nix fürs Verständnis.
Das, was du hier beschreibst:
zumindest soweit man etwas mit dem X Window System Server/Client machen kann, Software ausführen kann ohne den User Space / Desktop Environment dafür zu haben. Zugriff mit bzw. über SSH/VNC, Systemsicherheit - zumindest das Dameons/CRON Jobs zur Systempflege.
ist Systemadministration. Das hat nix mit "Ich programmier mir mein eigenes top und mein eigenes Munin" zu tun. Das ist rein Installation und Konfiguration von Diensten, Optimierung des Systems zum selbstgesteckten Ziel hin und Einrichtung einer Firewall.
Nur was ich mich dabei Frage, warum ist die Wahl der Distribution/Familie überhaupt so wichtig für Lernziele? Sollten nicht alle irgendwo dienlich dafür sein?
Alles und nein. Linux gibt es in hunderten verschiedenen Ausführungen, eine jede hat andere Ziele. Gentoo ist für Hardliner, die alles am System selbst bestimmen wollen. Es zwingt einen aber halt auch dazu. Arch ist für die etwas fauleren Hardliner - immer noch das meiste selber machen, aber zumindest kompiliert sind die Pakete schon. Beide Distros arbeiten bleeding edge, d. h. neue Software wird ohne langes Testen direkt ausgerollt. Bugs werden damit an eine große Gemeinde an Nutzern verteilt, die sie auch schnell finden. Das betrifft insbesondere Bugs, die nur in exotischen Umgebungen/Paketzusammenstellungen auftreten. Das hilft natürlich allen Distros in gewisser Weise, die Software wird ja oft in vielen Distros eingesetzt und meist etwas zeitverzögert ausgerollt.
Debian (ich rede hier vom Stable-Zweig, testing/sid ist eine reine Testumgebung, auch wenn es beliebt ist für Desktops) geht eine andere Richtung, es kommt mit einem funktionierenden, gut getesteten System daher, das nur noch an die eigenen Bedürfnisse angepasst werden muss. Die GUI ist wie alles andere natürlich optional, das Grundsystem besteht aus dem Kernel, ein paar Kernelmodulen, der Bash und apt (+ dem Bootloader deiner Wahl, d. h. Grub oder Lilo). Außerdem muss jedes Paket in den Hauptquellen sowohl OpenSource sein als auch mit freier Lizenz veröffentlicht sein (was zeitweise dazu führte, dass Firefox wegen Anpassungen am Code in Iceweasel umbenannt und mit anderem Logo ausgerollt werden musste, weil Mozilla die Codeänderungen in Verbindung mit der Veröffentlichung als ihr Produkt nicht gestattet hat - gleiches galt für Thunderbird/Icedove). Außerdem ändert Debian selten was an eingespielten Vorgängen - man kann teilweise drei und mehr Hauptversionen upgraden, bis man per Mail informiert wird, dass sich eine Konfigdatei geändert hat und umgeschrieben/angepasst/verschoben werden muss. Debian ist also ziemlich adminfreundlich.
Ubuntu, als Tochter von Debian, geht einen benutzerfreundlicheren Weg, es installiert automatisch eine selbst entwickelte GUI (Unity) und hängt die Schranken für Pakete nicht so hoch (bezüglich Lizenzierung und OpenSource), kann damit aber auch viel schneller mit neuer Hardware arbeiten. Außerdem hat es ziemlich viel Zeug nicht mehr so konservativ gelöst wie Debian, also manchmal muss man als Admin etwas suchen, um die richtigen Dateien zu finden, die zum Beispiel für die Netzwerkeinrichtung verantwortlich sind, zumal einige Dinge dort zentral administriert werden und nicht, wie bei Debian, hübsch nach Dienst sortiert und verteilt. Kann in der nächsten Version schon wieder anders sein.
Suse ist da noch übler, da geht fast nichts mehr ohne ihre zentrale Verwaltungsschnittstelle yast. Es wird halt als SLES an Unternehmen verkauft und da supportet, daher setzen es viele Unternehmen ein. Bei RHEL ist das ähnlich.
Kali ist für Administration überhaupt nicht ausgelegt, es ist ein stark angepasstes Debian für Penetration-Tests. Klar könnte man einen Server damit betreiben, aber Sinn macht das wenig. Du kaufst dir ja auch keinen F1-Boliden, um hinterher das komplette Auto umzubauen, weil du TÜV und Straßenzulassung bekommen willst.
Wie gesagt, die Distros haben alle irgendwo einen Sinn, es gibt auch an jeder was auszusetzen. Auch der von dir gewünschte Lerneffekt "bezüglich des Systems" ist breit gefächert - wer Kali verwendet, kennt andere Teile des Systems als jemand, der den Kernel programmiert. Ein Firewall-Admin ist ein Guru in Bezug auf iptables, Security-Logs und vielleicht noch die Einbindung an Munin (oder ein anderes Monitoring-Werkzeug), hat aber von Samba vielleicht keine Ahnung, obwohl das
eine wichtige DIE Schnittstelle zu Windows-Systemen ist. phre4k hat da schon recht, wenn er sagt, dass Entwickler und Admins zwei völlig verschiedene Typen sind. Klar, das mag hin und wieder mal in einer Person vereint sein, aber das wird entweder nicht gut, oder kein Hobby. Irgendwas leidet an dieser Kombination immer, weil Systeme heute zu komplex werden, um sie vollumfänglich verstehen zu können.
Mach dir also erstmal klar, was du erreichen möchtest, dann können wir dir einen Weg zeigen, der aus unserer Sicht der sinnvollste ist.
ja/nein... und ähnliches. Auch wenn nicht im Detail darauf eingegangen wurde was genau welche Gruppe eigentlich umfasst, aber auch nicht so schlimm. Es wurden ja noch weitere Information gegeben. 
