I'm not sure why you say this was flamebait. It you mean that I'm
implying that sound is not important, no, that is not what I mean. I
was using that as an example. Earlier this year there was a thread and
one person made the claim that people wanting some feature (it was
either video or sound) were "bimbos". This person's interests for
Linux were as a development environment and for embedded systems
(IIRC). Hence sound, video and such were things that didn't belong in
the kernel, because they weren't useful *to him*.
I have seen this kind of attitude on the list before, and I maintain
that it is selfish. The kernel is for all of us. Just because you
(generic you) don't feel the need for some feature, doesn't mean that
others shouldn't have it. If a feature proves quite popular, that
doesn't make the supporters "bimbos" (note I'm not claiming you have
this attitude).
> > > 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.
No, your pet ideas are >2GB files on 32 bit systems, logging FSes and
>16 SCSI discs. Did I forget something there?
You can't just say that because some companies may have some interest
in these things they aren't you pet ideas. The point is you care about
those issues. Not everyone else cares. Of the above, I'm only
interested in >16 SCSI discs. The other stuff I don't care about, but
neither will I oppose them. I'll not configure them into my kernels,
but that's my choice. You are welcome to implement those features and
have them included into the kernel, as far as I'm concerned.
Now I have users who feel they have a real need for devfs. Their views
are every bit as valid as your users.
> 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.
Your messages have been largely based on complaints about the new
naming scheme. You have been using this as a strong argument against
devfs (the other argument is that you don't need it). You raised the
spectacle of companies running away from Linux because they would hate
the new names. This strongly implies that the new names are being
forced upon them.
> 1. Companies, clients, and I like the current naming conventions,
> and want to keep using the current naming conventions.
Fine. Keep them.
> 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?
Read the FAQ. There are several advantages. If you don't think the
advantages are worth having, don't configure devfs into your
kernel. Maybe the gain on your systems is marginal. On other systems
there is a huge gain to having devfs.
> > > > 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?
Bloat. Hacks to the kernel, hacks to different places in
userspace. Overall a bigger, slower system. Complexity. Yes!
Complexity. Devfs keeps it small and keeps it in one
place. Maintainability. Scalability.
> 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.
You have used two arguments: the new SCSI names and that you don't
need it. You have not given a clear technical argument stating what is
wrong with it.
Your users need not be affected by devfs: don't enable it.
> General principles I go by:
>
> 1. The simplest solution is usually the best.
> 2. Resolve a single problem with the simplest solution.
Devfs *is* simple. It's a simple idea.
> 3. Resolving many problems with one solution is generally not the
> simplest solution.
There is no evidence that this is true. Furthermore, I'm sure there
would be many who disagree.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html