User: Password:
|
|
Subscribe / Log in / New account

My problem with this

My problem with this

Posted Jul 30, 2004 6:52 UTC (Fri) by pm101 (guest, #3011)
Parent article: Another look at the new development model

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."


(Log in to post comments)

My problem with this

Posted Jul 30, 2004 9:02 UTC (Fri) by NAR (subscriber, #1313) [Link]

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

Stable branch still needed

Posted Jul 30, 2004 22:02 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

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.

My problem with this

Posted Dec 28, 2004 7:19 UTC (Tue) by smamunr (guest, #26850) [Link]

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!


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds