Subject: Re: OS X irony (and: OSXS10.1)
From: Lorenzo Perone (lopez.on.the.lists@yellowspace.net)
Date: Sat Oct 06 2001 - 13:33:24 EDT
At 21:48 Uhr -0400 04.10.2001, Rick Zeman wrote:
>After struggling to find a version of netatalk that would work with 10.0.4,
>I said the hell with it after many failures and went back to my trusty
>1.4b2+asun2.1.4 (compiled from source and run on OpenLinux 2.4, kernel
>2.2.18).
1.4b2+asun2.1.4_pre37_test
The biggest problem is the inconsistency of folder IDs, but this will be a good reason to try out 1.5p8 with cnid-support ;-). Have no panics anymore since 10.1. Had some spare ones with 10.0.4 (thanx, Apple).
Some small other problems occur when the rights of .AppleDoubles and content get messed up
(I use 2771 for dirs, 0660 for files and that usually works well.)
The following is for the topic "OS X irony":
I recently had the occasion to watch Mac OS X 10.1 Server's AFP features in action @ my favorite supplier.
I had in mind to eventually get OSX Server to replace netatalk for the most Macish-shares in our environment (and if benchmark comparisons hadn't been as depressing as they have, also as a php/mysql development server).
Here are some notes....(quick, informal 'showdown' ).
Speed (on a G3/266 DT with 225MB, original IDE drive, on 100BT Ethernet, cheap Realtek fast ethernet card):
- LinuxPPC / netatalk 1.4b2+asun2.1.4_pre37_test:
single file, 650 MB: ~8.5 MB/s
folder, 2200 items, 250MB: ~ 3.5 MB/s
- OS X Server 10.1:
single file, 650 MB: ~ 3.5 MB/s
folder, 2200 items , 250MB: ~ 2.5 MB/s
(Note: using a newer G4 probably will saturate ethernet also with OSX)
(Note: the beta OSX driver for the realtek card could be involved)
Names / Encoding:
- Unicode is great. OS X Server 10.1 correctly uses samba codepages (10.0.4 didn't) for a good cross-platform usability, and long names usable in OS X, OS 9 (shortened as usual on HFS+ volumes) and Win clients.
- no equivalents to the -mswindows option: with Mac clients, you can still use characters that are illegal on Windows, e.g. the question mark, so Windows truncates those names and cannot access them
Filesystem metadata, folder IDs:
- as expected, no .AppleDouble-"clutter". Instead, the other clutter: the 'now usual' .DS_Store, and the good old TheFindByContentFolder (visible? why?).
- Icons and all the rest work seemlessly,
- didn't try Quark... (have not)
Searching:
- incredible: both Sherlock 1 and 2 are even more _unusable_ in name searches when connected to OSXS 10.1 than with netatalk (Apple, what did ya do here??!)
- irony: Windows clients find files by name lightning fast on the OSXS-Samba ?¿-!
Configurability:
- OSXS 10.1 could be set up by completely inexperienced admins in minutes
- Forget the COMFORT of afpd.conf, AppleVolumes.default, and all the rest!
Unless there will appear an 'advanced' administration tool, you'll feel like in a cage here.
Overall impression:
- My impression is that Mac-centric graphics companies... are possibly addressed with OSXS 10.1.
(I didn't have a _close_ look at the printing services, but LW and LPR-color RIP worked like a charm with it - and this might be also a good reason for the print sector).
- Kudos, Apple: you just axed a few jobs (now also photoshop-only users can administer a fileserver).... ;-!
- Not for me (web development, mixed clients environment).
>From my personal perspective OSXS solution loses in the price/performance run with linux/intel boxes - but mainly for the hardware: as of now, Macs are totally out of competition from that point of view and I sincerely hope this will change radically soon (or OSX gets 'legalized for intel?')!
That is to say:
please KEEP IT GOING, Netatalk Development group...! ;-)
- I hope to get that CNID-stuff productive soon (thanx to Karen Swanberg for the cross-post).
Another nice thing of netatalk is that we can still dream of features... without depending on a $ompany for them to get reality (because it's... Open).
Dreams: ... a fast search... a nice, reliable GUI ssh remote admin tool... native HFS+ support ()....
:-)
-LP
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:54 EDT