Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

[Terry L Ridder]

Hello Everyone;
 

Richard Gooch wrote:
>
<snip>
> 
> Hey! I don't have a SoundBlaster card! Let's chuck out drivers/sound,
> it's only used by bimbos anyway! You don't need a SB to do Real
> Work[tm]. I've seen that kind of attitude here before, and frankly I
> find it selfish.

Richard the above is clearly flamebait, which I was under the impression
we were trying to avoid.

<snip>

> >
> > I agree many inodes are a problem.
> > It is that problem that we do not care about.
> > There are various reasons for that attitude, which I will not go into.
> 
> Is it because you only care about your own pet ideas? Look, I'm not
> trying to force you to even use devfs, and if you do use it, I'm not
> trying to force you to use the new names. Please respect the
> substantial number of us who *do* see a need for it. You are welcome
> to configure it out of your kernels.

Well no, I have no "pet" ideas to care about. What I do care about
is the amount of time others and I have spent "courting" companies
and clients to use Linux. That those same companies have the ability
to be heard concerning their "suggestions" concerning Linux.

I have never posted anything stating that you were "forcing" me to do
anything. What I have posted are two simple statements which neither
Shawn Leas or Richard Gooch have answered.
I have repeated them below.

1. Companies, clients, and I like the current naming conventions,
and want to keep using the current naming conventions.

2. What advantage does dev_fs offer us over the present system?
Understand that we do not care about thousands & thousands of
inodes in /dev, we do not care about directory searches being slow.
So given that what are the advantages?

> 
> > > Not that I advocate devfs, but there is no denying it does sidestep
> > > the issue quite nicely, but then again, there may be other
> > > alternatives not so closely tied to the kernel.
> >
> > Alternatives are nice to have and alternatives need to be looked at.
> 
> Yeah, but the alternatives are arranged as one solution per
> problem. Devfs is arranged as one solution for many problems. And best
> of all, it's *optional*.

What is "wrong" with one solution per problem?

I have the impression that if anyone suggests that alternatives be
investigated that you view that as "opposing" dev_fs. Just as you are
requesting that I respect other views, I ask that you also respect
the views of the companies, clients, and myself.

General principles I go by:

1. The simplest solution is usually the best.
2. Resolve a single problem with the simplest solution.
3. Resolving many problems with one solution is generally not the
simplest
   solution.

> 
>                                 Regards,
> 
>                                         Richard....

-- 
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."

 When the toast is burnt
 and all the milk has turned
 and Captain Crunch is waving farewell
 when the Big One finds you
 may this song remind you that they 
 don't serve breakfast in hell
 ==Breakfast==Newsboys