> The fact that you can think of 100 different things Livingston should be
> directing their resource towards is the whole point. You have your
> priorities, other people have theirs, and because their priorities differ
> does not make them *wrong*, just in the minority, and thems the breaks,
> which is fine.
>
I never said they were wrong. I simply said that Livingston had their
priorities right.
> > We shouldn't. However, it's _EASIER_ to implement this as a local site-
> > specific solution. If you want to make it _EASY_ do it that way. Otherwise,
> > accept that it's hard and bill.
>
> Easier for whom? Certainly not for me. It has taken me over a week straight
> *with* consulting from William Bulley(one of the Merit engineers) to get
> Merit up on my system. Multiple logins were not the only reason for the
> switch, but hey, it would have been a lot easier to have had this support
> in Livingstons code, and not to have had to make the switch.
>
Hmmm... Well I don't know what was special about your system, but you
probably could have added this as a hack to the Livingston code in less
than a week of a consultant's time.
> > > > > Which costs money.
> > > > >
> > > > So? If it costs you more to code it than it does to let people log in
> > > > multiple times, ignore it. Otherwise, it pays for itself. Welcome to
> > > > business.
> > >
> > > Lessee, we can have the vendor code a solution, which they said they
> > > will, or we can have tens if not hundreds of ISP's spending resources
> > > individually on solutions. Thank god you aren't teaching a business class.
> > >
> > Lessee... If the vendor codes the solution, they need to code a solution
> > that provides for 100's if not 1000's of possible different authentication
> > policies at each of these little ISP's, few of which are actually going
> > to be sufficiently satisfied with any generic solution that comes out,
> > most of which are going to end up modifying the solution that Livingston
>
> Again, your view of the situation, not mine. Who said anything about a
> 100 different authentication policies, besides you?
>
Don't remember exactly who, but I believe it was actually "100's" rather
than "a hundred". However, if you just read what people have been asking
for, you will find at least 5 different ways have been discussed in terms
of WHAT to do when someone loggs in twice. Setting the limit is one problem.
Detecting excess or attempted excess is problem two. What you do afterwards
is problem 3. Problem 3 has a lot of differing opinions running around,
and depending on your andwer to number 3, it has an impact on what's
acceptable for 1 and 2.
> > provides as such anyway. Thank god you aren't teaching a class on how
> > to run an ISP.
>
> Gee I dunno, "Try to get base code to do what you want," vs. "hack your
> own, which your vendor is not going to support" seems to be a better
> method of running an ISP.
>
So, tell me, are you running _ALL_ Stock drivers on your UNIX systems?
You haven't added any third-party drivers to your NT systems (if you have
any). Etc. Let's face it, I doubt you could effectively run an ISP on
stock software.
> > > One of Livingston's biggest assets is that it creates easy to configure
> > > devices. I would imagine that support this functionality would be no
> > > different. Your theory about a support nightmare is just that: a dream.
> > >
> > HA! This is a complicated enough issue that there's no easy way to explain
> > all the tradeoffs in the different solutions that would have to be
> > implemented. Sorry, but the way Livingston made their boxes easy to
> > configure was by making them do a few things very well. RADIUS is not
> > easy to configure. It's easy to clone RADIUS entries and modify them
> > using a text editor if you know what you're doing. But Livingston has
> > not done anything to make RADIUS easy to "configure". Why do you think
> > this extension would be any different?
>
> RADIUS is *hard* to configure!? For whom?
>
Compare configuring a new user in RADIUS to adding a USER to the USER table
using the X version of PMCONSOLE. Which one is easier?
Now, take a local high school student who can debug a Windows box
blindfolded with one hand tied behind his back. Put him in front of
RADIUS and have him add a bunch of users without substantial training
or support. Any bets? I bet he could configure a PortMaster easier.
> > > > Not necessarily all of them, but I _KNOW_ (confirmed by Livingston) that
> > > > _ALL_ of their engineers are busy on higher priority projects.
> > > >
> > >
> > > Even after posting to the contrary, you have the misconception that I feel
> > > that this is the most important feature on earth. I don't. All I have
> > > ever said is that the request is valid, should be implemented, and those
> > > that are asking for it are not "lusers" by default.
> > >
> > And I have never disagreed with that. I have said that it should not get
> > a higher priority than it has. I have never called anyone a luser.
> > I suspect that your retort suffers from the same problem that my above
> > statements do. Read enough mail messages about the same topic and you
> > soon forget exactly who said exactly what.
>
> And if you would do the same, you would realize that I never accused you
> of calling people lusers.
>
Huh? This sentence doesn't make sense to me.
1. I was saying that after so many messages I couldn't remember
exactly who said exactly what.
2. I never called anyone a luser.
3. I never accused you of claiming that I called anyone a luser.
4. I've fallen and I can't get up. :-)
Owen