Announcement

Collapse
No announcement yet.

The Big Changes Merged This Week For The Linux 4.17 Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by -MacNuke- View Post
    That would be just more work with no benefits.
    How is it more work? The only difference is the timing when the kernel version goes up. It's pretty much entirely effortless.
    It's not like that Linux drops CPU architectures just because they feel like it. They get dropped because nobody uses them anymore. Show me one user that used a vanilla 4.x kernel on a 386. There are also no users of kernel 4.16 on a POWER4 because it did not work for years.
    I understand all of that... You're acting as though I'm advocating for keeping these old architectures, and I have no idea where you're getting that impression from.
    If kernel versions are based on planning around intentionally obsoleting older architectures, this would actually help encourage obsoleted hardware to get removed sooner, while making kernel versions easier to follow in terms of compatibility. Remember, new architectures would affect it too.

    Orienting kernel version numbers around ancient architectures would be just stupid. Nobody "suffers" from those changes.
    First of all, I said it would revolve around both old and new architectures. Also, what's your idea? Because do you seriously think Linus' whim of an approach is better? At least with my idea there's a coherent reason.

    Comment


    • #12
      Originally posted by schmidtbag View Post
      I feel like any time there is a CPU architecture being removed from the kernel, that should warrant a new kernel version. To me, that'd make a lot more sense than the arbitrary numbering scheme used now. Also, if an all-new achitecture were made, that should also warrant a new kernel version.
      Please no. Then we'd be moving to a Chrome/Firefox-like scheme and I'm not a fan of that.

      Comment


      • #13
        Originally posted by lucrus View Post

        I know, but there are a number of issues with the current naming scheme:
        • It's Fearless Coyote since 4.11 - so it does not match important changes in supported architectures, nor in other areas (Meltdown mitigation, amdgpu, ...)
        • It's reminescent of Ubuntu releases, and that's bad of its own ("Psychotic Stoned Sheep", "Roaring Lionus", "Fearless Coyote", "Bionic Beaver", same nonsense, you get the picture)
        • Currently no one really cares about the name, just because it's a random name, just like it's a random version number. Remembering what kernel supported what is a nightmare.
        • I recall in past years I found it handy to know that 2.4+ meant iptables support, while 2.2 meant ipchains and 2.0 meant ipfw or something like that. If being constrained by version numbers gets in Linus way, at least giving a "commercial" name to each "important" release would be nice.
        • I know, Linus does not give a f*** to commercial issues, so I'm going to take care of that in his place. I'm going to call Linux 4.17 "Manhood" 'cause you know, it will be a great release... I'm sure it will be easy to remember for everyone...
        Version numbers are always random. There's nothing stopping Linus (or any other developer) from releasing the next version as 0.5 or 1000.11 for that matter. Sure, it would look weird but that's not the point.

        Comment


        • #14
          Originally posted by Vistaus View Post
          Please no. Then we'd be moving to a Chrome/Firefox-like scheme and I'm not a fan of that.
          ...what? How? Besides, the Linux kernel is already doing that, just at a relatively slower pace.

          Comment


          • #15
            Originally posted by schmidtbag View Post
            How is it more work? The only difference is the timing when the kernel version goes up. It's pretty much entirely effortless.
            Holding back patches _is_ more work just for version numbers.

            Originally posted by schmidtbag View Post
            If kernel versions are based on planning around intentionally obsoleting older architectures, this would actually help encourage obsoleted hardware to get removed sooner, while making kernel versions easier to follow in terms of compatibility. Remember, new architectures would affect it too.
            Nobody is interrested in removing architectures all the time. They get removed because nobody is maintaining them or they are holding back modernisation _and_ (!) nobody uses them anymore. Building version numbers around that _is_ stupid. "Hey, we have to rise the version number, because we changed stuff that nobody cares for". Again: Nobody is interrested in removing stuff that is in use and has active maintainers.

            Originally posted by schmidtbag View Post
            Also, what's your idea?
            I don't care for the version number. Linus/Linux has one big rule: Do not break the userspace. Apart from closed-source driver bullshit (that nobody should ever buy or use) there is no reason why you should not use the newest kernel all the time. And if you are afraid of kernel bugs you can use one of the 6 (!) long-term kernel releases.

            Comment

            Working...
            X