Language Selection

English French German Italian Portuguese Spanish

Linux 5.5-rc1

Filed under
Linux

  • Linux 5.5-rc1
    We've had a normal merge window, and it's now early Sunday afternoon,
    and it's getting closed as has been the standard rule for a long while
    now.
    
    Everything looks fairly regular - it's a tiny bit larger (in commit
    counts) than the few last merge windows have been, but not bigger
    enough to really raise any eyebrows. And there's nothing particularly
    odd in there either that I can think of: just a bit over half of the
    patch is drivers, with the next big area being arch updates. Which is
    pretty much the rule for how things have been forever by now.
    
    Outside of that, the documentation and tooling (perf and selftests)
    updates stand out, but that's actually been a common pattern for a
    while now too, so it's not really surprising either. And the rest is
    all the usual core stuff - filesystems, core kernel, networking, etc.
    
    The pipe rework patches are a small drop in the ocean, but ended up
    being the most painful part of the merge for me personally. They
    clearly weren't quite ready, but it got fixed up and I didn't have to
    revert them. There may be other problems like that that I just didn't
    see and be involved in, and didn't strike me as painful as a result ;)
    
    We're missing some VFS updates, but I think we'll have Al on it for
    the next merge window. On the whole, considering that this was a big
    enough release anyway, I had no problem going "we can do that later".
    
    As usual, even the shortlog is much too large to post, and nobody
    would have the energy to read through it anyway. My mergelog below
    gives an overview of the top-level changes so that you can see the
    different subsystems that got development. But with 12,500+ non-merge
    commits, there's obviously a little bit of everything going on.
    
    Go out and test (and special thanks to people who already did, and
    started sending reports even during the merge window),
    
    Linus
    
    
  • Linus Torvalds Kicks Off Development of Linux Kernel 5.5, First RC Is Out Now

    The two week-long merge window that opened with the release of the Linux 5.4 kernel series last month ended today with the launch of the first release candidate of Linux kernel 5.5, which was announced by Linus Torvalds himself.
    That's right, Linus Torvalds has officially kicked off the development cycle of the next major Linux kernel series, Linux 5.5, which is now available for public testing from the kernel.org website. Linux kernel 5.5-rc1 is the first milestone in many to come and gives the community a first look at the new features and changes.

    "We've had a normal merge window, and it's now early Sunday afternoon, and it's getting closed as has been the standard rule for a long while now," said Linus Torvalds. "Everything looks fairly regular - it's a tiny bit larger (in commit counts) than the few last merge windows have been, but not bigger enough to really raise any eyebrows. And there's nothing particularly odd in there either that I can think of: just a bit over half of the patch is drivers, with the next big area being Arch updates."

  • Linux 5.5 Feature Overview - Raspberry Pi 4 To New Graphics Capabilities To KUnit

    Linux 5.5-rc1 is on the way to mirrors and with that the Linux 5.5 merge window is now over. Here is a look at the lengthy set of changes and new features for this next Linux kernel that will debut as stable in early 2020.
    Among the many changes to find with Linux 5.5 are support for the Raspberry Pi 4 / BCM2711, various performance changes still being explored, support for reporting NVMe drive temperatures, a new Logitech keyboard driver, AMD HDCP support for content protection, wake-on-voice support from Chromebooks, the introduction of KUnit for unit testing the kernel, new RAID1 modes that are quite exciting for Btrfs, and much more. Below is a more detailed look based upon our original monitoring and reporting.

  • Unified sizeof_member() Re-Proposed For Linux 5.5

    After not being merged for Linux 5.4, the new sizeof_member() macro as a unified means of calculating the size of a member of a struct has been volleyed for Linux 5.5 for possible inclusion on this last day of the merge window.

    The Linux kernel to now has supported SIZEOF_FIELD, FIELD_SIZEOF, sizeof_field as means of calculating the size of a member of a C struct... The new sizeof_member looks to clean-up that code cruft that has accumulated over the years with converting all usage of the old macros over to this new unified macro.

Catchup by Michael Larabel

  • Linux 5.5-rc1 Kernel Released With 12,500+ Commits

    Linus Torvalds has just issued the first release candidate of the Linux 5.5 cycle following the traditional two week long merge window.

    See our newly-published Linux 5.5 feature overview to learn about all of the new changes and improvements in this kernel -- there's a lot.

LWN: Kernel prepatch 5.5-rc1

  • Kernel prepatch 5.5-rc1

    Linus has released the 5.5-rc1 kernel prepatch and closed the merge window for this development cycle.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Audiocasts/Shows/Screencasts: FLOSS Weekly, BSDNow and Linux Mint 20 Backgrounds Slideshow

  • FLOSS Weekly 581: Purism

    Doc Searls and Simon Phipps talk to Kyle Rankin, Chief Security Officer and Vice President at Purism. Purism is security focussed software & hardware company that believes in building products that respect and protect individuals' privacy, security, and freedom.

  • BSDNow 353: ZFS on Ironwolf

    Scheduling in NetBSD, ZFS vs. RAID on Ironwolf disks, OpenBSD on Microsoft Surface Go 2, FreeBSD for Linux sysadmins, FreeBSD on Lenovo T480, and more.

  • Linux Mint 20 Backgrounds Slideshow

    In this video, we are looking at the beautiful backgrounds of the upcoming Linux Mint 20.

Servers: Kubernetes, Benchmarks and OpenStack

  • Longhorn Simplifies Distributed Block Storage in Kubernetes

    Today we’re announcing the general availability of Longhorn, an enterprise-grade, cloud-native container storage solution. Longhorn directly answers the need for an enterprise-grade, vendor-neutral persistent storage solution that supports the easy development of stateful applications within Kubernetes. We’ve been working on Longhorn for almost as long as we’ve been around as a company. We launched the project in 2017, and then in 2019, we contributed it to the Cloud Native Computing Foundation (CNCF) as a sandbox project. So it’s that CNCF open source project that is now generally available.

  • Supporting the Evolving Ingress Specification in Kubernetes 1.18

    Earlier this year, the Kubernetes team released Kubernetes 1.18, which extended Ingress. In this blog post, we’ll walk through what’s new in the new Ingress specification, what it means for your applications, and how to upgrade to an ingress controller that supports this new specification.

  • Benchmarks Of 2nd Gen AMD EPYC On Amazon EC2 Against Intel Xeon, Graviton2

    Today AMD and Amazon announced the general availability of 2nd Gen AMD EPYC "Rome" processors available via the Elastic Compute Cloud. AMD EPYC "Rome" on EC2 with the new "C5a" instance types offer very competitive performance against the latest Intel Xeon instance types, Amazon's own Graviton2 Arm-based instances, and a big upgrade compared to the first-generation EPYC processors in the cloud.

  • OpenStack Ussuri for Ubuntu 20.04 and 18.04 LTS

    The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Ussuri on Ubuntu 20.04 LTS and on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive.

Debian Leftovers and Developers

  • Antoine Beaupré: Replacing Smokeping with Prometheus

    I've been struggling with replacing parts of my old sysadmin monitoring toolkit (previously built with Nagios, Munin and Smokeping) with more modern tools (specifically Prometheus, its "exporters" and Grafana) for a while now. Replacing Munin with Prometheus and Grafana is fairly straightforward: the network architecture ("server pulls metrics from all nodes") is similar and there are lots of exporters. They are a little harder to write than Munin modules, but that makes them more flexible and efficient, which was a huge problem in Munin. I wrote a Migrating from Munin guide that summarizes those differences. Replacing Nagios is much harder, and I still haven't quite figured out if it's worth it. [...] A naive implementation of Smokeping in Prometheus/Grafana would be to use the blackbox exporter and create a dashboard displaying those metrics. I've done this at home, and then I realized that I was missing something.

  • Reproducible Builds in May 2020

    One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. Nonetheless, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into seemingly secure software during the various compilation and distribution processes.

  • Steve McIntyre: Interesting times, and a new job!

    It's been over ten years since I started in Arm, and nine since I joined Linaro as an assignee. It was wonderful working with some excellent people in both companies, but around the end of last year I started to think that it might be time to look for something new and different. As is the usual way in Cambridge, I ended up mentioning this to friends and things happened! [...] Where do I fit in? Pexip is a relatively small company with a very flat setup in engineering, so that's a difficult question to answer! I'll be starting working in the team developing and maintaining PexOS, the small Linux-based platform on which other things depend. (No prizes for guessing which distro it's based on!) But there's lots of scope to get involved in all kinds of other areas as needs and interests arise. I can't wait to get stuck in! Although I'm no longer going to be working on Debian arm port issues on work time, I'm still planning to help where I can. Let's see how that works...

LibreELEC (Leia) 9.2.3

LibreELEC 9.2.3 (Leia) the final version has arrived based upon Kodi v18.7.1. Read more