Re: [FYI] Historikertag: Verbandschef warnt vor Fixierung auf dasInternet

[PILCH Hartmut <phm@a2e.de>]

> > > > Wenn die nicht als freie Software geliefert werden, hat das aber einen
> > > > entscheidenden Nachteil:  der Aufwand fuer die Nacharbeit wird
> > > > vervielfacht, man klickt sich durch zahlreiche Menues und kann nichts
> > > 
> > > Quatsch. Seit wann ist Softwareergonomie bei freier Software ueblich?
> > 
> > Schon immer.
> 
> Zufall, dass Torvalds sich gerade an Unix herangemacht hat und nicht einen
> Windows-Clone haben wollte. Dann wuerdest Du heute konsequenterweise diesen
> Textmodepfusch verteufeln, wie die meisten Klicker. Das Verdienst des
> Shell-Pipings gebuehrt den Entwicklern des proprietaeren Systems AT&T-UNIX,
> aber ganz gewiss nicht irgendwelchen abkupfernden OpenSource-Freaks. Ohne
> Linux oder *BSD wuerdest Du ggf. heute vor einem SCO-Unix o.ae. (zu einem
> obszoenen Kaufpreis) sitzen.

Deine Laestereien sind ja normalerweise ganz nett, aber allmaehlich
sabberst du wie ein Betrunkener daher.

1- Die Unix-Welt war auch schon vor Torvalds die Welt, in der freie
   Software sich entwickelt.  Unix war einmal frei, bevor es proprietaer
   und dann wieder wurde.
2- Wesentlich ist, dass in der Unix-Welt und generell in der freien
   Hackerwelt kleine maechtige Programme gebaut und mit einfachen
   Mechanismen kombiniert werden.  Unter diesen Voraussetzungen kann man
   unvorhergesehene Probleme loesen, und unter diesen Voraussetzungen
   gedeiht freie Software.  Uebrigens sind auch nicht unzufaellig genau
   diese Voraussetzungen bei Texterkennungssystemen nicht gegeben.  Es
   gibt da erst mal viel monolitisches zu programmieren und dann wenig
   zu vernetzen und zu kombinieren.
3- Das Pipe-Konzept ist nicht besonders kompliziert und erfordert keine
   proprietaere Entwicklung.  In freier Software wurden schon
   komplizierter Innovationen vorangebracht.  Schwierig ist allenfalls
   das Konzept der Prozesse und die Implementation in C mit Funktionen
   wie dup.
 
> >  Z.B. der Art
> > 
> > $ scan < /dev/scanner | pnmtotiff | ocr --lang=de --cols=2 > seite.txt

Heutzutage muesste vielleicht hinter "ocr" ein Aufruf eines Servers
stecken, der die Texterkennung mit einem proprietaeren Programm leistet
und dafuer mengenabhaengige Gebuehren kassiert.  Irgendwann ist die
Aufgabe vielleicht dann so weit in Module zergliedert, dass freie Software
entstehen kann.  Aber bis dahin ist es weit, und es muss nie so weit
kommen.  Mich wundert nur, warum es diesen Netzdienst noch nicht gibt.
Zu wenige Rechner permanent am Netz?  Zu grosser Aufwand an Bandbreite
fuer das Uebersenden von TIFF-Grafiken?
 
> Du hast den letzten, wesentlichen Schritt vergessen, der die Zeit kostet: *)
> emacs seite.txt, ggf. mit ispell, aber dennoch Wort-fuer-Wort, Satzzeichen-fuer-
> Satzzeichen mit dem Original vergleichen.

Man kann es auch zunaechst billiger machen:  Grafik-PDF + fehlerhaftes
Texterkennungsergebnis, das erst Schritt fuer Schritt bei Bedarf dezentral
korrigiert wird.

> > Waere es nicht so, dann wuerden auch mehr Texterkennungsprogramme unter
> > Linux laufen.  Denn die Kernfunktionalitaet, die man von der Kommandozeile
> 
> Nein. Es gibt keine Spezialisten fuer Texterkennungssoftware in der Free SW Szene.
> Die, die sich damit auskennen, sind samt und sonders _erwachsen_, und wissen, wo
> ihr Knowledge meistbietend honoriert wird. Wo man relativ einfach abkupfern kann,
> weil das Problem verhaeltnismaessig einfach ist, oder das Knowledge veroeffentlicht
> und bekannt ist, da finden sich auch Linuxbastler. 

Nochmals trunkenes Gelaester.
Es gibt durchaus Texterkennungsspezialisten, die schon etwas
brauchbares freies geschrieben haben, z.B. xocr.  Allerdings nicht so
brauchbar wie kommerzielle Alternativen.
Das Problem ist wiegesagt die mangelnde Modularitaet des Prozesses.
Das ist ein klassisches Feld fuer die Kathedralen-Methode, und daran wird
sich so schnell nichts aendern.  So ist es bei vielen Spezialanwendungen.
Gerade deshalb koennen freie und proprietaere Software sehr gut
koexistieren, ohne dass einer die Abkupferer fuerchten muss.  In den
letzten Jahren hat M$ nicht allzu viel originelles entwickelt und viel bei
Unix/Linux abgekupfert.  Andererseits ist manche Entwicklung bei KDE/Gnome
auch von M$ inspiriert.  Das eigentlich schwierige sind nicht die Ideen,
sondern die viele Arbeit, die darin steckt, das ganze zum Funktionieren zu
bringen. 
 
> > aus bedienen kann, laesst sich gut plattformunabhaengig in Common Lisp,
> > Prolog oder Java programmieren.  Tut aber niemand.
 
> Weil kein Markt existiert, der bereit ist fuer eine Software
> zusaetzliches Geld zu bezahlen, die auf zig Betriebssystemen und
> Rechnerplattformen ohne sonderlichen Portierungsaufwand (aber dafuer
> schneckenlahm - was Du genannt hast, ist portabel aber interpretiert!)

Nichts von alledem ist interpretiert.  Fuer alle drei Sprachen gibt es
Kompilierprogramme.  Manche Lisp-Kompilate stellen sogar
Geschwindigkeitsrekorde auf, uebertreffen C-Kompilate.  Auch
JIT-uebersetztes Java ist nicht merklich langsamer als kompilierte
C-Programme.  Wenn man die Staerken der jeweiligen Sprache geschickt
nutzt, uebertrifft man leicht Programmierer anderer angeblich schnellerer
Sprachen.
  
Ausserdem koennte man auch in C, C++, Eiffel, Ada uvm leicht portierbar
schreiben.

> laeuft. Wer z.B. DTP machen will, kauft sich ein System, etwa die
> Software und dazu den Rechner, auf dem das laeuft. Die Sichtweise der
> Linuxler ist diesbezueglich auf den eigenen Nabel beschraenkt.

Umgekehrt.  Es existiert ein Markt fuer netzbasierte Serverdienste.
Die DTP-Sichtweise ist beschraenkt und veraltet.  Trotzdem halten die
grossen Firmen daran erstmal noch fest.   Und kleine arbeiten kaum an
Erkennungsprogrammen.

-phm