Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux 5.0-rc1

lore.kernel.org

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Linux 5.0-rc1

#31

Post by zanny »

michaelmrose wrote: post #26
uniformlyrandom wrote: post #5

I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.

It seems likely that the people that have been doing this for decades have a reason for the current methodology. Generally how far exactly you are behind mainstream is useless information it produces exactly zero actionable intelligence. For most people in fact no amount of information would be actionable because mostly what they ought to do is run whatever their distribution comes with. For those who do indeed need…

The version.patch notation is still meaningful to Linux because each version increment means new features and support. If the latest is version 50 and you are on 48 you should be suspicious if that unsupported PCI device works on that newer release.

Its just the major version that is always redundant because Linux never breaks userspace compatibility.

But of all software projects the Linux kernel is definitely not a poster child for having a reasonable methodology to versioning. Just some choice released kernel version names: 0.95, pre2.0, 2.2 and 2.4 but no 2.1 or 2.3, 2.6 lasted 8 years, 3.19 - 4.0 because Linus felt like it, and 4.20 -> 5.0 because Linus felt like it.

The only consistent number has been patch releases.

Re: Linux 5.0-rc1

#32

Post by zanny »

michaelmrose wrote: post #27
sys_64738 wrote: post #8

Maybe the kernel should switch to Chrome style versioning? It would solve this dilemma.

At this rate we would be in triple digit numbers before long.

There have been plenty of Linux releases with triple digit patch series. I'm familiar with 3.18 reaching 131 and I know 3.0 and 3.2 got over a hundred each as well.

Also, by any reasonable definition, there is no meaningful difference between 4.20 or 420. You just put a period in there. The major number has no real significance.

Re: Linux 5.0-rc1

#33

Post by zanny »

uniformlyrandom wrote: post #5

I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.

Besides what others have said kernel releases aren't special. They are just quarterly. There would be no "big" release each year because any arbitrary release can be "big" or not. Nobody is going to keep major functionality out of the kernel just because they want to wait for a bigger number to go up.

Re: Linux 5.0-rc1

#34

Post by lostmsu »

IMHO, Linux is failing us, end users.

It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable.

But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too. I think that situation is caused by the lack of stable driver API.

Now that's what I'll be looking forward to for 6.0.

Re: Linux 5.0-rc1

#35

Post by IloveHN84 »

I'm still contrary to all those drivers additions that are being made, slowing the compile time.

Why don't they get rid of old drivers (say, prior to 2000)?

It would make the kernel slimmer for sure. They could made optional and one has to self compile the kernel to enable them

Re: Linux 5.0-rc1

#36

Post by lostapathy »

IloveHN84 wrote: post #35

I'm still contrary to all those drivers additions that are being made, slowing the compile time. Why don't they get rid of old drivers (say, prior to 2000)? It would make the kernel slimmer for sure. They could made optional and one has to self compile the kernel to enable them

You can already disable building whatever drivers you don’t need when you make your kernel config.

Re: Linux 5.0-rc1

#37

Post by c256 »

lostmsu wrote: post #34

IMHO, Linux is failing us, end users. It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable. But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too.…

I don’t know if you realize it, but your complaint is “hardware vendors change things too frequently”. Kernel hackers don’t make up the need to do extra work for hardware support just for kicks. Yes, the hits everyone: Windows loses support for old hardware much faster than it used to. Even the closed-ecosystem of OSX/macosx/macOS leaves hardware behind these days. Mobile phone hardware changes so frequently that you can’t even be sure that the same make & model of handset will use the same hardware. In many ways, it’s both a sign of progress and the baseline cost of doing business.

Re: Linux 5.0-rc1

#38

Post by lostmsu »

c256 wrote: post #37
lostmsu wrote: post #34

IMHO, Linux is failing us, end users. It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable. But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too.…

I don’t know if you realize it, but your complaint is “hardware vendors change things too frequently”. Kernel hackers don’t make up the need to do extra work for hardware support just for kicks. Yes, the hits everyone: Windows loses support for old hardware much faster than it used to. Even the closed-ecosystem of OSX/macosx/macOS leaves hardware behind these days. Mobile phone hardware changes so frequently that you…

Why do you think it has anything to do with the hardware vendors? They don't want to spend resources upstreaming their changes, but do something else, that's all.

Did not we just see a fight last year, between, I think, AMD and Linux, where AMD, instead of the common practice to drop a blob and be done with it, tried to actually upstream some drivers, but they were not up to Linux's coding standards, so got rejected.

I am not saying AMD is in right here. Maybe nobody is, given the current state of affairs. But it is end users who are suffering from the conflict of interest between Linux community, who doesn't want to maintain cheaply written code, and hardware companies, who can't make great open source drivers for the same money they can make an OK-ishly made closed source blob, that only supports 2yo LTS.

That decision, that I can't have the latest Linux and 5yo drivers that work is simply bad for me as a consumer. Heck, if Linux had stable driver API, somebody could easily go and fix that just slightly buggy AMD driver to be compatible with the latest kernel without much fuss, and without the need to upstream it. And I could use my laptop with the supported kernel again.

I think stable driver API for Linux would do a great good to billions of people. Would let them not to spend money every 3 years on a new phone, and let Microsoft to let Windows 10 go, finally bringing proper privacy to the common folk.

Re: Linux 5.0-rc1

#39

Post by lostmsu »

c256 wrote: post #37
lostmsu wrote: post #34

IMHO, Linux is failing us, end users. It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable. But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too.…

I don’t know if you realize it, but your complaint is “hardware vendors change things too frequently”. Kernel hackers don’t make up the need to do extra work for hardware support just for kicks. Yes, the hits everyone: Windows loses support for old hardware much faster than it used to. Even the closed-ecosystem of OSX/macosx/macOS leaves hardware behind these days. Mobile phone hardware changes so frequently that you…

Then again, how is the need to upstream drivers affecting small businesses doing hardware? Forget AMD, they might (arguably) find resources to do the clean-up. But mom, who learned a bit of programming to make a driver for Mom&Pop's Pool Acidity Sensor will never be able to upstream.

So small business needs it even more. Don't you think that is a good reason on its own?

Re: Linux 5.0-rc1

#40

Post by jplayer01 »

azernik wrote: post #20
uniformlyrandom wrote: post #5

I actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.

That's not how kernel development actually works. There's a set of supported releases that continue getting fixes over time - e.g. 4.20 will keep on getting patch fixes for a while. Better to have nothing referring to a date than some digits referring to dates and some not.

Huh? Ubuntu does the date as version and they do patch fixes and what not.
Post reply on HN