Die größten Probleme in Mac OS X Panther

Moin,

Zu Koffern:
._ut schrieb:
Man kommt doch ganz prima dran im Finder;)
Auf einer anderen Plattform kannst Du mit dem Inghalt eh nichts anfangen.
Screenfonts umsortieren? Die Zeiten sind wohl vorbei. Denn
1. OTF statt PostScript.
2. Wenn Postscript, dann ein Screen-Font pro "Koffer".
TrueType ist eh unprofessionell (und braucht eh keine Screenfonts).

1. Wieso kann ich auf anderen Plattformen nichts mit dem Inhalt von Koffern anfangen? Beispielsweise Screenfonts enthalten die Metriken, und an die möchte ich sehr gern ran!

2. "OTF statt Postscript"... aha. Wir haben auf unserem Fontserver über 11 Jahre hinweg PostScriptfonts angesammelt (gekauft!) im Gegenwert eines kleinen Hauses. Du hast sicher gute Tips, mit welchem Finger ich schnipsen muß, damit die
a) über von selbst über Nacht von PS nach OTF konvertieren und
b) wie ich dann die archivierten, unter OS 9 erstellten Dokumente alter Jobs für Nachproduktionen dazu bringe, mit Freehand 8 oder Quark 4 auf OTF-Fonts zuzugreifen.

3. Warum TrueType "unprofessionell" ist, wüsste ich gerne. Daß die Implementation in einigen Rips für OS-9.PostScript besch...eiden ist, ist wohl kaum die Schuld der Fonts. Jednefalls ist die Qualität von OTF mit TTF identisch, der Mehrwert des OTF-Formates besteht nicht in besserer Qualität der Glyphen.

._ut schrieb:
*Ordner* mit Suffixen.

Ja, das war die Frage: Welches Filesystem denn keine Ordner mit Suffixen unterstützen würde, außer dem uralten FAT16 und davor.
Wie du schon sagst: Ein Suffix ist nichts als "alles hinter dem Punkt". Sowas wie "char[8]char[3]" gibt es nicht mehr, nur noch, als RegEx geschrieben, sowas wie /(.*)\.(.*)/s
Daher meine Frage: Welches FS unterstützt den KEINE Suffixe? Soweit ich das sehe: Alle können es.

._ut schrieb:
HelveCOnBol ist wohl ein Type1-Font. Mit dem kann man eh nur auf dem Mac was anfangen.

http://gd.tuwien.ac.at/z1/opsys/linux/RPM/contrib/libc5/i386/macfont-1.1-1.i386.html

Man kann mit allem überall was anfangen - wenn es einem nciht zu schwer gemacht wird. Was sollte auch in "HelveConBol" anderes drinstehen als in "HELVECB_.PFB".

._ut schrieb:
Und banane.eps ist auf einem Mac ob mit dem Inghalt von ._banane.eps oder mit Tiff innerhalb von banane.eps immer eine brauchbare Datei.:D
Der Unterschied ist nur: Wenn die Vorschau innerhalb von ._banane.eps (bzw. im Resource-Fork) kaputt geht, dann lässt sie sich einfach aus den Daten wieder herstellen, denn die sind ja getrennt davon. Wenn jedoch die Tiff-Vorschau innerhalb banane.eps kaputt geht, dann ist die komplette Datei und damit auch das eigentliche eps hin. Daher ist es eine gute Idee, Daten von Resourcen zu trennen und eine schlechte Daten und Resourcen zu mischen.

Äh..."Wenn ein Teil einer Datei kaputt geht, und es ist der richtige Teil, dann hat man Glück und es geht immer noch". Ja, klar - aber warum sollten Dateien kaputtgehen, warum nur Teile davon, warum ausgerechnet der richtige Teil? Und vermutlich kommt ohnehin auf beiden Varianten das gleiche heraus: Beim platzieren wird ein Programm auf die Vorschau zurückgreifen und wegsemmeln. Beim Öffnen im Erstellungsprogramm wird die Vorschau übersprungen (Da überflüssig) und das Dokument wird neu gesichert - in "funktionierend".
Im Gegensatz dazu: Man erstelle ein eps, brenne es auf eine CD, schicke es dem Kunden, der hat Windows, schickt es seiner lokalen Agentur per ISDN, der mailt es weiter an seine Druckerei - wie groß ist die Chance, daß die Datei heile ankommt, a) mit zwei Streams und b) mit einem Stream?
Und da Bilder meistens in der Druckerei neu plaziert werden müssen, ist ein eps ohne Preview de facto "kaputt", weil man sie außer in Illustrator und Corel nicht wieder öffnen kann (Freehand je nach Format - meistens nicht) und mit Preview sichern.

._ut schrieb:
Das grüne Etikett hat nichts mit den Resourcen zu tun. Das ist ein Metadatum im Dateisystem.

Ja. Nimms als Metapher. :)

._ut schrieb:
P.S. Warum Du aber Koffer und Packages gleichsetzt, habe ich immer noch nicht verstanden. Das sind unterschiedliche Dinge, die unterschiedlicher nicht sein könnten.

Ich setze sie nicht technisch gleich, sondern "logisch". Sie haben die Unsitte gemeinsam, daß sie Dinger "verstecken". Koffer sollten stattdessen normale Ordner sein. Packages sollten nicht nur "heimlich" normale Ordern sein, sondern sich auch so verhalten.
Du sagst ja, Packages seien ganz normale Ordner mit einer Extension. In der Shell ist da keine Extension. Was würde ich sehen, wenn ich ein HFS+-Volume unter Linux mounte? Eine Extension? In diesem Falle würde sich das Filesystem auf unterschiedlichen Plattformen unterschiedlich verhalten. Oder sehe ich keine Extension? Dann muß es doch wieder ein proprietäres FS-Feature sein. So oder so klemmt es - und wo ist der *Sinn* von Packages?

Gruß, Ratti
 
Zuletzt bearbeitet von einem Moderator:
BadHorsie schrieb:
Kleine Ergänzung wenns erlaubt ist: Type1-Fonts funktionieren auch unter Linux.

._ut schrieb:
Windows-Type1-Fonts.

Nixda. Einspruch! Randale!

*.PFB, PFA, PFM, AFM, INF sind Unix-Type-1-Fonts. Die gab es schon, da hat Bill noch an DOS rumgeschraubt. Also, wenn schon, dann laufen Unix-Fonts auch unter Windows, nicht umgekehrt :)))

Obige Formate hat erst der ATM unter Windows eingeführt.

Unter NT4 hat Billy dann einen "internen" Konverter mitgeliefert. Man konnte PS-Fonts laden, und intern wurden die dann nach TrueType gewandelt. Uargs...

Erst seit Windows 2000 kann man diese Formate auch ohne ATM "nativ" laden, und wenn ich mich recht entsinne, dann hatten die benötigten DLL-Files alle ein "ATM" im Namen - so'n Zufall. :)

Wie es nach Win2K weiterging, weiss ich nicht, ich habe dann zum Pinguin gewechselt.

Gruß, Ratti
 
Du sagst ja, Packages seien ganz normale Ordner mit einer Extension. In der Shell ist da keine Extension.

Doch! Guckst du

ls /Appications

lauter .app's

Das

und wo ist der *Sinn* von Packages

Packages sind dateisystemtechnisch stinknormale Ordner. Gut, denn dann kann man mit den schönen UNIX tools und ohne Verrenken ran.

Für die Oberfläche sind Packages aber immer von einem Typ und der sagt halt aus, wie das Package (der Ordner) intern strukturiert sein sollen. Also das ausführbare Programm innerhalb eines .app Packages z.B. unter

/Applications/iTunes.app/Contents/MacOS/

damit ist für den Finder klar, was zu starten ist.

Wenn du so willst, dann sind Packages halt standardisierte Ordner.

*Sinn*: Drag'and'Drop Installation von Programmen und nicht drüber nachdenken müssen, welchen Aufrufpfad man benutzten soll. Hab unter Linux schon oft das Programm suchen müssen:

/usr/bin
/usr/local/bin
/opt/XXX/bin
/usr/local/lib/XXX/bin

klar gibts in der Linux-Welt auch dafür Konventionen, aber leider sind die nicht auf allen Distris gleich.

Packages einfach der Nachbau von Ressource-Fork Dateien auf einem UNIX Filesystem. Und wenn man zweimal drüber nachdenkt auch besser.
 
Apple nimmt lieber Cocoa als X11 - OK, dann eben kein brauchbares OpenOffice für Maccianer.

Ich fang mit Dir nicht wieder die Pro/Contra Mac OSX/Linux an. Das nervt. Ausserdem widersprichst Du Dir in Bezug auf die Mailboxen. Komm wieder runter. Wenn Dir der Mac nicht passt zwingt Dich niemand ihn zu nutzen.
 
Ich sag nur SMB Performance. Lausig!

Kann ich nicht bestätigen. Ich hab die maximal mögliche Performance auf meinem Netzwerk. Und eher wenig CPU Last.
 
ai-freak schrieb:
Doch! Guckst du

ls /Appications

lauter .app's

Nö:

[xbox:/Applications] admin% ls -lad S*
-rw-r--r-- 1 admin admin 0 Aug 17 2003 SLP-Umgebung einstellen
drwxrwxr-x 3 root admin 102 May 21 2003 Safari.app
-rw-r--r-- 1 admin admin 0 Jan 13 2004 Schlu??sselbund
-rw-r--r-- 1 admin admin 0 Mar 12 2004 Server-Assistent
-rw-r--r-- 1 admin admin 0 Aug 17 2003 Server-Einstellungen
-rw-r--r-- 1 admin admin 0 Aug 17 2003 Server-Status
-rw-r--r-- 1 admin admin 0 Aug 17 2003 Servermonitor
drwxrwxr-x 3 root admin 102 Sep 15 2003 Sherlock.app
drwxrwxr-x 3 root admin 102 Jul 29 2002 Stickies.app
-rw-r--r-- 1 admin admin 0 Aug 17 2003 StuffIt Expander
drwxr-xr-x 3 root wheel 102 Jul 29 2002 System Preferences.app

Mac OS X 10.2 Server.
Beachte die vielen 0-Bye-Files.

ai-freak schrieb:
Packages sind dateisystemtechnisch stinknormale Ordner. Gut, denn dann kann man mit den schönen UNIX tools und ohne Verrenken ran.

Für die Oberfläche sind Packages aber immer von einem Typ und der sagt halt aus, wie das Package (der Ordner) intern strukturiert sein sollen. Also das ausführbare Programm innerhalb eines .app Packages z.B. unter

/Applications/iTunes.app/Contents/MacOS/

damit ist für den Finder klar, was zu starten ist.

Und genau hier ist doch die Sinnfrage: Warum nicht das Programm xyz im Ordner "/Applications/iTunes.app/Contents/MacOS/" starten?


ai-freak schrieb:
*Sinn*: Drag'and'Drop Installation von Programmen und nicht drüber nachdenken müssen, welchen Aufrufpfad man benutzten soll. Hab unter Linux schon oft das Programm suchen müssen:

/usr/bin
/usr/local/bin
/opt/XXX/bin
/usr/local/lib/XXX/bin

klar gibts in der Linux-Welt auch dafür Konventionen, aber leider sind die nicht auf allen Distris gleich.

"which" ist auf allen Distris gleich funktional und macht sich wunderbar innerhalb von Backticks:

> which fdisk

oder

> cp `which fdisk` ~/fdisk.bak


ai-freak schrieb:
Packages einfach der Nachbau von Ressource-Fork Dateien auf einem UNIX Filesystem. Und wenn man zweimal drüber nachdenkt auch besser.

Gut ist schonmal, daß die Daten in einer Fork liegen. Den Vorteil gegenüber normalen Ordnern sehe ich aber nicht...

Gruß, Ratti
 
sgmelin schrieb:
Ich fang mit Dir nicht wieder die Pro/Contra Mac OSX/Linux an. Das nervt.

X11 ist kein "Linux", sondern eine plattformübergreifende Technologie. X gab es schon, da hat Linus noch an seinem Heimcomputer gelötet.

sgmelin schrieb:
Ausserdem widersprichst Du Dir in Bezug auf die Mailboxen.

Kannst du mir eine Stelle zeigen, an der ich etwas ANDERES sage als "Mails sollten
- in standardisierten Fileformaten vorliegen (mbox, MHdir, MailDir,...),
- ohne plattformspezifische Strukturen in oder um die Dateien,
- ggf. mit in externe Indices ausgelagerten Erweiterungen"?

Ich glaube nicht. Den Widerspruch mußt du also bitte zeigen.

sgmelin schrieb:
Wenn Dir der Mac nicht passt zwingt Dich niemand ihn zu nutzen.
Ich habe Jehova gesagt. Daher muß ich sofort meinen Job kündigen.

Gruß, Ratti
 

Du hast ein komisches System. So siehts bei mir aus:

drwxrwxr-x 3 root admin 102 6 Aug 06:26 Disk Utility.app
drwxrwxrwx 3 sgmelin sgmelin 102 11 Aug 00:54 EPSON Scan Settings.app
drwxrwxrwx 3 sgmelin admin 102 13 Apr 04:20 FinkCommander.app
drwxrwxr-x 3 root admin 102 6 Mar 2004 Grab.app
drwxrwxr-x 3 root admin 102 6 Aug 06:29 Installer.app
drwxrwxr-x 8 root admin 272 6 Aug 2003 Java
drwxrwxr-x 3 root admin 102 15 May 23:30 Keychain Access.app

Und genau hier ist doch die Sinnfrage: Warum nicht das Programm xyz im Ordner "/Applications/iTunes.app/Contents/MacOS/" starten?

Häää? Mach ich doch, wenn ich auf das Icon klicke. Das reicht doch. Mit der Lösung hab ich alles zusammen. Ich weiss nicht, was Du willst. Du bist einfach komisch. Mehr fällt mir dazu nicht ein. Nimm es doch einfach hin, dass ein anderes System komplett anders funktioniert. Ich wünsche Dir von ganzem Herzen, dass Du mal mit einer iSeries (AS/400) arbeiten musst. Dann weisst Du was anders ist.
 
sgmelin schrieb:
Du hast ein komisches System.

Mein System ist nicht komisch. ICH bin komisch. Tragikomisch! Hmpf... das waren nämlich Aliasse. Ich Elch. Selbstkopfschiess.

sgmelin schrieb:
Häää? Mach ich doch, wenn ich auf das Icon klicke. Das reicht doch. Mit der Lösung hab ich alles zusammen. Ich weiss nicht, was Du willst.

Wenn ich auf /Applications/TextEdit.app klicke, dann will ich, daß sich dieser Ordner öffnet. Nicht, daß dadurch ein Programm drei Ordner tiefer gestartet wird. Das ist obskur.

sgmelin schrieb:
Ich wünsche Dir von ganzem Herzen, dass Du mal mit einer iSeries (AS/400) arbeiten musst. Dann weisst Du was anders ist.

Aha. Meines Wissens handelt es sich bei einer AS/400 um eine Hardware, auf deren Basis virtuelle Maschinene diverse Plattformen gleichzeitig ausgeführen - oder irre ich mich da? Ist das in einer Diskussion über Desktop-OSse nicht ebenso passend wie "Schau dir mal Salatgurken an, die sind *richtig* anders als Mac OS!". Ja, sind sie. Und?

Gruß, Ratti
 
X11 ist kein "Linux", sondern eine plattformübergreifende Technologie. X gab es schon, da hat Linus noch an seinem Heimcomputer gelötet.

Danke, aber das weiss ich auch. Also, warum sollte Apple beim Design eines neues Systems auf eine mehrere Jahrzehnte alte Technologie zurückgreifen? Nur, damit es die Programmierer einfacher haben? Nutzt denn Windows X-Window? Nein. Wenn Stillstand Rückschritt ist, was ist dann Rückschritt??
 
Aha. Meines Wissens handelt es sich bei einer AS/400 um eine Hardware, auf deren Basis virtuelle Maschinene diverse Plattformen gleichzeitig ausgeführen - oder irre ich mich da?

Da irrst Du Dich ganz gewalting. Die AS/400 stellt ein Einspeichersystem zur Verfügung. D.h. die Festplatten werden wie normaler Hauptspeicher verwaltet und Daten, die auf der Platte liegen werden Objektorientiert abgelegt. Das Filesystem (welches keines ist) ist eine einizige grosse Datenbank und Objekte werden lediglich aufgrund ihrer Attribute zu bestimmten Objekten. D.h. Du legst ein Objekt an und gibst im dann alle Attribute, die einen Benutzer darstellen und schon ist das Objekt ein Benutzer.
Also was komplett anderes.

Wenn ich auf /Applications/TextEdit.app klicke, dann will ich, daß sich dieser Ordner öffnet.

Wieso? Wenn Du den Order nur deshalb öffnest, um ein Programm darin zu starten kannst Du das Programm doch auch direkt starten. Wenn Du unbedingt in den Ordner willst kannst Du das ja tun. Aber wenn Du nur das Programm starten willst ist es doch wesentlich einfacher, wenn direkt dieses gestartet wird.

Ist das in einer Diskussion über Desktop-OSse nicht...

Ein Mac OS X Server ist kein Desktop OS. Ein Unix ist von Haus aus kein Desktop OS. Es ist komplett auf Serverbetrieb ausgelegt. Und Linux ist auch erstmal ein Multiuser OS mit Fokus auf den Serverbetrieb. Wäre es ein Desktop OS gäbe es einheitliche Standards.
 
sgmelin schrieb:
Also, warum sollte Apple beim Design eines neues Systems auf eine mehrere Jahrzehnte alte Technologie zurückgreifen? Nur, damit es die Programmierer einfacher haben? Nutzt denn Windows X-Window? Nein. Wenn Stillstand Rückschritt ist, was ist dann Rückschritt??
Um zurück zum Topic zu kommen, ein netzwerktransaprentes Aqua/Quartz wäre klasse!
 
ratti schrieb:
Wenn ich auf /Applications/TextEdit.app klicke, dann will ich, daß sich dieser Ordner öffnet. Nicht, daß dadurch ein Programm drei Ordner tiefer gestartet wird. Das ist obskur.
Zuerst Hochachtung vor eurer Fachdiskussion - da versteh ich nur Bahnhof

Nehmen wir Muster Müller aus Kleinlützel und stellen uns vor, was der machen würde, wenn es ein normaler Ordner wäre:
"ÖHH!?? was sind denn das für komische Sachen drinn? - äh im Grunde brauche ich kein Muster!! oder was immer das sein mag. mal ein wenig aufräumen hier.. - will doch nicht jedesmal das Programm suchen! Weg mit dem Müll..."

---> Dann ist das Progi futsch

Zur Erinnerung an alle UNIX und Linux Freaks: Mac OS X wurde nicht in 1. Linie für Euch erfunden. Sondern als Basis die Vorteile eines stabilen UNIX Systems und dann wurde "weiterentwickelt" damit es Hansdampf intuitiv bedienen kann, um damit produktiv zu arbeiten oder sehr kreativ zu sein.

Aha. Meines Wissens handelt es sich bei einer AS/400 um eine Hardware, auf deren Basis virtuelle Maschinene diverse Plattformen gleichzeitig ausgeführen - oder irre ich mich da? Ist das in einer Diskussion über Desktop-OSse nicht ebenso passend wie "Schau dir mal Salatgurken an, die sind *richtig* anders als Mac OS!". Ja, sind sie. Und?
Gruß, Ratti
IMHO ist AS/400 ein "altes" Betriebssystem von IBM, welches mich an "Matrix" erinnert. Und das läuft halt eben auf iSeries Hardware von IBM.
 
hallo alle!

interessante diskussion führt ihr da…*über standardisierte ordner und struktur des BS… ich würde aber mal ganz gern zum thema "most wanted panther bugs" noch was hinzufügen:

Um Ressourcen zu sparen wird der Finder nur alle 5 sekunden oder bei Triggerung mittels eines Mausklicks neu geladen. Das kann aber mit einem Tool geändert werden.

Habe immer wieder das Problem, daß von mir erstellte PDFs nicht sofort im Finder sichtbar sind. Ich schreibe per Drucken-Dialog und Acrobat 6 ein PDF auf den Schreibtisch. Es erscheint aber erst, wenn ich Apfel+n drücke und mich zu meinem Schreibtisch durchklicke. Einfach nur eine Mausbewegung ausführen hilft da garnichts. Neben den bereits erwähnten Bugs wäre auch hier noch ein echtes Potential - unter OS 9 gab es solche Trägheits-Probleme nämlich nie…
 
Ich finde die *.app Archive auch sehr nützlich. Dieses Beispiel sollte Schule machen. Sinnvoll wäre sowas auch für HTML Archive *.har. Noch besser wäre es wenn man generell die Möglichkeit hätte zusammengehörende Dateien zu bundeln und mit einem eigenen Icon zu versehen. Mittels *.xml oder *.pref Datei könnte die zu startende Datei beim Doppelklick definiert werden.

Eine wie ich finde richitg coole Sache.
BadHorsie
 
Eine sehr amüsante Diskussion, ehrlich.

Aber wie immer werden zwei Sachen durcheinander geworfen: Usability für normale Benutzer und Mächtigkeit für die Profis.

Warum hat Apple die Packages eingeführt? Ganz einfach: Für Anbieter von Software wird das Deployment vereinfacht und für den normalen Benutzer die Handhabung und Übersichtlichkeit des "Dateisystems". Und das ist in meinen Augen auch schlüssig, denn ich liefere meine Java-Anwendungen ja auch als .jar-Archiv inkl. Manifest aus und nicht tausende von Unterverzeichnissen mit .class Dateien. Und der "Profi" kann über die Shell immer noch auf die Inhalte der Packages zugreifen, und das einfacher, als es z.B. mit den jar-Archiven möglich ist.

Apple hat meiner Meinung nach einen mutigen aber guten Weg verfolgt, ein benutzerfreundliche Oberfläche und ein UNIX-System zu verbinden, um die Bedürfnisse aller Benutzergruppen zu befriedigen. Das das aus den unterschiedlichsten Gründen nicht ganz ohne properitäre Lösungen, seien es auch wirtschaftliche, sollte auch nachvollziehbar sein. Welcher Grund würde denn für die Anschaffung von Apple-Geräten sprechen, wenn da Darwin mit X11 laufen würde? Dann könnte sich die Apple darauf beschränken, das x-te Fenstersystem zu entwickeln oder einfach ein Theme für KDE auf den Markt zu bringen. Dann könnten Sie auch die Hardware-Sparte dicht machen, denn andere Architekturen sind billiger.

Un wo wir gerade bei dem Thema sind: Ich war eigentlich der Meinung, dass Apple nur an der Entwicklung von Darwin beteiligt ist, indem sie Änderungen machen und dem Darwin-Team wieder zur Verfügung stellen. Das ist auch wieder ein Grund, warum hier und da getrickst werden muß, denn Apple kann nicht das ganze Darwin umkrempeln, nur weil es Diskrepanzen zwischen Usability und Mächtigkeit gibt. Das wurde in einem der ersten Posts etwas von hinten aufgezäumt.

Und genau diese Kombination hat mich zum Umstieg zu Mac bewogen: Ich habe ein einfaches, benutzerfreundliches und grafisches Betriebssystem bei dem ich dennoch, unter Einsatz des UNIX's Kerns volle Kontrolle ausüben kann, auch wenn ich dafür auf die Shell zugreifen muß (was ich auch sehr gerne mache, denn ich komme noch aus dem Novell-Umfeld und liebe Shell's).

Zu dieser ganzen Diskussion möchte ich euch auch nopch ein Essay ans Herz legen: "At the beginning was the commandline" von Neal Stephenson (heißt im deutschen Die Diktatur des schönen Scheins, oder so.). Unter dem Leitsatz "Wie grafische Oberflächen die Computernutzer entmündigen" geht es genau um die Inhalte dieser Diskussion
 
ratti schrieb:
Wenn ich auf /Applications/TextEdit.app klicke, dann will ich, daß sich dieser Ordner öffnet. Nicht, daß dadurch ein Programm drei Ordner tiefer gestartet wird. Das ist obskur.

Hmmm, ich hab die Diskussion verfolgt und im "einstelligen Prozentbereich" kapiert :) Habe mich mit Unix- bzw. Linux-Internas noch nicht groß beschäftigt.
Aber das kapier ich nicht mehr. Also ich will, daß sich dann das Programm öffnet. Wenn ich in den Paketinhalt reinschauen will, dann halt mit der rechten Maustaste. Ich will aber nur im Notfall reinschauen. Da bin ich Pragmat und Nihilist zugleich.
Das ist doch das schöne an den Paketen - alles unter einem Dach :) Egal wo das Ding liegt, es startet. Im Gegensatz zu gewissen anderen BS.
Oder interpretiere ich da was falsch?

Grüße,
Flippidu
 
ratti schrieb:
Daher meine Frage: Welches FS unterstützt den KEINE Suffixe? Soweit ich das sehe: Alle können es.
Das FS hat damit nichts zu tun. Packages funktionieren auch auf UFS-Volumes.
In anderen BS hat ein Suffix in einem Ordnernamen keinerlei Bedeutung, ein Suffix in einem Dateinamen aber schon.
Unter Mac OS X hat aber auch ein Suffix in einem Ordnernamen eine Bedeutung, er macht den Ordner zu einem Package. (Wenn es der richtige ist. Ordner mit Suffix .kext wurden übrigens in 10.0 noch als normale Ordner angezeigt, sind jetzt aber Packages.)
Äh..."Wenn ein Teil einer Datei kaputt geht, und es ist der richtige Teil, dann hat man Glück und es geht immer noch".
Daten und Resourcen sind eigentlich nicht Teile einer Datei. Es sind zwei Dateien, die lediglich vom Dateisystem zueinander zugeordnet werden.
Ich setze sie nicht technisch gleich, sondern "logisch". Sie haben die Unsitte gemeinsam, daß sie Dinger "verstecken". Koffer sollten stattdessen normale Ordner sein.
Koffer sind keine Ordner, sondern Dateien, die im Finder geöffnet werden können. (Wie gesagt, das ist keine Eigenschaft des Koffers, sondern des Finders.)
Packages hingegen sind Ordner, die im Finder nicht per Doppelklick geöffnet werden.
Das genaue Gegenteil also.
Packages sollten nicht nur "heimlich" normale Ordern sein, sondern sich auch so verhalten. Du sagst ja, Packages seien ganz normale Ordner mit einer Extension. In der Shell ist da keine Extension. Was würde ich sehen, wenn ich ein HFS+-Volume unter Linux mounte? Eine Extension? In diesem Falle würde sich das Filesystem auf unterschiedlichen Plattformen unterschiedlich verhalten. Oder sehe ich keine Extension? Dann muß es doch wieder ein proprietäres FS-Feature sein.
Unter Linux siehst Du eine Extension (mal davon abgesehen, dass auch im Finder die Suffixe von Packages angezeigt werden, mit Ausnahme der .app-Packages, bei denen der Suffix immer ausgeblendet wird) und kannst den Ordner ganz normal öffnen. Es ist auch kein FS-Feature, sondern ein Feature des Finders. Ordner mit bestimmten Suffixen werden nicht per Doppelklick geöffnet. Das dient der Übersichtlichkeit und verhindert versehentliches Auseinanderreißen des Inhalts.
So oder so klemmt es - und wo ist der *Sinn* von Packages?
Bei einem .app-Ordner z.B. bekommt der Anwender ein klar dem Programm zuzuordnendes Icon zu sehen, bei einem Doppelklick wird die darin enthaltene Binärdatei gestartet.

Das /System zu einem Package zu machen wäre übrigens eine gute Idee. Geht aber nicht mehr, weil dann ja der Name geändert werden müsste (z.B. in /System.system).
 
Zurück
Oben Unten