The reason we can't continue using Samba
hwimmer at bakerref.com
Thu Oct 5 21:56:22 GMT 2000
man what a dick. i want it done as bad as he does. it is freeware and if
he wants to make a sizeable contribution to the samba team that may be a
different story. however, until then we have to wait and see. if samba
isnt ready when we have to migrate from netware then win2000 will have to go
in. i hope it doesnt because i am a real samba fan. keep up the good work
team, i understand the shit you deal with and greatly appreciate it....
----- Original Message -----
From: "Joe Rhett" <jrhett at isite.net>
To: "Jeremy Allison" <jeremy at valinux.com>
Cc: "Gerald Carter" <gcarter at valinux.com>; <samba-ntdom at us4.samba.org>
Sent: Thursday, October 05, 2000 4:37 PM
Subject: Re: The reason we can't continue using Samba
> > > Because we're not using it as a fileserver. If I just needed File &
> > > 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
> 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
> I mean.
> > > AND if I have to implement a superstructure of NT servers, then why
> > > 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
> > > 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
> > > don't feel that the community will offer the Samba team up as a
> > > if you're a month or even a quarter late. The intention is to know
> > > _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
> 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 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
> > > isn't even intending to _attempt_ to be where it needs to be within
> > > 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",
> 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
> > > 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
> 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/
More information about the samba-ntdom