Die größten Probleme in Mac OS X Panther

93noddy schrieb:
äh also andersrum hab ich das problem auch...die lösung ist da wie folgt: Apple als netzlaufwerk verbinden und mit xcopy arbeiten. Ich denke andersrum geht es ähnlich: Mounten, cp
@93noddy
xcopy kann doch nicht die einzige Lösung sein... Ich hab gestern meinen Mac als FTP Server konfiguriert und anschließend die Daten mit einem FTP Client auf die Windows Krücke gezogen - aber das war halt leider saulahm. Da alter man schon beim zuschauen... :D
Gibt's denn kein gescheites Kopiertool auf unserer favorisierten Plattform das sowas kann?

Chris
 
ich weiss nicht, ich find xcopy kein problem. Ich arbeite gerne unter dos im "terminal". Es gibt bestimmt nen tool, aber ehrlich gesagt findet bei mir eh nur die dose den mac und nicht andersrum und das googlen dauert sicher nicht viel weniger lang als xcopy zu tippen. Der MAC (bzw. das in samba gerade freigegebene VZ) wird "gemountet" und dann halt xcopy bzw. sichern.bat aufrufen *g*. Solang man GANZE Verzeichnisse kopiert ist das kein Problem. Bei Einzeldateien wird es schwierig, aber dann tritt der Fehler ja nicht mehr auf...
 
@93noddy
Ich hab auch kein Problem mit DOS, bei mir siegt momentan nur die Bequemlichkeit. Die Windows Kiste steht im Keller und mein Büro ist im Dachgeschoss... Und das ganze über die Remote Desktop Verbindung oder VNC kann schließlich nicht der Weisheit letzter Schluss sein. Vielleicht muss man am End doch noch selber programmieren...
Apropos Programme, hast Du das schonmal mit dem TotalCommander probiert? Der ist um einiges komfortabler und leistungsfähiger - vielleicht klappts damit ja auch bei Dir
 
ratti schrieb:
Schonmal versucht, unter einem anderen OS einen Koffer zu öffnen, weil du an die Metriken eines Fonts dranwolltest? Selbst wenn du die Ressource-Fork rüberkriegst, hast du irgendein proprietäres Dateiformat namens "Koffer".
Moderne Fonts sind eine "normale" Datei
Die dfonts sind genau diese Koffer im Datenzweig.
Warum ist ein Postfach in Mail ein Package, welches eine mbox und eine Indexdatei einthält - warum hat man nicht einfach die flache mbox und ein .idx-Datei? Es steht außer Zweifel, daß es lokal funktioniert, aber /warum/?
Noch einmal: Pakete sind Ordner mit Suffix. Nichts weiter.
Der Inhalt des .mbox-Ordners sieht genau so aus, wie Du es beschreibst: Eine Mailbox und eine Index-Datei, dazu eine Unterorder für die Attachments und noch ein paar Dateien für den Kontextindex und ähnlichen Verwaltungskram. (Das Format stammt aus NeXT-Zeiten, da gab es keine Resourcen und keine Metadaten.)
Warum bekommen EPSe eine pict-Preview in der Ressource-Datei, vorbei an allen von Adobe definierten Standards, statt eine Cross-Platform-kompatiblen Tiff-Preview in der Data-Fork
Das PICT-Preview im Resourcen-Zweig hat Adobe eingeführt. Die Standards hat Adobe dann geändert, als sie begannen Software auch für den PC zu verkaufen. Ein PC kann nun mal keine getrennten Resourcen, also müssen Daten, Resourcen und Metadaten in die Daten-Datei gemischt werden.

P.S. Übrigens schreibt auch Photoshop CS bei EPSen eine PICT-Vorschau in den Resourcen-Zweig (es sei denn, man wählt beim Sichern ein anderes Vorschau-Format).

P-.P.S Und warum man Daten und Resourcen eigentlich nicht mischen sollte, kann man am Pagemaker- oder Word-Format sehen. Da sind nämlich defekte Dateien vorprogrammiert.
 
Zuletzt bearbeitet von einem Moderator:
sgmelin schrieb:
Wieso denn das??? Gib mir mal einen triftigen Grund, warum eine Datei eine extension haben sollte. Gerade als Linux Verfechter, der Du ja bist sind ext. ja quatsch. Die Appl. soll gefälligst in das File reingucken und nicht auf die ext. Dann ist auch Schluss mit Script-Viren.

Mit "Script-Viren" ist dann Schluß, wenn nicht jedes HansFranz-Programm meint, irgendwas embedden, executen oder whatever zu müssen. Egal, wie die Datei heisst... wir brauchen keine Textformate, die executables einbetten... aber das nur am Rande.

Nun, ganz einfach:
Wenn ich zuhause ein Shellscript anlege, will ich, daß es auf meinem Linux ein Shellscript ist, und wenn ich es mir auf die Arbeit maile, dann soll es auf meinem Mac OS X auch immer noch ein Shellscript sein und kein "Text". Und wenn ich dann an unseren OS 7 (Ja, sieben!) Leonardo-ISDN-Server gehe und es meinem Admin-Kollegen sende (Ist nämlich ein Quadra mit NuBus, und eine neue Maschine macht ISDN genau so schnell oder langsam), dann will ich, daß es seinen Namen behält und nicht auf 31 Zeichen oder whatever gekürzt wird. Und wenn der es in seiner Cygwin-Umgebung unter Windows handhabt, soll es immer noch ein Shellscript sein.

Beispiel reales Leben: Ich habe heute mit Interarchy zwei selbstgebastelte Perl-Scripte von meinem Webserver geholt, und beide waren plötzlich vom Typ "Diskimage". Mit ".pl" wäre das nicht passiert, und wenn doch, hätte ich dem Mac gesagt "*.pl mit immer BBedit öffnen". So habe ich erst mit SetInfo aus dem Developerpack dran rumfummeln müssen...

Gut, 8+3-Dateinamen müssen nicht sein - aber 30 Zeichen reichen.

Dazu kommt: Ich verwende zuhause zwar eine grafische Benutzeroberfläche, aber keinen Dateimanager mehr, dazu nehme ich ein xterm. Das geht einfach deutlich schneller als durchklickern. Wenn ich bei jeder Datei überlegen muß, ob ich sie vorne groß oder klein geschrieben habe, und Leerzeichen escapen muß... dann kann ich auch wieder Dateifensterchen benutzen, dann ist der Geschwindigkeitsvorteil dahin.

sgmelin schrieb:
Gut, Sonderzeichen kann ich verstehen. Leerzeichen sind aber doch kein Problem. Sie sind vielleicht für uns humanoide schlecht zu handeln, weil wir sie immer in Anführungszeichen setzen müssen, aber das ist doch auch nur eine kleine Unannehmlichkeit.
Kurze Dateinamen????? Wieso um alles in der Welt darf ich meinen Brief nicht "Brief an Oma wegen Danksagung für Weihnachten" nennen??? Ich will bereits am Namen erkennen können was mich erwartet. Gut, 255 Zeichen sind vielleicht etwas viel, aber so um die 50 Zeichn sollten es schon sein. Die 31 auf meinem Amiga waren schon oft zu kurz.

oma_weihnachbrief.txt

Komm, gib zu, _so_ oft schreibst du deiner Oma nicht, daß du die Briefe verwechselst... :)))

sgmelin schrieb:
Creator wo nötig? Wieso denn? Ich muss sagen, wenn ich in der Datei den Creator erfasse reicht das doch. Wenn im Header Freehand drinsteht soll sich das System darum kümmern woher es kommt....

Manchmal bin ich es ein klein wenig leid... :)
Nein, das richtet sich nicht gegen dich. Ich predige solche Sachen halt immer, und ernte auch immer diese Reaktion. Und früher oder später fallen die Leute dann so richtig auf die Schnauze.
Weil die Dateien über Windowskisten wandern. Weil sie über alte Macs transportiert werden. Weil sie auf einem Drucker gedruckt werden, der an ein Unixbasiertes OPI-System angeschlossen ist mit einem "%" als verbotenes Nameszeichen. Weil irgendjemand versehentlich eine ISO-CD brennt statt HFS(+). Und vor allem: Weil einfach niemand mit sowas rechnet - daß da plötzlich eine Unix-Maschine mitspielt - man wollte doch bloß ein Poster drucken... Deswegen beachte ich diese Regeln IMMER. Und es hat mir oft den Allerwertesten gerettet.

Man kann halt auf seiner Kiste machen, was man will. Sobald der Kram in fremde Hände geht, sollte alles unterbleiben, was Schaden anrichtet.

Um beim "Creator" zu bleiben: Wenn du deine "*.eps"-Datei nach Windows rüberschiebst, gehören halt alle eps-Dateien CorelDraw. Oder Illustrator. Oder Freehand. Je nachdem, was als letztes installiert wurde. Was glaubst du, wie der Empfänger sich freut, wenn der in problematischen Daten nicht rumhacken brauch, sondern die Datei heisst "logo.fh7.eps".

(Natürlich nenne ich eine Textdatei nicht "meintext.bbedit.txt", denn das wäre Quatsch. Und ein jpeg für eine Website muß nicht "bild.rgb.72dpi.jpg" heissen, das ist eh klar.)

Lange Rede, kurzer Sinn, meine Devise:
Mach es Idiotensicher. Vollidiotensicher.

sgmelin schrieb:
Also manchmal überraschst Du mich doch stark.

Oh, Danke. :)

Gruß, Ratti
 
Wenn ich bei jeder Datei überlegen muß, ob ich sie vorne groß oder klein geschrieben habe, und Leerzeichen escapen muß... dann kann ich auch wieder Dateifensterchen benutzen, dann ist der Geschwindigkeitsvorteil dahin.

Die Tab Taste macht das doch für Dich. Und Cut´n´Paste.
Und nur, weil Du Deine Scripts mit nem uralt System austauschen willst willst Du die gesamte OS Welt ändern? Naja....

oma_weihnachbrief.txt

Komm, gib zu, _so_ oft schreibst du deiner Oma nicht, daß du die Briefe verwechselst... :)))

Erwischt: :) Aber das war ja nur ein Beispiel. Ich habe einige Dateinamen, die länger sind. OK, viele sind nicht länger als 30 Zeichen, das wird schlecht lesbar, aber ich als Benutzer will doch die Wahl haben und nicht vom Computer eingeschränkt werden.

Deswegen beachte ich diese Regeln IMMER. Und es hat mir oft den Allerwertesten gerettet.

Das darfst Du auch gerne machen. Wenn Du lange Dateinamen verwenden kannst, die nicht auf die ext. schauen, dann kannst Du die Namenspolicy verwenden, die Du willst. Ohne anderen was aufzuzwängen.
Um beim "Creator" zu bleiben: Wenn du deine "*.eps"-Datei nach Windows rüberschiebst, gehören halt alle eps-Dateien CorelDraw. Oder Illustrator. Oder Freehand. Je nachdem, was als letztes installiert wurde. Was glaubst du, wie der Empfänger sich freut, wenn der in problematischen Daten nicht rumhacken brauch, sondern die Datei heisst "logo.fh7.eps".

Da wären wir ja wieder beim eigentlichen Problem: Mach Dein System Windows kompatibel. NEIN! Ich ordne mich diesem ollen Müll nicht unter. Nur wenn ich muss. Und wenn nicht, dann nicht. Aber das entscheide ich. Und nicht mein System. Wenn jetzt noch der Mac anfängt sich nach Windows zu richten nehm ich wieder Papier und Bleistift.
 
._ut schrieb:
Die dfonts sind genau diese Koffer im Datenzweig.

Koffer sind einfach ein zugenageltes Format. Auf anderen Kisten ist kein rankommen an den Inhalt - im Gegensatz z.B. zu einer "losen OTF-Datei.

._ut schrieb:
Noch einmal: Pakete sind Ordner mit Suffix. Nichts weiter.
Der Inhalt des .mbox-Ordners sieht genau so aus, wie Du es beschreibst: Eine Mailbox und eine Index-Datei, dazu eine Unterorder für die Attachments und noch ein paar Dateien für den Kontextindex und ähnlichen Verwaltungskram. (Das Format stammt aus NeXT-Zeiten, da gab es keine Resourcen und keine Metadaten.)

Ja, aber meine Frage war ja: Warum?
Was, wenn eine andere Plattform ebendiesen Suffix für etwas anderes benötigt, und was ist der Vorteil gegnüber einem "echten" Ordner (heisst: Ein als solcher erkennbarer)


._ut schrieb:
Das PICT-Preview im Resourcen-Zweig hat Adobe eingeführt.

Also, meine Postscript-Doku weist ausschliesslich TIFF aus.
Das ist ja auch nicht weiter verwunderlich, da damals Unix noch eine größere Rolle als "DTP-Workstation" gespielt hat (Wenn ich das manuelle verdrahten von Fontlochkarten mal als DTP bezeichnen darf :) ) und PICT ein rein propritäres Mac-Format ist.

._ut schrieb:
Die Standards hat Adobe dann geändert, als sie begannen Software auch für den PC zu verkaufen. Ein PC kann nun mal keine getrennten Resourcen, also müssen Daten, Resourcen und Metadaten in die Daten-Datei gemischt werden.

Das kann eigentlich nicht sein. Allenfalls hat Adobe PICT später hinzugefügt. Die Doku kannst du bei Adobe downloaden.

._ut schrieb:
P.S. Übrigens schreibt auch Photoshop CS bei EPSen eine PICT-Vorschau in den Resourcen-Zweig (es sei denn, man wählt beim Sichern ein anderes Vorschau-Format).

Ja - und das wird man ziemlich schnell tun. Die PICT-Previews funktionieren nämlich oft nicht, nichtmal innerhalb der CreativeSuite. Spätestens beim Plattformwechsel, und der ist heutzutage normal.

._ut schrieb:
P-.P.S Und warum man Daten und Resourcen eigentlich nicht mischen sollte, kann man am Pagemaker- oder Word-Format sehen. Da sind nämlich defekte Dateien vorprogrammiert.

Das mußt du dann jetzt bitte doch mal erklären, wieso das dann bei allen anderen Programmen hervorragend funktioniert, insbesondere bei Systemen, die dort gar nicht trennen, und wieso denn dabei irgendwas "kaputt" gehen soll. In Pagemaker (Ok, ich arbeite selten damit) hat es mir noch nie was zerlegt, und in Word...zerlegt es dauern irgendwas, ob nun mit oder ohne Ressourcen.


Führt aber alles am Thema vorbei. Mehrstreamige Dateisystem sind nicht CrossPlattform-kompatibel, zugunsten kleinster Goodies, die man nicht braucht. Also warum? Für die paar bells'n whistles auf dem Desktop? Das kann man alles auch anders lösen, ohne Kollateralschäden.

Gruß, Ratti
 
Was, wenn eine andere Plattform ebendiesen Suffix für etwas anderes benötigt,

Andere Frage: Was stellt die andere Plattform über diese? Wieso sollte ich mich nach der anderen richten, oder diese nach mir? Wieso sind wir denn so von diesen Scheiss ext. abhängig?
Ich halte die Lösung von Apple für gut. Für den Anwender erscheint der Ordner als Datei und wenn er das Programm löschen oder kopieren will kann er es bedenkenlos tun (meistens). Die Idee dahinter ist gut. Dass Du damit auf deiner Linux oder DOSe nix anfangen kannst ist nicht Apples schuld. Es befinden sich eh Binaries in dem Ordner mit denen Du nix anfangen kannst.
 
sgmelin schrieb:
Die Tab Taste macht das doch für Dich. Und Cut´n´Paste.
Und nur, weil Du Deine Scripts mit nem uralt System austauschen willst willst Du die gesamte OS Welt ändern? Naja....

Wieso "Uralt-System"? Da:

ls -la /boot/vmlinuz-2.6.9-rc2
-rw-r--r-- 1 root root 1761306 2004-09-26 23:33 /boot/vmlinuz-2.6.9-rc2

...der Kernel ist von gestern!

:)

Im Ernst: Ich "komme" ja selbst von der GUI, Shells habe ich zunächst widerwillig hingenommen, inzwischen habe ich festgestellt, daß es einfach schneller geht als mit der GUI. Und wenn ich meine Linux- und Darwin-Mailinglisten so verfolge, geht es vielen Leute so.

Tab-Taste hilft nicht, wenn ich mir über die Groß-und Kleinschreibung nicht sicher bin, oder wenn ich alle drei Zeichen TabTab drücken muß. Oder, Extremfall: Wenn ich wie eben bei einer downgeloadeten mp3-Datei mit "!" und '"' und Spaces und ":"...vor lauter escaping den Namen kaum entschlüsseln kann. :)

Ich mache mir halt das Leben einfach. Und "cp oma[tab]" geht halt einfacher als "cp o[tabtab, nix][backspace]O[tabtab][aha, war groß geschrieben]ma[tabtab]\ ..."


sgmelin schrieb:
aber ich als Benutzer will doch die Wahl haben und nicht vom Computer eingeschränkt werden.

Hmm... Computer sind wie das Wetter: Klar will man kein Regen oder Schneegestöber, aber es ist nunmal Realität, daß es so ist, wie es ist. Diverse Schrottware ist in der Welt, und man muß damit klarkommen...

Das fiese an Computern ist: Es ist ihnen Scheissegal, ob man etwas dreissig mal versucht und jedesmal auf die Schnauze fällt. "This device has no brain. Use your own." Oder, wie letzte Woche mein Arbeitskollege zu unserem Praktikanten sagte, angesichts dessen haarausraufenden Programmierstils: "Der Computer braucht keine Zeilenumbrüche. *DU* brauchst Zeilenumbrüche!" :)


sgmelin schrieb:
Das darfst Du auch gerne machen. Wenn Du lange Dateinamen verwenden kannst, die nicht auf die ext. schauen, dann kannst Du die Namenspolicy verwenden, die Du willst. Ohne anderen was aufzuzwängen.

Wie sollte ich auch anderen Usern eine Namenspolicy aufzwingen. Soll ich mir drei Albaner mieten? :) Ich kann halt nur dazu raten - und begründen, warum es Sinn macht.

Ärgerlich wird es halt nur, wenn man selber zum Ziel der Gedankenlosigkeit anderer wird. Neulich wollte ich alte Deutsche Schreibschrift lernen, habe mir einen schönen Font besorgt - und der rennt nicht, weil er "Sütterlin" heisst - jedenfalls unter Windows. Unter allen anderen OSsen heisst er "S[sonderzeichen]tterlin" und lässt sich in HTML nicht ansprechen. Grmbl...


sgmelin schrieb:
Da wären wir ja wieder beim eigentlichen Problem: Mach Dein System Windows kompatibel. NEIN! Ich ordne mich diesem ollen Müll nicht unter. Nur wenn ich muss. Und wenn nicht, dann nicht. Aber das entscheide ich. Und nicht mein System. Wenn jetzt noch der Mac anfängt sich nach Windows zu richten nehm ich wieder Papier und Bleistift.

Mir ist Windows egal. Ich will heile Dateien erstellen, bekommen, versenden, verarbeiten oder verarbeiten lassen. In einer Welt, in der verschiedenste Systeme nunmal existieren, so wie verschiedene Autos und verschiedene Audiogeräte.

Wenn man mal ein paar uralte Sache außer acht lässt wie FAT16, dann ergibt sich aus den im Umlauf befindlichen Systemen ein kleinster gemeinsamer Nenner, mit dem ich ganz hervorragend Arbeiten kann. Das bisschen "Mehrwert" proprietärer Goodies ist es mir nicht wert, diese sichere Plattform zu verlassen.
...und als Anwender von gleich zwei "Randgruppenen-OSsen" ist mir die Portabilität von Daten einfach heilig.

GRuß, Ratti
 
Im Ernst: Ich "komme" ja selbst von der GUI, Shells habe ich zunächst widerwillig hingenommen, inzwischen habe ich festgestellt, daß es einfach schneller geht als mit der GUI. Und wenn ich meine Linux- und Darwin-Mailinglisten so verfolge, geht es vielen Leute so.

Da widerspreche ich Dir auch nicht. Wenn ich an einem Linux sitze mache ich auch sehr viel mit der Shell. Die kann ja auch angenehm sein. Und die name completion erleichtert die Arbeit ungemein. Auch mit Leerzeichen ;)

Tab-Taste hilft nicht, wenn ich mir über die Groß-und Kleinschreibung nicht sicher bin, oder wenn ich alle drei Zeichen TabTab drücken muß.

Dann musst Du eben Dispziplin üben und alles klein schreiben.

Oder, Extremfall: Wenn ich wie eben bei einer downgeloadeten mp3-Datei mit "!" und '"' und Spaces und ":"...vor lauter escaping den Namen kaum entschlüsseln kann. :)

Tja, was soll ich da sagen, ausser: Selber Schuld! Man lädt seine Musik bei Apple runter. Und nicht aus ner Tauschbörse. Verbrecher! ;)
 
ratti schrieb:
Koffer sind einfach ein zugenageltes Format. Auf anderen Kisten ist kein rankommen an den Inhalt - im Gegensatz z.B. zu einer "losen OTF-Datei.
OTF gibt es nicht als Koffer. Koffer sind entweder TrueTypes oder Bitmaps. Dfont-TrueTypes entsprechen exakt den TrueType-Koffern, außer, dass sie sich im Datenzweig befinden.
Dass man in Koffer im Finder reinkommt, ist eine Eigenschaft des Finders, nicht des Koffers (im OS-X-Finder gehts auch nicht mehr), der ist nämlich eigentlich auch nur eine Datei.
Ja, aber meine Frage war ja: Warum?
Was, wenn eine andere Plattform ebendiesen Suffix für etwas anderes benötigt, und was ist der Vorteil gegnüber einem "echten" Ordner (heisst: Ein als solcher erkennbarer)
Da man die Daten, die sich darin befinden eh nicht trennen sollte, ist es schöner, besser, übersichtlicher wenn der Ordner nicht einfach so zu öffnen ist.
Andere Plattformen kennen überhaupt keine Ordner mit Suffix (außer, AFAIR dem Archimedes; und NeXTStep, natürlich), insofern ist das Suffix dort völlig irrelevant. Nur ein Punkt im Namen.
und wieso denn dabei irgendwas "kaputt" gehen soll
Viele unterschiedliche Datentypen innerhalb einer Datei, die sich in Ermangelung einer übergeordneten Struktur gegenseitig - und, schlimmer noch, die Haupt-Daten - beeinflussen können.
(Zu Pagemaker dieses Zitat: https://www.macuser.de/forum/showpost.php?p=413642&postcount=9)
Führt aber alles am Thema vorbei. Mehrstreamige Dateisystem sind nicht CrossPlattform-kompatibeli
Deshalb gibt es ja auch die schönen ._-Dateien.
Womit wir wieder beim Thema wären;)
 
Zuletzt bearbeitet von einem Moderator:
sgmelin schrieb:
Andere Frage: Was stellt die andere Plattform über diese? Wieso sollte ich mich nach der anderen richten, oder diese nach mir? Wieso sind wir denn so von diesen Scheiss ext. abhängig?
Ich halte die Lösung von Apple für gut. Für den Anwender erscheint der Ordner als Datei und wenn er das Programm löschen oder kopieren will kann er es bedenkenlos tun (meistens). Die Idee dahinter ist gut. Dass Du damit auf deiner Linux oder DOSe nix anfangen kannst ist nicht Apples schuld. Es befinden sich eh Binaries in dem Ordner mit denen Du nix anfangen kannst.

In einem Postfach-Ordner befinden sich keine Obskuren PPC-Binaries, sondern stinknormale unixoide mbox-Files. Das ist es ja gerade, was mich so anpisst. Apple macht genau das, was andere Software auch tut: Sie verwendet Standard-mbox-Files und lagert alles proprietäre in eine externe, ggf. verzichtbare Index-Datei aus. Hurra! Super! Genu so geht das! ...und dann tun sie's in ein Package. Örgs. Warum?

Gut. Da kann man's rausholen. Bleibt die Sinnfrage, aber man kann was machen. Andere Geschichte:

Guck in meine Signatur. Da steht was von Schriftenverwaltungssoftware. Sehr gern würde ich die Software auch Mac OS X-Usern zugänglich machen. Und außerdem würde ich sie auch gerne selbst dazu verwenden, nicht nur meine "normalen" Fonts zu katalogisieren, sondern auch die auf dem Mac.

Pustekuchen! Das Dickicht aus Suitcases und Ressourceforks macht es einfach mit normalem Aufwand unmöglich, das zu integrieren. "Normale" Fonts gehen - Koffer gehen nicht.

Unterm Strich: Ich möchte nicht wissen, wieviel Software nicht angepasst wird, weil proprietäre Formate den Aufwand explodieren lassen. Das ist nicht schlecht für den Autor - das ist schlecht für die User. Die kriegen nämlich das Programm nicht.

Ich denke, das einer der schönen Seiten von OS X darin besteht, daß Tools und Programme (im Gegensatz zu OS 9) nur so aus dem Boden spriessen. In Massen. Das liegt daran, daß offene Technologien und offene Formate zur Verfügung stehen. Der portierte GCC. Die von iCal verwendeten ICS-Files. Die von Mail.app verwendeten mbox'en. Das ist gut für Apple, gut für die Anwender, und gut für alle OpenSourcler. Im Umkehreffekt ist der Kahlschlag eben sehr deutlich in Bereichen, wo nicht-offene oder nicht-portable Technologien eingesetzt wurden: Apple nimmt lieber Cocoa als X11 - OK, dann eben kein brauchbares OpenOffice für Maccianer. Hach! Sowas ärgert mich! Weil das Ende vom Lied nämlich ist, daß ich für 25 Arbeitsplätze Word-Lizenzen kaufen muß. Scheisse - das sind ja nun die allerletzten, die das Geld verdient hätten! Und genau deswegen offene und portable Technologien - weil sonst bloß der Monopolist verdient.

Puh. Musste raus.

Gruß, Ratti
 
._ut schrieb:
OTF gibt es nicht als Koffer. Koffer sind entweder TrueTypes oder Bitmaps. Dfont-TrueTypes entsprechen exakt den TrueType-Koffern, außer, dass sie sich im Datenzweig befinden.

Genau das sag ich ja. Koffer böse. Nicht weil etwas bestimmtes drin ist, sondern weil man nicht drankommt.
Aus dem gleichen Grund packt man seine Dateien mit zip und nicht mit ace, arc, ar, zoo, lha oder whatever. Ich wünschte mir, Apple hätte die Dateien einfach "lose" gelassen, mit den Daten in der Datafork. Na, eben so, wie es heute endlich ist.

._ut schrieb:
Dass man in Koffer im Finder reinkommt, ist eine Eigenschaft des Finders, nicht des Koffers (im OS-X-Finder gehts auch nicht mehr), der ist nämlich eigentlich auch nur eine Datei.

Schon klar. Ich benutze dafür übrigens den "D/A Mover" unter Classic, wenn ich Screenfonts umsortiere. Gibt's was besseres?

._ut schrieb:
Da man die Daten, die sich darin befinden eh nicht trennen sollte, ist es schöner, besser, übersichtlicher wenn der Ordner nicht einfach so zu öffnen ist.

Hmpf - das ist keine Begründung. Dann könnte man auch aus /System und /Library ein Package machen, oder besser gleich aus /. Oder man könnte alle Postfächer in einem Package zusammenfassen. Oder jeweils $HOME...

Außer der mbox kannst du übrigens alles wegwerfen, wenn z.B. die Indexreparatur auch nciht mehr hilft. Wird regeneriert (Natürlich sind die Stati dann futsch) - um so unverständlicher finde ich es, daß man sowas "versteckt". Bei mir auf dem System sieht es doch genau so aus:

ratti@ratti:~/.evolution/mail/local/Mail.sbd/Aktuell.sbd$ ls -1 Suse_Programming*
Suse_Programming
Suse_Programming.cmeta
Suse_Programming.ev-summary
Suse_Programming.ibex.index
Suse_Programming.ibex.index.data

ratti@ratti:~/.evolution/mail/local/Mail.sbd/Aktuell.sbd$ file -i Suse_Programming*
Suse_Programming: text/x-mail; charset=iso-8859-1
Suse_Programming.cmeta: application/octet-stream
Suse_Programming.ev-summary: application/octet-stream
Suse_Programming.ibex.index: application/octet-stream
Suse_Programming.ibex.index.data: application/octet-stream

Geht doch! :)


._ut schrieb:
Andere Plattformen kennen überhaupt keine Ordner mit Suffix (außer, AFAIR dem Archimedes; und NeXTStep, natürlich), insofern ist das Suffix dort völlig irrelevant. Nur ein Punkt im Namen.

Bei welchem System ist das denn nicht so? Ausser FAT16 mit seiner legendären char[8];char[3] - Deklaration fällt mir da keiner ein. Selbst unter Windows kannst du ja inzwischen sowas wie "x.LieblingsTextEditor" basteln. :)
Zumal ja in unixoiden Systemen von jeher sowas wie "archiv.tar.bz2.md5" üblich und sogar sinnvoll war.



(Word und Pagemaker ...)
._ut schrieb:
Viele unterschiedliche Datentypen innerhalb einer Datei, die sich in Ermangelung einer übergeordneten Struktur gegenseitig - und, schlimmer noch, die Haupt-Daten - beeinflussen können.

Mit anderen Worten: Gewachsene Struktur.
Das ist ja nachvollziehbar, nur hat das nichts mit mehren Streams im Filesystem zu tun.
Schön zu sehen ist das in Fontdateien. Da sind sehr viele Informationen doppelt und dreifach vorhanden, teils aus Performancegründen, teils weil es unterschiedliche Interpretation der Spezifikation gibt, teils weil man Mist gebaut hat und später Mistkompatibel bleiben mußte,... Tja, und dann steht in ein und derselben Datei hier, das "A" sei 500 em breit, und woanders steht, es sei 800 em breit. Und die armen Renderer und Konverter müssens ausbaden. :)
Dagegen hilft nur ein Kraut: Ausmisten.


._ut schrieb:

:))))

._ut schrieb:
Deshalb gibt es ja auch die schönen ._-Dateien.
Womit wir wieder beim Thema wären;)

Nur ist eben banane.eps ohne den Inhalt von ._banane.eps auf dem nächsten Rechner bloß ein grauer Kasten ohne Preview, und "HelveCOnBol" bloß eine 0-Byte-Datei. Hingegen ist das gleiche eps mit Tiff-Preview ein schönes, verwendbares Bild, und HelveticaCondensedBold.ttf eine wunderbare Fontdatei. Ginge es bloß um das grüne Etikett, wäre es mir egal.

Gruß, Ratti
 
Zuletzt bearbeitet von einem Moderator:
ratti schrieb:
Genau das sag ich ja. Koffer böse. Nicht weil etwas bestimmtes drin ist, sondern weil man nicht drankommt.
Man kommt doch ganz prima dran im Finder;)
Auf einer anderen Plattform kannst Du mit dem Inghalt eh nichts anfangen.
Schon klar. Ich benutze dafür übrigens den "D/A Mover" unter Classic, wenn ich Screenfonts umsortiere. Gibt's was besseres?
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).
Oder jeweils $HOME...
Das ist im Gegenteil dazu gedacht, Daten rein- und raus und drin rum zu bewegen.
Bei welchem System ist das denn nicht so?
*Ordner* mit Suffixen.
Nur ist eben banane.eps ohne den Inhalt von ._banane.eps auf dem nächsten Rechner bloß ein grauer Kasten ohne Preview, und "HelveCOnBol" bloß eine 0-Byte-Datei. Hingegen ist das gleiche eps mit Tiff-Preview ein schönes, verwendbares Bild, und HelveticaCondensedBold.ttf eine wunderbare Fontdatei. Ginge es bloß um das grüne Etikett, wäre es mir egal.
HelveCOnBol ist wohl ein Type1-Font. Mit dem kann man eh nur auf dem Mac was anfangen.
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.

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


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.
 
Zuletzt bearbeitet von einem Moderator:
Kleine Ergänzung wenns erlaubt ist: Type1-Fonts funktionieren auch unter Linux.

BadHorsie
 
Was mich an MacOS X.3.5 noch stört ist folgendes:

- Die auf iBook-Bildschirmen viel zu langen Menüleistenbefehle, die bei einigen Programmen regelmässig den AirPort Status, die Batterieanzeige und so weiter verdecken.
- Dass Sachen wie Spiele oder eine Modemverbindung unerklärlich langsamer sind als auf dem selben iBook mit MacOS 9!
- Viel zu viel Brushed Metal im ganzen System! Das GUI heisst AQUA und nicht METAL! motz
- So nette Dinge aus MacOS 9 wie die Anmeldung per Sprache könnten ruhig wieder den Weg ins MacOS X finden!
- Verständlichere Drucken-Dialoge, die jetzigen sind alles andere als verständlich und einfach! Wie man da rumklicken muss, um alle Einstellungen zu finden...
- Dinge wie Sherlock könnten auch mal wieder überarbeitet und vor allem an deutsche Inhalte angepasst werden! Komischweise nutze ich Sherlock so gut wie nie, weil ich die (übrig gebliebenen) Funktionen kaum benötige.

Das wäre vorläufig mal alles...
 
Ich sag nur SMB Performance. Lausig!
 
Seit 10.3.5 sind viele mögliche Auflösungen verschwunden. Unter anderem auch die für mich lebenswichtigen 1600x1024 bei 60 HZ (es werden nur noch 76 Hz angeboten).

Bisher konnte mir keiner helfen oder einen Tipp geben, wie/was ich machen muss um diese wieder "freizuschalten".

Gibt's hier keine "MAC-Profis"?

Und bitte keinen Link zu "Switchres". ich hab es ausprobiert, es gibt mind. 50 zusätzliche Auflösungen, aber die 1600x1024 bei 60 Hz sind nicht dabei. Ich könnte sie zwar selbst editieren, aber irgendwie sehe ich es auch nicht ein eine zusätzliche Shareware zu kaufen, nur weil Apple die Auflösung rausgepatched hat. Es kann doch nicht so schwer sein diese wieder freizuschalten oder?

Das Kopieren einer 10.3 com.apple.windowserver.plist in das 10.3.5 System hat leider auch nichts gebracht.
 
Also wenn ich ganz ehrlich bin, sind mir die genannten Fehler nicht aufgefallen.
Als "Normal User", der seine Textverarbeitung....Emails....usw. mit dem OS X bewerkstelligt, ist es ein stabiles Betriebssystem.
 
ChrisOnSki schrieb:
@93noddy
Ich hab auch kein Problem mit DOS, bei mir siegt momentan nur die Bequemlichkeit. Die Windows Kiste steht im Keller und mein Büro ist im Dachgeschoss...
Apropos Programme, hast Du das schonmal mit dem TotalCommander probiert? Der ist um einiges komfortabler und leistungsfähiger - vielleicht klappts damit ja auch bei Dir
nee hab ich noch nicht. Mach ich vielleicht mal. Bei mir ist die Dose der dienstrechner und das book der privatrechner. Die stehen als immer direkt nebeneinander ;-) da ist dos nicht sehr umständlich...
 
Zurück
Oben Unten