opensource nicht so gerne gesehen

arbeitssklave schrieb:
> Ich beobachte, dass häufiger Windows und visualstudio oder MacOS
> eingesetzt werden.

Und ich beobachte beides. VisualStudio und Eclipse. Je nach Entwickler.

> Meist wird auch versucht alle Komponenten selbst zu entwickeln,

Auch das kenne ich anders.

Heinz schrieb:
> Als weiteres Argument kommt oft "Lizenzmodell".

Stimmt. Also beispielsweise wenn es um SQL Server vs MySQL/MariaDB als 
Backend-DB geht (von Oracle ganz zu schweigen). Da sollte man die 
Lizenzmodelle wahrlich im Auge behalten.

> Man möchte seine Software nicht veröffentlichen, also nutzt man keine
> open source Komponenten.

Die diversen Lizenzmodelle von Open Source sind keineswegs durchweg so 
restriktiv, wie in diesem Satz suggeriert - besonders, wenn man selbst 
entwickelte Software nicht verkauft, sondern einsetzt. Und die 
Lizenzmodelle von beispielsweise Microsoft und Oracle sind ein Risiko 
für die geistige und ggf auch finanzielle Gesundheit.

Hans schrieb:
> Aber was ich noch NIE! gesehen habe in den bisherigen
> Betrieben ist, dass eine Firma selber aktiv eine Open Source Library
> weiterentwickelt oder anderweitig die Open Source Community unterstützt

Mir fallen da schon ein paar ein, die Libs und Produkte als Open Source 
supporten oder direkt erstellt haben. Redhat und Suse beispielsweise. 
Aber auch IBM (z.B. Postfix).

inggg schrieb:
> (Dualboot hatten
> unsere Windows-Admins kaputtkonfiguriert... Na dann halt nicht...)

Ergibt m.E. auch nicht mehr viel Sinn. Sondern man nimmt das eine System 
als Host, das andere läuft als VM. Was auch als Windows on Windows Sinn 
ergibt, weil die Anforderungen an eine Entwicklermaschine u.U. mit denen 
der Firmen-IT kollidieren.

C. A. Rotwang schrieb:
> Web-Bereich zähle ich jetz gerade nicht zur (klassischen) Industrie wie
> Maschinenbau, Medizintechnik, Chemie, Energieerzeugung, Flugzeugbau,
> Bauwirtschaft ...

Würde ich jetzt nicht sagen. Viele solcher Geräte sind vernetzt, werden 
via Netz bedient. Und das schon seit Jahren vorwiegend via Browser. 
Teils direkt, teils mit Servern dazwischen, die als zentrale Instanz 
operieren.

243890 schrieb:
> Wie groß ist denn z.B. der Martkanteil von embedded Windows oder Solaris
> im Vergleich zu Linux und BSD? Welcher Hersteller würde z.B. Windows in
> ein autonomes Auto oder ein anderes IoT-Gerät einbauen.

Von EMC kannte ich mal ein SATA SAN Speichersystem für iSCSI oder 
Fibre-Channel, in dem seltsamerweise ein Windows werkelte.

In Fahrkarten-, Bank- und Tankstellenautomaten ist Windows häufig 
anzutreffen. Auch auf Verlaufsanzeigen in Nahverkehrsbussen habe ich 
gelegentlich schon typische Windows-Grüsse gesehen.

Der Witz an Embedded ist halt: Was drin steckt siehst du nur, wenn es 
einen Bildschirm hat und nicht mehr funktioniert. Crash-Schirm (ehem. 
Blue Screen) => Windows, Textsalat für Eingeweide => Linux.

Aha schrieb:
> schon zu meiner Diplomarbeit im '96 so und ist's immer noch.

Tja, ein grosses Lob dem Ventura Publisher unter DOS/GEM. ;-)

1. Problem mit Open Source sind lizenzen. Bei manchen muss man den 
Quellcode offen legen, was bei quasi jedem Industrie-projekt 
indiskutabel ist.
Andere dürfen kommerziell nicht verwendet werden.
Bei der meisen Open Source-SW ist das nicht der Fall, aber irgendjemand 
muss das ja vorher prüfen. Bei uns hat die Rechtsabteilung einen Stapel 
von über 400 Programmen und Libs auf dem Tisch, die auf ihre Nutzbarkeit 
für intern/Kunde/geheim geprüft werden müssen. Da muss dann auch noch 
die IT ran, die prüft obs Maleware enthält.
Wenn ich die Wahl hab 1000€ für ein kommerzielles Produkt zu zahlen, 
oder 2000€ für die juristische Prüfung auszugeben, ist die entscheidung 
klar.

2. Garantie & Codequalität
Firmen garantieren für ihr SW für bestimmte Features oder Code Qualität 
(z.B. AUTOSAR-Konform, MISRA-getestet usw.) Bei OS muss man sich selbst 
um diese Punkte kümmern, was erheblich mehr Aufwand bedeuten kann, als 
es von extern zu kaufen. Eventuell hat man selber auch gar nicht die 
Kapazität übrig den Code selbst zu verifizieren.

3. Support & Dokumentation
Wenn irgendwas mit Orcad nicht so funktioniert wie ich mir das 
Vorstelle, schau ich in die Anleitung, oder rufe den Support an und hab 
in 10 min meine Lösung. Bei KiCad ist das eine rudimentär und das andere 
Inexistent. Heißt nicht, dass Kicad ein schlechtes Programm ist, aber 
einen Support zu bezhalen ist in der Regel billiger als Mitarbeiter die 
Probleme selbst lösen zu lassen.
Wir hatten z.B. grad den Fall, dass wir paralell eine Open-Source-lib 
und eine Kommerzielle Lib evalutiert haben.
Nach 12 Mann-Wochen arbeiten mit der weitestgehend undokumentieren 
OS-lib, funktionieren bestenfalls 20% der Features die wir brauchen 
reibungslos.
Die kommerzielle Lib wurde uns von der Firma für 9000€ in unser Projekt 
integirert und deckt >90% aller Features ab. Die restlichen 10% kriegen 
wir dank guter Doku wohl auch in wenigen Tagen fertig. Damit ist das 
OS-Projekt natürlich für uns gestorben.

4. Bedienbarkeit
Word hat sicherlich schwächen, was komplexes Layouting angeht, aber für 
einfache Notizen und Anleitungen reicht es allemal.
Latex ist uintuitiv und verschlingt unnätig Zeit, wenn man sich damit 
nicht gut auskennt.
Wenn ich tatsächlich "print"-geeignete Dokumente brauche, schuster ich 
mir die Pi*Daumen in Word zusammen und schicke das an den 
Dokumenten-dienst. Der macht dann mit InDesign ein vorzeigbares Dokument 
draus.
Die haben übrigens früher auch Latex verwendet und sind vor 3 Jahren auf 
InDesgin umgeschwenkt. Ich weiß zu wenig über Layouting um den Schwenk 
zu bewerten, aber wenn man von kostenlos auf ein 300€/Jahr Tool 
umsteigt, werden die schon ihre Gründe gehabt haben...
Diese Krux zieht sich durch viele OS-Projekte.
Egal wie man es dreht und wendet, sobald ich in Konsolen oder Skripten 
furwerken muss um das Programm zu nutzen, hab ich min. 80% der 
Standardnutzer abgehängt. In einer Firma in der alle möglichen 
IT-Kenntnislevel unterwegs sind geht das nicht. Sieht man ja wie oft 
z.B. die Linux-projekte in Gemeinden scheitern.

Naja, eine Grafikkarte sind auch nur ein paar Chips. Das Teure ist die 
Entwicklung und die Treiber. Sollen die auch wenn die Entwicklung 
bezahlt ist, die Weiteren zum Selsbtkostenpreis raushauen ?

Nee. Nicht jede Entwicklung ist erfolgreich.

Fan schrieb:
> Ja, die Entwicklung der Software ist schwierig, teuer und so weiter,
> aber wenn es mal fertig ist kostet es nicht mehr in Produktion.

Eure Software supported sich bestimmt selbst und behebt Bugs 
automatisch. Da braucht man ja kein Personal dafür.

> ist es nicht so wie bei Hardware,

Stimmt. Es ist schlimmer. Mitunter wird beispielsweise erwartet, dass es 
nach dem Erscheinen einer Version 10 Jahre lang kostenlos Fixes gibt.

> weil wenn du z.B 100 Grafikkarten
> produzierst musst du jede einzeln bauen.

Und die Software dazu. Das ist längst ein hochkomplexer Teil davon.

> Deswegen sind die Softwarelizensen illegal meiner Meinung nach.

Was verstehst du unter einer Softwarelizenz? Der erste Idiot zahlt die 
ganze Entwicklung, die anderen kopieren es umsonst?

Wühlhase schrieb:
> Macht bei 10 Softwerkern, zwei Büromäusen (Vertrieb und Support ist da
> noch nichtmal mit drin) über zwei Jahre mal eben knapp 2,4 Mio
> Tacken-reine Vorleistung, damit wurde noch kein Geld verdient.

Rechne bei 10 Softwerkern mit mindestens 20 weiteren Personen für 
Support, Vertrieb, Verwaltung und Chef(s).

Fan schrieb:
> Es gibt praktisch keine Software mehr die fehlerfrei ist.

Die hat es jenseits trivialer Programme auch noch nie gegeben.

Fan schrieb:
> Mit Softwarelizenzen meine ich was anderes. Die Software kann natürlich
> was kosten, 100Euro z.B aber nicht 1000Euro wei es zu viel ist.Und
> ausserdem verlangt die Lizenz, dass nur eine Person die Software
> benutzen darf oder noch irgendwelche Einschränkungen, das ist nicht O.K

Ein Multi mit 100.000 Mitarbeitern soll also für die Office-Software 
genauso einmalig 100€ zahlen wie ein einsamer Freiberufler? Weil der 
Multi, wenn er ein Exemplar für 100€ gekauft hat, dieses Exemplar an 
beliebig vielen Arbeitsplätzen einsetzen kann?

243890 schrieb:
> Während ein Ingenierbüro mit MatLab, VisualBasic, MsAccess und Word
> auskommt, müssen Unis meist aufwendigere Probleme lösen und setzen daher
> auf Python, Qt, PostgreSQL und Latex.

Prust.
Du wolltest schreiben: Während ein Ingenierbüro reale Probleme 
bearbeiten muss die es zeitsparend mit MatLab, VisualBasic, MsAccess und 
Word dokumentiert, kann sich eine Uni den Luxus gönnen, mit Python, Qt, 
PostgreSQL und Latex die Zeit zu vertrödeln.

Jemand schrieb:
> Nutzt hier eigentlich jemand LyX?

Nur mal versucht. Da lauern schon knapp unter der Oberfläche 
katastrophale Fehler.

243890 schrieb:
> Liegt eventuell auch an anderen Schwerpunkten. Formeln setzen, Graphen
> zeichnen (sowohl im Sinne der Graphentheorie als auch als Abbildung
> einer Funktion), source code einbetten, etc. funktioniert in Word
> einfach nicht so gut wie in Latex

In Latex zeichnen ? Wäre mir neu, daß es dafür einen Editor gibt. Statt 
(dem 30 Jahre alten) WYSIWYG ist LaTex doch auf dem Stand von WordStar 
und Electric Pencil (1975): Sonderzeichen werden später zu 
Formatierungen.
Ich weiss, dieses Forum ist da nicht besser.

Michael B. schrieb:
>> Nutzt hier eigentlich jemand LyX?
>
> Nur mal versucht. Da lauern schon knapp unter der Oberfläche
> katastrophale Fehler.

Ich hatte vor fast 2 Jahrzehnten mal eine Doku damit produziert. Ging 
eigentlich ganz gut.

>Fan schrieb:
> Mit Softwarelizenzen meine ich was anderes. Die Software kann natürlich
> was kosten, 100Euro z.B aber nicht 1000Euro wei es zu viel ist.Und
> ausserdem verlangt die Lizenz, dass nur eine Person die Software
> benutzen darf oder noch irgendwelche Einschränkungen, das ist nicht O.K

Ich verwende eine Software, deren Miete liegt bei 18kEuro, pro Jahr. 
Kauf waere um die 50kEuro. Dann gaeb's noch teurere Software wie zB 
Catia, ein Zeichenprogramm, das liegt bei 50kEuro Miete, pro Jahr und 
Arbeitsplatz.

Weil eben an diesen Programmen jeweils eine groessere 
Entwicklungsabteilung, Support, Verkauf, Schulung dranhaengen.

Fan schrieb:
> Für was soll ich oder jemand anders 18kEuro pro Jahr
> bezahlen? Nur dafür, dass ich ein Program benitzen darf. Für diesen
> Preis brauch ich das nicht.

Dann lass es. Andere brauchen das.

Der Preis eines Produkts hat auch was mit der Verteilung von 
Entwicklungskosten auf die Anzahl Verkäufe zu tun. Software, die 
beispielsweise nur im Zeitungsdruck eingesetzt wird, die verkauft sich 
nicht Millionenfach. Also ist sie pro Kunde entsprechend teurer. Das ist 
bei der Hardware dazu, der Druckmaschine, auch nicht anders. Auch da 
bestimmt sich der Preis nicht nur aus dem verbauten Blech, sondern auch 
aus dem umgelegten Entwicklungskosten und der Verzinsung der 
Vorfinanzierung davon.

Fan schrieb:
> Für was soll ich oder jemand anders 18kEuro pro Jahr
> bezahlen? Nur dafür, dass ich ein Program benitzen darf. Für diesen
> Preis brauch ich das nicht.

Du besitzt es nicht mal, du darfst es benutzen. Darfst. Nun, uns bringt 
es etwas. Wir koennten es auch selbst entwickeln, und uns im naechsten 
Jahrhundert wuieder drueber unterhalten. Die Software macht eben etwas 
was sonst keine macht. Und sie ist auch etwas komplexer wie ein paar 
Icons zusamenclicken

Das ganze wirtschaftsystem ist dazu da, die kleinen Leute auszubeuten. 
Man erzaehlt ihnen was sie allen brauchen, sie sollen Schluden machen. 
Dass sie im Hamsterrad umlaufen. Je schneller je besser. Es ist an jedem 
Einzelnen, das system zu hinterfragen - brauch ich das alles?
Frueher war's die Kirche, die den Leuten konstant vorgeworfen hat, sie 
seien unperfekt, und sollten deshalb abduecken, resp sich freikaufen. 
Heute ist es das goldene Kalb, die konsumgesellschaft, wo man rund 
rumlaeuft...

Aus dem Hamsterrad kommst du ganz leicht raus: nichts kaufen.

Du brauchst quasi per Definition nicht mehr, als schon deinem Vorfahr 
vor 100.000 Jahren zur Verfügung stand. Da allerdings wie überall 
berichtet, die Menschheit seit damals von einer Generation zur nächsten 
immer dümmer geworden ist, verwundert es nicht, wenn heute eines fehlt: 
das Wissen, wie man so überlebt.

Hallo Fan.

Fan schrieb:

> Ich weiss, dass es solche teure Software gibt. Genau deswegen finde ich
> es illegal. Für was soll ich oder jemand anders 18kEuro pro Jahr
> bezahlen? Nur dafür, dass ich ein Program benitzen darf. Für diesen
> Preis brauch ich das nicht.

Vermutlich brauchst Du auch so teure Software nicht. Kleine Leute können 
sich komplett mit open source Software versorgen. Ich mache das z.B. so, 
und es funktioniert. Für alles, was ich meine, zu benötigen, gib es eine 
open Source Lösung, und in den meisten Fällen finde ich die sogar besser 
zu bedienen als die kommerziellen Produkte.*)

Wo mir bisher eine Kleinigkeit gefehlt hatte, konnte ich mir das selber 
schreiben. Eigene Programme schreiben ist unter Linux für kleine Leute 
wie mich auch viel einfacher als unter Windows.

Was für mich gilt, gilt aber auch für Kleinstunternehmen. Werden die 
Unternehmen größer, wird es etwas dünner. Aber auch für mittelständische 
Unternehmen ist es durchaus möglich, und wird auch praktiziert, für 
einige Anwendungsfälle open Source einzusetzten.

Ich habe schon in mehreren mittelständischen Firmen gearbeitet, wo es 
Office Lizenzen nur für  die Verwaltung gab. Der Rest hatte libreOffice.
Apache Server sind ein anderes Beispiel. Oder LaTeX. Es werden mehr 
Kataloge mit LaTeX erstellt, als man glaubt, auch in Großunternehmen. 
KiCad ist ein weiteres Beispiel. BRL-CAD auch.

Es gibt übrigens auch recht große Firmen, die open source erstellen. Als 
ein Beispiel "Code Aster" für Finite Elemente.
https://de.wikipedia.org/wiki/Code_Aster

LaTeX und BRL-CAD sind übrigens Programme, die ihren Ursprung in 
staatlichen amerikanischen Intitutionen haben. Von daher sollten sie 
über den Verdacht der "kommunistischen Unterwanderung" erhaben sein. ;O)

open Source ist wesentlich verbreiteter als man denkt. Aber es ist halt 
eben so, dass es einfach verwendet wird, und nicht an die große Glocke 
gehängt wird. Es laufen keine Vertreter durch die Welt, die jetzt 
unbedingt open source an den Mann bringen wollen. Nach open source muss 
man sich halt selber umsehen. Auch als Statussymbol taugt open Source 
nicht, weil Statussymbole müssen quasi per Definition teuer sein. Und 
Lamborginis fallen halt deutlicher auf als irgendwelche 0815 
Arbeitspferde - und das ist ja auch so gewünscht.
Je größer eine Firma oder ein Konzern wird, umso mehr ähnelt sie einem 
Staat, der anfällig für die Beeinflussung durch Lobbyisten ist. Und open 
Source hat in dem Sinne nur eine relativ schwache Lobby aus dem 
akademischen Umfeld und von einigen Kennern und Geniessern. ;O)


Grundsätzlich finde ich die Idee, Software, die man benötigt, zu kaufen, 
nicht verwerflich. Das Problem ist auch eher weniger die proprietäre 
Software, als die strategischen Probleme, die man sich damit 
einhandelt, weil man ab jetzt für das begonnene Projekt von dieser 
Software und ihrem Hersteller abhängig ist. Diese Abhängigkeit geht 
weit über die Software und ihren Preis hinaus, und dass ist das 
eigentliche Problem.

Darum sind offene Dateiformate und speziell Austauschformate 
eigentlich wesentlich wichtiger als die offene Software, weil erst das 
einen wirklichen Wettbewerb unter den Softwareherstellern ermöglichen 
würde. Wenn einem der eine nicht mehr gefallen würde, könnte man zu 
einem anderen Wechseln, ohne Probleme mit seinen Projekten zu 
haben......
Wenn ich mir also einen gesetzlichen Hebel wünsche, müsste er zuerst 
einmal hier ansetzten.

*) Weil kommerzielle Software so geschrieben ist, dass der Entscheider, 
der die Software kauft, meint, sie ist gut zu benutzten. Der Entscheider 
ist aber selten der Benutzter, der damit dann tatsächlich umgehen muss.
Desweiteren wird open source oft geschrieben, weil sich ein Anwender 
über proprietäre Software und deren Unzulänglichkeiten geärgert hat. Von 
daher ist oft größerer Wert auf die Bedienbarkeit gelegt, als bei 
kommerzieller Software, wo es eher auf den Eindruck guter Bedienbarkeit 
ankommt.
Und nicht zuletzt die ganzen open Source Projekte, die rein aus Spass an 
der Freude entstanden sind. Bei solchen Projekten können ungezwungen und 
spielerisch unkonventionelle Lösungen gesucht und gefunden werden, zu 
denen man sich sonst nicht traut, und es kann Energie in details 
gesteckt werden, für die nie ein Vertreter werben könnte, die aber 
trozdem wichtig sind.


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

Ordner schrieb:
> Falsches Beispiel.
>
> Grund für die Verbreitung von HTML ist die Standardisierung durch das
> W3C Consortium. Und dort finden sich kaum OS-Schreiber:
> http://www.w3.org/Consortium/Member/List

Schon auf den ersten Blick erkenne ich eine ganze Reihe von Unternehmen, 
die entweder selbst in großem Umfang OpenSource-Software entwickeln, 
große Summen in die Weiterentwicklung von OpenSource-Software gesteckt 
haben und weiterhin stecken, oder die OpenSource-Software 
weiterentwickeln und auf die eigene Plattform bringen. Darunter: Apple, 
IBM, Microsoft, Oracle, um nur einige der kleinen, unbedeutenden 
Unbekannten zu benennen. Meine Güte, wie peinlich, sogar Microsoft, IBM 
und Oracle sind schon weiter als die frustrierten OpenSource-Hasser 
hier.

> Ohne Verbreitung durch die Industrie verreckt jede Standard in seiner
> Akademischen/Hobbyisten Nische. Beispiel: WWW-Vorläufer Gopher

Nein, das Beispiel ist ganz richtig. Wenn HTML (und HTTP) aus der 
Industrie gekommen wären, dann wären sie jetzt proprietäre Produkte und 
überall dort, wo das möglich ist, mit Patenten vernagelt. Man erinnere 
sich an die großen "Browserkriege", als vor allem Microsoft versucht 
hat, HTML zu vereinnahmen und seinen Wettbewerbern die Luft abzudrehen.

Und wie zum Beweis des Gegenteils dessen, was Du behauptest, ist Gopher 
doch ausgerechnet deswegen gestorben, weil der Inhaber der Urheberrechte 
-- die Universität von Minnesota -- für die kommerzielle Nutzung 
Gebühren verlangt hat. Genau so wäre es auch HTML und HTTP gegangen, 
wenn sie von einem Unternehmen entwickelt worden wären.

Aber bei HTML und HTTP haben stattdessen die Offenheit und die 
Einfachheit dafür gesorgt, daß sie zu einem verbreiteten Standard 
wurden, bei dessen Weiterentwicklung die unter Deinem Link aufgelisteten 
Unternehmen trotz ihrer Wettbewerbssituation mitwirken.

Michael B. schrieb:
> 243890 schrieb:
>> Während ein Ingenierbüro mit MatLab, VisualBasic, MsAccess und Word
>> auskommt, müssen Unis meist aufwendigere Probleme lösen und setzen daher
>> auf Python, Qt, PostgreSQL und Latex.
>
> Prust.
> Du wolltest schreiben: Während ein Ingenierbüro reale Probleme
> bearbeiten muss die es zeitsparend mit MatLab, VisualBasic, MsAccess und
> Word dokumentiert, kann sich eine Uni den Luxus gönnen, mit Python, Qt,
> PostgreSQL und Latex die Zeit zu vertrödeln.

Als ich bei meinem derzeitigen Arbeitgeber angefangen habe, wurde ich 
von vielen meiner Kollegen und Vorgesetzten belächelt, weil ich so 
altmodisches Zeug benutze. Hin und wieder wurden Ratschläge und auch 
Anweisungen an mich herangetragen, dieses oder jenes doch in Word, 
Access oder Excel zu machen, das ginge doch viel schneller.

Diese Zeit ist jetzt fünf Jahre her. Mittlerweile hat mir der eine oder 
andere Kollege bei der Arbeit über die Schulter geschaut, von denen 
lacht heute keiner mehr darüber. Ebenso höre ich schon lange keine 
Anweisungen und Ratschläge mehr, die handelsüblichen GUI-Werkzeuge zu 
benutzen.

Stattdessen haben einige meiner Kollegen die Macht und das enorme 
Potential einiger meiner Werkzeuge für sich entdeckt. Seit gut zwei 
Jahren haben wir sogar "offizielle" LaTeX-Vorlagen für Präsentationen 
und Berichte, und in naher Zukunft sollen weitere folgen. Bisher 
funktioniert diese Koexistenz sogar besser, als ich anfangs zu hoffen 
gewagt hatte.

Ja, die Lernkurve der betreffenden Werkzeuge ist etwas steiler, aber 
wenn man sie einmal beherrscht und ihr exorbitantes Potential zu nutzen 
weiß, ist man damit häufig viel schneller als mit dem üblichen Zeug -- 
vor allem bei Aufgaben, die vom Hersteller nicht vorgesehen sind oder 
die mehrmals, mithin automatisiert genutzt werden sollen.

Zeno schrieb:
> Ich benutze auch OS z.B. Libreoffice und finde dieses auch besser als
> das kommerzielle Gegenstück, aber es gibt auch Software wo ich lieber
> auf ein kommerzielles Produkt zurückgreife. Hängt auch davon ab wie ich
> die Software einsetze. Für private Zwecke ist vieles egal aber sobald
> ich Software im kommerziellen Bereich einsetze ist z.B. auch
> Softwarepflege und Support wichtig. Gerade bei letzterem sieht es im OS
> manchmal doch recht düster aus und bei Produktivsystemen ist das leider
> ein KO Kriterium.

Ach, Zeno, das ist doch eine Sammlung von Allgemeinplätzchen. Natürlich 
soll jeder die Software benutzen, mit der er seine Aufgabe am Besten 
lösen kann, und ob das kommerzielle Software ist oder OSS, ist doch 
Kinderkram.

In beiden Bereichen gibt es gute und schlechte Software, in beiden gibt 
es gut und schlecht gepflegte Software, in beiden gibt es Software mit 
gutem und solche mit schlechtem Support. Qualität, Pflege, und Support 
kannst Du nicht am Gegensatz kommerziell versus OpenSource festmachen, 
sondern diese Kriterien müssen individuell für jede Software einzeln 
bewertet werden, gleichgültig, nach welchem Modell sie entwickelt und 
vertrieben wird.

Einigen unserer Kunden dürfen wir mit OpenSource-Software gar nicht 
kommen, die wollen einen Hersteller, den sie zur Not verklagen können. 
Es hat zwar meines Wissens noch nie einen Fall gegeben, wo ein 
Softwaregigant wie IBM, Microsoft oder Oracle erfolgreich verklagt 
worden wäre, aber für einige unserer Kunden -- meist die, in denen nicht 
die Fachabteilungen oder die Softwerker, sondern die Betriebswirte 
entscheiden, was genutzt wird -- spielen derartige Erwägungen eine 
wichtige Rolle.

Andere Kunden hingegen haben nicht weniger strikte Policies in Bezug auf 
kommerzielle Software. Bei einem der größten europäischen Versicherer 
ist es Policy, daß auf allen Servern soweit wie möglich 
OpenSource-Software sowie offene Datenformate und Protokolle genutzt 
werden sollen. Wer dort proprietäre Formate, Protokolle oder Software 
verwenden will, muß einen elenden Marathon an Anträgen ausfüllen und 
ausführlich begründen, warum diese und nur genau diese Software benutzt 
werden muß und warum eventuell vorhandene OSS-Alternativen nicht dafür 
geeignet sind.

Hallo Zeno.

Zeno schrieb:

>> Vermutlich brauchst Du auch so teure Software nicht. Kleine Leute können
>> sich komplett mit open source Software versorgen.

> Hallo Bernd, Du hast ja prinzipiell recht, aber die Krux ist das auch
> die Leute die Opensource entwickeln von irgendetwas leben müssen.

Nun, kleine Leute brauchen auch nur kleine Programme. Da geht das oft 
als Hobby. ;O)

> Entweder sie haben ein Job (z.B. kommerzielle Softwareentwicklung) wo
> sie Kohle verdienen und machen OS-Entwicklung quasi im unbezahlten
> Nebenjob

Das fällt unter Spiel und Spass und bringt oft die besten Ergebnisse.
"Sport" ist damit nur sehr indirekt verbunden, weil es bei intrinsicher 
Motivation eher weniger auf den Wettkampf ankommt. Es gibt darum sehr 
viele Leute, für die ist "intrinsische Motivation" ein abstrakter 
Begriff, unter dem sie sich überhaupt nichts vorstellen können. Und das 
jemand Software für umsonst schreibt, ist ihnen unheimlich. ;O)

Unter den Leuten, die Software aus Spiel und Spass schreiben sind auch 
sehr viele Leute, die Informatik Fachwissen haben, und oft sogar 
Informatik studiert haben, weil es sie interessierte, die aber dann 
keine passende Stelle gefunden haben.
Du magst einwenden, dass diese möglicherweise nicht die besten und 
leistungsfähigsten sind....nunja, Leistung ist Arbeit pro Zeiteinheit, 
und es besteht selten Zeitdruck bei open source.
Und viele Leute können auch nicht unter dem Druck eines kommerziellen 
Umfeldes kreativ Arbeiten.

Eine Art von "Wettkampf" dagegen ist oft bei Leuten zu sehen, die sich 
über kommerzielle Software geärgert haben, und nun vorführen wollen, wie 
es ihrer Meinung nach besser geht.

Aus all solchen Leuten speisst sich die Entwicklergemeinde von open 
source Projekten.

> oder sie haben einen potenten Gönner der das finanziert. Und ja
> viel Software kommt auch aus dem universitären Bereich, wo sie oftmals
> nebenbei mit "abfällt".

Alle Modelle sind möglich und es gibt Beispiele dafür.

> Für private Zwecke ist vieles egal aber sobald
> ich Software im kommerziellen Bereich einsetze ist z.B. auch
> Softwarepflege und Support wichtig. Gerade bei letzterem sieht es im OS
> manchmal doch recht düster aus und bei Produktivsystemen ist das leider
> ein KO Kriterium.

Und bei größeren open Source Projekten ist es im allgemeinen kein 
Problem, eine Art von Support zu erhalten. ;O)
Und bei kleinen erstaunlicherweise auch eher selten.
Es hängt aber eben auch sehr am Stil der Anfrage, und aufzutreten wie 
Graf Koks, wie es im kommerziellen Umfeld oft Stil ist, führ dann 
tatsächlich dazu, dass Du auf der Spam Liste landest. Schliesslich bist 
Du "kein Kunde". Open Source beruht auf Kooperation unter Peers. Auch da 
mag es rauhe Töne geben, aber bei weitem nicht so rauh wie im 
kommerziellen Bereich. ;O)

Bei vielen open source Projekten kommunizierst Du mit den Programmierern 
direkt. Wenn Du das geschickt anstellst, ist das um Klassen effizienter 
als die ganze Kette Kunde > Service/Vertrieb > Entwicklung und wieder 
zurück. Und vor allem ohne den "stille Post" Effekt. ;O)

Auch die Behauptung, das open Source schlecht dokumentiert ist, 
relativiert sich, weil ich für die Dokumentation proprietärer Software 
noch mehr zahlen muss als für die Software selber.
Und der teure "Support" besteht oft in einem Call Center, wo ich anrufen 
kann, und dort sitzt dann jemand, der sich nicht Vorstellen kann, was 
das Programm eigentlich macht, der aber Vormittags einen Aktenordner mit 
dem Manual bekommen hat, sich zwei Stunden eingelesen hat, und mir als 
Support daraus vorliest. ;O)

Ist schon ok, wenn große Firmen eine Sicherheit verlangen und auch 
bezahlen können.
Der Kleinanwender hätte aber im Zweifel nicht das Kapital, eine 
Sicherheit, die ihm vertraglich bei kommerzieller Software zustände, 
auch gerichtlich durchzusetzten. Selbst wenn er den Bedarf hat, könnte 
er ihn sich meist nicht realistisch leisten.

D.h. für den Kleinanwender bietet open Source mit einem breiten Team von 
Programmierern und Usern eher die Chance, auf Anfrage das zu bekommen, 
was er benötigt. Und davon abgesehen ist es schwerer, ihm ein Programm 
unterzujubeln, das auf seinem Rechner ein Eigenleben entwickelt und 
macht was es will, weil das offenlegen der Software und die Möglichkeit, 
das sich interessierte den Code ansehen können, solche Tricks 
erschweren.

Wenn solche Programme dann lange genug gereift sind, sind sie oft auch 
in der Lage, gehobeneren Ansprüchen gerecht zu werden. ;O)

Ich behaupte ja auch nicht, das open Source das Paradies ist. Ich zeige 
nur auf, das proprietäre Software auch Grenzen hat, die für open Source 
eben so nicht gelten, und dass es weite Einsatzfelder dafür gibt. Und es 
ist ja auch ok, wenn beides nebeneinander existiert.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

Zeno schrieb:
> Bernd W. schrieb:
>> das sich interessierte den Code ansehen können
>
> Das mag für Dich und einige andere hier Forum zu treffen, aber der reine
> Anwender schaut da wie die Sau ins Uhrwerk. Der möchte eine
> funktionierende, intuitiv zu bedienende Software haben.

Die gibt es im OpenSource-Umfeld für die üblichen Aufgaben von 
unbedarften Endanwendern seit mindestens fünfzehn Jahren. Seitdem 
braucht niemand mehr für die üblichen Aufgaben wie Office, Internet etc. 
eine Kommandozeile -- auch wenn Nerds wie ich, die sie beherrschen, ihre 
Leistungsfähigkeit und ihre Flexibilität jeder "intuitiv" zu bedienenden 
GUI-Software vorziehen, wo immer das möglich und sinnvoll ist.

> Programme die per Kommandozeile mit Parametern gesteuert werden, die wie
> es lange Zeit im Unix/Linux-Bereich üblich war, schrecken den Normaluser
> ab, obwohl diese Programme oftmals sehr leistungsfähig waren und sind.
> Beim Scripting möchte ich auf derartige Programme auch nicht verzichten.

Entschuldige bitte, aber das ist ein vollkommen anderer Scope. Das hat 
sogar Microsoft schon vor langer Zeit erkannt und zur Automatisierung 
der eigenen Softwareprodukte deswegen die Powershell entwickelt -- 
obwohl sie vorher die Ansicht vertreten haben, daß Kommandozeilen 
unmodern seien und kein Mensch auf der Welt so etwas braucht. So ändern 
sich die Zeiten. ;-)

> Zwischenzeitlich ist das aber kein Problem mehr und auch bei Linux haben
> qualitativ hochwertige Programme mit grafischer Oberfläche Einzug
> gehalten, was auch Gut ist.

Naja, das kommt auf das Umfeld an. Auch für Linux gibt es 
leistungsfähige kommerzielle Software (neuerdings sogar Microsoft Visual 
Studio und den Microsoft SQL Server), und in vielen Bereichen wie etwa 
Office-, Web- und Mailsoftware, Serveranwendungen aller Art gibt es 
OpenSource-Software, die ihren kommerziellen Wettbewerbern mindestens 
ebenbürtig ist und sie zum Teil sogar überflügelt. In Bereichen wie 
Cloud- und Distributed Computing gibt es sogar überhaupt keine 
kommerziellen Lösungen, die denen aus dem OpenSource-Bereich auch nur 
annähernd das Wasser reichen könnten.

> Nur so ist es möglich Linuxakzeptanz für den normalen PC User zu
> schaffen.

Ist das denn das Ziel? Eher nicht. Natürlich freuen sich auch 
OpenSource-Autoren, wenn ihre Software benutzt wird. Aber 
Softwarehersteller sind zwingend auf den Verkaufserlös und also auf die 
Akzeptanz ihrer Software angewiesen, und das sind OpenSource-Autoren 
prinzipbedingt -- egal, ob sie von einem Hersteller oder einem Sponsor 
bezahlt werden oder das nur "just for fun" machen -- eben nicht. Im 
Laufe der Jahre habe ich mittlerweile sicherlich zu zwanzig oder dreißig 
OSS-Projekten beigetragen, und dabei waren meine Motive immer dieselben: 
entweder, ich wollte eine Funktion in einer von mir genutzten Software 
haben, die diese noch nicht hatte, oder ich wollte einen Fehler in einer 
von mir genutzten Software beheben, der mich gestört hat -- und in 
einigen wenigen Fällen wurde ich von Freunden, die ihre Software 
entwickelt haben, um Unterstützung gebeten.

Ob Lieschen Müller, Oma Erna oder sonst jemand diese Software benutzt 
oder nicht, das war mir -- und allen anderen OSS-Autoren, die ich kenne 
und mit denen ich darüber geredet habe -- dabei immer völlig 
gleichgültig. Viele meiner Freunde und Bekannten aus dem OSS-Umfeld 
wollen allerdings so gar keine höhere Akzeptanz von "normalen PC Usern", 
weil sie befürchten, daß die einerseits unsere Kommunikationskanäle mit 
belanglosen, inkompetenten Beschwerden und Fragen überfluten würden, und 
andererseits den besonders guten Ruf von OpenSource-Software in Bezug 
auf Sicherheit, Stabilität und Flexibilität unterminieren könnten.

> Ich bestreite ja gar nicht das es OS Programme gibt die auch gehobenen
> Ansprüchen gerecht werden - es gibt sogar sehr viele. Das Hauptproblem
> hast Du ja selbst benannt, den manchmal langen Reifeprozeß. Dies führt
> eben auch dazu das dann auf kommerzielle Produkte zurück gegriffen wird,
> zumindest im Produktivbereich.

Nunja, das ist ein zweischneidiges Schwert. Kommerzielle Software wird 
dann released, wenn Vertrieb, Marketing und die Roadmap das wollen -- 
und zwar ganz unabhängig von der Frage, ob die Software dann auch in 
einem Zustand ist, der sich bei einigem Wohlwollen als "fertig" im Sinne 
von "stabil", "sicher" und "benutzbar" beschreiben ließe. Häufig geht es 
strategisch nur darum, einen Markt zu besetzen, bevor ein Wettbewerber 
es tut.

Solche Zwänge kennt OpenSource-Software normalerweise nicht. Da wird die 
Software in der Regel erst dann veröffentlicht, wenn sie fertig ist. Das 
ist aus meiner Sicht einer der wichtigsten Gründe dafür, daß 
OSS-Software sich ihren Ruf als besonders stabil und sicher erarbeitet 
hat.

Insofern ist und bleibt es, wie es schon immer war: wer eine Software 
für eine bestimmte Aufgabe sucht, kommt nicht darum herum, einige 
mögliche Lösungen zu evaluieren und sich dann für die zu entscheiden, 
die ihm am Besten geeignet erscheint. Dabei gelten für Unternehmen mit 
zunehmender Größe jedoch andere Kriterien als für Einzelunternehmer oder 
Privatuser, und je größer das Unternehmen wird, desto wichtiger werden 
Fragen wie Kompatibilität, Interoperabilität, Betriebs- und 
Verwaltungsaufwand, Hochverfügbar- und Skalierbarkeit.

Am Ende glaube ich immer noch daran, daß beide Bereiche -- kommerzielle 
und OSS-Software -- gleichermaßen wichtig sind und beide der 
IT-Industrie und der Weiterentwicklung von Hard- und Software jeweils 
ihre eigenen Impulse mitgeben. Wettbewerb beflügelt Innovation und 
Entwicklung, egal welches Modell dahinter steht. Aber in der 
Softwareentwicklung gibt es dabei ein besonderes Umfeld: weil Software 
immateriell ist und es zur Teilhabe an ihrer Entwicklung nur eines 
Computers und einer gewissen Neugier bedarf.

Fantom schrieb:
> Sheeva P. schrieb:
>> Das
>> ist aus meiner Sicht einer der wichtigsten Gründe dafür, daß
>> OSS-Software sich ihren Ruf als besonders stabil und sicher erarbeitet
>> hat.
>
> Das würde ich nicht so sagen, es gibt auch schlechte OSS-Software.

Ja, das stimmt. Es gibt schlechte OSS-Software, ebenso, wie es auch 
schlechte kommerzielle Software gibt. Nur das Argument "wir haben das 
jetzt bezahlt, also müssen wir es auch benutzen" kenne ich aus dem 
OSS-Bereich nicht. ;-)

Sheeva P. schrieb:

> Ja, das stimmt. Es gibt schlechte OSS-Software, ebenso, wie es auch
> schlechte kommerzielle Software gibt. Nur das Argument "wir haben das
> jetzt bezahlt, also müssen wir es auch benutzen" kenne ich aus dem
> OSS-Bereich nicht. ;-)

Man kauft bei kommerzieller Software den Support mit ein. Bei OSS ist 
das mitunter schwierig.

Michael X. schrieb:

> Man kauft bei kommerzieller Software den Support mit ein. Bei OSS ist
> das mitunter schwierig.

Das ist ein Argument, dass ich früher auch immer gehört habe. Aber hast 
Du mal versucht, den Support von z.B. Microsoft in Anspruch zu nehmen? 
Ich muss z.Z. Word verwenden (auf Mac) und ich muss sagen, dass ich 
absolut erschrocken bin, was das für eine fürchterliche Qualität diese 
Software hat. Der Support hat mir gesagt, dass er sich damit auch nicht 
auskennt und gefragt, ob ich den schon mal den Feedback-Knopf oben 
rechts ausprobiert hätte.

In der SW-Entwicklung setze ich Libraries, zu denen ich keine Quellen 
habe, extrem ungerne ein (unabhängig davon, unter welcher Lizens die nun 
stehen). Selbst wenn ein Fehler, der sich in der Library manifestiert, 
als eigener Fehler heraus stellt, findet man den Fehler mit Quellen 
deutlich schneller.

Letzten habe ich 2 Wochen gebraucht, um einen Fehler im Bluetooth Stack 
von TI zu finden. (Der Linker richtet ab und zu eine Korrekturtabelle 
nicht an Wortgrenzen aus.) Der Fehler manifestierte sich in einem 
Hardfault im eingebauten ROM-CODE eines CC2650. Mit den Quellen, hätte 
ich den Fehler sicher deutlich schneller gefunden. TI rückt die Quellen 
aber nicht raus. Sicher nicht, weil da super-tolle Raketentechnik 
verwendet wird, sondern wahrscheinlich eher, weil sie eigene Fehler 
darin verbergen wollen und sich für die Code-Qualität schämen.

Schon mal versucht, Oracle dazu zu bringen einen Bug zu fixen? Der 
Support nutzt Dir da wenig. Den gemeldeten Fehler must Du erst mal 
finden und erkenenn, dass die Libraries von Oracle schuld sind und dann 
auch noch einen Workaround dafür finden.

Ich denke ein weiterer Punkt ist die Verantwortlichkeit bzw. die 
(moralische) Haftung.

Wenn die Klicki-Bunti-Präsentationen der Chefs und Personaler nicht 
funktionieren, dann ist entweder das “schieß Windows/Powerpoint“ dran 
schuld, oder aber der “schieß Admin“ weil er Open Office eingesetzt hat.
Der User macht aus Prinzip nichts verkehrt. ;)

Deswegen denke ich, es wird oft auf “bewährte Software“ gesetzt wird, 
einfach um weniger Angriffsfläche zu bieten.

Das scheint sowieso immer mehr Zeit und Aufwand zu fressen. Die Leute 
müssen immer mehr zusehen den eigenen Kopf aus der Schlinge zu ziehen, 
statt sich auf die Technik zu konzentrieren.

Leroy M. schrieb:
> Deswegen denke ich, es wird oft auf “bewährte Software“ gesetzt wird,
> einfach um weniger Angriffsfläche zu bieten.

Yep.

> Das scheint sowieso immer mehr Zeit und Aufwand zu fressen. Die Leute
> müssen immer mehr zusehen den eigenen Kopf aus der Schlinge zu ziehen,
> statt sich auf die Technik zu konzentrieren.

Das ist allerdings keine wirklich neue Strategie. In früheren Zeiten 
hiess das "nobody ever got fired for buying IBM".

Tom schrieb:
> Keine Ahnung woran es liegt jedenfalls gibt es ständig
> Probleme bei den PTC-Servern und die ClientSW ist einfach nur grottig.
> Da ist mir SVN oder git 1000mal lieber.

Muss hier eine Lanze für PTC brechen. Wir nutzen es auch, und es ist das 
beste VCS das ich jemals nutzen durfte. Ich wills nicht mehr missen 
(insbesondere was das Konfigurieren von Sub-Projekten angeht). Wenn man 
weiß was es für Möglichkeiten bietet, ist es einfach nur noch grandios. 
:)

Torsten R. schrieb:
> Michael X. schrieb:
>
>> Man kauft bei kommerzieller Software den Support mit ein. Bei OSS ist
>> das mitunter schwierig.
>
> Das ist ein Argument, dass ich früher auch immer gehört habe. Aber hast
> Du mal versucht, den Support von z.B. Microsoft in Anspruch zu nehmen?

Mickeysoft? Nö, noch nicht. Aber Cadence (bzw Flowcad), Mentor (direkt) 
und Bartels (auch direkt). War jedesmal zufriedenstellend.

MS Word wird nicht gekauft weil es gut ist sondern weil es so ziemlich 
jeder auf dem Arbeitsrechner hat und es schlicht vorausgesetzt wird. 
Wenn du dem entgehen kannst, prima. Nur wenn der komplette Workflow 
darauf basiert kommst du nicht drum herum.

Wühlhase schrieb:
> Die Anschaffungskosten einer Software spielen selten eine echte Rolle.

Wie immer: es kommt darauf an :-)

> Das dKosten/dt erscheint punktuell exorbitant bei käuflicher Software,
> verschwindet aber, wenn man die Kosten über das Jahr integriert und
> neben die Zeit stellt, die einem ein gutes Programm erspart und die
> Fehler, vor denen es einen bewahrt (oder auch nicht).

Wobei es bei OOS auch "gute Programme" gibt, genau so wie grottige.

Ich sehe aber bspw. keinen signifikaten Unterschied zwischen MS-Office 
und LibreOffice (ok, die Vorlagenverwaltung ist bei LibreOffice deutlich 
besser gelöst). Warum dann also Geld ausgeben?

> Daher meine ich, daß, wer bei Open Source Software (bzw. bei Werkzeug
> allgemein) mit den Anschaffungskosten argumentiert, hat zu kurz gedacht.

Es ist auch nur ein Faktor von mehreren, aber er ist einer.

Bei uns bspw. werden pro Jahr vielleicht zehn Platinen entworfen. Man 
benötigt aber für den Entwurf eine Software für PCBs.
Würde ich diese mieten/kaufen, würden sich die Kosten durchaus deutlich 
niederschlagen (wir arbeiten hier mit KiCad).

Gleiches gilt hier für FreeCAD. Wir machen im Jahr einige Konstruktionen 
damit. Aber für ein kommerzielles CAD-System einfach nicht genug, dass 
sich der Erwerb lohnen würde.

Wenn jemand aber tagtäglich mit einer Software arbeiten muss, dann geht 
der Preis in der Tat im Rauschen unter.

Ob es sich lohnt ist immer auch eine Frage der damit "produzierten 
Menge".

Kein Freigeist schrieb:
> Was allerdings daran Stümperei sein soll, in einer Dokumentation eine
> beschreibende Skizze, die nur aus ein paar Rechtecken, Verbindungslinien
> und Texten daran besteht mit einem OSS-Vektorgrafikprogramm anzulegen
> anstatt mit einem teuren kommerziellen, dessen proprietäres Dateiformat
> in ein paar Jahren vielleicht gar nicht mehr zu öffnen ist, erschließt
> sich mir beim besten Willen nicht. Das Endprodukt, das der Kunde in die
> Hand bekommt, sind ein paar saubere Rechtecke, Linien und Text, aus
> denen man nicht erkennen kann, mit was sie erzeugt wurden.

Das ist auch keine Stümperei oder Frickelei.
Wichtig ist nur eines: erfüllt es die Anforderungen oder nicht?

> Die Aussage, man könne mit
> kommerzieller Software grundsätzlich schneller arbeiten als mit OSS, ist
> genauso falsch, wie wenn man das Gegenteil behaupten würde.

Vieles ist einfach auch eine Frage der Einarbeitung.

Ich erledige hier (hie rläuft überall Linux) praktisch allen 
"organisatorischen Krams" im Netzwerk per Kommandozeile, einfach weil 
ich die beherrsche und ich damit extrem schnell bin.

Ich sehe aber, dass das viele überfordern würde - es ist ja auch 
kryptisch. Ich kann das eben, weil ich es schon sehr lange mache. Aber 
ich würde aber nie jemanden davor setzen, der bisher nur unter einer GUI 
Windows administriert hat.

> Und bevor jetzt wieder die Latexfetischisten um die Ecke kommen: Kein
> normaler Mensch, der nicht 110% Nerd ist, fertigt normale
> Alltagskorrespondenz in Latex. Die Zielgruppe, für die diese Vorlagen
> waren, kennt diese Software vermutlich nicht mal.

Bei LaTeX ist es hier bspw. genau anders herum wie mit der 
Kommandozeile: ich schreibe einfach zu wenig Dokumente im Jahr, damit 
sich LaTeX lohnen würde. Ich habe keine Zeit dafür (und auch keine 
Lust), mich nach vielleicht zwei Monaten jedes Mal wieder auffrischen zu 
müssen, wann welcher Befehl welche Wirkung hat. Im Studium war das kein 
Problem, da ich damals jede Woche damit arbeiten musste.

Auch wenn LaTeX ein hervorragendes Ergebnis liefert, so ist mir der 
Aufwand  als Wenignutzer dafür schlicht zu groß.

Daher schreiben wir Dokumentation etc. nur noch unter LibreOffice, 
allerdings mit entsprechenden Vorlagen (mMn das "Geheimnis", um darunter 
gut arbeiten zu können).

Und natürlich klauen wir für diese Computer Modern als Schriftart ;-)

Also, hier in meinem kleinen Unternehmen macht OSS 100% der Software 
aus, ist also gern gesehen :-)

Wenn es aber nichts Passendes gäbe, würde ich selbstverständlich 
Software einkaufen.

Kein Freigeist schrieb:
> Chris D. schrieb:
>> Auch wenn LaTeX ein hervorragendes Ergebnis liefert, so ist mir der
>> Aufwand  als Wenignutzer dafür schlicht zu groß.
>
> Nachvollziehbar. Das hat mich, zusammen mit dem Zeitaufwand, sich da
> erstmalig reinzufuchsen, mein Leben lang davon abgehalten, es zu
> versuchen.

Als passionierter LaTeX-User kann ich Eure Vorbehalte gut verstehen; ein 
so mächtiges Werkzeug braucht ein bisschen Zeit und Übung, bis man 
produktiv mit ihm arbeiten kann. Und bei dieser Investition kommt es 
natürlich immer auch darauf an, was man damit machen möchte -- und wie 
oft.

Aber wenn ich nun andererseits all das, was ich mit LaTeX (und mit 
Python mit Jinja2) mache, mit anderen Programmen machen müßte, müßte ich 
dazu einen ganzen Strauß anderer Programme lernen: einen Wortprozessor, 
eine Tabellenkalkulation, ein Präsentations-, ein Datenbank-, ein 
Statistik-, ein Pixelgrafik-, ein Vektorgrafik-, sowie ein 
Layoutprogramm. Und dann bräuchte ich noch etwas, mit dem ich all diese 
Programme fernsteuern und automatisieren kann.

Ich bin mir nicht sicher, ob die Lernkurve in diesem Fall nicht ähnlich 
steil und langwierig wäre, wobei die meisten Anwender wohl nur einen 
Teil dieser Arbeiten machen. Aber für mich ist LaTeX an dieser Stelle 
prima geeignet, um aus meinen langweiligen Tabellen mit überschaubarem 
Aufwand ansehnliche Dokumente, Berichte, Grafiken und Präsentationen zu 
erzeugen und diese Dinge wenn nötig schnell automatisieren zu können. 
YMMV. ;-)

Sheeva P. schrieb:
> Kein Freigeist schrieb:
>> Chris D. schrieb:
>>> Auch wenn LaTeX ein hervorragendes Ergebnis liefert, so ist mir der
>>> Aufwand  als Wenignutzer dafür schlicht zu groß.
>>
>> Nachvollziehbar. Das hat mich, zusammen mit dem Zeitaufwand, sich da
>> erstmalig reinzufuchsen, mein Leben lang davon abgehalten, es zu
>> versuchen.
>
> Als passionierter LaTeX-User kann ich Eure Vorbehalte gut verstehen; ein
> so mächtiges Werkzeug braucht ein bisschen Zeit und Übung, bis man
> produktiv mit ihm arbeiten kann. Und bei dieser Investition kommt es
> natürlich immer auch darauf an, was man damit machen möchte -- und wie
> oft.

Der Vorteil von Latex ist, dass es sich selbst überlebt hat. Wir reden 
von Nutzungszeiten von Jahrzehnten für ein und die selben Dateien, 
Betriebssystem unabhängig, beispielsweise für Rechnungsstellung und 
Briefe. Die letzte Modifikation war Konto/BLZ -> IBAN/BIC.
Aktuell habe ich nicht viel. Aber wenn ich wieder regelmäßig Briefe 
verschicken würde, so wäre die nächste Anpassung die 
(semi?-)automatische Einbindung der QR-Briefmarke.
Für alles verwende ich es dennoch nicht, zB Slides. Und dann gibt es da 
noch LyX...

Hallo,

> ...ein so mächtiges Werkzeug braucht ein bisschen Zeit und Übung,
> bis man produktiv mit ihm arbeiten kann.

Wenn ich so einige Diskussionsbeiträge von dir (auch in anderen 
Diskussionen) Revue passieren lasse, trifft das auf praktisch alle von 
dir verwendeten Software zu. Das funktioniert aber auch nur weil du 
permanent diese jeweilige Software verwendest und somit bezüglich der 
Bedienung immer "auf Stand" bist.
Aber was ist wenn du bestimmte Programme nur (sehr) selten benutzt? Hast 
du dann auch nach längerer Zeit noch alle wichtigen Bediensequenzen im 
Kopf?

Vor vielen Jahren habe ich mal versucht mit dem Editor vi zu arbeiten 
(für mich mit Abstand das unintuitivste Programm, das ich kenne). Ich 
dachte mir das das eine gute Idee wäre, da es ja vi für praktisch jedes 
Betriebssystem gibt und ich mich damit nur einmal einarbeiten müsste. 
Kurzum: ich bin gescheitert. Da ich einen Editor nur ab und zu benötige, 
konnte ich mir die Bedienlogik und die entsprechenden Editorbefehle 
einfach nicht über einen längeren Zeitraum merken. vi mag ein hoch 
effektives Werkzeug sein, aber wenn man nicht ständig damit arbeitet ist 
es schlicht unbrauchbar.
Heute verwende ich einfach irgend einen grafischen Testeditor, den das 
jeweilige System anbietet. Und das funktioniert gut, da fast alle in den 
Grundfunktionen identisch sind und man somit praktisch immer die gleiche 
Bedienung vorfindet. Trotz langsamerer Bedienung per Maus komme ich so 
schneller zu einem Ergebnis.

rhf

Roland F. schrieb:
>> ...ein so mächtiges Werkzeug braucht ein bisschen Zeit und Übung,
>> bis man produktiv mit ihm arbeiten kann.
>
> Wenn ich so einige Diskussionsbeiträge von dir (auch in anderen
> Diskussionen) Revue passieren lasse, trifft das auf praktisch alle von
> dir verwendeten Software zu. Das funktioniert aber auch nur weil du
> permanent diese jeweilige Software verwendest und somit bezüglich der
> Bedienung immer "auf Stand" bist.

Sag' ich ja. Meine Aufgaben, meine Arbeitsweise, mein Vergnügen. Alles 
meines. Für mich und meine Aufgaben funktioniert das gut und 
mittlerweile schon ziemlich lange.

> Aber was ist wenn du bestimmte Programme nur (sehr) selten benutzt? Hast
> du dann auch nach längerer Zeit noch alle wichtigen Bediensequenzen im
> Kopf?

Nein, aber dafür haben Unix-Systeme ein System von sogenannten Manpages, 
oder genauer: "Manual Pages". Kurz gesagt: da rufe ich die Manpage des 
betreffenden Programms auf und finde dort meist, was ich suche.

> Vor vielen Jahren habe ich mal versucht mit dem Editor vi zu arbeiten
> (für mich mit Abstand das unintuitivste Programm, das ich kenne). Ich
> dachte mir das das eine gute Idee wäre, da es ja vi für praktisch jedes
> Betriebssystem gibt und ich mich damit nur einmal einarbeiten müsste.
> Kurzum: ich bin gescheitert.

Ach, geht so. Obwohl ich den vi-Klon vim brauchbar beherrsche, bevorzuge 
ich den GNU/Emacs. Wenn man sich aber einmal an die Sache mit den Modus 
gewöhnt hat, ist der vi(m) sehr gut. Mein Emacs ist ähnlich sperrig.

> Heute verwende ich einfach irgend einen grafischen Testeditor, den das
> jeweilige System anbietet. Und das funktioniert gut, da fast alle in den
> Grundfunktionen identisch sind und man somit praktisch immer die gleiche
> Bedienung vorfindet. Trotz langsamerer Bedienung per Maus komme ich so
> schneller zu einem Ergebnis.

Du hast offensichtlich ein Werkzeug gefunden, mit dem Du arbeiten 
kannst. Super, das freut mich für Dich. Ist es schlimm, daß ich meine 
Werkzeuge habe und Du Deine?

Sheeva P. schrieb:
> Als passionierter LaTeX-User kann ich Eure Vorbehalte gut verstehen; ein
> so mächtiges Werkzeug braucht ein bisschen Zeit und Übung, bis man
> produktiv mit ihm arbeiten kann. Und bei dieser Investition kommt es
> natürlich immer auch darauf an, was man damit machen möchte -- und wie
> oft.

Ja, das war hier das Kriterium für die Einmottung von LaTeX. Der Aufwand 
der Wiedereinarbeitung war zu hoch. Jetzt mit LibreOffice ist das ok. Da 
bin ich direkt wieder drin.

> Aber wenn ich nun andererseits all das, was ich mit LaTeX (und mit
> Python mit Jinja2) mache, mit anderen Programmen machen müßte, müßte ich
> dazu einen ganzen Strauß anderer Programme lernen: einen Wortprozessor,
> eine Tabellenkalkulation, ein Präsentations-, ein Datenbank-, ein
> Statistik-, ein Pixelgrafik-, ein Vektorgrafik-, sowie ein
> Layoutprogramm. Und dann bräuchte ich noch etwas, mit dem ich all diese
> Programme fernsteuern und automatisieren kann.

So hat jeder seine Anforderungen - und natürlich auch Vorlieben. Ich 
komme bspw. besser mit Programmen zurecht, bei denen ich grafische Dinge 
per Maus erledigen kann (Inkscape, Scribus etc.)

> Ich bin mir nicht sicher, ob die Lernkurve in diesem Fall nicht ähnlich
> steil und langwierig wäre

Ich hab's für mich ausprobiert und bin zu dem Schluss gekommen: die 
immer wieder neue Einarbeitung in LaTeX kostet mich mehr als es mir 
bringt.

Roland F. schrieb:
> Vor vielen Jahren habe ich mal versucht mit dem Editor vi zu arbeiten
> (für mich mit Abstand das unintuitivste Programm, das ich kenne). Ich
> dachte mir das das eine gute Idee wäre, da es ja vi für praktisch jedes
> Betriebssystem gibt und ich mich damit nur einmal einarbeiten müsste.
> Kurzum: ich bin gescheitert. Da ich einen Editor nur ab und zu benötige,
> konnte ich mir die Bedienlogik und die entsprechenden Editorbefehle
> einfach nicht über einen längeren Zeitraum merken. vi mag ein hoch
> effektives Werkzeug sein, aber wenn man nicht ständig damit arbeitet ist
> es schlicht unbrauchbar.

Ja, so ist es.

Ich bspw. liebe den vi (bzw. vim) bspw. für schnelle Änderungen an 
Konfig-Dateien :-)

Aber ich arbeite auch fast täglich damit. Das ist der Knackpunkt.

Und man darf auch die eigenen Vorlieben nicht vergessen:
Wer die Kommandozeile schlicht nicht mag, weil er besser mit 
visualisierten Zusammenhängen (bspw. der aufklappbaren Baumstruktur bei 
Dateisystemen, Icons) zurecht kommt, der kann die noch so oft benutzen - 
er wird nicht glücklich werden.

Das Schöne ist doch: es gibt bei OSS praktisch für jeden (Geschmack, 
Nutzungshäufigkeit) etwas.

Chris D. schrieb:
> Und man darf auch die eigenen Vorlieben nicht vergessen:
> Wer die Kommandozeile schlicht nicht mag, weil er besser mit
> visualisierten Zusammenhängen (bspw. der aufklappbaren Baumstruktur bei
> Dateisystemen, Icons) zurecht kommt, der kann die noch so oft benutzen -
> er wird nicht glücklich werden.

Idealerweise funktioniert die Tastatursteuerung im graphischen 
Dateisystem-Explorer aufgrund von mehr Möglichkeiten besser als auf der 
Kommandozeile. Mindestens sollte sie jedoch genauso gut funktionieren. 
Leider ist das nicht überall gegeben.

Lars R. schrieb:
> Idealerweise funktioniert die Tastatursteuerung im graphischen
> Dateisystem-Explorer aufgrund von mehr Möglichkeiten besser als auf der
> Kommandozeile.

Kommt darauf an, und die Grenzen sind fließend. Zählt der 
ncurses-basierte Midnight Commander denn noch als Kommandozeilen- oder 
schon als grafisches Werkzeug? Und: ist Tab-Completion eine Form der 
Tastatursteuerung?

Ich halte es für Unfug, zwei unterschiedliche Arbeitsumgebungen und 
-weisen in winzigen Teilaspekten zu vergleichen und dann zu behaupten, 
das Eine sei aber besser als das Andere -- zumal die Grenzen, siehe das 
Beispiel Midnight Commander, ja zum Teil verschwimmen. Da könnte ich 
auch hingehen und sagen, daß grafische Dateimanager wesentlich weniger 
leistungsfähig sind als ein "find -exec" oder eine Shell-Schleife. Das 
wäre zwar nicht falsch, aber auch irrelevant, irreführend und somit 
nicht weniger unsinnig.

Es bringt in solchen Fällen ohnehin nichts, sich einzelne Teilansichten 
heraus zu picken und dann zu behaupten, sie seien hier oder dort besser 
gelöst  einfacher  schneller / <whatever>. Es kommt auf eine stimmige 
Gesamtumgebung an, nicht auf solche Kleinigkeiten.

Sheeva P. schrieb:
> Lars R. schrieb:
>> Idealerweise funktioniert die Tastatursteuerung im graphischen
>> Dateisystem-Explorer aufgrund von mehr Möglichkeiten besser als auf der
>> Kommandozeile.
>
> Kommt darauf an, [...] Tab-Completion eine Form der
> Tastatursteuerung?

Ja. Graphisch:
. sollten nicht mehr Anschläge erforderlich sein als mit der 
Kommandozeile
. Ein Dropdown-Menü zeigt eine Auswahl, aus der man jederzeit mittels 
Cursor wählen kann.
. Im aktuellen Verzeichnis kannst Du mittels Tippen selektieren und Du 
siehst gleich alles in der näheren Umgebung.


> "find -exec"

Grafisch:
. kann auch find nutzen.
. Shortcuts zur Auswahl von Optionen
. bei speziellen Optionen hört es eventuell auf
. vielfach erübrigt sich exec (zB Suchen und dann mit der Ergebnissmenge 
arbeiten)
. dafür: komfortables Suchen in Suchergebnissen, usw
. Suchergebnisse verschwinden nicht mit dem nächsten Befehl, usw.

> oder eine Shell-Schleife.

Du schreibst Shell-Schleifen auf der Kommandozeile? Kann man graphisch 
im Editor machen.

> Ich halte es für Unfug, zwei unterschiedliche Arbeitsumgebungen und
> -weisen in winzigen Teilaspekten zu vergleichen und dann zu behaupten,
> das Eine sei aber besser als das Andere -- zumal die Grenzen, siehe das
> Beispiel Midnight Commander, ja zum Teil verschwimmen. Da könnte ich
> auch hingehen und sagen, daß grafische Dateimanager wesentlich weniger
> leistungsfähig sind als ein "find -exec" oder eine Shell-Schleife. Das
> wäre zwar nicht falsch, aber auch irrelevant, irreführend und somit
> nicht weniger unsinnig.

Ich habe geschrieben wie es sein sollte und nicht was der Midnight 
Commander ist oder nicht ist. Ich habe sogar dazu geschrieben, dass es 
häufig nicht so ist wie es sein sollte.

Prinzipiell kann jede Funktionalität der Kommandozeile auch in einer 
graphischen Umgebung realisiert werden und dazu kommen weitere 
Möglichkeiten (insbesondere aufgrund der Visualisierung und aufgrund der 
Fenster)

Lars R. schrieb:
> Sheeva P. schrieb:
>> "find -exec"
>
> Grafisch:
> . kann auch find nutzen.

Ich kenne kein grafisches find(1)-Frontend, das halbwegs übersichtlich 
und tatsächlich ordentlich benutzbar wäre. Du vielleicht?

> . vielfach erübrigt sich exec (zB Suchen und dann mit der Ergebnissmenge
> arbeiten)

Mag sein -- aber sehr, sehr häufig ist -exec eben trotzdem sehr, sehr 
nützlich. Wie man das ordentlich mit einer GUI abbilden will, ist mir 
schleierhaft, aber vielleicht hast Du ja eine Idee.

>> oder eine Shell-Schleife.
>
> Du schreibst Shell-Schleifen auf der Kommandozeile?

Ja, jeden Tag viele Male. Schnellen Überblick verschaffen, wie der 
Compiler optimiert?

1

for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o main; size main; done

Schnell herausfinden, welche Boost-Header im Projekt genutzt werden? 
(Ja, auch find(1) -exec ist im Prinzip eine For-Loop:)

1

find . \( -iname '*.hpp' -or -iname '*.cpp' \) -exec grep '^#include' {} \; | grep boost | sort | uniq

> Kann man graphisch im Editor machen.

Genau: dann muß man erstmal den Editor aufrufen, seine Loop schreiben, 
die Datei abspeichern, die Datei ausführen... und wie kommt dann das 
Ergebnis zum Benutzer? Willst Du jedesmal eine eigene GUI dafür 
schreiben? ;-)

> Ich habe geschrieben wie es sein sollte und nicht was der Midnight
> Commander ist oder nicht ist. Ich habe sogar dazu geschrieben, dass es
> häufig nicht so ist wie es sein sollte.

Sich an irgendwelchen Idealvorstellungen hoch zu hangeln, ist aber sogar 
noch viel unsinniger als die Kaprizierung auf unwesentliche Teilaspekte. 
Software ist, wie sie ist, ideale Software gibt es in der Praxis leider 
ebensowenig wie eine ideale Welt.

Fakt ist, daß man mit der Kommandozeile in sehr vielen Fällen ein wenig 
schneller ist als mit einem GUI-Werkzeug. Fakt ist aber eben auch, daß 
man eine recht steile Lernkurve überwinden und in der Übung bleiben muß, 
um so schnell und flüssig mit der Kommandozeile arbeiten zu können.

"To GUI or not to GUI" ist also nichtmal die Kernfrage. Die Kernfrage 
ist, ob man bereit ist, Einarbeitungszeit zu investieren, um hinterher 
schneller und flexibler arbeiten zu können -- oder ob man gleich 
loslegen will, dafür aber dauerhaft im Schnitt ein wenig langsamer ist. 
Das ist eine ökonomische Frage, die jeder für jede von ihm genutzte 
Software selbst beantworten muß. Und wie wir gerade gelesen haben, 
können sogar Kommandozeilenfreunde diese Frage etwa im Falle von LaTeX 
durchaus anders beantworten als ich -- und sie haben ebenso gute, 
nachvollziehbare und vernünftige Gründe für ihre Entscheidung, wie ich 
welche für meine habe.

> Prinzipiell kann jede Funktionalität der Kommandozeile auch in einer
> graphischen Umgebung realisiert werden und dazu kommen weitere
> Möglichkeiten (insbesondere aufgrund der Visualisierung und aufgrund der
> Fenster)

Ja. Aber dann wird die GUI so umfangreich und unübersichtlich, daß es 
ihren wichtigsten Vorteil -- die geringere Einarbeitungszeit -- zunichte 
macht.

Sheeva P. schrieb:
> Lars R. schrieb:
>> Sheeva P. schrieb:
>>> "find -exec"
>>
>> Grafisch:
>> . kann auch find nutzen.
>
> Ich kenne kein grafisches find(1)-Frontend, das halbwegs übersichtlich
> und tatsächlich ordentlich benutzbar wäre. Du vielleicht?

"ordentlich" definierst Du dann nachdem ich Vorschläge gemacht habe? Ich 
kürze das ab: "ordentlich" ist für Dich, wenn es eine GUI nicht kann ;) 
Aber wie weiter unten in diesem Post erwähnt und auch im Vorherigen: Die 
Kommandozeile könnte ein Bestandteil der GUI sein.

>>> oder eine Shell-Schleife.
>>
>> Du schreibst Shell-Schleifen auf der Kommandozeile?
>
> Ja, jeden Tag viele Male. Schnellen Überblick verschaffen, wie der
> Compiler optimiert?
>
>

1

> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o 

2

> main; size main; done

3

>

Ok. Ich würde das nicht jedes Mal neu eintippen.

>> Kann man graphisch im Editor machen.
>
> Genau: dann muß man erstmal den Editor aufrufen, seine Loop schreiben,
> die Datei abspeichern, die Datei ausführen...

Du bringst in zwei Zeilen 100+ Zeichen, nennst das schnell und gehst an 
einem weiteren Tastenanschlag für einen Editor-Aufruf kaputt? Ok. War 
nur ein Vorschlag.

> und wie kommt dann das
> Ergebnis zum Benutzer?

Das fehlt u.a. in der Tat noch: Die Möglichkeit zur Ausgabe des 
Kommandos in einem graphischen Fenster; ggf. gleich zur 
Weiterverwendung. Vielleicht macht das aber auch schon jemand mit irgend 
einem Trick. Ein Kommando ausführen ist jedenfalls kein Problem.
Unter Windows gab es Tools, die haben wenigstens die Ausgabe einfach 
offen gehalten. Mit PCmanFM scheint das nicht so einfach möglich, wie 
auch einiges anderes.

>> Ich habe geschrieben wie es sein sollte und nicht was der Midnight
>> Commander ist oder nicht ist. Ich habe sogar dazu geschrieben, dass es
>> häufig nicht so ist wie es sein sollte.
>
> Sich an irgendwelchen Idealvorstellungen hoch zu hangeln, ist aber sogar
> noch viel unsinniger als die Kaprizierung auf unwesentliche Teilaspekte.

Das sind nicht irgendwelche Idealvorstellungen. Mit dem Windowsexplorer 
kann ich aufgrund von mehr Visualisierung und Auswahlmöglichkeiten mit 
durchschnittlich weniger Anschlägen durch die Verzeichnisse gehen als 
mit der Kommandozeile unter Linux.

In der visualisierten Darstellung bekomme ich alle Optionen auf einmal 
angezeigt und den Shortcut noch dazu.

> "To GUI or not to GUI" ist also nichtmal die Kernfrage.

Doch. Denn die Kommandozeile kann vollständig Bestandteil der GUI sein. 
Vielleicht hat die Ausgabe eines Kommandos noch niemand vernünftig in 
eine GUI integriert, damit ja genug Menschen der puren, reinen 
Kommandozeile treu bleiben ;)

>> Prinzipiell kann jede Funktionalität der Kommandozeile auch in einer
>> graphischen Umgebung realisiert werden und dazu kommen weitere
>> Möglichkeiten (insbesondere aufgrund der Visualisierung und aufgrund der
>> Fenster)
>
> Ja. Aber dann wird die GUI so umfangreich und unübersichtlich, daß es
> ihren wichtigsten Vorteil -- die geringere Einarbeitungszeit -- zunichte
> macht.

Nein, wird sie nicht. Die Kommondozeile kann einfach zusätzlich komplett 
enthalten sein. Optionen für typische Befehle/Programme werden 
automatisch eingeblendet, usw.


Edit: Am Ende sind selbst zwei Terminalfenster nebeneinander "GUI". 
Copy/Paste von einer in die andere auf jeden Fall.

Lars R. schrieb:
> Sheeva P. schrieb:
>> Ich kenne kein grafisches find(1)-Frontend, das halbwegs übersichtlich
>> und tatsächlich ordentlich benutzbar wäre. Du vielleicht?
>
> "ordentlich" definierst Du dann nachdem ich Vorschläge gemacht habe? Ich
> kürze das ab: "ordentlich" ist für Dich, wenn es eine GUI nicht kann ;)

Habe ich -- außer, Dir zu widersprechen -- irgend etwas getan, daß Dich 
zu so böswilligen Unterstellungen verleitet? Oder kommst Du nur nicht 
damit klar, daß ich etwas anderes sehe, mache, und benutze als Du?

> Aber wie weiter unten in diesem Post erwähnt und auch im Vorherigen: Die
> Kommandozeile könnte ein Bestandteil der GUI sein.

Ja, und es gibt auch ein paar Programme, die ein CLI integrieren. Aber 
die, die ich kenne, verwenden darin eine eigene DSL, die außerhalb der 
Bedienung des betreffenden Programms wenig bis gar nichts kann. Warum 
sollte auch jemand eine Allround-Kommandozeile in ein GUI-Programm 
integrieren? Dann nimmt man doch lieber gleich das Original.

>>

1

>> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o

2

>> main; size main; done

3

>>

>
> Ok. Ich würde das nicht jedes Mal neu eintippen.

Ich schon -- denn das ist ja nur ein winziges, einfaches Beispiel von 
den vielen Wegwerf-CLI-Programmen, die ich bei meiner Arbeit benutze. 
All das in Skripte zu stecken, wäre total bescheuert und würde mich 
eines Gutteils der Flexibilität und Produktivität berauben, die ich in 
der CLI grade wegen des dynamischen Zusammensetzens leistungsfähiger 
Komponenten habe. Und wenn ich auf die Schnelle noch wissen will, wie 
lange mein Compiler übersetzt, oder wie schnell das Programm am Ende 
läuft? Kein Thema: ein paarmal in die Tastatur gehauen, schon steht das 
gewünschte Ergebnis da. Und der Clou: diese Methoden auf der CLI kann 
ich zur Not auch über eine schmalbandige SSH-Verbindung von meinem 
Mobiltelefon benutzen.

> Das fehlt u.a. in der Tat noch: Die Möglichkeit zur Ausgabe des
> Kommandos in einem graphischen Fenster; ggf. gleich zur
> Weiterverwendung. Vielleicht macht das aber auch schon jemand mit irgend
> einem Trick. Ein Kommando ausführen ist jedenfalls kein Problem.
> Unter Windows gab es Tools, die haben wenigstens die Ausgabe einfach
> offen gehalten. Mit PCmanFM scheint das nicht so einfach möglich, wie
> auch einiges anderes.

Also sind wir insoweit einig, daß sowohl CLIs als auch GUIs gewisse 
Limitierungen haben. Ich mein', zum Surfen im Netz benutze ich ja auch 
einen grafischen Webbrowser, lokal und wo es möglich ist die grafische 
Version vom Emacs, und zum interaktiven Editieren von Grafiken natürlich 
auch ein entsprechendes Grafikprogramm. Aber 90% meiner Arbeit besteht 
daraus, Dinge dynamisch zusammenzusetzen und sie dann zu automatisieren, 
und für solche Arbeiten ist eine CLI das ideale Profi-Werkzeug.

> Das sind nicht irgendwelche Idealvorstellungen.

Aber das hattest Du oben doch selbst geschrieben?

> Mit dem Windowsexplorer
> kann ich aufgrund von mehr Visualisierung und Auswahlmöglichkeiten mit
> durchschnittlich weniger Anschlägen durch die Verzeichnisse gehen als
> mit der Kommandozeile unter Linux.

Das bezweifle ich. Hast Du die Kommandozeile unter Linux überhaupt schon 
einmal ernsthaft und über einen längeren Zeitraum benutzt, oder redet da 
ein Blinder über die Farben?

> Doch. Denn die Kommandozeile kann vollständig Bestandteil der GUI sein.
> Vielleicht hat die Ausgabe eines Kommandos noch niemand vernünftig in
> eine GUI integriert, damit ja genug Menschen der puren, reinen
> Kommandozeile treu bleiben ;)

Vielleicht hat das aber auch nur deswegen noch niemand gemacht, weil es 
nahezu unmöglich ist, die unendlich vielen Möglichkeiten, die eine CLI 
bietet, in eine üblicherweise recht starre GUI zu gießen. Wenn es einen 
Sinn ergeben würde, die CLI in eine GUI zu integrieren, hätte das sicher 
schon jemand gemacht. Aber wozu sollte jemand so etwas tun, wenn er auch 
gleich das Original benutzen kann?

> Edit: Am Ende sind selbst zwei Terminalfenster nebeneinander "GUI".
> Copy/Paste von einer in die andere auf jeden Fall.

Das ist offensichtlich Quatsch, den Du Dir nur ausdenkst, um Deinen 
kruden irgendeinen Anschein von logischer Vernunft zu geben. Nach diesem 
Kriterium wäre auch meine CLI, die Konsole von KDE, dann in Wirklichkeit 
eine GUI. Aber so eine Behauptung wäre dann tatsächlich noch viel 
größerer Quatsch.

Latex ist was für Low-Performer.

Profis schreiben ihre Dokumente natürlich direkt in Postscript!!11!

Sheeva P. schrieb:
> Lars R. schrieb:
>> Sheeva P. schrieb:
>>> Ich kenne kein grafisches find(1)-Frontend, das halbwegs übersichtlich
>>> und tatsächlich ordentlich benutzbar wäre. Du vielleicht?
>>
>> "ordentlich" definierst Du dann nachdem ich Vorschläge gemacht habe? Ich
>> kürze das ab: "ordentlich" ist für Dich, wenn es eine GUI nicht kann ;)
>
> Habe ich -- außer, Dir zu widersprechen -- irgend etwas getan, daß Dich
> zu so böswilligen Unterstellungen verleitet?

Nein.

> Oder kommst Du nur nicht
> damit klar, daß ich etwas anderes sehe, mache, und benutze als Du?

Nein. Naja...

Ich hatte ursprünglich nur geschrieben, dass man in einer GUI fast alles 
idealerweise mit weniger Tastenanschlägen zum Erfolg kommt als mit der 
CLI (Logischerweise nur das, was die GUI auch beherrscht; was aber für 
viele Tätigkeiten ausreicht). Und daran ziehst Du Dich jetzt hoch.


> Warum
> sollte auch jemand eine Allround-Kommandozeile in ein GUI-Programm
> integrieren? Dann nimmt man doch lieber gleich das Original.

Damit man in der GUI auch einmal einen Befehl "ordentlich" absetzen 
kann, ohne dafür das Terminal aufmachen zu müssen und damit man die 
Ergebnisse des Befehls in der graphischen Umgebung weiterverwenden kann 
und damit man mehr visuelle Unterstützung hat.

>>>

1

>>> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o

2

>>> main; size main; done

3

>>>

>>
>> Ok. Ich würde das nicht jedes Mal neu eintippen.
>
> Ich schon -- denn das ist ja nur ein winziges, einfaches Beispiel von
> den vielen Wegwerf-CLI-Programmen, die ich bei meiner Arbeit benutze.

Andere sind noch größer und dann wirfst Du sie weg und tippst sie frisch 
(ggf. etwas anders) neu ein? Ich frage mich, was Du unter "schnell" 
verstehst.

> All das in Skripte zu stecken, wäre total bescheuert und würde mich
> eines Gutteils der Flexibilität und Produktivität berauben, die ich in
> der CLI grade wegen des dynamischen Zusammensetzens leistungsfähiger
> Komponenten habe.

Wenn einzelne Dateien ungünstig sind, dann würde ich zumindest eine 
Auswahlliste bevorzugen.

> Also sind wir insoweit einig, daß sowohl CLIs als auch GUIs gewisse
> Limitierungen haben.

Wir sind uns einig, dass eine GUI ohne Integration des kompletten CLI 
keine CLI ersetzt.

>> Das sind nicht irgendwelche Idealvorstellungen.
>
> Aber das hattest Du oben doch selbst geschrieben?

Stimmt. Mein Fehler.


>> Mit dem Windowsexplorer
>> kann ich aufgrund von mehr Visualisierung und Auswahlmöglichkeiten mit
>> durchschnittlich weniger Anschlägen durch die Verzeichnisse gehen als
>> mit der Kommandozeile unter Linux.
>
> Das bezweifle ich.

Gibt es für das Wechseln der Verzeichnisse in der CLI noch weitere 
Funktionen außer TAB und ENTER?

>> Doch. Denn die Kommandozeile kann vollständig Bestandteil der GUI sein.
>> Vielleicht hat die Ausgabe eines Kommandos noch niemand vernünftig in
>> eine GUI integriert, damit ja genug Menschen der puren, reinen
>> Kommandozeile treu bleiben ;)
>
> Vielleicht hat das aber auch nur deswegen noch niemand gemacht, weil es
> nahezu unmöglich ist, die unendlich vielen Möglichkeiten, die eine CLI
> bietet, in eine üblicherweise recht starre GUI zu gießen.

Eine Möglichkeit wäre ein integriertes zB xterm. Starr wäre es 
keinesfalls, denn dann wäre es keine CLI mehr.

> Wenn es einen
> Sinn ergeben würde, die CLI in eine GUI zu integrieren, hätte das sicher
> schon jemand gemacht. Aber wozu sollte jemand so etwas tun, wenn er auch
> gleich das Original benutzen kann?

Damit
. man den CLI nicht extra aufrufen muss.
. mehr Visualisierung in der CLI hat
. die Ergebnisse graphisch weiterverwenden kann
. ...

>> Edit: Am Ende sind selbst zwei Terminalfenster nebeneinander "GUI".
>> Copy/Paste von einer in die andere auf jeden Fall.
>
> Nach diesem
> Kriterium wäre auch meine CLI, die Konsole von KDE, dann in Wirklichkeit
> eine GUI.

Die Konsole von KDE ist nicht die GUI. KDE ist die GUI.

> Aber so eine Behauptung wäre dann tatsächlich noch viel
> größerer Quatsch.

Copy/Paste von einer CLI in die andere ist keine Funktionalität der CLI, 
sondern von einer (G)UI. Dann ist mein Vorschlag, auch von der CLI in 
die graphische Umgebung hinein kopieren zu können,zB Pfadangaben der CLI 
= Symbole graphisch oder "Rechtsklick, Öffnen mit" auf ein CLI-Ergebnis, 
usw

Lars R. schrieb:
> Ich hatte ursprünglich nur geschrieben, dass man in einer GUI fast alles
> idealerweise mit weniger Tastenanschlägen zum Erfolg kommt als mit der
> CLI (Logischerweise nur das, was die GUI auch beherrscht; was aber für
> viele Tätigkeiten ausreicht). Und daran ziehst Du Dich jetzt hoch.

Es wäre ja auch eine schlechte GUI, wenn man da sogar noch mehr tippen 
müsste als in einem CLI :-)

Aber: meiner Erfahrung nach bin ich mit der Kommandozeile auch deswegen 
deutlich schneller, weil ich gerade nicht zwischen Maus und Tastatur 
pendeln muss. Bis ich die Maus geschnappt (wo isser denn, der Zeiger?) 
und positioniert habe bin ich mit der Tastatureingabe schon längst 
durch.

> Andere sind noch größer und dann wirfst Du sie weg und tippst sie frisch
> (ggf. etwas anders) neu ein? Ich frage mich, was Du unter "schnell"
> verstehst.

Naja, so wild ist das nicht. Die Bash bspw. hat eine sehr gute 
History-Verarbeitung, in der man sehr schnell solche alten befehlszeilen 
wieder hochholen kann. Für Dinge, die man wirklich oft und vielleicht 
nur leicht abgewandelt benötigt, gibt es dann Aliasse usw.

>>> Mit dem Windowsexplorer
>>> kann ich aufgrund von mehr Visualisierung und Auswahlmöglichkeiten mit
>>> durchschnittlich weniger Anschlägen durch die Verzeichnisse gehen als
>>> mit der Kommandozeile unter Linux.
>>
>> Das bezweifle ich.
>
> Gibt es für das Wechseln der Verzeichnisse in der CLI noch weitere
> Funktionen außer TAB und ENTER?

Ich selbst verwende jedenfalls keine weiteren - aber die Bash ist 
unergründlich. Auch ich benutze nur einen Teil der Funktionalität :-)

Irgendwie muss man bei mehreren Treffern auswählen, in welchen Pfad man 
hinabsteigen möchte.

Geht das im Explorer schneller als (meist) mit einem Buchstaben, der 
dann die Differenzierung erlaubt?

> Damit
> . man den CLI nicht extra aufrufen muss.
> . mehr Visualisierung in der CLI hat
> . die Ergebnisse graphisch weiterverwenden kann

Ja, das sehe ich auch so. Ich hab zwar immer ein bis zwei Shell-fenster 
geöffnet, aber in Eclipse bspw. bevorzuge ich das eingebaute 
Bash-Fenster, einfach weil ich dann kein anderes nach vorn holen muss.

Chris D. schrieb:
> Lars R. schrieb:
> Aber: meiner Erfahrung nach bin ich mit der Kommandozeile auch deswegen
> deutlich schneller, weil ich gerade nicht zwischen Maus und Tastatur
> pendeln muss. Bis ich die Maus geschnappt (wo isser denn, der Zeiger?)
> und positioniert habe bin ich mit der Tastatureingabe schon längst
> durch.

Es kommt darauf an wie oft man überhaupt zur Maus wechselt. Jedes Feld 
und jeder selektierbare Haken sollte seinen Shortcut haben, idealerweise 
auch visuell mittels unterstrichenem Buchstaben dargestellt. Seit es 
günstige Notebooks nur noch mit Touch gibt und inzwischen mit immer 
weniger echten Tasten, mache ich das auch immer weniger. Hinzu kommen 
die Einstellungen der Maus (Bescheunigung/Sensitivität). Unter Linux mit 
den neuesten Touch benötige ich inzwischen ein Dutzend synclient 
Parameter für erträgliche Nutzbarkeit.

> Geht das im Explorer schneller als (meist) mit einem Buchstaben, der
> dann die Differenzierung erlaubt?

Windows7 (Erinnerung):
Zunächst gibt es auf der Eingabezeile mit dem ersten Buchstaben einen 
Defaultvorschlag. Dieser kann mehrere Verzeichnisse in die Tiefe gehen 
und orientiert sich an häufig genutztem. Der Vorschlag ist aber nicht 
eingegeben, sondern nur markiert. Mit Enter wählt man ihn aus.
Zusätzlich geht eine Dropdown-Liste auf, in der die weiteren (noch 
verbliebenen) Möglichkeiten angezeigt werden. Aus diesen kann man mit 
Cursor-UNTEN und Cursor-Hoch auswählen, ggf auch indem man auf der Taste 
bleibt. Nur ein weiterer Tastenanschlag Cursor-Rechts wählt den aktuell 
markierten Listeneintrag derart aus, dass man danach den nächsten 
Buchstaben tippen kann. Und dann beginnt alles von vorn. Ich glaube, es 
gab noch weitere Funktionen.
Es ist so ähnlich wie das Hangeln durch Klassen/Instanzen bei einer 
schönen IDE. Da gibt es irgendwo ein Optimum für möglichst wenig 
Tastenanschläge und visueller Unterstützung bei der Auswahl.

Im Moment nutze ich PCmanFM. Dieser beherrscht viele der auch unter 
Windows verfügbaren Funktionen, aber nicht alles davon genauso gut. 
Dafür hat er einige Stärken in anderen Bereichen.

Edit: PCmanFM
Alt+ CursorHOCH: Verzeichnis höher
Alt+ CursorLINKS/RECHTS: Duch die Historie der besuchten Verzeichnisse 
vor und zurück wechseln
usw...

Zeno schrieb:
> Lars R. schrieb:
>>>> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o
>>> main; size main; done
>>>
>> Ok. Ich würde das nicht jedes Mal neu eintippen.
>
> Also wenn ich so etwas öfter bräuchte würde ich das auch nicht jedesmal
> neu eintippen wollen. Das käme in ein Script.  Man könnte sicher auch
> einen Alias definieren.

Leute, Leute, Ihr zieht Euch ja an einem popeligen Beispiel hoch... 
dabei ist das nur ein schnelles, simples Beispiel, das ich auf die 
Schnelle aus einer meiner Bash-Histories gegrept habe. So große 
Aufmerksamkeit, wie Ihr ihm widmet, hat dieses popelige kleine Ding gar 
nicht verdient.

Ja, natürlich könnte man das in ein Skript packen, wenn man es wirklich 
öfter braucht. Abgesehen davon, daß man sich dann den Namen des Skripts 
oder des Alias merken müßte, wozu ich, zugegeben, viel zu faul bin, 
müßte man das Skript oder den Alias jedes Mal ändern, wenn die Dateien 
einmal nicht "main.cpp" und "main" heißen, oder man zusätzlich wissen 
will, wie lange der Compilerlauf oder das Ausführen des Programms 
dauert, oder wenn man noch andere Compilereinstellungen benutzen will, 
oder oder oder. Hinzu kommt, daß es sich erst dann lohnt, so etwas in 
ein Skript zu gießen, wenn man es öfter braucht -- dann würde ich es 
aber als eigenes Target in mein jeweiliges Makefile schreiben -- was 
hier aber nicht der Fall ist. Darum heißt sowas ja auch Wegwerfskript 
(throwaway script). Weil man es nur ein Mal braucht und dann wegwirft. 
Und am Ende ist ja auch nichts verloren: hundert Zeichen gebe ich in 
unter zwanzig Sekunden ein, viele GUI-Tools wären in dieser Zeit noch 
nicht einmal gestartet; Visual Studio, habe ich gerade gelesen, kann je 
nach installierten Erweiterungen, geschlagene fünf bis sieben Minuten 
benötigen, um zu starten... ;-)

For- oder While-Schleifen benutze ich in meinen Wegwerfskripten auch 
sehr regelmäßig. Das ist einfach praktisch und nützlich, um über Dateien 
oder zeilenweise über den Inhalt von Dateien zu iterieren -- na und? Wer 
kann, der kann, und Schleifen, Bedingungen, Variablen sind nicht nur 
inhärenter Bestandteil jeder ordentlichen Shell, sondern in vielen 
Situationen eben auch extrem nützlich. Soll ich mir von Leuten, die eine 
offensichtliche Abneigung gegen die Kommandozeile pflegen, etwa 
vorschreiben lassen, ob oder wie ich dieses extrem leistungfähige 
Profiwerkzeug benutzen darf, ob und wann ich Wegwerfskripte in einer 
Datei verewigen muß, anstatt sie -- wie es in der Natur der Sache liegt 
-- wegwerfen und vergessen darf? Wollt Ihr, die Ihr keine Ahnung von 
meiner Arbeit und meinen Aufgaben habt, mir wirklich erklären, wie ich 
mit Werkzeugen zu arbeiten habe, die ich seit dreißig Jahren täglich 
benutze? LOL!

Lars R. schrieb:
> Sheeva P. schrieb:
>>

1

>> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o

2

>> main; size main; done

3

>>

>
> Ok. Ich würde das nicht jedes Mal neu eintippen.

Wozu auch? Drei, vier Tastendrücke um es aus der history zu holen um 
Teile davon oder alles wiederzuverwenden.

Das Problem ist daß man als Windowsnutzer von Microsoft dazu erzogen 
wurde eine Kommandozeile kategorisch abzulehnen. Das haben sie erreicht 
indem sie die verkrüppeltste und benutzerfeindlichste Kommandozeile des 
ganzen Sonnensystems konstruiert und diese dann als abschreckendes 
Beispiel jedem Exemplar von Windows beigelegt haben. Der unbedarfte 
Anwender stolpert irgendwann mal über diese bizarre Monstrosität und 
lehnt sofort aufgrund dieses Einzelfalls (erster Eindruck zählt) die 
ganze Kategorie Kommandozeile als ganzes ab, für den Rest seines Lebens. 
Das ist sehr bedauerlich.

Bernd K. schrieb:
> Lars R. schrieb:
>> Sheeva P. schrieb:
>>>

1

>>> for i in 0 1 2 3 4 5 s fast g; do echo "${i}:"; g++ -O$i main.cpp -o

2

>>> main; size main; done

3

>>>

>>
>> Ok. Ich würde das nicht jedes Mal neu eintippen.
>
> Wozu auch? Drei, vier Tastendrücke um es aus der history zu holen um
> Teile davon oder alles wiederzuverwenden.

Die Rede war von sehr vielen, verschiedenen Scripten. Dazwischen noch 
diverse andere Befehle. Wie willst Du aus dieser Vielzahl das gerade 
Gesuchte ohne visualisierte Liste mit drei vier Tastendrücken aus der 
history holen? Geht nicht. Deshalb schreibt Sheeva ja auch, dass er's 
neu eintippt.


> Das Problem ist daß man als Windowsnutzer von Microsoft [...]
Keine Ahnung wovon Du schreibst... aber im Jahre 2017 ist mir persönlich 
die bash für Scripting (sei es live oder über Dateien) viel zu mickrig 
und die Syntax zu ungefällig.

Lars R. schrieb:
> Ich hatte ursprünglich nur geschrieben, dass man in einer GUI fast alles
> idealerweise mit weniger Tastenanschlägen zum Erfolg kommt als mit der
> CLI (Logischerweise nur das, was die GUI auch beherrscht; was aber für
> viele Tätigkeiten ausreicht). Und daran ziehst Du Dich jetzt hoch.

Naja, meine Erfahrung ist, daß die meisten GUIs eben bei Weitem nicht so 
effizient benutzt werden können, wie es unter idealen Bedingungen der 
Fall wäre. Und natürlich -- Du sagst es selbst -- kann eine GUI immer 
nur das, was ihr Hersteller vorgesehen hat. Das mag -- nein: es muß! -- 
für viele Tätigkeiten ausreichen, sonst wäre die ganze GUI nämlich 
unbrauchbar, und niemand könnte oder würde sie benutzen.

Aber genau hier kommt einer der wesentlichen und wichtigsten Vorteile 
von Kommandozeilenumgebungen zum Tragen: die können nämlich auch Dinge, 
and die der Hersteller nicht gedacht hat, und können aus einfachen 
Bausteinen viel leistungsfähigere Werkzeuge und Miniprogramme 
zusammensetzen. Kurz gesagt:  GUIs sind weitgehend starr, Kommandozeilen 
dagegen extrem flexibel.

> Damit man in der GUI auch einmal einen Befehl "ordentlich" absetzen
> kann, ohne dafür das Terminal aufmachen zu müssen und damit man die
> Ergebnisse des Befehls in der graphischen Umgebung weiterverwenden kann
> und damit man mehr visuelle Unterstützung hat.

Aber dazu müssen die Ergebnisse des Befehls in einem Format vorliegen, 
das von der GUI dargestellt werden kann, richtig? Eine Kommandozeile 
bleibt außerdem auch dann eine Kommandozeile, wenn sie in einer GUI 
dargestellt wird. Entscheidend dafür, was eine Kommandozeile ist, ist ja 
nicht die Darstellung auf dem Bildschirm, sondern das Konzept einer 
interaktiven Eingabe und ggf. Ausgabe von Befehlen in Textform.

> Andere sind noch größer und dann wirfst Du sie weg und tippst sie frisch
> (ggf. etwas anders) neu ein? Ich frage mich, was Du unter "schnell"
> verstehst.

Dazu haben moderne Kommandozeilenumgebungen wie die Bash ein grandioses 
Feature: nämlich die History, in der alle einmal eingegebenen Befehle 
und Befehlsfolgen abgespeichert werden und -- überraschenderweise mit 
dem Befehl "history" -- wieder abgerufen werden können. Es ist sogar 
möglich, einen Befehl in der History interaktiv zu suchen und -- 
gegebenenfalls modifiziert -- erneut auszuführen. Und wenn ich nur einen 
der zuletzt eingegebenen Befehle zurückholen will, drücke einfach die 
Taste "ArrowUp", hole den gerade ausgeführten Befehl wieder zurück, 
ändere ihn, und führe die geänderte Version aus. Natürlich kann ich auch 
einfach Teile von alten Befehlen kopieren und zu einem neuen 
zusammenfügen. All das ist äußerst  nützlich, um interaktiv komplexe 
Befehlsketten aufzubauen.

> Gibt es für das Wechseln der Verzeichnisse in der CLI noch weitere
> Funktionen außer TAB und ENTER?

Oh ja -- aber das Wechseln der Verzeichnisse erfolgt mit dem Befehl 
"cd", nicht mit TAB und ENTER. Dabei haben "cd" und TAB mehrere 
Funktionen: ein "cd -" wechselt ins zuletzt genutzte Verzeichnis, ein 
"cd" ohne Parameter wechselt ins Homeverzeichnis des Benutzers, ein 
einmaliger Druck auf TAB vervollständigt soweit das möglich ist und ein 
weiterer Druck auf TAB zeigt eine Liste von weiteren möglichen 
Vervollständigungen an. Außerdem gibt es pushd und popd, mit denen 
Listen häufig genutzter Verzeichnisse angelegt und direkt in beliebiger 
Tiefe angesprungen werden können.

Oft ist es in einer CLI aber auch gar nicht nötig, das 
Arbeitsverzeichnis zu wechseln. So kann ich etwa mit "emacs 
NICB/es/elasticsearch/config/elasticsearch.yml &" -- natürlich alles mit 
Tab-Completion eingegeben -- direkt die gewünschte Datei editieren, die 
tief in einem Unterverzeichnis liegt, ohne dazu mit meiner Shell in 
dieses Verzeichnis wechseln zu müssen. Das "&" am Ende versetzt den 
Befehl dazu gleich in den Hintergrund, so daß ich direkt in meiner Shell 
weiterarbeiten kann -- zum Beispiel, um ESearch nach der 
Konfigurationsänderung direkt neu zu starten ("systemctl restart 
elasticsearch.service", ebenfalls alles mit Tab-Completion). Und wenn 
ich es ganz schnell haben will, lasse ich das "&" weg, starte den Emacs 
mit "-nw" im Textmodus, und versetze ihn dann zum Neustart des Dienstes 
eben mit "Ctrl+Z" in den Hintergrund...

Mit dem Windows-Explorer oder ähnlichen Werkzeugen wie Dolphin oä. müßte 
ich erst nacheinander in die Verzeichnisse "NICB", "es", "elasticsearch" 
und "config" wechseln, dann könnte ich die Datei "elasticsearch.yml" 
öffnen, ändern, speichern, und danach müßte ich wiederum eine andere GUI 
-- unter Windows wäre das IIRC die "Diensteverwaltung" -- starten, dort 
den Elasticsearch-Dienst finden, und ihn dann neu starten. Ich 
bezweifle, daß das in der GUI schneller geht als in der CLI. (Sofern Du 
einen anderen Weg kennst, mit dem das schneller geht: immer her damit, 
vielleicht kann ich dabei ja noch etwas lernen.)

>> Vielleicht hat das aber auch nur deswegen noch niemand gemacht, weil es
>> nahezu unmöglich ist, die unendlich vielen Möglichkeiten, die eine CLI
>> bietet, in eine üblicherweise recht starre GUI zu gießen.
>
> Eine Möglichkeit wäre ein integriertes zB xterm. Starr wäre es
> keinesfalls, denn dann wäre es keine CLI mehr.

Aber natürlich wäre das eine CLI, alle Merkmale sind weiterhin vorhanden 
-- vor allem die interaktive Ein- und Ausgabe von Befehlen. Auch wenn 
eine Kommandozeile von einer GUI angezeigt wird, wird daraus noch keine 
GUI. Eine GUI zeichnet sich dadurch aus, daß sie bestimmte 
Bedienelemente hat, die vornehmlich mit einer Maus bedient werden 
können: Buttons, Checkboxen, Dropdown-Menüs und so weiter. Daß man 
manche GUIs auch mit Shortcurs über die Tastatur bedienen kann, macht 
diese ja auch nicht zu CLIs. ;-)

> Copy/Paste von einer CLI in die andere ist keine Funktionalität der CLI,
> sondern von einer (G)UI.

Das geht dank gpm auch auf der Textkonsole -- aber wenigstens weiß ich 
jetzt, warum wie so grandios an einander vorbei reden. Ja, natürlich ist 
auf meinen Arbeitsrechnern ein KDE (oder ein anderes Desktop 
Environment) installiert und wird dort auch benutzt. Aber diese Desktop 
Environments haben für mich zwei Funktionen: erstens stellen sie eine 
Basis für die verwendeten GUI-Programme dar, und andererseits dienen sie 
als eine Art Terminal-Multiplexer, um mehrere parallele Kommandozeilen 
offen zu haben und bequem zwischen ihnen umschalten zu können. Aber daß 
eine Shell in einem xterm (oder der Konsole) läuft, macht die Shell 
nicht weniger zu einer Kommandozeile. ;-)

Lars R. schrieb:
> Die Rede war von sehr vielen, verschiedenen Scripten. Dazwischen noch
> diverse andere Befehle. Wie willst Du aus dieser Vielzahl das gerade
> Gesuchte ohne visualisierte Liste mit drei vier Tastendrücken aus der
> history holen? Geht nicht. Deshalb schreibt Sheeva ja auch, dass er's
> neu eintippt.

Ein Mistverständnis: wenn ich denselben Wegwerf-Befehl mehrmals brauche, 
gebe ich ihn nicht neu ein, sondern hole ihn mir aus der History. Da 
kann ich wahlweise mit den Pfeiltasten arbeiten, die History interaktiv 
(mit "Strg+r" durchsuchen, oder mir die History komplett ausgeben lassen 
und natürlich auch auf diese Ausgabe grep(1)pen.

Nur wenn ich den Befehl -- wahrscheinlich nächstes Jahr, so ungefähr um 
die Weihnachtszeit -- wieder brauche, ja, dann gebe ich ihn eben wieder 
neu ein.

Sheeva P. schrieb:
> Lars R. schrieb:
>
>> Damit man in der GUI auch einmal einen Befehl "ordentlich" absetzen
>> kann, ohne dafür das Terminal aufmachen zu müssen und damit man die
>> Ergebnisse des Befehls in der graphischen Umgebung weiterverwenden kann
>> und damit man mehr visuelle Unterstützung hat.
>
> Aber dazu müssen die Ergebnisse des Befehls in einem Format vorliegen,
> das von der GUI dargestellt werden kann, richtig?

Richtig. Das wäre aber kein Problem. Die CLI sucht sich aus den Eingaben 
heraus, welche Zeichenkette ein Pfad sein kann. Ein Stück weit machen 
das GUIs auch. Spricht nichts dagegen, auch CLI-Ausgaben dahingehend zu 
untersuchen und sprechend aufzubereiten. usw

> Eine Kommandozeile
> bleibt außerdem auch dann eine Kommandozeile, wenn sie in einer GUI
> dargestellt wird. Entscheidend dafür, was eine Kommandozeile ist, ist ja
> nicht die Darstellung auf dem Bildschirm, sondern das Konzept einer
> interaktiven Eingabe und ggf. Ausgabe von Befehlen in Textform.

Ja.

>> Andere sind noch größer und dann wirfst Du sie weg und tippst sie frisch
>> (ggf. etwas anders) neu ein? Ich frage mich, was Du unter "schnell"
>> verstehst.
>
> Dazu haben moderne Kommandozeilenumgebungen wie die Bash ein grandioses
> Feature: nämlich die History, in der alle einmal eingegebenen Befehle
> und Befehlsfolgen abgespeichert werden und -- überraschenderweise mit
> dem Befehl "history"

7 Anschläge inkl. Enter

>> Gibt es für das Wechseln der Verzeichnisse in der CLI noch weitere
>> Funktionen außer TAB und ENTER?
>
> Oh ja -- aber das Wechseln der Verzeichnisse erfolgt mit dem Befehl
> "cd", nicht mit TAB und ENTER. Dabei haben "cd" und TAB mehrere
> Funktionen: ein "cd -"

5 Anschläge inkl. Enter. Alt+CursorLINKS in der GUI ist einer.

> wechselt ins zuletzt genutzte Verzeichnis, ein
> "cd" ohne Parameter wechselt ins Homeverzeichnis des Benutzers,

3 Anschläge. Alt+HOME in der GUI ist einer.

Das setzt sich endlos fort. Ein Tastenanschlag ->Menü xy. Ein 
Tastenanschlag -> Reiter xy. Ein Tastenanschlag -> Option ausgewählt, 
usw.

> ein
> einmaliger Druck auf TAB vervollständigt soweit das möglich ist und ein
> weiterer Druck auf TAB zeigt eine Liste von weiteren möglichen
> Vervollständigungen an.

Dafür braucht's in der GUI gar keinen Tastenanschlag.

> Oft ist es in einer CLI aber auch gar nicht nötig, das
> Arbeitsverzeichnis zu wechseln. So kann ich etwa mit "emacs
> NICB/es/elasticsearch/config/elasticsearch.yml &" -- natürlich alles mit
> Tab-Completion eingegeben -- direkt die gewünschte Datei editieren, die
> tief in einem Unterverzeichnis liegt, ohne dazu mit meiner Shell in
> dieses Verzeichnis wechseln zu müssen.

Geht mit einer GUI typischerweise auch und zwar ohne dass man noch extra 
"emacs " tippen muss.


>  Das "&" am Ende versetzt den
> Befehl dazu gleich in den Hintergrund, so daß ich direkt in meiner Shell
> weiterarbeiten kann -- zum Beispiel, um ESearch nach der
> Konfigurationsänderung direkt neu zu starten ("systemctl restart
> elasticsearch.service", ebenfalls alles mit Tab-Completion). Und wenn
> ich es ganz schnell haben will, lasse ich das "&" weg, starte den Emacs
> mit "-nw" im Textmodus, und versetze ihn dann zum Neustart des Dienstes
> eben mit "Ctrl+Z" in den Hintergrund...

Dafür hat eine GUI Fenster.


>>> Vielleicht hat das aber auch nur deswegen noch niemand gemacht, weil es
>>> nahezu unmöglich ist, die unendlich vielen Möglichkeiten, die eine CLI
>>> bietet, in eine üblicherweise recht starre GUI zu gießen.
>>
>> Eine Möglichkeit wäre ein integriertes zB xterm. Starr wäre es
>> keinesfalls, denn dann wäre es keine CLI mehr.
>
> Aber natürlich wäre das eine CLI, alle Merkmale sind weiterhin vorhanden
> -- vor allem die interaktive Ein- und Ausgabe von Befehlen.

Ich wollte zum Ausdruck bringen: Wenn es starr wäre, wäre CLI kein 
Bestandteil mehr.

> Auch wenn
> eine Kommandozeile von einer GUI angezeigt wird, wird daraus noch keine
> GUI. Eine GUI zeichnet sich dadurch aus, daß sie bestimmte
> Bedienelemente hat, die vornehmlich mit einer Maus bedient werden
> können

GUIs gab es vor Mäusen.

> Buttons, Checkboxen, Dropdown-Menüs und so weiter. Daß man
> manche GUIs auch mit Shortcurs über die Tastatur bedienen kann, macht
> diese ja auch nicht zu CLIs. ;-)

Richtig.

> und andererseits dienen sie
> als eine Art Terminal-Multiplexer

Das nennt sich GUI, nicht multiplexer! Und von einem Terminal zum 
anderen brauchst Du keine Maus. Du benutzt die CLI ständig in 
Zusammenhang mit einer GUI. Und ich sage unter anderem: Warum das nicht 
noch weiter graphisch verzahnen?

Lars R. schrieb:
> Wie willst Du aus dieser Vielzahl das gerade
> Gesuchte ohne visualisierte Liste mit drei vier Tastendrücken aus der
> history holen? Geht nicht.

Wenn man sich noch daran erinnern kann (was wohl nahe liegt wenn man es 
"ständig" braucht) dass es zum Beispiel mit "for i in 0" anfing dann 
tippt man das und und benutzt anschließend die Pfeiltasten um in den 
gefilterten Ergebnissen zu blättern bis man es oder eine Abwandlung 
davon gefunden hat die man wiederverwenden kann.

Es stellt sich also in der Praxis genau das Gegenteil des von Dir 
vermuteten Effekts ein: Je öfter man ein bestimmtes Konstrukt immer 
wieder braucht desto weniger muss man tippen.

Zeno schrieb:
> Um mal bei dem Beispiel zu bleiben, wenn ich dieses in ein Script packe
> und dem z.B. den Namen "optcompile" (Bezeichnung habe ich mir gerade aus
> den Fingern gesogen), dann bin ich mit "optcompile main" sicherlich
> schneller als wenn ich den Kram jedes mal neu eingebe oder aus den
> Tiefen der History hervorholen muß.

Dann müßte ich mich -- wie gesagt: nächstes Jahr kurz vor Weihnachten -- 
wieder an den Namen "optcompile" erinnern -- sowie daran, daß ich den 
Namen des Kompilats und nicht etwa der Quelldatei angeben muß. Natürlich 
müßte ich auch Schalter einbauen, wenn ich  zum Beispiel statt eines 
Standalone-Binary eine Shared Library bauen, einen anderen C++-Standard 
benutzen, oder andere Optimierungen wie LTO. Das alles auch nächstes 
Jahr zu Weihnachten noch zu wissen, fällt mir mir steigendem Alter 
zunehmend schwer, zumal das ja nur eines von dutzenden oder vielleicht 
sogar hunderten Wegwerfskripten ist, welche ich täglich baue und 
benutze. Zu meiner Erinnerung müßte ich dieses Skript also mindestens 
mit einem "-h" oder "--help"-Schalter ausstatten, besser wäre es aber, 
zusätzlich eine kleine Dokumentation dafür anzulegen. Und sogar dann 
dauert es angesichts der Vielzahl solch kleiner Wegwerfskripte, die ich 
täglich benutze, vermutlich länger, das passende Skript aus der 
Dokumentation zu fischen, als die Befehle neu einzugeben.

Nee, Leute, sorry, aber Wegwerfskripte sind Wegwerfskripte, weil man die 
eben nicht ständig benutzt und weil es billiger ist, sie wegzuwerfen und 
für den unwahrscheinlichen Fall, daß man sie geraume Zeit später dann 
doch nochmal braucht, eben einfach erneut einzugeben. Klar, wenn diese 
Skripte einen bestimmten Umfang überschreiten, ist es trotzdem besser, 
sie in eine Skriptdatei zu schreiben, schon wegen der besseren 
Übersichtlichkeit, und die dann wahlweise zu behalten oder zu löschen, 
je nachdem, ob, und wie bald man diese oder eine ähnliche Funktionaltät 
wieder benötigt.

Lars R. schrieb:
>> Das Problem ist daß man als Windowsnutzer von Microsoft [...]
> Keine Ahnung wovon Du schreibst...

Du demonstrierst gerade den Effekt den ich beschreibe: Du beurteilst die 
vermuteten Workflows auf einer richtigen[TM] shell ausschließlich anhand 
deiner Erfahrungen mit der stark limitierten cmd.exe.

Konkretes Beispiel: Du fasst es noch nichtmal ins Auge daß es eventuell 
sowas geben könnte wie Filtern der History oder gezieltes Suchen in 
derselben. Die meisten Deiner Kollegen gehen sogar noch einen Schritt 
weiter und fassen noch nichtmal ins Auge daß es überhaupt sowas geben 
könnte wie ne History wenn sie Dinge ablehnen die sie noch nie gesehen 
haben.

Bernd K. schrieb:
> Lars R. schrieb:
>> Wie willst Du aus dieser Vielzahl das gerade
>> Gesuchte ohne visualisierte Liste mit drei vier Tastendrücken aus der
>> history holen? Geht nicht.
>
> Wenn man sich noch daran erinnern kann (was wohl nahe liegt wenn man es
> "ständig" braucht) dass es zum Beispiel mit "for i in 0" anfing

Fast jede for-Schleife fängt so an.

> Es stellt sich also in der Praxis genau das Gegenteil[...]

Nein, die Aussage war, es wird neu eingetippt. Das ist inzwischen 
korrigiert. Mir letztlich egal.


Bernd K. schrieb:
> Lars R. schrieb:
>>> Das Problem ist daß man als Windowsnutzer von Microsoft [...]
>> Keine Ahnung wovon Du schreibst...
>
> Du demonstrierst gerade den Effekt den ich beschreibe: Du beurteilst die
> vermuteten Workflows auf einer richtigen[TM] shell ausschließlich anhand
> deiner Erfahrungen mit der stark limitierten cmd.exe.

Nein, denn für Scripttätigkeiten (zB Schleifen)nutze ich eine relativ 
aktuellen Python-Version. So etwas gab es zwar vor 30 Jahren noch nicht, 
aber man muss ja nicht zwingend auf so einem alten Entwicklungsstand 
(bash) stehen bleiben, oder?

> Konkretes Beispiel: Du fasst es noch nichtmal ins Auge daß es eventuell
> sowas geben könnte wie Filtern der History oder gezieltes Suchen in
> derselben.

Hab ich vergessen. Dauert alles zu lang. Zu viele Tastenanschläge. Zu 
vieles Durchsteppen. Zu wenig Übersicht. Ggf. nehme ich heutzutage dann 
gleich Pyhton.


Edit: Ich nutzte auch selbstgeschriebene Bash-Scripte. Gerade nochmal 
nachgeschaut. Das sind aber zumeist (längere) Einzeiler.

Hallo Bernd,

> Das Problem ist daß man als Windowsnutzer von Microsoft dazu erzogen
> wurde eine Kommandozeile kategorisch abzulehnen. Das haben sie erreicht
> indem sie die verkrüppeltste und benutzerfeindlichste Kommandozeile des
> ganzen Sonnensystems konstruiert und diese dann als abschreckendes
> Beispiel jedem Exemplar von Windows beigelegt haben. Der unbedarfte
> Anwender stolpert irgendwann mal über diese bizarre Monstrosität und
> lehnt sofort aufgrund dieses Einzelfalls (erster Eindruck zählt) die
> ganze Kategorie Kommandozeile als ganzes ab, für den Rest seines Lebens.
> Das ist sehr bedauerlich.

Entschuldige, aber das ist doch Blödsinn und wieder eine von diesen 
Microsoft-Verschwörungstheorien. Die Kommandozeile von Microsoft ist zu 
einer Zeit entstanden in der sie irgend wie ihr MS-DOS bedienbar machen 
mussten. Und wie es ebenso ist werden solche (sicherlich ungenügenden) 
Konstrukte immer weiterverwendet.
So wie ich verstanden habe gibt es ja mittlerweile als Ersatz die 
Powershell oder sogar eine BASH-artige-Kommandozeile, so das man das 
alte "Ding" gar nicht mehr benutzen muss.

Trotzdem bleibt das Grundproblem aller Kommandozeilen bestehen: die 
intensive Benutzung (wie es z.B. Sheeva Plug macht) und die damit 
verbundene Effizienzsteigerung ist nur möglich wenn man ständig und 
permanent damit arbeitet. Verwendet man dagegen ein derart mächtiges 
Werkzeug wie die Bash nur ab und zu , b.z.w. eher selten, bietet sie 
zeitlich und funktionell keinen Vorteil gegenüber der "umständlicheren" 
Benutzung einer grafischen Oberfläche.

rhf

Lars R. schrieb:
> Richtig. Das wäre aber kein Problem. Die CLI sucht sich aus den Eingaben
> heraus, welche Zeichenkette ein Pfad sein kann. Ein Stück weit machen
> das GUIs auch. Spricht nichts dagegen, auch CLI-Ausgaben dahingehend zu
> untersuchen und sprechend aufzubereiten. usw

Die CLI sucht sich aus den Eingaben nicht heraus, welche Zeichenketten 
ein Pfad sein kann, wie kommst Du darauf? Eine moderne Tab-Completion 
arbeitet natürlich kontextsensitiv.

>> Dazu haben moderne Kommandozeilenumgebungen wie die Bash ein grandioses
>> Feature: nämlich die History, in der alle einmal eingegebenen Befehle
>> und Befehlsfolgen abgespeichert werden und -- überraschenderweise mit
>> dem Befehl "history"
>
> 7 Anschläge inkl. Enter

Wenn man so rechnet wie Du, wären es sogar 8 ("history": 7 plus ENTER: 8 
Anschläge). Könner brauchen natürlich nur 5: "his", TAB, ENTER. Damit 
sehe ich meine Vermutung bestätigt, daß Du noch nie ernsthaft und über 
längere Zeit mit einer Kommandozeile gearbeitet hast und Du ein Blinder 
bist, der den Sehenden etwas über Farben erzählen will.

>> und andererseits dienen sie
>> als eine Art Terminal-Multiplexer
>
> Das nennt sich GUI, nicht multiplexer! Und von einem Terminal zum
> anderen brauchst Du keine Maus. Du benutzt die CLI ständig in
> Zusammenhang mit einer GUI. Und ich sage unter anderem: Warum das nicht
> noch weiter graphisch verzahnen?

Mach' das doch. Ich bin gespannt, was dabei herauskommt, und ob man 
damit schneller arbeiten kann als mit einer GUI oder sogar als einer 
CLI. Wann ungefähr darf ich denn mit ersten Ergebnissen rechnen?

Weißt Du, ich kenne GUIs, ihre Vorzüge, aber auch ihre Limitierungen. 
Nicht selten entwerfe und schreibe ich sogar selbst GUIs, meistens für 
Menschen, die mit CLIs überfordert wären. Es ist also nicht so, als 
würde ich dabei über etwas sprechen, von dem ich keine Ahnung hätte. 
Aber gerade weil ich GUIs kenne, kenne ich natürlich auch ihre Grenzen 
und weiß darum, daß viele Dinge wesentlich schneller mit einer CLI 
gemacht werden können. Das ist der einzige Grund, warum ich für sehr 
viele Aufgaben lieber CLIs benutze, weil ich damit für die meisten 
meiner Arbeiten und Aufgaben wesentlich schneller bin, als irgendwer es 
mit einer GUI sein könnte. Wenn ich das mit einer GUI schneller machen 
könnte, dann würde ich eben die benutzen. Die CLI ist für mich kein 
Selbstzweck, sondern ein extrem leistungsfähiges, enorm flexibles 
Profiwerkzeug, welches es mir ermöglicht, meine Arbeit schnellstmöglich 
zu erledigen -- nicht mehr, aber auch nicht weniger.

Tatsächlich ist es sogar häufig so, daß sich CLI- und GUI-Nutzung bei 
mir überschneiden und ergänzen: beispielsweise extrahiere ich Daten aus 
einer oder mehreren Datenbanken, kombiniere, aggregiere und visualisiere 
sie mit der CLI in ein schickes Diagramm, und arbeite dieses dann mit 
einem GUI-Programm nach. Somit nutze ich das Beste aus beiden Welten und 
kann daher beim besten Willen nicht das geringste Verständnis für Deine 
Fixierung und Selbstbeschränkung auf GUIs aufbringen -- aber 
erfreulicherweise muß ich das ja auch nicht.

Am Ende ist es mir allerdings vollkommen gleichgültig, was Du benutzt. 
Nur wenn Du Unsinn erzählst und beispielsweise die gleichermaßen falsche 
wie verallgemeinernde Behauptung aufstellst, daß man mit GUIs immer 
schneller und produktiver arbeiten könne als mit CLIs, dann ist das 
schlicht Unsinn, und dann wirst Du mit deutlichem Widerspruch 
meinerseits rechnen müssen. Und nein, mit böswilligen Unterstellungen, 
kindischen Rechthabereien wie dem geradezu lächerlichen Abzählen von 
Tastaturanschlägen für einzelne Pippifax-Befehle und der vollständigen 
Ignoranz gegenüber dem wichtigsten Feature der CLI, nämlich viele 
einfache Befehle zu sehr viel größeren und komplexeren Werkzeugen 
zusammensetzen zu können, wirst Du mich ganz sicher nicht davon 
abhalten, solchem Unsinn zu widersprechen.

Lars R. schrieb:
> So etwas gab es zwar vor 30 Jahren noch nicht,

Perl wird dieses Jahr dreißig.

> Hab ich vergessen. Dauert alles zu lang. Zu viele Tastenanschläge. Zu
> vieles Durchsteppen. Zu wenig Übersicht. Ggf. nehme ich heutzutage dann
> gleich Pyhton.

Im interaktiven Modus des Standardinterpreters oder mit dem extra auf 
die interaktive Nutzung optimierten iPython (ja, auch mit 
Tab-Completion) ist Python nichts anderes als eine Shell bzw. eine CLI 
-- und ein wichtiger Bestandteil meines täglich genutzten 
Werkzeugkastens. Wenn ich von CLI spreche, meine ich damit auch 
Werkzeuge wie Python und Perl.

Sheeva P. schrieb:
> Lars R. schrieb:
>> Richtig. Das wäre aber kein Problem. Die CLI sucht sich aus den Eingaben
>> heraus, welche Zeichenkette ein Pfad sein kann. Ein Stück weit machen
>> das GUIs auch. Spricht nichts dagegen, auch CLI-Ausgaben dahingehend zu
>> untersuchen und sprechend aufzubereiten. usw
>
> Die CLI sucht sich aus den Eingaben nicht heraus, welche Zeichenketten
> ein Pfad sein kann, wie kommst Du darauf? Eine moderne Tab-Completion
> arbeitet natürlich kontextsensitiv.
>
>>> Dazu haben moderne Kommandozeilenumgebungen wie die Bash ein grandioses
>>> Feature: nämlich die History, in der alle einmal eingegebenen Befehle
>>> und Befehlsfolgen abgespeichert werden und -- überraschenderweise mit
>>> dem Befehl "history"
>>
>> 7 Anschläge inkl. Enter
>
> Wenn man so rechnet wie Du, wären es sogar 8 ("history": 7 plus ENTER: 8
> Anschläge). Könner brauchen natürlich nur 5: "his", TAB, ENTER. Damit
> sehe ich meine Vermutung bestätigt, daß Du noch nie ernsthaft und über
> längere Zeit mit einer Kommandozeile gearbeitet hast und Du ein Blinder
> bist, der den Sehenden etwas über Farben erzählen will.

Hast Du etwa auswendig gewusst wie viele Tastenanschläge es sind, oder 
musstest Du mindestens gedanklich nachzählen, weil Du die Kommandozeile 
so selten benutzt?

> Am Ende ist es mir allerdings vollkommen gleichgültig, was Du benutzt.
> Nur wenn Du Unsinn erzählst und beispielsweise die gleichermaßen falsche
> wie verallgemeinernde Behauptung aufstellst

Selber. Verwendest GUI und nennst es Multiplexer. Habe Dir die Anzahl 
erforderlicher Tastenanschläge vorgerechnet GUI vs. CLI.


> Tastaturanschlägen für einzelne Pippifax-Befehle und der vollständigen
> Ignoranz gegenüber dem wichtigsten Feature der CLI, nämlich viele
> einfache Befehle zu sehr viel größeren und komplexeren Werkzeugen
> zusammensetzen zu können

Ich benutze selbst die Bash. Aber das hat seine Grenzen. Für Komplexeres 
nutze ich nicht die Pippifax-Funktionalität der Bash, sondern Python. 
Bin kein Nostalgiker.

Nochmal die Nachfrage, was stört Dich jetzt an meiner Aussage, an der Du 
Dich nun schon seitenlang aufreibst:

"Idealerweise funktioniert die Tastatursteuerung im graphischen
Dateisystem-Explorer aufgrund von mehr Möglichkeiten besser als auf der
Kommandozeile. Mindestens sollte sie jedoch genauso gut funktionieren.
Leider ist das nicht überall gegeben."


Stört Dich der Begriff "mehr Möglichkeiten"?
Das bezog sich auf die Visualisierung und die Tastatursteuerung (beides 
habe ich belegt), nicht auf den Funktionsumfang.

Roland F. schrieb:
> Entschuldige, aber das ist doch Blödsinn und wieder eine von diesen
> Microsoft-Verschwörungstheorien. Die Kommandozeile von Microsoft ist zu
> einer Zeit entstanden in der sie irgend wie ihr MS-DOS bedienbar machen
> mussten. Und wie es ebenso ist werden solche (sicherlich ungenügenden)
> Konstrukte immer weiterverwendet.
> So wie ich verstanden habe gibt es ja mittlerweile als Ersatz die
> Powershell oder sogar eine BASH-artige-Kommandozeile, so das man das
> alte "Ding" gar nicht mehr benutzen muss.

Naja, richtig ist jedenfalls, daß Microsoft mit dem Schwenk auf die 
NT-Technik anfangs selbst gesagt hat, jetzt bräuchte man so ein Relikt 
wie eine Kommandozeile nicht mehr. Trotzdem hat man als Ersatz für die 
gute alte command.com die cmd.exe beibehalten, wollte sie damals aber 
auch eigentlich lieber loswerden.

Als Microsoft dann festgestellt hat, daß viele Benutzer die 
Kommandozeile behalten wollten, haben sie dann anfangs sogar die cmd.exe 
weiterentwickelt und auch dort ein paar Features der klassischen 
UNIX-Shells eingebaut, zum Beispiel das wiederholen einmal abgeschickter 
Befehle über die Pfeiltasten und -- anfangs mußte man dazu noch einen 
Registry-Eintrag umschalten, wenn ich mich recht entsinne -- übrigens 
auch die Tab-Completion. Dadurch wurde die Windows-Shell zwar etwas 
komfortabler, aber es trotzdem fehlte immer noch ein Userland, dessen 
Mächtigkeit an das der UNIX-Welt heran reichte.

Anstatt nun dieses Userland nachzureichen (teilweise wurde das mit den 
Resource Kits gemacht), hat Microsoft sich dann aber entschieden, etwas 
ganz Neues zu machen: die Powershell. Die hat einige durchaus 
interessante Ansätze, beispielsweise, daß dort keine Textausgaben auf 
die Eingabe des Folgebefehls weitergereicht werden, sondern 
serialisierte .NET-Objekte; der größte Vorteil davon ist, daß die 
Objekte nicht aufwändig transformiert werden müssen, wie es in 
klassischen UNIX-Skripten häufig gemacht werden muß. Jedoch ist der 
Nachteil, daß die Powershell in einigen Bereichen stark an das komplexe 
.NET-Framework gebunden ist, was den Einarbeitungsaufwand für Anwender, 
die mit dem .NET-Framework nicht vertraut sind, noch einmal erhöht und 
dadurch oftmals abgeschreckt hat.

Nachdem Microsoft aber festgestellt hat, daß sie in den meisten 
Bereichen außerhalb der Desktop- und Office-Produkte weitestgehend 
verloren haben -- sogar in Microsofts Azure-Cloud laufen fast zwei 
Drittel der Systeme unter Linux -- hat man sich zu einem Kurswechsel 
entschieden und dem NT-Kernel die Fähigkeit eingebaut, Binaries im unter 
Linux üblichen ELF-Binärformat auszuführen. Dadurch können in modernen 
Windows-Systemen direkt Binaries aus den Repositories von Ubuntu-Linux 
heruntergeladen, installiert, und ausgeführt werden. Das Ganze ist noch 
in einem frühen Stadium, deshalb als "Experimental Feature" markiert und 
noch etwas holprig. Die Fortschritte zwischen den letzten beiden 
Versionen lassen allerdings erkennen, daß die Microsoft-Entwickler 
ziemlich intensiv an diesem Feature arbeiten.

> Trotzdem bleibt das Grundproblem aller Kommandozeilen bestehen: die
> intensive Benutzung (wie es z.B. Sheeva Plug macht) und die damit
> verbundene Effizienzsteigerung ist nur möglich wenn man ständig und
> permanent damit arbeitet. Verwendet man dagegen ein derart mächtiges
> Werkzeug wie die Bash nur ab und zu , b.z.w. eher selten, bietet sie
> zeitlich und funktionell keinen Vorteil gegenüber der "umständlicheren"
> Benutzung einer grafischen Oberfläche.

Ja. Das gilt aber für jedes halbwegs komplexe Programm, egal ob CLI oder 
GUI. Wer nur ab und an mit GUI-Monstern wie Photoshop oder Eclipse 
arbeitet, kann deren Leistungspotential nicht ausnutzen. Genauso ist das 
natürlich auch mit einer Kommandozeile; wer sie so selten benutzt, daß 
er die Befehle oder ihre wichtigsten Optionen vergißt, kann damit 
niemals effizient sein.

Lars R. schrieb:
> Hast Du etwa auswendig gewusst wie viele Tastenanschläge es sind, oder
> musstest Du mindestens gedanklich nachzählen, weil Du die Kommandozeile
> so selten benutzt?

Ich habe sogar praktisch nachgezählt, weil ich die Kommandozeile so 
häufig benuzte, daß ich über Tastenanschläge nicht mehr nachdenke und 
meine Finger schon von selbst in der passenden Position auf die Tastatur 
fallen.

> Selber. Verwendest GUI und nennst es Multiplexer.

Ja, als genau solchen benutze ich die GUI ja auch: als Multiplexer für 
diverse CLIs und einige wenige GUI-Anwendungen.

> Habe Dir die Anzahl erforderlicher Tastenanschläge vorgerechnet GUI vs.
> CLI.

Ja, sehr lustig. Dabei hast Du natürlich unterschlagen, daß man Deine 
GUI-Programme erstmal starten muß, in vielen Fällen zwischen ihnen 
umschalten muß, und so weiter...

> Ich benutze selbst die Bash. Aber das hat seine Grenzen. Für Komplexeres
> nutze ich nicht die Pippifax-Funktionalität der Bash, sondern Python.

Ja da schau her, Überraschung: das mach' ich genauso. Und manchmal nehme 
ich dazu auch noch Perl, meistens als Filter, ganz pragmatisch, immer 
was eben gerade am besten passt. Sehr oft benutze ich übrigens auch 
ipython oder den interaktiven Modus des Python-Interpreters, und das 
sind ja auch nichts anderes als CLIs. Ich fürchte, Du assoziierst den 
Begriff "CLI" ein bisschen zu stark mit der Bash.

> Bin kein Nostalgiker.

Sondern Dogmatiker?!

Lars R. schrieb:
> Nochmal die Nachfrage, was stört Dich jetzt an meiner Aussage, an der Du
> Dich nun schon seitenlang aufreibst:

Eigentlich habe ich mich vor allem an den seitenlangen Folgeausführungen 
"aufgerieben". Danke, mir gehts trotzdem gut. ;-)

> "Idealerweise funktioniert die Tastatursteuerung im graphischen
> Dateisystem-Explorer aufgrund von mehr Möglichkeiten besser als auf der
> Kommandozeile. Mindestens sollte sie jedoch genauso gut funktionieren.
> Leider ist das nicht überall gegeben."
>
> Stört Dich der Begriff "mehr Möglichkeiten"?

Sowohl der, als auch das "funktioniert [...] besser". De facto haben 
alle GUI-Programme das Manko, daß sie eben weniger Möglichkeiten haben 
als ein gutes CLI. GUI-Programme haben immer nur ausschließlich die 
Möglichkeiten, die ihr Entwickler vorgesehen hat, während die vielen 
kleinen CLI-Programme vollkommen flexibel kombiniert werden können zu 
geradezu unendlich vielen Möglichkeiten.

Deshalb kann eine GUI-Anwendung prinzipbedingt nur einen Bruchteil der 
Möglichkeiten anbieten, die eine CLI hat, und wegen dieser Limitierungen 
eben nicht einmal gleich gut funktionieren, schon gar nicht "besser". 
Sie kann allerhöchstens gleich gut funktionieren, wenn man die vom 
Entwickler vorgesehenen Pfade nicht verläßt und einem die von ihm 
vorgesehene und prinzipbedingt limitierte Funktionalität ausreicht. Am 
Ende kann Dein Dateimanager nicht mehr als Dateien managen, also: 
auflisten, kopieren, verschieben und löschen. Bitte entschuldige, aber 
das ist ja wohl keine besonders aufregende Vielfalt von Funktionen, 
vorsichtig gesagt.

> Das bezog sich auf die Visualisierung und die Tastatursteuerung (beides
> habe ich belegt), nicht auf den Funktionsumfang.

Ach, Baumstrukturen kann ich auch auf der CLI benutzen, als Beispiel sei 
hier nur das Programm "tree" genannt. Und, wie gesagt, die Steuerung per 
Tastatur bietet immer nur das an, was der Entwickler vorgesehen hat. Wie 
sollte ein solch starres Konzept an die Funktionalität und Flexibilität 
etlicher leistungsfähiger, frei kombinierbarer Werkzeuge heran reichen?

Weiter oben hattest Du dazu gesagt, daß das, was die GUI kann, "für 
viele Tätigkeiten ausreicht". Das kann ja gerne sein, daß Dir das für 
Deine Tätigkeiten ausreicht, aber mir reicht das für meine 
Tätigkeiten eben regelmäßig nicht und deswegen benutze ich Werkzeuge, 
die wesentlich mehr können, sehr viel flexibler, und meistens auch 
erheblich schneller und stabiler sind als jede GUI.

Sheeva P. schrieb:
> Lars R. schrieb:
>> Hast Du etwa auswendig gewusst wie viele Tastenanschläge es sind, oder
>> musstest Du mindestens gedanklich nachzählen, weil Du die Kommandozeile
>> so selten benutzt?
>
> Ich habe sogar praktisch nachgezählt, weil ich die Kommandozeile so
> häufig benuzte, daß ich über Tastenanschläge nicht mehr nachdenke und
> meine Finger schon von selbst in der passenden Position auf die Tastatur
> fallen.

Aber mir wirfst Du gleich wieder vor, ein Blinder zu sein der sich über 
Farben beschwert. Nur weil ich spontan statt 5Anschläge 8Anschläge 
gesagt hatte. Dabei geht's Dir selbst nicht besser. Es sind eben einfach 
zu viele Tastenanschläge, die man in der bash für jede Kleinigkeit 
tätigen muss.

>> Habe Dir die Anzahl erforderlicher Tastenanschläge vorgerechnet GUI vs.
>> CLI.
>
> Ja, sehr lustig. Dabei hast Du natürlich unterschlagen, daß man Deine
> GUI-Programme erstmal starten muß, in vielen Fällen zwischen ihnen
> umschalten muß, und so weiter...

Selber lustig. Deine bash (bzw samt KDE wenn Du mehrere startet) steht 
im BootROM? Umschalten? Weiß nicht was Du meinst.

Sheeva P. schrieb:
> Dadurch können in modernen
> Windows-Systemen direkt Binaries aus den Repositories von Ubuntu-Linux
> heruntergeladen

Ich möchte da nur kurz unterbrechen. Was du als Linux bezeichnest, ist 
tatsächlich GNU/Linux oder - wie ich kürzlich angefangen habe es zu 
nennen - GNU plus Linux. Linux ist an sich kein Betriebssystem sondern 
eine weitere freie Komponente eines voll funktionierenden GNU Systems, 
das brauchbar gemacht wird durch die GNU-corelibs, shell-Werkzeuge und 
die grundlegenden Systemkomponenten, die ein vollständiges OS nach POSIX 
Definition ausmachen. Viele Computernutzer betreiben täglich eine 
modifizierte Version des GNU Systems ohne sich darüber im Klaren zu 
sein. Durch einen bestimmten Gang der Dinge wird die GNU Variante, die 
heute weit verbreitet ist, oft "Linux" genannt und vielen Nutzern ist 
nicht klar, dass es im Prinzip das GNU System ist, das vom GNU Projekt 
entwickelt wurde. Es gibt tatsächlich ein Linux und diese Leute benutzen 
es, aber es ist nur ein Teil des Systems das sie benutzen.
Linux ist der Kernel: das Programm im System, das die Ressourcen des 
Rechners für die anderen Programme, die laufen, allokiert. Der Kernel 
ist ein essentieller Teil eines Betriebssystems, aber alleine nutzlos; 
es kann im Kontext eines kompletten Betriebssystems funktionieren. Linux 
wird normalerweise in Kombination mit dem GNU Betriebssystem benutzt: 
das ganze System ist grundsätzlich GNU, dem Linux hinzugefügt wurde, 
oder GNU/Linux. Alle sogenannten "Linux" Distributionen sind tatsächlich 
Distributionen von GNU/Linux.

Felix U. schrieb:
> Sheeva P. schrieb:
>> Dadurch können in modernen
>> Windows-Systemen direkt Binaries aus den Repositories von Ubuntu-Linux
>> heruntergeladen
>
> Ich möchte da nur kurz unterbrechen. Was du als Linux bezeichnest, ist
> tatsächlich GNU/Linux oder - wie ich kürzlich angefangen habe es zu
> nennen - GNU plus Linux.

https://en.wikipedia.org/wiki/GNU_Hurd

Vielleicht kommen die Mikrokernel ja noch nun da die Leistung eines 
einzelnen Prozessorkerns am Limit ist. Stallman ist der Gesellschaft 
einfach sehr weit voraus.

https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate

Lars R. schrieb:
> Aber mir wirfst Du gleich wieder vor, ein Blinder zu sein der sich über
> Farben beschwert. Nur weil ich spontan statt 5Anschläge 8Anschläge
> gesagt hatte.

Nein, nicht deswegen. Sondern weil Du die ganze Zeit Unsinn erzählst, 
aus dem sich ein schlüssiges Gesamtbild ergibt: nämlich daß Du die 
Mächtigkeit moderner Kommandozeilen nicht kennst, warum auch immer nicht 
kennenlernen willst, und darum eben leider auch nicht beurteilen kannst.

> Dabei geht's Dir selbst nicht besser. Es sind eben einfach
> zu viele Tastenanschläge, die man in der bash für jede Kleinigkeit
> tätigen muss.

Da kannst Du nur für Dich sprechen: mag sein, daß es für Dich "zu viele" 
sind, obwohl ich nach Deinen bisherigen Diskussionsbeiträgen meine 
Zweifel habe, daß Du das beurteilen kannst. Aber eines, das kann 
jedenfalls ich beurteilen: daß es für mich eben nicht "zu viele" sind.

> Selber lustig. Deine bash (bzw samt KDE wenn Du mehrere startet) steht
> im BootROM?

Nö. Aber wenn meine Bash einmal gestartet ist, kann sie unendlich viel 
mehr als das popelige bisschen Dateimanagement, auf das Dein Explorer 
und Dein PacmanFM beschränkt sind.

> Umschalten? Weiß nicht was Du meinst.

Ja, den Eindruck habe ich auch. ;-)

Felix U. schrieb:
> Ich möchte da nur kurz unterbrechen. Was du als Linux bezeichnest, ist
> tatsächlich GNU/Linux

Ach Gottchen... ja, ich weiß, daß der heilige Sankt Ignucius und einige 
seiner Jünger es gerne sähen, wenn man GNU/Linux statt Linux sagte. Aber 
wenn ich mit diesem Scheiß anfange, kommen am Ende noch die 
Apache-Leute, die BSD-Leute, Matthias Kalle Dalheimer, Miguel de Icaza 
und was weiß ich wer sonst noch alles und wollen auch bitte erwähnt 
werden. Wenn ich dann bei jeder Erwähnung alle auflisten muß, die etwas 
zu den aktuellen Linux-Distributionen beigetragen haben, komme ich zu 
gar nichts mehr.

Bei allen ruhmreichen Verdiensten, die sich das GNU-Projekt erworben 
hat, sollte es froh und dankbar dafür sein, daß es Linux gibt. Tatsache 
ist nämlich auch, daß das GNU-Projekt erst dank und durch Linux eine 
breitere Akzeptanz und Verbreitung gefunden hat. Dessen eigener Kernel 
Hurd steckt ja schon seit einem Vierteljahrhundert in den Kinderschuhen 
und kann bis heute nichtmal praktisch benutzt werden, tatsächlich kann 
er bisher sogar nicht einmal 64Bit, IIRC.

> Alle sogenannten "Linux" Distributionen sind tatsächlich
> Distributionen von GNU/Linux.

Das mag vielleicht derzeit der Fall sein, ist aber nicht zwangsläufig 
so. Die GNU-Leute arbeiten immer noch an ihrem Hurd-Kernel, und bisher 
sind mir schon einige Versuche über den Weg gelaufen, ein GNU-Userland 
mit einem BSD- sowie ein BSD-Userland mit einem Linux-Kernel zu 
verheiraten.

Ansonsten gilt das, was ich hier gesagt habe, nicht nur für Linux, 
sondern auch für *BSD, Solaris, AIX und verschiedene andere UNIXiode, an 
und mit denen ich im Laufe der Zeit gearbeitet habe. Zu den Diskussionen 
über OSS im Allgemeinen und CLIs/GUIs im Besonderen trägt diese 
Klugscheißerei ja irgendwie so gar nichts bei, also halt bitte mal die 
Bälle flach. Danke.