The reason we can't continue using Samba

[Joe Rhett]

> > Because we're not using it as a fileserver. If I just needed File & Print,
> > I can do that with NFS/LPD. 
 
> For Windows clients ? Good luck :-).
 
File locking on NFS clients for Windows works properly. Printing using LPD
clients for NT works properly. Samba hasn't solved either problem, and has
no listed schedule for solving either.

But NFS will never provide domain services, so it isn't a solution. And why
are we talking about this? Another useless, irrelevant comment.

> > Are you really so dense as to believe that
> > maintaining a hundred NT/98 workstations only requires file & print?
> 
> No, it requires an authentication infrastructure. Which Samba
> does not yet provide. I know you want it to - so do I. But wishes
> don't make code.

I didn't talk about wants versus code. I said that we needed a timeline.
You asked what I needed besides file & print. This random outake it 100%
your useless and irrelevent sidetrack on "what is necessary". You know what
I mean.

> > AND if I have to implement a superstructure of NT servers, then why don't I
> > just put the disk space on them? 
> 
> Because they are less reliable, and are more expensive.
 
Thank you. But I CAN'T do it with Samba without PDC support.

> > Therefore Samba (current) provides NOTHING
> > that can assist me with our current environment.
> 
> Then don't use it. There is no "Samba mafia" out there

Are you ever going to respond to the stated issue, or must you always take
single sentences out of context for irrelevant and useless responses?

> > Not being confident of what you mean by the first 3 words, will this allow
> > workstations to log in and retrieve their profiles?
> 
> This is nothing to do with profile support. It is a method
> of allowing UNIX user/group enumeration (which is what Samba
> uses).

So how is UNIX user enumeration going to provide anything of use to the
Windows desktops? Why am I asking this question -- the original question
was quite clear -- what does this mean to me?

> > No, it isn't. You can ignore my points and be dense all you like. I really
> > don't feel that the community will offer the Samba team up as a sacrifice
> > if you're a month or even a quarter late. The intention is to know when you
> > _intend_ to complete it.
> 
> That's not a question that has a meaningful answer. We *intend* to
> complete it "when it works" and that will be "as soon as possible".
> Does that help - no - of course not. Stop asking questions for which
> there are no meaningful answers.
> Keep downloading the "stable" code branches, and when it does what
> you need, then deploy.
 
Ah. Jeremey, some of us work at companies with a few more than 2 systems.
We have infrastructure to work around. We have hundreds of systems to
update, and we need to develop plans to implement an upgrade of this
magnitude. 

Do I really need to say this? You're playing dense again when the reality
of why someone would prefer to have a projected date to work with is quite,
quite clear.

> > Nobody bases their strategy on the specific date. But it gives us some
> > reasonable measure to determine if we must find another strategy, if Samba
> > isn't even intending to _attempt_ to be where it needs to be within our
> > timelines.
> 
> We are *attempting* to complete as soon as possible. Keep checking 
> the code to see how far we are along.
 
What the hell is asap? When someone says asap to me, I hear "November", but
Gerald's comments clearly indicate "maybe March". Those are two different
orders of magnitude. And given the general crawl of Samba development, I
would interpret "asap" to mean November, 2001. I'm used to interpret Sun &
Microsoft's "release schedules", to interpret "asap" in terms of Samba is
to assume 1-2 years unless you say otherwise.

> > But if you say that you can't possibly make it before September, then we
> > start implementing another strategy NOW ...
> 
> I'm not making your decisions for you. *YOU* have to decide
> when it meets your needs. *YOU* need to monitor the development
> process, and watch the announcements - and test if it meets
> your needs.
 
You're asking for us to wait until the very last minute to find another
plan and implement that instead. My god, you really have no useful
production experience do you? Have you ever worked on an upgrade path that
took more than a day?

> Yes, it's easy to rely on these to pretend to have a strategy,
> most IS departments do so - "Sorry boss, we can't deploy this
> month, vendor X who promised they'd have product Y ready has
> slipped by 6 months - not *my* fault".
 
It's not pretend. Your arrogance doesn't change the fact that it takes
roughly a year to deploy a whole new operating system worldwide in any
decent-sized company. The project plan for Win2K deployment at Intel is
volumes in size, for example. Having some sort of basis for a deployment
plan is critical.

Just because you've never had a strategy doesn't mean that the rest of the
world can work that way. But then if you had a strategy, you'd have a 
timeline and we wouldn't have to do this.

Jeremy, it's been 5 years since I got sick of your idiotic comments about
real problems I was reporting and I'm flat out amazed that you haven't
grown up the slightest in the intervening time period. Some of us have real
projects, real jobs, real schedules.

You've always ignored anything you didn't like or couldn't personally
understand, and that's why everyone's contributions to Samba main were
ignored for years and years. Samba would have had PDC support in 1997 if
you hadn't ignored everything that those of us who work in real jobs were
providing back to the team. Your attitude was certainly why I stopped
sending in sniffer traces displaying how Samba differed and why certain
errors were occuring.

-- 
Joe Rhett                                         Chief Technology Officer
JRhett at ISite.Net                                      ISite Services, Inc.

PGP keys and contact information:          http://www.noc.isite.net/Staff/