LWN: Comments on "Another look at the new development model"

My problem with this

smamunr — Tue, 28 Dec 2004 07:19:30 +0000

Hey the kind of issues you are talking about is real but not cheap. you
have to hire programmers who will keep track of trivial changes and will
incorporate those trivial changes and security changes. Unfortunately
there are certain type of bugs exists (may be a security threat) which
need quite a good amount of change.
There could be another option. That is hire some expart who will plan and
design migration plan to new kernel. Then I will suggest you upgrade your
system every six months otherwise take risk of becoming obsolete. Come'on
it is free as in beer, why the developer will take the pain when you are
not ready to consider it.
Even proprietary systems are not painless. Check MS XP-SP2? How many ways
it is disruptive. Life is like that!

In a few words

philips — Thu, 05 Aug 2004 06:47:05 +0000

In a few words: Unleash The Power of BitKeeper.

I cannot find better explanation to this happening.

Stable branch still needed

giraffedata — Fri, 30 Jul 2004 22:02:35 +0000

There is still a huge need for a stable/stabilizing branch of the Linux kernel, which is not provided in this system. If Linus doesn't want to provide or endorse one, I expect someone else will. Probably major distributions.

I'm talking about a branch for people who are using a computer to do a certain thing and as long as that thing doesn't change, they don't need new features. They do, however, need bug fixes and other minor adjustments. For these people, no matter how much a certain piece of code has stabilized in mm, it is too big a risk to add it to their system when they aren't even going to use it.

Also, removing features can only hurt these people.

I envision an expanded form of subtrees (which already exist to a small degree), wherein someone distributes 2.6.7.1, 2.6.7.2, etc. Assuming such a distributor starts up the next stabilizing series before 2.6.7 is two years old, we will avoid the pressure to make destabilizing changes to the stable series, that killed the even/odd system we had going.

The only problem left...

fdesloges — Fri, 30 Jul 2004 13:04:36 +0000

The only problem left with this continuum of changes is that developpers in generals (ISVs come to mind) are expecting API not to change in 2.6 and new features and API to be introduced all together with new major versions. This allows them to say "Works with kernel 2.6". The tracking of incremental changes will make things more difficult for the ISVs using cutting edge features of the kernel (CGI houses, etc.)

Oh, and it will certainly offer some challenge to our beloved editor, as to when he is supposed to send the next edition of Linux Device Drivers to the press. ;-)

My problem with this

NAR — Fri, 30 Jul 2004 09:02:31 +0000

In addition, kernel security holes force me to upgrade periodically. Right now, I grab a new kernel from kernel.org, copy the .config, check for new options, build, and reboot. Minor pain-in-the-ass, but manageable even if I'm on deadline. [...] Say I'm running 2.6.12 at the time, since keeping up with 2.6 is too much work, and the current kernel is 2.6.41.

If you're up-to-date with the 2.4.x kernel, I see no reason why you wouldn't be up-to-date with the 2.6.x kernel too so this later scenario wouldn't happen to you.

Bye,NAR

My problem with this

pm101 — Fri, 30 Jul 2004 06:52:29 +0000

I'm not a computer person. I understand computers, but I don't like dealing with computers. I read LWN every week, and am an able programmer, but fundamentally, I want computers to just work. I last installed Debian maybe four years ago, configured it up very nicely, and haven't really reconfigured anything on my computer other than the periodic apt-get update/upgrade, to keep me current for security patches. In addition, kernel security holes force me to upgrade periodically. Right now, I grab a new kernel from kernel.org, copy the .config, check for new options, build, and reboot. Minor pain-in-the-ass, but manageable even if I'm on deadline. The computer does stuff for a while, but I have 5 minutes, so I can keep everything up-to-date.

I haven't had time to migrate to 2.6. I tried once. Too much time. Didn't have time to finish. I'll do it someday, but reconfiguring all the hardware and every subsystem is a royal pain.

What concerns me is the following:

I'm on deadline. A security hole is found in the kernel, so I must upgrade. Say I'm running 2.6.12 at the time, since keeping up with 2.6 is too much work, and the current kernel is 2.6.41. With this model, upgrading is really untenable. I won't have time to reconfigure everything, figure out ALSA was removed in favor of some new sound system, iptables works differently, so my firewall breaks, and either way, I have 100 new/changed options in make menuconfig to redo.

I don't/can't run stock distribution kernels, since I did configure up my system with a nice firewall, power management, support for esoteric hardware, etc. Some things in this (I don't recall what) weren't in the stock kernel.

I'm just an end-user, but the same applies to corporate installs that want a consistent system. To you, 2.4 may be obsolete, but to me, it's stable and fast/easy to manage. I don't want to be forced to upgrade my kernel to a significantly different one anytime a security hole is found, or even for new hardware (except in extreme examples; maybe for PCI->PCI/X or something). I also don't need features backported; the only thing I might need in the new kernel are the new device drivers.

I'd be much happier if some version of 2.6 was just marked as "stable," and had just drivers and security fixes backported to it. Otherwise, I'd continue the above development model with the mainstream kernel marked 2.7 "semistable," together with 2.7-mm/2.7-ac "unstable"?

As with Debian, most users would run kernel/testing, developers would run kernel/unstable, and technologically-backwards old farts like me would have a nice kernel/stable. Stable here wouldn't just mean "won't crash," but the more traditional definition of "won't change much."

Another look at the new development model

simon_kitching — Fri, 30 Jul 2004 01:16:18 +0000

Is this a move towards a system similar to the BSD development models?

I have seen comments from BSD developers which were very critical of the "periodic release" style development of Linux, and praising their own system (which I know very little about).

Cryptoloop does the hokey-cokey?

Ross — Thu, 29 Jul 2004 22:23:19 +0000

You can use DM to encrypt a device and loopback block driver to create the
device from a file. So you end up using two tools instead of one but it
works.

Will there be a 2.7 kernel generation

corbet — Thu, 29 Jul 2004 14:18:43 +0000

Nobody really knows how 2.7 will work, once it's created. But, yes, there is a good chance that the developments which forced the creation of 2.7 will, once they are ready, be pushed downward into 2.6 and 2.7 will fade away. It all really depends on the nature of the changes, however. Someday, something sufficiently disruptive will come along and there will be no choice but to push forward to a 2.8.

Will there be a 2.7 kernel generation

allesfresser — Thu, 29 Jul 2004 14:13:04 +0000

I also had the same question; it was engendered by this curious sentence: "Even then, however, 2.7 will track 2.6 as closely as possible, and it may go away when the feature which drove its existence becomes ready to go into the mainline."

Any idea what that means? Will the 2.7 tree just dry up and blow away when it's not needed anymore? It might be better to call it something else than 2.7 if that's the case...

Will there be a 2.7 kernel generation

elanthis — Thu, 29 Jul 2004 13:37:36 +0000

No, because if you actually read the article, it explicitly states that when patches which are too disruptive even for -mm start showing up, 2.7 will likely be created.

Will there be a 2.7 kernel generation

tarvin — Thu, 29 Jul 2004 09:49:56 +0000

Is the article to be read as there will not be a 2.7 development generation of the kernel?

Cryptoloop does the hokey-cokey?

james — Thu, 29 Jul 2004 09:37:19 +0000

As I understand it, the replacement is dm-crypt: doing cryptography through DM.

The old cryptoloop support is allegedly "buggy, unmaintained, and reportedly has mutliple [sic] security weaknesses," and the kernel crew feel that vulnerable encrypted filesystem support is worse than no support at all: at least if there's no support, people know their data is vulnerable...

James.

Cryptoloop does the hokey-cokey?

nix — Thu, 29 Jul 2004 07:30:48 +0000

Cryptoloop *in the device mapper* is new.

Encrypted loopback devices (implemented by cryptoloop outside the device mapper) are very old: I remember them from the 2.0 days, and they may predate that.

One question: if cryptoloop is going away, what's replacing it? Is the CryptoAPI there for no reason, or is there some new magical way to encrypt filesystems that I've overlooked?

Cryptoloop does the hokey-cokey?

tgb — Thu, 29 Jul 2004 06:58:06 +0000

Consider some of the changes which have been merged since 2.6.0:

...

Cryptoloop

...

...

The first features to be removed by this path are likely to be devfs and cryptoloop.

Pardon my ignorance, but why is cryptoloop, which appears to be a relatively new feature, being pulled already?

LWN: Comments on "Another look at the new development model"

My problem with this

In a few words

Similar problem to Debian, and a similar solution

Stable branch still needed

The only problem left...

My problem with this

My problem with this

Another look at the new development model

Cryptoloop does the hokey-cokey?

Will there be a 2.7 kernel generation

Will there be a 2.7 kernel generation

Will there be a 2.7 kernel generation

Will there be a 2.7 kernel generation

Cryptoloop does the hokey-cokey?

Cryptoloop does the hokey-cokey?

Cryptoloop does the hokey-cokey?