[Ihrgendwehr]

Um mal den Betriebssystemthread nicht zu sehr zu strapazieren antworte ich leiber hier in nem neuen Thread auf den Herrn Kugelfisch:

Zitat von Kugelfisch23

Das hängt damit zusammen, das Serververwaltung definitiv keine Aufgabe für Laien ist.

Oh ja, allerdings wäre sowas wie in dem beschriebenen Fall mit automatischen Updates schon behebbar... Wenn viele Distributionen doch so tolle Paketmanager haben, dann sollten sie auch genutzt werden, z.B. nur umständlich Sicherheitsupdates ausschaltbar machen! Bis ein DASysop da dahintersteigt wie das geht hat er ja laut dem Artikel eh shcon das Handtuch geworfen!

Zitat von Kugelfisch23

Und diejenigen, die wissen, was sie suchen, sind in der Shell bei vielen Aufgaben schneller, als wenn man sich durch eine langsam reagierende, unübersichtliche GUI quälen müsste. Des weiteren ist eine flache Konfigdatei wesentlich einfacher zu dokumentieren als eine umfangreiche GUI.

Ich nehme mal eMule als Beispiel... Ist es wirklich angenehmer sich zuerst http://www.emule-project.net/home/pe...ic&topic_id=92 durchzulesen und dann die Einstellungen zu treffen oder die GUI dafür zu verwenden?

Ok, das Beispiel ist wieder ein bisschen unfair, da das Konfigfile eher der GUI "unterstellt" ist als umgekehrt eine GUI programmiert wurde um das Konfigfile zu ändern - in dem Fall würde es wohl so aussehen wie hier:

Was an Mouseover-Texten die erst dann erscheinen wenn man sich auch für diesen Punkt interessiert (im Gegensatz zu Kommentaren in Konfig-Files) so schlecht sein soll verstehe ich auch nicht ganz - nLite wäre so ein Beispiel.

Zitat von Kugelfisch23

Zu mir: Ich verwende sowohl unter GNU/Linux wie auch unter Mac OS X die Shell oft. Wenn man zum Beispiel schnell eine Datei kopieren will, ist man oft mit einem `cp ~/tex[TAB](te)/unt[TAB](erverzeichnis)/mei[TAB](nedatei) ~/anderesv[TAB](erzeichnis)` schneller, als wenn man sich per Maus und GUI durch alle Unterverzeichnisse klicken müsste.

Naja, unter dem Explorer (oder vergleichbarem) bräuchte man noch weniger Fingerarbeit...
t auf der Tastatur, Ordner Texte mit Enter öffnen, u auf der Tastatur, Ordner Unterverzeichniss mit Enter öffnen, Meinedatei markieren, Strg+c, Backspace, Backspace, Anderesverzeichnis öffnen und Strg+v

Je nach Verwendung der Pfeiltasten oder der Maus (je nachdem ob man die Datei schon markiert hat wenn man in den Ordner wechselt) kommt man so mit min. 11 Tastenanschlägen aus, während du in deinem Beispiel 31 mal auf den Tasten klimperst. Im Idealfall (1 Buchstabe reicht um den Pfad zu vervollständigen) brauchst du auch 18 Zeichen (16 wenn du die ~-Zeichen als "Zierde" verwendet hast und sie nicht für cp wichtig sind) wobei das Beispiel von beiden seiten (deiner und meiner) hinkt.

Außerdem kommt es bei mir häufiger vor, dass ich die Datei kopieren will, die ich gerade betrachte, von daher fällt das Hinnavigieren meist schon aus - für "Daueraufträge" wie z.B. dem Automatischen Sortieren von MP3 Dateien in die Musiksammlung verwende ich natürlich auch Batchdateien.

Zitat von Kugelfisch23

Aber die Diskussion Shell<>GUI ist genau so alt wie Windows<>Linux. Und tut hier nicht wirklich etwas zur Sache.

Daher auch dieser Thread hier.

Was denken die anderen?
Ist es wirklich zeitgemäß einen Webserver wie Apache mit einer Textdatei zu administrieren? Sind GUIs wirklich lahm und unübersichtlich? Ist es echt schneller und besser dokumentierbar wenn man ein Programm ohne GUI verwendet + konfiguriert?

[Dark Silence]

Zitat von Ihrgendwehr

Um mal den Betriebssystemthread nicht zu sehr zu strapazieren antworte ich leiber hier in nem neuen Thread auf den Herrn Kugelfisch:

Hättest einfach auch in dem alten Thread zu diesem Thema antworten können, falls was unklar geblieben wäre.

Zitat von Ihrgendwehr

Oh ja, allerdings wäre sowas wie in dem beschriebenen Fall mit automatischen Updates schon behebbar... Wenn viele Distributionen doch so tolle Paketmanager haben, dann sollten sie auch genutzt werden, z.B. nur umständlich Sicherheitsupdates ausschaltbar machen! Bis ein DASysop da dahintersteigt wie das geht hat er ja laut dem Artikel eh shcon das Handtuch geworfen!

Könntest du das bitte noch einmal etwas verständlicher im Bezug auf dein genanntes Zitat ausdrücken.

Zitat von Ihrgendwehr

Ok, das Beispiel ist wieder ein bisschen unfair, da das Konfigfile eher der GUI "unterstellt" ist als umgekehrt eine GUI programmiert wurde um das Konfigfile zu ändern

Nichts für Ungut aber da verstehst du wohl etwas falsch. Es wird bei solchen Projekten klar zwischen der Core und der GUI getrennt. Zuerst wurde aber die Core entwickelt und als Aufsatz für die einfachere Bedienung dann die GUI und nicht umgedreht. Nebenbei ist eMule auch nicht die typische Serveranwendung. Es spricht aber noch nicht einmal etwas gegen eine GUI bei solch einer Anwendung, aber warum bitte schön soll diese GUI auf dem Server und nicht auf dem Desktop Rechner gestartet werden? Die Core läuft auf dem Server und verrichtet seine Arbeit und du greifst dann einfach über Netzwerk zu und nimmst dann deine Einstellungen per GUI vor.

Zitat von Ihrgendwehr

Was denken die anderen?

Meiner Meinung nach hat ein WM auf einem Server im Normalfall nichts zu suchen. Warum? Die Gründe wurden eigentlich schon von dir, aber auch im vorherigen Thread und natürlich auch im alten Thread genannt. Also nächstes Mal bitte die Suchfunktion verwenden. Da wirst dann vermutlich auch noch ein paar andere Threads dazu finden.

MfG
Dark Silence

[Ihrgendwehr]

Okay, dann sag mir doch was "alles" in dem alten Thread steht und was das mit der GUI-Verliebtheit von eigentlich allen Linuxdistributionen zu tun hat.

Könntest du das bitte noch einmal etwas verständlicher im Bezug auf dein genanntes Zitat ausdrücken.

Naja, in dem Link dort ging es darum, dass irgendein Kiddy sich nen Rootserver mietet weil das gerade so kewl ist, es dann nach ein paar Tagen verzweifelt aufgibt weil er vom Server nur ne Textbox findet und ne Zombiebox dadurch erschafft, da keine Sicherheitslücken gestopft werden - mit automatischen Updates wäre sowas weniger wahrscheinlich, da dann zumindest Sicherheitslücken nicht offen blieben (gegen "test" als Rootpasswort hilft das natürlich nicht...)

Es spricht aber noch nicht einmal etwas gegen eine GUI bei solch einer Anwendung, aber warum bitte schön soll diese GUI auf dem Server und nicht auf dem Desktop Rechner gestartet werden? Die Core läuft auf dem Server und verrichtet seine Arbeit und du greifst dann einfach über Netzwerk zu und nimmst dann deine Einstellungen per GUI vor.

Klar, wenn die GUI (oder das Webinterface, muss ja kein extra Programm sein...) gescheit integriert + zugänglich designt wäre - kein Problem!

Eie GUI auf ein bestehendes und gut funktionierendes Programm aufzusetzen schaut leider eher meist so aus wie im ersten Screenshot (Robocopy).
Bei eMule gehe ich mal davon aus, dass es von Anfang an mit GUI geplant wurde, daher schaut das Optionsfenster dann doch etwas ansprechender aus. (Achtung, das waren jetzt nur 2 _Beispiele_!)

Was hilft es mir, wenn ich mit GUIs besser zurechtkomme, aber dauernd gesagt kriege, dass es mit Kommandozeile doch sooo viel schneller+besser geht?
siehe z.B. das Zitat von vmk in deinem "alten thread":

Zitat von vmk

Du musst den Window-Manager einrichten, dafür sorgen das alle Pakete laufen, u.s.w. - Nur wofür?
=> Welchen Zeitgewinn hast du durch den Zeitaufwand "Einrichten des X-Servers"? Es gibt für Linux keine graphischen Tools um solche Pakete zu verwalten. Alle wichtigen Tools laufen von der Konsole aus und lassen sich wunderbar per Parameter bedienen (das notiert man sich und weißt später was man gemacht hat. Bei einer graphischen Oberfläche kannst du das nicht!)

In meinen Augen Blödsinn, da sich eine GUI ja auch irgendwo merken muss was man getan hat - gerne auch in einer Konfigurationsdatei in der dann vi-Fans rumwühlen können!
Außerdem hat man sogenannte "Logs" erfunden, damit man nicht mit dem Bleistift neben dem Computer sitzen muss...

Im "alten Thread" geht es auch um X-Server für Server. Ich sehe ja ein, dass das mit einem Programm/Interface auf meiner Seite besser und sicherer zu verwalten ist - nur warum sollte man dafür nicht auch eine GUI haben?

[Kugelfisch23]

Zitat von Ihrgendwehr

mit automatischen Updates wäre sowas weniger wahrscheinlich, da dann zumindest Sicherheitslücken nicht offen blieben (gegen "test" als Rootpasswort hilft das natürlich nicht...)

Ein Automatisches Update will man nicht - was ist, wenn z.B der Apache geupdatet wird? Richtig, er muss gestoppt werden, was eine Downtime verursacht. Und falls etwas schief laufen sollte, ist die Seite danach offline. Nein, der Admin ist dafür verantwortlich, Securitymailinglisten zu lesen, und die dort besprochenen Löcher zu stopfen. Wer das nicht kann oder will, soll einen Managed-Server mieten!

Zitat von Ihrgendwehr

In meinen Augen Blödsinn, da sich eine GUI ja auch irgendwo merken muss was man getan hat - gerne auch in einer Konfigurationsdatei in der dann vi-Fans rumwühlen können!

Ja, sie merkt es sich - in einer Binären Konfigdatei, mit der man nichts anfangen kann.

Zitat von Ihrgendwehr

Außerdem hat man sogenannte "Logs" erfunden, damit man nicht mit dem Bleistift neben dem Computer sitzen muss...

Ja und? Die gibt es bei jedem vernünftigen System, und das sind übrigens reine Textdateien

Zitat von Ihrgendwehr

Ich sehe ja ein, dass das mit einem Programm/Interface auf meiner Seite besser und sicherer zu verwalten ist - nur warum sollte man dafür nicht auch eine GUI haben?

Die Frage ist: WARUM sollte man eine GUI haben? Du bist es dir - als Windows-User nehme ich an - gewohnt, alles in klickbar zu haben (Am Ende werden noch soganannte `Wizards` gefordert, die einem nur nerven, und bei der Konfiguration einschränken). Ich bin mir eher gewohnt, viel in der Shell zu machen - und wie gesagt, ich bin, subjektiv gesehen, bei vielem schneller, wenn ich es in der Shell erledige. Geklicke und den Griff zur Maus, resp. zum Touchpad, erachte ich eher als nervig.

[ITnetX]

Zitat von Kugelfisch23

Ein Automatisches Update will man nicht - was ist, wenn z.B der Apache geupdatet wird? Richtig, er muss gestoppt werden, was eine Downtime verursacht. Und falls etwas schief laufen sollte, ist die Seite danach offline. Nein, der Admin ist dafür verantwortlich, Securitymailinglisten zu lesen, und die dort besprochenen Löcher zu stopfen. Wer das nicht kann oder will, soll einen Managed-Server mieten!

Ich klinke mich mal kurz ein .. weil ich das so verstehe als wenn jeder Administrator der sein System aktualisiert(update) anstatt es selbst mit Assembler, Compiler etc vergewaltigt kein guter Admin ist....

[Kugelfisch23]

Zitat von ITnetX

Ich klinke mich mal kurz ein .. weil ich das so verstehe als wenn jeder Administrator der sein System aktualisiert(update) anstatt es selbst mit Assembler, Compiler etc vergewaltigt kein guter Admin ist....

Natürlich nicht. Mit `stopfen` meinte ich: Beaufsichtigt die Updates/Fixes einspielen. Was ich auf einem Server nicht haben will, ist ein Autoupdater, der selbständig Updates zu installieren versucht, und dafür eigenmächtig Services stoppt und neu startet.

[Ihrgendwehr]

Zitat von Kugelfisch23

Ein Automatisches Update will man nicht - was ist, wenn z.B der Apache geupdatet wird? Richtig, er muss gestoppt werden, was eine Downtime verursacht. Und falls etwas schief laufen sollte, ist die Seite danach offline.

Dann wäre es vielleicht an der Zeit einen anderen Updatemechanismus zu integrieren oder Serversysteme generell zumindest ein bisschen reundant von Anfang an zu gestalten? Wenn dann der Apache gepatcht wird, wird z.B. der alte Apache erst gestoppt wenn der neue nach einem Selbsttest fehlerfrei läuft.

Wenn ein Sicherheitsupdate kommt, musst du sowieso den Server neu starten, was wäre so schlimm an einem Dienst der das automatisch macht, wenn du z.B. 48 oder 72 Stunden nach einem kritischen Patch diesen noch nicht eingespielt hast und den Apachen dann zwangsweise in der (laut geführter Statistik) Zeit neustartet in der die wenigsten Leute online sind? Gerade schlecht gewartete Zombieboxen würden so verhindert werden, gut gewartete Server bekämen ihre Updates ohnehin eingespielt oder der Countdown würde zumindest vom Admin unterbrochen werden.

Edit: Hat zwar mit dem Thema herzlich wenig zu tun ist aber trotzdem interessant!

[hellrunner]

Nur kurz.

Ich bin gerne in der Shell unterwegs jedenfalls unter Unix. Heißt aber nicht das ich es nicht auch unheimlich angenehm und wesentlich übersichtlicher Finde wenn ich kein GUI habe.

Es ist einfach so das ich mit dem GUI das gleiche sichere System und die selben Möglichkeiten habe wie mit einer Kommandozeile. VORAUSSGESETZT sie ist gut Designed.

Ich mache beides gerne sofern die GUI hübsch ist. Ansonsten hacke ich das auch mal fix in die Shell.
Aber schneller bin ich mal mit der einen mal mit der anderen Seite.

Es ist also lediglich eine Glaubensfrage und daher in meinen Augen keine Diskussion wert.
Wer wirklich Ahnung hat, der kann auch einen Server aufsetzen mit einer GUI Oberfläche, wenn die Ordentlich gemacht ist/wäre.

----> und jetzt schlag mich

[obsd]

Welchen Sinn hat X auf einem Unix-Server? Es macht das System nur verwundbarer - je mehr Servies laufen, umso mehr mögliche Schwachstellen. Ganz einfach.

Davon abgesehen, stimme ich Kugelfisch in allen Punkten zu, ich bin nur mit der Tastatur wesentlich schneller - alleine ständig zwischen Tastatur und Maus hin und herzugreifen nervt ....

[Dark Silence]

Zitat von Ihrgendwehr

mit automatischen Updates wäre sowas weniger wahrscheinlich, da dann zumindest Sicherheitslücken nicht offen blieben (gegen "test" als Rootpasswort hilft das natürlich nicht...)

Ganz so einfach ist es nun auch nicht. Updates alleine reichen nicht aus. Man muss sich auch schon mit dem System und den laufenden Diensten auskennen und das System entsprechend härten. Aber damit alleine ist es auch nicht getan.

Zitat von Ihrgendwehr

Eie GUI auf ein bestehendes und gut funktionierendes Programm aufzusetzen schaut leider eher meist so aus wie im ersten Screenshot (Robocopy).
Bei eMule gehe ich mal davon aus, dass es von Anfang an mit GUI geplant wurde, daher schaut das Optionsfenster dann doch etwas ansprechender aus. (Achtung, das waren jetzt nur 2 _Beispiele_!)

Ob eine GUI von Anfang an geplant ist oder nicht, im Bezug auf die meisten Programme macht das kaum ein Unterschied. Wie die GUI später schließlich aussieht hängt nicht davon ab ob ein Server-Modell verwendet wird oder nicht, sondern eher von der Vorstellung des Programmierers. Bei mldonkey z.B. hatte ich damals kaum ein Unterschied festgestellt im Bezug auf die Oberfläche im Vergleich zu anderen Anwendungen wie eMule und dort wurde logischerweise auch das Server-Client-Prinzip verwendet.

Zitat von Ihrgendwehr

Im "alten Thread" geht es auch um X-Server für Server.

Den brauchst du schließlich damit deine ganzen grafischen Oberflächen auch dargestellt werden können, daher haben die Argumente aus dem "alten" Thread natürlich auch hier ihre Gültigkeit.

Zitat von hellrunner

----> und jetzt schlag mich

Na dann fang ich mal.

Zitat von hellrunner

Es ist einfach so das ich mit dem GUI das gleiche sichere System und die selben Möglichkeiten habe wie mit einer Kommandozeile. VORAUSSGESETZT sie ist gut Designed.

Ne, eben nicht! Selbst wenn die GUI gut designed ist, sie stellt trotzdem ein zusätzliches Sicherheitsrisiko da und die Leistung des Servers leidet darunter ebenfalls. Du musst bedenken, dass wegen der GUI zusätzlich noch ein X-Server laufen muss und aufgrund von Abhängigkeiten, laufen dementsprechend mehr Dienste, also weitere Nachteile. Aber oft es auch so, dass die GUIs gar nicht alle möglichen Parameter anbieten und so bist du in deinem Tun letztendlich wieder eingeschränkt.

Zitat von hellrunner

Es ist also lediglich eine Glaubensfrage und daher in meinen Augen keine Diskussion wert.

In meinen Augen ist es keineswegs eine Glaubensfrage, da eine grafische Oberfläche fast nur Nachteile mit sich bringt im Bezug auf einen Server. Die einzigen Vorteile sind, dass es für den ungeübten Anwender oft etwas schneller und einfacher geht im Hinblick auf die Konfiguration. Die Nachteile überwiegen die Vorteile aber bei Weitem. Nun zähle ich mal die Nachteile auf:
1. Das System wird langsamer
2. Speicherplatzverschwendung
3. Die Sicherheit leidet aufgrund weiterer laufender Dienste
4. Mehr Arbeitsaufwand, da der X-Server usw. eingerichtet werden muss
5. Teilweise Einschränkung durch die GUIs, da diese nicht immer alle Parameter abdecken
6. Eine Automatisierung wäre schwieriger zu realisieren, wenn man sich nur auf graphische Oberflächen einlassen würde
7. Höhere Stromrechnung
8. Man kann mit der Zeit viele Tätigkeiten schneller über die Konsole abwickeln als über die jeweiligen grafischen Oberflächen

Es bleibt also letztlich immer wieder die Frage, wofür eigentlich einen X-Server aufsetzen. Der Punkt mit der Sicherheit wäre für mich alleine schon ausschlaggebend genug keinen X-Server aufzusetzen.

MfG
Dark Silence

[bakaroo]

Warum nicht einfach beide Ideen verbinden? Warum muß die Steuerung des Servers unbedingt _grafisch_ erfolgen? Ein X-Server zu installieren ist ein elender Rattenschwanz an Paketen und Diensten, die es ebenfalls gilt, auf aktuellen Stand zu halten. Ein vi ist da meisst einfacher zu warten, aber wer von uns kennt das nicht: "Wie hieß noch mal dieser f**king Parameter und wie war das nochmal mit dieser und jener Option?"
Warum das ganze nicht per .ini belassen und diese .ini mit einem perl/cgi-script via Webbroswer anpassen?
zwei schöne Beispiele
Erstens: /etc/samba/smb.conf mit seinen inzwischen wohl über 10.000 Parametern (Man smb.conf zähle ich zu den größten manpages) und das dazu passende kleine Progrämmchen namens SWAT, anzusteuern via http://sambaserver:901
Zweitens: CUPS. Schonmal auf einem CUPS-Server http://Cupsserver:631 aufgemacht? Selbst das Einrichten eines Druckers am Windowsrechner macht da mehr Arbeit!

Klar, wer immer noch will, kann das ganze auch lokal via X-Server oder durch vi smb.conf oder mittels scp cupsd.conf serverip:/etc/cups/ machen..

als weitere Idee: wer partout eine Oberfläche braucht, kann sich ja mal die Distributionstools anschauen, susis yast z.B. kann auch im Textmodus laufen und somit über einfache ssh-Verbindungen benutzt werden. Trotzdem bietet es die Möglichkeiten eines "willst du Döner oda Pizza?"
Alles Möglichkeiten, die nicht mal so 200 MB Ram schlucken, damit ein X-Server an ist.
Ergo: viele Wege führen nach Rom. nicht nur der steinige schnelle ttyS0 für Blindstarter, oder komfortable langsame X-window für Sightseeingtouristen.

Gruß
Bakaroo

[Kontrolltroll]

Eine Kommandozeile ist ein GUI, genauer ein CLI. Ein GUI im Sinne einer Desktopoberfläche ist eine Shell, genau wie ein CLI. Beides übersetzt Inputs des Nutzers fürs OS.
Das Leben der Bits it übrigens ein gar eigenartiges: Nicht wenige von ihnen sind für Interfaces und zu wenige für echte Funktionen.

Im Übrigen braucht sich hier kein Windows Hoschi zu äußern: ihr habt kein CLI. Zumindest keines, das man sinnvoll verwenden will.

[Ihrgendwehr]

Genau sowas meinte ich ja, GUI muss ja nicht Windowmanager bedeuten...

Nur leider sind viele solche Oberflächen teils veraltet und verschlucken/verschweigen Parameter und sind meist auch nicht mal von den Entwicklern der Programme gemacht, die da konfiguriert werden.

Es würde mich z.B. sehr freuen wenn man einfach wählen könnte ob man sich lieber durch XXXX.conf wühlt oder das auf einer grafischen Oberfläche zusammenbastelt die dann die Änderungen eben in die XXXX.conf Datei einpflegt. Solche Oberflächen sind eben leider (noch?) zu selten, meiner Meinung nach und vielleicht liegt das auch daran, dass UI-Programmierung ein etwas undankbarer und fader Job ist (nehme ich an) - dauernd irgendwelche User zu berücksichtigen die z.B. meinen in 640x480 Auflösung arbeiten zu müssen stelle ich mir nicht einfach und eher frustrierend vor.

Edit die Antwort war an bakaroo und nicht an den Troll oberhalb...
Ich sag da nur Windows Power Shell
Außerdem kann man quasi jedes Linuxprogramm auch unter Windows verwenden, notfalls installiert man eben einen Linuxkernel neben Windows.

[bakaroo]

Es würde mich z.B. sehr freuen wenn man einfach wählen könnte ob man sich lieber durch XXXX.conf wühlt oder das auf einer grafischen Oberfläche zusammenbastelt die dann die Änderungen eben in die XXXX.conf Datei einpflegt.

Genau das ist die Idee. Du bearbeitest mit einem Script die ini-Datei. Das Script kann ein simples Perlscript in einer Cgi-Umgebung sein, dessen Webserver selbst z.b. lediglich ein Perl-Script ist.

dauernd irgendwelche User zu berücksichtigen die z.B. meinen in 640x480 Auflösung arbeiten zu müssen

Die grafische Darstellung selbst macht dann ein Webbrowser. Somit ist es auch egal, welche Auflösung der Admin nutzt. ja selbst das darunterliegende System ist egal. Zur Not würde selbst ein PocketPC gehen

@Kontrolltroll: dir ist schon klar, daß GUI ausgeschrieben "Graphical User interface" und CLI "command Line interface" heißt? Und daß die cmd unter Windows sinnlos ist, zeigt, daß du noch nie eine Windose administriert hast. achja: wenn du meinst, ich sei ein "windows-Hoschi", dann hast du eine elementare Grundregel übersehen: "Erst lesen, dann posten", denn wieso sollte man Samba auf einer Windose installieren?

Gruß
Bakaroo