
Linux 5.8-rc1 - john-shaffer
https://lore.kernel.org/lkml/CAHk-=whfuea587g8rh2DeLFFGYxiVuh-bzq22osJwz3q4SOfmA@mail.gmail.com/
======
archseer
This is about 1-2 months old (dated Jun 14th)? 5.8 is out already.
[https://kernelnewbies.org/LinuxChanges](https://kernelnewbies.org/LinuxChanges)

------
sambeau

      we have modified about 20% of all the files 
      in the kernel source repository
    

also

    
    
      despite not really having any single thing that stands out
    

So, is this a ton of bugfixes? A "Snow Linux" as-it-were? If so that will be
awesome.

~~~
kelnos
I really like that no single thing stands out. It shows that a lot of people
were working on a lot of different things, which is a sign of a healthy
project... not that I would otherwise think of Linux as an unhealthy project.

------
S_A_P
As someone who has nowhere in the vicinity of 1% of the responsibility to
insuring that a code base is clean and performs its intended function- who is
reviewing all these pull requests? It cant be Linus, right? How are the folks
with PR privileges vetted?

Fully admitting to ignorance here, but to me it seems that this problem is way
to big to prevent bad actors from participating. I would love to hear thoughts
to the contrary.

~~~
fintler
There's sorta like a "tree" of maintainers for each part of Linux -- with
Linus at the top of the tree. When you make a patch for the kernel, there's a
script you can run on the patch:

scripts/get_maintainer.pl

It'll output the appropriate subtree of maintainers who "own" the code in the
kernel that the patch applies to. Then, you can email your patch to them. The
maintainer will send the patch up the "tree" until (hopefully) it ends up in
Linus' repo.

~~~
Razengan
What happens after Linus dies? Could there be an schism between opposing
successors?

~~~
hpaavola
Two years ago Linus took a break and Greg Kroah-Hartman was leading the
project during that. Greg normally maintains the LTS branch of the kernel (and
possibly many other things also).

------
filereaper
I've lost track of linux versioning, but do folks here know how the next LTS
kernel line is determined?

Looking at kernel.org, the last LTS was the 5.4.z series, so I'm curious when
the next LTS branch will be cut to use these features in most distros.

~~~
kemotep
Looking at past releases[0] it appears every 5th release so since 5.4 was the
last stable release, the next release at 5.9 should be LTS.

[0]([https://www.kernel.org/category/releases.html](https://www.kernel.org/category/releases.html))

~~~
freedomben
Also worth noting for people that use distribution kernels, a distributions
LTS kernel may or may not match the official one. Just something to be aware
of.

------
mehrdadn
If you're interested in async I/O, keep an eye on the io_uring changes.

~~~
jeffbee
Easily 5-10 years before most of us can expect to use that in a work context.

~~~
mehrdadn
I assume you mean because of the time it'll take to trickle down to production
kernels? Does that take 5-10 years?

~~~
gizmo686
It depends on your domain.

RHEL7 has another year[0] of support left (until August 30, 2021), and is
based on kernel 3.10 [1], which was released in 2013 [2]

RHEL 8 is expected to see support through 2029, and is based on kernel 4.18,
which was released in 2018.

Redhat does backport changes, but tends to avoid backporting feature changes.

If you want to be able to use "recent" features of software, you are probably
not running running Redhat But, many companies prefer the stability of systems
that have been battle tested, and so are perpetually years behind the bleeding
edge in terms of features.

[0]
[https://access.redhat.com/support/policy/updates/errata/](https://access.redhat.com/support/policy/updates/errata/)

[1] [https://www.redhat.com/en/blog/what-latest-kernel-release-
my...](https://www.redhat.com/en/blog/what-latest-kernel-release-my-version-
red-hat-enterprise-linux)

[2]
[https://kernelnewbies.org/LinuxVersions](https://kernelnewbies.org/LinuxVersions)

~~~
wwright
I don’t mean to start an off-topic debate on this, but I just have to say that
personally, I run into issues caused by using old software on our EL7 boxes
_all the time_. For example, cgroup memory limits are broken on Red Hat 7
kernels as far as I can tell (most versions have a memory leak, but iirc the
most recent has a panic instead). They’re missing all sorts of features that
are useful for usability or reliability.

I’m just personally not convinced we really win much with the trade off as a
society :p

~~~
jeffbee
Memory control group code is replete with bugs throughout 4.x kernels, way
beyond RHEL 7. This is one of the big problems with getting locked into "LTS"
kernels. It takes a long time to discover all the nameplate features that
don't actually work.

------
xenonite
Could the lockdowns and the extra time at home be partly responsible for this
achievement?

~~~
stolen_biscuit
I wouldn't discount it, but I think many software devs continued working from
home instead of getting laid off. maybe all those kernel contributors found
themselves with an extra 2/3 hours in the day without the daily commute? Not
to mention not being able to carry out daily social lives + leisure activities

~~~
laumars
There are a lot of us developers out there who have had _less_ free time
during the lockdown. Whether it’s because of having young kids or doing
charitable work in the local community for those less fortunate.

~~~
reaperducer
Or you're a dev working in healthcare.

~~~
sushshshsh
HAH wow this hit way too hard. I don't have a shred of free time. I should be
working on the backlog right now as I post.

------
anonymousiam
I am wondering if kernel developers had more time to spend on the project
because of all the recent virus lock-downs. That could account for the higher-
than-usual number of files changed, and overall bulk.

~~~
faho
Are you assuming these are hobbyists who now have more free time?

The majority of kernel hackers are paid to work on it.

~~~
benibela
When they worked in the office, and now work from home, they would have much
more time (no commute!) even if they get paid

------
sixothree
800,000 new lines of code. No matter how you count them that’s a lot of
typing.

My main project has 95 libraries and is nowhere near that massive.

~~~
randyrand
That’s a lot of new surface area for attacks. A lot of new code quickly
worries me.

~~~
tedk-42
What if it's 790000 lines of new/updated tests and 10000 of new functionality?

~~~
ajdlinux
The day a ratio anywhere close to that happens in the Linux kernel, be alert
for all the flying pigs outside.

~~~
tedk-42
Hahaah TIL - Not a contributor, nor do i have the C skills to know what's
going on in the code base to understand it

------
ra
5.8-rc1 was 2 months ago; 5.8 went through rc7 and was released as final last
week.

------
marmshallow
Seems this is biggest in terms of # commits / lines of code / etc.

But does anyone have opinions on what the most “impactful” linux releases ever
was?

------
spanhandler

      Andrew Morton (7):
        updates
        more updates
        yet more updates
        still more updates
        even more updates
        some more updates
        updates
    

Real illuminating merge log there bud :-)

~~~
wmichelin
I'm surprised this is allowed in the linux kernel. I am not familiar, but
assuming these are commit messages, that's pretty damn pathetic.

~~~
stefan_
These are only merges - they don't matter. The actual functional commits are
excellent beyond anything you would ever find in your company VCS.

~~~
0x00000000
Git and Subversion even allowing single line “-m” commit messages was a
mistake. You would see a lot better messages if they forced you to use the
editor. I bet a lot of programmers don’t even know you could do multi line
messages and assume there is some short-ish character limit. I know I did for
a long time

~~~
cardiffspaceman
I feel a huge pain of resignation when I am forced to use multiple lines to
describe a single commit. There is almost no audience for any line of the
commit message other than the first line. As far as line length goes, any
practical means of displaying the messages, like gitk or git --oneline, is
unfriendly to lengthy lines. Gerrit will display all the lines of the tip
commit's commit message, so one can amend that commit to create a summary of
the others, but then of course the other commits are not as visible.

The character limits are a real thing in git culture. One could start here,
with a question posed by an apparent skeptic:

[https://stackoverflow.com/questions/2290016/git-commit-
messa...](https://stackoverflow.com/questions/2290016/git-commit-
messages-50-72-formatting)

~~~
cycloptic
As someone who has had to dig deep with git blame, I tremendously value a good
long multiline commit message. At the very least it can save the trouble of
having to dig up some obscure mailing list discussion or bug report to figure
out why a change was made, assuming that exists at all. If it doesn't, all you
have is the git commits.

~~~
cardiffspaceman
Imagine you followed 50/72 AND the "title" was required to reference
"[JIRA-1234]" or "Bugzilla-1234".

------
anilakar
The number of lines in the amdgpu driver sadly does not mean that it would be
usable in any way. The amount of red in dmesg is just sad when you're stuck
with USB-C DisplayPort graphics.

------
ksec
I am looking at the changelog, even if we ignore drivers being used not in
Server Environment, and improvement from Security, Networking, I am wondering
how are BSDs going to compete?

~~~
jabl
Increasingly, they don't.

I don't think a Linux monoculture is good, but from the perspective of an
individual or organisation choosing which OS to use, there's less and less
reason to choose a BSD.

~~~
mnd999
Yeah, completely. Competition and alternative approaches are what pushes us
forward. The fanboi culture of “*BSD is dying”, “use Chrome” etc. which tech
communities seem to encourage makes it worse.

Keep doing it the hard way, trying something different and running your code
on a different browser and OS. In the long run, Windows and the BSDs have done
a lot to make Linux good, in the same way that Android and iOS push each other
forward. I’m just hoping folks keep adopting Firefox.

------
bjoli
I remember reading that he got a new threadripper-based workstation. It seems
like he is putting it to good use.

------
elitistphoenix
Subject: Linux 5.8-rc1 Date: Sun, 14 Jun 2020

------
jariel
I'm a little wary of the types of metrics: LOC, updates, file changes, merges.

Those are tertiary issues at most.

Features, quality, issues resolved etc.. is mostly what matters.

------
EmilStenstrom
Notably missing: “I want to thank everyone involved for all the work they put
into Linux, this is really a community driven project.”

~~~
IntelMiner
Except Linux by and large is written by paid programmers

