🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.comp.sys.next
Article #737

Re: NextStep vs. BeOS (war: L. A. Times: Jobs wieder bei Apple!?)

#737
From: Bernd Rutzmoser
Date: Thu, 02 Jan 1997 00:00
152 lines
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-mail
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>

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