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

[Bill Davidsen <davidsen@tmr.com>]

Douglas McNaught wrote:

>Bill Davidsen <davidsen@tmr.com> 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@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979