Programmieren unter Linux - wo ist was ?
Holger Schauer
>>"AK" == Andreas Keese schrieb am Wed, 19 Nov 1997 10:00:59 +0100:
AK> Mein Problem ist, dass ich noch ueberhaupt keine strukturierte
AK> Hilfe zu Bibliotheksfunktionen gefunden habe. Ich kann natuerlich
AK> per man -k nach Funktionen suchen, wenn ich weiss, wonach ich
AK> suche, und dann kann ich per man in jede der entdeckten
AK> Funktionen hineinschauen (Stoehn, wieso gibts da keine
AK> Hyperlink-Funktionalitaet ?)
Haengt halt von Deinem Environment ab. Wenn Du eine
Standard-Linux-Distribution hast, dann ist hoffentlich eine
anstaendige Sammlung info-Dateien vorhanden, und ein Emacs.
Im Emacs gibt es dann die praktische C-h i Tastenkombination, und
hoffentlich findest Du da einige Dokumentation, mind. der
libc. Normalerweise sind auch noch mehr Sachen dabei, libgdbm bspw.
Die Man-Funktion (M-x man) laesst bzgl. apropos und Hyperlinks
zwischen Funktionen natuerlich auch keine Wuensche offen.
Holger
--
holger_schauer :-
mail_address("Holger....@gmd.de"),
project("BGP-MS/AVANTI, GMD Sankt Augustin, FIT.MMK"),
www_home_page("http://www.uni-koblenz.de/~schauer/index.html").
(^:= An ideal world is left as an exercise to the reader.
Jochen Hanff
Andreas Keese wrote:
> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
> Software entwickeln :-(
wieso leider ? ich habe sowohl mit vc++ und unix-werkzeugen soft
entwickelt und muß sagen : unix macht mehr spaß !!
>
> Mein Problem ist, dass ich noch ueberhaupt keine strukturierte Hilfe zu
> Bibliotheksfunktionen gefunden habe. Ich kann natuerlich per man -k nach
> Funktionen suchen, wenn ich weiss, wonach ich suche, und dann kann ich
> per man in jede der entdeckten Funktionen hineinschauen (Stoehn, wieso
> gibts da keine Hyperlink-Funktionalitaet ?)
ein gutes buch ist durch nichts zu ersetzen, z.b. 'programmierung in
der unix-umgebung' von w.r. stevens, addison-wesley.
>
> Ich habe aber vor allem das Problem, dass ich keinen Ueberblick darueber
> habe, was es ueberhaupt an Funktionen gibt. Das geht damit los, dass ich
> noch keine Uebersicht ueber die im System existierenden Bibliotheken
> entdeckt habe. Unter VisualC kann ich einfach in der Hilfe den Teilbaum
> mit den Win32-APIs aufklappen und hab sofort einen Ueberblick. Ich kann
> mir gar nicht vorstellen, dass es unter Unix nirgends eine derartige
> Uebersicht gibt.
in den man-pages steht das wichtigste. es gibt auch grafische frontends
wie tkman, ich persönlich benutze kdehelp oder die shell um manpages zu
lesen.
stay free
jochen
--
Jochen Hanff
mailto:joc...@ifb.bv.tu-berlin.de
http://ifb.bv.TU-Berlin.DE/JOCHEN/jochen.html
IfB Theoretische Methoden
http://ifb.bv.TU-Berlin.de
Andreas Keese
Hallo allerseits,
zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
Software entwickeln :-(
Mein Problem ist, dass ich noch ueberhaupt keine strukturierte Hilfe zu
Bibliotheksfunktionen gefunden habe. Ich kann natuerlich per man -k nach
Funktionen suchen, wenn ich weiss, wonach ich suche, und dann kann ich
per man in jede der entdeckten Funktionen hineinschauen (Stoehn, wieso
gibts da keine Hyperlink-Funktionalitaet ?)
Ich habe aber vor allem das Problem, dass ich keinen Ueberblick darueber
habe, was es ueberhaupt an Funktionen gibt. Das geht damit los, dass ich
noch keine Uebersicht ueber die im System existierenden Bibliotheken
entdeckt habe. Unter VisualC kann ich einfach in der Hilfe den Teilbaum
mit den Win32-APIs aufklappen und hab sofort einen Ueberblick. Ich kann
mir gar nicht vorstellen, dass es unter Unix nirgends eine derartige
Uebersicht gibt.
Dann kommt das naechste Problem: Wenn man nicht weiss, welche
Bibliotheken da sind, kann man nicht nach Funktionen suchen... Staendig
mit grep auf das Include-Verzeichnis zu gehen, ist was fuer Masochisten.
Also, gebt mir doch mal ein paar Tips dazu, wie ich Hilfe zum
Programmieren erhalte. Gibt es vielleicht ein schoenes Hypertext-System,
in dem alle Unix-Bibliotheken und enthaltene Funktionen erlaeutert
werden ?
Tschuess,
Andreas
Oliver Rebach
In article <3472AACA...@tu-bs.de>, Andreas Keese <A.K...@tu-bs.de> writes:
|> Hallo allerseits,
|>
|> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
|> angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
|> Software entwickeln :-(
Kopf hoch. Beim ersten Mal tut's etwas weh. Danach macht es dann
nur noch Spaß ;-)
|>
|> Mein Problem ist, dass ich noch ueberhaupt keine strukturierte Hilfe zu
|> Bibliotheksfunktionen gefunden habe. Ich kann natuerlich per man -k nach
|> Funktionen suchen, wenn ich weiss, wonach ich suche, und dann kann ich
|> per man in jede der entdeckten Funktionen hineinschauen (Stoehn, wieso
|> gibts da keine Hyperlink-Funktionalitaet ?)
Nun ja, Unix gibt es schon etwas länger als Hypertext. Bei Bedarf
kannst Du
- einem Web-Server (sagte das jemand Apache?) laufen lassen, und Dir
die Manuals Online in HTML wandeln lassen (weiß den Namen des
Pakets aber nicht)
- tkman benutzen.
|> Ich habe aber vor allem das Problem, dass ich keinen Ueberblick darueber
|> habe, was es ueberhaupt an Funktionen gibt. Das geht damit los, dass ich
|> noch keine Uebersicht ueber die im System existierenden Bibliotheken
|> entdeckt habe. Unter VisualC kann ich einfach in der Hilfe den Teilbaum
|> mit den Win32-APIs aufklappen und hab sofort einen Ueberblick. Ich kann
|> mir gar nicht vorstellen, dass es unter Unix nirgends eine derartige
|> Uebersicht gibt.
Was in Deinem System existiert, hängt von Deinem System ab ;^).
Pflicht sind libc und libm, die alle Standard-C-Funktionen und einige
Erweiterungen enthalten. Vermutlich hast Du noch libX, libXt und
einige dutzende weitere. Es hängt sehr davon ab, was Du machen willst.
|>
|> Dann kommt das naechste Problem: Wenn man nicht weiss, welche
|> Bibliotheken da sind, kann man nicht nach Funktionen suchen... Staendig
|> mit grep auf das Include-Verzeichnis zu gehen, ist was fuer Masochisten.
Ich nehme mal an, die Standard-C-Sachen kennst Du. Wenn Du etwas
spezielles brauchst, hast Du dafür auch die Doku (hoffentlich).
Bleibt die Sache mit der GUI. Hier würde ich Dir dringend empfehlen,
einen modernen High-Level-Toolkit wie Tcl/Tk oder Qt zu benutzen.
(Wenn Du nicht die Wahl hast - was mußt Du denn nehmen). Wenn
Du Motif benutzen mußt, sag Deinem Chef, er möge Dir einen
gescheiten GUI-Builder kaufen. Es lohnt sich auch für Ihn,
schließlich muß er Deine Arbeitszeit bezahlen. Ansonsten nimm
etwas besseres. Motif ohne GUI-Builder ist ein Job für Leute,
die Vater und Mutter erschlagen haben. Das ist in der
Produktivitätsskala gleich hinter purem Assembler - zumindest
wenn eine Komplexität angestrebt wird, die etwas über
"Hello World" liegt.
|> Also, gebt mir doch mal ein paar Tips dazu, wie ich Hilfe zum
|> Programmieren erhalte. Gibt es vielleicht ein schoenes Hypertext-System,
|> in dem alle Unix-Bibliotheken und enthaltene Funktionen erlaeutert
|> werden ?
Besorg Dir ein paar Bücher zu den Bibiotheken, die Du brauchst.
O'Reilly hat alles Gute da - allerdings nicht immer auf deutsch.
Auch von Addison-Wesley gibt es ein paar gute Bücher.
|> Tschuess,
|> Andreas
|>
Ebenfalls tschüß
Oliver
--
O. Rebach <Oliver...@UniBw-Hamburg.DE> /|\ /|\
Universitaet der Bundeswehr Hamburg, FB Maschinenbau / | \/ |
Fachgebiet Maschinenelemente und Getriebetechnik |--| | ~|
- Labor fuer Datenverarbeitung in der Konstruktion - | | /
Joachim Zobel
Andreas Keese <A.K...@tu-bs.de> wrote:
>Ich habe aber vor allem das Problem, dass ich keinen Ueberblick darueber
>habe, was es ueberhaupt an Funktionen gibt. Das geht damit los, dass ich
>noch keine Uebersicht ueber die im System existierenden Bibliotheken
>entdeckt habe. Unter VisualC kann ich einfach in der Hilfe den Teilbaum
>mit den Win32-APIs aufklappen und hab sofort einen Ueberblick. Ich kann
>mir gar nicht vorstellen, dass es unter Unix nirgends eine derartige
>Uebersicht gibt.
Unter Linux gibt es das meines Wissens nicht.
[...]
>Also, gebt mir doch mal ein paar Tips dazu, wie ich Hilfe zum
>Programmieren erhalte. Gibt es vielleicht ein schoenes Hypertext-System,
>in dem alle Unix-Bibliotheken und enthaltene Funktionen erlaeutert
>werden ?
Du kannst sowas selber basteln. Du brauchst einen Webserver (z.B.
apache), man2html o.ae., info2www und dann musst du eine Suchmaschine
konfigurieren.
Ich bin gerade dabei, htdig zu installieren und hoffe, demnächst eine
durchsuchbare Dokumentation zu haben. Im Moment hab' ich erstmal
Volltextsuche ueber die Manpages (per ISearch [1]), das ist schon ein
grosser Fortschritt.
Irgendwo da draussen hab' ich auch schon mal eine
Linuxdokumentationssuchmaschine gesehen. Aber man will ja nicht für
jede Funktion, die man sucht, anrufen.
[1] ISearch hat Nachteile, z.B. muss die html-Seite als File vorhanden
sein.
Joachim
Send email replies to us...@kud.com
where user = jzobel.
Wolfram Gloger
Michael Hoennig <mhoe...@on-line.de> writes:
> ... und der gdb auf Intel kann nichtmal Hardware-
> unterst=FCtzte Watchpoints.
Das stimmt schon seit ueber zwei Jahren nicht mehr.
> Und langsam ist das Debuggen auch
> ohne Watchpoints: das Update von display-Variablen,
> Source-Anzeige/Disasemblierung (insbes. unter z.B. ddd)
> lassen das Sytem manchmal minutenlang geradezu stehen.
Zu ddd kann ich nicht viel sagen, aber gdb an sich oder im
Emacs-gud-mode ist mit Sicherheit _nicht_ langsam.
MfG
Wolfram.
Andreas Keese
Sascha Bohnenkamp wrote:
> |> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> |> angeht - von Visual-C verwoehnt bin.
> tja ist schon uebel, wenn man mit einem derart miesen compiler gearbeitet hat.
> (was ist das Gegenteil von Optimierung? Visual-C++ ;) )
Tolles Argument - die Optimierung ist fuer Feld-Wald- und Wiesen-Anwendungen voellig
irrelevant. Wichtig ist hier die Entwicklungsumgebung, die Kompilierzeiten, die
Einbindung der Hilfe, die Integration des Editors, kurz: alles, was das Entwickeln
vereinfacht. Was soll ich mit einem super-optimierenden Compiler, wenn ich mit dem
20% mehr Zeit benoetige, um meine Software zu erstellen ? Optimierung wird natuerlich
sehr wichtig, wenn man wissenschaftliche Software schreiben will, aber das wuerde ja
eh kein Mensch unter Windows tun...
> |> Leider muss ich jetzt unter Unix
> |> Software entwickeln :-(
> Nicht Leider, zum Glueck!
Du musst zugeben, dass Unix sehr viel haerter zu bedienen ist als andere
Betriebssysteme. Und die Entwicklungsumgebungen haben meist gar keinen Komfort. Wenn
man Komfort will, muss man erstmal eine Woche investieren, um Emacs-Lisp zu lernen
und zu lernen, wie man sich den Emacs hinkonfiguriert. Selbst die
Entwicklungsumgebungen, die SGI mitliefert (z.B. CosmoCreate) sind imho ineffizienter
als Borland oder MS-Umgebungen. Das einzige Entwicklerwerkzug, das mir unter Unix
bisher einigermassen gefaellt (abgesehen vom Emacs) ist der Totalview-Debugger von
Cray.
> Seit wann hat die Online-Doku eigentlich etwas mit den mitgelieferten Bibliotheken
> zu tun? Gerade bzgl. MSVC ist da einiges in 3 Versionen vorhanden
> (gelieferte Bibliothek, gedruckte Doku, Online-Doku)
Die Qualitaet der Online-Doku hat allergroessten Einfluss auf meine
Entwicklungsgeschwindigkeit. Ich will doch nicht in Buechern wuehlen, wenn ich in
fremden Quelltexten irgendeine unbekannte Funktion oder Datenstruktur entdecke.
> |Das ist doch Spielkram ... oder hast du ein 40" Bildschirm?
Ich finde Buecher als Referenz unbrauchbar. Zum lernen sind Buecher prima, aber doch
nicht als Referenz. Da ist man doch nur mit blaettern beschaeftigt. Uebrigens ist die
Hilfe bei VisualC so gut in die Umgebung integriert, dass man mit einem 17"-Monitor
sehr gut arbeiten kann.
Tschuess,
Andreas
Michael Hoennig
Hallo Sascha,
> |> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren=
> |> angeht - von Visual-C verwoehnt bin.=20
> tja ist schon uebel, wenn man mit einem derart miesen compiler=20
gearbeitet hat.
> (was ist das Gegenteil von Optimierung? Visual-C++ ;) )
nun werd' mal nicht polemisch! Der Visual C++ erzeugt mindestens
genausogut optimierten Code wie der g++ und von allen uns bei=20
Star Division bekannten Compilern damit den besten Code =FCberhaupt.=20=
Bei vielen Compilern, derzeit inkl. dem G++ (*) m=FCssen wir die=20
Optimierung sogar aufgrund von Code-Generierungs-Fehlern abschalten.=20=
#I.d.R. grenzen wir das Problem zwar ein und bauen den Quell-Code=20
entsprechend um oder schalten die Optimierung nur in den betroffenen=20=
Files aus, wenn man aber mehrere Millionen Zeilen C++ Quellcode auf=20
20 verschiedenen Compilern =FCbersetzen mu=DF, dann kann man sich nunmal=
=20
nicht um alle Details auf einmal k=FCmmern.
(*) Ich mu=DF nat=FCrlich zugeben, da=DF auch der Visual C++ seine Bugs=
hat. Die - da NT Hauptentwicklungsplattform ist - wir schon beim
Codieren umschiffen. Nur ist leider selbst von den sporadischen
Fehlern abgesehen, der Code trotzdem besser als der vom
g++/gcc erzeugte. Bei reinem C mag das ja vielleicht anders
sein, bei C++ leider nicht.
Solange die UNIXer mit Scheuklappen immer nur behaupten, da=DF
UNIX das bessere System zum Software-Entwickeln w=E4re, wird
sich wohl auch nichts daran =E4ndern, da=DF Kleinweich sich ins
F=E4ustchen lacht. Denn deren Entwicklungsumgebung ist mittlerweile
verdammt gut geworden.=20
Das gilt erst recht f=FCr die Entwickler, die wir UNIXer f=FCr
UNIX begeistern wollen. Wir k=F6nnen nicht einfach sagen:
=84Den ganzen Schnickschnak hast Du nicht mehr, daf=FCr diese
tausend tollen Einzeltools.=93 Das Konzept ist zwar genial,
aber der andere hat auch seine Vorteile. Und Gewohnheit
beeinflu=DFt die Meinung jedes Menschen mehr als alles andere.
> |> Leider muss ich jetzt unter Unix
> |> Software entwickeln :-(
> Nicht Leider, zum Glueck!
Das kommt ganz auf das UNIX an. Unter Solaris z.B. hat man
eine ziemlich gute Umgebung, inkl. online-Hilfe, Debugger,
Profiler etc. pp. Auf einem Intel-Linux, dagegen gibt es=20
meines Wissens nach nur den ziemlich schwachbr=FCstigen
GNU Profiler und der gdb auf Intel kann nichtmal Hardware-
unterst=FCtzte Watchpoints. Und langsam ist das Debuggen auch
ohne Watchpoints: das Update von display-Variablen,
Source-Anzeige/Disasemblierung (insbes. unter z.B. ddd)
lassen das Sytem manchmal minutenlang geradezu stehen.
Mit dem MS-Developer-Studio-Debugger hab ich das noch
nicht erlebt.
> zu tun? Gerade bzgl. MSVC ist da einiges in 3 Versionen vorhanden=20
> (gelieferte Bibliothek, gedruckte Doku, Online-Doku)
Up-To-Date ist die MS-Doku schon, nur manchmal etwas=20
oberfl=E4chlich. Und dann gibt es leider immer noch die
undefnierten Funktionen, ohne die man gewisse Sachen
so gut wie gar nicht hingekommt. Hier mu=DF ich also=20
zumindest teilweise zustimmen.
> Ueber die Win32-API findest du etwas, aber ueber 'alle' installierten=
> Bibliotheken (dll's)? Das will ich sehen ... *hihi*
hihihi, das stimmt. Aber viele brauchen kaum mehr!
> |> Programmieren erhalte. Gibt es vielleicht ein=20
> |> schoenes Hypertext-System,
> |> in dem alle Unix-Bibliotheken und enthaltene=20
> |> Funktionen erlaeutert
> |> werden ?
> Das ist doch Spielkram ... oder hast du ein 40" Bildschirm?
F=FCr denjenigen, der daran gew=F6hnt ist, ist das eben kein
Spielkram, sondern n=FCtzlich. Kleinweich ist nicht zuletzt
deshalb so erfolgreich, weil sie es Entwicklern so leicht
machen!
Bye,=20
Michael
P.S. Wer jetzt glaubt, ich sei mit Kleinweich verheiratet:
http://www.geocities.com/SiliconValley/Bay/7117/=20
Gunnar Beushausen
Holger Eitzenberger wrote:
> Die Hilfe zum Developer Studio ist seehhr gut, ausserdem wird man
> durch fundierte Beispielprogramme regelrecht erschlagen, trotzdem findet
> immer sofort das, was man gerade an Beispielprogrammen sucht. Und wenn
> dir noch Doku oder Beispielprogramme fehlt kriegst Du (gegen Bar)
> vierteljährlich mehrere CD´s (MSDN Level 2). Mehr geht wirklich net.
>
> So schlecht das Betriebssystem Win95 auch ist, in manchen Dingen seht
> ihr alles nur durch die Anti-M$-Brille. Mehr Objektivität tut not. :)
Sehr schön. Aber wie kann ich damit Linux Programme schreiben?
--
---
Gunnar Beushausen
Gun...@hof.de
http://www.hof.de/~gbasic
Holger Eitzenberger
Ich kenne Visual C++ und hacke auch unter Unix, aber...
Sascha Bohnenkamp wrote:
>
> tja ist schon uebel, wenn man mit einem derart miesen compiler gearbeitet hat.
> (was ist das Gegenteil von Optimierung? Visual-C++ ;) )
>
Stimmt nicht. Der Visual C++ Compiler optimiert recht gut, wird aber
glaub´ ich vom Watcomm C++ Compiler geschlagen. Als
Entwicklungsumgebung gelten MS Developer Studio und die IBM Produkte als
Maß der Dinge.
> |> Mein Problem ist, dass ich noch ueberhaupt keine strukturierte Hilfe zu
> |> Bibliotheksfunktionen gefunden habe. Ich kann natuerlich per man -k nach
> |> Funktionen suchen, wenn ich weiss, wonach ich suche, und dann kann ich
> |> per man in jede der entdeckten Funktionen hineinschauen (Stoehn, wieso
> |> gibts da keine Hyperlink-Funktionalitaet ?)
> Warum kaufst Du Dir kein Buch?
> Stevens Advanced Programming in the UNIX Environment
> und
> Stevens Network Programming
> sind SEHR zu empfehlen.
Die Hilfe zum Developer Studio ist seehhr gut, ausserdem wird man
durch fundierte Beispielprogramme regelrecht erschlagen, trotzdem findet
immer sofort das, was man gerade an Beispielprogrammen sucht. Und wenn
dir noch Doku oder Beispielprogramme fehlt kriegst Du (gegen Bar)
vierteljährlich mehrere CD´s (MSDN Level 2). Mehr geht wirklich net.
So schlecht das Betriebssystem Win95 auch ist, in manchen Dingen seht
ihr alles nur durch die Anti-M$-Brille. Mehr Objektivität tut not. :)
Holger
--
PGP-key via email or finger ei...@jonathan.weh.rwth-aachen.de
Oliver Bandel
Andreas Keese <A.K...@tu-bs.de> wrote:
> Hallo allerseits,
> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
> Software entwickeln :-(
tse tse tse... was ist das denn für ein Schwachsinn?
Versuchs mal mit dem Komando "apropos".
Das gibt Dir den Überblick.
Es gibt auch noch weitere Tools, aber eigentlich ist man mit apropos schon
sehr gut bedient. Dann weiß man, wo man schauen sollte.
Als Argumente von Apropos gibst Du dann Befehlsnamen, oder Themnen ein.
Z.B. "apropos news".
Tschüß,
Oliver
--
Oliver Bandel
Sascha Bohnenkamp <bon...@informatik.uni-bremen.de> wrote:
> In article <3472AACA...@tu-bs.de>, Andreas Keese <A.K...@tu-bs.de> writes:
> |> Also, gebt mir doch mal ein paar Tips dazu, wie ich Hilfe zum
> |> in dem alle Unix-Bibliotheken und enthaltene Funktionen erlaeutert
> |> werden ?
> Das ist doch Spielkram ... oder hast du ein 40" Bildschirm?
:-)
Der war gut!
Tschüß,
Oliver
--
Michael Hoennig
Wolfram Gloger wrote:
>
> > ... und der gdb auf Intel kann nichtmal Hardware-
> > unterst=FCtzte Watchpoints.
>
Integer-Variable mehrere Tage, während das mit dem
Debugger von MS unter NT schon nach Sekunden zuschlägt?
Vielleicht mach ich ja was falsch...
> > Und langsam ist das Debuggen auch
> > ohne Watchpoints: das Update von display-Variablen,
> > Source-Anzeige/Disasemblierung (insbes. unter z.B. ddd)
> > lassen das Sytem manchmal minutenlang geradezu stehen.
>
> Zu ddd kann ich nicht viel sagen, aber gdb an sich oder im
> Emacs-gud-mode ist mit Sicherheit _nicht_ langsam.
Auch der gdb direkt braucht manchmal mehrere Minuten auf
einem Penti 200 mit 128 MB RAM, um die o.g. Aktionen
durchzuführen. Vielleicht mach ich ja auch dort was falsch...
Bye,
Michael
Sascha Bohnenkamp
In article <19971121...@mi-1114.stardiv.de>, Michael Hoennig <mhoe...@on-line.de> writes:
Moin
|> > |> Leider muss ich jetzt unter Unix
|> > |> Software entwickeln :-(
|> > Nicht Leider, zum Glueck!
|> Das kommt ganz auf das UNIX an. Unter Solaris z.B. hat man
|> eine ziemlich gute Umgebung, inkl. online-Hilfe, Debugger,
|> Profiler etc. pp. Auf einem Intel-Linux, dagegen gibt es=20
|> meines Wissens nach nur den ziemlich schwachbr=FCstigen
|> GNU Profiler und der gdb auf Intel kann nichtmal Hardware-
|> unterst=FCtzte Watchpoints. Und langsam ist das Debuggen auch
|> ohne Watchpoints: das Update von display-Variablen,
|> Source-Anzeige/Disasemblierung (insbes. unter z.B. ddd)
|> lassen das Sytem manchmal minutenlang geradezu stehen.
|> Mit dem MS-Developer-Studio-Debugger hab ich das noch
|> nicht erlebt.
Der gcc ist nicht kommerziell, wenn du 'teure' Tools haben willst,
dann kauf doch auch teure Software ... d.h. es gibt auch kommerzielle
Systeme fuer Linux.
|> > zu tun? Gerade bzgl. MSVC ist da einiges in 3 Versionen vorhanden=20
|> > (gelieferte Bibliothek, gedruckte Doku, Online-Doku)
|> Up-To-Date ist die MS-Doku schon, nur manchmal etwas=20
|> oberfl=E4chlich. Und dann gibt es leider immer noch die
|> undefnierten Funktionen, ohne die man gewisse Sachen
|> so gut wie gar nicht hingekommt. Hier mu=DF ich also=20
|> zumindest teilweise zustimmen.
Also gerade bei der MSVC gibt es sehr lustige Sachen,
z.B. werden manche Objekte laut Online-Doku als Referenz verarbeitet,
laut gedruckter Doku als Const-Variable und laut Implementierung als Pointer
-- lustig nicht !?
|> > |> Programmieren erhalte. Gibt es vielleicht ein=20
|> > |> schoenes Hypertext-System,
|> > |> in dem alle Unix-Bibliotheken und enthaltene=20
|> > |> Funktionen erlaeutert
|> > |> werden ?
|> > Das ist doch Spielkram ... oder hast du ein 40" Bildschirm?
|> F=FCr denjenigen, der daran gew=F6hnt ist, ist das eben kein
|> Spielkram, sondern n=FCtzlich. Kleinweich ist nicht zuletzt
|> deshalb so erfolgreich, weil sie es Entwicklern so leicht
|> machen!
Ich denke eher, weil die Leute so dumm sind immer das 'billigste'
zu kaufen, abgesehen davon, dass genau diese 'Leute' sich so
einfach Software besorgen koennen ('ein Bekannter von mir hat auch
Ms-Burbware ... soll er dir eine Kopie machen?')
Sascha Bohnenkamp
In article <347593C4...@tu-bs.de>, Andreas Keese <A.K...@tu-bs.de> writes:
|> Sascha Bohnenkamp wrote:
|>
|> > |> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
|> > |> angeht - von Visual-C verwoehnt bin.
|> > (was ist das Gegenteil von Optimierung? Visual-C++ ;) )
|>
|> irrelevant. Wichtig ist hier die Entwicklungsumgebung, die Kompilierzeiten, die
|> Einbindung der Hilfe, die Integration des Editors, kurz: alles, was das Entwickeln
|> vereinfacht. Was soll ich mit einem super-optimierenden Compiler, wenn ich mit dem
|> 20% mehr Zeit benoetige, um meine Software zu erstellen ? Optimierung wird natuerlich
|> sehr wichtig, wenn man wissenschaftliche Software schreiben will, aber das wuerde ja
|> eh kein Mensch unter Windows tun...
zum Watcom ..
|> Du musst zugeben, dass Unix sehr viel haerter zu bedienen ist als andere
|> Betriebssysteme.
und manchmal reicht ja auch STRG-ALT-ENTF ...
|> Und die Entwicklungsumgebungen haben meist gar keinen Komfort. Wenn
|> man Komfort will, muss man erstmal eine Woche investieren, um Emacs-Lisp zu lernen
|> und zu lernen, wie man sich den Emacs hinkonfiguriert. Selbst die
|> Entwicklungsumgebungen, die SGI mitliefert (z.B. CosmoCreate) sind imho ineffizienter
|> als Borland oder MS-Umgebungen. Das einzige Entwicklerwerkzug, das mir unter Unix
|> bisher einigermassen gefaellt (abgesehen vom Emacs) ist der Totalview-Debugger von
|> Cray.
Ich persoenlich bevorzuge eine stabile Entwicklungsumgebung ... und sag jetz nicht das waere
bei irgendeinem MS-* Produkt der Fall, dafuer habe ich schon zu viele BSODs gesehen.
|> > Seit wann hat die Online-Doku eigentlich etwas mit den mitgelieferten Bibliotheken
|> > zu tun? Gerade bzgl. MSVC ist da einiges in 3 Versionen vorhanden
|> > (gelieferte Bibliothek, gedruckte Doku, Online-Doku)
|>
|> Die Qualitaet der Online-Doku hat allergroessten Einfluss auf meine
|> Entwicklungsgeschwindigkeit. Ich will doch nicht in Buechern wuehlen, wenn ich in
|> fremden Quelltexten irgendeine unbekannte Funktion oder Datenstruktur entdecke.
eben und die Doku von MS ist haeufig um einiges schlaechter als einfach Man.Pages
|> Ich finde Buecher als Referenz unbrauchbar. Zum lernen sind Buecher prima, aber doch
|> nicht als Referenz. Da ist man doch nur mit blaettern beschaeftigt. Uebrigens ist die
|> Hilfe bei VisualC so gut in die Umgebung integriert, dass man mit einem 17"-Monitor
|> sehr gut arbeiten kann.
Das mit den Buechern ist wohl geschmackssache ... abgesehen davon das lesen in Buechern
gesuender ist ...
Andreas Keese
Oliver Bandel wrote:
> > zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> > angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
> > Software entwickeln :-(
> tse tse tse... was ist das denn für ein Schwachsinn?
Hmm, ich glaube, Du hast meine Mail nicht gelesen.
> Versuchs mal mit dem Komando "apropos".
Toll, genau diese Philosophie stoert mich an Unix. Man muss man sich quaelen,
darf keine komfortablen Umgebungen benutzen, denn das waere ja uncool und
ueberhaupt zu Microsoft-artig. Wer nicht mindestens tausend
.xxxx-Konfigurationssprachen und zweitausend Kommandoparameter lernen will,
sollte gleich bei Windows bleiben. Ohnehin ist ja Microsoft deshalb gross,
weil sie boese sind, und sie sind boese, weil sie gross sind, und daher
redet jeder, der ein Produkt von denen mag, Schwachsinn... Logisch.
Unter Unix artet jede noch so kleine Aufgabe gleich in Riesenaufwand aus -
letztens hab ich mir ein Makefile geschrieben - und dafuer reicht es
natuerlich nicht, erstmal diese komische Make-Sprache zu lernen - nein, um
das anstaendig zu machen, muss man auch gleich noch sed lernen :-( Das dauert
mir alles zu lange. Unter VisualC kann ich einfach die Dateien ins Projekt
ziehen und kompilieren.
> Das gibt Dir den Überblick.
Vielleicht solltest Du Mails nicht nach dem ersten Absatz beantworten,
sondern weiter lesen ?
Sorry, wenn sich mein Text etwas veraergert anhoert - aber seit ich mich mit
Unix beschaeftige, habe ich den Eindruck, dass sich einige Unix-Apostel etwas
erhaben fuehlen, weil sie in der Lage sind, mit tausend kryptischen
Konfigurationsdateien und Kommandozeilenparametern umzugehen und nicht noetig
haben, mit neumodischem Bloedsinn wie Maus und Fenstern umgehen zu muessen.
Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort Microsoft
faellt, sollte man sich mal Gedanken darueber machen, warum deren Produkte
erfolgreicher sind als Unix. In der Unix-Welt scheint der Glaube
vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
Unix-Apostel die Weisheit gefressen haben ?
Tschuess,
Andreas
Bernd Gehrmann
Andreas Keese <A.K...@tu-bs.de> writes:
> erfolgreicher sind als Unix. In der Unix-Welt scheint der Glaube
> vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
> Unix-Apostel die Weisheit gefressen haben ?
Durchaus nicht - es gibt ja einige Projekte, die versuchen, Unix auch
für den Nicht-Programmierer zugänglich zu machen. Allerdings schreien
in den Linux-Gruppen wie de.comp.os.linux.misc die am lautesten, denen
es gar nicht um die Behebung von technischen Problemen oder um sachliche
Diskussion geht, sondern nur darum, ihre Anti-Microsoft-Ideologie
herauszuposaunen. Folgerichtig müssen solche Leute natürlich nach dem
Motto "Daraus schloß er messerscharf, daß nicht sein kann, was nicht
sein darf" jeden noch so abstrusen Aspekt von Unix als genialen
Geistesblitz verkaufen.
Bernd.
Jens Dittmar
>>>>> Andreas Keese kritisiert:
AK> Toll, genau diese Philosophie stoert mich an Unix. Man muss man
AK> sich quaelen, darf keine komfortablen Umgebungen benutzen,
Du darfst! Den Begriff "komfortabel" sollten wir mal weglassen, da
versteht jeder was anderes drunter.
AK> Unter Unix artet jede noch so kleine Aufgabe gleich in
AK> Riesenaufwand aus
Das Gefuehl hatte ich immer unter Windows. Unter Unix geht mir alles
leichter von der Hand. Und wenn ich Windows-Usern zusehe, denk ich mir oft
nach dem zwanzigsten Mausklick: "Unter Unix waere ich schon lange fertig."
AK> - letztens hab ich mir ein Makefile geschrieben
AK> - und dafuer reicht es natuerlich nicht, erstmal diese komische
AK> Make-Sprache zu lernen -
?
AK> nein, um das anstaendig zu machen, muss
AK> man auch gleich noch sed lernen :-(
??????????????????????????????????????????????????????????????????????
AK> Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort
AK> Microsoft faellt, sollte man sich mal Gedanken darueber machen,
AK> warum deren Produkte erfolgreicher sind als Unix.
Schon tausendmal durchgekaut. Wobei man zwischen Entwicklern und Usern
unterscheiden muss. Die Motivation ist sehr unterschiedlich.
AK> In der Unix-Welt
AK> scheint der Glaube vorzuherrschen, dass die Mehrheit der Menschen
AK> schwachsinnig sei
Da meine Meinung zu diesem Thema nichts mit Software zu tun hat, werde ich
sie hier nicht breittreten.
Jens
uwolf
In article <m2sosm7...@dittmar.pci.uni-leipzig.de>,
dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar) wrote:
>>>>>> Andreas Keese kritisiert:
>AK> Toll, genau diese Philosophie stoert mich an Unix. Man muss man
>AK> sich quaelen, darf keine komfortablen Umgebungen benutzen,
> Du darfst! Den Begriff "komfortabel" sollten wir mal weglassen, da
>versteht jeder was anderes drunter.
Projekte)).
>AK> Unter Unix artet jede noch so kleine Aufgabe gleich in
>AK> Riesenaufwand aus
> Das Gefuehl hatte ich immer unter Windows. Unter Unix geht mir alles
>leichter von der Hand. Und wenn ich Windows-Usern zusehe, denk ich mir oft
>nach dem zwanzigsten Mausklick: "Unter Unix waere ich schon lange fertig."
Ich kenne beides. Windows ist einfacher, was im wesentlichen daran liegt,
dass es "gute" und komfortable Entwicklungsumgebungen gibt, die schablonen
artig sehr schnelles Entwicklen einer Windowsapplikation erlauben.
Einen Prototype habe ich da in ein paar Minuten zusammengeklickt.
Sowas fehlt meines Erachtens noch unter Unix/Linux.
Die oben angesprochenen Entwicklungsumgebungen unterstuetzten C/C++, jedoch
nicht X.
>
>AK> - letztens hab ich mir ein Makefile geschrieben
>AK> - und dafuer reicht es natuerlich nicht, erstmal diese komische
>AK> Make-Sprache zu lernen -
> ?
Naja, die Umgebungen unter Windows brauchen sowas nicht bzw. bauen ein
Makefile selbst. Da muss man nichts lernen ;-)
Funktioniert sogar.
>AK> In der Unix-Welt
>AK> scheint der Glaube vorzuherrschen, dass die Mehrheit der Menschen
>AK> schwachsinnig sei
> Da meine Meinung zu diesem Thema nichts mit Software zu tun hat, werde ich
>sie hier nicht breittreten.
;-)
Gruss
Uwe
Michael Hoennig
Moin Moin,
> Der gcc ist nicht kommerziell, wenn du 'teure' Tools haben willst,
> dann kauf doch auch teure Software ... d.h. es gibt auch kommerzielle=
> Systeme fuer Linux.
Darum geht es gar nicht, sondern es geht darum, da=DF immer
behauptet wird, da=DF Microsoft nur schlechte Sachen macht.
Und das stimmt eben nicht! Diese Meinung kommt nur durch die
Ha=DF-Brille MS gegen=FCber. Ob mir das gef=E4llt oder nicht,
ist ein ganz anderes Ding (mir gef=E4llt es nicht). Irgendwann
kommt das gro=DFe Erwachen und Microsoft rules the world!
Und den einzigen mir bekannten kommerziellen C++ Compiler
werden wir demn=E4cht auch mal unter die Lupe nehmen. Und ob
der besser ist als der gcc (g++) glaube ich trotz allem erst,
wenn ichs gesehen habe.
> Also gerade bei der MSVC gibt es sehr lustige Sachen,
> z.B. werden manche Objekte laut Online-Doku als Referenz verarbeitet,=
> laut gedruckter Doku als Const-Variable und laut Implementierung als=20=
Pointer
> -- lustig nicht !?
Mag ja sein, wir verwenden hier kein MFC, sondern VCL
(StarView-Nachfolger). Oder hat schonmal jemand einen
Linux Port von MFC gesehen (hihihi).
Alle die Sascha Bohnenkamps Meinung sind, sollten
sich dar=FCber klar werden, da=DF sie mit dieser Einstellung
nur alle Umstiegswilligen in die Arme von Microsoft
zur=FCcktreiben.
Bye,
Michael
Wolfram Gloger
Michael Hoennig <mhoe...@on-line.de> writes:
> Wolfram Gloger wrote:
> >
> > > ... und der gdb auf Intel kann nichtmal Hardware-
> > > unterst=FCtzte Watchpoints.
> >
> > Das stimmt schon seit ueber zwei Jahren nicht mehr.
> und warum braucht der 4.16 dann für ein Watch auf eine
> Integer-Variable mehrere Tage, während das mit dem
> Debugger von MS unter NT schon nach Sekunden zuschlägt?
Mit was fuer einer Applikation ? Mehrere Tage !? Ich vermute, da
swapped sich irgendetwas zu Tode, entweder hat die Applikation oder
gdb ein memory leak. Was sagt `ps -m' ?
Aber Spekulation beiseite, an fehlenden Hardware Watchpoints kann es
jedenfalls auf keinen Fall liegen (use the source,
gdb/config/i386/nm-linux.h):
----
/* Linux supports the 386 hardware debugging registers. */
#define TARGET_HAS_HARDWARE_WATCHPOINTS
#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
----
> Auch der gdb direkt braucht manchmal mehrere Minuten auf
> einem Penti 200 mit 128 MB RAM, um die o.g. Aktionen
> durchzuführen. Vielleicht mach ich ja auch dort was falsch...
Ich habe nur einen P100 mit ganzen 48MB, aber laenger als Sekunden
habe ich noch auf keine gdb-Ausgabe gewartet (auch mit groesseren
X-Applikationen).
MfG
Wolfram.
Jens Dittmar
>>>>> uwolf erklaert:
u> In article <m2sosm7...@dittmar.pci.uni-leipzig.de>,
AK> Riesenaufwand aus
>> Das Gefuehl hatte ich immer unter Windows. Unter Unix geht mir
>> alles leichter von der Hand. Und wenn ich Windows-Usern zusehe,
>> denk ich mir oft nach dem zwanzigsten Mausklick: "Unter Unix waere
>> ich schon lange fertig."
u> liegt, dass es "gute" und komfortable Entwicklungsumgebungen gibt,
u> die schablonen artig sehr schnelles Entwicklen einer
u> Windowsapplikation erlauben. Einen Prototype habe ich da in ein
u> paar Minuten zusammengeklickt.
Ich hab' den Eindruck, dass ich mit Windows besser zurechtkomme, als die
meisten Win-User, die mir bisher begegnet sind, aber Unix empfinde ich als
intuitiver, durchschaubarer usw. - insgesamt einfacher zu bedienen (OS/2
uebrigens auch).
Aber wir sind ja beim Entwickeln. Ich habe vor ein paar Jahren mal mit
BorlandC (3.1 glaube ich) unter DOS5.0 und Win3.1 hantiert. DOS ging gut,
die Windows-Version hab' ich irgendwann frustriert weggeschmissen, weil:
a) die IDE war nicht besonders praktisch
b) das Win-API ist ziemlich konfus
c) Debugging muendete immer in die Frage: Warmstart oder Kaltstart?
Aus dem "Wunsch" heraus, fuer jemanden etwas zu basteln, was unter
Windows3.1 laeuft, habe ich Borland Pascal und Visual Basic
ausprobiert. Ersteres sah ganz gut aus, war leider fehlerhaft
installiert. Mit VB hab' ich gar nix hingekriegt. Ich werde mir das Pascal
noch mal ansehen, wenn das nicht klappt, nehm ich Tcl.
Um die beiden Aspekte der Rechnernutzung zusammenzufassen: Freiwillig fass
ich kein Windows mehr an! Gebrannte Mandel scheut das Feuer.
Zusatz: Ein ehrliches DOS ist produktiver.
u> Naja, die Umgebungen unter Windows brauchen sowas nicht bzw. bauen
u> ein Makefile selbst. Da muss man nichts lernen ;-) Funktioniert
u> sogar.
Das ging mit BC fuer DOS auch gut. :) Aber make kann doch noch mehr, als
Programmprojekte "machen". Ich nehm's z.B. sehr gern fuer TeX. Muesste
eigentlich auch Kaffee kochen koennnen...;)
Jens
Jochem Huhmann
Andreas Keese <A.K...@tu-bs.de> ("AK") schrieb:
AK> Sorry, wenn sich mein Text etwas veraergert anhoert - aber seit ich mich mit
AK> Unix beschaeftige, habe ich den Eindruck, dass sich einige Unix-Apostel etwas
AK> erhaben fuehlen, weil sie in der Lage sind, mit tausend kryptischen
AK> Konfigurationsdateien und Kommandozeilenparametern umzugehen und nicht noetig
AK> haben, mit neumodischem Bloedsinn wie Maus und Fenstern umgehen zu muessen.
AK> Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort Microsoft
AK> faellt, sollte man sich mal Gedanken darueber machen, warum deren Produkte
AK> erfolgreicher sind als Unix. In der Unix-Welt scheint der Glaube
AK> vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
AK> Unix-Apostel die Weisheit gefressen haben ?
Wenn Du ein wenig Geld anlegen moechtest, kannst Du auch
Entwicklungsumgebungen kaufen, die Dir vielleicht besser gefallen, z.B.
Sniff++ oder den Source-Code-Navigator von Cygnus. Von letzterem gibt
es auch eine kostenlose Light-Version (beschraenkt auf max. 50000
Zeilen pro Projekt).
Ganz umsonst ist wipeout (http://www.softwaerebuero.de/).
Dass die ueblichen Tools als tausend Einzeltools daherkommen, liegt
IMHO nicht zuletzt daran, dass nur so ein System moeglich ist, dass
evolutionaer waechst, weil jedes dieser Tools einzeln entwickelt und
verbessert werden kann, ohne das ganze System aendern zu muessen.
Die "Unix-Apostel" haben vielleicht nicht die Weisheit gefressen, aber
sie glauben in den letzten zwanzig Jahren festgestellt zu haben, dass
so ein Ansatz zwar unpopulaer, auf lange Sicht aber der einzig
sinnvolle ist.
Wenn Du mit einem System arbeitest, dann musst Du so oder so sehr viel
lernen. Wenn man nur MS-Produkte kennt, steht man bei Unix natuerlich
erstmal wie der Ochse vor dem Berg, aber glaub mir, umgekehrt ist das
genauso.
Jochem
--
# Jochem Huhmann <j...@gmx.net> Duisburg (Germany)
# PGP fingerprint = 6C 85 FC 93 31 10 4E 81 1F 4C BE 4E 21 72 B3 7B
Ulrich Eckhardt
Holger Eitzenberger wrote:
>
> Ich kenne Visual C++ und hacke auch unter Unix, aber...
> Die Hilfe zum Developer Studio ist seehhr gut, ausserdem wird man
> durch fundierte Beispielprogramme regelrecht erschlagen, trotzdem findet
> immer sofort das, was man gerade an Beispielprogrammen sucht. Und wenn
> dir noch Doku oder Beispielprogramme fehlt kriegst Du (gegen Bar)
> vierteljährlich mehrere CD´s (MSDN Level 2). Mehr geht wirklich net.
>
> So schlecht das Betriebssystem Win95 auch ist, in manchen Dingen seht
> ihr alles nur durch die Anti-M$-Brille. Mehr Objektivität tut not. :)
>
Hi,
das stimmte ja alles, wenn's nur darum geht ein paar bunte Bildchen
zu programmieren, da ist Visual C++ sehr komfortabel und da gibts
auch viele Beispiele. Ich programmiere zur Zeit wieder an whfc
(einem Faxclient unter windows für HylaFax [läuft auch auf linux und
kostet nix]). Da habe ich ein unter Unix furchbar einfaches Problem.
Ich muss die Druckerausgabe in ein Programm umlenken. Also schnell
mal die Doku zu Visual C++ aufgemacht und rumgesucht. Ein halbes
Jahr nichts gefunden 8-( , in MS-Windows Newsgroups gepostet, keine
Antwort 8-( . Durch Zufall habe ich dann Infos zum Port Monitor auf der
DDK CD gefunden. Die Beschreibung, wie man so was macht beschränkt
sich auf ein Programm mit besch..eidener Dokumentation 8-(.
Jetzt sitze ich hier mit einer Glaskugel und einer Doku zum Gedanken-
lesen neben meinem Windows PC und versuche einen Port Monitor
zusammenzu-
stricken 8-(. Ich muss die Kiste alle 3 Minuten neu booten, weil die DLL
den Spooler zerhauen hat 8-( .
Selbst wenn man bei Linux wirklich mal in die Verlegenheit kommen sollte
einen Device-Treiber zu schreiben, so findet man umfangreiche Beispiele,
eine menge hilfreicher Newsgroups, die auch wirklich in der Lage sind
hilfreiche Tips zu geben. Das einzige Problem ist hier wirklich, die
Doku zu finden, aber wenn man sich mal ein gutes Buch zu diesem
Thema anschafft (hier reicht wirklich eins, zum Thema Port Monitor
habe ich in 5 Windows Bibeln nix gefunden 8-( ) findet man sich wirklich
gut zurecht. Ausserdem hat die Linux doku noch einen großen Vorteil :
was die Doku beschreibt, stimmt wirklich, was ich von der Visual C++
doku und einigen Windows Büchern und der DDK leider nicht behaupten kann
8-( .
Gruesse von jemandem der MS$ von herzen hasst
Uli
--
Ulrich Eckhardt mailto:u...@transcom.de
http://people.frankfurt.netsurf.de/uli
Truly great madness can not be achieved without significant
intelligence. (Henrik Tikkanen)
Jochen Schmitt
Michael Hoennig <mhoe...@on-line.de> wrote:
>Mag ja sein, wir verwenden hier kein MFC, sondern VCL
>(StarView-Nachfolger). Oder hat schonmal jemand einen
>Linux Port von MFC gesehen (hihihi).
In der aktuellen Ausgabe der iX wurde ein Portierungstool namens Win/U
getestet, mit dem es auch möglich sein soll MFC-Programme auf Unix zu
übernehmen. Dafür wurde sogar eine entsprechend angepaßte Version
dieser Bibliothek mitgeliefert.
Aber laut dem Testbericht scheint dieses Tool nicht zu empfehlen zu
sein.
mfg: Jochen Schmitt
Töns Büker
uwolf <uw...@gmx.net> meinte:
>Ich kenne beides. Windows ist einfacher, was im wesentlichen daran liegt,
>dass es "gute" und komfortable Entwicklungsumgebungen gibt, die schablonen
>artig sehr schnelles Entwicklen einer Windowsapplikation erlauben.
>Einen Prototype habe ich da in ein paar Minuten zusammengeklickt.
>Sowas fehlt meines Erachtens noch unter Unix/Linux.
>Die oben angesprochenen Entwicklungsumgebungen unterstuetzten C/C++, jedoch
>nicht X.
OpenStep ist das was Du suchst.
Tschö
Töns
PS.: gnustep rulez!
--
_o)
/\\ pgp fingerprint: 9B AC A5 CB C8 CC FC DC 25 B5 26 9A 5D 28 C0 3D
_\_V
Aldo Valente
Andreas Keese <A.K...@tu-bs.de> writes:
> > Versuchs mal mit dem Komando "apropos".
>
> Toll, genau diese Philosophie stoert mich an Unix. Man muss man sich quaelen,
<insert Unverständnis>
> darf keine komfortablen Umgebungen benutzen, denn das waere ja uncool und
> ueberhaupt zu Microsoft-artig. Wer nicht mindestens tausend
> .xxxx-Konfigurationssprachen und zweitausend Kommandoparameter lernen will,
> sollte gleich bei Windows bleiben. Ohnehin ist ja Microsoft deshalb gross,
> weil sie boese sind, und sie sind boese, weil sie gross sind, und daher
> redet jeder, der ein Produkt von denen mag, Schwachsinn... Logisch.
Kommandzeilen sind einfach flexibler und schneller als Mausschubsereien.
> Sorry, wenn sich mein Text etwas veraergert anhoert - aber seit ich mich mit
> Unix beschaeftige, habe ich den Eindruck, dass sich einige Unix-Apostel etwas
> erhaben fuehlen, weil sie in der Lage sind, mit tausend kryptischen
> Konfigurationsdateien und Kommandozeilenparametern umzugehen und nicht noetig
> haben, mit neumodischem Bloedsinn wie Maus und Fenstern umgehen zu muessen.
...weil sie damit schneller sind. Punkt.
> Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort Microsoft
> faellt, sollte man sich mal Gedanken darueber machen, warum deren Produkte
> erfolgreicher sind als Unix. In der Unix-Welt scheint der Glaube
> vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
> Unix-Apostel die Weisheit gefressen haben ?
Exakt. Der allgemeine Unix-Apostel fühlt sich verhöhnt, wenn in den
90ern noch sog. Betriebsysteme und Programme eingesetzt werden, die
alle Nase lang abstürzen. Wirklich ärgern tut er sich, weil er zur
Benutzung dieses minderwertigen Drecks gewzungen wird, weil es alle
anderen auch machen.
Ich habe es mit M$VC++ auf NT versucht und alle meine Befürchtungen
sind wahr geworden. Durchhangeln in subsubsubmenues. Unbrauchbare,
aber klickbare "Hilfe". Blaue Screens. Ein Königreich für apropos.
Aldo
PS: make werte ich als Punkt für Dich. Ich warte jedoch darauf, daß
Du etwas mehr mit make anstellen willst.
Mario Hoerich
# dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar) wrote:
> Ich hab' den Eindruck, dass ich mit Windows besser zurechtkomme, als die
>meisten Win-User, die mir bisher begegnet sind, aber Unix empfinde ich als
>intuitiver, durchschaubarer usw. - insgesamt einfacher zu bedienen (OS/2
>uebrigens auch).
Wenn ich mir da als Noch-Im-Umstieg-Befindlicher einen Kommentar zu
erlauben darf ...
Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig, insbesondere wenn man
vorher Windows benutzt hat. Die Manpages erschlagen einen förmlich vor
lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
bleibt. Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
wieviel freien Platz ich noch auf der Platte hab ...
(nach Lektüre von immerhin 2 eher schlechten Büchern ... + 2
Handbücher der Distri (DLD))
(nebenbei ist mein Linux mittlerweile öfter "gestorben" (==
neuinstallation notwendig) als mein Win0.0.95. Und das in weniger als
einem halben Jahr. Für einen "altgedienten" mag es intuitiver sein,
für einen Umsteiger ist es (imho) erstmal die Hölle. (Daß es sich
lohnt werd ich allerdings ganz bestimmt nicht bestreiten)
> Zusatz: Ein ehrliches DOS ist produktiver.
Mmmhhh... wenn ich mich nicht täusche gibt es doch auch Rhide für
Linux ?! (Ist ein Klon der Borland C/C++ DOS IDE)
http://www.tu-chemnitz.de/~sho/rho/rhide-1.4/rhide.html
Vielleicht kann Andreas ja _damit_ was anfangen ?
(KostAuchNix)
> Das ging mit BC fuer DOS auch gut. :) Aber make kann doch noch mehr, als
>Programmprojekte "machen". Ich nehm's z.B. sehr gern fuer TeX. Muesste
>eigentlich auch Kaffee kochen koennnen...;)
geht mit Rhide auch.
Zumindest unter DOS ;)
MfG
Mario
Morgige Schlagzeile der WILD Zeitung :
"Elch beim Mercedestest umgefallen !"
Nils Bokermann
Michael Hoennig <mhoe...@on-line.de> writes:
> Wolfram Gloger wrote:
> >
> > > ... und der gdb auf Intel kann nichtmal Hardware-
> > > unterst=FCtzte Watchpoints.
> >
> > Das stimmt schon seit ueber zwei Jahren nicht mehr.
> und warum braucht der 4.16 dann für ein Watch auf eine
> Integer-Variable mehrere Tage, während das mit dem
> Debugger von MS unter NT schon nach Sekunden zuschlägt?
> Vielleicht mach ich ja was falsch...
>
> > > Und langsam ist das Debuggen auch
> > > ohne Watchpoints: das Update von display-Variablen,
> > > Source-Anzeige/Disasemblierung (insbes. unter z.B. ddd)
> > > lassen das Sytem manchmal minutenlang geradezu stehen.
> >
> > Zu ddd kann ich nicht viel sagen, aber gdb an sich oder im
> > Emacs-gud-mode ist mit Sicherheit _nicht_ langsam.
> Auch der gdb direkt braucht manchmal mehrere Minuten auf
> einem Penti 200 mit 128 MB RAM, um die o.g. Aktionen
> durchzuführen. Vielleicht mach ich ja auch dort was falsch...
Vom Rechner einschalten mehrere Minuten? Ok, kann ich verstehen ;-) aber sonst
ist gdb deutlich schneller. Ich habe zwar noch nicht mit M$-Debuggern zu tun
gehabt, aber HP's debugger ist auf einer 10x so teuren Maschine auch nicht
schneller (Mag daran liegen, da"s da auch 50x soviele Benutzer drauf
arbeiten). Ansonsten ist der erste Start etwas tr"age (liegt das an shared
libs? Dann linke ich ab jetzt -static;-)
Tsch"u"s, Nils
--
Nils Bokermann
Johanneswerkstr. 90 Phone: +49 521 891279
33613 Bielefeld FAX: +49 521 550116
Germany "Wir wollen die Natur nicht erhalten --
Wir wollen nur ihre Dynamik nicht st"oren."
Michael Holzt
Aldo Valente <al...@dagobar.rhein.de> schrieb im Beitrag =
<m2wwhya...@elvis.rhein.de>...
> Kommandzeilen sind einfach flexibler und schneller als =
Mausschubsereien.
Ich w=FCrde es eher so formulieren: Tastaturbasierte Programme sind =
schneller
als mausorientierte. Der Kommandozeilen-Kram von Linux st=F6rt mich =
n=E4mlich
auch h=E4ufig. Die Existenz des Midnight Commanders beweist, da=DF ich =
da
wohl nicht alleine stehe.
Gibt es eigentlich unter Linux nichts, was irgendwie mit der =
Oberfl=E4che
von Borland C vergleichbar w=E4re - sprich ein Editor, und vor allem -
eine vern=FCnfte Online-Hilfe, wo ich alle C-Library-Befehle =
nachschlagen
kann - ohne den exakten Namen zu kennen?
--=20
Gruss Michael
Backup-Mailaddress: k...@mark.sub.de, Phone: +49-2359-903362
Christian Perle
Mario Hoerich (Mario_...@t-online.de) wrote:
: Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig, insbesondere wenn man
: vorher Windows benutzt hat. Die Manpages erschlagen einen förmlich vor
Bei Windows hast Du ja noch nicht mal vollstaendige Doku. Dann doch
lieber umfangreiche Manpages.
: lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
: bleibt. Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
: wieviel freien Platz ich noch auf der Platte hab ...
df (diskfree)
: (nebenbei ist mein Linux mittlerweile öfter "gestorben" (==
: neuinstallation notwendig) als mein Win0.0.95. Und das in weniger als
: einem halben Jahr. Für einen "altgedienten" mag es intuitiver sein,
Arbeitest vielleicht immer als Root? Dann waers kein Wunder.
Welche Distribution hast Du?
bye,
Chris
--
Christian Perle E-mail: christi...@tu-clausthal.de
Am Galgensberg 4 WWW: http://home.tu-clausthal.de/~incp/
38678 Clausthal/Germany ComputerGuitarKitesBicyclesBeerPizzaRaytracing
Jens Dittmar
>>>>> Mario Hoerich kommentiert:
MH> Wenn ich mir da als Noch-Im-Umstieg-Befindlicher einen Kommentar
MH> zu erlauben darf ...
Du darfst :)
MH> Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig,
Das ist jedes System.
MH> insbesondere wenn man vorher Windows benutzt hat.
Auf den Windows-Desktop hab' ich auch erst geguckt, wie das beruehmte
Schwein in's Uhrwerk. Dto. OS/2...
MH> Die Manpages erschlagen einen
MH> förmlich vor lauter Parametern, deren Sinn und Zweck zumindest mir
MH> meist verborgen bleibt.
Vieles erschliesst sich einem oft erst, wenn man es braucht.
MH> Ich hab z.B. immer noch keine Ahnung wie
MH> ich rausfinden soll, wieviel freien Platz ich noch auf der Platte
MH> hab (nach Lektüre von immerhin 2 eher schlechten Büchern
MH> ... + 2 Handbücher der Distri (DLD))
Da musst Du aber wirklich schlechte Buecher erwischt haben! :(
Versuch mal:
df
Kommt Zeit, kommt Durchblick. Mit den Brettern, die ich schon vorm Kopf
hatte, koennte ich einen sibirischen Winter durchheizen.
Jens
Enrico Scholz
Sascha Bohnenkamp wrote:
>
> In article <3472AACA...@tu-bs.de>, Andreas Keese <A.K...@tu-bs.de> writes:
> |> Hallo allerseits,
> |>
> |> zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> |> angeht - von Visual-C verwoehnt bin.
> (was ist das Gegenteil von Optimierung? Visual-C++ ;) )
Optimierung duerfte fuer die Standard-Softwareentwicklung ziemlich
irrelevant sein (Die geringe Zeit, die dabei gut gemacht wird, faellt
bei normalen Anwendungen kaum in Betracht. Da sollte der Programmierer
lieber in die Algorithmen investieren.)
Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
weitem nicht die unter Win95 erreicht. Hier ist m.E. nach die Gesamtheit
von Sprache, Debugger(+Profiler ?), IDE und letztendlich dem Compiler
(in dieser Reihenfolge) von Interesse.
Hier ein kurzer Vergleich:
Sprache: C++ ist fuer derzeitige professionelle Anwendungen als
Standard anzusehen. Allerdings wird heutzutage von den meisten Nutzern
eine graphische Oberflaeche verlangt. Da solche Oberflaeche aus Gruenden
der Produktivitaet nicht selbst programmiert werden koennen, ist man auf
meist kommerzielle Klassenbibliotheken (sowohl unter Windows, als auch
Linux) angewiesen. Diese besitzen allerdings kaum vollstaendig
beherrschbare Sprachbausteine, so dass man gewisse Teile der
Codegenerierung automatisieren muss. Darunter verstehe ich z.B. das
"Zusammenklichen" von Fenstern und Dialogbausteinen.
Dabei sieht es aber unter Linux meines Wissens nach ziemlich duester
aus; unter Windows hingegen findet man eine Reihe (teilweise
erschwinglicher) Tools, wie z.B. Delphi, C++ Builder, VC++.
Ein anderer Aspekt ist auch die Nutzung bereits vorhandener Programme.
Hier hat Microsoft aufgrund seiner Monopolstellung die 2
leistungsfaehige Standards DDE und OLE gesetzt. Seinesgleichen vermisse
ich leider unter X; wobei das X-Protokoll aber sicherlich genuegend
Moeglichkeiten bieten wuerde.
C++ ist allgemein auf so ziemliche jede Plattform portierbar, was aber
durch die angesprochenen Klassenbibliotheken eingeschraenkt wird. Die
Windows Bibliotheken laufen nur auf auf x86 Maschinen, wohingegen X
ueberall laeuft.
Debugger: Wo gehobelt wird, fallen Spaene; und wo programmiert wird,
geschehen Fehler (nach Murphy meist da, wo man sie nicht erwartet und
den meisten Schaden anrichten). Deswegen ist ein leistungsfaehiger
Debugger zwingend notwendig.
Auch hierbei ist Linux leider im Hintertreffen; ´gdb´ kann sich in
Verbindung mit ´ddd´ evtl. gerade mit Turbo Pascal 5.5 messen.
Er bietet zwar eine Menge von Vorteilen, wie z.B. core-Files und vor
allem Stabilitaet, aber auch Schwaechen ( das Debuggen von template -
Klassen ist fast unmoeglich, Breakpoints verschieben sich bei
Codeaenderungen nicht mit ). Ausserdem geschieht z.B. der Segmentation
fault bei einem doppelten "delete" meist nicht dort, wo er eigentlich
auftreten sollte, sondern irgendwo anders (wie z.B. in "libc_malloc"
nach Ausfuehren beliebig vieler Codezeilen), was eine Fehlereingrenzung
unmoeglich macht.
Diese Schwaechen ueberwiegen aufgrund der menschliche Psyche ( das
Nichtvorhandene dominiert ), und so erscheint mir ´gdb´ fuer
professionelles Arbeiten wenig geeignet. ´ddd´ erbt, da es vollstaendig
auf ´gdb´ aufsetzt, saemtliche Nachteile und bringt noch eigene mit (
das muehsam zusammengestellte Datenfenster verschwindet beim
Programmende, ´ddd´ scheint ziemlich hohen Ressourcenbedarf zu besitzen
und instabil zu sein, das Debuggen von ncurses-Anwendungen ist
unmoeglich, die Tastenbefehle sind grausam und fuehren bei laengerem
Gebrauch zur Sehnenscheidenentzuendung ).
Unter einer Windows Umgebung ist die Bedienung der Debugger meist
intuitiv (siehe auch IDE), und die Darstellung geschieht in neueren
Versionen meistens sehr gut. Die oben angesprochene Sprachunterstuetzung
(templates, Debuggen von Makros) kann ich aufgrund mangelnder Erfahrung
unter Windows nicht beurteilen.
Ich raeume allerdings ein, dass ´gdb´ wegen vieler
Einstellungsmoeglichkeiten leistungsfaehiger ist.
Dies gilt aber allgemein fuer Linux - man kann es konfigurieren und den
jeweiligen Beduerfnissen bestmoeglich anpassen; Windows ist (ausser bei
einigen Basiseinstellungen, wie z.B. Schriftfarbe) unkonfigurierbar -
entweder es laeuft, oder man hat Pech gehabt.
IDE: Irgendwie muss man den Code eingeben und da es sich bei
groesseren Projekten um mehrere zig-Tausend Codezeilen handelt, ist man
auf eine komfortable Oberflaeche angewiesen, welche einem mit Rat
(Hilfe) und Tat ("Zusammenklicken" von Fenstern --> Codegenerierung) zur
Seite stehen sollte. Angenehm waere ausserdem, wenn andere
Entwicklungswerkzeuge, wie Debugger und Compiler, irgendwie integriert
sind.
Unter Linux hat man hierbei lediglich ein "paar" Anfangsschwierigkeiten,
wie z.B. den richtigen Editor zu finden, die ...zig Seiten HOWTO´s
durchzulesen; aber nach ca. 4 Wochen existiert endlich ein perfektes
Emacs - Konfigurationsfile.
Es klappt zwar meistens doch noch nicht alles 100prozentig - die
Del-Taste macht nicht immer das, was sie soll, der numerische
Tastenblock ist nicht immer zu gebrauchen und von der NumLock Taste
wollen wir hier gar nicht sprechen - wir haben aber eine
leistungsfaehige Entwicklungsumgebung, in welcher _WIR_ hervorragend
zurechtkommen.
Falls sich jemand anderes ransetzen will, muss er sich halt mit der
Bedienung bekannt machen.
In der Linux-Welt hat aber sowieso jedes Programm seine eigene
Bedienphilosophie. Hier gibt es keinen Monopolisten, welcher Standards
vorschreibt, sondern nur die totale Freiheit, in der die ENTER-Taste den
Rechner runterfaehrt!
Unter DOS herrscht dagegen traege Einheitlichkeit - CTRL-Y loescht die
aktuelle Zeile, ESC schliesst das aktuelle Fenster, mit
SHIFT-Pfeiltasten wird markiert, die Funktionstasten funktionieren und
es laesst sich alles mehr oder weniger intuitiv bedienen. Allerdings
stossen wir bei einigen Sachen leicht an die Grenzen der jeweiligen IDE;
z.B. geschieht bei der VC-IDE das Einruecken stets in
Tabulator-Schrittweite, welche, dem allgemeinen Standard folgend,
natuerlich auf 4 Zeichen gesetzt ist.
Compiler: Hier lassen sich unter Linux und Windows wenig Unterschiede
ausmachen. Unter Linux ist man, falls es erforderlich ist, aber
erheblich flexibler. Als wunderbarer Erweiterung zur Compilierung, steht
hier die Skriptsprache zur Verfuegung, fuer die es unter Windows keine
Entsprechung gibt. Ausserdem existiert fuer ziemlich jede Plattform
einen ´gcc´-Compiler, so dass die Portierung der Programme ein
Kinderspiel ist.
Zusammenfassend laesst sich sagen, dass Windows intuitiv bedienbare und
fuer Graphikanwendungen die besseren Entwicklungsmoeglichkeiten bietet.
Fuer Textanwendungen ist, wenn man eine gewisse Einarbeitungszeit in
Betracht zieht, Linux aber die bessere Wahl.
> |> Leider muss ich jetzt unter Unix
> |> Software entwickeln :-(
> Nicht Leider, zum Glueck!
Ich finde es auch toll, wenn nach einiger Zeit Herumprobieren die IDE
endlich das macht, was sie soll. Hier hat man einfach mehr
Erfolgserlebnisse.
Linux macht viel mehr Spass - hier hat man eine ordentliche
Kommandozeile (TAB-Taste !), leistungsfaehige Shell-Kommandos, welche so
manches Programm ueberfluessig machen, viiiiiieeeeeele Befehle und vor
allem ist das meiste (noch) kostenlos.
Auch sehe ich es nicht ein, warum viele Unternehmen sich einen teuren
und instabilen NT-Rechner zulegen, nur um ihr "Intranet" (wieder so ein
Kunstwort, mit dem sich Kohle machen laesst ...) darauf laufen zu lassen
...
> |> Mein Problem ist, dass ich noch ueberhaupt keine strukturierte Hilfe zu
> |> Bibliotheksfunktionen gefunden habe. Ich kann natuerlich per man -k nach
> [...]
> Warum kaufst Du Dir kein Buch?
Buecher sind nur etwas fuer´s Kennenlernen der Sprache - waehrend der
Entwicklung ist man auf eine Online-Hilfe angewiesen. Diese ist unter
Linux aber laecherlich - aelteres steht in den Manpages, Hilfe zu C++ -
Sachen findet man entweder gar nicht, oder nur in gezippten HOWTO´s
(z.B. zu den stream-Klassen), und neuerdings bietet nur noch das
Programm via "--help" ausfuehrliche Informationen.
> [...]
> Ueber die Win32-API findest du etwas, aber ueber 'alle' installierten
> Bibliotheken (dll's)? Das will ich sehen ... *hihi*
Ist das denn auch noetig?
> [...]
Bye ... ESC
Oliver Bandel
Andreas Keese <A.K...@tu-bs.de> wrote:
> Oliver Bandel wrote:
> > > zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> > > angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
> > > Software entwickeln :-(
> > tse tse tse... was ist das denn für ein Schwachsinn?
> Hmm, ich glaube, Du hast meine Mail nicht gelesen.
Tja, glaub mal weiter.
Wahrscheinlich glaubst Du auch an den Weihnachtsmann (ist ja bald
wieder so weit).
Und der Knecht mit der Rute, der Dich verprügelt, wenn Du nicht weiterhin
die M$-Flagge hißt, heißt Billy, ist mir schon klar.
> > Versuchs mal mit dem Komando "apropos".
> Toll, genau diese Philosophie stoert mich an Unix. Man muss man sich quaelen,
> darf keine komfortablen Umgebungen benutzen, denn das waere ja uncool und
> ueberhaupt zu Microsoft-artig.
Ey, Du Stinker!
Erst willst Du eine Antwort, und wenn man Dir eine gibt, dann biste
auch nicht zufrieden.
Was willst Du eigentlich?
Willste hier nur erzählen, wie Scheiße Unix/Linux ist?
Dann geh doch in die M$-Gruppen. Da kannste von mir aus sowas ablassen.
Und wenn Du keine Tips haben willst, dann frage auch nicht danach.
Ich finde apropos ein geniales Tool. Wenn's Dir nicht reicht, kann ich
nichts dafür. Du wolltest nicht ewig lange suchen in Büchern und
Manpages suchen, um zu finden was Du
brauchst, sondern fragtest nach einem Tool, das einem einen Überblick
über Funktionen gibt, z.B. über die entsprechenden manpages.
Wenn Du es aber Scheiße findest, daß man Dir eine Antwort gibt,
dann verpiss Dich, Du undankbarer Knilch!
(Normalerweise habe ich mir eine Engelsgeduld angewöhnt, aber
das geht einfach zu weit!)
> Wer nicht mindestens tausend
> .xxxx-Konfigurationssprachen und zweitausend Kommandoparameter lernen will,
> sollte gleich bei Windows bleiben.
Klar, wenn ihm das besser gefällt, soll er Windows nehmen.
Jeder soll bitteschön die Plattform nutzen, die ihm gefällt.
Und Windows mag auch seine guten Seiten haben.
Andererseits muß man am Anfang immer was dazu lernen. Aber dazu
bist Du ja anscheinend zu faul/verwöhnt.
> Ohnehin ist ja Microsoft deshalb gross,
> weil sie boese sind, und sie sind boese, weil sie gross sind, und daher
> redet jeder, der ein Produkt von denen mag, Schwachsinn... Logisch.
Blödsinn!
Ich finde die Microschrottware zum Kotzen. Ich habe reichlich Erfahrung
mit Microschrott gemacht. Und die war fast ausnahmslos negativ.
Deswegen brauchst Du aber nicht gut gemeinte Ratschläge abschmettern.
Wenn Du keinen Rat suchst (sondern Streit), dann geh woanders hin.
> Unter Unix artet jede noch so kleine Aufgabe gleich in Riesenaufwand aus -
> letztens hab ich mir ein Makefile geschrieben - und dafuer reicht es
> natuerlich nicht, erstmal diese komische Make-Sprache zu lernen - nein, um
> das anstaendig zu machen, muss man auch gleich noch sed lernen :-( Das dauert
> mir alles zu lange. Unter VisualC kann ich einfach die Dateien ins Projekt
> ziehen und kompilieren.
Aller Anfang ist schwer... außer bei Microsoft, da wirds dann nach
einem anfänglich leichten Anfang zunehmend schwerer.
Auch Unix/Linux muß man erst mal beherrschen. Das ist sicherlich nicht
leicht am Anfang. Aber wenn man sich mal einen Moment lang Zeit nimmt
und die rosarote Microshit-Brille abnimmt, dann kann man eines Tages
auch noch erkennen, wie genial die Tools sind - wenn man sie erst
einmal begriffen hat.
Dazu bedarf es allerdings etwas Zeit und etwas wohlwollende Laune.
Wenn Du schon jetzt grundsätzlich von Unix/Linux genervt bist, dann
laß die Finger davon. Ich zum Beispiel meide Microshit, weil es mich
sofort anekelt, wenn etwas nicht so funktioniert, wie ich es haben
will.
Und bei Unix/Linux kann man sicher sein, daß man eine
Lösung findet und man halt bisher irgend etwas übersehen hat.
Microschrott dagegen stürzt grundlos ab. Und das macht das Programmieren
und arbeiten daran so "angenehm": Man selber ist ja bestimmt nicht
Schuld daran, sondern das Billygotchi hatte wieder schlechte Laune.
Aber jeder hat halt seine Vorlieben und Abneigungen.
> > Das gibt Dir den Überblick.
> Vielleicht solltest Du Mails nicht nach dem ersten Absatz beantworten,
> sondern weiter lesen ?
Dumpfbacke!
Vielleicht solltest Du auchmal Antworten auf Deine Anfragen weiterlesen
und Dich nicht von einem Spruch vom weiterlesen abhalten lassen.
Meine Antwort war durchweg wohlwollend gemeint. Sonst hätte ich Dir
kaum noch erzählt, welches Tool einen weiterbringen kann.
Wenn allerdings Deine ganze Prorammierkunst darin besteht, BUNTE
FENSTERCHEN aufzumachen und wieder zu schließen, und irgendwelche
Icons hin und her zu ziehen, dann geh zu Windoof.
Wenn es Dir um einen Überblick über Tools/Manpages geht, dann nimm
"apropos"; und sollte Dir das zu einfarbig sein, dann mal Deinen
Bildschirm bunt an.
> Sorry, wenn sich mein Text etwas veraergert anhoert -
Vielleicht bist Du einfach etwas arrogant und schnallst nicht, daß
Unix/Linux ein anderes System ist als Microschrotts Windumpf.
Es muß Dir ja auch nicht gefallen; mir gefällt M$-Zeug ja auch nicht.
Aber dann ziehe Konsequenzen daraus: Entweder meide Unix/Linux, wenns
Dir nicht zusagt, oder aber sieh einfach, daß es etwas ANDERES ist.
Wenn Du Windoof willst - bitte, dann nimm Windoof.
Und wenn Du Unix willst, dann komm von Deinem hohen Ross herunter
und schaue Dir an, welche Möglichkeiten es bietet.
(auch, wenn es anfangs etwas unübersichtlich ist; man könnte
es auch positiv Formulieren: Es bietet so viele Möglichkeiten,
bietet Potential, das anfangs halt etwas verwirrt)
(iX 12/97 in einem Beitrag zum e-Mail-Gateway des WDR,
der nun unter Linux läuft: "Eine Administration auf
Basis von ASCII-Dateien hat sich effektiver als
jede GUI erwiesen.")
> aber seit ich mich mit
> Unix beschaeftige, habe ich den Eindruck, dass sich einige Unix-Apostel etwas
> erhaben fuehlen,
Ich für meinen Teil bin bestimmt kein Unix-Apostel.
Auch fühle ich mich nicht erhaben...
> weil sie in der Lage sind, mit tausend kryptischen
> Konfigurationsdateien und Kommandozeilenparametern umzugehen
Ja, ich kann mit Kommandozeilenparametern umgehen.
Und ich kann auch mit Konfigurationsdateien umgehen; allerdings
bin auch ich manchmal völlig überfordert von den oft mächtigen
Dateien.
Nur weiß ich es zu schätzen, daß man bei Unix/Linux alles im Klartext
verwalten kann und nicht abhängig ist von irgendwelchen WIRKLICH
KRYPTISCHEN BINÄRDATEIEN, WIE ES BILLY-BOY UNS ALS SCHLECHTES BEISPIEL
VORMACHT.
> und nicht noetig
> haben, mit neumodischem Bloedsinn wie Maus und Fenstern umgehen zu muessen.
Quatsch.
Ich bin auch oft froh, daß es das X Window System gibt; aber ich arbeite
halt am liebsten auf der Textshell.
Ist halt schon schlimm, wenn man vor lauter Klickerei das Schreiben
verlernt hat und womöglich noch ein paar Befehle kennen muß.
> Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort Microsoft
> faellt, sollte man sich mal Gedanken darueber machen, warum deren Produkte
> erfolgreicher sind als Unix.
Klar, darüber mache ich mir oft Gedanken.
Manches an Unix könnte man noch übersichtlicher Gestalten; keine Frage.
Aber im Gegenzug: Immer wenn das Wort Textshell fällt brauchst Du
nicht gleich die Krätze zu kriegen.
> In der Unix-Welt scheint der Glaube
> vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
> Unix-Apostel die Weisheit gefressen haben ?
Absoluter Stuß.
Nur sind die Microsoft-Erleuchteten oft nicht mehr gewillt, sich auch
mal mit dem Gerät, das sie Bedienen, etwas näher zu beschäftigen.
(Fährst Du auch's Auto ohne Führerschein, oder ohne Beachtung der
Verkehrsregeln, weil Du ja siehst, was da so passiert?)
MICROSOFT baut auf einem MYTHOS auf: Man braucht nichts können,
aber alles soll nach dem eigenen Willen funktionieren.
Das ist absoluter Dumpfsinn und gehört in den Religiösen Bereich.
SEKTE MICROSOFT!
Wenn alles so läuft, wie Microschrott es einem vorgaukelt,
dann würde ja alles problemlos laufen; die tägliche Praxis
zeigt das Gegenteil.
Und ich habe in diversen Firmen schon gesehen, was man so üblicherweise
als Arbeiten, oder gar effektives Arbeiten bezeichnet. Und mir
ist fast schlecht geworden. Siesta ist dagegen Schwerstarbeit.
Und einen Großteil der Arbeitszeit wurde in Diskussionen verplempert,
wo es um Microschrotts Netzwerk und sein pissiges Word ging.
(und dann müssen Überstunden geschoben werden,
weil die Arbeit nicht erledigt werden kann...)
Soll ja jeder der es will damit arbeiten. Keine Frage.
Aber UNIX ist da nunmal anders. Nicht einfach, aber sicherlich GENIAL.
Und das soll keineswegs heißen, daß ich es grundsätzlich ablehne,
GUIs einzusetzen, oder irgendwelche Tools einzusetzen.
Nur, bitteschön, komm von Deiner Arroganz herunter, daß der Arbeits-
platz an einem UNIX-Rechner genauso aussehen soll, wie an einem
M$-Rechner, nur weil DU Dich dazu herabläßt, überhaupt mal an einem
Rechner zu arbeiten, der noch sowas wie eine Textshell hat.
Tschüß,
Oliver
--
Oliver Bandel
> AK> sich quaelen, darf keine komfortablen Umgebungen benutzen,
> Du darfst! Den Begriff "komfortabel" sollten wir mal weglassen, da
> versteht jeder was anderes drunter.
> AK> Unter Unix artet jede noch so kleine Aufgabe gleich in
> AK> Riesenaufwand aus
> Das Gefuehl hatte ich immer unter Windows. Unter Unix geht mir alles
> leichter von der Hand. Und wenn ich Windows-Usern zusehe, denk ich mir oft
> nach dem zwanzigsten Mausklick: "Unter Unix waere ich schon lange fertig."
Kooorekt!
Das ist das, was mir bei Unix/Linux so gefällt: EFFIZIENTES, EFFEKTIVES
arbeiten.
Da programmieren andere Wochenlang an einer Datenbank, ob nun unter Excel,
oder eine richtige Datenbank, um ein paar Adressen zu verwalten...
... dabei braucht man dafür oft bloß den vi und grep.
Und grep ist ja nun wirklich simpel zu benutzen!
Tschüß,
Oliver
--
jou
Mario Hoerich wrote:
>
> # dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar) wrote:
>
> > Ich hab' den Eindruck, dass ich mit Windows besser zurechtkomme, als die
> >meisten Win-User, die mir bisher begegnet sind, aber Unix empfinde ich als
> >intuitiver, durchschaubarer usw. - insgesamt einfacher zu bedienen (OS/2
> >uebrigens auch).
> erlauben darf ...
>
> Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig, insbesondere wenn man
> vorher Windows benutzt hat. Die Manpages erschlagen einen förmlich vor
> lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
> bleibt. Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
> wieviel freien Platz ich noch auf der Platte hab ...
> (nach Lektüre von immerhin 2 eher schlechten Büchern ... + 2
> Handbücher der Distri (DLD))
Fuer umsteiger ist es hart (war ich ja auch mal), aber bald wirst du die
in-sich konsistebz lieben lernen.. Der support ist ungeschlagen (wenn
man internet connect hat)..
BTW:
man man
man -k disk
(oder man -k disk | grep free)
man df
df
> (nebenbei ist mein Linux mittlerweile öfter "gestorben" (==
> neuinstallation notwendig) als mein Win0.0.95. Und das in weniger als
> einem halben Jahr. Für einen "altgedienten" mag es intuitiver sein,
> für einen Umsteiger ist es (imho) erstmal die Hölle. (Daß es sich
> lohnt werd ich allerdings ganz bestimmt nicht bestreiten)
Hast du die inittab und bootscripts zur nichtbootfaehigkeit veraehndet
oder einfach nur eine falsche option im kernel gehabt ?
Die inittab ruehren selbst power user vorsichtig an, ein passender
fehler und das wars.. Bei falschen kernel sollte man per lilo die
vorigen versionen immer parat halten..
Jou.
jou
geht noch kuerzer.. less..
Jou.
Hauke Klein
Enrico Scholz wrote:
>
> und instabil zu sein, das Debuggen von ncurses-Anwendungen ist
> unmoeglich, die Tastenbefehle sind grausam und fuehren bei laengerem
> Gebrauch zur Sehnenscheidenentzuendung ).
>
gdb und ddd haben natuerlich ihre Schwaechen, aber das das Debuggen
von ncurses-Anwendungen unmoeglich ist, ist schlichtweg nicht wahr.
Du startest in einem xterm zuerst ddd auf dem zu debuggenden ncurses-
Programm, startest anschliessend das Programm selbst und gibst im ddd
Kommandofenster "attach <PID des Programms>" ein. Dann funktioniert
das auch.
Hauke
Sascha Bohnenkamp
Ich habe mal im Rahmen eines groesseren Projektes Teile der MFC portiert
(die Teile die wir brauchten ...). Mit einer guten Klassenbibliothek fuer
Motif (2.x) geht das eigentlich ganz gut, solange man sich bei der
Windowsversion benommen hat, d.h. nicht zu viele Win-Eigenheiten genutzt
hat.
Auf diese Weise habe ich eine CAD-System von Win-Burp nach Alpha-VMS portiert.
Nach zwei Wochen lief das erste Build vollstaendig durch ! Und nach einer
weiteren Woche lief das Programm (immerhin ca. 50.000 Zeilen C++, ohne Kommentar,
ein cat | grep | wc -l machts moeglich ;-) )
Nur Ole etc. duerfte schwierig sein ... vielleicht mit EntireX ?!
Daher sehe ich Produkte obiger Art eher skeptisch ...
Andreas Keese
Enrico Scholz wrote:
> Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> weitem nicht die unter Win95 erreicht. Hier ist m.E. nach die Gesamtheit
> von Sprache, Debugger(+Profiler ?), IDE und letztendlich dem Compiler
> (in dieser Reihenfolge) von Interesse.
Genau mein Eindruck - man darf in dieser Hinsicht vielleicht freie Software nicht mit
Kommerz-Software vergleichen, aber ich habe den Eindruck, dass diese Aussage fuer
Unix allgemein und auch fuer kommerzielle Entwicklungstools gilt (ich kenne
allerdings nur Linux, HP-Ux, Unicos und Irix - und darunter wieder nur ein paar
Compiler/Entwicklungsumgebungen)
> Da solche Oberflaeche aus Gruenden
> der Produktivitaet nicht selbst programmiert werden koennen, ist man auf
> meist kommerzielle Klassenbibliotheken (sowohl unter Windows, als auch
> Linux) angewiesen.
Gibt es denn solche fuer Linux, die vielleicht auch noch portabel sind ?
> Ein anderer Aspekt ist auch die Nutzung bereits vorhandener Programme.
> Hier hat Microsoft aufgrund seiner Monopolstellung die 2
> leistungsfaehige Standards DDE und OLE gesetzt.
Ich kenne mich in der Hinsicht nicht aus - aber kann man nicht TCP/IP statt
DDE verwenden ? Ich weiss, dass z.B. das Visualisierungstool AVS diese
Funktionalitaet durch TCP/IP umsetzt...
Tschuess,
Andreas
Andreas Keese
Mario Hoerich wrote:
> Die Manpages erschlagen einen förmlich vor
> lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
> bleibt. I
Das schlimmste ist mE, dass die Man-Pages zwar alles noetige erklaeren, aber
keine Beispiele liefern. Ich kann mir nicht vorstellen, dass jemand find oder
sed nur anhand der Man-Page verstehen kann.
> (nach Lektüre von immerhin 2 eher schlechten Büchern ... + 2
> Handbücher der Distri (DLD))
Die Handbuecher des LDP finde ich sehr gut. Hast Du Dich da mal umgeschaut ?
BTW: Auch als Anfaenger finde ich das Systemadminstrator-Handbuch sehr
sinnvoll, da es einem die Philosophie von Linux und die Hintergruende ganz gut
vermittelt.
> http://www.tu-chemnitz.de/~sho/rho/rhide-1.4/rhide.html
> Vielleicht kann Andreas ja _damit_ was anfangen ?
> (KostAuchNix)
:-)
Mal sehen... Allerdings muss ich mich hauptsaechlich in Fortran tummeln, wo
ich vielleicht ein, zwei C oder C++-Module ranlinken darf, wenn ich Glueck
habe.
Tschuess,
Andreas
Oliver Bandel
Ulrich Eckhardt <u...@transcom.de> wrote:
[...]
> Selbst wenn man bei Linux wirklich mal in die Verlegenheit kommen sollte
> einen Device-Treiber zu schreiben, so findet man umfangreiche Beispiele,
> eine menge hilfreicher Newsgroups, die auch wirklich in der Lage sind
> hilfreiche Tips zu geben.
Also, nur mal so als Beispiel: Wenn man mal das Stichwort "device"
heraus nimmt und dann mal apropos damit beauftragt, was heraus zu
suchen, dann bekommt man folgendes:
-----------------------------------------
badblocks (8) - search a device for bad blocks
creat (2) - open and possibly create a file or device
fd (4) - floppy disk device
groff_font (5) - format of groff device and font description files
hd (4) - MFM/IDE hard disk device
ioctl (2) - control device
open (2) - open and possibly create a file or device
ram (4) - ram disk device
ramsize (8) - query/set image root device, swap device, RAM disk size, or video mode
rdev (8) - query/set image root device, swap device, RAM disk size, or video mode
rootflags (8) - query/set image root device, swap device, RAM disk size, or video mode
st (4) - SCSI tape device
swapdev (8) - query/set image root device, swap device, RAM disk size, or video mode
swapoff (2) - start/stop swapping to file/device
swapon (2) - start/stop swapping to file/device
ttytype (5) - terminal name and device list
tunelp (8) - set various parameters for the lp device
vidmode (8) - query/set image root device, swap device, RAM disk size, or video mode
-----------------------------------------
Und?
Da hat man doch schon einen ersten Anhaltspunkt, wo man schauen kann.
Und dann guckt man halt weiter...
... und Newsgroups gibt's für den Fall aller Fälle ja auchnoch.
Tschüß,
Oliver
P.S.: Schließt sich GUI und apropos aus?
--
Dirk Moebius
Mario_...@t-online.de (Mario Hoerich) writes:
> Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig, insbesondere wenn man
> vorher Windows benutzt hat. Die Manpages erschlagen einen förmlich vor
> lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
> bleibt.
Ein Zweck ist z.B. die weitgehende Automatisierung von Abläufen (Stichwort
crontab, shell scripts).
Kannst Du windisk oder winzip im Hintergrund oder automatisch starten und ihm
gleich alle benötigten Anweisungen mitgeben?
> Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
> wieviel freien Platz ich noch auf der Platte hab ...
man df
--
Dirk Moebius ---------------------------------v------- pgp key on request -----
Fax +49 - 30 - 7002 - 3851 ALCATEL Mobile Communication Berlin
Phone +49 - 30 - 7002 - 3577 D-12099 Berlin, Colditzstr. 34
mailto:Dirk.M...@bln.sel.alcatel.de Alcanet moe...@bln.sel.alcatel.de
forcer
On 24 Nov 1997 21:51:43 GMT, Mario Hoerich <Mario_...@t-online.de> wrote:
># dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar) wrote:
>
>> Ich hab' den Eindruck, dass ich mit Windows besser zurechtkomme, als die
>>meisten Win-User, die mir bisher begegnet sind, aber Unix empfinde ich als
>>intuitiver, durchschaubarer usw. - insgesamt einfacher zu bedienen (OS/2
>>uebrigens auch).
>Wenn ich mir da als Noch-Im-Umstieg-Befindlicher einen Kommentar zu
>erlauben darf ...
>
>vorher Windows benutzt hat.
sollen. Einfacher gehts nicht. grad ein paar sachen ausfuehren, neustart ;),
fertig. nur... dann ging was nicht.... und es gibt wirklich keine mit-
gelieferte docu fuer das. Da muss man sich halt noch 3 waelzer a 100DM zulegen,
um damit zurechtzukommen ;)
>Die Manpages erschlagen einen förmlich vor
>lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
>bleibt.
listet 23 zeilen parameter. Ich brauche kaum mehr als xzf, gelegentlich auch
ohne z. Seltenst mal ein -C. Das ist das schoene unter Linux/UNIX: Du musst
nicht alles lesen, was dir angeboten wird, aber wenn du es brauchst, findest
du auch infos darueber.
>Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
>wieviel freien Platz ich noch auf der Platte hab ...
>(nach Lektüre von immerhin 2 eher schlechten Büchern ... + 2
>Handbücher der Distri (DLD))
UNIX im allgemeinen (oder auch Linux). :) sollte langen.
>
>(nebenbei ist mein Linux mittlerweile öfter "gestorben" (==
>neuinstallation notwendig) als mein Win0.0.95. Und das in weniger als
>einem halben Jahr. Für einen "altgedienten" mag es intuitiver sein,
>für einen Umsteiger ist es (imho) erstmal die Hölle. (Daß es sich
>lohnt werd ich allerdings ganz bestimmt nicht bestreiten)
eigenes unwissen als nachteil des OS zu sehen, ist nicht in ordnung.
Wenn du nicht gerade als root unkontrolliert rm -rf'sd, kann in aller
regel nichts so schwerwiegendes passieren, dass man das system komplett
neu installieren muss. Hoechstens ein-zwei packages nachinstallieren ;)
Damit will ich nicht behaupten, ich weiss alles, das waere naemlich komplett
falsch, aber ich habe etwas gelernt, das ich dir auch empfehlen kann, und
jedem anderen auch. Unter Linux darfst du niemals aufgeben. Wenn etwas nicht
klappt, weiterprobieren (oder eher weiter RTFMen)... Ich habe mir letztens
mit einem upgrade von libc5 auf glibc2 mein system halb untauglich gemacht,
aber das lag an meiner dummheit, nicht an linux. Und nach einem tag rum-
werkeln lief das ding auch wieder einwandfrei, und ich habe nicht mal
rebootet.
>
>> Zusatz: Ein ehrliches DOS ist produktiver.
>Mmmhhh... wenn ich mich nicht täusche gibt es doch auch Rhide für
>Linux ?! (Ist ein Klon der Borland C/C++ DOS IDE)
>
>Vielleicht kann Andreas ja _damit_ was anfangen ?
>(KostAuchNix)
>
>>Programmprojekte "machen". Ich nehm's z.B. sehr gern fuer TeX. Muesste
>>eigentlich auch Kaffee kochen koennnen...;)
>geht mit Rhide auch.
>Zumindest unter DOS ;)
Wurde aber zu komplex, also hat mans in ein anderes modul ausgelagert ("Java").
>
>MfG
>Mario
>Morgige Schlagzeile der WILD Zeitung :
>
>"Elch beim Mercedestest umgefallen !"
-forcer
--
/* Software is like sex; it's better when it's free - Linus Torvalds */
/* email: for...@mindless.com.nospam www: http://www.forcer.base.org/ */
/* finger: for...@cyberspace.org.nospam IRC: forcer (IRCnet #StarWars) */
/* pgppub: 1024/56554141 B3 2A 88 53 DB DA 12 20 FD B0 D4 79 4E 5A AB 32 */
Jens Dittmar
>>>>> Andreas Keese zweifelt:
AK> ... Ich kann mir nicht
AK> vorstellen, dass jemand find oder sed nur anhand der Man-Page
AK> verstehen kann.
Zumindest fuer find kann ich Dir versichern: es geht! Beim sed wird es
etwas muehsam. Obwohl Manpages ja eigentlich zum Nachschlagen sind, ...
Jens
Frank Roscher
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
: Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
: weitem nicht die unter Win95 erreicht.
Meinst Du das wirklich ernst? Falls ja solltest Du vielleicht nicht
"die Produktivitaet" sondern "meine Produktivitaet" scheiben.
: Auch hierbei ist Linux leider im Hintertreffen; ´gdb´ kann sich in
: Verbindung mit ´ddd´ evtl. gerade mit Turbo Pascal 5.5 messen.
Ich kenne zwar TurboPascal 5.5 nicht, aber ich vermisse an gdb recht wenig.
: Er bietet zwar eine Menge von Vorteilen, wie z.B. core-Files und vor
: allem Stabilitaet, aber auch Schwaechen ( das Debuggen von template -
: Klassen ist fast unmoeglich, Breakpoints verschieben sich bei
: Codeaenderungen nicht mit ). Ausserdem geschieht z.B. der Segmentation
: fault bei einem doppelten "delete" meist nicht dort, wo er eigentlich
: auftreten sollte, sondern irgendwo anders (wie z.B. in "libc_malloc"
: nach Ausfuehren beliebig vieler Codezeilen), was eine Fehlereingrenzung
: unmoeglich macht.
Das mit dem doppeltem delete hat wohl recht wenig mit dem Debugger zu tun,
sondern viel mehr mit der Implementierung der dynamischen Speicherverwaltung.
Ausserdem gibt es Debug libraries mit denen sich solche und andere Fehler
in der Speicherverwaltung recht schnell finden lassen.
: Diese Schwaechen ueberwiegen aufgrund der menschliche Psyche ( das
: Nichtvorhandene dominiert ), und so erscheint mir ´gdb´ fuer
: professionelles Arbeiten wenig geeignet.
Das scheint Dir nur so, ich fuehle mich mit einem Debugger wohler, den
ich auf mehreren Plattformen benutzen kann bedeutend wohler.
: und instabil zu sein, das Debuggen von ncurses-Anwendungen ist
: unmoeglich, die Tastenbefehle sind grausam und fuehren bei laengerem
: Gebrauch zur Sehnenscheidenentzuendung ).
Also mit native gdb kann ich ncurses wunderbar in einem anderem XTerm oder
auf einem seriellen Terminal debuggen. ddd kenne ich nicht.
: Einstellungsmoeglichkeiten leistungsfaehiger ist.
: Dies gilt aber allgemein fuer Linux - man kann es konfigurieren und den
: jeweiligen Beduerfnissen bestmoeglich anpassen; Windows ist (ausser bei
: einigen Basiseinstellungen, wie z.B. Schriftfarbe) unkonfigurierbar -
: entweder es laeuft, oder man hat Pech gehabt.
"entweder es laeuft ..." - das ist natuerlich fuer professionelles Arbeiten
sehr gut geeignet.
: IDE: Irgendwie muss man den Code eingeben und da es sich bei
: groesseren Projekten um mehrere zig-Tausend Codezeilen handelt, ist man
: auf eine komfortable Oberflaeche angewiesen, welche einem mit Rat
: (Hilfe) und Tat ("Zusammenklicken" von Fenstern --> Codegenerierung) zur
: Seite stehen sollte. Angenehm waere ausserdem, wenn andere
: Entwicklungswerkzeuge, wie Debugger und Compiler, irgendwie integriert
: sind.
Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
: Unter Linux hat man hierbei lediglich ein "paar" Anfangsschwierigkeiten,
: wie z.B. den richtigen Editor zu finden, die ...zig Seiten HOWTO´s
: durchzulesen; aber nach ca. 4 Wochen existiert endlich ein perfektes
: Emacs - Konfigurationsfile.
: Es klappt zwar meistens doch noch nicht alles 100prozentig - die
: Del-Taste macht nicht immer das, was sie soll, der numerische
: Tastenblock ist nicht immer zu gebrauchen und von der NumLock Taste
: wollen wir hier gar nicht sprechen - wir haben aber eine
: leistungsfaehige Entwicklungsumgebung, in welcher _WIR_ hervorragend
: zurechtkommen.
: Falls sich jemand anderes ransetzen will, muss er sich halt mit der
: Bedienung bekannt machen.
Ich brauche eine Entwicklungsumgebung in der ich zurechtkomme, da muss
sich niemand anderes ransetzen.
: In der Linux-Welt hat aber sowieso jedes Programm seine eigene
: Bedienphilosophie. Hier gibt es keinen Monopolisten, welcher Standards
: vorschreibt, sondern nur die totale Freiheit, in der die ENTER-Taste den
: Rechner runterfaehrt!
: Unter DOS herrscht dagegen traege Einheitlichkeit - CTRL-Y loescht die
: aktuelle Zeile, ESC schliesst das aktuelle Fenster, mit
: SHIFT-Pfeiltasten wird markiert, die Funktionstasten funktionieren und
: es laesst sich alles mehr oder weniger intuitiv bedienen. Allerdings
: stossen wir bei einigen Sachen leicht an die Grenzen der jeweiligen IDE;
: z.B. geschieht bei der VC-IDE das Einruecken stets in
: Tabulator-Schrittweite, welche, dem allgemeinen Standard folgend,
: natuerlich auf 4 Zeichen gesetzt ist.
Aha in welchem Standard steht, das die Tabulatorweite 4 Zeichen ist?
frank
Frank Roscher
Mario Hoerich <Mario_...@t-online.de> wrote:
: Unix/Linux ist imho _SEHR_ gewöhnungsbedürftig, insbesondere wenn man
: vorher Windows benutzt hat. Die Manpages erschlagen einen förmlich vor
: lauter Parametern, deren Sinn und Zweck zumindest mir meist verborgen
: bleibt.
Natuerlich undokumentiere Parameter sind natuerlich viel einfacher zu
verstehen:-)
: Ich hab z.B. immer noch keine Ahnung wie ich rausfinden soll,
: wieviel freien Platz ich noch auf der Platte hab ...
: (nach Lektüre von immerhin 2 eher schlechten Büchern ... + 2
: Handbücher der Distri (DLD))
man df. Irgendwie hast Du die falschen Buecher gelesen.
: (nebenbei ist mein Linux mittlerweile öfter "gestorben" (==
: neuinstallation notwendig) als mein Win0.0.95. Und das in weniger als
: einem halben Jahr.
Also ich arbeite mit Linux seit einigen Jahren und gestorben, d.h. das
es notwendig war es neuzuinstallieren ist es mir bisher noch nie (ausser
bei einem HD-Crash).
frank
Enrico Scholz
Andreas Keese wrote:
>
> Enrico Scholz wrote:
>
> > Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> > weitem nicht die unter Win95 erreicht. Hier ist m.E. nach die Gesamtheit
> > von Sprache, Debugger(+Profiler ?), IDE und letztendlich dem Compiler
> > (in dieser Reihenfolge) von Interesse.
>
> Kommerz-Software vergleichen, aber ich habe den Eindruck, dass diese Aussage fuer
Deswegen hatte ich weiter unten in meinem Posting einmal TP 5.5
erwaehnt, was in etwa dem aktuellen
Linux-(Freeware-)Entwicklungsumgebungsstand entspricht und mittlerweile
ebenfalls kostenlos bzw. billig erhaeltlich ist (bei Pearl ??).
> Unix allgemein und auch fuer kommerzielle Entwicklungstools gilt (ich kenne
> allerdings nur Linux, HP-Ux, Unicos und Irix - und darunter wieder nur ein paar
> Compiler/Entwicklungsumgebungen)
Ich kenne keine Unix-Entwicklungssysteme aus eigener Erfahrung, vermute
aber, dass sie nicht fuer den Preis erhaeltlich sind, der unter Windows
ueblich ist ( 300 - 5000 DM ). Und Preise darueber, sind fuer den
Hobbyprogrammierer inakzeptabel.
> > Da solche Oberflaeche aus Gruenden
> > der Produktivitaet nicht selbst programmiert werden koennen, ist man auf
> > meist kommerzielle Klassenbibliotheken (sowohl unter Windows, als auch
> > Linux) angewiesen.
>
> Gibt es denn solche fuer Linux, die vielleicht auch noch portabel sind ?
Sorry ueber meine unklare Ausdrucksweise; ich hatte hier an Motif & Co.
gedacht, aber nicht beachtet, dass es zwar Bibliotheken sind, aber
herzlich wenig mit Klassen zu tun haben ...
> > Ein anderer Aspekt ist auch die Nutzung bereits vorhandener Programme.
> > Hier hat Microsoft aufgrund seiner Monopolstellung die 2
> > leistungsfaehige Standards DDE und OLE gesetzt.
>
> Ich kenne mich in der Hinsicht nicht aus - aber kann man nicht TCP/IP statt
> DDE verwenden ? Ich weiss, dass z.B. das Visualisierungstool AVS diese
> Funktionalitaet durch TCP/IP umsetzt...
Die X-Kommunikation geschieht ueber das Netzwerkprotokoll TCP/IP
(deswegen ist auch zum Betrieb von X zumindest ein dummy-Netzwerktreiber
noetig). DDE und OLE sind Standards, welche vorschrieben, wie etwas
uebermittelt werden soll; der eigentliche Transport ist hier egal. Er
geschieht unter Windows entweder direkt via API oder bei NetDDE ueber
NetBEUI.
Ich persoenlich brauche DDE eigentlich weniger, obwohl es schon angenehm
ist, gepackte Dateien einfach ins Packprogramm zu ziehen.
Mit OLE sieht es hingegen schon anders aus.Um z.B. eine Animation in ein
Dokument einzubinden (ueber den Sinn kann man streiten), hat man
meistens keine Zeit, das Rad neu zu erfinden, sondern ist auf bereits
vorhandene Programme angewiesen. Da unter Linux aber jedes seine eigene
Bedienphilosophie besitzt, ist entweder Konfigurationsarbeit faellig,
welche fuer den Null-Ahnung-Nutzer unzumutbar ist (meine Mutter stoehnt
schon, wenn sie mal den Videorekorder programmieren soll!), oder die
Einbindung geschieht ueber festgelegte Schnittstellen (OLE!). Und diese
Schnittstellen sollten fuer alle Programme gleich sein; ansonsten sind
bei Programmieren tausende, sich hoechstwahrscheinlich widersprechende,
Spezifikationen zu beachten.
Bye ... ESC
Enrico Scholz
Frank Roscher wrote:
>
> Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
> : Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> : weitem nicht die unter Win95 erreicht.
>
> "die Produktivitaet" sondern "meine Produktivitaet" scheiben.
Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
Anwendungen messen koennen (abgesehen von den vielen
Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
verdanken) ?
Das einzige, mit Window vergleichbare, professionell aussehende
Programm, was mir momentan einfaellt, ist der Netscape
Communicator/Navigator.
Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
Linux Programme machen ihre komplizierte und meist unlogische Bedienung
durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
wett.
Sie beinhalten zwar meist genauso viele Funktionen wie entsprechende
Windows-Programme, jedoch sind diese schwerer zu finden. Heute ist es
(leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
"normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
besten Features, wenn man sie nicht findet ?
Linux Programme sind ebenfalls weitaus stabiler (Stichword Word97). Dies
hat aber damit zu tun, dass diese Programme seit vielen Jahren mit Hilfe
vieler Leute lediglich gewartet und von Fehlern bereinigt werden.
Kommerzielle Window Anwendungen muessen aber so zeitig wie moeglich
fertig werden und kommen deswegen ueber den Beta-Status selten hinweg;
besitzen aber stets neue Extras und eine noch intuitiv bedienbarere
Oberflaeche.
> : Auch hierbei ist Linux leider im Hintertreffen; ´gdb´ kann sich in
> : Verbindung mit ´ddd´ evtl. gerade mit Turbo Pascal 5.5 messen.
>
> Ich kenne zwar TurboPascal 5.5 nicht, aber ich vermisse an gdb recht wenig.
Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
dort den Inhalt einer Variablen zu ueberwachen?
Ich mache es folgendermassen: Ich oeffne die jeweilige Datei (je nach
"IDE" unterschiedlich langwierig), suche die entsprechende Stelle, MERKE
mir die Position, gehe in ein xterm-Fenster, ´make´, rufe ´gdb ...´ auf,
gebe ´b ....:...´ ein, starte mit ´r parameter1 parameter2 ...´. -->
stop --> ´print langer_variablen_name´
Unter TP geht es folgendermassen: Einmaliges Festlegen der Parameter,
oeffnen der Datei via F3, Suchen der entsprechenden Stelle, Breakpoint
setzen (CTRL-F8), Programm starten (CTRL-F9). --> stop --> einige
CTRL-Right, bzw. ein Mausklick, CTRL-F7, ENTER
Jetzt kann jeder selbst nachrechnen, was laenger dauert!
> [...]
> Das mit dem doppeltem delete hat wohl recht wenig mit dem Debugger zu tun,
> sondern viel mehr mit der Implementierung der dynamischen Speicherverwaltung.
> Ausserdem gibt es Debug libraries mit denen sich solche und andere Fehler
> in der Speicherverwaltung recht schnell finden lassen.
Ok, geb´ ich zu - war mein Fehler.
> : Diese Schwaechen ueberwiegen aufgrund der menschliche Psyche ( das
> : Nichtvorhandene dominiert ), und so erscheint mir ´gdb´ fuer
> : professionelles Arbeiten wenig geeignet.
>
> Das scheint Dir nur so, ich fuehle mich mit einem Debugger wohler, den
> ich auf mehreren Plattformen benutzen kann bedeutend wohler.
Was machst Du denn, dass Du auf so viiiiieeeelen Plattformen entwickelst
?
> [...]
> Also mit native gdb kann ich ncurses wunderbar in einem anderem XTerm oder
> auf einem seriellen Terminal debuggen. ddd kenne ich nicht.
Unter´m reinen ´gdb´ geht das auch direkt. Bei ´ddd´ hab´ ich in einem
anderen Posting die Methode via ´attach´ erfahren, scheitere aber daran,
dass ich meine Symbole nicht laden kann.
> [...]
> : entweder es laeuft, oder man hat Pech gehabt.
>
> "entweder es laeuft ..." - das ist natuerlich fuer professionelles Arbeiten
> sehr gut geeignet.
1. ... laeuft es meistens
2. war teilweise ironisch gemeint (ich verwende nicht gerne Smilies)
> [...]
> Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
> die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
ankommt, keine gute Einstellung.
2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
noch mit OWL ...)
> [...]
> Ich brauche eine Entwicklungsumgebung in der ich zurechtkomme, da muss
> sich niemand anderes ransetzen.
Und wenn Du derjenige bist, der an einer anderen arbeiten muss ?
> [...]
> : z.B. geschieht bei der VC-IDE das Einruecken stets in
> : Tabulator-Schrittweite, welche, dem allgemeinen Standard folgend,
> : natuerlich auf 4 Zeichen gesetzt ist.
>
> Aha in welchem Standard steht, das die Tabulatorweite 4 Zeichen ist?
Dies war ebenfalls ironisch gemeint und ich dachte eigentlich, dass man
das auch erkennt. Naja - da muss ich wohl an meinen hellseheriscehn
Faehigkeiten noch etwas arbeiten ...
Bye ... ESC
Jochen Schmitt
Andreas Keese <A.K...@tu-bs.de> wrote:
>Gibt es denn solche fuer Linux, die vielleicht auch noch portabel sind ?
Ja, z. B. Qt, wobei Du für Windows eine kommerzeille Lizenz brauchst.
mfg: Jochen Schmitt
Jochen Schmitt
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
>Linux) angewiesen. Diese besitzen allerdings kaum vollstaendig
>beherrschbare Sprachbausteine, so dass man gewisse Teile der
>Codegenerierung automatisieren muss. Darunter verstehe ich z.B. das
>"Zusammenklichen" von Fenstern und Dialogbausteinen.
>Dabei sieht es aber unter Linux meines Wissens nach ziemlich duester
>aus; unter Windows hingegen findet man eine Reihe (teilweise
>erschwinglicher) Tools, wie z.B. Delphi, C++ Builder, VC++.
Visual C++ ist, was den Bereich der visuellen Programmierung angeht,
eher armsellig. Es besteht dort zwar die Möglichket, sich ein
Grundgerüst einer Anwendung mit dem Application-Wizard generieren zu
lassen, aber danach gehen die Möglichkeiten dieser
Entwicklungsumgebung nicht viel über die Möglichkeiten eines
Resourceeditros hinaus.
Wenn man unter Windows ein wirklich gute visuelle Entwicklungsumgebung
haben möchte, dann kommen nur Power++ oder Visual Age for C++ in
Frage.
mfg: Jochen Schmitt
Enrico Scholz
Mein voriges Reply war etwas zerknittert rausgegangen (der Apostroph ist
wirklich nicht mehr dort, wo er frueher mal war; naja, jetzt ist er's
wieder), deshalb hier nochmal:
Frank Roscher wrote:
>
> Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
> : Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> : weitem nicht die unter Win95 erreicht.
>
> : Auch hierbei ist Linux leider im Hintertreffen; ´gdb´ kann sich in
> : Verbindung mit ´ddd´ evtl. gerade mit Turbo Pascal 5.5 messen.
>
> Ich kenne zwar TurboPascal 5.5 nicht, aber ich vermisse an gdb recht wenig.
Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
dort den Inhalt einer Variablen zu ueberwachen?
Ich mache es folgendermassen: Ich oeffne die jeweilige Datei (je nach
"IDE" unterschiedlich langwierig), suche die entsprechende Stelle, MERKE
mir die Position, gehe in ein xterm-Fenster, ´make´, rufe ´gdb ...´ auf,
gebe ´b ....:...´ ein, starte mit ´r parameter1 parameter2 ...´. -->
stop --> ´print langer_variablen_name´
Unter TP geht es folgendermassen: Einmaliges Festlegen der Parameter,
oeffnen der Datei via F3, Suchen der entsprechenden Stelle, Breakpoint
setzen (CTRL-F8), Programm starten (CTRL-F9). --> stop --> einige
CTRL-Right, bzw. ein Mausklick, CTRL-F7, ENTER
Jetzt kann jeder selbst nachrechnen, was laenger dauert!
> [...]
> Das mit dem doppeltem delete hat wohl recht wenig mit dem Debugger zu tun,
> sondern viel mehr mit der Implementierung der dynamischen Speicherverwaltung.
> Ausserdem gibt es Debug libraries mit denen sich solche und andere Fehler
> in der Speicherverwaltung recht schnell finden lassen.
Ok, geb´ ich zu - war mein Fehler.
> : Diese Schwaechen ueberwiegen aufgrund der menschliche Psyche ( das
> : Nichtvorhandene dominiert ), und so erscheint mir ´gdb´ fuer
> : professionelles Arbeiten wenig geeignet.
>
> Das scheint Dir nur so, ich fuehle mich mit einem Debugger wohler, den
> ich auf mehreren Plattformen benutzen kann bedeutend wohler.
Was machst Du denn, dass Du auf so viiiiieeeelen Plattformen entwickelst
?
> [...]
> Also mit native gdb kann ich ncurses wunderbar in einem anderem XTerm oder
> auf einem seriellen Terminal debuggen. ddd kenne ich nicht.
Unter´m reinen ´gdb´ geht das auch direkt. Bei ´ddd´ hab´ ich in einem
anderen Posting die Methode via ´attach´ erfahren, scheitere aber daran,
dass ich meine Symbole nicht laden kann.
> [...]
> : entweder es laeuft, oder man hat Pech gehabt.
>
> "entweder es laeuft ..." - das ist natuerlich fuer professionelles Arbeiten
> sehr gut geeignet.
1. laeuft es meistens und
2. war es teilweise ironisch gemeint (ich verwende nicht gerne Smilies)
> [...]
> Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
> die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
ankommt, keine gute Einstellung.
2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
noch mit OWL ...)
> [...]
> Ich brauche eine Entwicklungsumgebung in der ich zurechtkomme, da muss
> sich niemand anderes ransetzen.
Und wenn Du derjenige bist, der an einer anderen arbeiten muss ?
> [...]
> : z.B. geschieht bei der VC-IDE das Einruecken stets in
> : Tabulator-Schrittweite, welche, dem allgemeinen Standard folgend,
> : natuerlich auf 4 Zeichen gesetzt ist.
>
Nils Bokermann
Andreas Keese <A.K...@tu-bs.de> writes:
> Oliver Bandel wrote:
>
> > > zuerstmal muss ich vorausschicken, dass ich - was das Programmieren
> > > angeht - von Visual-C verwoehnt bin. Leider muss ich jetzt unter Unix
> > > Software entwickeln :-(
> > tse tse tse... was ist das denn für ein Schwachsinn?
>
> Hmm, ich glaube, Du hast meine Mail nicht gelesen.
>
> > Versuchs mal mit dem Komando "apropos".
>
> Toll, genau diese Philosophie stoert mich an Unix. Man muss man sich quaelen,
> darf keine komfortablen Umgebungen benutzen, denn das waere ja uncool und
> ueberhaupt zu Microsoft-artig. Wer nicht mindestens tausend
> .xxxx-Konfigurationssprachen und zweitausend Kommandoparameter lernen will,
> sollte gleich bei Windows bleiben. Ohnehin ist ja Microsoft deshalb gross,
> weil sie boese sind, und sie sind boese, weil sie gross sind, und daher
> redet jeder, der ein Produkt von denen mag, Schwachsinn... Logisch.
Die meisten Sprachen (die ich kenne) haben eine gewisse "Ahnlichkeit. In 20
min wei"st du genug um ein Makefile zusammenzuflicken, nach weiteren 10 min
kannst du dank den sgml-tools deine Doku in den verschiedenen Formaten
entwickeln (C, C++, Fortran und command.com(Arghl) kannst du ja eh schon) da
ist es kein gro"ses Problem sich gerade noch die Grundbegriffe der
Shell-Programmierung reinzutun (Wenn man nicht so ein Trottel ist wie ich einer
bin, ich brauch halt f"ur alles doppelt so lange).
>
> Unter Unix artet jede noch so kleine Aufgabe gleich in Riesenaufwand aus -
> letztens hab ich mir ein Makefile geschrieben - und dafuer reicht es
> natuerlich nicht, erstmal diese komische Make-Sprache zu lernen - nein, um
> das anstaendig zu machen, muss man auch gleich noch sed lernen :-( Das dauert
> mir alles zu lange. Unter VisualC kann ich einfach die Dateien ins Projekt
> ziehen und kompilieren.
Ok, regualar-expression sind so eine Sache f"ur sich. Wer _alle_
M"oglichkeiten kennt darf sich melden. Wer mit sed ein paar strings vertauscht
sollte sich besser nicht melden, sonst ist das .de-Backbone die n"achsten 14
Tage dicht :-)
>
> > Das gibt Dir den Überblick.
>
> Vielleicht solltest Du Mails nicht nach dem ersten Absatz beantworten,
> sondern weiter lesen ?
>
> Sorry, wenn sich mein Text etwas veraergert anhoert - aber seit ich mich mit
> Unix beschaeftige, habe ich den Eindruck, dass sich einige Unix-Apostel etwas
> erhaben fuehlen, weil sie in der Lage sind, mit tausend kryptischen
> Konfigurationsdateien und Kommandozeilenparametern umzugehen und nicht noetig
> haben, mit neumodischem Bloedsinn wie Maus und Fenstern umgehen zu muessen.
> Anstatt zu maulen und ausfallend zu werden, wannimmer das Wort Microsoft
> faellt, sollte man sich mal Gedanken darueber machen, warum deren Produkte
> erfolgreicher sind als Unix. In der Unix-Welt scheint der Glaube
> vorzuherrschen, dass die Mehrheit der Menschen schwachsinnig sei und nur die
> Unix-Apostel die Weisheit gefressen haben ?
Das ist es (hoffentlich) nicht. Jeder kann mit dem Umgehen was er gelernt hat
(Siehe hierzu auch die regelm"a"sig aufflammende Editor-Flame-Wars). Unix und
Dos(im weiteren Sinne) unterscheiden sich in ihrer gedanklichen Struktur
vollst"andig voneinander.
Unter Dos bietet _jedes_ Tool seine vollst"andige Oberfl"ache, i.e.\ der
C-Compiler kommt mit _seinem_ Editor und _seinen_ Shortcuts (1xlernen, oder
klicken); die Textverarbeitung (sei sie gut oder schlecht) kommt mit einem
_anderen_ Editor mit _anderen_ Shortcuts.
Unix dagegen setzt auf eine individuelle Zusammenstellung der verschiedenen
_kleinen_ Tools. Jeder mag seinen Editor benutzen -- sei es zur Erstellung von
Texten oder Programmen (was letztendlich auch nur Texte einer bestimmten
Formatierung sind). Dabei braucht er den Editor nicht einmal zu verlassen,
wenn er meint zwischendurch mal einen Text zu schreiben (Dann lohnen sich auch
gr"o"sere Editoren a'la (X)Emacs).
Mit Hilfe des Pipe und redirect Konzepts k"onnen die vielen kleinen
hochspezialiesierten Tools zu hocheffektiven ``Programmen'' zusammengestellt
werden, die Dinge leisten, die trotz Drag'n'Drop und Oberfl"ache unter Dos nur
mit M"uhe erreichbar sind. (Typisches Beispiel w"are: in allen Dateien mit der
Endung \.c, die String "a" enthalten soll String "b" durch String "c" ersetzt
werden (In allen Unterverzeichnissen selbstredend auch). Dies ist IMO _kein_
an den Haaren herbeigezogenes Problem, sondern ergibt sich beim Programmieren
schon ab und zu -- Bis auf das Problem, da"s ich's immer erst bei der
vorletzten Datei merke ;-)
Tsch"u"s, Nils
P.S.: Tu dir die Einarbeitungsschwierigkeiten an (Kauf dir daf"ur das eine
oder andere Buch), du wirst es sicherlich nicht bereuen. Der Unix-Ansatz ist
IMHO wesentlich m"achtiger.
Stefan Hornburg
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> writes:
> Frank Roscher wrote:
> > =
> > Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
> > : Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> > : weitem nicht die unter Win95 erreicht.
> > =
> > Meinst Du das wirklich ernst? Falls ja solltest Du vielleicht nicht
> > "die Produktivitaet" sondern "meine Produktivitaet" scheiben.
> =
> Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
> warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
> Anwendungen messen koennen (abgesehen von den vielen
> Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
> verdanken) ?
> Das einzige, mit Window vergleichbare, professionell aussehende
> Programm, was mir momentan einfaellt, ist der Netscape
> Communicator/Navigator.
> =
> Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
> Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
> wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
> mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
>
Gerade kleinere Tools kann man gut mit Tk erstellen. Die funktionieren
dann prinzipiell noch auf W32/Mac-Maschinen. Einen Builder gibt es da
auch.
=
[...]
> > [...]
> > Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
> > die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
> =
> 1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
> ankommt, keine gute Einstellung.
> 2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
> aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
> noch mit OWL ...)
>
Schnell viel Schrott produzieren ...
[...]
Ciao =
Racke
-- =
Hier l=E4uft Linux 2.0.29.
Paketmanager ist RPM 2.4.10.
Tips und Tricks f=FCr Linuxanwender: http://www.han.de/~racke/trove.html =
Mario Hoerich
# in...@azurix.rz.tu-clausthal.de (Christian Perle) wrote:
>Bei Windows hast Du ja noch nicht mal vollstaendige Doku. Dann doch
>lieber umfangreiche Manpages.
Stimmt schon, nur in vielen Fällen ist man eben da nicht auf die Doku
angewiesen. (Ich zumindest nicht)
>df (diskfree)
Ahaaaa (eigentlich ja ganz logisch ...)
Danke !
>Arbeitest vielleicht immer als Root? Dann waers kein Wunder.
Mmmh ... damit hab ich mir mein System EINmal abgeschossen, allerdings
die anderen Male verschwand der Lilo *irgendwie* aus dem MBR. Aus
irgendwelchen Gründen funktionieren die Bootdisks nie (Fehler 0x01
oder sowas in der Art) :((( . Wenn ich mit den Installdisks hochboote
bekomm ich zwar meine "herrenlose" Partition gemountet, beim manuellen
Reinstall des Lilo schmeißt der allerdings mit Fehlern um sich ...
(Wahrscheinlich weil der Path dann nicht mehr richtig sitzt ... wie
auch, ich muß die Partition ja in 'nem _zusätzlichen_ Verzeichnis
mounten )
>Welche Distribution hast Du?
DLD 5.2
MfG
Mario
-
PGP 0xA1B2E9B5 [2.6.3]
-
EHE : Errare Humanum Est
Mario Hoerich
# jou <j...@gmx.net> wrote:
>Fuer umsteiger ist es hart (war ich ja auch mal), aber bald wirst du die
>in-sich konsistebz lieben lernen..
>Der support ist ungeschlagen
Hab ich auch schon gemerkt.
>Hast du die inittab und bootscripts zur nichtbootfaehigkeit veraehndet
>oder einfach nur eine falsche option im kernel gehabt ?
Weder noch (siehe anderes Posting im gleichen Thread)
>Die inittab ruehren selbst power user vorsichtig an, ein passender
>fehler und das wars..
Die gesamten /etc Scripts ruehr ich nur mit außerster Vorsicht an.
(Gans blöt bin ich ja nun auch nicht ;)
Mario Hoerich
# for...@mynock.org (forcer) wrote:
>>[erschlagende Manpages]
>man tar
>listet 23 zeilen parameter. Ich brauche kaum mehr als xzf, gelegentlich auch
>ohne z. Seltenst mal ein -C. Das ist das schoene unter Linux/UNIX: Du musst
>nicht alles lesen, was dir angeboten wird, aber wenn du es brauchst, findest
>du auch infos darueber.
benutzen mußt. Wenn ich das nicht weiß hab ich schlechte Karten (kann
ja im Prinzip 'ne ganze Masse sein).
>>["totes" Linux :( ]
>eigenes unwissen als nachteil des OS zu sehen, ist nicht in ordnung.
Ich hab ja auch nie behauptet, daß es nicht _mein_ Fehler ist ;)
Ich hab damit lediglich sagen wollen, daß ein Anfänger mangels
Überblick eher Fehler macht.
>jedem anderen auch. Unter Linux darfst du niemals aufgeben. Wenn etwas nicht
>klappt, weiterprobieren (oder eher weiter RTFMen)... Ich habe mir letztens
>mit einem upgrade von libc5 auf glibc2 mein system halb untauglich gemacht,
>aber das lag an meiner dummheit, nicht an linux. Und nach einem tag rum-
>werkeln lief das ding auch wieder einwandfrei, und ich habe nicht mal
>rebootet.
Ja, die Arbeitsstabilität ist wahrhaftig --->GENIAL<---
>"GNU beim Fenstertest zu eNTe geworden !"
ROTFL !
Mfg
Mario
Mario Hoerich
# Dirk Moebius <Dirk.M...@bln.sel.alcatel.de> wrote:
>Ein Zweck ist z.B. die weitgehende Automatisierung von Abläufen (Stichwort
>crontab, shell scripts).
>
>Kannst Du windisk oder winzip im Hintergrund oder automatisch starten und ihm
>gleich alle benötigten Anweisungen mitgeben?
Nö.
Die zeitgesteuerten Abläufe sind schon 'ne Klasse Sache (soweit ich
das aus dem "trockenen" einschätzen kann).
Mfg
forcer
On 25 Nov 1997 07:47:20 GMT, Sascha BohnenkampIch lerne gerne... wieso grep??
forcer
On Tue, 25 Nov 1997 19:30:07 +0100, Enrico Scholz
<enrico...@wirtschaft.tu-chemnitz.de> wrote:
>Frank Roscher wrote:
>>
>> Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
>> : Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
>> : weitem nicht die unter Win95 erreicht.
>>
>> Meinst Du das wirklich ernst? Falls ja solltest Du vielleicht nicht
>> "die Produktivitaet" sondern "meine Produktivitaet" scheiben.
>
>Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
>warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
>Anwendungen messen koennen (abgesehen von den vielen
>Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
>verdanken) ?
sondern DAS es ihn verrichtet.
>Das einzige, mit Window vergleichbare, professionell aussehende
>Programm, was mir momentan einfaellt, ist der Netscape
>Communicator/Navigator.
aber professionell... naja, definitonssachen.
Professionelle programme? gcc, emacs, TeX, die zahlreichen webserver, ...
Sorry, nein, kaum mir bekannte klickibunti programme, die ihre
professionalitaet aus der "einfachen" Bedienung herleiten, die zwar fuer den
Anfaenger gut ist, aber sobald man sich mit dem Programm auskennt, doch
eher hinderlich ist.
Obwohl sich das mit KDE ja aendern koennte. (ich hoffe nicht).
>
>Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
>Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
>wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
>mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
>
tcl/tk, perl/tk.
Und was meinst du mit bescheiden? keine fuenfzig rotierende icons? ;)
ernsthaft, was meinst du warum linux auch mit X so schnell ist im
gegensatz zu windows. Bei aller liebe, um einen derartigen Unterschied zu
erreichen, muss microsoft wirklich MIST gebaut haben (ja, habensie, ok).
IMHO liegt das an dem ungeheuren ressourcenhunger der programme (und daran,
das windows das ineffizienter handhabt;)
>Linux Programme machen ihre komplizierte und meist unlogische Bedienung
>durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
>wett.
Windows Programme machen ihre featuritis und software bloat durch bugginess
und extreme langsamkeit eindeutig NICHT wett ;)
Und kompliziert/unlogisch ist hier wirklich ansichtssache.
>Sie beinhalten zwar meist genauso viele Funktionen wie entsprechende
>Windows-Programme, jedoch sind diese schwerer zu finden. Heute ist es
>(leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
>welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
>"normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
>grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
>ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
>besten Features, wenn man sie nicht findet ?
>Linux Programme sind ebenfalls weitaus stabiler (Stichword Word97). Dies
>hat aber damit zu tun, dass diese Programme seit vielen Jahren mit Hilfe
>vieler Leute lediglich gewartet und von Fehlern bereinigt werden.
>Kommerzielle Window Anwendungen muessen aber so zeitig wie moeglich
>fertig werden und kommen deswegen ueber den Beta-Status selten hinweg;
>besitzen aber stets neue Extras und eine noch intuitiv bedienbarere
>Oberflaeche.
aehh... "noch intuitivere" ????? naja.... fuer den anfaenger, der profi hat
immer mehr probleme. Und was will ich mit 20 neuen features, die kein mensch
braucht, weil man 90% der alten noch nichtmal gebraucht hat??? Und an windows
features kommt man auch nicht soo problemlos ran.
Mehrere != viele. Ich weiss nicht, was er macht, aber es langt wenn er
auf PPC's und Suns arbeitet, plus x86er.
>
>> [...]
>> Also mit native gdb kann ich ncurses wunderbar in einem anderem XTerm oder
>> auf einem seriellen Terminal debuggen. ddd kenne ich nicht.
>
>Unter´m reinen ´gdb´ geht das auch direkt. Bei ´ddd´ hab´ ich in einem
>anderen Posting die Methode via ´attach´ erfahren, scheitere aber daran,
>dass ich meine Symbole nicht laden kann.
>
>> [...]
>> : entweder es laeuft, oder man hat Pech gehabt.
>>
>> "entweder es laeuft ..." - das ist natuerlich fuer professionelles Arbeiten
>> sehr gut geeignet.
>
>1. ... laeuft es meistens
... wenn man nichts eigenes macht ...
>2. war teilweise ironisch gemeint (ich verwende nicht gerne Smilies)
probiere *sarcasm* oder *ironie*
>
>> [...]
>> Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
>> die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
>
>1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
>ankommt, keine gute Einstellung.
So entstehen programme wie Word97 und IE4.0. Schnell da, mit so vielen bugs
und dermassen langsam, dass sie eigentlich schnell wieder weg sollten :)
>2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
>aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
>noch mit OWL ...)
... ist das bei professionellen Softwareentwicklung keine gute Einstellung.
;)
>> [...]
>> Ich brauche eine Entwicklungsumgebung in der ich zurechtkomme, da muss
>> sich niemand anderes ransetzen.
>
>Und wenn Du derjenige bist, der an einer anderen arbeiten muss ?
Wieso? source code is portable, wenn jeder seine eigen umgebung hat??
>
>> [...]
>> : z.B. geschieht bei der VC-IDE das Einruecken stets in
>> : Tabulator-Schrittweite, welche, dem allgemeinen Standard folgend,
>> : natuerlich auf 4 Zeichen gesetzt ist.
>>
>> Aha in welchem Standard steht, das die Tabulatorweite 4 Zeichen ist?
>
>Dies war ebenfalls ironisch gemeint und ich dachte eigentlich, dass man
>das auch erkennt. Naja - da muss ich wohl an meinen hellseheriscehn
>Faehigkeiten noch etwas arbeiten ...
Naja, wenn man einen ernsten text schreibt, kann man nicht erwarten, dass das
sofort als ironie erkannt wird.
;)
forcer
On Mon, 24 Nov 1997 13:27:25 GMT, Michael Hoennig <mhoe...@on-line.de> wrote:
>Moin Moin,
>
>> Der gcc ist nicht kommerziell, wenn du 'teure' Tools haben willst,
>> dann kauf doch auch teure Software ... d.h. es gibt auch kommerzielle
>> Systeme fuer Linux.
>
>Darum geht es gar nicht, sondern es geht darum, daß immer
>behauptet wird, daß Microsoft nur schlechte Sachen macht.
>Und das stimmt eben nicht! Diese Meinung kommt nur durch die
>Haß-Brille MS gegenüber. Ob mir das gefällt oder nicht,
>ist ein ganz anderes Ding (mir gefällt es nicht). Irgendwann
>kommt das große Erwachen und Microsoft rules the world!
Hmm... das war doch vorgestern?
Btw, ich kenne wirklich kein groesseres tool von microsoft, das nicht
uebermaessig buggy ist. Und ich finde nicht alles schlecht, nur weils von
M$ kommt, ich mag INTERLNK.EXE, zum beispiel ;)
-forcer
-- ( achtung, posting leidet an akuter ironie ) --
Anselm Lingnau
Im Artikel <347B0982...@wirtschaft.tu-chemnitz.de> schrieb
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de>:
> Die X-Kommunikation geschieht ueber das Netzwerkprotokoll TCP/IP
> (deswegen ist auch zum Betrieb von X zumindest ein dummy-Netzwerktreiber
> noetig). DDE und OLE sind Standards, welche vorschrieben, wie etwas
> uebermittelt werden soll; der eigentliche Transport ist hier egal. Er
> geschieht unter Windows entweder direkt via API oder bei NetDDE ueber
> NetBEUI.
Auch X ist vom Netzwerkdienst unabhängig; zwischen verschiedenen
Maschinen wird meist TCP/IP benutzt, aber DECnet tut's bei manchen
Implementierungen notfalls auch. Wenn Server und Clients auf derselben
Maschine laufen, kann man Unix-Domain-Sockets oder gar shared memory für
die Kommunikation verwenden. Einen dummy-Netzwerktreiber braucht man
jedenfalls nicht.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
PCC may have been a pretty good compiler in its day, but its day was Version 6
UNIX on a PDP-11, when 24K was a lot of memory, 10 MB was a lot of disk space,
and ten thousand instructions per second was fast. --- Chris Torek
Anselm Lingnau
Im Artikel <347B192F...@wirtschaft.tu-chemnitz.de> schrieb
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de>:
> Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
> Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
> wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
> mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
Das kann nur jemand behaupten, der Tcl/Tk nicht kennt. Ein Vorteil von
Tcl/Tk-Programmen ist, daß sie nicht (wie Delphi-Programme) bloß auf
Windows laufen, sondern auf jedem erwähnenswerten Unix, auf Windows und
auf dem Macintosh -- und das ohne Neuübersetzung!
> Linux Programme sind ebenfalls weitaus stabiler (Stichword Word97). Dies
> hat aber damit zu tun, dass diese Programme seit vielen Jahren mit Hilfe
> vieler Leute lediglich gewartet und von Fehlern bereinigt werden.
> Kommerzielle Window Anwendungen muessen aber so zeitig wie moeglich
> fertig werden und kommen deswegen ueber den Beta-Status selten hinweg;
> besitzen aber stets neue Extras und eine noch intuitiv bedienbarere
> Oberflaeche.
Was hast Du lieber: ein stabiles, weitgehend fehlerfreies Programm oder
eins im permanenten Beta-Test mit Extras, die *Du* persönlich
wahrscheinlich nie brauchst (und die vermutlich eh nicht richtig
funktionieren, weil das Programm sich noch im Beta-Test befindet)?
Siehste, hatte ich's mir doch gedacht. :^)
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Technology is a gift of God. After the gift of life it is perhaps the greatest
of God's gifts. It is the mother of civilizations, of arts and of sciences.
--- Freeman Dyson, *Infinite in All Directions*
Anselm Lingnau
Im Artikel <e44_971...@antares.antar.com> schrieb
Marco Budde <Marco...@hqsys.antar.com>:
> Was ist an make bitte komisch? Das ist ein Standard.
Wer hat gesagt, daß Standards nicht komisch sein dürfen? Beispiele dafür
gibt es genug.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Learning to drive a car is a lot easier than learning to play the fiddle. And
it's a lot safer, too. --- Kevin Burke (Attr.)
Ulrich Eckhardt
Enrico Scholz wrote:
>
> Frank Roscher wrote:
> >
> > Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
> > : Was ich aber bemerke, ist, dass die Produktivitaet unter Linux bei
> > : weitem nicht die unter Win95 erreicht.
> >
> > Meinst Du das wirklich ernst? Falls ja solltest Du vielleicht nicht
> > "die Produktivitaet" sondern "meine Produktivitaet" scheiben.
>
> Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
> warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
> Anwendungen messen koennen (abgesehen von den vielen
> Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
> verdanken) ?
Hi,
das Problem ist hier wohl, dass Linux zur Zeit weniger im Desktop-
bereich als im Serverbereich eingesetzt wird. Wenn man Linux als
Server betreibt, ist eine graphische Oberfläche ziemlich verzichtbar,
da die eigentlich nur Ressourcen frisst. Diese Serveranwendungen
kann man auch mit Visual C++ nicht einfach zusammenklicken. Im
Gegenteil, die Windows API und die Doku von Visual C++ sind in diesem
Bereich besch.. . Ich habe eine Anwendung unter Linux und Windows
programmiert, die einen Barcodescanner über die serielle Schnittstelle
ausliesst und die Daten über Netzwerk an einen Server weiterschickt.
Zur Entwicklung des kompletten Protokolls habe ich unter Linux ca.
2 Wochen gebraucht. Die Portierung auf Windows hat noch mal die
selbe Zeit gebraucht. Das war jetzt z.B. eine Anwendung die sehr
wenig GUI gebraucht hat (nur eine Eingabe für den COM-Port und die
Serveradresse). Derzeit arbeite ich schon 4 Tage daran, dass
ich eine Windowsdruckerausgabe in ein Programm umleiten möchte,
und das Ende ist noch nicht abzusehen. Unter Linux kostet mich
das ungefähr 3 sekunden !.
[...]
> Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
> Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
> wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
> mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
Kleinere Programme lassen sich hervorragend mit TCL/TK schreiben.
> Linux Programme machen ihre komplizierte und meist unlogische Bedienung
> durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
> wett.
> Sie beinhalten zwar meist genauso viele Funktionen wie entsprechende
> Windows-Programme, jedoch sind diese schwerer zu finden.
Die Bedienung ist meist logisch, die komplizierte Konfigurierbarkeit
liegt meist an der riesigen Funktionalität, die meist weit über der
von Windows liegt.
> (leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
> welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
> "normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
> grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
> ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
> besten Features, wenn man sie nicht findet ?
Um Linux zu bedienen, muss man kein Freak sein, man muß lediglich
in der Lage sein, die Doku zu lesen. Wenn du Linux als Desktop
für deine Sekretärin willst, dann installiere ihr halt anstatt
Emacs WordPerfect, ApplixWare oder StarOffice.
> Linux Programme sind ebenfalls weitaus stabiler (Stichword Word97). Dies
> hat aber damit zu tun, dass diese Programme seit vielen Jahren mit Hilfe
> vieler Leute lediglich gewartet und von Fehlern bereinigt werden.
> Kommerzielle Window Anwendungen muessen aber so zeitig wie moeglich
> fertig werden und kommen deswegen ueber den Beta-Status selten hinweg;
> besitzen aber stets neue Extras und eine noch intuitiv bedienbarere
> Oberflaeche.
>
>
Also unsere Sekreärinen haben teilweise die Kriese gekriegt, als wir
WordPerfect 6.0 auf 8.0 upgedatet haben. Statt neuer Extras und noch
"intuitiv bedienbarere Oberflaeche" wünsche ich mir (und auch unsere
Sekretärinen) lieber ein stabieles Programm, dass nicht andauernd
abstürtzt. Das ist nämlich ein furchtbarer Produktivitätskiller !
Ausserdem benutzt die durchschnittliche Sekretärin auch nicht viel
mehr als die WordPad funktionalität.
[...]
>
> Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
> dort den Inhalt einer Variablen zu ueberwachen?
Nimm ddd, klicke auf OpenSource und da in die Zeile, wo du deinen
Breakpoint setzten willst und clicke auf break.
Ich würde sagen, für die Programmvielfalt ist mittlerweile gesorgt,
als IDE kucke dir doch mal WipeOut an :
http://www.softwarebuero.de/wipeout.html
Wobei, für z.B. Datenbankanwendungen zu entwickeln wäre ein Tool
ala Borland Delphi wirklich wünschenswert.
Gruesse
Uli
--
Ulrich Eckhardt mailto:u...@transcom.de
http://people.frankfurt.netsurf.de/uli
Truly great madness can not be achieved without significant
intelligence. (Henrik Tikkanen)
Anke Haeming
Enrico Scholz wrote:
>
> Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
> warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
> Anwendungen messen koennen (abgesehen von den vielen
> Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
> verdanken) ?
Hallo!
Man kann nicht Produktivitaet mit Benutzerfreundlichkeit
gleichsetzen.
Programmierer stellen meist andere Ansprueche an ein Programm
als reine Nutzer. Um ein Programm fuer den ungeuebten Benutzer
komfortabel zu gestalten, muss der Programmierer einiges an Zeit
in Dinge stecken, die fuer ihn selbst unnoetig sind.
Beispiel Windowmanager:
Der fvwm ist wunderbar konfigurierbar, allerdings wird ein
Anfaenger damit erschlagen.
Der Kde-Windowmanager hingegen ist ueber Menues zu konfigurieren,
hat allerdings nicht so viele Konfigurationsmoeglichkeiten.
Welcher der beiden ist nun besser?
Tschuess,
Anke
Andreas Keese
Jochen Schmitt wrote:
> Ja, z. B. Qt, wobei Du für Windows eine kommerzeille Lizenz brauchst.
Kann hier jemand - basierend auf seinen Erfahrungen - Qt empfehlen oder
davon abraten ?
Tschuess,
Andreas
Enrico Scholz
forcer wrote:
> [...]
> >Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
> >warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
> >Anwendungen messen koennen (abgesehen von den vielen
> >Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
> >verdanken) ?
> Es kommt nicht drauf an, WARUM das programm seinen dienst gut verrichtet,
> sondern DAS es ihn verrichtet.
Genau - und das machen viele X-Programme nicht; man denke z.B. an glint
(ach Du Schreck). Adaquate Prograemmchen wuerden via eines virtuelle
Tools unter Window hoechstwahrscheinlich innerhalb einer Stunde
zusammenklickbar sein und besser funktionieren.
Fuer die meisten "einfachen" Dinge, wie sich z.B. einen Ueberblick ueber
gerade angekommene Mails zu beschaffen (eine Standleitung ist schon eine
tolle Sache :) ), bevorzuge ich auch die Kommandozeile ('mail'). Fuer
komplexere Dinge, wie z.B. die Programmentwicklung, ist sie aber
unbrauchbar und nur selten einsetzbar (z.B. fuer 'grep').
> >Das einzige, mit Window vergleichbare, professionell aussehende
> >Programm, was mir momentan einfaellt, ist der Netscape
> >Communicator/Navigator.
> Man markiere "aussehen". Der Netscape ist zwar schoen gross, und macht viel,
> aber professionell... naja, definitonssachen.
Stimmt - er hat auch so seine Macken.
> Professionelle programme? gcc, emacs, TeX, die zahlreichen webserver, ...
> Sorry, nein, kaum mir bekannte klickibunti programme, die ihre
> professionalitaet aus der "einfachen" Bedienung herleiten, die zwar fuer den
> Anfaenger gut ist, aber sobald man sich mit dem Programm auskennt, doch
> eher hinderlich ist.
> Obwohl sich das mit KDE ja aendern koennte. (ich hoffe nicht).
Wie waere es mit leichter Bedienung fuer den Anfaenger und umfangreicher
Konfigurierbarkeit fuer den Profi ?
> >
> >Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
> >Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
> >wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
> >mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
> >
> tcl/tk, perl/tk.
Das sind coole write-once-read-never-Sprachen ...
> Und was meinst du mit bescheiden? keine fuenfzig rotierende icons? ;)
> ernsthaft, was meinst du warum linux auch mit X so schnell ist im
> gegensatz zu windows. Bei aller liebe, um einen derartigen Unterschied zu
> erreichen, muss microsoft wirklich MIST gebaut haben (ja, habensie, ok).
Bestreite ich nicht - nur laesst sich da auf meinem System, dem ich
wegen 'ddd' irgendwann noch mal zusaetzliche 32 MB RAM verpassen werde,
effektivier Programmieren.
> IMHO liegt das an dem ungeheuren ressourcenhunger der programme (und daran,
> das windows das ineffizienter handhabt;)
> >Linux Programme machen ihre komplizierte und meist unlogische Bedienung
> >durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
> >wett.
> Windows Programme machen ihre featuritis und software bloat durch bugginess
> und extreme langsamkeit eindeutig NICHT wett ;)
EINIGE Windows Programme (darunter viele MS-Produkte) sind tatsaechlich
instabil, die meisten verrichten aber ihren Dienst zuverlaessig. Und das
mit der Langsamkeit ist entweder ein Geruecht bzw. auf modernere
X-Programme genauso anwendbar.
> Und kompliziert/unlogisch ist hier wirklich ansichtssache.
Nicht kompliziert ist, wenn die meisten auf Anhieb problemlos
zurechtkommen.
Logische Bedienung ist, wenn in einem Programm eine Tastekombination
eine aehnliche Auswirkung hat, wie in allen anderen.
> [...]
> aehh... "noch intuitivere" ????? naja.... fuer den anfaenger, der profi hat
> immer mehr probleme. Und was will ich mit 20 neuen features, die kein mensch
> braucht, weil man 90% der alten noch nichtmal gebraucht hat???
... Du weisst nur nicht, dass Du sie brauchst ...
> Und an windows
> features kommt man auch nicht soo problemlos ran.
Das ist aber ein allgemeines Software-Problem - Programme werden von
Programmierern geschrieben und nicht den Nutzern, welche sie
schliesslich verwenden. Aber (zumindest bei Windows) wird daran
gearbeitet.
> >
> >Was machst Du denn, dass Du auf so viiiiieeeelen Plattformen entwickelst
> >?
> Mehrere != viele. Ich weiss nicht, was er macht, aber es langt wenn er
> auf PPC's und Suns arbeitet, plus x86er.
Arbeiten ja, aber entwickeln auf mehreren Plattformen? Sowohl auf
Arbeit, als auch privat, arbeite ich auf x86'ern.
> [...]
> >> "entweder es laeuft ..." - das ist natuerlich fuer professionelles Arbeiten
> >> sehr gut geeignet.
> >
> >1. ... laeuft es meistens
> ... wenn man nichts eigenes macht ...
Meine Programme laufen eigentlich ...
> [...]
> >> [...]
> >> Warum? Ich scheibe meinen Code lieber selber und vertraue keinen IDE's
> >> die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
> >
> >1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
> >ankommt, keine gute Einstellung.
> So entstehen programme wie Word97 und IE4.0. Schnell da, mit so vielen bugs
> und dermassen langsam, dass sie eigentlich schnell wieder weg sollten :)
Das spielt aber auf dem Softwaremarkt keine Rolle! Einen IV-Chef, der
entscheidet, welches Programm gekauft wird, interessiert nur die
Wirtschaftlichkeit. Und da spielen z.B. Schulungskosten und
Kompatibilaet eine groessere Rolle, als gelegentlich auftretende
Programmabstuerze (deren Schaden z.B. bei Word97 durch die
Autosave-Funktion kompensiert wird). Und geschwindigkeitsmaessig ist
Word97 auch nicht schlecht beseitet.
> >2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
> >aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
> >noch mit OWL ...)
> ... ist das bei professionellen Softwareentwicklung keine gute Einstellung.
> ;)
Wieso? Ein Mausklick (10 Sekunden) erzeugt mehrere Codezeilen, fuer die
ich unter OWL wahrscheinlich 1 Minute gebraucht haette.
--> 6 fache Entwicklungsgeschwindigkeit!
>
> >> [...]
> >> Ich brauche eine Entwicklungsumgebung in der ich zurechtkomme, da muss
> >> sich niemand anderes ransetzen.
> >
> >Und wenn Du derjenige bist, der an einer anderen arbeiten muss ?
> Wieso? source code is portable, wenn jeder seine eigen umgebung hat??
Aha - Du schleppst also neben dem Quelltext auch Dein ganz persoenlichen
Emacs mit Dir rum?
> [...]
> /* Software is like sex; it's better when it's free - Linus Torvalds */
Im Leben ist nicht umsonst!
Bye ... ESC
Bjoern_Hesse
Andreas Keese <A.K...@tu-bs.de> writes:
> Jochen Schmitt wrote:
>
> > Ja, z. B. Qt, wobei Du f=FCr Windows eine kommerzeille Lizenz brauchst.
>
> Kann hier jemand - basierend auf seinen Erfahrungen - Qt empfehlen oder
> davon abraten ?
oh, oh,.. Jost koennte antworten...
Bjoern
Enrico Scholz
Ulrich Eckhardt wrote:
> [...]
> > Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
> > warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
> > Anwendungen messen koennen (abgesehen von den vielen
> > Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
> > verdanken) ?
>
> Hi,
>
> das Problem ist hier wohl, dass Linux zur Zeit weniger im Desktop-
Genau - das meine ich mit den Vorteilen der Linux-Architektur!
> [...]
> Die Bedienung ist meist logisch,
Was ist an der Bedienung logisch? Ist es etwa logisch, dass unter 'ddd'
vielbenutzte Funktionen, wie z.B. 'next' auf ergonomisch voellig
unsinnige Tastenkombinationen wie CTRL-J gelegt sind? Da bevorzuge ich
doch die unter DOS ueblichen Funktionstasten.
Das einzige Logische/Einheitliche, was ich bisher gefunden habe, ist
z.B. die Verwendung von '/' als Suchoperator und ^A, ^E als Ersatz fuer
Home/End (wieso eigentlich ^A und ^E? ). Ansonsten stimmen verschiedene
Programme selten in der Bedienung ueberein (mit Standardkonfiguration
!).
> die komplizierte Konfigurierbarkeit
> liegt meist an der riesigen Funktionalität, die meist weit über der
> von Windows liegt.
Bei Serveranwendungen sehe ich ein, dass sie am sinnvollsten ueber
Textfiles konfiguriert werden; aber normale Front-End Anwendungen
sollten innerhalb des Programmes einstellbar sein und ueber eine
Standardkonfiguration verfuegen, mit der jeder Nutzer (der
hoechstwahrscheinlich von eine Windows-/Macintosh-Umgebung kommt) etwas
anfangen kann.
>
> > (leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
> > welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
> > "normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
> > grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
> > ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
> > besten Features, wenn man sie nicht findet ?
>
> Um Linux zu bedienen, muss man kein Freak sein, man muß lediglich
> in der Lage sein, die Doku zu lesen.
Soweit, so gut; aber: wer hat Lust, fuer jedes Programm sich erst einmal
durch hunderte Seiten, meist englischsprachiger HOWTO's und Manpages zu
wuehlen?
> Wenn du Linux als Desktop
> für deine Sekretärin willst, dann installiere ihr halt anstatt
> Emacs WordPerfect, ApplixWare oder StarOffice.
Also Anwendungen, die der Bedienphilosophie von Window entsprechen!
> [...]
> Also unsere Sekreärinen haben teilweise die Kriese gekriegt, als wir
> WordPerfect 6.0 auf 8.0 upgedatet haben. Statt neuer Extras und noch
> "intuitiv bedienbarere Oberflaeche" wünsche ich mir (und auch unsere
> Sekretärinen) lieber ein stabieles Programm, dass nicht andauernd
> abstürtzt.
Tja, so ist das halt. Wegen hoeherer Stabilitaet kann man keine
Programme verkaufen; da muss man schon etwas mehr bieten, naemlich mehr
Extras als die Konkurrenz, und das moeglichst zeitig!
> Das ist nämlich ein furchtbarer Produktivitätskiller !
> Ausserdem benutzt die durchschnittliche Sekretärin auch nicht viel
> mehr als die WordPad funktionalität.
Extras muss man nicht unbedingt explizit benutzen - z.B. finde ich die
automatische Absatzformatierung von Word97 toll.
> [...]
> >
> > Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
> > dort den Inhalt einer Variablen zu ueberwachen?
>
> Nimm ddd, klicke auf OpenSource und da in die Zeile, wo du deinen
> Breakpoint setzten willst und clicke auf break.
... dann veraendere den Quelltext, fuege einige Zeilen ein und
kompiliere neu! Wo ist denn jetzt der Breakpoint? Natuerlich nicht dort,
wo Du ihn gerne haettest.
> Ich würde sagen, für die Programmvielfalt ist mittlerweile gesorgt,
> als IDE kucke dir doch mal WipeOut an :
> http://www.softwarebuero.de/wipeout.html
Mal seh'n, wann ich Zeit dafuer habe. Ich persoenlich benutze FTE, was
hier zwar einige wegen seiner stark DOS-lastigen Erscheinung ablehnen
werden (warum eigentlich?). Dieses Programm ist eines der wenigen
positiven Beispiele fuer leistungsfaehige, gut konfigurierbare
Oberflaechen unter X. Es hat zwar auch einige Schwaechen (numerischer
Tastenblock unbenutzbar, CTRL-BACK funktioniert standardmaessig nicht,
Consolenversion braucht Schreibrecht auf /dev/console), welchen aber
wenig in Gewicht fallen.
Bye ... ESC
Andreas Zeller
Hi!
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> writes:
> ´gdb´ kann sich in Verbindung mit ´ddd´ evtl. gerade mit Turbo
> Pascal 5.5 messen. Er bietet zwar eine Menge von Vorteilen, wie
> z.B. core-Files und vor allem Stabilitaet, aber auch Schwaechen
> [...]. ´ddd´ erbt, da es vollstaendig auf ´gdb´ aufsetzt,
> saemtliche Nachteile und bringt noch eigene mit ( das muehsam
> zusammengestellte Datenfenster verschwindet beim Programmende, ´ddd´
> scheint ziemlich hohen Ressourcenbedarf zu besitzen und instabil zu
> sein, das Debuggen von ncurses-Anwendungen ist unmoeglich, die
> Tastenbefehle sind grausam und fuehren bei laengerem Gebrauch zur
> Sehnenscheidenentzuendung ).
Was GDB angeht, kann ich mich anschliessen, aber die Schwaechen von
DDD moechte ich gerne dementieren. In der aktuellen Version 2.2
kannst Du das Datenfenster speichern und wiederherstellen (`Save
Session' oder Cut/Copy/Paste), ncurses-Anwendungen in einem eigenen
xterm ausfuehren (`Run in Execution Window'), Tastenbefehle ignorieren
(dafuer ist ein GUI schliesslich da) und das ganze noch bei deutlich
geringerem Ressourcenverbrauch. Auch Stabilitaet ist kein Problem
(sofern Du nicht LessTif oder eine inkompatible Laufzeit-Bibliothek
benutzt).
--
Andreas Zeller Technische Universitaet Braunschweig, Germany
mailto:zel...@acm.org http://www.cs.tu-bs.de/~zeller/
Anselm Lingnau
Im Artikel <347BEDE4...@wirtschaft.tu-chemnitz.de> schrieb
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de>:
> > Wenn du Linux als Desktop
> > für deine Sekretärin willst, dann installiere ihr halt anstatt
> > Emacs WordPerfect, ApplixWare oder StarOffice.
>
> Also Anwendungen, die der Bedienphilosophie von Window entsprechen!
Die `Bedienphilosophie' von Windows wurde von einem System abgekupfert,
dessen grundlegende Ideen wiederum von einem anderen abgekupfert wurden,
das damals schon fast ein Jahrzehnt auf dem Buckel hatte. Wenn es nur
darum geht, mit einem Zeiger auf dem Bildschirm auf bestimmte sensitive
Felder zu zeigen und Knöpfchen zu drücken, das ist nun wirklich nichts
Besonderes mehr.
Wenn man also unter Linux Programme laufen läßt, die so ähnlich aussehen
und funktionieren wie ähnliche Programme unter Windows, dann ist das
nicht zwangsläufig eine Hommage an die Überlegenheit der (abgekupferten)
`Bedienphilosophie' von Windows, sondern im ersten Moment einfach nur
parallele Evolution und Aufmerksamkeit gegenüber dem, was Benutzer so
erwarten. Wahre Überlegenheit zeigt sich viel eher bei den
Möglichkeiten, die man außerdem noch hat -- und da ist mir ein System
wie Linux, mit dem ich tatsächlich etwas getan kriegen kann und nicht
dauernd an Grenzen stoße, für die der Programmentwickler in seiner
Allwissenheit keinen Button vorgesehen hat, zehnmal lieber als ein
anderes, das vielleicht schön bunt ist, aber mit wenig bis nichts
dahinter (außer viel Ärger und zusätzlichem Zeitaufwand), vielen Dank
auch.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman
Marco Bubke
Hi Jochen
j.sc...@pop-frankfurt.com (Jochen Schmitt) writes:
> Wenn man unter Windows ein wirklich gute visuelle Entwicklungsumgebung
> haben möchte, dann kommen nur Power++ oder Visual Age for C++ in
> Frage.
Schon mal mit Smalltalk oder dem App Builder von
Next-/OpenStep/MacOS?? programmiert. Die koennen sowas schon
wesentlich laenger (und IMHO besser) als die Visual Sonstwas.
--
Marco Bubke - Otto-von-Guericke Universitaet Magdeburg
Email: bu...@cs.uni-magdeburg.de
WWW : http://www-hppool.cs.uni-magdeburg.de/~bubke/
jou
> >Arbeitest vielleicht immer als Root? Dann waers kein Wunder.
> Mmmh ... damit hab ich mir mein System EINmal abgeschossen, allerdings
> die anderen Male verschwand der Lilo *irgendwie* aus dem MBR. Aus
> irgendwelchen Gründen funktionieren die Bootdisks nie (Fehler 0x01
> oder sowas in der Art) :((( . Wenn ich mit den Installdisks hochboote
> bekomm ich zwar meine "herrenlose" Partition gemountet, beim manuellen
> Reinstall des Lilo schmeißt der allerdings mit Fehlern um sich ...
> (Wahrscheinlich weil der Path dann nicht mehr richtig sitzt ... wie
> auch, ich muß die Partition ja in 'nem _zusätzlichen_ Verzeichnis
> mounten )
>
> >Welche Distribution hast Du?
> DLD 5.2
Benutze DLDadmin um eine Bootdisk herzustellen.
Wenn die nicht tut, nimm einen compilierten Kernel und mach:
cat vmlinuz > /dev/fd0
und voilá, eine bootdisk für den fall lilo mal wieder tot ist.
Benutzt du noch ein anderes OS ausser Linux auf der Machine ?.. wenn ja
und wenn M$, dann ist das der Grund fuer deine MBR-Lilo Aufloesungen.
Das ist der Grund warum man ihn moeglichst nicht in den MBR legen sollte
sondern eher in den Superbootblock deine Linux Partition.
JOu.
jou
> Nö.
> Die zeitgesteuerten Abläufe sind schon 'ne Klasse Sache (soweit ich
> das aus dem "trockenen" einschätzen kann).
Mir fehlt das "&" Zeichen am meisten bei non-unixen..
zip -r blah irgwndwas/* &
und weg ist der Task und arbeitet im Hintergrund ohne mich weiter zu
nerven..
Jou.
Andreas Keese
Bjoern_Hesse wrote:
> oh, oh,.. Jost koennte antworten...
Wer ist Jost - muss ich den kennen ?
Tschuess,
Andreas
Jochem Huhmann
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> ("ES") schrieb:
ES> Wieso? Ein Mausklick (10 Sekunden) erzeugt mehrere Codezeilen, fuer die
ES> ich unter OWL wahrscheinlich 1 Minute gebraucht haette.
ES> --> 6 fache Entwicklungsgeschwindigkeit!
*Jetzt* kapiere ich einiges...
>> [...]
>> /* Software is like sex; it's better when it's free - Linus Torvalds */
ES>
ES> Im Leben ist nicht umsonst!
Ach, Du *bezahlst* Deine Freundin/Deinen Freund mit Geld dafuer...?
--
# Jochem Huhmann <j...@gmx.net> Duisburg (Germany)
# PGP fingerprint = 6C 85 FC 93 31 10 4E 81 1F 4C BE 4E 21 72 B3 7B
Jochem Huhmann
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> ("ES") schrieb:
ES> Was ist an der Bedienung logisch? Ist es etwa logisch, dass unter 'ddd'
ES> vielbenutzte Funktionen, wie z.B. 'next' auf ergonomisch voellig
ES> unsinnige Tastenkombinationen wie CTRL-J gelegt sind? Da bevorzuge ich
ES> doch die unter DOS ueblichen Funktionstasten.
ES> Das einzige Logische/Einheitliche, was ich bisher gefunden habe, ist
ES> z.B. die Verwendung von '/' als Suchoperator und ^A, ^E als Ersatz fuer
ES> Home/End (wieso eigentlich ^A und ^E? ). Ansonsten stimmen verschiedene
ES> Programme selten in der Bedienung ueberein (mit Standardkonfiguration
ES> !).
Die allermeisten Programme lehnen sich in Hinsicht auf
Tastenkombinationen an vi oder emacs an. Wenn Du diese beiden Editoren
kennst, wird Du die allermeiste andere Software ziemlich intuitiv
bedienen koennen. Du glaubst gar nicht, wie viele Programme fuer
"abwaertsscrollen" die Taste "J" verwenden. Wer natuerlich aus der
Windows-Ecke kommt, der drueckt ein wenig auf den Funktionstasten herum
und ist verzweifelt, dass sich nix tut. Nur: Funktionstasten sind auf
den diversen Tastaturen der Systeme, auf denen z.B. ddd laeuft
dermassen uneinheitlich, dass man ihre Existenz am besten vergisst. Sie
sind genau das richtige fuer Konfiguration durch den User, weil der
naemlich weiss, an was fuer einer Kiste oder was fuer einem Terminal er
sitzt.
>> die komplizierte Konfigurierbarkeit
>> liegt meist an der riesigen Funktionalität, die meist weit über der
>> von Windows liegt.
ES>
ES> Bei Serveranwendungen sehe ich ein, dass sie am sinnvollsten ueber
ES> Textfiles konfiguriert werden; aber normale Front-End Anwendungen
ES> sollten innerhalb des Programmes einstellbar sein und ueber eine
ES> Standardkonfiguration verfuegen, mit der jeder Nutzer (der
ES> hoechstwahrscheinlich von eine Windows-/Macintosh-Umgebung kommt) etwas
ES> anfangen kann.
Also, ich komme nicht aus der Win/Mac-Umgebung und verbitte mir sowas
(nur um meine Stimme abzugeben ;-).
Ausserdem ist ein User spaetestens dann, wenn er ein, zwei Jahre mit
einem System gearbeitet hat, auch kein Volltrottel mehr. Vielleicht
sollte man sich langsam von der Vorstellung trennen, dass ein Computer
nur Spielzeug ist. Wer mit einer Software *arbeitet* der ist in der
Regel fuer eine moeglichst weitgehende Konfigurationsmoeglichkeit mehr
als dankbar, wenn er sich damit mehr Arbeit ersparen kann, als die paar
Minuten, die es dauert, eine Konfigurationsdatei zu lesen und zu
aendern. Selbst wenn es Stunden dauert, die Software an die
Systemumgebung und Arbeitserfordernisse anzupassen, lohnt sich das,
wenn man damit die naechsten Jahre arbeitet. Einen Emacs probiert man
nicht eben aus und wirft ihn dann wieder weg, wenn eine Woche spaeter
der neueste Super-Duper-Editor auf den Markt geworfen wird.
>> Um Linux zu bedienen, muss man kein Freak sein, man muß lediglich
>> in der Lage sein, die Doku zu lesen.
ES>
ES> Soweit, so gut; aber: wer hat Lust, fuer jedes Programm sich erst einmal
ES> durch hunderte Seiten, meist englischsprachiger HOWTO's und Manpages zu
ES> wuehlen?
Genau das meine ich: Wer mit Computern arbeitet, der probiert nicht
alle paar Tage eine neue Software aus, weil die alte nix taugt (unter
Windows mag das ueblich sein, unter Unix nicht), sondern arbeitet mit
einem paar Dutzend Programme, die im Laufe der Jahre nicht immer wieder
weggeworfen und neuerfunden, sondern erweitert und verbessert werden.
Da ist es voellig angebracht, die Dokumentation zu lesen, weil man das,
was man da lernt, wirklich gebrauchen kann, und zwar laenger als ein
paar Wochen. Diese Einstellung, von der Du da stillschweigend ausgehst,
ist der groesste Produktivitaetskiller ueberhaupt.
>> Wenn du Linux als Desktop
>> für deine Sekretärin willst, dann installiere ihr halt anstatt
>> Emacs WordPerfect, ApplixWare oder StarOffice.
ES>
ES> Also Anwendungen, die der Bedienphilosophie von Window entsprechen!
Tja, ich befuerchte, das Sekretaerinnenproblem ist auch unter Linux
noch nicht geloest (ausser, dass richtige Unix-User keine Sekretaerin
brauchen, fuer sowas haben sie cron und at ;-)
>> [...]
>> Also unsere Sekreärinen haben teilweise die Kriese gekriegt, als wir
>> WordPerfect 6.0 auf 8.0 upgedatet haben. Statt neuer Extras und noch
>> "intuitiv bedienbarere Oberflaeche" wünsche ich mir (und auch unsere
>> Sekretärinen) lieber ein stabieles Programm, dass nicht andauernd
>> abstürtzt.
ES>
ES> Tja, so ist das halt. Wegen hoeherer Stabilitaet kann man keine
ES> Programme verkaufen; da muss man schon etwas mehr bieten, naemlich mehr
ES> Extras als die Konkurrenz, und das moeglichst zeitig!
Dein Problem liegt wahrscheinlich darin, dass die meisten der
Linux-Entwickler ihre Software nicht verkaufen, sondern benutzen wollen
und daher mehr Wert auf Stabilitaet legen, als darauf, mehr Features
als die "Konkurrenz" einzubauen.
Jochem
Peter Suetterlin
In article <slrn67mqkj...@mynock.org>,
for...@mynock.org (forcer) writes:
> Ich lerne gerne... wieso grep??
Um die Kommentar- und Leerzeilen rauszufiltern
Peter
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Peter "Pit" Suetterlin http://www.uni-sw.gwdg.de/~pit
Universitaets-Sternwarte Goettingen
Tel.: +49 551 39-5048 p...@uni-sw.gwdg.de
-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * -- * ...-- * --
Come and see the stars! http://www.kis.uni-freiburg.de/~ps/SFB
Sternfreunde Breisgau e.V. Tel.: +49 7641 3492
__________________________________________________________________________
Jens Dittmar
>>>>> Andreas Keese fragt:
AK> Wer ist Jost - muss ich den kennen ?
Du wirst ihn kennenlernen, dafuer wird er schon selber sorgen! :)
Jens
Enrico Scholz
Jochem Huhmann wrote:
> [...]
> >> /* Software is like sex; it's better when it's free - Linus Torvalds */
> ES> Im Leben ist nicht umsonst!
>
> Ach, Du *bezahlst* Deine Freundin/Deinen Freund mit Geld dafuer...?
Nur ganz kurz: Wenn ich die Zeit, die ich DAMIT verbringe, auf meinen
Stundenlohn hochrechne, waere das naechste Festmahl bei McDonalds
finanziert ... (Schluss damit, das ist jetzt wirklich off topic!)
Bye ... ESC
Jens Dittmar
>>>>> Enrico Scholz pruegelte in sein Terminal:
ES> forcer wrote:
>> >Das einzige, mit Window vergleichbare, professionell aussehende
>> >Programm, was mir momentan einfaellt, ist der Netscape
>> >Communicator/Navigator. Man markiere "aussehen". Der Netscape ist
>> zwar schoen gross, und macht viel, aber professionell... naja,
>> definitonssachen.
Er ist ein Musterbeispiel fuer Dilettantismus. Wobei sich wie so oft die
Frage stellt, ob die Entwickler wirklich so unfaehig sind oder einfach
keinen Bock haben. Wahrscheinlich kann man bei solchen kommerziellen
Schnellschuessen nix brauchbares mehr produzieren.
ES> Nicht kompliziert ist, wenn die meisten auf Anhieb problemlos
ES> zurechtkommen.
Ich will da jetzt nicht zuviel hineininterpretieren, aber das klingt fuer
mich nach "auspacken-einschalten-laeuft". Da muss ich ja beim Fernsehen
mehr nachdenken.
ES> Logische Bedienung ist, wenn in einem Programm
ES> eine Tastekombination eine aehnliche Auswirkung hat, wie in allen
ES> anderen.
Nee, das ist erst mal _konsistente_ Bedienung - die muss deswegen noch
nicht logisch sein.
>> [...] aehh... "noch intuitivere" ????? naja.... fuer den
>> anfaenger, der profi hat immer mehr probleme. Und was will ich mit
>> 20 neuen features, die kein mensch braucht, weil man 90% der alten
>> noch nichtmal gebraucht hat???
ES> ... Du weisst nur nicht, dass Du sie brauchst ...
Wenn ich sehe, wie viele Winword-Benutzer (und auch andere) ihre
Buchstaben auf's Papier meisseln, glaube ich, dass die nicht mal eine
Schreibmaschine von 1930 ausreizen koennten.
ES> Aha - Du schleppst also neben dem Quelltext auch Dein ganz
ES> persoenlichen Emacs mit Dir rum?
Soll ich fuer jeden Host komplett neue Konfigurationsdateien schreiben?
Jens
Dirk Moebius
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> writes:
> Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
> dort den Inhalt einer Variablen zu ueberwachen?
>
> Ich mache es folgendermassen: Ich oeffne die jeweilige Datei (je nach
> "IDE" unterschiedlich langwierig), suche die entsprechende Stelle, MERKE
> mir die Position, gehe in ein xterm-Fenster, ´make´, rufe ´gdb ...´ auf,
> gebe ´b ....:...´ ein, starte mit ´r parameter1 parameter2 ...´. -->
> stop --> ´print langer_variablen_name´
Mensch starte den gdb aus dem emacs.
Breakpoints setzt mensch dann, indem es im source auf der entsprechenden
Zeile ein CTRL-space macht.
Davon abgesehen lädt emacs latürnich files, wenn man in irgendwelche Funktionen
reinstept und zeigt Dir, wo Du stehst...
--
Dirk Moebius ---------------------------------v------- pgp key on request -----
Fax +49 - 30 - 7002 - 3851 ALCATEL Mobile Communication Berlin
Phone +49 - 30 - 7002 - 3577 D-12099 Berlin, Colditzstr. 34
mailto:Dirk.M...@bln.sel.alcatel.de Alcanet moe...@bln.sel.alcatel.de
Enrico Scholz
Jochem Huhmann wrote:
> [...]
> Die allermeisten Programme lehnen sich in Hinsicht auf
> Tastenkombinationen an vi oder emacs an. Wenn Du diese beiden Editoren
> kennst, wird Du die allermeiste andere Software ziemlich intuitiv
> bedienen koennen. Du glaubst gar nicht, wie viele Programme fuer
> "abwaertsscrollen" die Taste "J" verwenden. Wer natuerlich aus der
> Windows-Ecke kommt, der drueckt ein wenig auf den Funktionstasten herum
> und ist verzweifelt, dass sich nix tut. Nur: Funktionstasten sind auf
> den diversen Tastaturen der Systeme, auf denen z.B. ddd laeuft
> dermassen uneinheitlich, dass man ihre Existenz am besten vergisst. Sie
> sind genau das richtige fuer Konfiguration durch den User, weil der
> naemlich weiss, an was fuer einer Kiste oder was fuer einem Terminal er
> sitzt.
Ich weiss die genaue Zahl nicht, aber es duerften wohl mehr als 80%
aller Computer PC's (egal ob Win oder Mac) sein. Diese besitzen alle
Funktions- und Cursortasten, wie wahrscheinlich auch ein Grossteil der
anderen 20%. Was spricht also dagegen, diese auch so zu benutzen, und
zwar so wie es die meisten Benutzer erwarten (ich assoziiere z.B. mit F1
Hilfe, Pfeiltasten -> Cursorbewegung, CTRL-PgUp/PgDn ->
Seitenanfang/-ende usw.). Die evtl. 10% grosse Minderheit (entschuldige,
wenn Du Dich angesprochen fuehlst), welche solche Tasten nicht zur
Verfuegung hat, kann ja immer noch das Programm entsprechend
konfigurieren, was ihnen ja aufgrund ihres Nischenstatuses leichter
fallen duerfte.
Die logische Vorgehensweise waere, dass sich die Minderheit der Mehrheit
anpasst. Im Moment ist es aber gerade andersherum (ok, ich weiss, dass
Unix tradionsreicher als DOS ist und auf Maschinen ohne Tastatur zu
Hause ist, aber eine schrittweise Anpassung waere dringend noetig
gewesen).
> [...]
> Also, ich komme nicht aus der Win/Mac-Umgebung und verbitte mir sowas
> (nur um meine Stimme abzugeben ;-).
Da gehoerst Du aber zu einer Minderheit (siehe oben) ...
> Ausserdem ist ein User spaetestens dann, wenn er ein, zwei Jahre mit
> einem System gearbeitet hat, auch kein Volltrottel mehr. Vielleicht
> sollte man sich langsam von der Vorstellung trennen, dass ein Computer
> nur Spielzeug ist. Wer mit einer Software *arbeitet* der ist in der
> Regel fuer eine moeglichst weitgehende Konfigurationsmoeglichkeit mehr
> als dankbar, wenn er sich damit mehr Arbeit ersparen kann, als die paar
> Minuten, die es dauert, eine Konfigurationsdatei zu lesen und zu
> aendern. Selbst wenn es Stunden dauert, die Software an die
> Systemumgebung und Arbeitserfordernisse anzupassen, lohnt sich das,
> wenn man damit die naechsten Jahre arbeitet. Einen Emacs probiert man
> nicht eben aus und wirft ihn dann wieder weg, wenn eine Woche spaeter
> der neueste Super-Duper-Editor auf den Markt geworfen wird.
Angenommen, Du hast 2 Waschmaschinen, wobei eine im ersten Vierteljahr
riesige Probleme bereitet, aber dafuer 10 Jahre lang laeuft, und die
andere von Anfang an keinerlei Probleme bereitet, aber schon nach 7
Jahren den Geist aufgibt. Welche wuerde die Mehrheit wieder kaufen? -
Maschine Nr. 1 !!
Und genauso ist es mit Software: hier entscheidet die Mehrheit der
(privaten) Nutzer aehnlich. Deswegen bringt auch ein Programm mit
geringerem Funktionsumfang, aber einfacherer Bedienung
hoechstwahrscheinlich hoeheren Gewinn, als ein Vergleichbares mit
mehr/besseren Funktionen, aber hochkomplizierter Bedienung.
Eine nicht zu unterschaetzende Rolle spielt ausserdem die Gewohnheit -
und die meisten Nutzer kommen eben von Win/Mac und sind diese Bedienung
gewoehnt. Es ist hier oekonomisch unsinnig, stur zu bleiben und auf der
von Hand zu editierenden Konfigurationsdatei und den kryptischen
Tastenkombinationen zu bestehen.
> [...]
> Genau das meine ich: Wer mit Computern arbeitet, der probiert nicht
> alle paar Tage eine neue Software aus, weil die alte nix taugt (unter
> Windows mag das ueblich sein, unter Unix nicht), sondern arbeitet mit
> einem paar Dutzend Programme, die im Laufe der Jahre nicht immer wieder
> weggeworfen und neuerfunden, sondern erweitert und verbessert werden.
> Da ist es voellig angebracht, die Dokumentation zu lesen, weil man das,
> was man da lernt, wirklich gebrauchen kann, und zwar laenger als ein
> paar Wochen. Diese Einstellung, von der Du da stillschweigend ausgehst,
> ist der groesste Produktivitaetskiller ueberhaupt.
Diese Einstellung ist aber Tatsache! Die altgedienten Unix-Admins
koennen zwar wahrscheinlich nicht verstehen, wie jemand etwas anderes
als 'vi' benutzen kann, aber das auch nur, weil es damals nichts anderes
gab und sie damit gross geworden sind (--> perfektes Beherrschen).
Der heutige Nutzer, der frisch von Windows kommt, die Schnauze von den
dortigen Unzulaenglichkeiten voll hat und mal Linux probieren will,
trifft normalerweise das erste Mal auf emacs und kehrt, Haende ueber den
Kopf geschlagen, freudestrahlend zu Windows zurueck und nimmt dessen
"kleine" Schwaechen gern in Kauf.
> [...]
> Dein Problem
welches Problem? Mir ist Linux auch viel lieber als Windows, weil es
nach einiger Einarbeitungszeit tatsaechlich mehr Spass macht. Allerdings
stoert mich, dass man hier kaum Chancen hat, seine (Hobby-)Software
gewinnbringend zu verkaufen. Es findet sich naemlich kein
erschwinglichen Compiler+Umgebung dafuer und die GNU-Lizenz ist nicht
gerade der Vermarktung von Software zutraeglich.
> liegt wahrscheinlich darin, dass die meisten der
> Linux-Entwickler ihre Software nicht verkaufen, sondern benutzen wollen
Typisch Informatiker; aber: Geld regiert die Welt !!!
Bye ... ESC
Ulrich Eckhardt
Andreas Keese wrote:
>
> Bjoern_Hesse wrote:
>
> > oh, oh,.. Jost koennte antworten...
>
>
> Andreas
Hi,
du bist wohl noch nicht lange in dieser Gruppe ? Wenn du
irgendow was liest --> TONNE, dann war Jost da.
Frank Roscher
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
: Wenn die allgemeine Produktivitaet unter Linux wirklich hoeher ist,
: warum gibt es dann kaum Programme, welche sich mit entsprechenden Window
: Anwendungen messen koennen (abgesehen von den vielen
: Kommandozeilen-Tools, die ihren Vorteil aber eher der Linux-Architektur
: verdanken) ?
Die Grundphilosophie von UNIX (und damit wohl auch Linux) ist nun einmal die
Toolbox und das Kombinieren von einigen
kleinen/leistungsfaehigen/ueberschauberen/robusten Programmen ist mir halt
lieber als riesige/resourcenfressende/unuebersichtliche/mauslastige Ungetueme.
Aber das ist eben Geschmackssache - Deine Behauptung, das die Arbeitsweise
unter Win* effektiver/schneller ist finde ich aber nach-wie-vor etwas gewagt.
: Das einzige, mit Window vergleichbare, professionell aussehende
^^^^^^^^^^^^^^^^^^^^^^^^
: Programm, was mir momentan einfaellt, ist der Netscape
: Communicator/Navigator.
Mit professionell aussehen hast Du vielleicht recht, aber sonst ... Ich finde
vim, perl, tcl/tk, gdb, gcc, gawk, bash ... aeusserst professionell.
: Insbesondere bei der Entwicklung kleinerer Tools mit graphischer
: Oberflaeche ist Linux unbrauchbar. Was man unter Delphi & Co. mit
: wenigen Mausklicks zusammengebaut hat, braucht unter X wahrscheinlich
: mehrere Stunden und sieht danach immer noch sehr bescheiden aus.
Stichwort tcl/tk.
: Linux Programme machen ihre komplizierte und meist unlogische Bedienung
: durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
: wett.
: Sie beinhalten zwar meist genauso viele Funktionen wie entsprechende
: Windows-Programme, jedoch sind diese schwerer zu finden. Heute ist es
: (leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
: welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
: "normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
: grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
: ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
: besten Features, wenn man sie nicht findet ?
Das hat alles nichts mit UNIX/Linux zu tun sondern hoechstens mit den
Applikationen, ich habe in einer Firma Applixware eingefuehrt und die sind sehr
zufrieden damit.
: Linux Programme sind ebenfalls weitaus stabiler (Stichword Word97). Dies
: hat aber damit zu tun, dass diese Programme seit vielen Jahren mit Hilfe
: vieler Leute lediglich gewartet und von Fehlern bereinigt werden.
: Kommerzielle Window Anwendungen muessen aber so zeitig wie moeglich
: fertig werden und kommen deswegen ueber den Beta-Status selten hinweg;
: besitzen aber stets neue Extras und eine noch intuitiv bedienbarere
: Oberflaeche.
Fuer mich ist die Oberflaeche von Windows Programmen wohl genausowenig intuitiv
wie fuer einen Windows Anwender die Unix-Philosophie.
: Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
: dort den Inhalt einer Variablen zu ueberwachen?
: Ich mache es folgendermassen: Ich oeffne die jeweilige Datei (je nach
: "IDE" unterschiedlich langwierig), suche die entsprechende Stelle, MERKE
: mir die Position, gehe in ein xterm-Fenster, ´make´, rufe ´gdb ...´ auf,
: gebe ´b ....:...´ ein, starte mit ´r parameter1 parameter2 ...´. -->
: stop --> ´print langer_variablen_name´
Wenn ich die Funktion weiss, die ich debuggen will, starte ich sofort
gdb, und gebe "b <funktion>", dannach r parameter, ansonsten oeffne ich
die Datei im vim via "<ESC>e <datei> (wobei ich mir natuerlich den
Dateinamen mit Tab vervollstaendigenlassen kann), such mir die Zeile, starte
in einem anderem XTerm gdb, gebe "b ..." ein dannach r parameter ... und
loss gehts. Die ganzen Parameter, etc. muss ich allerdings nur einmal eingeben
ansonsten kann ich dank readline-lib jederzeit mittels CTRL-P zurueckgehen,
mit "set history save on" geht das auch ueber mehrere Debug-Sessions hinweg.
Die Bedienung der Kommandozeile ist dank readline-lib in bash/gdb/ftp ueberall
gleich.
Und das schoenste ist, das ich diese Vorgehensweise auf allen moeglichen
Plattformen mit gdb (bei mir Linux/UnixWare/ISC-Unix/SCO/Solaris Sparc) genauso
anwenden kann.
: Unter TP geht es folgendermassen: Einmaliges Festlegen der Parameter,
: oeffnen der Datei via F3, Suchen der entsprechenden Stelle, Breakpoint
: setzen (CTRL-F8), Programm starten (CTRL-F9). --> stop --> einige
: CTRL-Right, bzw. ein Mausklick, CTRL-F7, ENTER
: Jetzt kann jeder selbst nachrechnen, was laenger dauert!
: 1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
: ankommt, keine gute Einstellung.
Bei professioneller Softwareentwicklung sollte es nicht nur auf Zeit ankommen
sondern vielmehr auf Qualitaet!. Mir ist es bedeutend lieber etwas mehr Zeit in
die Entwicklung zu stecken als dannach die Zeit von X-Anwendern durch staendige
Programmabstuerze (womoeglich mit Datenverlust) zu strapazieren.
: 2. klicke ich mir lieber etwas zusammen, als alte Win31 Zeiten wieder
: aufkommen zu lassen und direkt die API zu programmieren, (womoeglich
: noch mit OWL ...)
Ich kenne OWL nicht, arbeite aber mit C++/Qt und bin damit sehr zufrieden.
frank
Frank Roscher
Enrico Scholz <enrico...@wirtschaft.tu-chemnitz.de> wrote:
: Ich kenne keine Unix-Entwicklungssysteme aus eigener Erfahrung, vermute
: aber, dass sie nicht fuer den Preis erhaeltlich sind, der unter Windows
: ueblich ist ( 300 - 5000 DM ). Und Preise darueber, sind fuer den
: Hobbyprogrammierer inakzeptabel.
Es kommt darauf an wie Du Entwicklungssysteme definierst. Also bei mir
vim/ctags (oder auch emacs/etags) : DM 0,00
gcc/g++/gdb : DM 0,00
make : DM 0,00
cvs/rcs : DM 0,00
perl/sed/awk/grep/bash ... : DM 0,00
xterm : DM 0,00
=========
DM 0,00
Also fuer mich auch als Nicht-Hobbyprogrammierer akzeptabel.
frank
Frank Roscher
Marco Budde <Marco...@hqsys.antar.com> wrote:
: Hier muss ich Dir zustimmen, die Dokumentation der API ist eine
: Katastrophe (bitte nicht schon wieder diese Diskussion :)!).
Sorry, aber wenn Du keine Diskussion willst, dann darfst Du auch nicht
einfach irgendwelche abstrusen/subjectiven Meinungen in den Raum stellen.
Also ich finde die Kombination von O'Reilly POSIX Programmers Guide, dem
4.4 BSD Programmers Reference Manual, Stephens Advanced Unix Programming in
the UNIX Envionment alles andere als eine Katastrophe.
: Was ist an make bitte komisch? Das ist ein Standard.
Genau.
: Die Programme mit GUI sind unter Linux allerdings wirklich meistens
: ziemlich schlecht. Nimm nur die Window Manager wie fvwm. Sowas gehoert
: wirklich in die Tonne.
Was ist an fvwm2 fuer die Tonne - also ich mag ihn ...
frank
Jens Dittmar
>>>>> Enrico Scholz erwidert auf Jochem Huhmanns Artikel:
ES> ich assoziiere z.B. mit F1 Hilfe,
Ich nicht. Da steht "F1" drauf, nicht "Hilfe". Witzigerweise kommt bei
meinem von Dir so gescholtenen Emacs die Online-Hilfe, wenn man F1
drueckt. (Hab' ich vorher noch nie versucht...)
ES> Pfeiltasten -> Cursorbewegung,
Yep, das funktioniert aber auch fast ueberall. Bei einer Remote-Session
wuerde ich mich da aber nicht drauf verlassen.
ES> CTRL-PgUp/PgDn -> Seitenanfang/-ende usw.
PgUp/PgDn fuer seitenweises hoch- und runterblaettern ja, aber wieso CTRL?
ES> Angenommen, Du hast 2 Waschmaschinen, wobei eine im ersten
ES> Vierteljahr riesige Probleme bereitet, aber dafuer 10 Jahre lang
ES> laeuft, und die andere von Anfang an keinerlei Probleme bereitet,
ES> aber schon nach 7 Jahren den Geist aufgibt. Welche wuerde die
ES> Mehrheit wieder kaufen? - Maschine Nr. 1 !!
Nee, mein Bester! Dann wuerden die Leute ihre Texte ja mit (plain/La/AMS
oder sonstwas)TeX verfassen. Da der Weg zum ersten DVI-File aber meist doch
etwas haerter ist, mit irgendeinem WYSIWYNWG-Klickprozessor eine Seite
haesslich aber schnell auf dem Bildschirm zu sehen ist (Drucken ist schon
wieder was anderes :), wird also munter drauflos gemeisselt. Wenn das Ding
ab und zu 'nen Text mitnimmt, muss das wohl normal sein.
ES> Und genauso ist es mit Software: hier entscheidet die Mehrheit der
ES> (privaten) Nutzer aehnlich. Deswegen bringt auch ein Programm mit
ES> geringerem Funktionsumfang, aber einfacherer Bedienung
ES> hoechstwahrscheinlich hoeheren Gewinn, als ein Vergleichbares mit
ES> mehr/besseren Funktionen, aber hochkomplizierter Bedienung.
Heisst das, MS sollte das Wordpad, oder wie das Ding heisst, einzeln
verkaufen?
ES> Eine nicht zu unterschaetzende Rolle spielt ausserdem die
ES> Gewohnheit - und die meisten Nutzer kommen eben von Win/Mac und
ES> sind diese Bedienung gewoehnt.
Gewohnheiten muss man nicht unbesehen uebernehmen. Die kann man aendern,
und es kann sich sehr lohnen.
ES> Es ist hier oekonomisch unsinnig,
ES> stur zu bleiben und auf der von Hand zu editierenden
ES> Konfigurationsdatei und den kryptischen Tastenkombinationen zu
ES> bestehen.
Ein Generator fuer Konfigurationsdateien kann fuer manchen sicher
hilfreich sein.
ES> Der heutige Nutzer, der frisch von
ES> Windows kommt, die Schnauze von den dortigen Unzulaenglichkeiten
ES> voll hat und mal Linux probieren will, trifft normalerweise das
ES> erste Mal auf emacs und kehrt, Haende ueber den Kopf geschlagen,
ES> freudestrahlend zu Windows zurueck und nimmt dessen "kleine"
ES> Schwaechen gern in Kauf.
Das ist sein Problem. Wer nicht fahren lernen will, laeuft halt.
ES> Allerdings stoert mich, dass man hier kaum Chancen hat,
ES> seine (Hobby-)Software gewinnbringend zu verkaufen. Es findet sich
ES> naemlich kein erschwinglichen Compiler+Umgebung dafuer und die
ES> GNU-Lizenz ist nicht gerade der Vermarktung von Software
ES> zutraeglich.
Es zwingt Dich doch keiner, Deine Software unter die GPL zu stellen. Und
die LGPL duerfte nicht stoeren.
Jens
Enrico Scholz
Frank Roscher wrote:
> [...]
> Mit professionell aussehen hast Du vielleicht recht, aber sonst ... Ich finde
> vim, perl, tcl/tk, gdb, gcc, gawk, bash ... aeusserst professionell.
programmierst Du ?). Sowas ist doch nur fuer Administratoren und bedingt
Programmierer geeignet!
> [...]
> Stichwort tcl/tk.
Stichwort: write-only Sprache
> : Linux Programme machen ihre komplizierte und meist unlogische Bedienung
> : durch umfangreiche, aber meist ebenso komplizierte Konfigurierbarkeit
> : wett.
> : Sie beinhalten zwar meist genauso viele Funktionen wie entsprechende
> : Windows-Programme, jedoch sind diese schwerer zu finden. Heute ist es
> : (leider) immer noch so, dass nur die totalen Freaks Linux laufen haben,
> : welche Spass daran haben, Unbekanntes rauszufinden; wuerde man eine
> : "normale" Sekretaerin an Emacs setzen, koennte sie zwar evtl. einige
> : grundsaetzliche Dinge beherrschen, die eigentlichen Staerken, welche
> : ueber WordPad hinausgehen, aber nie rausfinden. Und was nuetzen die
> : besten Features, wenn man sie nicht findet ?
>
> Das hat alles nichts mit UNIX/Linux zu tun sondern hoechstens mit den
> Applikationen, ich habe in einer Firma Applixware eingefuehrt und die sind sehr
> zufrieden damit.
Unter Unix ist weitaus weniger Konkurrenzdruck vorhanden, als unter
Windows und die Programmierer haben somit mehr Zeit (unter Windows
sollte jedes Programm moeglichst schon vorige Woche fertig sein). Das
wird natuerlich in hoeherer Qualitaet und dem Preis widergespiegelt.
[Eine Anmerkung zur Effektivitaet unter Linux:]
Und womit ist Applixware [kenn' ich nicht] programmiert? Doch sicherlich
nicht mit gcc, gdb + tcl/tk, oder? Sonst waere es (abgesehen vom
rechtlichen Standpunkt) wohl heute noch nicht fertig. Und um eben diese
Ineffektivitaet der Standard-Linux-Entwicklungsumgebung ging es ja in
meinem Ursprungsposting.
Die fuer Applixware verwendete Umgebung mag zwar leistungsfaehig sein,
hat aber sicherlich ein Vielfaches des unter Windows ueblichen Preises
gekostet und ist somit fuer den Heimgebrauch und "kleinere"
Sharewareprogrammierer unerschwinglich.
> [...]
> Fuer mich ist die Oberflaeche von Windows Programmen wohl genausowenig intuitiv
> wie fuer einen Windows Anwender die Unix-Philosophie.
Geschmackssache; aber die meisten Nutzer finden Windows intuitiver.
> : Frage: wie gehst Du vor, um unter ´gdb´ einen Breakpoint zu setzen und
> : dort den Inhalt einer Variablen zu ueberwachen?
>
> : Ich mache es folgendermassen: Ich oeffne die jeweilige Datei (je nach
> : "IDE" unterschiedlich langwierig), suche die entsprechende Stelle, MERKE
> : mir die Position, gehe in ein xterm-Fenster, ´make´, rufe ´gdb ...´ auf,
> : gebe ´b ....:...´ ein, starte mit ´r parameter1 parameter2 ...´. -->
> : stop --> ´print langer_variablen_name´
>
> Wenn ich die Funktion weiss, die ich debuggen will, starte ich sofort
> gdb, und gebe "b <funktion>", dannach r parameter, ansonsten oeffne ich
> die Datei im vim via "<ESC>e <datei> (wobei ich mir natuerlich den
> Dateinamen mit Tab vervollstaendigenlassen kann), such mir die Zeile, starte
> in einem anderem XTerm gdb, gebe "b ..." ein dannach r parameter ... und
> loss gehts. Die ganzen Parameter, etc. muss ich allerdings nur einmal eingeben
> ansonsten kann ich dank readline-lib jederzeit mittels CTRL-P zurueckgehen,
> mit "set history save on" geht das auch ueber mehrere Debug-Sessions hinweg.
> Die Bedienung der Kommandozeile ist dank readline-lib in bash/gdb/ftp ueberall
> gleich.
Ziemlich umstaendlich, oder? Un was machst Du, wenn Du regelmaessige
einige Codezeilen ueberspringen (d.h. nicht debuggen) willst? Unter DOS
geh' ich dorthin und druecke F4. Fertig.
> Und das schoenste ist, das ich diese Vorgehensweise auf allen moeglichen
> Plattformen mit gdb (bei mir Linux/UnixWare/ISC-Unix/SCO/Solaris Sparc) genauso
> anwenden kann.
Ich kann mir ehrlich gesagt nicht vorstellen, dass man auf so vielen
Systemen gleichzeitig debuggen muss. Wenn ein Unix-Programm auf der
einen Plattform laeuft, sollte es, meinen Vorstellungen von Linux
entsprechend, auch auf allen anderen laufenm, oder ?
> [...]
>
> : 1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
> : ankommt, keine gute Einstellung.
>
> Bei professioneller Softwareentwicklung sollte es nicht nur auf Zeit ankommen
> sondern vielmehr auf Qualitaet!.
Du solltest versuchen, meine Kommentare im Zusammenhang zu lesen und
auch entsprechend zu quoten. Dann sehe es so aus:
> > [...]
> > Warum? Ich scheibe meinen Code lieber selber und vertraue keinen
IDE's
> > die durch Zusammenklicken irgendwelchen Spaghetti-Code erzeugen.
>
> 1. ist das bei professionellen Softwareentwicklung, wo es auf Zeit
> ankommt, keine gute Einstellung.
> [...]
Jetzt wuerdest Du erkennen, dass ich nie behauptet habe, dass es NUR auf
Zeit ankommt.
> Mir ist es bedeutend lieber etwas mehr Zeit in
> die Entwicklung zu stecken als dannach die Zeit von X-Anwendern durch staendige
> Programmabstuerze (womoeglich mit Datenverlust) zu strapazieren.
Das Zusammenklicken ansich, verursacht keine Fehler, sondern erzeugt im
Regelfall mehr (Delphi) oder weniger (VC++) sauberen Code.
Die Abstuerze werden entweder durch handprogrammierten Code oder
fehlerhafte Klassenbibliotheken verursacht. Aber vor keinem von beiden
ist ein Unix-Programmierer gefeit.
> [...]
Bye ... ESC
Enrico Scholz
Jens Dittmar wrote:
> [...]
> Ich nicht. Da steht "F1" drauf, nicht "Hilfe". Witzigerweise kommt bei
> meinem von Dir so gescholtenen Emacs die Online-Hilfe, wenn man F1
naja - ist halt das Programm, was die Situation unter Linux am besten
representiert.
> [...]
> ES> Pfeiltasten -> Cursorbewegung,
>
> Yep, das funktioniert aber auch fast ueberall. Bei einer Remote-Session
> wuerde ich mich da aber nicht drauf verlassen.
Stimmt - da hat der Admin das termcap-file nicht richtig gewartet! Warum
denn nur ???
> ES> CTRL-PgUp/PgDn -> Seitenanfang/-ende usw.
>
> PgUp/PgDn fuer seitenweises hoch- und runterblaettern ja, aber wieso CTRL?
Ich meinte Dokumentanfang/-ende. Sorry
>
> ES> Angenommen, Du hast 2 Waschmaschinen, wobei eine im ersten
> ES> Vierteljahr riesige Probleme bereitet, aber dafuer 10 Jahre lang
> ES> laeuft, und die andere von Anfang an keinerlei Probleme bereitet,
> ES> aber schon nach 7 Jahren den Geist aufgibt. Welche wuerde die
> ES> Mehrheit wieder kaufen? - Maschine Nr. 1 !!
>
> Nee, mein Bester!
Genau!! Das wollte ich auch schreiben, aber mein Koffeinspiegel war
schon ziemlich gesunken und da laesst halt die Konzentration nach ...
> Dann wuerden die Leute ihre Texte ja mit (plain/La/AMS
> oder sonstwas)TeX verfassen. Da der Weg zum ersten DVI-File aber meist doch
> etwas haerter ist, mit irgendeinem WYSIWYNWG-Klickprozessor eine Seite
> haesslich aber schnell auf dem Bildschirm zu sehen ist (Drucken ist schon
> wieder was anderes :), wird also munter drauflos gemeisselt. Wenn das Ding
> ab und zu 'nen Text mitnimmt, muss das wohl normal sein.
Ganz genau !!
> ES> Und genauso ist es mit Software: hier entscheidet die Mehrheit der
> ES> (privaten) Nutzer aehnlich. Deswegen bringt auch ein Programm mit
> ES> geringerem Funktionsumfang, aber einfacherer Bedienung
> ES> hoechstwahrscheinlich hoeheren Gewinn, als ein Vergleichbares mit
> ES> mehr/besseren Funktionen, aber hochkomplizierter Bedienung.
>
> Heisst das, MS sollte das Wordpad, oder wie das Ding heisst, einzeln
> verkaufen?
Waere vom Marketingstandpunkt hoechstwahrscheinlich unsinnig. Ausserdem
koennte man das Ding hoechstens fuer 10 Deutsche Maerker unter die Leute
bringen.
Da bringt Word schon mehr ein.
> ES> Eine nicht zu unterschaetzende Rolle spielt ausserdem die
> ES> Gewohnheit - und die meisten Nutzer kommen eben von Win/Mac und
> ES> sind diese Bedienung gewoehnt.
>
> Gewohnheiten muss man nicht unbesehen uebernehmen. Die kann man aendern,
> und es kann sich sehr lohnen.
Das ist doch das selbe, wie beim Kommunismus. Er funktioniert schon und
ist besser als Kapitalismus; man muss halt nur die Leute so aendern,
dass sie nicht mehr egoistisch sind .... Marx war schon ein cooler
Typ ...
--> Followup to 'de.politic' <--
>
> ES> Es ist hier oekonomisch unsinnig,
> ES> stur zu bleiben und auf der von Hand zu editierenden
> ES> Konfigurationsdatei und den kryptischen Tastenkombinationen zu
> ES> bestehen.
>
> Ein Generator fuer Konfigurationsdateien kann fuer manchen sicher
> hilfreich sein.
Kannst ja dran arbeiten, wenn Du glaubst, dass es was einbringt. Ich
persoenlich bezweifle das.
>
> ES> Der heutige Nutzer, der frisch von
> ES> Windows kommt, die Schnauze von den dortigen Unzulaenglichkeiten
> ES> voll hat und mal Linux probieren will, trifft normalerweise das
> ES> erste Mal auf emacs und kehrt, Haende ueber den Kopf geschlagen,
> ES> freudestrahlend zu Windows zurueck und nimmt dessen "kleine"
> ES> Schwaechen gern in Kauf.
>
> Das ist sein Problem. Wer nicht fahren lernen will, laeuft halt.
... und die Autoindustrie hat Pech gehabt ...
Bye ... ESC
Bernd Gehrmann
Frank Roscher <f...@acm.org> writes:
> Die Bedienung der Kommandozeile ist dank readline-lib in bash/gdb/ftp
Wo gibt es ein ftp mit readline?
Bernd.
Gunnar Beushausen
Enrico Scholz wrote:
> [Eine Anmerkung zur Effektivitaet unter Linux:]
> Und womit ist Applixware [kenn' ich nicht] programmiert? Doch sicherlich
> nicht mit gcc, gdb + tcl/tk, oder? Sonst waere es (abgesehen vom
> rechtlichen Standpunkt) wohl heute noch nicht fertig. Und um eben diese
> Ineffektivitaet der Standard-Linux-Entwicklungsumgebung ging es ja in
> meinem Ursprungsposting.
> Die fuer Applixware verwendete Umgebung mag zwar leistungsfaehig sein,
> hat aber sicherlich ein Vielfaches des unter Windows ueblichen Preises
> gekostet und ist somit fuer den Heimgebrauch und "kleinere"
> Sharewareprogrammierer unerschwinglich.
Das ist ja der größte Quatsch, den ich je gehört habe! Ich kenne mehrere
Programmierer, deren Frimen Individualsoftware schreiben, unter anderen z.B. für
Zeitungen. Alle die zumindest ich kenne benutzen GCC als entwicklungsplattform. Zwar
nicht unter Linux, aber unter Solaris oder Open Server. GCC hat weltweit bei den
Entwicklern einen sehr guten Ruf und GCC wird meist bei Unix Platformen anderen
kommerziellen Produkten vorgezogen.
Wenn du dich nicht in der Szene auskennst, höre bitte auf Misinformationen im Netz
zu posten.
> > Und das schoenste ist, das ich diese Vorgehensweise auf allen moeglichen
> > Plattformen mit gdb (bei mir Linux/UnixWare/ISC-Unix/SCO/Solaris Sparc) genauso
> > anwenden kann.
>
> Ich kann mir ehrlich gesagt nicht vorstellen, dass man auf so vielen
> Systemen gleichzeitig debuggen muss. Wenn ein Unix-Programm auf der
> einen Plattform laeuft, sollte es, meinen Vorstellungen von Linux
> entsprechend, auch auf allen anderen laufenm, oder ?
Völlig daneben. Mal abgesehen daß jedes Betriebsystem andere Routinen und startup
Code benutzt, laufen die oben genannten Betriebsysteme auch noch auf ganz anderer
Hardware (siehe Sparc). Ein für jedes System einzelne debuggen ist durchaus
notwendig. Der Fehler muß ja möglicherweise nicht nur im eigenen Code stecken,
sondern kann sich im zusammenspiel mit Betriebsystemroutinen und /oder Hardware
ergeben.
--
---
Gunnar Beushausen
Gun...@hof.de
http://www.hof.de/~gbasic
Kristian Koehntopp
>Kann hier jemand - basierend auf seinen Erfahrungen - Qt empfehlen oder
>davon abraten ?
Sieh' Dir einfach mal KDE an (www.kde.org). Dann entscheide
selber (KDE ist auf der Basis von Qt entwickelt).
Vielleicht moechtest Du auch Qt in Zusammenhang mit KDE
einsetzen - KDEs Bibliotheken erweitern die Funktionen von Qt
noch einmal erheblich.
Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
http://www.koehntopp.de
"What do we have here? Two rodents looking for a theme park?" -- "Hercules"
Enrico Scholz
Gunnar Beushausen wrote:
>
> Enrico Scholz wrote:
>
> > [Eine Anmerkung zur Effektivitaet unter Linux:]
> > Und womit ist Applixware [kenn' ich nicht] programmiert? Doch sicherlich
> > nicht mit gcc, gdb + tcl/tk, oder? Sonst waere es (abgesehen vom
> > rechtlichen Standpunkt) wohl heute noch nicht fertig. Und um eben diese
> > Ineffektivitaet der Standard-Linux-Entwicklungsumgebung ging es ja in
> > meinem Ursprungsposting.
> > Die fuer Applixware verwendete Umgebung mag zwar leistungsfaehig sein,
> > hat aber sicherlich ein Vielfaches des unter Windows ueblichen Preises
> > gekostet und ist somit fuer den Heimgebrauch und "kleinere"
> > Sharewareprogrammierer unerschwinglich.
>
> Programmierer, deren Frimen Individualsoftware schreiben,
1. Fuer Individualsoftware stellt die GPL kein Problem dar, bei
Massensoftware hingegen schon. Und auf LGPL auszuweichen und nur
Libraries auszuliefern, bringt wahrscheinlich auch einige
Schwierigkeiten mit sich.
2. Bei Individualsoftware werden teilweise die exotischsten Sachen
verlangt, die in keiner Standardbibliothek zu finden sind und deshalb
selbst programmiert werden muessen.
3. Leistungsfaehige Entwicklungsumgebungen kosten unter Unix viel Geld,
und da ist es billiger, die Programmierer mit gcc+vi zu quaelen.
> unter anderen z.B. für
> Zeitungen. Alle die zumindest ich kenne benutzen GCC als entwicklungsplattform. Zwar
> nicht unter Linux, aber unter Solaris oder Open Server. GCC hat weltweit bei den
> Entwicklern einen sehr guten Ruf und GCC wird meist bei Unix Platformen anderen
> kommerziellen Produkten vorgezogen.
Fuer Standard C mag es ja ausreichend sein, bei C++ gibt es aber einige
Schwierigkeiten, speziell bei der Erzeugung von Debuginformationen und
der Behandlung von templates.
> [...]
> Völlig daneben. Mal abgesehen daß jedes Betriebsystem andere Routinen und startup
> Code benutzt, laufen die oben genannten Betriebsysteme auch noch auf ganz anderer
> Hardware (siehe Sparc). Ein für jedes System einzelne debuggen ist durchaus
> notwendig. Der Fehler muß ja möglicherweise nicht nur im eigenen Code stecken,
> sondern kann sich im zusammenspiel mit Betriebsystemroutinen und /oder Hardware
> ergeben.
Da kommt echtes Windows-Feeling auf ...
Bye ... ESC
Jens Dittmar
>>>>> Enrico Scholz schreibt:
ES> Jens Dittmar wrote:
>> [...]
ES> Pfeiltasten -> Cursorbewegung,
>> Yep, das funktioniert aber auch fast ueberall. Bei einer
>> Remote-Session wuerde ich mich da aber nicht drauf verlassen.
Muss nicht, oft liegt's am Terminal. Ein Windows-Telnet z.B. ist meiner
Erfahrung nach fast schon eine Garantie fuer Probleme. Da gibt's bizarre
Dinger.
ES> CTRL-PgUp/PgDn -> Seitenanfang/-ende usw.
>> PgUp/PgDn fuer seitenweises hoch- und runterblaettern ja, aber
>> wieso CTRL?
ES> Ich meinte Dokumentanfang/-ende. Sorry
Huch, ist mir gar nicht aufgefallen! So hab' ich das auch gelesen. Ist
doch die Windows-Konvention, oder?
>> Gewohnheiten muss man nicht unbesehen uebernehmen. Die kann man
>> aendern, und es kann sich sehr lohnen.
ES> Das ist doch das selbe, wie beim Kommunismus.
Nicht ganz - bei der Software habe ich selbst die Wahl.
ES> Bye ... ESC
dto
Jens
I. Laera
>3. Leistungsfaehige Entwicklungsumgebungen kosten unter Unix viel Geld,
>und da ist es billiger, die Programmierer mit gcc+vi zu quaelen.
Plus die Kosten der Unix Programmierer selbst. Os2/Win-Datenbank-
programmierer mit Power++/Delphi/Foxpro/Access-KnowHow gibts schon
fuer ein viertel der Stundengebuehren.
>> Hardware (siehe Sparc). Ein für jedes System einzelne debuggen ist durchaus
>> notwendig. Der Fehler muß ja möglicherweise nicht nur im eigenen Code stecken,
>> sondern kann sich im zusammenspiel mit Betriebsystemroutinen und /oder Hardware
>> ergeben.
>Da kommt echtes Windows-Feeling auf ...
Irgendwie werden hier schon wieder die Probleme EINER Plattform mit
den Problemen und Erfordernissen von Multiplattform-Programmierung
verglichen. Kein Mac-Entwickler wuerde sich freiwillig von seiner
(vorzueglichen) CodeWarrior-Umgebung trennen, wenn er es nicht
unbedingt muesste. Da mir unter Win die VisualC Umgebung auch nicht
gefaellt, schreibe ich gerade an einer eigenen IDE, die mir RCS/CVS
Funktionaliaet und Mailinglisten-Verwaltung per _Knopfdruck_ bietet.
Warum nicht "Best of Both Worlds" ?
gruss
Igor
---
Attention: remove SPAM from email adress
I. Laera
On Wed, 26 Nov 1997 21:43:54 +0100, Gunnar Beushausen
<us...@beushausen.wl.eunet.de> wrote:
>Programmierer, deren Frimen Individualsoftware schreiben, unter anderen z.B. für
>Zeitungen. Alle die zumindest ich kenne benutzen GCC als entwicklungsplattform. Zwar
>nicht unter Linux, aber unter Solaris oder Open Server. GCC hat weltweit bei den
>Entwicklern einen sehr guten Ruf und GCC wird meist bei Unix Platformen anderen
>kommerziellen Produkten vorgezogen.
>Wenn du dich nicht in der Szene auskennst, höre bitte auf Misinformationen im Netz
>zu posten.
Welche Szene ? Der Unix-Individualprogrammierer ?
In der "Mac-Szene" wuerde ich den GCC genauso mit der Lupe suchen, wie
in der "Windows/Dos-Game-Szene" (VisualC oder Watcom) oder
Lernsoftware (Macromedia Director). Es mag schon stimmen, das in der
EDV-Welt GGC Standard ist, aber Ihn auf den obersten Compiler-Thron
aller Anwendungsparten und Anforderungen zu setzen, ist fast schon
dreist. Ich kenne einige Leute, die auf den Intel eigenen x86-Compiler
aus Hardware-Design-Gruenden angewesen sind und ihn in die VisualC
Umgebung eingebunden haben.
Vor allem Quereinsteiger, die keine semesterlange "Grundausbildung" in
der Shell nachweisen koennen, tun sich mit vi und gcc auf nicht-Unix
Systemen recht schwer. Ich wuesste z.B. nicht, wie ich mit vi und gcc
unter Mac/Win eine GUI-Datenbankanwendung schreiben sollte.
I. Laera
On 25 Nov 1997 02:08:00 +0100, oli...@first.in-berlin.de (Oliver
Bandel) wrote:
>Da programmieren andere Wochenlang an einer Datenbank, ob nun unter Excel,
>oder eine richtige Datenbank, um ein paar Adressen zu verwalten...
>... dabei braucht man dafür oft bloß den vi und grep.
Jedes Tool hat seine Anwendung. Ich glaube kaum, das jemand eine
komplette Lager/Rechnungsverwaltung von ueber 100.000 Einzelteilen/
50 Mitarbeitern "einfach" mit vi und grep zusammenbekommt... und dazu
gleich eine nette X-GUI fuer die nicht gerade hellen Lagerbearbeiter
bastelt. Da gibt es unter OS/2 bzw. Windoof einfachere und schnellere
Loesungen, die nicht sofort in die 10(0).000 DM gehen.
Mario Hoerich
# jou <j...@gmx.net> wrote:
>cat vmlinuz > /dev/fd0
>und voilá, eine bootdisk für den fall lilo mal wieder tot ist.
Merci .
(Bislang hab ich die Bootdisks bei der Installation gemacht)
>Benutzt du noch ein anderes OS ausser Linux auf der Machine ?.. wenn ja
>und wenn M$, dann ist das der Grund fuer deine MBR-Lilo Aufloesungen.
Kann ich M$ nicht dafür verklagen ? ;)
>Das ist der Grund warum man ihn moeglichst nicht in den MBR legen sollte
>sondern eher in den Superbootblock deine Linux Partition.
Werd ich machen, sobald es wieder mal nötig ist.
Danke !
MfG
Mario
--
void sig(void)
{
printf("Please do NOT send spam to my adress.\n");
}