Login
Newsletter

Thema: GUI oder Konsole?

60 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
6
Von rirasoft am Fr, 6. September 2019 um 14:43 #

Es kommt immer auf die Tätigkeit an. Arbeiten auf der Konsole: z.B. Software installieren / aktualisieren, Dateien verschieben / ein- und auspacken, Konfig Dateien bearbeiten, usw.,
Gui: Mail, Internet, Office, Spiele, Video schauen und Musik hören

  • 1
    Von Bert am Fr, 6. September 2019 um 16:14 #

    Es kommt immer auf die Tätigkeit an.

    Dito. Ich bin begeisterter Linux-Anwender, weil man sich das prima einteilen kann. 50% Konsole, 50% GUI in zeitlicher Hinsicht. Alles, was gut in der GUI-Konsole geht, wird da auch gemacht. Und alles, was besser mit der Maus geht, wird eben dort gemacht.

    0
    Von Franz Sauerzopf am So, 8. September 2019 um 10:40 #

    Ich schließe mich dieser Meinung an. Ich habe immer KDE offen und immer drei oder mehr Terminals, mit denen ich arbeite. Da stellt sich die Frage nicht, ob das "oder" sein soll. Beides ist ein jeweils notwendiger Teil meiner Arbeitsumgebung, je nach Aufgabe.

2
Von Potz Blitz am Fr, 6. September 2019 um 15:04 #

Den typischen Linux-Neuling schreckt die Konsole aber eher ab. Genauso wie Fachbegriffe und Fragen wie: "Möchten Sie für Snapshots lieber btrfs oder rsync verwenden?" Das weiß Otto-Normalanwender nicht (und will es auch nicht wissen)! Am besten also gar nicht erst fragen ...

  • 0
    Von Linux_user am Fr, 6. September 2019 um 15:58 #

    Ganz klar rsync, was ist das für ne Frage? ;-)

    • 0
      Von Calabi-Yau am Fr, 6. September 2019 um 16:55 #

      Genau die Frage stellt Linux Mint unmittelbar nach Installation des Systems. Nehmen wir an, ein interessierter Umsteiger von Windows wird damit konfrontiert: Weiß er, was btrfs oder rsync überhaupt sind? Wahrscheinlich nicht.
      Will Linux auf dem Desktop aus der Nische heraus, muss es verständlicher werden und darf Anfänger nicht gleich überfordern. Das beinhaltet, möglichst alles mit der GUI steuerbar zu machen und o.g. Fragen auch zu erläutern. Nicht in dicken Handbüchern, versteht sich. Laut Netmarketshare hatte Linux im August 2019 einen Marktanteil von lediglich 1,53 %. Und es hat schon seinen Grund, dass bei Linux Ubuntu einen höheren Marktanteil hat als Debian.

      • 0
        Von Jürgen Sauer am Sa, 7. September 2019 um 10:08 #

        Linux ist kein DAU System.

        Es kann sich mit einer Anfänger Distribution zwar als Pflegeleicht darstellen, aber Linux ist und bleibt für technisch Interessierte, die auch mal eine Thematik hinterfragen und sich informieren.

        Im Gegensatz zu den marktführenden user verblödenen "geheim" Systemen ist in der Gnu/Linux bzw. *BSD Welt alles offen gelegt und nahezu durch und durch dokumentiert, so das die Anwender tatsächlich wissen, was mit Ihren Daten (persönliche und Geschäftliche) passiert.

        Schönes Wochenende

        Jojo

        • 1
          Von msi am Sa, 7. September 2019 um 12:16 #

          1. Leute, die nicht Linux, BSD oder ein anderes freies Unix nutzen, als dumm abzustempeln, ist was zum Abgewöhnen.

          2. Dass in der Welt von Linux und BSD „alles offengelegt und nahezu durch und durch dokumentiert“ sei, stimmt auch nicht. Sowohl im Linuxkernel wie auch in den Kernen von BSD-Systemen finden sich Komponenten, die nicht quelloffen sind und nicht unter einer freien Lizenz stehen. Zudem ist zur Benutzung der Systeme mitunter das Installieren proprietärer Software nötig, bspw., um den vollen Leistungsumfang von Nvidia-Grafikkarten auszuschöpfen oder um einen bestimmten WLAN-Adapter zum Laufen zu bringen. Für Letzteres können zwar die Entwickler von Linux etc. nichts, die Nutzer sind aber trotzdem betroffen.

          3. Was mit den persönlichen und geschäftlichen Daten der Anwender passiert, hängt ja nicht einfach vom benutzten Betriebssystem ab, sondern auch wesentlich davon, wie sich ein Webbrowser verhält oder davon, was ein E-Mailprovider oder der Anbieter eines digitalen Zeitungsabos mit den verfügbaren Nutzerdaten anstellt.

          0
          Von Pardon moi am Mo, 9. September 2019 um 10:37 #

          Linux ist kein DAU System.

          Es kann sich mit einer Anfänger Distribution zwar als Pflegeleicht darstellen, aber Linux ist und bleibt für technisch Interessierte, die auch mal eine Thematik hinterfragen und sich informieren.

          Sorry, aber das halte ich für Unsinn.

          Linux ist sehr wohl ein System für DAUs oder besser ONUs. Da kann ich dir genügend ONUs vorstellen, die eben nicht "technisch" interessiert sind, und trotzdem wunderbar mit Linux klar kommen.

        0
        Von blablabla233 am Sa, 7. September 2019 um 12:04 #

        Das sehe ich nicht so, bei neuen Sachen ist überforderung ein muss!
        Das nächste wird sein per wikipedia den unterschied von rsync zu btrfs nach-zu-lesen und schon hat man was gelernt.
        Im übrigen ist es mir ganz egal ob Linux eine Desktopnische ist...ja es ist mir sogar recht, denn wenn verbreitung zu gross ist, ist stillstand in der entwicklung angesagt...niemand will millionen von "normalos" verärgern.

        0
        Von Pardon moi am Mo, 9. September 2019 um 10:44 #

        Laut Netmarketshare hatte Linux im August 2019 einen Marktanteil von lediglich 1,53 %.

        Boah, wenn ich immer so einen Schwachsinn lese, dann könnte ich...

        Zum einen, ist die Methode, wie NetMarketShare seine Zahlen ermittelt ist mehr als umstritten. Zum anderen sind reine "Prozentzahlen" ohne absoluten Bezug genau null wert.

        Nimm z.B. Steam Survey. Da hatte Linux mal einen Anteil von 1,6% und jetzt sind es dank China nur noch um die 0,8%. Die Frage ist nun, sind es weniger Linuxer geworden? Eben nicht, und darum kannst du deine Prozente sonst wo hinschieben ;P

      0
      Von blubb am Fr, 6. September 2019 um 19:05 #

      Weil du kein btrfs verwendest?

    1
    Von Bert am Fr, 6. September 2019 um 17:51 #

    Den typischen Linux-Neuling schreckt die Konsole aber eher ab.

    Teils, teils. Die meisten User interessiert das nicht. Ich kenne in der IT arbeitende Ingenieure, die WOLLEN NICHT damit konfrontiert werden. Aber die meisten können nicht und wollen dann keine Zeit hineinstecken. Einer meiner Bekannten hat sich fast zehn Jahre lang daran versucht und dann aufgegeben. Es waren die technischen Details, die ihn überfordert haben. So geht es den meisten. Sie kommen von Windows, und es denen zuviel. Zuviel deshalb, weil sie eben noch andere Dinge beschäftigt, und der "sch.... Computer" einfach nur ein paar dösige Aufgaben erledigen soll.

    Wer hier im Forum liest, ist interessiert, und dementsprechend auch bereit, ein paar mehr Schritte zu gehen.

    • 0
      Von was ist das am Fr, 6. September 2019 um 21:15 #

      Ich würde nicht pauschal so sagen. Ich bin mehr Windows Anwender und verwende sehr oft die CMD und die Git-Bash für Java, PHP, Git und konfigurationen für XAMPP. Klar, anders als bei Linux muss ich bei Windows manuell die Pfade angeben. Aber ist das gemacht, vermisse ich nichts mehr. Unter Linux oder Macos mache ich dann auch nicht mehr. Und es gibt da noch weiter Windows-Nutzer die ähnlich arbeiten.

      0
      Von stephanus am Sa, 7. September 2019 um 04:06 #

      Nicht nur Ingenieure wollen damit nicht konfrontiert werden, sondern auch Otto Normalverbraucher. ;-)
      Die meisten Benutzer kümmern sich noch nicht einmal um das Betriebssystem selbst (keine Updates, keine Virenscanner usw. ), obwohl jede Menge Videos über Windows 10 existieren.

      GUI / Konsole: Ich erledige die meisten Dinge über die Konsole. Irgendwie geht das schneller und
      besser als mit der Maus...

      0
      Von lilili am Sa, 7. September 2019 um 09:36 #

      Wer in der IT arbeitet und weder unter Windows noch unter Linux die Konsole bedient ist unfähig und nicht in der Lage seine Aufgaben zu erledigen. Manches geht im Netzwerk nur mit Konsole effektiv - gerade auch unter Windows. Er gehört gekickt.

      Etwas anderes ist der private Bereich wenn man einen popeligen Rechner hat. Da braucht man auch unter Linux die Konsole nicht wirklich mehr unbedingt.

      • 0
        Von Bert am Sa, 7. September 2019 um 12:11 #

        Wer in der IT arbeitet und weder unter Windows noch unter Linux die Konsole bedient ist unfähig ...

        stimmt ;-)

        ... und nicht in der Lage seine Aufgaben zu erledigen.

        ... stimmt nicht! :-)

        In der IT arbeiten genügend Leute, die werden dafür eingestellt, mit bestimmten Maschinen / bestimmter Software zu arbeiten. Manche machen das sehr erfolgreich und verdienen damit viel Geld.

        Der Sinn von Software ist es, den Menschen das Denken abzunehmen. Wer lieber mit der Konsole arbeitet, läßt sich nicht darauf ein. Daraus ergibt sich, wer mit der Konsole arbeiten kann aber keinen hochwertigen, hochbezahlbaren Job ausfüllt, ist unfähig. ;-)

      0
      Von Grantler am So, 8. September 2019 um 11:50 #

      In der IT arbeitende Ingenieure wollen nicht mit Technik belastet werden? Dann geht halt sterben! Oder Blumen pflücken! Schon mal was auf der GUI automatisiert?

    0
    Von Wiesensohle am So, 8. September 2019 um 12:07 #

    Den typischen Linux-Neuling schreckt die Konsole aber eher ab.

    Bin auf dem Amiga groß geworden und daher notorischer Mausschubser… Bin 2002 auf Linux umgestiegen. Konsole brauche ich nur dann, wenn sich meine Aufgaben nicht mit der GUI erledigen lassen… ich schätze GUI-Nutzung auf 98% und Konsole 2%…

    0
    Von rgsidler am Mo, 9. September 2019 um 09:58 #

    Da könntest Du schon früher ansetzen. Die meisten Windows-Benutzer bzw. Linux-Einsteiger wissen nicht einmal, was ein "Snapshot" sein und wozu man das überhaupt brauchen soll.

    Es grüsst


    Roland

0
Von Max Maier am Fr, 6. September 2019 um 15:38 #

Moin

warum Konsole?

Ich kann doch für jedes Programm einen grafischen Überzug in bunt stricken. Dann brauche ich nur noch klicken und die vorgegebenen Symbole, Zeichen oder Zahlen auswählen.

1. das ist nicht schwer
2. ich bin zu faul mir die Parameter zu merken
3. ich kann zwar 10-Finger blind tippen, aber seit meinen Anfängen bei Atari und Apple habe ich immer alles schööön präsentiert bekommen, das will ich auch weiter so haben
4. man kann ja für die Konsolenfreunde in einer GUI auch ein Fenster zum Tippen als Alternative für die Knöpfe einbauen
5. Wenn mir jemand mit Energieverschwendung wegen des grafischen Overheads kommt, ich habe mein Auto abgeschafft und fahre Fahrrad oder mit öffentlichen Verkehrsmitteln ;-)

CU Max

  • 0
    Von Linux_user am Fr, 6. September 2019 um 15:59 #

    warum Konsole? firefox -P

    0
    Von anonymous am Fr, 6. September 2019 um 16:22 #

    Weil grafische Anwendungen sich (noch) nicht so verknüpfen lassen wie textbasierte Applikationen.

    Bei TUI-Applikationen wie cfdisk oder make menuconfig (also groß alles curses-basierte) stimme ich zu.

    0
    Von msi am Fr, 6. September 2019 um 21:17 #

    1. das ist nicht schwer

    Genau darauf, dass eine Nutzerschnittstelle nicht unnötig schwierig zu bedienen ist, zielt vernünftiges Design ab.

    2. ich bin zu faul mir die Parameter zu merken

    Angesichts dessen, dass Unix-Kommandos mitunter etliche Optionen haben (z. B. rsync) oder selbst eine Art domänenspezifische Programmiersprache darstellen (z. B. find) und zudem gleichlautende Optionen in verschiedenen Kontexten völlig unterschiedliche Dinge bedeuten können, wird niemand, der noch halbwegs bei Trost ist, seine Zeit damit verschwenden, „die Parameter“ auswendig zu lernen.

    Das ist ohnehin weitgehend unnötig, denn die Optionen für ein Kommando lassen sich zumeist relativ schmerzlos in der Handbuchseite oder der eingebauten Kurzhilfe nachschlagen.

    3. ich kann zwar 10-Finger blind tippen, aber seit meinen Anfängen bei Atari und Apple habe ich immer alles schööön präsentiert bekommen, das will ich auch weiter so haben

    Blind im Zehnfingersystem tippen zu können und eine bestimmte Programmiersprache (z. B. Bash) zu beherrschen, sind zwei komplett verschiedene Dinge.

    4. man kann ja für die Konsolenfreunde in einer GUI auch ein Fenster zum Tippen als Alternative für die Knöpfe einbauen

    Das kann in der Tat sinnvoll sein und wird auch gemacht. Zum Beispiel hat Firefox eine „Web-Konsole“. Ein weiteres Beispiel wäre AutoCAD.

0
Von Töppke am Fr, 6. September 2019 um 16:34 #

Ganz klar: GUI
Bin nur Endanwender, kein Spezialist oder Programierer.

1
Von Andy_m4 am Sa, 7. September 2019 um 00:47 #

Warum nicht beides miteinander verbinden. Wieso nicht mit ls ne Dateiliste ausgeben und dann per Maus welche per Drag und Drop irgendwo hinziehen?
Ich kann mir da durchaus so Einiges vorstellen, was machbar wäre.

  • 0
    Von Josef Hahn am Sa, 7. September 2019 um 17:43 #

    Oh, die Idee finde ich spannend. Wenn man da noch ein paar Feinheiten zuende denkt, und um noch ein paar weitere simple GUI-Konzepte erweitert - vielleicht auch mal ein Button, auf den mal klicken kann - könnte das ein interessanter Mittelweg sein. Das API sollte idealerweise simpel bleiben, sonst ginge ein wesentlicher Vorteil der Konsole ja verloren. Nicht ganz einfach. Kennst du denn ein Projekt, was mit sowas schonmal experimentiert hat?

    • 0
      Von Falk am Sa, 7. September 2019 um 18:08 #

      Wie wäre es damit (ist der 2. Text - den ersten hatte vor einigen Stunden mein Firefox gefressen)

      Bisher sind solche Befehle wie ls mit ASCII-Color-Informationen angereichert. Die kommen allerdings aus der ASCII-Tabelle.

      Wie wäre es, wenn man stattdessen eine Ausgabe mit Metainformation geben würde?

      Z.B. sendet der Befehl ls eine url (file://...) und eine Benennung (datei001) mit. Das übernimmt die Bibliothek. ls ist nach dem Funktionsaufruf auch völlig raus aus der Verwaltung (Speicher, ...). Nun gibt es einen "Verwalter" in Wayland und X oder einzeln, der diesen Dienst Frameworks wie Gnome oder KDE anbietet (GPM 2?). Wenn nun eine (Maus-)Aktion mit einem Zeichen ausgelöst wird (z.B. D&D), kann dazu die Metainformation abgefragt werden.

      - Wichtig fände ich, dass es trotzdem noch einfach bleibt und in die GNU-Tools nicht ein riesiges Framework reinkommt. Denn im Gegensatz zu den GUIs sind echte Unix-Programme meist absichtlich klein und beschränkt.
      - muss man dabei über Sicherheit reden? Ein Programm kann ja schließlich ziemlich viel in die Metainfos reinschieben und evtl. auch etwas untergeschoben bekommen ...
      - Pipes haben evtl. einfach nicht diese Schnittstelle, dass die Metainfo einfach in Ablage P (Edit: /dev/null) fällt

      Im Übrigen: Ich hab grad keine Zeit und nicht genug Knoff Hoff :o)

      Interessant wäre es aber schon, bevor da wieder ein so großer Druck entsteht, dass jemand großes Monster erschafft und nichts einfaches erschafft. Es wäre gut, wenn die Kommandozeile auf einfache Weise stetig verbessert würde. Dazu gehören evtl. auch ein paar Experimente. Das oben ist ein Vorschlag. Die Idee finde ich auch gut.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Sep 2019 um 18:09.
      • 0
        Von Andy_m4 am So, 8. September 2019 um 09:58 #

        Ich würde das auch gar nicht unbedingt im großen Stil aufziehen.
        Also jetzt hat man ja bei einer Kommandozeile innerhalb seiner Desktopumgebung im Wesentlichen die Shell als solches (bash or whatever) und eine Terminalemulation, die sozusagen das Interface zur Shell herstellt.

        Das ich machen würde ist sozusagen die Terminalemulation eben nicht nur ein Frontend sein zu lassen, sondern Ausgaben zusätzlich mit Semantik hinterlegen. Sprich wenn irgendwo ein Dateiname ausgegeben wird das halt nicht nur textuell der Name der Datei ist, sondern verknüpft damit die Information, das dieser Text eine Datei (Pfad oder was auch immer) repräsentiert.

        Da mir die "Terminalemulation" (die ja keine reine Terminalemulation mehr ist) gehört, kann ich halt auch auf Drag-Ereignisse selbst reagieren. Zieh ich also nen angeklickten Dateinamen irgendwo hin, gebe ich dann einfach dem Desktop-System die Information so mit wie es wäre wenn man es aus nem Dateimanager Drag-gen würde.

        So hätte man zunächst ein mal nur eine Applikation und auch keinen Bedarf irgendetwas anderes anpassen zu müssen.
        Das begrenzt sicherlich die Möglichkeiten, aber ich denke mal allein damit kommt man schon sehr weit.
        Und der Aufwand ist überschaubar. Zumal man ja nicht alles auf einmal umsetzen muss, sondern es Schritt für Schritt machen kann. Was noch nicht umgesetzt ist, deklarierst Du halt als Text und es verhält sich erst mal noch so wie bisher gewohnt.

        Überschaubarer Aufwand mit raschen einstellen von ersten sichtbaren Erfolgen sind schon mal gute Vorzeichen, damit so ein Projekt ans rollen kommt.

      0
      Von Andy_m4 am So, 8. September 2019 um 10:06 #

      Kennst du denn ein Projekt, was mit sowas schonmal experimentiert hat?
      Nein. Aber mich beschäftigt die Thematik schon eine Weile. Auf meiner Suche bin ich bisher aber noch nicht wirklich auf was gestoßen ,weshalb ich mich mal selbst daran machen wollte, wenn sich Zeit & Muße ergibt.

      Ich empfinde übrigens die bisherige Shell nicht als simpel. Man hat sich dran gewöhnt und beherrscht sie und empfindet es deshalb als simpel. Aber umso mehr man drüber nachdenkt, umso mehr Dinge fallen einem auf die man besser lösen kann.

      Das ist auch nicht als Negativ-Kritik gemeint. Wenn man guckt, wie sich das alles entwickelt hat, dann erklärt sich daraus warum bestimmte dinge so sind wie sie sind.

      Was mich nur wundert ist, das innerhalb der Linux-Community da niemand ist der mal mutiger an die Sache ran geht und ruhig auch mal mit Ungewöhnlichen experimentiert.

      Die Shell wird ja immer als wichtiges Werkzeug hochgehalten. Und trotzdem finden dort die wenigsten Innovationen statt. Grotesk.

      • 0
        Von msi am So, 8. September 2019 um 14:54 #

        Die Shell wird ja immer als wichtiges Werkzeug hochgehalten. Und trotzdem finden dort die wenigsten Innovationen statt. Grotesk.

        Das halte ich für eine einigermaßen gewagte Aussage. Zudem kommt es ja auch nicht auf die bloße Menge an Innovationen an, sondern darauf, ob sie wesentliche Verbesserungen darstellen.

        Ich habe da mal ein paar Dinge zusammengesucht:

        Bereits 1989 erschien eine von Tom Duff für Plan 9 entwickelte Shell namens rc (die zuerst allerdings einfach Plan 9 Shell hieß), die so Einiges an Innovationen zu bieten hatte. Zu den erklärten Zielen des Projekts gehörte es, eine „weniger idiosynkratische Syntax“ als die klassische Bourne-Shell zu verwenden. Eine von Duff verfasste Beschreibung von rc gibt's unter https://9p.io/sys/doc/rc.html.

        Diese Shell wurde dann Anfang der 90er von Byron Rakitzis für Unix reimplementiert und später von anderen weiterentwickelt. Die aktuelle Version ist 1.7.4 und kann bspw. unter Debian einfach über die Paketverwaltung installiert werden. Den Quelltext gibt's unter https://github.com/rakitzis/rc. Soweit mir bekannt, hat rc aber einen wesentlich geringeren Funktionsumfang als die weit verbreiteten Bourne-ähnlichen Shells wie Bash, Z Shell oder KornShell.

        Ein Folgeprojekt von Rakitzis' Unix-Port der Plan-9-Shell war schließlich die Entwicklung von Es, einer weiteren Shell, die von Rakitzis zusammen mit Paul Haahr geschrieben wurde. Ziel war dabei, durch eine grundlegend andere Konzeption der Shell-Sprache die Programmierbarkeit der Shell wesentlich zu verbessern. Orientiert wurde sich dabei an funktionalen Programmiersprachen, wie Scheme und ML, aber auch an Tcl. Den Standardtext zu Es gibt's unter: https://stuff.mit.edu/afs/sipb/user/yandros/doc/es-usenix-winter93.html.

        Es wird schienbar auch noch mehr oder weniger weiter gepflegt. Auf Systemen aber, die musl libc verwenden, lässt sich der Quelltext aus dem verlinkten GitHub-Depot nicht übersetzen.

        Eine ganz aktuelle Innovation, die mit all dem eher nichts zu tun zu haben scheint, ist im Übrigen Nu Shell. Da wurde auch kürzlich auf der Website des Linux-Magazins drüber berichtet.

        • 0
          Von Andy_m4 am So, 8. September 2019 um 19:14 #

          Bereits 1989 erschien eine von Tom Duff für Plan 9 entwickelte Shell namens rc
          Ist mir bekannt. Ich bezog mich aber auf Linux.

          Den Quelltext gibt's unter https://github.com/rakitzis/rc. Soweit mir bekannt, hat rc aber einen wesentlich geringeren Funktionsumfang als die weit verbreiteten Bourne-ähnlichen Shells wie Bash, Z Shell oder KornShell.
          Kein Wunder. rc ist ist ja auch schon etwas älter. Abgesehen davon das Plan-9-Tools ohne Plan-9 System nur begrenzt Sinn machen.

          Ein Folgeprojekt von Rakitzis' Unix-Port der Plan-9-Shell war schließlich die Entwicklung von Es
          Das kannte ich noch nicht.

          Konzeption der Shell-Sprache die Programmierbarkeit der Shell wesentlich zu verbessern. Orientiert wurde sich dabei an funktionalen Programmiersprachen, wie Scheme und ML
          Was sehr interessant klingt und mir auch eher gefallen würde. Mit der Syntax rund um Bash und Co konnte ich mich nie so richtig anfreunden. Daher schreib ich damit auch eher selten Skripte.

          Eine ganz aktuelle Innovation, die mit all dem eher nichts zu tun zu haben scheint, ist im Übrigen Nu Shell.
          Klingt ein wenig nach Powershell.
          Und das sind so Sachen die ich unbedingt drin haben will. Es ist echt nervig wenn irgendwelche Werte nur textuell sind und man die erst umständlich rausfischen und ggf. parsen muss um sie weiter zu verarbeiten.

          Auch die Berücksichtigung des Inhalts von Dateien (sprich: den Dateityp) schwirrt auch schon länger in meinen Gedanken zu der Thematik herum.

          Gut. Zugegeben. Es gibt ein paar nette Sachen.

          Nichtsdestotrotz führt das Thema doch ein Nischendasein.

          Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh.
          Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.

          • 0
            Von msi am Mo, 9. September 2019 um 16:44 #

            Gut. Zugegeben. Es gibt ein paar nette Sachen.

            Nichtsdestotrotz führt das Thema doch ein Nischendasein.

            Das stimmt schon. Ich habe diese paar Sachen ja sozusagen aus 30 Jahren Unix- und Linux-Geschichte zusammengekratzt, wobei ich allerdings z. B. fish gar nicht erwähnt habe.

            Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh.
            Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.

            Mir fallen da verschiedene mögliche Gründe ein.

            Zum einen ist es so, dass POSIX eine erweiterte Bourne-Shell als Standard für alle Unix-Systeme spezifiziert und zumindest unter Linux und OpenBSD standardmäßig erweiterte – und in ihrem Erweiterungen weitgehend kompatible – POSIX-Shells zum Einsatz kommen. Solaris wird das schätzungsweise auch so machen. (FreeBSD fällt hier aus der Reihe, aber auch dort ist zumindest die Standard-Shell für normale Nutzer eine erweiterte POSIX-Shell, wenn auch deren Erweiterungen nicht so weit reichen wie bei Bash, KornShell oder Z Shell.)

            Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.

            Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.

            Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.

            Das führt gleich zum nächsten Punkt: Bei Betriebssystemshells spielt Rückwärtskompatibilität eine große Rolle.

            Desktopumgebungen unter Linux nimmt, wie mir scheint, ohnehin niemand wirklich ernst, was ich gut nachvollziehen kann. Daher ähnelt dieser Bereich, wohl oder übel, auch eher einer Spielwiese für Entwickler.

            Mir wäre mehr Diversität bei Unix-Shells auch eher ein Graus. Gut wäre stattdessen, wenn einfach eine Shell wie Es den Status einer gängigen Alternative zu den Bourne-ähnlichen Shells erlangen würde.

            • 0
              Von Andy_m4 am Mo, 9. September 2019 um 18:25 #

              z. B. fish gar nicht erwähnt habe.
              Ja. Fish kenne ich auch. Finde ich eigentlich auch gar nicht so schlecht. Bietet nette Funktionen und ist auch vom Start weg sehr gut benutzbar ohne das man irgendwas konfigurieren muss.
              Man hat sozusagen schon was davon, indem man sie einfach nur installiert.
              Mir geht sie aber in manchen Dingen einfach nicht weit genug und macht Dinge anders als ich sie mir wünschen würde.
              Dennoch ist es eine sehr empfehlenswerte Shell für Leute die da mal was anderes abseits von Bash probieren wollen.

              Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.
              Ich sag ja auch nicht, das andere Shells dafür verschwinden sollen. Aber als Ergänzung? warum nicht?

              Kann man ja so ein bisschen vielleichen mit dem vi. Den gibts auch "überall". Wenn Du also irgendwie unter nem "UNIX" ne Datei editieren willst, kannst Du sicher sein nen vi zu haben. Es ist praktisch, wenn man den zumindest halbwegs beherrscht.
              Trotzdem würde ich nicht auf die Idee kommen ihn deshalb ständig einzusetzen.

              Warum sollte ich das bei einer Shell nicht machen? Ich muss ja nicht mal meine Standardshell ändern. Ich kann ja meine Lieblingsshell jederzeit aufrufen, wenn ich meine ich möchte sie in dem Augenblick nutzen.

              Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.
              Genau dann ist aber die Shell eher wacklig. Gerade wenn Du Scripting-Sachen machst. Es gibt einfach so viele Stolperfallen. Klar kann man die umgehen. Aber besser ist natürlich, wenn es die gar nicht erst gibt.

              Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.
              Hat ja auch niemand behauptet, das bestehende Skripte alle neu geschrieben werden sollen.

              Aber wo wir gerade beim Scripting sind:
              Ne Shell erfüllt ja i.d.R. heutzutage zwei Aufgaben. Erstens das schon angesprochene Scripting, zweitens eine interaktive Benutzerstelle. Mal abgesehen davon, das es gegen "one Job one tool" verstößt ist es auch so, das es beides nicht optimal erfüllt und vielleicht auch nicht erfüllen kann.
              Nicht umsonst gibt es ja immer mal wieder Bestrebungen den Scripting-Teil mit was anderem zu machen. Perl ist ja da das klassische Beispiel für. Die reellen Geschehnisse zeigen also schon, das es da eine gewisse Spannung in der Thematik gibt.

              Fürs Bereich Skripting hat sich da ne Menge getan. Sei es nun Perl, Python, Ruby oder was auch immer, da gibt es reichlich Optionen die den Teil angehen und Alternativen bieten. POSIX-Shell-Scripte oder von mir aus auch noch Bash-Skripte haben natürlich weiterhin den Charme, das sie überall ohne großarige Voraussetzungen laufen. Aber damit hat es sich auch schon an Vorteilen.
              Auf der Seite der Interaktion mit dem Nutzer hast Du das meines Erachtens nach weniger Bewegung drin. Es gibt sie, aber die sind eben (wie schon gesagt) nicht so präsent.

              Wie gesagt. Es schätze es auch, wenn es einen Minimalstandard gibt der überall funktioniert. Für den täglichen Gebrauch wäre mir das aber dann doch zu rudimentär und unkomfortabel.

    0
    Von Bert am So, 8. September 2019 um 09:30 #

    Zumindest teilweise gibt es das.

    Ich für meinen Teil arbeite gerne mit dem Programm "Konsole" in der GUI.
    Dort per Tastatur aufgerufen 'mc' (Aufruf könnte man auch komplett mit dem Desktop verbinden)
    lässt sich einiges per Maus machen. Nur nicht Drag&Drop. Beim Mac (zertifiziertes UNIX mit Bash) geht was.

    Unter Linux kenne ich nur Terminalprogramme, die damit zurechtkommen, mit Klick auf "Knöpfe" und Doppelklick auf andere Elemente inn mc. Ich benutze beides, Tastatur und Maus.

    Man könnte sich aber weitergehendes selber machen. Nur nicht Drag&Drop, sondern über Kontext-Menü.

    Es fehl also jemand, der Yoink äh ... ja nein Yoink für die Linux-Welt nachprogrammiert, wie damals Launchd nachprogrammiert wurde.

    • 0
      Von Andy_m4 am So, 8. September 2019 um 12:55 #

      Beim Mac (zertifiziertes UNIX
      Ja. Dummerweise nützt Dir so was heutzutage wenig. Linux ist inzwischen so dominant, das man vermehrt auf Programme trifft, die nur unter Linux (vernünftig) laufen.
      Grad bei KDE5 hat man das schön beobachten können.
      Wenn man mal überlegt, das KDE sogar mal unter Windows anständig lief, dann sind solche Entwicklungen eher unerfreulich.

      Zumal ja Viele aus der Linux-Community früher immer Microsoft vorgehalten haben das die eigene Standards durchdrücken und zu nichts kompatibel sind. Und jetzt macht mans nicht besser.

      Man könnte sich aber weitergehendes selber machen. Nur nicht Drag&Drop, sondern über Kontext-Menü.
      Ja. Wobei ich ungern Sachen machen würde, die nur auf einem Desktop funktionieren. Wenn dann würde ich wohl eher auf freedesktop.org-Standards zurückgreifen auch wenn ich dafür eingeschränkte Möglichkeiten in Kauf nehmen muss.

      Es fehl also jemand, der Yoink äh .
      Das kannte ich bisher noch gar nicht. Zeigt aber Ansätze wie ich sie mir auch vorstelle.
      Als Demo wie so was aussehen könnte ist die Seite jedenfalls prima

      Es fehl also jemand, der Yoink äh ... ja nein Yoink für die Linux-Welt nachprogrammiert
      Naja. Warum nur für Linux? Wenn, dann gleich plattformunabhängig.

      • 0
        Von Josef Hahn am So, 8. September 2019 um 17:24 #

        Es ist ja sowieso immer wieder zu beobachten, dass MS eigentlich lieber ein abgeschlossenes Windows ala iOS/Android hätte, in dem ohne Tricksereien nur über den Store irgendwas installieren kann, und die Software dann auch nicht einfach per win32 api loslegt, sondern nur über "moderne" Schnittstellen, die überall verkappt sind. Wo solche Systeme die Normalität werden, ist auch Plattformunabhängigkeit nicht einfach. Schreib mal einen Webbrowser für iOS...

        0
        Von Bert am Mo, 9. September 2019 um 05:06 #

        Das wid für Drag&Drop nicht gehen, weil die zugrunde liegenden Architekturen das nicht zulassen werden. Aber schön wär's.

        Allein Yoink! ist doch eine fürchterliche Krücke. Aber interessant, dass das mit einer entsprechenden bash-Konfiguration möglich ist. Also müsste man das auch für Linux hinbekommen. Ich persönlich werde mich in nächster Zeit mal um die KDE-Konfiguration von Kontext-Menüs hermachen und meine eigenen Skripte durchgehen, was ich dahin übertragen kann.

        • 0
          Von Andy_m4 am Mo, 9. September 2019 um 09:52 #

          Das wid für Drag&Drop nicht gehen, weil die zugrunde liegenden Architekturen das nicht zulassen werden. Aber schön wär's.
          Wenn es plattformspezifischen Code im überschaubaren Rahmen braucht, kann ich damit auch noch leben.
          Was ich halt nicht will ist so was wie:
          Läuft nur auf Linux
          Läuft nur auf KDE
          Läuft nur bei Vollmond
          :-)

          Ich persönlich werde mich in nächster Zeit mal um die KDE-Konfiguration von Kontext-Menüs hermachen und meine eigenen Skripte durchgehen, was ich dahin übertragen kann.
          Ja. Klingt alles ja auch ganz interessant und relativ einfach umzusetzen. Von der her ist es schon eine Sache, die man "einfach mal machen kann".

    0
    Von Pardon moi am Mo, 9. September 2019 um 11:00 #

    Ja, das "oder" verstehe ich auch nicht. Es gibt Aufgaben, die man besser in der GUI erledigt und andere sind wieder besser in der Konsole aufgehoben.

1
Von kubuntuuser am Sa, 7. September 2019 um 17:09 #

Das Ergebnis ist in den Kommentaren nachzulesen. Da hauen die Gegner und Befürworter aufeinander ein, weil sie sich jeweils auf einen ganz anderen Anwendungsfall beziehen.

Die Frage sollte eher in die Richtung "bevorzugen Sie zur Administration ein GUI oder die Konsole" gehen.

Persönlich bevorzuge ich hier die Konsole. Wo es passt nehme ich auch mal ein GUI.

Ich schätze mal, dass die Zahl derer die umfangreiche Briefe in der Konsole schreiben gegen Null geht. Emails werden sicherlich zumeist auch nicht in der Konsole abgerufen oder verfasst. Web-Seiten rufen vermutlich auch nur wenige Anwender in der Konsole auf. Es kommt eben auf den Anwendungsfall an.

Die Konsole ist der Favorit bei administrativen Aufgaben. Nicht nur bei Linux. Selbst bei der Administration von Windows-Systemen können viele Dinge nur auf der Kommandozeile gemacht werden.

Also bitte Pro-Linux: Die Umfragen etwas sinnvoller gestalten, dann gibt es auch verwertbare und aussagekräftige Ergebnisse. So ist es vertane Zeit.

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Sep 2019 um 17:11.
1
Von arnulf am Sa, 7. September 2019 um 18:38 #

Moin,
ich bin froh das ich beides habe. Es würde mir der Komfort fehlen den beide bieten.
Gruß

  • 0
    Von Falk am Sa, 7. September 2019 um 20:17 #

    Genau. Ich selbst habe keine Server zu adminstrieren (bis auf bald einen Entwickerserver und zu Hause).

    Bei der Entwicklung werden z.B. die Git- und Angular/Node-Befehle in die Kommandozeile gehackt (lustigerweise keine Java-Befehle). Auch Docker-Befehle. Wenn ich aber einen Überblick möchte und git status nicht ausreicht, dann wird ein Graphisches Tool gestartet (z.B. gitk). Bei der Java-Entwicklung sowieso.

    Auch bei der Installation: Einzelne Programme werden auch mal auf der Kommandozeile installiert. Muss ich suchen und es ist mehr als grep/find/less nötig, dann nehme ich natürlich gerne was grafisches.

1
Von Con Sol am So, 8. September 2019 um 13:37 #

Moin,
ich bin froh das ich beides habe. Es würde mir der Komfort fehlen den beide bieten.
Gruß

Con Sol

0
Von needle am So, 8. September 2019 um 14:06 #

Moin,

aus der Erfahrung muss man sagen: "es hängt davon ab". Fakt ist, wenn man professionelles Equipment nimmt z.B. Carrier Grade oder zumindest Enterprise Grade Endgeräte, also kommerzielles Equipment wird beides angeboten GUI sowie CLI. Jaja, die meisten bedienen sich da auch des Linux Kernels, so das wir beim Thema bleiben. Und natürlich gibt es auch professionelles Equipment dass etweder oder anbietet. Manche professionellen Hersteller haben auch versucht die CLI durch eine GUI zu ersetzten, ohne Erfolg. Die Hersteller mussten dann die CLI wieder zugänglich machen, da die Kunden es so gewünscht haben.

Oft ist es so dass die CLI mehr Möglichkeiten bietet als die GUI, aus verständlichen Gründen, man kann nicht so viel kaputtmachen. Spezielle Funktionen werden nur in der CLI angeboten, für die professionellen Anwender die sich damit sehr gut auskennen und wissen was sie tun und warum.

Speziell hier muss ich sagen, dass ich die CLI benutze und auch bevorzuge, aber das ist durch meine Tätigkeit bedingt. Aber es gibt Geräte da habe ich lieber das GUI weil drei Klicks in der GUI, 22 CLI Kommandozeilenparameter generiert in der Konfig, die mir nicht so geläufig sind und ich damit unendlich lang beschäftigt wäre diese 22 Kommandos richtig zu setzten. Hier sind speziell Firewalls gemeint, da arbeite ich gerne in der GUI. Bei Routern und Switchen wird CLI benutzt.

Also das eine wird nicht ohne das andere Koexistieren können. Auch wenn manche Hersteller das so gerne hätten und die CLI als ein "deprecated UI" propagieren, zumidest versuchen sie es, aber ohne Erfolg. Lasst Euch nicht bevormunden.

  • 0
    Von zettberlin am So, 8. September 2019 um 22:59 #

    Ist hier genauso mit GIS.
    Da kann man so ziemlich alles und noch etwas mehr mit WFS/WMS Kommandos und ECQL machen aber in der Weboberfläche von Geoserver gehen selten genutzte Aktionen in 1 Minute, während man für die gleiche Aktion einen Nachmittag lang Dokumentation lesen und oft erst suchen muss, bevor man die gleiche Aktion in 30 Sekunden als Kommandozeile tippen und abschicken kann. Bis zum nächsten Mal in 3 4 Wochen.

    Natürlich ist es dennoch unverzichtbar, dass der ganze Kram auch programmiert werden kann. So kann ich öfter gebrauchte Aktionen in einer grafische Anwendung einbauen und Curl an den Server schicken, der mir JSON zurückgibt.
    Der Nutzer bekommt dann Suchmasken und Landkarten. Zum Klicken.

mehr GUI
0
Von walker1973 am So, 8. September 2019 um 16:44 #

Ich Arbeite viel am Rechner aber die Konsole habe ich eher selten auf war Früher mal anders. Habe Pamac am laufen und sobald das Tray Icon was anzeigt Update ich normal sofort. Da ich nur KDE Plasma Verwende habe ich da aber immer wieder mal Probleme weil Pamac unter KDE öfter hängt das Nervt und diesem Falle muss ich dann auf die Konsole zurück greifen. Würde mir Wünschen das Sie das endlich mal in den Griff kriegen würden dann würde ich das nur noch mit Pamac machen.

1
Von zettberlin am So, 8. September 2019 um 22:52 #

Für Einstellungen, Updates, Installation ist die Kommandozeile überlegen.

Aber Computer sind kein Selbstzweck. Ihr Sinn sind Anwendungen für komplexe Aufgaben und Unterhaltung, in dieser Reihenfolge(weil fast alle Unterhaltungsinhalte auch auf Computern produziert werden)

Zeichnen von Landkarten, Konstruieren von Maschinen, Bearbeiten von Fotos, Produktion von Musik und Filmen, Schreiben von Texten etc etc

Alles das geht von der Konsole aus aber es gibt gute Gründe dafür, dass all das mit GUI Anwendungen gemacht wird.

Wer nichts von alldem tut, ist eben ein reiner Systemadministrator. Das kann Spaß machen aber wenn es was erwirtschaften soll, muss irgendwas von dem oben genannten damit gemacht werden. In Anwendungen mit GUI. Egal ob Standalone oder im Browser oder auf spezialisierter Hardware.

Pro-Linux
Gewinnspiel
Neue Nachrichten