On 11/19/01 7:07 PM, "gabriel rosenkoetter" <gr@eclipsed.net> wrote:

> On Mon, Nov 19, 2001 at 05:54:21PM -0500, Kadari Mayson wrote:
>> Well, my point was that you would be installing SAMBA on the server side
>> (NetBSD box), so this is still relevant.  If you have OS X, then the upgrade
>> to 10.1 and 10.1.1 are free.
> 
> Sorry if this comes off as abrasive, but you are COMPLETELY missing
> the point here. This is the port-mac68k mailing list. Many people
> must support Macintosh models that don't have a PowerPC, much less a
> G3. For these people, using MacOS X, much less some specific version
> of it, is completely impossible. "Use Samba" is a (monetarily)
> losing suggestion for these people even if there's a free MacOS
> 8/9 client involved: they still have to maintain software on every
> client instead of just on the server and, yes, that really does cost
> real money.
> 

No, I know what you're saying.  But we live in a service oriented
industrial/capitalistic society, nothing is ever completely free.  Somewhere
along the line, you are going to have to pay for something.  Netatalk may be
fine for some things, especially if you are administering a /small/ home
office type environment with /all/ Macs using OS 7.x to 9.x, but it does not
integrate well into later environments due to speed issues and certain other
limitations like the 32 character thing.  Never mind that you are using
Netatalk on NetBSD's ffs which is a "flat" filesystem which completely
obliterates Classic and Carbon PEF applications' resource forks (but this is
also a ffs limitation), you can only store data files, no applications that
are not Mac OS X Cocoa or Carbon Mach-O "bundles" will even be able to
housed on that volume. I think the whole point of the discussion was about
"how do I fix Netatalk so it can export filenames that are greater than 32
characters" and the answer is: "you can't".  If you are only storing data
files for backup purposes, in a very small environment, then it's ok.  But
if you're trying to do anything more demanding then Netatalk is not your
answer.


>> Netatalk is HORRIBLY slow compared to SMB anyway, it's just a terribly
>> kludgy hack and completely unnecessary, after you use it, you'll understand.
> 
> ... and this bit is just ludicrously self-indulgent. What about this
> thread gave you to believe that anyone recommending it had not used
> Netatalk before?
> 

I was just pointing out alternate solutions to Netatalk.  People were asking
about filename limitations, and the reality is, that issue will probably
never be addressed in Netatalk unless some developers sequestered themselves
in a room and vowed not to come out until they get something banged out
something that they could live with.

> Fwiw, I found Netatalk (before any ASUN version existed) on an i386
> (literally) machine running Debian Linux (this is all about four
> years ago) to be significantly faster when accessing it from a Mac
> Quadra than when accessing a similarly-sized shared partition living
> on a PowerMac 6100/66 running Mac OS 7.5ish.
> 

And it was great for what it was /four years ago/.  Back then, filenames
mostly adhered to the DOS 8.3 standard.  Today, we live in a world where
filenames can be up to 255 unicode chars long, and often are (well maybe not
255 unicode chars) greater than 32 characters.

> I don't think I've ever actually suggested that Netatalk should
> magically make the filename-length problem go away. I've been
> suggesting all along just that it make it easier for the
> administrator to deal with. I think plenty of people would find
> Netatalk totally sufficient for their needs, and this small addition
> would make them much happier.
> 

But it's not a "small addition".  How old is Netatalk?  6-7 years old?  If
it was that easy, it would certainly have been added by now.

Well, I was trying to find the exact reference(s), but I couldn't find them
(didn't search very long anyway).  But the Netatalk developers have said
many many times in the past that it's not that easy to implement long
filename support, and they also hinted that it might be in Netatalk 3.0, but
it's a /long/ way off (I found that in the mailing list just now).

I guess the bottom line is use what you're most comfortable with.  For me
it's Samba.

>> Apple is attempting to phase out AFP anyway, but they have not introduced a
>> successor.
> 
> Sure they have, and it's called NFS. That's why they're shipping
> Mac OS X with decent NFS support these days and gradually doing
> backwards support only for AppleTalkIP stuff. They (very sanely)
> want to get rid of the ridiculously talky AppleTalk networking.
> 

No, AFP's successor is definitely not NFS.  Not today at any rate, and I
don't think it will ever be.  Certainly not in it's current state. Sure it
works, but it's not for everybody, and I'd wager you'd be hard pressed to
find people who actually do use it even if they know what they're doing.
NFS in Mac OS X, to get it working efficiently in OS X, while not strictly
necessary, requires a fair amount of knowledge in using NetInfo Manager
which is not very well documented.

Like I said, you really have to know what you are doing to get that working,
unlike OS X's AFP or SMB implementation.  Mounting NFS shares is one thing,
serving it is a whole different area.
 
> But what Apple is or isn't supporting today is totally not the
> point. There are plenty of people subscribed to this list specifically
> because they have macs that Apple doesn't care about any more and
> they would rather pull some of those up as real Unix servers than
> drop the money on Apple's shiny new boxes. To turn a cold shoulder
> to them is ridiculous, cruel, and wholly inappropriate.

That's why I use my Q800 as a file/web server.  I paid $4500 for it in 1993,
and I'm going to use it every day until it melts.  I am trying to maximize
the performance, and for my money, Netatalk just doesn't cut it even if I
were using only OS 9, which I'm not.  I have PCs on my home network (even
though my Mac OS X boxes are my primary work stations) and it's silly to
have both Netatalk and Samba running doing the same exact thing but with two
separate protocols.

./km