Re: Aktuelles OpenOffice ohne Schnickschnack als Paket

Polytropon <freebsd(at)edvax.de> wrote:
> [...]
> Was Deine Annahme, man müsse für aktuelle Software auch
> aktuelle Hardware haben, anbetrifft,

Das habe ich *nicht* geschrieben, und das würde ich so auf
gar keinen Fall pauschalisieren. Meine diesbezügliche
Anspielung bezog sich speziell nur auf OpenOffice.

> so bin ich anderer Meinung, insbesondere dank meiner
> "jahrelangen" Reise mit FreeBSD.

Ich glaube, da sind wir der gleichen Meinung.

> Seit 4.0 bin ich dabei und kenne es vom Server wie auch
> von der Workstation. Immer, wenn ein neues Release
> angekündigt wurde, konnte ich mich freuen - denn das
> bedeutete, daß das System auf DERSELBEN Hardware nach
> der Aktualisierung nun noch schneller und besser laufen
> würde. In diesem Punkt bin ich von FreeBSD noch nie
> enttäuscht worden. Daher an dieser Stelle auch nochmal
> mein Dank an alle, die an FreeBSD mitarbeiten und diese
> Erfahrung immer wieder möglich machen.

Dem kann ich mich nur anschließen (ich bin übrigens seit
2.0.5 dabei; die alten Walnut-Creek-CDs stehen noch bei mir
im Regal).

Es gibt allerdings auch Ausnahmefälle. Mein selbstgebauter
mp3-Player zum Beispiel läuft noch mit einem 4er FreeBSD,
da es dort von der Hardware her schon relativ eng wird
(langsame Geode-CPU, wenig RAM und kein Swap, kleiner Flash-
Speicher), will ich's mir da nicht unnötig enger machen.
Außerdem: »Never change a running System«. Und da das Ding
zwar im DNS steht (cantaro.fromme.com), aber nicht geroutet
wird, sehe ich da auch kein Sicherheitsproblem.

Es kommt halt auch immer drauf an, was man machen will.
Wenn ich eine A4-Seite mit 600 dpi einscanne und dann in
Gimp bearbeiten will, komme ich mit 512 MB RAM nicht weit,
ohne dass er anfängt, sich nach drei, vier Arbeitsschritten
totzuswappen. Mit 1 GB geht's gerade so, aber kann nicht
besonders viele Bearbeitungsebenen, Undo-Level usw. verwen-
den.

> Früher, Du wirst das wissen, konnte man "pkg_add -r de-openoffice"
> machen und bekam ein OpenOffice in Minimalausstattung.
> Alles optionale konnte nachinstalliert werden. Heute
> wird doch so viel von Modularität in der Software
> gesprochen, und da muß ich nun bei der Herstellung
> der Software entscheiden, welche Sprache ich will?
> Oder welches Druckersystem?
>
> Wenn ich mal spinnen darf: Mir schwebt sowas vor wie
> "pkg_add -r de-openoffice3", was ein 3er OO in deutscher
> Sprache installiert. Will man nun optionale Komponenten
> mit Absicht haben, dann macht man "pkg_add -r ooo3-cups"
> oder "pkg_add -r ooo3-kde" oder sowas. Und wenn das
> mit den Sprachen zu umfangreich ist, dann sollte man
> die auch als Binärpaket nachladen können.

Ich stimme Dir vollkommen zu. Aber damit das in der Form
klappt, muss sich jemand die Mühe machen, das zu implemen-
tieren. Das hat bisher offenbar niemand getan.

In der Open-Source-Welt ist es häufig so, dass diejenigen
etwas implementieren, denen der Mangel am meisten schmerzt
(entsprechendes Know-how vorausgesetzt, aber das kann man
sich nötigenfalls ja auch aneignen).

> > Das ist auf den ersten Blick natürlich weniger bequem,
> > als wenn man einfach pkg_add -r von seinem Standard-FTP-
> > Mirror machen könnte. Und es erfordert ein wenig Orga-
> > nisation bzw. Koordination innerhalb der nationalen
> > Benutzergruppe. Aber das lässt sich leider nicht so
> > einfach ändern.
>
> Wenn man *weiß*, wie es läuft, ist das ja im Grunde auch
> kein Problem.
>
> Da fällt mir ein: Wenn diese Idee sich in das Ports-System
> integrieren ließe, und damit vielleicht portmaster oder
> portupgrade (wenn schon nicht pkg_add) beeinflussen ließen,
> man also quasi einen Port hat, der nur aus einem Makefile
> besteht, in dem die zur Verfügung stehenden Pakete mit
> den jeweiligen Optionen registriert sind - und natürlich
> auch die Quelle, wo sie herkommen -, dann wäre das eine
> Umgehung von "man muß wissen, wo es liegt".

Das wäre durchaus eine Möglichkeit. Wenn Du Lust und Muße
hast, kannst Du das ja mal auf der Ports-Mailingliste zur
Diskussion stellen. Aber Vorsicht: Es ist möglich, dass
Du Dir damit Arbeit aufhalst. ;-)

> In diesem Zusammenhang könnte ich mich auch über Java
> aufregen, aber das verschiebe ich auf ein anderes Mal. :-)

Lass das Thema Java lieber ruhen ... Davon könnte ich
auch ein Lied singen. Aber helfen tut's ja nichts.

> > PS: Ich persönlich verwende LaTeX, was auch auf 15 Jahre
> > alter Hardware noch gut funktioniert und sich auch ohne
> > Probleme bauen lässt.
>
> Öhm... war da nicht was wegen teTeX und / oder TeXlive?
> Wieder ein "oder" zu viel. :-)

Ja, ich verwende nach wie vor teTeX, auch wenn's nicht mehr
"hip" ist. Solange es funktioniert, ist mir das wurst.

Ich hatte auch gegen Ende der 90er noch eine emTeX-Instal-
lation auf einer alten Büchse unter Novel-DOS-7 am laufen.
Der Mensch ist halt ein Gewohnheitstier. ;-)
Und der VESA-DVI-Viewer (für DOS) hat wunderbar funktio-
niert; sowas vermisse ich heute noch.

> > Allerdings ist das nicht für Leute
> > geeignet, die einen MS-Office-Clone haben möchten.
>
> Möchten? Nein, die Leute, die Du meinst, "müssen" es. :-)

Ich glaube, die Unterschieden zwischen »möchten« und
»müssen« verwischen in dem Fall. Häufig liegt es evtl.
auch nur an einer gewissen Unaufgeklärtheit, dass man
glaubt, man _müsse_ es so haben.

> > Und falls ich mal etwas an eine Druckerei liefern muss,
> > nehme ich scribus (ports/print/scribus) und LCMS (ports/
> > graphics/lcms) für die DTP-Endstufe.
>
> Interessant - werde ich mir mal ansehen, um meinen
> erwiesenermaßen etwas niedrigen Horizont zu erweitern.

Druckereien wollen ja die Dateien gerne schon mit passender
Farbseparation (CMYK, evtl. auch mit Pantone-Farben o.ä.)
haben. Dazu bekommt man meistens das Farbprofil der Druck-
maschinen mitgeteilt. Und damit die Farben im Druck dann
auch halbwegs so herauskommen wie auf dem Bildschirm, muss
man seinen Bildschirm kalibrieren und ebenfalls ein Farb-
profil dafür erstellen. Scribus und LCMS können dann mit
diesen Profilen arbeiten und erledigen die notwendigen
Konvertierungen. (Das funktioniert natürlich nicht perfekt,
da »normalen« Bildschirme nicht den vollen Farbraum eines
Drucks darstellen können, aber für einfache Sachen wie
Flugis, Visitenkarten oder Aufkleber genügt es.)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
        -- Chris Torek
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message