So two weeks have passed, the merge window is over, and 4.11-rc1 has
been tagged and pushed out.
This looks like a fairly regular release. It's on the smallish side,
but mainly just compared to 4.9 and 4.10 - so it's not really
_unusually_ small (in recent kernels, 4.1, 4.3, 4.5, 4.7 and now 4.11
all had about the same number of commits in the merge window).
It _does_ feel like there was more stuff that I was asked to pull than
was in linux-next. That always happens, but seems to have happened
more now than usually. Comparing to the linux-next tree at the time of
the 4.10 release, almost 18% of the non-merge commits were not in
Linux-next. That seems higher than usual, although I guess Stephen
Rothwell has actual numbers from past merges.
Now, about a quarter of the patches that weren't in linux-next do end
up having the same patch ID as something that was, so some of it was
due to just rebasing. But still - we have about 13% of the merge
window that wasn't in linux-next when 4.10 was released.
Looking at the sources of that, there's a few different classes:
This is obviously ok and inevitable. I don't expect everything to
have been in linux-next, after all.
- the statx() systen call thing.
Yeah, I'll allow this one too, because quite frankly, the first
version of that patch was posted over six years ago.
- there's the quite noticeable
This one was posted and discussed before the merge window, and
needed to be merged late (and even then caused some conflicts). So it
had real reasons for late inclusion.
- a couple of subsystems. drm, Infiniband, watchdog and btrfs stand out.
That last case is what I found rather annoying this merge window.
In particular, if you cannot follow the simple merge window rules
(this whole two-week merge window and linux-next process has been in
place over a decade), at least make the end result look good. Make it
all look easy and problem-free. Make it look like you know what you're
doing, and make damn sure the code was tested exhaustively some other
Because if you bypass the linux-next sanity checks, you had better
have your own sanity checks that you replaced them with. Or you just
need to be _so_ good that nobody minds you bypassing them, and nobody
ever notices your shortcuts.
Saying "screw all the rules and processes we have in place to verify
things", and then sending me crap that doesn't even build for me is
You people know who you are. Next merge window I will not accept
anything even remotely like that. Things that haven't been in
linux-next will be rejected, and since you're already on my shit-list
you'll get shouted at again.
Linus Torvalds Announces the First Release Candidate of Linux Kernel 4.11
Just a few moments ago, Linus Torvalds announced the availability of the first Release Candidate (RC) development build of the upcoming Linux 4.11 kernel series, which users can download, compile, and test on their GNU/Linux distributions.
Linux 4.11-rc1 Kernel Released
Linus Torvalds has announced the first test release of the upcoming Linux 4.11 kernel.
Torvalds' release announcement that just hit the mailing list mostly talks about the size of the merges and a fair amount of material that was merged but hadn't been staged in linux-next, upsetting him some. Beginning with Linux 4.12, Linus will become more strict about seeing that big changes be staged in linux-next for testing.
I'm quite used to the prescense of an IDE when coding - at least for the completion functions. I use YouCompleteMe for the job now, but I'm wondering if there's something I'm missing that I just have to hear about (even another editor with similar bindings). Cheers!submitted by /u/Masterchef365
LXer: This Week in Open Source, CNCF Announces 6th Managed Project, Changes in OSS Accelerate SDN & More
"How much swap is recommended nowadays? Can I run without swap? Is further tuning possible?"
- The New Features Of The Linux 4.11 Kernel
Linux 4.11 Doesn't Change The Game For AMD's Ryzen
Linux 4.11 is worthwhile in that it's bringing ALC1220 audio support, the codec used by many Ryzen (and Intel Kabylake) motherboards, but this next kernel version doesn't appear to change Ryzen's performance.
I didn't see anything notable this Linux 4.11 merge window with regard to Ryzen for potentially affecting its performance, but I ran some benchmarks this weekend just to confirm.
SWR Software Rasterizer Now Supports Geometry Shaders
Intel's "SWR" software rasterizer living within Mesa now has support for OpenGL geometry shaders.
Thanks to work that landed today by Intel's Tim Rowley, there is now support for OpenGL geometry shaders in this software rasterizer. The code amounts to over 700 lines of new code to implement GL GS support.