Re: RFC: Starting a stable kernel series off the 2.6 kernel

From: Bill Davidsen
Date: Sun Dec 11 2005 - 22:25:17 EST


Douglas McNaught wrote:

Bill Davidsen <davidsen@xxxxxxx> writes:



Rob Landley wrote:



Re-raising the same objections over and over again when they've
already been aired, considered, and rejections is called "whining".



Repeating the same information over and over until it sinks in is
called "rote learning." The question is not if cryptoloop is perfect,
every crypto seems to fail eventually, recently md5 was cracked,
etc. But people have used cryptoloop now, and removing it from the
kernel will lock them out of their own data, or prevent them from
moving forward. There's no replacement for cryptoloop, so I can't just
reconfigure X and still read my 147 DVDs full of business data, or
access the current data on 34 laptops around the country.



Bill, I still don't think your complaints are justified.


I never expected anyone to admit they were wrong, so that doesn't surprise me...

You're only "locked out of your own data" if you knowingly upgrade to
a kernel that doesn't support cryptoloop. Nobody's forcing you to do
that.


Are you endorsing ignoring security fixes? Of course you're forced to if you are trying to be secure. If there were a replacement for cryptoloop that wouldn't be a problem. But saying that CL must go because it isn't perfect is like saying that you shouldn't lock your window because someone could still break it and get in.

The kernel developers owe *nothing* to J. Random User. They are
either doing what they do for their own reasons (the "fun" of it), or
being paid by an organization with specific objectives (even if, in
Linus' case, the objective is just "make the best kernel possible,
based on your judgement and that of people you trust").



A little later you say that most of the developers are paid for working on Linux. Just who is the ultimate source of that funding if not the random user? Almost all of it comes from people who lack the ability to maintain the kernel, one way or the other. If kernel features are left to the vendors you encourage fragmentation, and all you have to do is look at BSD to see what a success that is.

What Linux has going over Windows is choice... the ability to configure WITHOUT having to depend on the judgement of someone else. And when that judgement is to remove a feature which has no replacement, in which uses have made an investment, then the choice is gone.

That said, of course none of them want to break things unnecessarily.
But they make technical decisions, with the goal of having the best
kernel, that do sometimes have painful consequences. You're free, of
course, to disagree with those decisions and maintain your own kernel.



Why waste electrons on statments like that. Yes, I could do that, but the average users can't, and after maintaining GECOS, and MULTICS, and supporting BSD installations and writing a realtime control o/s, I certainly don't have the slightest interest in spending my time doing that. Effectively anything not in a kernel.org kernel is going to die.

They don't owe you security fixes either. Sorry, but that's the way
it is. We're all lucky that they take security very seriously and
respond quickly to problems.



In most cases CL is not expected to protect against goverment agencies
but rather stolen laptops in airports (yes the pros have added MacOS
and Linux to their business model) or the occasional lost DVD in the
mail. Removing CL is not a hell of a lot better morally than these
viruses which encrypt your data and then hold it for ransom, with the
price being doing without security fixes in future kernels.



That last sentence is crap.

You're free to backport security fixes to cryptoloop-supporting
kernels forever, or pay someone to do so. Or maintain a cryptoloop
patch against current kernels, or pay someone to do so. Or write a
converter for cryptoloop data to whatever's currently in the kernel,
or pay someone to do so.


Given that CL has minimal (essentially no) maintenence cost, I wish

the ivory tower developers could understand that real people have
invested real money in it, and real data in the technology. Since
there is no alternative solution offered, CL is far better than no
crypto at all, and I wish there were a few more developers who had
experience working in the real word.



If you include a crypto solution in the mainstream kernel, you're in
some sense endorsing its security. If that solution has known
weaknesses, I can understand wanting to either fix it or rip it out.
Crypto is hard enough to get right as it is.

Your "ivory tower" statement is really condescending. Linux is way
past the stage where college students were the main contributors (if
it ever was so after Linus graduated). and a great majority of
developers now are paid to work on the kernel. There are probably
very few of them that don't have at least a little sysadmin
experience.


I wonder... running servers is relatively easy, supporting end user systems (admin, not help desk) is hard.

If you've invested money and put important data in a system, and you
haven't contracted with anyone to support that system, supply security
fixes, and make sure it does what you want it to do, who's the fool?


The advantage of using dynamic systems rather than locking in with something like RHEL was attractive. Trusting a third party was not.

Basically, you're complaining about something you get *for free* that
represents millions of hours of work, because it doesn't work quite
the way you want it to, when you have perfect freedom to make it meet
your needs by putting in your own time, effort and/or money.


Most users have no such ability, but people jumped abord Linux when 2.6.0 came out, and it WAS called a "new stable release." Redefining what stable means after people have used the software is not something I would feel comfortable doing.

--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/