Suche Linux Distribution fuer Workstation

[max_power]

Achso, eine Sache, die mir der Systemadministrator noch geraten hatte: Ich solle schauen, dass es eine Enterprise Version ist, weil diese von kommerziellen Entwicklern von Linux-Software wohl besser unterstuetzt wuerden. Da CentOS ja auf Red Hat Enterprise Linux basiert, sollte das da gegeben sein, aber wie sieht es mit Debian aus?

Abgesehen davon lese ich bisher als Zwischen-Fazit aus dieser Diskussion, dass es im Grunde Jacke wie Hose und Geschmackssache ist, welches Linux man verwendet. Die Hauptentscheidung wird wohl zwischen Debian oder Red Hat basierten Distributionen sein und fuer mich wird das wohl im Endeffekt Ubuntu oder CentOS heißen.

Leider sieht es so aus, als wuerde der Computer noch länger auf sich warten lassen, auf der Bestellstatus-Seite hat sich noch immer nichts getan.

[TentakelTommy]

Wenn du kommerzielle Software nutzen willst, solltest du halt das nehmen was die unterstützen

Und ja, es ist "egal", was du nimmst - mußt halt je nachdem mehr Sachen/Pakete deinstallieren/installieren.

@Hans: huch? das was ich hier mal hatte nutze /bin/sh - was zum svn-checkout und Aufruf des "Berechnung"-Tools reichen sollte.

[td]

wie sind eigentlich die Unterschiede zwischen Ubuntu und Debian?

Ubuntu ist ein Debian unstable mit zusaetzlichen Paketen, die (zumeist aus gutem Grund, zum Beispiel wegen Lizenzproblemen) nicht in Debian sind, und diversen Aenderungen, um es inkompatibel zu einem Debian zu machen. Neue locales hinzufuegen geht unter Debian zum Beispiel mit `dpkg-reconfigure locale-config'; unter Ubuntu macht das genau gar nichts, da darf man die locales in eine Konfigurationsdatei reinfrickeln, die unter /usr/share/.../ liegt und nirgendwo dokumentiert ist. Policy ist anscheinend ,,Wer Ubuntu nutzt, will keine anderen locales haben.''

Wenn man mit Ubuntu so zufrieden ist, wie es ist, dann kann man das auch nutzen, ansonsten ist man bei Debian besser aufgehoben.

Was unstable auf Produktivsystemen betrifft: Testing ist in der Regel kaputter, weil die Fixes vorher durch unstable gehen.

(von der etwas komfortableren Installation mal abgesehen, aber wer will das schon )

Das ist auch nur der Entwicklungszweig von debian-installer.

Natürlich kann ich mir mein FreeBSD auch so herrichten, dass es sich anfühlt wie ein Linux (also gleich eine bash installieren, vim installieren, usw.)

Im Hintergrund bleibt es trotztdem ein FreeBSD, da kann man noch so viel bauen. Wenn man das halbwegs ernsthaft nutzt, merkt man zuegig, dass es kein Linux ist.

Doch, CentOS ist aktuell. Der Punkt [nicht-Aktualitaet] trifft eher auf Debian zu.

Das letzte CentOS-Release liegt zweieinhalb Monate laenger zurueck als das letzte Debian-Release. Was die Softwareversionen angeht, ist das (soweit ich das finden konnte, die CentOS-Leute scheinen nichts davon zu halten, Listen mit Paketversionen im Netz zu haben) beides etwa auf aehnlichem Stand, wenn man etch-backports mit dazu nimmt, dann liegt Debian stable eindeutig vorne. Ueber testing und unstable muessen wir gar nicht erst reden, die sind noch besser dran.

Fazit: Sehe keinen Grund, bei einem System, das hauptsächlich auch als Workstation benutzt werden soll, auf aus meiner Sicht reine Server-Linux oder Unix-Systeme zurückzugreifen.

Wie waers dann mit OpenSolaris, das ist eindeutig ein Workstation-Unix?

@Hans: huch? das was ich hier mal hatte nutze /bin/sh - was zum svn-checkout und Aufruf des "Berechnung"-Tools reichen sollte.

/bin/sh kann alles Moegliche sein, unter Debian meistens dash, unter Fedora bash, unter OpenBSD eine ksh, et cetera. Einzige Bedingung ist, dass es POSIX-konform ist.

[TentakelTommy]

Einzige Bedingung ist, dass es POSIX-konform ist.

Eben das meinte ich. Wenn sich das, was auf der shell gemacht werden soll, wirklich nur auf 3 Programmaufrufe beschränkt ist es IMHO ziemlich egal, welche zusätzlichen Funktionen die Shell beinhaltet. Es soll ja keiner was *damit* arbeiten

[max_power]

Gut, die Workstation ist endlich da und ich plage mich mit der Linux-Installation (ist CentOS geworden, allerdings ist die Plage eher Linux an sich ). Wie auch immer, ich habe folgendes Problem: Die Grafikanzeige ist unglaublich lahm. Scrollen oder Fenster verschieben belastet einen Kern teilweise komplett, das Verschieben eines Terminal-Fensters artet in eine unvorstellbare Ruckel-Orgie aus.

Was ist das Problem, was kann ich tun?

Meine Diagnose wäre, dass es am Grafikkarten-Treiber liegt. Es ist eine nVidia Quadro NVS 290 und installiert ist der mitgelieferte Treiber von HP, weswegen ich davon ausgegangen bin, dass der vernuenftige Leistung bietet. Im grafischen Frontend fuer die Grafiktreiber wird allerdings auch nur "nv" angezeigt, aber yum sagt, dass der HP-Treiber installiert sei. Der Versuch, einen Treiber von nVidia zu installieren, scheiterte am Kernel, da dort Xen aktiviert ist.

So ganz steige ich durch das alles nicht durch und auch im Netz habe ich bis jetzt keine passende Hilfe gefunden. Kann mir einer von euch einen Tipp geben?

[Hans]

Keine Ahnung, was XEN mit dem Grafiktreiber zu tun hat, aber brauchst du XEN? Wenn nicht, wieso deaktivierst du das nicht und installierst die NVidia-Treiber?

Was meinst du denn mit mitgelieferte Treiber von HP? Bietet HP Linux-Treiber für Nvidia-Chips an?

[max_power]

HP hat eine Treiber-CD beigelegt und da war auch ein nVidia Treiber bei.

"yum search *nvidia*"

sagt

"nvidia.x86_64 169.09-1 installed
Matched from:
nvidia
HP packaged nVIDIA accelerated graphics driver."

Der Treiber ist uebrigens fuer Red Hat gedacht, aber das sollte ja eigentlich kein Problem sein, oder?

So wie ich verstanden habe ist das Problem mit Xen, dass es einen modifizierten Kernel braucht, aber die nVidia-Standardtreiber nur mit Standard-Kernels (ohne Xen) laufen. Im Moment brauche ich Xen noch nicht, wollte aber ausprobieren, wie gut Windows in einer VM läuft, da ich das sicher irgendwann gut gebrauchen kann.

[td]

Xen deaktivieren duerfte auch eher ausfallen, das ist unter CentOS fest drin.

`nv' ist der Standard-NVIDIA-Treiber aus X.org, der Treiber direkt von NVIDIA heisst `nvidia.'

Konfiguriere dein X.org um, so dass es statt `nv' `nvidia' nimmt, und alles wird gut.

Code: Alles auswählen

 # nano /etc/X11/x.org
Statt nano kannst du natuerlich auch jeden anderen Editor nehmen.
[...]
Section "Device"
[...]
  Driver "nv"
[...]
EndSection
[...]

Aendern in `nvidia,' speichern, X.org neustarten (C-M-BS), fertig.

[Hans]

Xen deaktivieren duerfte auch eher ausfallen, das ist unter CentOS fest drin.

Wieso, man kann den sich den Kernel doch so kompilieren, wie man will? Oder was meinst du mit "fest drin"?

[max_power]

Ich wurde bei der Installation gefragt, ob ich Xen will oder nicht und könnte es auch nachträglich entfernen, die Frage ist nur, ob CentOS dann auch einen anderen Kernel nimmt. Wie auch immer, ich gehe davon aus, dass ich das deaktivieren oder zumindest irgendwie das Problem umgehen könnte, wenn ich meinen eigenen Kernel kompilieren würde, aber irgendwie will ich das nicht wirklich, zumal das sicherlich auch wieder jede Menge Zeit fressen würde.

Auf jeden Fall danke für den Tipp don, ich probiere das Montag aus.

[td]

Xen deaktivieren duerfte auch eher ausfallen, das ist unter CentOS fest drin.

Wieso, man kann den sich den Kernel doch so kompilieren, wie man will? Oder was meinst du mit "fest drin"?

Kann man machen, dabei verliert man aber unter Umstaenden den Grund, CentOS ueberhaupt zu nutzen: Binaerkompatibilitaet mit RHEL. Wenn die einen Kernel ohne Xen mitliefern, OK, sonst ist das halt doof (sowas wie packages.d.o scheints ja weder fuer RHEL noch fuer CentOS zu geben, tolles Feature).

[max_power]

Ich bin noch auf die Arbeit gefahren. Leider ging es nicht, da das Modul nvidia nicht verfuegbar sei. Ich schau mich noch mal bei hp auf der Homepage um, das kann doch nicht sein, dass die ein System mit vorinstallierten Red Hat ausliefern, aber fuer die Grafikkarte nur grottige Treiber liefern.

[td]

Guck mal, welche Dateien unter /usr/lib/xorg/modules/drivers liegen, da wird der Treiber mit dabei sein. Mein `nvidia'-Treiber heisst `nvidia_drv.so.'

[max_power]

In dem Verzeichnis (bzw. /lib64/ nicht /lib/) liegen sowohl nv_drv.so als auch nvidia_drv.so. Ich habe uebrigens festgestellt, dass er wohl beim booten auch versucht hat, ein nvidia-config-Skript auszufuehren, aber an besagtem Xen-Kernel gescheitert ist. Temporär habe ich mein Problem damit gelöst, dass ich mir per yum nun einfach einen Kernel ohne Xen gezogen habe (auf die Idee hätte ich auch schon frueher kommen können). Mit dem lief der nvidia Treiber und die Anzeige ist jetzt vernuenftig. Eine Dauerlösung ist das aber nicht, außerdem ist die CPU-Belastung beim Fenster-verschieben immer noch ueber 70%. Wie gut, dass ich mehrere Kerne habe...