Article View: de.comp.sys.next
Article #737Re: NextStep vs. BeOS (war: L. A. Times: Jobs wieder bei Apple!?)
From: Bernd Rutzmoser
Date: Thu, 02 Jan 1997 00:00
Date: Thu, 02 Jan 1997 00:00
152 lines
9058 bytes
9058 bytes
Ich entschuldige mich jetzt schon mal f�r dieses Megaposting, vielleicht lest ihr's aber trotzdem. :-) In article <we6iv5i222y.fsf@Fichte.mpibpc.gwdg.de>, Stephan Trebels <strebel2@fichte.mpibpc.gwdg.de> wrote: > > es ist in beiden faellen moeglich, die identische oberflaeche > aufrechtzuerhalten. kein user wuerde den unterschied bemerken. nur, > dass z.b. die netzprotokolle keine weiteren dateiattribute kennen (ein > "ftp-get" einer mac datei ist zum scheitern verurteilt, es sei denn, > sie ist verpackt, oder man hat angepasste ftp server und clients auf > beiden seiten, wo bleibt da die offene welt?) Hmmm...ASCII-Dateien sind genauso 'offen' �bertragbar wie �berall. Das Data- und Resource-Fork Problem hat man eh nur bei Programmen. Und damit haben sich die Leute soweit eigentlich ziemlich gut damitz abgefunden. Vielleicht liegt das daran, da� alle FTP-Programme die Entpackerei von selbst weiterdeligieren. Um es mal �berspitzt auszudr�cken: Die Benutzerunfreundlichkeit anderer Betriebssysteme ist kein Alibi um andere Systeme auf diesen Level hinunterzudr�cken. Man kann aber mit ein paar Tricks und Au�enrumprogrammiererei sowas geschickt umgehen. > > ich will benutzerfreundlichkeit _und_ administratorfreundlichkeit. Da hast Du durchaus recht, da� man sich mehr Administratorfreundlichkeit beim Mac w�nschen w�rde. Diese Administratorfreundlichkeit allerdings auf dem R�cken derer auszutragen, die damit arbeiten m�ssen, ist IMHO der falsche Ansatz. Es gibt aber mittlerweile viele viele Tools, die Dir das Leben erleichtern. Au�erdem ist es sicherlich sehr viel weniger Zeitaufwendig ein AppleShare-Netz zu administrieren, als ein Unix-Netz. Wenn's heterogen wird, bleibt der Aufwand ziemlich gleich. > > > Die unter uns, die Type und Creator �ndern wollen, wissen auch, wie > > (ResEdit, FileBuddy). > > alle unter _uns_? alle, die es mal brauchen? und sie wissen auch, wo > sie es her kriegen? meine erfahrung sieht leider anders aus. Nein, aber alle, die es wissen, wie es geht. Denen, die es brauchen w�rde ich h�chstens FileBuddy in die Hand geben. Allerdings kannst Du IMHO davon ausgehen, da� Ottonormaluser kein gro�es interesse hat, irgendwelche "LowLevel"-Dinge zu tun, die haben ganz einfach Angst davor. Also besteht auch kein Grund diese Art von Benutzerfreundlichkeit auf dem Kompatibilit�t-zu-Allem-Altar zu opfern. > > im allgemeinen wird man irgendwann von irgendjemanden in sein buero > gerufen, der gerade ziemlich flucht, und natuerlich die utils _nicht_ > auf der platte hat, ja sie wahrscheinlich fast nie brauchte und deshalb... Wenn Du der Admin bist, dann wirst Du sie wohl haben. :-) > > na gut, dann geh ich eben wieder zurueck in mein buero, und hole die > diskette und sage dem user dann, "das sollst du aber bitte nicht so > machen, weil es sonst nicht mehr benutzerfreundlich ist". bei einer > extension brauche ich definitiv keine utilities. Wenn Du die Datei von dem Programm aus �ffnest, von dem aus Du es �ffnen willst auch nicht. Au�erdem geht es noch einfacher: Mach Dir ein Alias von Deinem Lieblingsprogramm, leg' das Alias auf den Schreibtisch und zieh' das gew�nschte Dokument einfach drauf und voila! Wenn Du es dann sicherst, wird normalerweise der Creator angepasst. > > > Sicherlich w�re es nett, wenn man im Sichern-Dialog auch noch > > wahlweise die Applikation ausw�hlen k�nnte, mit der sie das n�chste > > Mal ge�ffnet werden soll oder wenn man best. Types und/oder Creators > > andere Defaultprogramme zuordnen k�nnte (sprich TeachText Dateien > > immer mit BBEdit �ffnen). Uber solche Erweiterungen la� ich mit mir > > diskutieren. :-) > > und wen freut nicht die meldung: die app zum oeffnen der datei bla > wurde nicht gefunden, moechten sie teachtext benutzen? ;-( ich sehe > nicht ein, warum man die metapher "datei" verlassen muss, ohne einen > gewinn davon zu haben. Versteh' ich jetzt nicht. Wer verl��t wen? :-} > > > Niemand wird davon abgehalten, irgendwelche - ihm/ihr vielsagende - > > Endungen an die Dateinamen anzuh�ngen. Man kann das machen MUSS aber > > nicht. > > es ist fuer die oberflaeche _identisch_, ob man dateien, mal extrem > gedacht, hallo.adobeillustrator.eps intern benennt, oder ob man die > datei hallo nennt mit creator=adobeillustrator und type=eps. Und woher wei� das Betriebssystem, da� Du jetzt deine Datei "hallo.adobeillustrator.eps" nennen willst oder nur "hallo" und "adobeillustrator.eps" nur ein Anh�ngsel ist? (In ersterem Fall w�re der Name dann n�mlich "hallo.adobeillustrator.eps.adobeillustrator.eps".) Es ist nicht ganz so einfach... > > mir geht es nur um die interne darstellung einer datei, und die ist > fuers look & feel irrelevant. Wie gerade angef�hrt nicht ganz. > ich will die _moeglichkeit_ haben, dateien mit file-utils zu > bearbeiten, und die wesentlichen attibute aenderbar zu behalten. ich > will, dass ftp funktioniert, und ... das bitte unter beachtung von > standards, wie unix und posix. Es gibt nur 'geht' und 'geht nicht'. Da� es geht, macht jeder anders. Unix und Posix m�gen die Standards auf dem Internet sein. Das hei�t aber nocht lange nicht, da� sie benutzerfreundlich sind. Das Unix-Anh�nger davon nicht allzuviel halten bzw. das geradezu als st�rend empfinden wei� ich... ;-) > > > ...aber da� Du bei Unix keinen "/" verwenden darfst, nicht? ;-) Es > > gibt halt mal ein Zeichen, da� Betriebssystemintern als > > Hierarchietrenner dienen mu�, bei Unix ist das der / beim Mac der : > > und bei DOS der \. > > naja, auch das ist kosmetik. man koennte das bei der "anzeige" > beliebig erzeugen. unix kann sicher kein / im namen, aber warum das > die oberflaeche nicht koennen soll, ist mir unklar. man koennte > z.b. \/ und \\ im namen entsprechend darstellen, oder dateinamen in > unicode erlauben, oder... vergi� aber nicht, da� wir uns im Internet auf sehr d�nnem (7-Bit-ASCII-) Eis bewgen, da gibt's kein Unicode. Und ob es wirklich sinnvoll ist, Dateinamen zu parsen la�' ich mal dahingestellt. Ich denke, da� man sehrwohl ohne / und : in Dateinamen leben kann. Au�erdem hast Du oben Offenheit beschworen. Es w�rde sicherlich ganz toll aussehen, wenn Du auf den Oberfl�chen mit den tollsten Zeichen hast, aber dann, wenn Du was ftp-en willst, auf einmal Dateinamen mit // und irgendwelchen 1-iso-8851-blabla angezeigt bekommst. Ist das benutzerfreundlich? Und das kannst Du nicht mehr verstecken, es sei denn, das Internet wird auf Unicode umgstellt. Und da werden noch viele Bits �ber die Leitungen tr�pflen. (Btw.: Schau Dir mal mit einem �lteren Norton Commander eine WIN95 Platte an, dann siehst Du, was passiert, wenn man 256 Zeichen lange Dateien auf xxxxxxxx.yyy ummappt. Leserlich, wirklich sehr leserlich. Und so offen und leicht zu administrieren ;-) ) > p.s. ich denke, dass man alles, was den Mac ausmacht, auf einem Unix > Unterbau implementieren kann, das duerfte bei Regierungsauftraegen in > den USA auch wichtig sein... Kann man sicherlich, aber wie gesagt: Wenn Du an der Benutzerfreundlichkeit anf�ngst, Kompromisse einzugehen, kannst Du Apple vergessen. Wenn Du Dich mal zur�ckerinnerst: Es gab mal Rechner (nicht von Apple), die waren 98% IBM- kompatibel (z.B. Victor). Alle die, nur ann�hernd kompatibel waren, sind tot. Apple war's nicht und hat �berlebt, weil sie keine Kompromisse eingegangen sind. So, jetzt reicht's... :-) Bernd -- Bernd Rutzmoser H�rwarthstrasse 4 80804 M�nchen Germany Tel.: +49/89/361 50 94 email: eBerndR@aol.com
Technical Details
Message-ID:
<eBerndR-ya023180000201971019460001@news.apple.de>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<59hif9$22u@brachio.zrz.TU-Berlin.DE> <59hu7c$224@colossus.nexttoyou.de> <59jdjd$9u5@brachio.zrz.TU-Berlin.DE> <59jlgl$laj@white.koehntopp.de> <59jv7n$m5g@brachio.zrz.TU-Berlin.DE> <59m937$in@tallowcross.uni-frankfurt.de> <19961223234014638858 <59ovl7$dip@brachio.zrz.TU-Berlin.DE> <5a44d8$em@tallowcross.uni-frankfurt.de> <we6loahl3yb.fsf@Fichte.mpibpc.gwdg.de> <eBerndR-ya023180003012961115030001@news.apple.de> <we6iv5i222y.fsf@Fichte.mpibpc.gwdg.de>Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII X-Google-Thread: 1066a2,295e70ce20088e4f X-Google-Attributes: gid1066a2,public X-Google-Thread: 101903,295e70ce20088e4f X-Google-Attributes: gid101903,public X-Google-Thread: 10cd83,295e70ce20088e4f X-Google-Attributes: gid10cd83,public X-Google-Thread: f54b7,134122f67c98ae9a X-Google-Attributes: gidf54b7,public From: eBerndR@aol.com (Bernd Rutzmoser) Subject: Re: NextStep vs. BeOS (war: L. A. Times: Jobs wieder bei Apple!?) Date: 1997/01/02 Message-ID: <eBerndR-ya023180000201971019460001@news.apple.de> X-Deja-AN: 207351849 distribution: world references: <59hif9$22u@brachio.zrz.TU-Berlin.DE> <59hu7c$224@colossus.nexttoyou.de> <59jdjd$9u5@brachio.zrz.TU-Berlin.DE> <59jlgl$laj@white.koehntopp.de> <59jv7n$m5g@brachio.zrz.TU-Berlin.DE> <59m937$in@tallowcross.uni-frankfurt.de> <19961223234014638858 <59ovl7$dip@brachio.zrz.TU-Berlin.DE> <5a44d8$em@tallowcross.uni-frankfurt.de> <we6loahl3yb.fsf@Fichte.mpibpc.gwdg.de> <eBerndR-ya023180003012961115030001@news.apple.de> <we6iv5i222y.fsf@Fichte.mpibpc.gwdg.de> content-type: text/plain; charset=ISO-8859-1 organization: Customer of EUnet Germany; Info: info@Germany.EU.net mime-version: 1.0 newsgroups: de.comp.sys.next,maus.sys.mac,de.comp.sys.mac,fido.ger.mac