> > Das muß ich Dir leider widersprechen: es muß stets das Vorrecht des Sysop oder
> > Nutzers (auf dem Standalone-Desktop) bleiben, wo die Software zu installieren
> > ist, was bei RPM's entfällt.
>
> Ja, dann hast du als Programmierer aber mit den sich daraus ergebenden
> Nachteilen für dich zu leben.
>
> Im Gegensatz zum Windows "Install Shield" ist RPM wohl der Durchbruch
> schlechthin!
> Oder hast schonmal versucht, MS Office zu DE-installieren ?
> Ich install und De-Install hier mein komplettes X-Win-System innerhalb
> von 5 Minuten, und es geht nacher alles wieder...
>
> > von der Existenz einer installierten anderen Software überzeugen: ich
> > beende gerade einen GUI-Wrapper für PGP 5.0i auf TK(X)/TCL(X) und Tix-
> > Basis. (funktioniert schon gut) gedacht für Leute, die gerne schnell etwas
> > außerhalb von emails verschlüsseln und/oder signieren (incl Schlüssel ver-
> > walten) und sich nicht mit den vielen Kommando-Zeilen-Parametern herumquälen
> > wollen. Wie kann ich die Existenz von pgp+ überprüfen ? Im Verzeichnis
> > /usr und/oder /bin und/oder /usr/bin ..... nachschauen ? Keine mich überzeugende
> > Lösung !
>
> Wieso ? Ginge erstens über die BASH-Tools recht schnell, zweitens kann
Mit welchen BASH-Tools ? (Ich kann Tcl nur in o.g. Pfaden nachschauen lassen)
> man das auch in der RPM-Datenbank abfragen..incl. Pfade, wo es sich
> befindet.
> Dazu ist RPM nämlich auch da....
Mit welchem RPM-Befehl, wenn der Programmierer von nicht feststehenden Paket-
Namen ausgehen kann ? (Bin für jedwelche Hilfe dankbar, da pgpk --version
unendlich langsam ist)
> Und sind wir mal ehrlich: Viele wissen gar nicht, wo sich ihre Programme
> befinden, auch wenn sie beim Installen groß und breit ein "Target-Dir"
> angeben dürfen...und es interessiert sie auch nicht!
> Warum also einen Aufwand treiben, um diese Infos zu erhalten und
> abzuspeichern, wenn es den Leuten nach 5 Minuten eh egal ist, ob ihr PGP
> jetzt unter /usr/local oder /opt liegt...zumal man mit symbolischen
> Links ja auch ein Programm ganz schnell "verschieben" kann...
Vollkommen klar, aber was ist, wenn aus irgendwelchen Gründen doch ein "Target-
Dir" gewünscht ist ?
> > Bist Du in der Lage mir die Anzahl und Lokationen der Konfig-Dateien nur
> > für das X-Window zu nennen zzgl. für KDE ?
>
> Anzahl nicht, wozu ?
> Lokation sehr wohl:
>
> X-Server : /etc/X11/xinit/*
> KDE: /home/user/Desktop
> sowie /home/user/.kde
und /opt/kde und Xdefaults und Xresources und xconfig und
/usr/X11R6/lib/X11/app-defaults (mit knapp 60 Dateien) und und ....
Klar, aber das sind überwiegend Batch-Files, keine standardisierte DB.
Konfig-Dateien wie Xdefaults z.B. weisen anwendungsspezisch eine eigene
Konfigurationslogik auf, die erst mühselig erschlossen werden muß.
> > Registry exportieren: kein Problem
>
> Schon, und nach dem Zurückschreiben crasht mir das NT...und wie bieg ich
> das dann wieder hin, ohne lauffähiges NT ?
Komisch bei mir nicht ! (Hab' vielleicht nur "Glück" gehabt) Wie ich schon
sagte: es ist ein halbes Hochschulstudium dazu nötig.
> > Na für wen wohl ! Z.B. für wildfremde Software-Produzenten, die zentral nur
> > irgendwo nach schauen müßten, wo z.B. ein externer Email-Klient läge, um diesen
> > aus deren Software heraus zu starten, wenn dieser eher vom User als der eigene
> > gewüsncht würde.
>
> Die RPM-Datenbank enthält alle diese Daten...
Ich wäre Dir wirklich dankbar, mir kurz zu zeigen, wie ein fremdes Programm zur
Laufzeit aus der RPM-DB o.g. Infos bekommt.
> Ich hab schon als absoluter NT-Laie Keys aus der Registry gekillt,
> teilweise ohne Plan und Sinn (Trial and Error), und es hat mich nie
> jemand gehindert...da ja meist eh alle als "Administrator" drin sind,
> weil man sonst nicht mal nen Drucker installen darf bzw. viele
> Install-Programme inzwischen auch Admin-Rechte brauchen....
> Hinzu kommen die Massen an schlecht programmierten Install-Programmen,
> die auch nach Belieben müllen gehen...
Die benötigten Admin-Rechte sind jawohl in allen Betriebssystemen, die den
Anspruch haben als solche genannt zu werden, notwendig.
> > Ich wette mit Dir, das so etwas kommen wird, um Software-Distribution und
> > zentralisierte Konfiguration beim User zu realisieren. Man muß die Leute aus
> > Redmond teilweise mit ihren eigenen Mitteln schlagen.
>
> Nein. Man muß bessere Alternativen entwickeln. Alles andre ist abkupfern
> und bringt Linux nicht weiter, sorry.
Linux ist in der Basis mehr oder weniger ein einziger Unix AT&T- und BSD-Clone !
> Nicht umsonst machen
> > die 20 Mrd $ p.a.
>
> Sagt gar nichts aus. Daimler-Chrysler macht noch mehr Umsatz, obwohl
> deren Autos teilweise umfallen. Das Ziel von Linux kann und sollte nicht
> sein, Gates zu kopieren, sondern alternative Wege aufzuzeigen, wie z.b.
> Open Source...
Mit Verlaub, der Vergleich hinkt ein wenig, was M$ in 15 Jahren durch
Ankündigungsorgien, rüpelhaftes Marktverhalten und ein glänzendes Marketing von
teilweise auch rechten ordentlichen Produkten schaffte hat Daimler-Chrysler erst
in 50 Jahren erreicht.
> Es bleibt noch vieles zu tun, um Linux bei Desktops aus der
> > 7 % -Marktanteilsecke herauszuholen !! PACKEN WIR`s AN !!!
>
> Ja, die 7% innerhalb von 3 Jahren....
> Natürlich sollten wir es anpacken. Aber nicht, indem jetzt planlos
> irgendwelchen Tools samt ihren Macken aus dem Unix- oder Windowsbereich
> portiert werden, nur um sagen zu können:
> "Yes, we too have a Registry!"
Geb' ich Dir voll recht. Trotzdem würde ich mich über eine zentralisierte
Datenbasis mit system- und netzwerkweite Konfigurations-Infos schon freuen !
Wir alle sollten uns vor einer Selbstgerechtigkeit, daß Linux das bessere OS
sei, hüten. Denn die selbstgefällige Arroganz sollte nur in Redmond zu Hause
sein.
Zum Schluß zählt nur eins: Die klare Beantwortung der Frage: mit welchen
Systemen bei niedrigen Administrationskosten und Herstellerabhängigkeiten
ist die höchste Produktivität und Anpassbarkeit an bestehende + zukünfige Ge-
schäftsprozesse zu erzielen ? (dabei sind technische Vorteile , der Open-
Source-Kram oder gar Linzenskosten absolut zweitrangig !!)
Ich wünsche ein schönes Wochenende
Hans Heering
_______________________________________________________________
Dipl. Wirt.-Inf. Hans Heering
email: Hans.Heering@munich.netsurf.de
www : http://homepages.munich.netsurf.de/Hans.Heering
Public-Key-Server: (ID: Hans Heering <Hans.Heering@munich.netsurf.de>)
http://www.trustcenter.de/cgi-bin/SearchCert.cgi?FORMTYPE=Search
oder: http://math-www.uni-paderborn.de/pgp/extract.html
_______________________________________________________________