
Linux 5.0-rc1 - ojn
https://lore.kernel.org/lkml/CAHk-=wgKYnrL3LjhVkH2Fp+ecmWhLqezT9zmR6CzfcpwcJX0qA@mail.gmail.com/t/
======
azhenley
I went to see what the big changes were to justify a new major version number
and saw:

“The numbering change is not indicative of anything special. If you want to
have an official reason, it's that I ran out of fingers and toes to count on,
so 4.21 became 5.0”

I laughed out loud.

~~~
Waterluvian
I can't help myself. I need to know why 5.0. Is there a reason, even a
pointless one? Or is it truly a "just because" moment?

~~~
uranusjr
It probably is simply “just because”. Not the first time Linus feels it, IIRC
3.0 was basically bumped for the same non-reason.

~~~
hornetblack
I think there was at least a Google+ poll.

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

~~~
CaliforniaKarl
Coming up with a response to this one was harder than I expected. The
calendar-based release cycle you describe is pretty different from what is
practiced today.

Although, if you change the time scales, maybe not so much: Kernels are
released on a fairly-predictable cadence now, and patches come in (to the
mailing list and maintainer trees) almost constantly. So, if this is as simple
as extending timescales, that leads down to an impossible debate: What changes
count as minor/major/patches? For example, some would say that adding a driver
is just a patch (as it doesn't change other parts of the kernel); some would
say that it is major (because it adds new functionality).

There's also the human element: If someone has something to contribute,
they'll want discussion to start on it sooner rather than later. Also, rolling
lots of major changes into a big release may make it hard to tease out
bugs—and performance regressions—as the just-released major version makes its
way down to individual distributions.

So in this case, I think the best think for your needs would be to ignore
upstream kernels, and instead rely on a distro kernel: Pick whichever distro
you think does kernels the best, and which uses a time-based release schedule,
and use their kernel.

Or, get an LWN subscription, and keep an eye out for their regular "What's new
in this kernel" articles.

~~~
1stranger
I assume they were referring to calendar based naming a la Ubuntu.

[https://calver.org](https://calver.org)

------
shmerl
Some annoying amdgpu bugs were fixed for Vega users (like one affecting
DisplayPort 1.2 monitors with REG_WAIT timeout /
dce110_stream_encoder_dp_blank error).

* [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/display/dc/core/dc_link.c?h=v5.0-rc1&id=8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06)

------
diminish
Newer projects have quick version bumps after the success of Chrome's
accelerated versioning approach.

But for software deeper in solutions, fast version changes appear confusing. I
like Apache, nginx with very small bumps. Most newer JS frameworks live fast
and die quick. It's also very confusing for developers to decide to jump to
newer versions.

Expecting 11.20 version around 2037.

~~~
zanny
The worst part is its arbitrary. I don't get why Linus is so bent on keeping a
three step version number when the first digit has been meaningless since 1996
(or maybe 2011 if you want to be pedantic and call the version change from
2.6.x to 3.x a major revision). For the largest free software project in the
world it sure doesn't do much to advertise good practices when informing your
user of relative newness of kernels.

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

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

------
mycall
RIP ISDN

~~~
codersbrew
Memories!

~~~
fffrantz
Still regular work for me, this thing just refuses to die

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

~~~
zapzupnz
Is it really a 'dilemma' though? Basically, a project can set the version
numbers how they want. They don't need to justify the change. So long as they
and others can refer to each release by a simple and easily identifiable
number or moniker, it really makes no difference if it's 5.0 or 4.22. In the
end, the Linux kernel is such a big project that there's really no reason to
single out any single or a set of changes as significant enough to warrant a
version number bump; it's all arbitrary to start with.

~~~
sys_64738
Versioning isn't just about the practical software build. The version is used
to describe differences to non-tech PMs.

A PM's eyes will glaze over when you talk 4.22 V 4.16, but you mention v22
versus v22 and then they 'get it'.

That's why a Chrome style versioning has value.

~~~
zapzupnz
It has value to certain people, sure. But given that it's mainly technically
minded people who work with the kernel on a daily basis, and most people don't
need to know their kernel version number outside of limited circumstances.

I would say for the majority of Linux users, it's the OS version that's more
important; that is, getting help with your installation of Ubuntu, it's more
useful to know that you're running 18.10 rather than kernel version 4.18.

Yes, Chrome-style versioning has value. But is that value applicable to this
scenario? I wouldn't say 'no', but I'm fairly comfortable saying "not
necessarily". Nothing is universal, and no one solution solves every problem.

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

~~~
c256
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.

~~~
lostmsu
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?

~~~
maxnoe
Then, is getting a driver upstreamed for linux really harder than getting it
trusted/signed for Windows or macOS?

~~~
lostmsu
If you are mom&pop's, you can live with unsigned driver.

Anyway, you don't have to be a professional developer to sign it. Just buy a
certificate, then it is just a couple of commands.

