Deinstallation von Software unter OS X
Michael Wiesauer
Gibt es in OS X eine Funktion zur Deinstallation von Programmen? - Wie
bekomme ich Programme wieder sauber von der Platte runter?
(Mac mini 1,66 Dual Core; OS X 10.4.9)
Danke,
Michael
Ralf Wenzel
> Wie bekomme ich Programme wieder sauber von der Platte runter?
Kommt drauf an wie es installiert wurde ;) Es gibt Programme da reicht
das Löschen des Programmes in "Programme" und es gibt welche, wo man
schon mehr Aufwand treiben muss.
Ralf
--
I'm using an evaluation license of nemo since 32 days.
You should really try it!
http://www.malcom-mac.com/nemo
Matthias Gerds
z.B. mit dem Hilfsprogramm 'uApp', Einfach das Programmicon reinziehen und
alle Dateien (auch *.plist etc.) werden angezeigt und gelöscht.
MG
--
Asus K8N-E AMD64 3000+ 2GB
openSUSE 10.2 Kernel 2.6.18 KDE 3.5.7
VMachines: Win98SE, WinVista Ultimate RC1
MacBook mit Tiger 10.4.9
Ralf Wenzel
> Kommt drauf an wie es installiert wurde ;) Es gibt Programme da
> reicht
im Wesentlichen
> das Löschen des Programmes in "Programme" und es gibt welche,
> wo manschon mehr Aufwand treiben muss.
Juergen Meurer
und ist zur Zeit für 10 Euro zu haben.
cu Juergen
Thomas Kaiser
> Michael Wiesauer schrieb:
>> Gibt es in OS X eine Funktion zur Deinstallation von Programmen? -
>> Wie bekomme ich Programme wieder sauber von der Platte runter? (Mac
>> mini 1,66 Dual Core; OS X 10.4.9)
>>
> und ist zur Zeit für 10 Euro zu haben.
Und jedes Geld für Uninstaller am Mac ist IMO pure Verschwendung, denn
das Problem existiert nicht in der Existenz von Altlasten oder störenden
Dateien irgendwo auf der Platte sondern rein mental im Kopf desjenigen,
der sich Uninstaller wünscht (andersherum wird dann natürlich wieder ein
Schuh draus: Wenn man für 10 Tacken ein gutes Gefühl erhält, ist das
auch was wert)
BTW: Es gibt keinen einzigen Uninstaller für Mac, der den Wunsch der
Anwender von Uninstallern, ein "sauberes möglichst unbelastetes System"
wieder herzustellen, gerecht werden _kann_. Einfach weil es kein Konzept
seitens Apple diesbzgl. gibt, d.h. schon mal rein gar nichts, an das
sich Software-Hersteller denn halten könnten, _wenn_ sie denn wollten.
Gruss,
Thomas
Michael Brendel
ich gebe in Spotlight den Namen des Programms ein. Die Treffer kuck ich
mir an (ob sich nicht vielleicht etwas reinverirrt hat, was da nicht
hingehört) und lösche den ganzen Kram.
Ob man auf diesem Weg wirklich alles findet, was zu dem entsprechenden
Programm gehört, kann ich leider nicht sagen.
Servus,
MiB
Guenther
Wiesauer <effd...@sneakemail.com> wrote:
Eine ganz brauchbare Lösung ist cleanapp. Allerdings: Nicht immer sind
die Vorschläge zum Löschen wirklich 100% zutreffend. Ich lasse öfter
mal einige Dateien noch auf dem Rechner, wenn ich mir nicht sicher über
die Zuordnung zu anderen Programmen bin.
Thomas Kaiser
> Michael Wiesauer <effd...@sneakemail.com> wrote:
>
>> Gibt es in OS X eine Funktion zur Deinstallation von Programmen? -
>> Wie bekomme ich Programme wieder sauber von der Platte runter? (Mac
>> mini 1,66 Dual Core; OS X 10.4.9)
>
> Eine ganz brauchbare Lösung ist cleanapp.
Die taugt genauso viel wie alle anderen sogenannten "Uninstaller" für
den Mac (also AppZapper, uApp und wie sie alle heißen mögen): Nix.
Nochmal: Es gibt am Mac kein Konzept zur Installation von Software
(jeder kann machen, was er will -- und genau das geschieht auch) und
folglich auch keines zur Deinstallation von Software.
Mal die Unterschiede, wie Programme auf die Platte kommen können:
* Programme kommen in Installern, die mit Apples PackageMaker erstellt
wurden. Hier gäbe es noch die Chance, sich anhand des Installations-
"Receipt" anzusehen, was installiert worden wäre. Diese Liste aber für
das Löschen zu nehmen, ist fahrlässig bis brunzdumm, weil ein
Installer auch Systembestandteile hat überschreiben können. Entfernt
man dann anschl. Dateien aufgrund der Auflistung innerhalb des
Receipts, geht vielleicht gar nix mehr, weil wichtige Dateien
plötzlich fehlen.
* Programme kommen in anderen Installern (bspw. Installer VISE). Hier
gilt prinzipiell alles wie oben, nur daß man gar keine Chance hat,
eine Liste mit installierten Dateien einzusehen. Wenn man Glück hat,
legt der Hersteller einen Uninstaller bei, der, wenn man doppeltes
Glück hat, dann sogar korrekt funktioniert...
* Programme kommen rein als Application Bundles daher. Das sieht toll
aus, weil angeblich ja "alles im Bundle" ist... nur fangen diese
Application Bundles beim ersten Start an, sich an diversen Stellen im
System auszuleben, bspw. im Preferences-Ordner des jeweiligen Users
für Programmeinstellungen. Manche Anwendungen kopieren auch Schriften
in Systemverzeichnisse, legen an anderen Stellen Hand an, etc.
Was macht man nun mit all diesen Hinterlassenschaften, wenn man ein
Programm wieder loswerden will? Ganz einfach: Man pfeift drauf! Das ist
der einzige Ansatz, der wirklich funktioniert. Also wenn dann
Application Bundle löschen und fertig. Ob da noch irgendwo andere
Dateien herumschwirren ist so dermaßen egal bei einem Betrübsystem, das
im Auslieferungzustand ca. 4 Trilliarden Dateien, die insg. mehrere
GByte schwer sind, wahllos auf der Festplatte verteilt. Ganz im Ernst:
was jucken da noch ein paar Dateien mehr?
Vor allem: Welcher User kann denn wirklich entscheiden, was welche Datei
genau macht bzw. von welcher Stelle im System noch ggf. gebraucht wird?
Das einzige, was man machen kann, ist den Uninstallern zu *vertrauen*.
Bei mir wenigstens hörts mit dem Vertrauen aber recht schnell auf, wenn
es um meine Daten geht. Da hab ich lieber ein paar Dateileichen mehr im
Keller als daß auf einmal was Wichtiges fehlt.
> Allerdings: Nicht immer sind die Vorschläge zum Löschen wirklich 100%
> zutreffend. Ich lasse öfter mal einige Dateien noch auf dem Rechner,
> wenn ich mir nicht sicher über die Zuordnung zu anderen Programmen
> bin.
Und so einen Ansatz empfiehlst Du? Ein kommerzielles Programm, das ein
bisserl herumrät und irgendwas zum Löschen vorschlägt? Prima :-(
Nochmal ganz allgemein:
Diese sogenannten Uninstaller lernen natürlich mit der Zeit hinzu. Die
ersten Versionen bspw. von AppZapper haben ja schlichtweg alles in den
Orkus befördert, das auch nur annähernd ähnlich benannt war wie das
Programm, das man löschen wollte. Heute kommen die tollen Uninstaller
auch schon mit kleinen Datenbanken, in denen verzeichnet ist, wo sich
welche Programme noch so alles im System ausleben.
Und neuere Vertreter nutzen gar Spotlight-Technologie (konkret fsevents)
um den Zustand _vor_ der Installation von Software mit dem Zustand
_nach_ der Installation zu vergleichen. Dazu ist es aber eben nötig,
besagten Uninstaller auch schon _vor_ der Installation anderer Software
zu starten bzw. deren "Daemons" im Hintergrund laufen zu haben, die
alles überwachen, was überhaupt so am Mac bzw. in dessen Dateisystem
passiert. Will man das wirklich?!
Und es fliegen auch die Spotlight-basierten Kandidaten auf die Schnauze,
wegen Anwendungs-Typ 3 da oben im Spiel ist, der irgendwann aus seinem
Application Bundle ausbricht und noch irgendwo anders Dateien anlegt.
Bzw. kommen diese Uninstaller dann evtl. auch auf die Idee, daß
Nutzdaten, die man während oder kurz nach einer Softwareinstallation
erstellt, dem Programm zuzuordnen wären und folglich später
"deinstalliert", d.h. vernichtet gehören.
Fazit: Es gibt keine Uninstaller für MacOS X, die dem Namen gerecht
würden und erst recht ihr Geld wert wären (selbst wenn sie nur 1 Cent
kosten würden). Und das Ganze ist reine Benutzerverblödung, die
vermutlich die lieben "Switcher" im Visier hat, die Windows-verwöhnt
vermuten, daß zu einem ordentlichen Betriebsystem auch ein ordentlicher
Uninstaller dazugehört, weil das System ja "sauber" bleiben soll...
Nur gibt es halt keine zugemüllte Registry unter MacOS X und auch keine
"DLL-Hölle", d.h. es bringt nichts, Windows-Notwendigkeiten wie
Uninstaller am Mac zu suchen. Und die Tatsache, daß es traurigerweise
inzwischen sogar mehrerer solcher Augenwischerei-Tools gibt, bedeutet
erst recht nicht, daß der Bedarf für solche Lösungen gestiegen wäre.
Nur, daß es inzwischen ausreichend Leute am Mac gibt, die darauf
hereinfallen.
Unter MacOS X gibt es keinerlei technische Notwendigkeit für den Einsatz
von "Uninstallern". Es ist ein rein mentales Problem, das ich in erster
Linie von Menschen kenne, die sattsam von den Verhältnissen unter
Windows geprägt bzw. versaut sind...
Gruss,
Thomas, ein absolut sauber laufendes System habend ohne jemals so einen
Quatsch wie Uninstaller eingesetzt zu haben...
Wolfgang Kefurt
> Nochmal: Es gibt am Mac kein Konzept zur Installation von Software
> (jeder kann machen, was er will -- und genau das geschieht auch) und
> folglich auch keines zur Deinstallation von Software.
>
Ich als nur-Anwender und nicht-Programmierer frage mal ganz unbedarft:
Warum hat Apple denn nicht die Chance genutzt und mit Einführung von OS
X endlich festgelegt, wie und wo etwas installiert werden darf?
Vermutlich waren die sich selbst nicht ganz sicher wie es weitergehen
soll, oder?
Drag´n Drop Installation wäre so eine schöne Sache, wenn außer den Prefs
nix liegen bliebe. Restriktive Maßnahmen für bestimmte Orte zum ablegen
der Dateien gab es ja für OS 9.x Umsteiger (ich meine auch hier
ausnahmslos Anwender) zur genüge, warum nicht gleich den MSlern und
Adoblern auch eine auf die Finger klopfen?
Wenn diese Programme etwa zusätzlich Fonts benötigen die sonst keiner
braucht, sollten sie sich gefälligst den eigenen Programmordner zumüllen
anstatt im System zu kramen. Allgemein sollte doch der Trend zur
einfachen draufundfallenlassen-Installation fortgesetzt werden,
mittlerweile scheint mir aber, kehren eher die Installer-Orgien vermehrt
zurück.
> Mal die Unterschiede, wie Programme auf die Platte kommen können:
>
> * Programme kommen in Installern, die mit Apples PackageMaker erstellt
Sollte IMHO Apple und dem System vorbehalten bleiben...
Oder zumindest nur für Treibersoftware Verwendung finden.
> * Programme kommen in anderen Installern (bspw. Installer VISE). Hier
> gilt prinzipiell alles wie oben, nur daß man gar keine Chance hat,
> eine Liste mit installierten Dateien einzusehen. Wenn man Glück hat,
> legt der Hersteller einen Uninstaller bei, der, wenn man doppeltes
> Glück hat, dann sogar korrekt funktioniert...
Mit präzisen Richtlinien hätte Apple hier z.B. rechtzeitig festlegen
müssen, daß außer Prefs nix im System landen darf und ein Uninstaller
Pflicht ist.
> * Programme kommen rein als Application Bundles daher. Das sieht toll
> aus, weil angeblich ja "alles im Bundle" ist... nur fangen diese
> Application Bundles beim ersten Start an, sich an diversen Stellen im
> System auszuleben, bspw. im Preferences-Ordner des jeweiligen Users
> für Programmeinstellungen. Manche Anwendungen kopieren auch Schriften
> in Systemverzeichnisse, legen an anderen Stellen Hand an, etc.
Auch hier hätte der zweite Punkt Schaden verhindern können. Zusätzliches
Zeug welches nur dem installierten Programm dient und überdies womöglich
gar nicht gewollt wird, ausschließlich im eigenen Programmordner
installieren zu lassen.
Mit diesen Regeln hätte es theoretisch möglich sein müssen, sein System
wieder in den Zustand vor der Installation versetzen zu können. Jetzt
ist es halt zu spät dafür...
> Und neuere Vertreter nutzen gar Spotlight-Technologie (konkret fsevents)
> um den Zustand _vor_ der Installation von Software mit dem Zustand
> _nach_ der Installation zu vergleichen. Dazu ist es aber eben nötig,
> besagten Uninstaller auch schon _vor_ der Installation anderer Software
> zu starten bzw. deren "Daemons" im Hintergrund laufen zu haben, die
> alles überwachen, was überhaupt so am Mac bzw. in dessen Dateisystem
> passiert. Will man das wirklich?!
Auch sowas wäre mit reinem Drag´nDrop und löschen der Prefs unnötig.
Hmmm, aber gab´s das nicht schon mal...in Mac OS <10?
;=)
--
Grüße
Wolfgang
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Nochmal: Es gibt am Mac kein Konzept zur Installation von Software
>> (jeder kann machen, was er will -- und genau das geschieht auch) und
>> folglich auch keines zur Deinstallation von Software.
>
> Ich als nur-Anwender und nicht-Programmierer frage mal ganz unbedarft:
> Warum hat Apple denn nicht die Chance genutzt und mit Einführung von OS
> X endlich festgelegt, wie und wo etwas installiert werden darf?
Haben sie doch. Es gibt da glasklare Vorgaben. Und Klitschen wie Adobe
und Microsoft, die immer als die bösen Buben dafür herhalten sollen, daß
sie nicht "alles in einem Bundle" ausliefern, halten sich da auch im
Großen und Ganzen daran.
Guckstu hier für einen Startpunkt:
> Vermutlich waren die sich selbst nicht ganz sicher wie es weitergehen
> soll, oder?
Es gibt einerseits das häßliche Wort "Abwärtskompatibilität" und zum
anderen ist es eben wirklich nicht so einfach, wie sich das Laien (im
Bezug auf Software-Entwicklung) regelmäßig vorstellen.
> Drag´n Drop Installation wäre so eine schöne Sache, wenn außer den
> Prefs nix liegen bliebe. Restriktive Maßnahmen für bestimmte Orte zum
> ablegen der Dateien gab es ja für OS 9.x Umsteiger (ich meine auch
> hier ausnahmslos Anwender) zur genüge, warum nicht gleich den MSlern
> und Adoblern auch eine auf die Finger klopfen?
Hä?
Die halten sich doch sogar dran und kippen gemeinsam genutzte Libraries
und so Kram unterhalb »/Library/Application Support«, etc. ab.
> Wenn diese Programme etwa zusätzlich Fonts benötigen die sonst keiner
> braucht, sollten sie sich gefälligst den eigenen Programmordner
> zumüllen anstatt im System zu kramen.
Das geschieht doch sogar (siehe Multiple Master Fonts, die innerhalb
Acrobat stecken bspw.). Auf der anderen Seite ist es einfach widersinnig
die selbe Anzahl Fonts in jedem Programm-Bundle vorzuhalten, wenn bspw.
alle Programme aus Adobes Creative Suite auf diese zugreifen sollen.
Eben dafür gibt es ja die verschiedenen Font-Ordner -- die sind *genau*
für diesen Zweck bestimmt, gemeinsam genutzte Resourcen platzsparend(er)
abzulegen.
Und die Probleme mit Schriften entstehen doch nicht dadurch, daß
Anwendungen im Rahmen ihrer Installation oder des ersten Starts
Schriften irgendwo auf die Platte kippen sondern *erst dann*, wenn
Benutzer anfangen, von Hand an den Schriften herumzufummeln und diese zu
"organisieren" (wie üblich, ohne zu wissen, was sie da tun und mit einem
klaren Feindbild im Hinterkopf -- böse Anwendung von böser Firma
Microsoft im Normalfall, inzwischen auch regelmäßig durch "Adobe"
ersetzbar -- und nicht falsch verstehen: Beide Läden liefern teils
grandiosen Schrott ab... halten sich aber gerade in Bezug auf "Wo wird
was hingekippt?" im Regelfall an Apples Vorgaben)
Zu Schriftenproblemen siehe hier:
<http://www.tidbits.com/tb-issues/lang/de/TidBITS-de-831.html#Artikel4>
Nachgucken, was man alles so auf Platte hat, geht ab 10.4 simpelst via
Spotlight per
mdfind 'kMDItemKind == "font"wcd'
Für mich sind Uninstaller inzwischen eine weitere potentielle Quelle von
maladen Systemen. Es ist doch wirklich bezeichnend, daß MacOS X
Installationen, an denen gar nicht gebastelt wird (also kein andauerndes
"Rechte Reparieren", keine präventive Onyx- und Cocktail-"Systempflege",
kein "Aufräumen" an Orten, von denen man sich besser fernhalten sollte)
einfach so problemfrei durchlaufen. Und die, an denen sich Hobby-Admins
angestachelt durch Tipps&Tricks aus "Fachmagazinen" à la MacSabber oder
MacBlöd vergehen, früher oder später in Schieflage geraten.
>> Mal die Unterschiede, wie Programme auf die Platte kommen können:
>>
>> * Programme kommen in Installern, die mit Apples PackageMaker erstellt
>
> Sollte IMHO Apple und dem System vorbehalten bleiben...
> Oder zumindest nur für Treibersoftware Verwendung finden.
Nein, *alle* Softwarehersteller sollten IMO Apples PackageMaker nehmen,
falls sie etwas ausliefern, was man nicht in ein Bundle stecken kann,
damit diese Krankheit namens "Installer VISE" endlich verschwindet. Mit
Apples Installer-Mechanismus entsteht wenigstens ein bisschen
Transparenz in der Form, daß man auch als Enduser relativ problemlos
nachschauen kann, was eigentlich alles installiert wird (kann man
einblendden lassen vom Installer).
Bei proprietären Installern hat man gar keine Ahnung, was alles
installiert wird und muß mit Tools wie fseventer oder Sonar/sandal
parallel zugucken, wo was hingemüllt wird.
>> * Programme kommen in anderen Installern (bspw. Installer VISE). Hier
>> gilt prinzipiell alles wie oben, nur daß man gar keine Chance hat,
>> eine Liste mit installierten Dateien einzusehen. Wenn man Glück
>> hat, legt der Hersteller einen Uninstaller bei, der, wenn man
>> doppeltes Glück hat, dann sogar korrekt funktioniert...
>
> Mit präzisen Richtlinien hätte Apple hier z.B. rechtzeitig festlegen
> müssen, daß außer Prefs nix im System landen darf
Lies Dir Apples Vorgaben dazu einfach nochmal durch. Es gibt mehr als
Prefs, die irgendwo abgelegt werden müssen. Und es gibt Sachen, die
leider sonstwohin müssen (bspw. Filter/Backends/"Treiber" des Druck-
systems, oder Kernel Extensions oder StartupItems oder dies und das und
sonstnochwas -- es paßt eben nicht alles nur in ein Application Bundle)
> und ein Uninstaller Pflicht ist.
Dieser Pflicht zum Uninstaller widersprächen:
* Apples nett anzuhörender Idee vom self-containing Application Bundle,
dessen Entsorgung ja bereits schon genügen solle, damit alles wieder
von der Platte ist
* Dem Fakt, daß es Uninstaller einfach nicht wirklich braucht. Was stört
denn eine Einstellungs-Datei, auf die kein Programm zugreift? Oder
eine Schriftart, die man nicht benutzt? Oder Shared Libraries, die
irgendwo unterhalb "Application Support" vor sich hin modern? Exakt:
Gar nichts, total egal, keine Gedanken drüber machen.
Wenn man sich mal vor Augen hält, wieviele zehntausende Dateien in
einer frischen MacOS X Installation garantiert niemals auch nur ein
einziges mal geöffnet werden (bspw. der ganze Kram unterhalb
/Library/Printers -- die wenigstens werden an ihrem Mac mehr als 3-4
Drucker einsetzen, da steckt aber der Support für hunderte bis
vielleicht sogar tausende Drucker drin) dann sieht man das hoffentlich
auch mit den Altlasten entsorgter Application Bundles ein wenig
entspannter
> Mit diesen Regeln hätte es theoretisch möglich sein müssen, sein
> System wieder in den Zustand vor der Installation versetzen zu können.
Nein, auch das nicht. Es kann bspw. nötig sein, wenn eine neue Software
installiert wird, daß gewisse Dinge tief im Inneren von MacOS X
ausgetauscht werden müssen (bspw. Kernel-Extensions -- iTunes und Quick-
Time-Installer sind bekannt für sowas wegen DRM-Schrott, etc.).
Der Installer muß also definitiv Sachen löschen. Es fehlt aber ein
Konzept, wo sowas hingeparkt werden soll, damit man eben ein Update oder
eine Software-Installation auch wieder rückstandsfrei rückgängig machen
könnte. Da hat Apple nix in petto -- weit und breit nix. Und wenn sie
was hätten, wäre fraglich, ob sich Anwendungsprogrammierer an solche
Vorgaben hielten, wo doch Apple als schlechtes Beispiel Nr. 1 vorneweg
marschiert.
Man muß schlicht und einfach mit der Tatsache leben, daß
* Uninstaller unter MacOS X nicht vernünftig funktionieren *können*
* Das das Ganze aber bei normalen Programmen so dermaßen wurscht ist,
daß man sich keinen Kopf drüber machen muß (weil ein paar Dateileichen
hier oder dort auf Platte schlicht und ergreifend nicht schaden!)
Was anderes sind System-Updates, bei denen Apple ja nur diesen ekligen
Mix aus Sicherheits- und groß angelegten Funktionalitäts-Updates
anbietet. Hier wäre ein Redo eines Updates eine wirklich feine Sache.
Aber Pustekuchen -- da wird wohl auch nie was Sinnvolles von Apple
kommen. Entspricht einfach nicht der Entwicklungsphilosohpie dahinter
(und die lautet: "Friß oder stirb!")
Gruss,
Thomas
Patrick Kormann
> * Das das Ganze aber bei normalen Programmen so dermaßen wurscht ist,
> daß man sich keinen Kopf drüber machen muß (weil ein paar Dateileichen
> hier oder dort auf Platte schlicht und ergreifend nicht schaden!)
Das Ganze sieht schnell anders aus, wenn die Programme beim Systemstart
automatisch starten (und es nur ca. 520000 Möglichkeiten gibt, wie man
das bewerkstelligt) oder eben tiefer in's System dringen - dann
vielleicht ne Preferences-Pane mitbringen etc.
Spätestens wenn das Zeugs dann unter Leopard nicht mehr tut, möchte
man's los werden.
Aber das hast du wohl mit 'normalen Programmen' nicht gemeint…
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> * Das das Ganze aber bei normalen Programmen so dermaßen wurscht ist,
>> daß man sich keinen Kopf drüber machen muß (weil ein paar
>> Dateileichen hier oder dort auf Platte schlicht und ergreifend
>> nicht schaden!)
>
> Das Ganze sieht schnell anders aus, wenn die Programme beim
> Systemstart automatisch starten (und es nur ca. 520000 Möglichkeiten
> gibt, wie man das bewerkstelligt)
Hä? Was ist mit 520000 Möglichkeiten? Für was?
> oder eben tiefer in's System dringen - dann vielleicht ne
> Preferences-Pane mitbringen etc.
Ja und? Ich wünsche sehr viel Spaß damit, einen dieser MacOS X
Uninstaller auf $irgendwas loszulassen, das auch nur ein bisserl tiefer
ins System eingreift. Die Chancen, daß dabei anschl. ein Scherbenhaufen
zurückbleibt, sind sehr groß.
Alleine das, was ich diese und letzte Woche von größeren
Software-Häusern im Rahmen irgendwelcher Betatests auf dem Rechner
hatte, kann mit herkömmlichen Uninstaller-Ansätzen nicht so beseitigt
werden, daß anschl. der Rechner noch läuft (weil die Entwickler der
Installer einfach ein paar Prinzipien, wie dies&das am Mac funktioniert,
nicht raffen und die Entwickler der Uninstaller dann noch das ihrige
getan haben, damit die Katastrophe perfekt wird)
> Spätestens wenn das Zeugs dann unter Leopard nicht mehr tut, möchte
> man's los werden.
Ja. Dann installiert man sich halt den Leopold vernünftig ohne Hacks
(also bspw. unter Zuhilfenahme des Migrations-Assistenten) und nicht nur
einfach "drüber" oder entsorgt einzelne Komponenten anschließend.
PrefPanes liegen hier und dort:
/Library/PreferencePanes/
~/Library/PreferencePanes/
Zeugs, das automatisch gestartet wird, sollte hier liegen (in der Praxis
findet sich leider auch immer Schrott, der sich unterhalb
/System/Library breitmacht -- VPN-Installer jeden Herstellers bspw.):
/Library/StartupItems/
/Library/LaunchDaemons/
/Library/LaunchAgents/
oder ist über das "Benutzer"-Prefpane in den Systemeinstellungen zu
verwalten (loginwindow.plist). Wo ist das Problem?
V.a. der Wunsch, solche Sachen loszuwerden, mag ja durchaus berechtigt
sein. Aber ob Dir den jeder dieser Uninstaller *ohne Nebenwirkungen*
auch so erfüllen kann, ist das andere.
Denn nach meinen Erfahrungen straucheln die gerne bei allem, was ein
bisserl tiefer ins System eingreift, sei es weil sie Dinge, die
ursprünglich mal nur aktualisiert wurden, entfernen (in der irrigen
Annahme hier wäre eine neue Datei hinzugekommen) und anschl. gar nix
mehr geht oder weil sie aus Vorsicht derlei Sachen gar nicht mehr
anbieten.
> Aber das hast du wohl mit 'normalen Programmen' nicht gemeint
Ich habe "normale Programme" als Abgrenzung zu System-Updates benutzt.
Für die hätte ich gerne eine Undo-Möglichkeit. Für "Programme" verzichte
ich da herzlich gerne darauf, weil es nicht nötig ist bzw. nicht gscheid
funktionieren kann...
Gruss,
Thomas
Patrick Kormann
> Hä? Was ist mit 520000 Möglichkeiten? Für was?
Um etwas beim Systemstart automatisch starten zu lassen…
> Ja und? Ich wünsche sehr viel Spaß damit, einen dieser MacOS X
> Uninstaller auf $irgendwas loszulassen, das auch nur ein bisserl tiefer
> ins System eingreift. Die Chancen, daß dabei anschl. ein Scherbenhaufen
> zurückbleibt, sind sehr groß.
Nur die Ruhe, nur die Ruhe. Ich habe ja nicht behauptet, dass
Uninstaller toll sind, aber dass mit dem Löschen eines Appbundles die
Sache gegessen ist, ist leider auch nicht immer richtig.
Ansonsten seh ich wenig unbekanntes in deinem Posting. Nur das:
> Ja. Dann installiert man sich halt den Leopold vernünftig ohne Hacks
> (also bspw. unter Zuhilfenahme des Migrations-Assistenten) und nicht nur
> einfach "drüber" oder entsorgt einzelne Komponenten anschließend.
Würde der Migrationsassistent z.B. ein 'Fan Control' nicht auch
rüberziehen?
> /Library/StartupItems/
> /Library/LaunchDaemons/
> /Library/LaunchAgents/
>
> oder ist über das "Benutzer"-Prefpane in den Systemeinstellungen zu
> verwalten (loginwindow.plist). Wo ist das Problem?
Na gut, es sind nicht 520000 aber eben doch einige, wenn man /Library,
/System/Library, ~/Library etc. etc. anschaut.
Es widerspricht (IMHO) halt ein bisschen der Mac Philosophie, dass ich
sowas dann nur noch 'Auf Systemebene' los werde…
Wolfgang Kefurt
> Es gibt einerseits das häßliche Wort "Abwärtskompatibilität" und zum
> anderen ist es eben wirklich nicht so einfach, wie sich das Laien (im
> Bezug auf Software-Entwicklung) regelmäßig vorstellen.
Schon klar, ich wollt ja nur darstellen, wie man es aus Anwendersicht am
schönsten und übersichtlichsten gerne hätte :-)
>> Drag´n Drop Installation wäre so eine schöne Sache, wenn außer den
>> Prefs nix liegen bliebe. Restriktive Maßnahmen für bestimmte Orte zum
>> ablegen der Dateien gab es ja für OS 9.x Umsteiger (ich meine auch
>> hier ausnahmslos Anwender) zur genüge, warum nicht gleich den MSlern
>> und Adoblern auch eine auf die Finger klopfen?
>
> Hä?
Na in Anbetracht der Tatsache, daß unter OS 9 die Ordner und Daten
überwiegend und wahllos auf der ersten Ordnerebene oder am Desktop
herumlagen, hat man sich ja mittlerweile schon an sein Home-Verzeichnis
gewöhnt. Das musste man als gewachsener Mackel erst mal lernen.
> Die halten sich doch sogar dran und kippen gemeinsam genutzte Libraries
> und so Kram unterhalb »/Library/Application Support«, etc. ab.
Ja OK, dort sollte man als unbedarfter doch bereits nicht mehr
rumfummeln müssen...
Und das wird auch je nach Ausprobierwahn des Users immer mehr und bleibt
dort liegen. Noch dazu sind solche unterstützenden Daten oft auch nicht
einfach zu finden und mit dem zugehörigen (zu entfernenden) Programm in
Verbindung zu bringen, weil sie etwa vom Programm völlig unabhängige
Namen besitzen und ähnliches. Nicht sehr optimal meiner Meinung nach.
>>> * Programme kommen in Installern, die mit Apples PackageMaker erstellt
>>
>> Sollte IMHO Apple und dem System vorbehalten bleiben...
>> Oder zumindest nur für Treibersoftware Verwendung finden.
>
> Nein, *alle* Softwarehersteller sollten IMO Apples PackageMaker nehmen,
> falls sie etwas ausliefern, was man nicht in ein Bundle stecken kann,
> damit diese Krankheit namens "Installer VISE" endlich verschwindet. Mit
> Apples Installer-Mechanismus entsteht wenigstens ein bisschen
> Transparenz in der Form, daß man auch als Enduser relativ problemlos
> nachschauen kann, was eigentlich alles installiert wird (kann man
> einblendden lassen vom Installer).
Naja, ich weiß nicht...
Gerade eben habe ich DxO OpticsPro aktualisiert. Der Installer sieht
zumindest aus wie der von Apple und wieder einmal kommt keine Frage
wohin ich das Ding gerne hätte, nein er installiert ungefragt in den
Programmordner! Ich würde lieber _vorher_ gefragt werden, ob er nicht
doch in den Unterordner "Grafikprogramme" istallieren soll, anstatt
_nacher_ händisch zu verschieben ;-)
>> Mit präzisen Richtlinien hätte Apple hier z.B. rechtzeitig festlegen
>> müssen, daß außer Prefs nix im System landen darf
>
> Lies Dir Apples Vorgaben dazu einfach nochmal durch. Es gibt mehr als
> Prefs, die irgendwo abgelegt werden müssen. Und es gibt Sachen, die
> leider sonstwohin müssen (bspw. Filter/Backends/"Treiber" des Druck-
> systems, oder Kernel Extensions oder StartupItems oder dies und das und
> sonstnochwas -- es paßt eben nicht alles nur in ein Application Bundle)
OK, das geht aber schon sehr ins Eingemachte. Dann halt eine Routine,
welche beim löschen der Anwendug die verteilten Goodies wieder mitnimmt
und dem User nur die Prefs zu löschen überläasst. Besser?
> Aber Pustekuchen -- da wird wohl auch nie was Sinnvolles von Apple
> kommen. Entspricht einfach nicht der Entwicklungsphilosohpie dahinter
> (und die lautet: "Friß oder stirb!")
>
> Gruss,
>
> Thomas
Das trifft den Kern am ehesten.
--
Grüße
Wolfgang
Wolfgang Kefurt
> So, wie die Situation auf OS X ist, war es schon Ende der 80er, Anfang
> der 90er auf dem Vorgänger NeXTSTEP und es wurde quasi ohne Änderung
> übernommen, wie die meisten anderen Sachen auch.
> Man darf ja nicht vergessen, daß Apple da nichts völlig Neues
> entwickelt, sondern ein wesentlich älteres System nur portiert und ein
> wenig aufgebrezelt hat.
Also eine Gelegenheit verpasst.
Mein Kontakt mit Openstep (1994) war zum Glück nur kurz und auf einem
400Mhz P3 Rechner in der Firma. Der gebliebene Eindruck ist bis heute
der, daß es langsam (display postscript), unflexibel für Anwender
(wahrscheinlich schon damals wegen der Rechtevergabe) und optisch
überfrachtet war (große Icons und unnötige Effekte). Ich bilde mir ein,
manches davon findet man auch heute noch in OS X. ;-)
> Resultat ist dann eben, daß z.B. mein 1997 installiertes und seitdem
> kontinuierlich upgedatetes Debiansystem heute noch blitzsauber und
> aufgeräumt ist, während eine nur zwei Jahre alte OS X Installation
> schon nett versumpft ist.
Und wie bzw. woran merkst du das es "versumpft" ist?
Thomas behauptet doch das Gegenteil, es sei völlig Wurst wenn da ein
paar Dateileichen mehr herumliegen!
> Ist aus Sicht von Apple vermutlich auch nicht weiter tragisch, weil
> man ohnehin alle paar Jahre eine neue OS-Version kaufen soll und sich
> der Müllhaufen auf der Platte dann durch Neuinstallation erledigt.
> Bei anderen Herstellern von kommerziellen OS scheint man das nebenbei
> auch nicht anders zu sehen.
Leider!
Andererseits, mein OS X schleppe ich auch schon seit 2002 mit dem G4 MDD
und jetzt am G5 2x2 relativ sturzfrei herum. Einzig der Ruhezustand geht
zur Zeit nicht und ich habe noch keinen Schuldigen gefunden, what shall´s...
--
Grüße
Wolfgang
Ingo Paschke
>Mein Kontakt mit Openstep (1994) war zum Glück nur kurz und auf einem
>400Mhz P3 Rechner in der Firma. Der gebliebene Eindruck ist bis heute
>der, daß es langsam (display postscript), unflexibel für Anwender
>(wahrscheinlich schon damals wegen der Rechtevergabe) und optisch
>überfrachtet war (große Icons und unnötige Effekte). Ich bilde mir ein,
>manches davon findet man auch heute noch in OS X. ;-)
1994 waren Pentium I-Prozessoren um 100 MHz aktuell. Der Pentium III wurde
erst fuenf Jahre spaeter vorgestellt. Ich fand das damals nicht unertraeglich
langsam, was rueckblickend schon irgendwie erstaunlich ist :-).
Gruss,
Ingo.
Wolfgang Kefurt
> Wolfgang Kefurt <wolfgan...@gmx.at> writes:
>
>>Mein Kontakt mit Openstep (1994) war zum Glück nur kurz und auf einem
>
> 1994 waren Pentium I-Prozessoren um 100 MHz aktuell. Der Pentium III wurde
> erst fuenf Jahre spaeter vorgestellt.
Uuups, war das noch P-I?
Wir hatten damals noch DEC-Alpha Workstations und Macs mit OS 7.5 oder
so. Kann sein das es auch ein Jahr später war. Mein Gott, die Zeit rast
nur so dahin...wie ihr euch die Rechnergenerationen merkt ist
erstaunlich. Ich kann das nicht. Aus den Augen aus dem Sinn, übrig
bleibt das was man noch braucht. :-)
> Ich fand das damals nicht unertraeglich
> langsam, was rueckblickend schon irgendwie erstaunlich ist :-).
Hmm, das Ding wovon ich schrieb war mit einer Software namens Digiscript
aufgestellt worden und diente der PS-Dateien Nachbearbeitung/Korrektur.
Es kann natürlich sein, daß dies auch nicht gerade zum flott-empfinden
des Rechners beigetragen hat. Der verwendete Rechner damals wurde als
neueste Generation bezeichnet, vielleicht war ja schon ein P-II drin,
aber auch egal. Im Vergleich mit OS 7.5 und den Alphas wirkte der
OpenStep-Rechner jedenfalls (zumindest die Benutzeroberfläche) wie
gelähmt...
--
Grüße
Wolfgang
Goetz Hoffart
> Im Vergleich mit OS 7.5 und den Alphas wirkte der
> OpenStep-Rechner jedenfalls (zumindest die Benutzeroberfläche) wie
> gelähmt...
Dafür war man vor OS 7.5 wie gelähmt, wenn der Fehler 11 mal wieder
auftrat: mangels Speicherschutz war ein harter Reset notwendig.
Grüße
Götz
--
http://www.knubbelmac.de/
Juergen Meurer
Das kannst du sehen wie du willst.
CleanApp läßt einen Dienst im Hintergrund lauf der sich einfach ansieht
welche Dateien bzw. Verzeichnisse das Programm verändert.
Das man danach noch einmal drübersieht bevor man löschen sagr dürfte
klar sein.
Es ist aber das einzig vernünftige Programm was ich kenne was auch Plist
Einträge usw. entfernt.
Zusätzlich kannst du damit nicht benötigten Code bei einem Combo Paket
verschwinden lassen, unbenötigte Sprachen entfernen usw.
Und dafür sind 10 Euro garantiert nicht zuviel.
cu Juergen
Thomas Adams
> Leider!
> Andererseits, mein OS X schleppe ich auch schon seit 2002 mit dem G4 MDD
> und jetzt am G5 2x2 relativ sturzfrei herum. Einzig der Ruhezustand geht
> zur Zeit nicht und ich habe noch keinen Schuldigen gefunden
Bei mir ist dafür der Schuldige die USB-Karte.
--
<insert witty comment here>
Wolfgang Kefurt
>> Leider!
>> Andererseits, mein OS X schleppe ich auch schon seit 2002 mit dem G4 MDD
>> und jetzt am G5 2x2 relativ sturzfrei herum. Einzig der Ruhezustand geht
>> zur Zeit nicht und ich habe noch keinen Schuldigen gefunden
>
> Bei mir ist dafür der Schuldige die USB-Karte.
Tja, gut möglich, kann bei mir genauso sein.
Aber was tun fragt man sich? Bei mir war das übrigens erst seit einem
der 10.4 updates der Fall, der Ruhezustand ging schon mal besser.
Die mickrigen 3 originalen USB-Ports reichen halt gerade für Tastatur,
mini-Hub mit Dongles und eventuell einen USB- oder Bluetooth-Stick.
Scanner, Drucker, Tablett, Cardreader etc. wollen teilweise an einem Hub
gar nicht, oder werden dort nicht richtig/immer erkannt. USB ist eine
wilde Baustelle...
So jetzt höre ich auf bevor es ganz OT wird. :-)
--
Grüße
Wolfgang
Klaus-Dieter Tepper
> Aber was tun fragt man sich?
Andere USB-Karte verwenden. Ich habe eine Sonnett Allegro in meinem G5,
und der Ruhezustand funktioniert.
Gruß, Klaus-Dieter
Clemens Beier
> Thomas Adams schrieb:
> > Bei mir ist dafür der Schuldige die USB-Karte.
>
> Tja, gut möglich, kann bei mir genauso sein.
> Aber was tun fragt man sich? Bei mir war das übrigens erst seit einem
> der 10.4 updates der Fall, der Ruhezustand ging schon mal besser.
>
> Die mickrigen 3 originalen USB-Ports reichen halt gerade für Tastatur,
> mini-Hub mit Dongles und eventuell einen USB- oder Bluetooth-Stick.
> Scanner, Drucker, Tablett, Cardreader etc. wollen teilweise an einem Hub
> gar nicht, oder werden dort nicht richtig/immer erkannt. USB ist eine
> wilde Baustelle...
... und immer noch eine Baustelle die Apple wohl nicht in den Griff
bringen kann.
Zitat MacFixit
<http://www.macfixit.com/article.php?story=20070628092230595>
Mac OS X 10.4.10 (#7): USB disasters and recovery
[Published Thursday, June 28th]
USB problems: devices not recognized, more, fixes Since Mac OS X 10.4.10
makes major modifications to the USB subsystem in Mac OS X, it's no
surprise that many users are experiencing significant issues with USB
devices after the update. These include inability to mount or recognize
devices, crashes when connecting devices and more. Many of these issues
were also occurring under Security Update 2007-005, which is rolled into
Mac OS X 10.4.10.
(...)
Fixes
* Get the update off your Mac (...)
* Revert kernel extensions
ClemiSan (ohne Update auf *.10)
Robert Schaffner
> Andere USB-Karte verwenden. Ich habe eine Sonnett Allegro in meinem G5,
> und der Ruhezustand funktioniert.
Das geht mit dieser Karte in einem G4 auch. Wollte ich nur bestätigen.
(Wärend -diverse- andere Karten den Ruhezustand garantiert verhindern)
Gruß, Robert
--
-= DOIT-Hardware FAQs =-
___________________________________
Apple Macintosh Hardware FAQs
<http://www.doitarchive.de>
Thomas Adams
> Klaus-Dieter Tepper <klaus-die...@t-online.de> wrote:
>
> > Andere USB-Karte verwenden. Ich habe eine Sonnett Allegro in meinem G5,
> > und der Ruhezustand funktioniert.
>
> Das geht mit dieser Karte in einem G4 auch. Wollte ich nur bestätigen.
Seit dem Einbau exakt dieser Karte in meinen Quicksilver geht der
Ruhezustand nicht mehr.
Robert Schaffner
> Seit dem Einbau exakt dieser Karte in meinen Quicksilver geht der
> Ruhezustand nicht mehr.
PRAM-Reset nach dem Einbau gemacht?
Du bist dann der einzige, den ich kenne, bei dem es mit der
Karte nicht geht :)
Es liegt aber vielleicht eher an einem der daran angeschlossenen
USB-Geräte.
Thomas Kaiser
> Thomas Kaiser schrieb:
>>
>> Und jedes Geld für Uninstaller am Mac ist IMO pure Verschwendung, denn
>> das Problem existiert nicht in der Existenz von Altlasten oder störenden
>> Dateien irgendwo auf der Platte sondern rein mental im Kopf desjenigen,
>> der sich Uninstaller wünscht (andersherum wird dann natürlich wieder ein
>> Schuh draus: Wenn man für 10 Tacken ein gutes Gefühl erhält, ist das
>> auch was wert)
>>
>> BTW: Es gibt keinen einzigen Uninstaller für Mac, der den Wunsch der
>> Anwender von Uninstallern, ein "sauberes möglichst unbelastetes System"
>> wieder herzustellen, gerecht werden _kann_. Einfach weil es kein Konzept
>> seitens Apple diesbzgl. gibt, d.h. schon mal rein gar nichts, an das
>> sich Software-Hersteller denn halten könnten, _wenn_ sie denn wollten.
>
> Das kannst du sehen wie du willst.
Ich kann's auch begründen, nebenbei bemerkt :-)
> CleanApp läßt einen Dienst im Hintergrund lauf der sich einfach ansieht
> welche Dateien bzw. Verzeichnisse das Programm verändert.
Ist bekannt. Deshalb läuft es ja auch erst seit 10.4 und deshalb muß das
Programm _vorher_ laufen, damit man sich anschl. der Jagd auf Altlasten
hingeben kann...
> Das man danach noch einmal drübersieht bevor man löschen sagr dürfte
> klar sein.
Echt? Ich dachte, dafür wäre das Programm dar? Wer ist dann im
Zweifelsfall schuld, wenn was Falsches gelöscht wird? Der Anwender oder,
weil er seiner Pflicht zum "Drübersehen" nicht nachgekommen ist, ja?
> Es ist aber das einzig vernünftige Programm was ich kenne was auch Plist
> Einträge usw. entfernt.
Bitte was? Was soll es machen?
Selektive Änderungen an Property Lists, die ein Programm vornimmt,
wieder rückgängig machen oder doch nur einfach die einem Programm
vermutlich evtl. vielleicht zugehörigen Property Lists mit zum Löschen
anbieten?
Je nach Deiner Antwort, könnte _für Dich_ auch ein Blick auf Yank
interessant sein. Das taugt ebenso wenig, bedient sich aber ebenfalls
bei Spotlight/fsevents, um permanent zu gucken, was Du als User so auf
Deinem System machst, damit es Dir anschl. Löschvorschläge unterbreiten
kann.
> Zusätzlich kannst du damit nicht benötigten Code bei einem Combo Paket
> verschwinden lassen, unbenötigte Sprachen entfernen usw.
Wow. Voll die Multi-Funktionswaffe. Quasi schon Kategorie Onyx und
Cocktail und Konsorten? Also totaler Verschlimmbesserungsschrott? :-)
> Und dafür sind 10 Euro garantiert nicht zuviel.
Mei, ich hab's initial ja schon gesagt: Wenn einem ein gutes Gefühl 10
EUR wert sind, dann soll man sie eben ausgeben -- irgendwer freut sich
ja doch immer drüber...
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Ja und? Ich wünsche sehr viel Spaß damit, einen dieser MacOS X
>> Uninstaller auf $irgendwas loszulassen, das auch nur ein bisserl
>> tiefer ins System eingreift. Die Chancen, daß dabei anschl. ein
>> Scherbenhaufen zurückbleibt, sind sehr groß.
>
> Nur die Ruhe, nur die Ruhe. Ich habe ja nicht behauptet, dass
> Uninstaller toll sind, aber dass mit dem Löschen eines Appbundles die
> Sache gegessen ist, ist leider auch nicht immer richtig.
Aber hier geht es darum, daß Uninstaller gesucht und empfohlen werden.
Und die Denke dahinter ist eine, die IMO hinterfragt gehört. Denn eine
Datei, die einfach so herumliegt, tut im Normallfall auch keinem was
(außer eben ein bisschen Platz belegen)
Die von Dir aufgeführten Spezialfälle sind gute Beispiel für sowohl
Bereiche, bei denen die Uninstaller meist kläglich versagen, als auch
für echten Bedarf einer sauberen Deinstallationsmöglichkeit.
>> Dann installiert man sich halt den Leopold vernünftig ohne Hacks
>> (also bspw. unter Zuhilfenahme des Migrations-Assistenten) und nicht
>> nur einfach "drüber" oder entsorgt einzelne Komponenten anschließend.
>
> Würde der Migrationsassistent z.B. ein 'Fan Control' nicht auch
> rüberziehen?
Wenn ich wüsste, in welche Kateforie das fällt, könnte ich vielleicht
irgendeine Aussage dazu treffen.
> Es widerspricht (IMHO) halt ein bisschen der Mac Philosophie, dass ich
> sowas dann nur noch 'Auf Systemebene' los werde
Tja, so ist es leider. Und daran ändern auch Augenwischerei-"Werkzeuge"
wie Uninstaller nichts.
Gruss,
Thomas
Thomas Kaiser
> Thomas Kaiser schrieb:
>
> [Adobes und Microsofts Programme und deren "Ausbreitung" im Dateisystem]
>> Die halten sich doch sogar dran und kippen gemeinsam genutzte Libraries
>> und so Kram unterhalb »/Library/Application Support«, etc. ab.
>
> Ja OK, dort sollte man als unbedarfter doch bereits nicht mehr
> rumfummeln müssen...
Als "Unbedarfter" sollte man nirgends rumfummeln. Bzw. andersherum
sollte man immer nur an irgendwas schrauben, von dem man auch Ahnung
hat. Und es im Zweifelsfall einfach lassen.
Ich halte das hier mit meinen Installationen auf egal welcher Plattform
grundsätzlich so und scheine damit in relativ wenig Probleme zu rennen.
> Und das wird auch je nach Ausprobierwahn des Users immer mehr und bleibt
> dort liegen. Noch dazu sind solche unterstützenden Daten oft auch nicht
> einfach zu finden und mit dem zugehörigen (zu entfernenden) Programm in
> Verbindung zu bringen, weil sie etwa vom Programm völlig unabhängige
> Namen besitzen und ähnliches. Nicht sehr optimal meiner Meinung nach.
Völlig egal meiner Meinung nach. Laß die Dateien doch einfach da liegen
und basta. Was stören die Dich denn? Die nehmen vielleicht bisserl Platz
weg. Aber was soll's? MacOS X alleine spült einem schon so viel Kram auf
die Platte, daß ein paar hundert MByte oder vielleicht sogar ein paar
GByte mehr doch auch schon nichts mehr ausmachen).
Aber wegen so ein paar MByte potentieller Plattenplatzeinsparung laß ich
mir doch nicht von einem *nicht korrekt funktionieren könnenden*
"Uninstaller" irgendwelche Löschvorschläge unterbreiten und bin am
Ende immer selbst der Dumme (weil ich ja nicht gut genug über die
Löschvorschläge drüber geschaut hat), wenn anschl. einerseits mehr fehlt
als nötig und andererseits trotzdem noch irgendwelcher Kram, der im
Zusammenhang mit dem eigentlich restlos zu entfernenden Programm stand,
auf Platte verbleibt.
>> Nein, *alle* Softwarehersteller sollten IMO Apples PackageMaker nehmen,
>> falls sie etwas ausliefern, was man nicht in ein Bundle stecken kann,
>> damit diese Krankheit namens "Installer VISE" endlich verschwindet. Mit
>> Apples Installer-Mechanismus entsteht wenigstens ein bisschen
>> Transparenz in der Form, daß man auch als Enduser relativ problemlos
>> nachschauen kann, was eigentlich alles installiert wird (kann man
>> einblendden lassen vom Installer).
>
> Naja, ich weiß nicht...
> Gerade eben habe ich DxO OpticsPro aktualisiert. Der Installer sieht
> zumindest aus wie der von Apple und wieder einmal kommt keine Frage
> wohin ich das Ding gerne hätte, nein er installiert ungefragt in den
> Programmordner! Ich würde lieber _vorher_ gefragt werden, ob er nicht
> doch in den Unterordner "Grafikprogramme" istallieren soll, anstatt
> _nacher_ händisch zu verschieben ;-)
Also wenn eine Anwendung mit einem Installer daherkommt und nicht
einfach nur ein Disk-Image mit einem Application Bundle ausgeliefert
wird... dann ist das ein Warnhinweis. Nämlich, daß der Ersteller der
Software anschl. auch erwartet, daß seine Software genau dort liegt und
besser nicht verschoben wird.
Ganz im Ernst: Ich seziere berufsbedingt relativ häufig Installer und
Software und schlackere regelmäßig mit den Ohren, was für hartkodierter
Pfusch so alles auf die Menschheit losgelassen wird. Meist von
Programmierern, die sich das Lesen der entsprechenden Entwickler-Doku
von Apple gespart haben.
Da funktioniert dann plötzlich nichts mehr oder Software läuft gar Amok,
wenn man ein Programm aus /Applications heraus in einen Unterordner oder
sonstwohin verschiebt. Oder Updates funktionieren plötzlich nicht mehr,
etc.
Zusammenfassend: Application Bundles sind eine schicke Sache. Und es
gibt Software, die sich auch prima ausschließlich als solches ausliefern
läßt (was einen nicht davor schützt, daß diese Software aus ihrem Bundle
"ausbricht" und beim ersten Start noch hier&dort dies&das installiert).
Kommt Software als reines Application Bundle daher, muß also nicht
explizit installiert werden, so kann man davon ausgehen, daß man dieses
Bundle selbständig verschieben kann.
Wird ein Application Bundle allerdings innerhalb eines Installers
ausgeliefert, so würde ich nach all den Erfahrungen damit, tunlichst
davon absehen, daß Application Bundle zu verschieben. Einfach weil die
Programmierer damit dokumentiert haben, daß es einen guten Grund dafür
gibt, das per Installer auszuliefern *oder* sie einfach keine Ahnung von
ein paar Sachen am Mac haben und vielleicht die naive Vorstellung
pflegen, das müssen eben so sein.
Letzten Endes IMO bisserl egal, denn wo ein Programm liegt, ist doch
völlig egal, oder? Außer man hat's mit Aufräumen und braucht einfach
eine gewisse Ordnung. Jener Aufräumtrieb ist IMO für einen Großteil der
Probleme, die "Normaluser" so mit ihren Macs haben, verantwortlich (nur
so am Rande erwähnt)
>> Lies Dir Apples Vorgaben dazu einfach nochmal durch. Es gibt mehr als
>> Prefs, die irgendwo abgelegt werden müssen. Und es gibt Sachen, die
>> leider sonstwohin müssen (bspw. Filter/Backends/"Treiber" des Druck-
>> systems, oder Kernel Extensions oder StartupItems oder dies und das und
>> sonstnochwas -- es paßt eben nicht alles nur in ein Application Bundle)
>
> OK, das geht aber schon sehr ins Eingemachte. Dann halt eine Routine,
> welche beim löschen der Anwendug die verteilten Goodies wieder mitnimmt
> und dem User nur die Prefs zu löschen überläasst. Besser?
Ja. Das ist eben das fehlende Konzept, das ich bemängele. Apple kann
sicher nicht so weit gehen und so eine Art Paketmanager, wie ihn bspw.
die BSD-Varianten mit ihrem "Ports System" oder irgendwelche Linux-
Distributionen haben, vorgeben, weil sich die 3rd-Party-Hersteller nicht
drum scheren würden.
Aber sie hätten einen Mechanismus implementieren können, der die
Änderungen, die ein Installer vornimmt sowie Dateien, die er im Rahmen
der Installation überschreibt, an einen System-Dienst übergibt, der dann
sonstwas damit macht. Damit ginge wenigstens ein einfaches "Undo" nach
einer Installation.
Wenn man das Ganze natürlich bisserl detaillierter durchdenkt, wird
einem schnell klar, daß auch so ein Mechanismus schnell an seine Grenzen
stößt und daß es $irgendwas zu einem Paketmanager Ähnliches (inkl. all
der Komplexität, die damit einhergeht) bräuchte, um das Problem
zufriedenstellend zu lösen. Sowas richtig zu machen, ist vermutlich
enorm aufwändig (inkl. Durchsetzen des Ansatzes bei den ganzen 3rd-
Party-Herstellern) und andererseits ausgesprochen unattraktiv in Bezug
auf "Kommt jetzt neu mit MacOS X 10.x"...
Also läßt man das Ganze eben sein und die Anwender haben nun entweder
ein Problem (ganz generell wenn sie dem Aufräum-Aberglauben nachhängen
oder schlecht schlafen, "weil da ja noch irgendwo Prefs und sowas sind")
oder eben nicht, wenn nie was "tief ins System Eingreifendes" installiert
wurde und daher das Wegschmeißen des Programmordners bzw. Application
Bundles die simpelste und völlig ausreichende Variante ist, um sich von
einem nicht mehr benötigten Programm zu trennen.
Gruss,
Thomas
Wolfgang Kefurt
> Als "Unbedarfter" sollte man nirgends rumfummeln. Bzw. andersherum
> sollte man immer nur an irgendwas schrauben, von dem man auch Ahnung
> hat. Und es im Zweifelsfall einfach lassen.
Alles klar!
Solange es "Library/Application Support/Klartext" heißt, ist ja
wenigstens zu sehen was man löschen kann.
>> Und das wird auch je nach Ausprobierwahn des Users immer mehr und bleibt
>> dort liegen...
>
> Völlig egal meiner Meinung nach. Laß die Dateien doch einfach da liegen
> und basta. Was stören die Dich denn? Die nehmen vielleicht bisserl Platz
> weg. Aber was soll's? MacOS X alleine spült einem schon so viel Kram auf
> die Platte, daß ein paar hundert MByte oder vielleicht sogar ein paar
> GByte mehr doch auch schon nichts mehr ausmachen).
Es ist nicht die Datenmenge die mich stört, sondern der Umstand Dinge
behalten zu müssen, deren Zugehörigkeit längst obsolet ist. Nenn es
einen Ordnungswahn ;-)
> Aber wegen so ein paar MByte potentieller Plattenplatzeinsparung laß ich
> mir doch nicht von einem *nicht korrekt funktionieren könnenden*
> "Uninstaller" irgendwelche Löschvorschläge unterbreiten und bin am
> Ende immer selbst der Dumme (weil ich ja nicht gut genug über die
> Löschvorschläge drüber geschaut hat), wenn anschl. einerseits mehr fehlt
> als nötig und andererseits trotzdem noch irgendwelcher Kram, der im
> Zusammenhang mit dem eigentlich restlos zu entfernenden Programm stand,
> auf Platte verbleibt.
Hier gibt´s Zustimmung meinerseits!
> Also wenn eine Anwendung mit einem Installer daherkommt und nicht
> einfach nur ein Disk-Image mit einem Application Bundle ausgeliefert
> wird... dann ist das ein Warnhinweis. Nämlich, daß der Ersteller der
> Software anschl. auch erwartet, daß seine Software genau dort liegt und
> besser nicht verschoben wird.
Wenn ich das beherzigt hätte, würde mein Programmordner ein paar Minuten
zum öffnen brauchen und 4-5 Spalten breit sein. ;-)
Im Ernst:
Es kann doch nicht Bedingung zur Funktion sein, alles und jedes im
Programmodner zu deponieren. Da verliert man über die Zeit ja jegliche
Übersicht und muß sich bei jedem Programm, selbst wenn es nur einmal im
Jahr verwendet wird, durch eine endlose Liste quälen. Abgesehen davon
kann man sich ohne Unter-Kategorie doch kaum an die Namen von selten
gebrauchten Freewares, Tools etc. erinnern. Mir geht es jedenfalls so.
> Da funktioniert dann plötzlich nichts mehr oder Software läuft gar Amok,
> wenn man ein Programm aus /Applications heraus in einen Unterordner oder
> sonstwohin verschiebt. Oder Updates funktionieren plötzlich nicht mehr,
> etc.
Die Programme zu den Epson Druckern sind immer wieder Anwärter für
sowas. Auch mit Silverfast habe ich schon Wunder erlebt, war aber kurz
nach erscheinen der OS X Versionen und ist auch schon besser. Die Canon
Kamerasoftware wurde dagegen besser. Sie findet immerhin schon ihren
Vorgänger auf der Platte, trotz Unterverzeichnis.
> Letzten Endes IMO bisserl egal, denn wo ein Programm liegt, ist doch
> völlig egal, oder? Außer man hat's mit Aufräumen und braucht einfach
> eine gewisse Ordnung. Jener Aufräumtrieb ist IMO für einen Großteil der
> Probleme, die "Normaluser" so mit ihren Macs haben, verantwortlich (nur
> so am Rande erwähnt)
Na komm, wer will schon Kraut und Rüben in einem einzigen Programmordner?
Ich behaupte jetzt mal, jeder Mac-User fängt (sofern es der eigene
Rechner ist) irgendwann an mit Audio, Foto, DVD, HTML oder ähnlichem
Zeug herumzuspielen und lädt sich zum probieren erstmal verschiedene
Shareware, Freeware oder LE Versionen. Wenn dies alles aus den
verschiedensten Interessensgebieten in einem einzigen Ordner landet,
dann gute Nacht! Ohne Ordnung wird es da rasch chaotisch. Ich habe
lieber die Wahl als eine Zwangsbeglückung in "Programme".
>> Dann halt eine Routine,
>> welche beim löschen der Anwendug die verteilten Goodies wieder mitnimmt
>> und dem User nur die Prefs zu löschen überläasst. Besser?
>
> Ja. Das ist eben das fehlende Konzept, das ich bemängele. Apple kann
> sicher nicht so weit gehen und so eine Art Paketmanager, wie ihn bspw.
> die BSD-Varianten mit ihrem "Ports System" oder irgendwelche Linux-
> Distributionen haben, vorgeben, weil sich die 3rd-Party-Hersteller nicht
> drum scheren würden.
Schande über sie...
> Aber sie hätten einen Mechanismus implementieren können, der die
> Änderungen, die ein Installer vornimmt sowie Dateien, die er im Rahmen
> der Installation überschreibt, an einen System-Dienst übergibt, der dann
> sonstwas damit macht. Damit ginge wenigstens ein einfaches "Undo" nach
> einer Installation.
Was auch sinnvoll wäre um Probleme nach einem Wartungsupdate wieder los
zu werden. Schlage es ihnen doch mal vor :-)
--
Grüße
Wolfgang
Thomas Kaiser
> Thomas Kaiser schrieb:
>
>> Laß die Dateien doch einfach da liegen und basta. Was stören die Dich
>> denn? Die nehmen vielleicht bisserl Platz weg. Aber was soll's? MacOS
>> X alleine spült einem schon so viel Kram auf die Platte, daß ein paar
>> hundert MByte oder vielleicht sogar ein paar GByte mehr doch auch
>> schon nichts mehr ausmachen).
>
> Es ist nicht die Datenmenge die mich stört, sondern der Umstand Dinge
> behalten zu müssen, deren Zugehörigkeit längst obsolet ist. Nenn es
> einen Ordnungswahn ;-)
Schön formuliert. Besagter Wahn ist es, der Menschen unvernünftigerweise
nach Uninstaller lechzen läßt und sie ihr System partiell lädieren läßt,
weil sie das mit dem Aufräumen und Ordnung schaffen einfach nicht sein
lassen wollen...
>> Also wenn eine Anwendung mit einem Installer daherkommt und nicht
>> einfach nur ein Disk-Image mit einem Application Bundle ausgeliefert
>> wird... dann ist das ein Warnhinweis. Nämlich, daß der Ersteller der
>> Software anschl. auch erwartet, daß seine Software genau dort liegt
>> und besser nicht verschoben wird.
>
> Wenn ich das beherzigt hätte, würde mein Programmordner ein paar Minuten
> zum öffnen brauchen und 4-5 Spalten breit sein. ;-)
In meinem Programmordner liegen aktuell 230 Objekte. Geöffnet ist der in
Sekundenbruchteilen und die Navigation zu den Programmen, die mich
interessieren, läuft ähnlich schnell (wenn man schon mal [apfel][shift]
[a] gedrückt hat, braucht man ja nur noch die Anfangsbuchstaben
hinterherhämmern, bisserl auf die Pfeiltasten klopfen und ein [apfel][o]
hinterherschicken)
> Es kann doch nicht Bedingung zur Funktion sein, alles und jedes im
> Programmodner zu deponieren.
Heul doch ;-)
Ebenso im Ernst: Es ist erschreckend viel Software am Mac unterwegs, die
hartkodierte Pfade an irgendwelchen Stellen benutzt. D.h. wenn man das
Application Bundle dann verschiebt, mag auf den ersten Blick noch alles
passen... aber irgendwo im Hintergrund fällt dann was auf die Nase oder
läuft sogar Amok. Nicht schön übrigens bei sowas zuzusehen (obwohl ich
es nach wie vor jedem ans Herz legen kann, ab und zu gezielt genauer per
fseventer oder Sonar/sandal nachzugucken, was grad auf der Festplatte
abgeht)
> Da verliert man über die Zeit ja jegliche Übersicht und muß sich bei
> jedem Programm, selbst wenn es nur einmal im Jahr verwendet wird,
> durch eine endlose Liste quälen. Abgesehen davon kann man sich ohne
> Unter-Kategorie doch kaum an die Namen von selten gebrauchten
> Freewares, Tools etc. erinnern. Mir geht es jedenfalls so.
Da sind die Menschen offenbar verschieden veranlagt, mag sein. Ich
brauch sowas eher nicht und halte auch das Konzept hierarchischer Ordner
für reichlich anachronistischen Mist. Ich will eigentlich Chaos wie auf
echten Schreibtischen und das in 3D mit allen Nebenwirkungen ("Piles on
steroids" oder so).
>> Da funktioniert dann plötzlich nichts mehr oder Software läuft gar
>> Amok, wenn man ein Programm aus /Applications heraus in einen
>> Unterordner oder sonstwohin verschiebt. Oder Updates funktionieren
>> plötzlich nicht mehr, etc.
>
> Die Programme zu den Epson Druckern sind immer wieder Anwärter für
> sowas. Auch mit Silverfast habe ich schon Wunder erlebt, war aber kurz
> nach erscheinen der OS X Versionen und ist auch schon besser.
Alte Mac-Programme der Prä MacOS X Ära kennen diese Problem naturgemäß
so gut wie gar nicht. Die sind für einen Personenkreis geschrieben
worden, der alles munter dorthin verschoben hat, wo es ihm gepaßt hat,
sein Startvolume dreimal am Tag umbenannt hat, dito im Finder die
Dokumente, an denen er gerade parallel in der Textverarbeitung
gebastelt hat. Und das hat auch alles funktioniert, weil Apple paar
Mechanismen im Hintergrund laufen ließ und die "APIs" entsprechend
ausgelegt waren, daß es nicht krachte.
Das Problem entstand dann eigentlich erst mit MacOS X und Programmierern,
die diese Konzepte weder kannten noch sich (Unix-/Linux- oder Windows-
vorbelastet) vorstellen konnten, daß sowas funktionieren kann. Also daß
bspw. ein Programm irgendwo auf der Platte liegen kann und trotzdem
Dokument-zu-Programm-Verknüpfungen funktionieren (früher Schreibtisch-
datei, heute LaunchServices). Oder daß sogar geöffnete Dateien umbenannt
oder verschoben werden dürfen, ohne daß das Ganze Probleme bereitet (den
sog. Catalog Node IDs sei Dank), Usw., usf.
Ist aber einfach Fakt. Und es ist erschreckend, in wie viel Software
sich völlig unnötige "Dummheiten" finden, die dann zu mehr oder weniger
großen Dramen führen, wenn mal Anwendungen verschoben (oder aufgeräumt)
werden. Manche Sachen auch nur schleichend und so, daß man den Schaden
erst bemerkt, wenn man das nächste Update einspielen möchte...
>> Letzten Endes IMO bisserl egal, denn wo ein Programm liegt, ist doch
>> völlig egal, oder? Außer man hat's mit Aufräumen und braucht einfach
>> eine gewisse Ordnung. Jener Aufräumtrieb ist IMO für einen Großteil
>> der Probleme, die "Normaluser" so mit ihren Macs haben,
>> verantwortlich (nur so am Rande erwähnt)
>
> Na komm, wer will schon Kraut und Rüben in einem einzigen
> Programmordner?
Ich. Mir ist das nämlich völlig egal, wo was liegt, weil ich
* schon immer dokument- und nicht programmzentriert gewerkelt habe, d.h.
ich die Frage, wo das Programm denn nun genau liegt, nicht so viel
abgewinnen kann, wie der Frage, ob LaunchServices/Schreibtischdatei
das richtige Programm für das Dokument, das ich gerade öffnen will,
finden
* Helfern wie LaunchBar, QuickSilver, etc. einen gewissen Charme
zusprechen kann
* Software, die ich nur selten nutze, eh gleich wieder wegschmeiße, weil
Programme meistens dann doch nie so intuitiv sind, daß mich die
erneute Einarbeitung in Konzepte/Bedienung nicht narrisch machen würde
* ganz grundsätzlich hierarchische Ordnerstrukturen für eine schrecklich
anachronistische Selbstbeschränkung halte (an der man aktuell aber
leider immer noch nicht vorbeikommt)
* Reiche auf Metadaten basierende Ansätze wie sie bspw. in Spotlight
vorkommen, was abgewinnen kann
> Ich behaupte jetzt mal, jeder Mac-User fängt (sofern es der eigene
> Rechner ist) irgendwann an mit Audio, Foto, DVD, HTML oder ähnlichem
> Zeug herumzuspielen und lädt sich zum probieren erstmal verschiedene
> Shareware, Freeware oder LE Versionen. Wenn dies alles aus den
> verschiedensten Interessensgebieten in einem einzigen Ordner landet,
> dann gute Nacht! Ohne Ordnung wird es da rasch chaotisch. Ich habe
> lieber die Wahl als eine Zwangsbeglückung in "Programme".
Tja, dann lebe Deinen Ordnungswahn aus und verschiebe Dinge, die nicht
verschoben gehören und wische nach Entsorgung von Programmbrocken noch
feucht mittels Uninstaller nach. Ein mit der Zeit immer instabileres
System ist der gerechte Lohn :-)
>> Aber sie hätten einen Mechanismus implementieren können, der die
>> Änderungen, die ein Installer vornimmt sowie Dateien, die er im
>> Rahmen der Installation überschreibt, an einen System-Dienst
>> übergibt, der dann sonstwas damit macht. Damit ginge wenigstens ein
>> einfaches "Undo" nach einer Installation.
>
> Was auch sinnvoll wäre um Probleme nach einem Wartungsupdate wieder
> los zu werden.
Hach ja, der andere Punkt, der einen zum Apple-Hasser machen könnte. Die
schreckliche Vermischung von Sicherheits- mit Funktions-Updates :-(
> Schlage es ihnen doch mal vor :-)
Ich rede eher mit Parkuhren und Straßenlaternen als daß ich meine Zeit
damit verschwende, bei Apple etwas vorzuschlagen. Ohne Vitamin B ist das
alles reichlich sinnlose Zeitverschwendung bei einer Klitsche, die aus
Prinzip noch nicht mal auf die Meldung gravierender sicherheitsrelevanter
Bugs reagiert.
Gruss,
Thomas
Thomas Adams
> > Seit dem Einbau exakt dieser Karte in meinen Quicksilver geht der
> > Ruhezustand nicht mehr.
>
> PRAM-Reset nach dem Einbau gemacht?
Ja, hatte ich. Selbst wenn nichts angeschlossen ist, funktioniert der
Ruhezustand nicht. Wird wohl Zeit für eine Neuinstallation nebst Beten
und Hoffen.
Patrick M. Hausen
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ebenso im Ernst: Es ist erschreckend viel Software am Mac unterwegs, die
> hartkodierte Pfade an irgendwelchen Stellen benutzt. D.h. wenn man das
> Application Bundle dann verschiebt, mag auf den ersten Blick noch alles
> passen... aber irgendwo im Hintergrund fällt dann was auf die Nase oder
> läuft sogar Amok. Nicht schön übrigens bei sowas zuzusehen (obwohl ich
> es nach wie vor jedem ans Herz legen kann, ab und zu gezielt genauer per
> fseventer oder Sonar/sandal nachzugucken, was grad auf der Festplatte
> abgeht)
Und es war ein absolut genialer Zug von Apple, die Ordner in jeder
Sprache gleich zu benennen und nur durch den Finder unterschiedlich
anzeigen zu lassen. Muß man auch mal sagen, finde ich.
Jeder, der den Terz unter Windows mit /Programme, /Program Files,
etc. pp. kennt, weiß, was ich meine.
> Da sind die Menschen offenbar verschieden veranlagt, mag sein. Ich
> brauch sowas eher nicht und halte auch das Konzept hierarchischer Ordner
> für reichlich anachronistischen Mist.
Siehst Du - und ich sortiere alles in Hierarchien und mag keine
Blätter und Knoten auf derselben Ebene - in einem Ordner sind entweder
nur Unter-Ordner oder nur Dateien. Zumindest unterhalb von ~/Documents.
Auf die Idee, den /Applications Ordner zu "ordnen" bin ich allerdings
auch noch nie gekommen. Alles, was ich brauche, ziehe ich ins Dock.
Selten gebrauchte Dinge kommen als Aliase in einen Ordner in der rechten
Hälfte vom Dock und aus.
> Alte Mac-Programme der Prä MacOS X Ära kennen diese Problem naturgemäß
> so gut wie gar nicht. Die sind für einen Personenkreis geschrieben
> worden, der alles munter dorthin verschoben hat, wo es ihm gepaßt hat,
> sein Startvolume dreimal am Tag umbenannt hat, dito im Finder die
> Dokumente, an denen er gerade parallel in der Textverarbeitung
> gebastelt hat. Und das hat auch alles funktioniert, weil Apple paar
> Mechanismen im Hintergrund laufen ließ und die "APIs" entsprechend
> ausgelegt waren, daß es nicht krachte.
Und, wenn man es nüchtern betrachtet, "gehört das auch so". Der
Rechner gehört dem Anwender und nicht irgendeinem System. Warum
sollte sich das Teil weigern, zu funktionieren, weil man die
"Macintosh HD" in "Hustinettenbär" umbenennt? Dito File-Extensions.
Was für ein Müll. Der Name einer Datei gehört einzig dem Benutzer.
Ging alles schon mal ...
> * schon immer dokument- und nicht programmzentriert gewerkelt habe, d.h.
> ich die Frage, wo das Programm denn nun genau liegt, nicht so viel
> abgewinnen kann, wie der Frage, ob LaunchServices/Schreibtischdatei
> das richtige Programm für das Dokument, das ich gerade öffnen will,
> finden
ACK.
> * Software, die ich nur selten nutze, eh gleich wieder wegschmeiße, weil
> Programme meistens dann doch nie so intuitiv sind, daß mich die
> erneute Einarbeitung in Konzepte/Bedienung nicht narrisch machen würde
2x ACK.
Gruß,
Patrick
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
in...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
Daniel Küstner
> Oder daß sogar geöffnete Dateien umbenannt
> oder verschoben werden dürfen, ohne daß das Ganze Probleme bereitet (den
> sog. Catalog Node IDs sei Dank), Usw., usf.
Daß das mal ging, habe ich auch gehört. Geht das aber unter Mac OS X
überhaupt noch irgendwo? TextEdit zum Beispiel, mit dem ich das gerade
getestet habe, kommt mit dem Verschieben nicht klar.
daniel.
--
Daniel Küstner
pgp public key on request
Nimm eine fremde Hand und geh ins Unbekannte.
Noses
> Jeder, der den Terz unter Windows mit /Programme, /Program Files,
> etc. pp. kennt, weiß, was ich meine.
Irgendwie finde ich das bei Vista um einiges besser gelöst.
Noses.
Olaf Joensson
> Der Name einer Datei gehört einzig dem Benutzer.
Ein Bekannter erzählte mir kürzlich, dass einer seiner Kunden ihn
gerufen hat, weil auf seinem neuen MacBook "alle Dateien weg" waren.
Er hatte seinen Benutzer-Ordner in "Eigene Dateien" umbenannt...
Gruß Olaf
Thomas Kaiser
> Thomas Kaiser wrote:
>> Oder daß sogar geöffnete Dateien umbenannt oder verschoben werden
>> dürfen, ohne daß das Ganze Probleme bereitet (den sog. Catalog Node
>> IDs sei Dank), Usw., usf.
>
> Daß das mal ging, habe ich auch gehört. Geht das aber unter Mac OS X
> überhaupt noch irgendwo?
Mit ein paar Programmen schon. Aber da das Gros nicht mehr damit zurecht
kommt, sollte man sich die Idee von vorneherein abschminken.
> TextEdit zum Beispiel, mit dem ich das gerade getestet habe, kommt mit
> dem Verschieben nicht klar.
Ich hab mich irgendwann mal vor meiner dcsm-Zeit dazu umfangreicher
ausgelassen und auch einige Tests gemacht. Muß also schon 2001 oder
früher gewesen sein. Und da ging schon so einiges nicht mehr mit
durchaus gebräuchlichen Programmen.
Derweil wäre es grundsätzlich kein Problem, wenn die Programme brav über
die CNID (Catalog Node ID) referenzieren würden. Das wiederum geht aber
nicht mit allen Dateisystemen problemlos: CNIDs sind nur immanentes
Feature von HFS(+) und AFPFS -- also wenn ein Volume per (Personal)
FileSharing genutzt wird, wobei es keine Rolle spielt, welches
Filesystem der Server nutzt, da der Server dann eben die CNIDs in einer
Datenbank oder sonstwie sauber verwalten muß, wenn er nicht auf HFS(+)
und dessen interne CNIDs zurückgreift.
D.h. man hat seit MacOS X (und der angeblichen Gleichwertigkeit weiterer
Dateisysteme wie lokal UFS oder im Netzwerk NFS, SMB/CIFS oder auch AFP-
Implementationen mit halbgarer CNID-Verwaltung -- bspw. AppleFileServer
auf UFS oder ältere Netatalk- oder Xinet-Versionen) mit genau dem
Feature eh immer wieder Probleme, weil plötzlich neben HFS+ und AFPFS
andere Dateisystemtypen aufgetaucht sind, die mit ID-Inkonsistenz
"glänzen", weshalb manche Programmhersteller gleich von sich aus dazu
übergegangen sind, intern einen Riegel vorzuschieben und sich komplett
querzustellen, wenn die geöffnete Datei nicht mehr denselben Pfad hat.
Irgendwie ist doch in den ersten MacOS X Versionen (bzw. bei der
strategischen Planung, wohin die Reise gehen soll) 'ne Menge schief
gelaufen. Aufweichung älterer Konzepte, Übernahme der maximal dämlichen
(Dateinamen-Suffixe), Propagierung von angeblicher Gleichheit durchaus
unterschiedlicher Dateisysteme mit der Folge, daß ein Problem, das wenn
dann irgendwo auf dem VFS-Layer seitens Apple abgefackelt werden müsste,
auf einmal an die Anwendungsentwickler durchgereicht wurde, etc.
Wo das einstmals sinnige Konzept der CNIDs zu Zeiten von MacOS X und der
zwischenzeitlichen Adaption von allerhand anderem Kram hingekommen ist,
kann man leicht selbst ausprobieren, wenn man mal aus einer beliebigen
nativen (also nicht Classic) Anwendung heraus eine Datei als bspw.
test#13.txt
*auf einem AFP 3.x-Server* absichern will. Geht nämlich nicht und die
Fehlermeldung fällt meist "lustig" aus, weil auf ein völlig anderes
Objekt (das mit der CNID 19 auf dem Server-Volume) hingewiesen wird.
Warum? AFP ab 3.x kennt neben langen Namen (in den AFP-Specs als
"AFPName" auftauchend), die wie auf HFS+ auch 255 Byte lang sein können
und in UTF-8 daherkommen (führt dann zu maximaler Stringlänge von 85-255
Zeichen abhängig von den verwendeten Glyphen) auch kurze (in den Specs
als "long name" auftauchend -- logisch nicht? ;-)
Und weil ältere AFP-Clients (also MacOS < 10) noch nicht mit den langen
Dateinamen in UTF-8 umgehen konnten, müssen AFP-Server ein Mangling
zwischen diesen langen Dateinamen und den kürzeren Varianten anbieten.
Apple löst das so, daß falls ein Dateiname auf dem Server länger als 31
Byte im Encoding des Clients (bei uns MacRoman) wäre, die ersten Zeichen
des Datei-/Ordnernamens in den "gemangelten" Namen gepackt werden,
gefolgt von einem "#" und der hexadezimal kodierten CNID des Objekts,
gefolgt von einem evtl. anhängenden Dateinamen-Suffix.
Eine Datei mit der CNID 255 und dem Namen
Ein wirklich saulanger Dateiname, den keiner braucht.jpg
würde also einem AFP 2.x Client gegenüber als
Ein wirklich saulanger D#FF.jpg
dargestellt. Hätte die Datei dagegen die Catalog Node ID 256, würde es
Ein wirklich saulanger #100.jpg
lauten. Und hätte die Datei auf dem Server kein Suffix ".jpg", dann
würden jeweils 4 Zeichen mehr vom Namen nach dem Mangling bzw. vor dem
"#" übrigbleiben.
Wer bis hierher noch dabei ist und sich jetzt fragt, was das Ganze mit
MacOS X _als AFP-Client_ zu tun haben soll... tja...
Dummerweise hat Apple eine ähnliche Logik auch auf dem VFS-Layer in den
AFP-Client eingebaut, d.h. ein Feature, das eigentlich für die Abwärts-
kompatibilität zu MacOS 9 *auf Serverseite* eingebaut wurde, findet sich
umgedreht auch im MacOS X Client (bis hoch zu 10.5). Datei-/Ordnernamen,
deren Name ein "#" gefolgt von einer Zeichenfolge, die hexadezimal
kodiert der CNID irgendeines Objektes auf dem Zielvolume entspricht
*und* ein den lokalen LaunchServices bekanntes Suffix angehängt hat...
sind in MacOS X illegal. Ändert man das Suffix auf irgendwas Sinnfreies
oder wählt zufällig nach dem "#" eine andere Zeichenfolge, zu der es
keine CNID auf dem Zielvolume existiert, dann klappt alles...
Wer zwei MacOS X Kisten hat --> einfach mal ausprobieren und anschl.
überlegen, ob Lachen oder Weinen angebracht ist.
Und wer sich jetzt denkt: WTF?! Ja, eben. Das denken sich auch
Anwendungsprogrammierer, die irgendwann über so Mist stolpern und sich
bei dieser denkbar dämlichen Verknüpfuung der Nachteile zweier Systeme
(CNIDs von HFS und Dateinamen-Suffixe von DOS/Windows) einerseits
fragen, was die in Cupertino wohl so rauchen und andererseits einfach im
Zweifelsfall mal wieder drauf pfeifen, was Apple so vorgibt bzw. recht
leidenschaftslos auf Probleme im Zusammenhang mit dieser Thematik
reagieren, weil "eh schon wurscht"-Einstellung adaptiert (in den Carbon-
APIs lungern noch ein paar so Stellen herum, wo ein langer Name
hineingesteckt wird aber ein verkürzter auf der anderen Seite wieder
rausguckt, was dann hier und dort für hübsch Ärger sorgt -- siehe bspw.:
<http://www.helios.de/support/ti.phtml?096>)
Gruss,
Thomas, mal die Allgemeinheit an "typischen Supportfällen" teilhaben
lassend, mit denen man so täglich zu tun hat. Wobei das ja alles eh
harmlos ist...
Goetz Hoffart
> mit genau dem Feature eh immer wieder Probleme, weil plötzlich neben HFS+
> und AFPFS andere Dateisystemtypen aufgetaucht sind, die mit
> ID-Inkonsistenz "glänzen", weshalb manche Programmhersteller gleich von
> sich aus dazu übergegangen sind, intern einen Riegel vorzuschieben und
> sich komplett querzustellen, wenn die geöffnete Datei nicht mehr denselben
> Pfad hat.
Und wie macht das DAVE unter System 7, Mac OS 8 und 9?
Thomas Kaiser
Naja, sich selbständig um die Verwaltung/Konsistenz der CNIDs kümmern.
Wie weiß ich mangels Interesse an SMB-/CIFS-basierten Ansätzen nicht.
Es gibt grundsätzlich verschiedene Ansätze:
* rein temporäre Verwaltung der CNIDs nur innerhalb einer "Session"
(sprich die nur während einer Anmeldung am Server gültig sind und
anschl. invalid). Beispiel: Netatalk in älteren Versionen mit "last"
CNID-Backend (IDs wurden je AFP-Client und -Session einfach stur
hochgezählt und fingen bei der nächsten Session wieder "bei null" an)
* Ausleihen anderer Dateisystem-Eigenschaften für CNIDs (serverseitig
bspw. die Inodes des Server-Dateisystems: Beispiele mal wieder
Netatalk mit dem alten "hash" oder "mtab"-CNID-Backend bzw. aktuelles
Netatalk mit "last"-Backend. Oder AFAIK immer noch Xinet mit ihrem
K-AShare. So ein Ansatz ist allerdings gefährlich, da CNIDs je Volume
so lange wie möglich eindeutig sein sollen... und Inodes meist sofort
wiederverwendet werden, wenn sie frei werden (bspw. weil andere
Dateien oder Ordner gelöscht werden). Direkte Folge: Fehlverhalten von
Anwendungen aufgrund CNID-Caching oder sogar Datenverlust (beliebt im
Zusammenhang mit dem "Network Trash Folder" -- die CNID xy entsprach
halt leider gar nicht mehr dem eigentlich zu löschenden Ordner sondern
einem völlig anderen)
* Datenbank-basierte oder -ähnliche Ansätze, d.h. Speichern der CNIDs in
einer echten Datenbank und/oder Datei-/Ordner-bezogen irgendwie in den
Metadaten der Dateien/Ordner (abermals Netatalk mit cdb/dbd-CNID-Backend
als Beispiel oder Helios seit 'zig Jahren). Sowohl Helios als auch bspw.
Netatalk fahren zweigleisig (d.h. sowohl eigene "echte" Datenbank als
auch Datei-/Ordner-bezogene Speicherung der CNIDs in internen
Metadaten)
Dave könnte von obigen Ansätzen den ersten und den dritten nutzen und
bei letzterem ggf. sogar in Abhängigkeit vom serverseitigen Dateisystem
differenzieren (bspw. bei NTFS auf dem Server die CNIDs einfach in
Filestreams speichern und bei Vorliegen von FAT32 irgendwie anders --
bspw. je Ordner eine Datei mit derlei Metadaten. Der AppleFileServer
bspw. fährt auch mehrgleisig in Abhängigkeit davon, ob er Dateien auf
HFS(+) freigeben muß oder auf flachen Dateisystemen, also UFS, XSan,
ZFS, etc.)
Oder Dave fährt tatsächlich nur den rein temporären Ansatz -- das merkt
man auch nur wirklich, wenn man Anwendungen nutzt, die CNIDs intern
benutzen -- Quark Xpress bspw., das Bild-Referenzierung früher mal
ausschlielich anhand CNIDs vornahm. D.h. bei dem rein temporären Ansatz
stünden plötzlich alle im Layout platzierten Bilder auf fehlend, wenn
man zwischendurch die Server-Verbindung trennte...
Gruss,
Thomas
Daniel Küstner
[Viel Erhellendes ...]
Oha.
Danke. daniel.
ra...@rsrc.de
> Datei-/Ordnernamen,
> deren Name ein "#" gefolgt von einer Zeichenfolge, die hexadezimal
> kodiert der CNID irgendeines Objektes auf dem Zielvolume entspricht
> *und* ein den lokalen LaunchServices bekanntes Suffix angehängt hat...
> sind in MacOS X illegal.
AFAIK nicht illegal, sondern krankes Sahnehäuchen auf illegal dämlichen
Mechanismus. Wäre die CNID aufm Server nicht schon besetzt wär der Name
ja in Ordnung.
-Ralph
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Datei-/Ordnernamen, deren Name ein "#" gefolgt von einer
>> Zeichenfolge, die hexadezimal kodiert der CNID irgendeines Objektes
>> auf dem Zielvolume entspricht *und* ein den lokalen LaunchServices
>> bekanntes Suffix angehängt hat... sind in MacOS X illegal.
>
> AFAIK nicht illegal
Den jeweiligen Dateinamen meinte ich -- der ist dann in dem Moment
seitens MacOS X' AFP-Client tatsächlich illegal geworden ;-)
> sondern krankes Sahnehäuchen auf illegal dämlichen Mechanismus. Wäre
> die CNID aufm Server nicht schon besetzt wär der Name ja in Ordnung.
Schon. Wobei ich das ja noch in Ordnung finde bzw. einen Algorithmus,
der auf sowas aufpaßt, noch irgendwie durchgehen lassen würde. Wieso in
das Ganze aber noch das Suffix hineinspielt und ein illegales bzw. den
LaunchServices unbekanntes auf einmal dazu führt, daß der Name doch
akzeptiert wird, ist mir ein Rätsel...
Naja, wie auch immer. Man darf davon ausgehen, daß Apple das in den AFP-
Client von MacOS X eingebaut hat, um irgendwann mal irgendeinen Fehler
im AppleFileServer dadurch auszubügeln. Machen sie ja öfter ganz gerne.
Gruss,
Thomas
Robert Schaffner
> Ja, hatte ich. Selbst wenn nichts angeschlossen ist, funktioniert der
> Ruhezustand nicht. Wird wohl Zeit für eine Neuinstallation nebst Beten
Naja, das ist dann schon ein wenig seltsam. Die Karte beherrscht das
ganz sicher. Ob da eine Neuinstallation etwas bringt kann ich dir leider
nicht sagen.
Clemens Beier
> Auf die Idee, den /Applications Ordner zu "ordnen" bin ich allerdings
> auch noch nie gekommen.
Auf diese Idee kommst du aber auch nur dann wenn du (meist)
Windows-Nutzer vor der Kiste sitzen hast die noch nicht einmal die
Schaltflächen von DragThing ansehen oder nutzen.
Dann eben Ordner für 'Office', 'Grafik', 'Audio' etc. pp.
<seufz />
ClemiSan
Noses
>> Und wie macht das DAVE unter System 7, Mac OS 8 und 9?
> Naja, sich selbständig um die Verwaltung/Konsistenz der CNIDs kümmern.
Äh - hä? Seit wann wird bei SMB von Kunden oder Kellnern irgendwas mit CNIDs
gemacht?
Noses.
Wolfgang Kefurt
>> Auf die Idee, den /Applications Ordner zu "ordnen" bin ich allerdings
>> auch noch nie gekommen.
>
> Auf diese Idee kommst du aber auch nur dann wenn du (meist)
> Windows-Nutzer vor der Kiste sitzen hast die noch nicht einmal die
> Schaltflächen von DragThing ansehen oder nutzen.
>
> Dann eben Ordner für 'Office', 'Grafik', 'Audio' etc. pp.
>
> <seufz />
Nein!
Auf die Idee kommst du auch, wenn du ein Alias des Programmordners im
Dock hast und nicht über DragThing od.ähnl. verfügst. Ich gebe zu das
ist Geschmackssache, aber es war damals die erste Art das Applemenü zu
ersetzen und ich habe es beibehalten...
<augenroll />
;-)
--
Grüße
Wolfgang
Thomas Kaiser
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> [Götz Hoffart wrote:]
>>> Und wie macht das DAVE unter System 7, Mac OS 8 und 9?
>> Naja, sich selbständig um die Verwaltung/Konsistenz der CNIDs kümmern.
>
> Äh - hä? Seit wann wird bei SMB von Kunden oder Kellnern irgendwas mit
> CNIDs gemacht?
Naja, eigentlich schon immer, vermute ich mal.
Ich hab mich mit Dave nie so groß beschäftigt, nur mal die eine
spannende Frage an einen Anwender gestellt: Kannst Du aus Xpress heraus
ein Dokument speichern. Hatter bejaht, damit ist klar, daß Dave sich
selbständig um CNIDs bzw. deren Emulation gekümmert haben muß (und das
auch noch relativ korrekt, denn Xpress ist in der Hinsicht bekanntermaßen
zickig, sprich ein 1a Indikator für korrekte CNID-Verwaltung).
Ich meine, wenn Dave das nicht erledigt hätte, dann hätten alle
Programme, die den PBExchangeFiles-Call beim Speichern verwenden, böse
auf die Fresse fallen müssen:
<http://developer.apple.com/documentation/mac/Files/Files-254.html>
Sind sie meines Wissens aber nicht. Weshalb ich ganz naiv annehme, daß
sich Dave da drum gekümmert haben wird. So wie es ja jetzt die diversen
VFS-Module auch versuchen...
Gruss,
Thomas
Noses
>> CNIDs gemacht?
> Naja, eigentlich schon immer, vermute ich mal.
Oder eher noch nie unter Mac OS X. CNIDs werden ausschließlich von HFS(+)
und AFP unterstützt. Bei allen anderen Dateisystemen würde ich mal annehmen,
daß das irgendwer oberhalb des kernels (vold wäre der zuständige
Sachbearbeiter) das isrgendwo geeignet aufbereitet (schlußendlich holen sich
ja urzeitliche Applikationen ihr Mapping von irgendwelchen (was, auch,
immer)-Tripeln zu Dateien unter /.vol ab und der vold bildet das dann auf
beliebige existierende Dateisysteme ab).
> Xpress
[...]
> zickig, sprich ein 1a Indikator für korrekte CNID-Verwaltung).
Naja - das Schwein kann Trüffeln fressen. Ob es auch sagen kann, wo genau
sie vergraben liegen, kann ich nicht bewerten. Ich glaube es aber eher
nicht.
> Ich meine, wenn Dave das nicht erledigt hätte, dann hätten alle
> Programme, die den PBExchangeFiles-Call beim Speichern verwenden, böse
> auf die Fresse fallen müssen:
> <http://developer.apple.com/documentation/mac/Files/Files-254.html>
Wieso? Passiert das denn mit smbfs, webfs oder msdos?
> Sind sie meines Wissens aber nicht. Weshalb ich ganz naiv annehme, daß
> sich Dave da drum gekümmert haben wird. So wie es ja jetzt die diversen
> VFS-Module auch versuchen...
Ich habe eher nicht das Gefühl, daß das der Fall ist. Ich hole mir mal heute
abend den Singh aus dem Regal...
Noses.
Thomas Kaiser
>>> Äh - hä? Seit wann wird bei SMB von Kunden oder Kellnern irgendwas
>>> mit CNIDs gemacht?
>
>> Naja, eigentlich schon immer, vermute ich mal.
>
> Oder eher noch nie unter Mac OS X. CNIDs werden ausschließlich von
> HFS(+) und AFP unterstützt. Bei allen anderen Dateisystemen würde ich
> mal annehmen, daß das irgendwer oberhalb des kernels (vold wäre der
> zuständige Sachbearbeiter) das isrgendwo geeignet aufbereitet
Klar, das meinte ich ja. Irgendwo müssen ja die CNID-Semantiken
herkommen, auch wenn es keine echten CNIDs im Dateisystem gibt.
>> Ich meine, wenn Dave das nicht erledigt hätte, dann hätten alle
>> Programme, die den PBExchangeFiles-Call beim Speichern verwenden,
>> böse auf die Fresse fallen müssen:
>
>> <http://developer.apple.com/documentation/mac/Files/Files-254.html>
>
> Wieso? Passiert das denn mit smbfs, webfs oder msdos?
Warum nicht? Wenn die Anwendung, die den Call absetzt, gar nichts davon
mitbekommt, was Ihr da untergeschoben wurde?
>> Sind sie meines Wissens aber nicht. Weshalb ich ganz naiv annehme,
>> daß sich Dave da drum gekümmert haben wird. So wie es ja jetzt die
>> diversen VFS-Module auch versuchen...
>
> Ich habe eher nicht das Gefühl, daß das der Fall ist. Ich hole mir mal
> heute abend den Singh aus dem Regal...
Der ist mir heute zu schwer, v.a. auf vollen Magen :-)
Reicht denn nicht:
<http://developer.apple.com/qa/qa2001/qa1113.html> (Argl, auf Stand
von 10.1 -- OK, lachhaft)
<http://developer.apple.com/qa/qa2001/qa1242.html> und
<http://developer.apple.com/samplecode/MFSLives/index.html>
Gruss,
Thomas
Clemens Beier
> Clemens Beier schrieb:
>
> >> Auf die Idee, den /Applications Ordner zu "ordnen" bin ich allerdings
> >> auch noch nie gekommen.
> >
> > Auf diese Idee kommst du aber auch nur dann wenn du (meist)
> > Windows-Nutzer vor der Kiste sitzen hast die noch nicht einmal die
> > Schaltflächen von DragThing ansehen oder nutzen.
> >
> > Dann eben Ordner für 'Office', 'Grafik', 'Audio' etc. pp.
> >
> > <seufz />
>
> Nein!
> Auf die Idee kommst du auch, wenn du ein Alias des Programmordners im
> Dock hast und nicht über DragThing od.ähnl. verfügst.
Naja. Wenn die Leute so etwas wenigsten nutzen würden. Aber es ist
einfach in den Köpfen einzementiert: auf die Festplatte gehen, Programm
öffnen, dann im "tollen" Öffnen-Dialog des Programms die Datei
heraussuchen (was ja auch immer wieder eine tolle "Hangelei" ist).
> Ich gebe zu das
> ist Geschmackssache, aber es war damals die erste Art das Applemenü zu
> ersetzen und ich habe es beibehalten...
Es ist eine Sache etwas direkt zu ersetzen um Gewohnheiten
weiterzuführen; was ich fein fand war neue Gewohnheiten zu entdecken.
In diesem Fall: 'LaunchBar' (jetzt 'Quicksilver').
Ich habe zwar mein altes DragThing wieder einmal aktiviert, nutze es
aber kaum.
> <augenroll />
Wozu? YMMV.
> ;-)
Jau!
ClemiSan
Wolfgang Kefurt
>> <augenroll />
>
> Wozu? YMMV.
>
War nicht böse oder genervt gemeint.
Wollte damit nur sagen, daß eben jeder seine Gewohnheiten hat und diese
nicht unbedingt konform mit anderen sind :-)
--
Grüße
Wolfgang
Clemens Beier
> Clemens Beier schrieb:
>
>
> >> <augenroll />
> >
> > Wozu? YMMV.
> >
>
> War nicht böse oder genervt gemeint.
Ist auch nicht so angekommen.
> Wollte damit nur sagen, daß eben jeder seine Gewohnheiten hat und diese
> nicht unbedingt konform mit anderen sind :-)
Kein Grund zum Augenrollen. ;-)
ClemiSan