Language Selection

English French German Italian Portuguese Spanish

Ubuntu 19.10 Dropping 32-bit Support Leaves Developers Fuming

Filed under
News

There will be no 32-bit support at all in Ubuntu 19.10. This is problematic for developers of Wine and Steam and gaming on Ubuntu might be in trouble.
Read more

Devs unhappy with Ubuntu for dropping 32bit

All this whining over playing games?? How about you grow up and use a computer for productivity and communications and buy a game machine to play games on. The PS4 runs on linux and appears to have no shortage of great gaming.

It's well past time to put the 32bit architecture behind us. Wine seems useful for running MSOffice on a linux box and many other productivity softwares. And they're available in 64bit versions.

I don't see why, after more than a decade of 64bit growth, devs should have to maintain both platforms.

The developers

I think it's them who are most upset.

Steam will not support Ubuntu 19.10 onwards

  • Steam will not support Ubuntu 19.10 onwards

    It is only a few days since Canonical announced that it was dropping support for 32-bit packages as of Ubuntu 19.10. The fall out from this is now being felt.

    While there were many developers who were not happy with the decision, Linux-based gamers are now likely to be more than slightly annoyed. Steam has announced that "Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to our users".

Ubuntu Developer Talks Down Impact Of 32-Bit

  • Ubuntu Developer Talks Down Impact Of 32-Bit Changes For Ubuntu 19.10

    Following Valve saying they won't be officially supporting Ubuntu 19.10 and Wine developers questioning their Ubuntu 32-bit builds following the announcement this week of not providing new 32-bit packages for new Ubuntu releases, longtime Ubuntu developer and Canonical employee Steve Langasek is trying to provide some clarity into the situation.

Steam Is About to Drop Official Support for Ubuntu

  • Steam Is About to Drop Official Support for Ubuntu

    Valve is dropping official support for Ubuntu 19.10 and future releases for its mega-popular Steam video game distribution platform, per Engadget, as the upcoming version of the OS will eliminate updates to 32-bit x86 components. According to Valve developer Pierre-Loup Griffais, the company will “evaluate ways to minimize breakage for existing users,” though it will also be focusing on “a different distribution, currently TBD.”

A couple more

  • Steam will stop supporting Ubuntu Linux over 32-bit compatibility
  • Canonical’s Decision To Drop 32-Bit Support In Ubuntu Upsets The Linux Gaming Community

    The future of Linux gaming sure is going to be interesting, as Canonical has announced this week that it’s going to be scrapping 32-bit support with Ubuntu 19.10. This was something considered last year, and clearly, even after all of the debate about whether or not it should happen, Canonical feels it’s best to pull the plug and look to the future.

    There are some problems with that, but before we go further, we do want to make clear that this decision is Canonical’s own. The myriad spins based on Ubuntu could take it upon themselves to continue supporting 32-bit libraries. For gamers, what this move means is that Ubuntu is no longer going to be the de facto “simple” choice for Linux gaming.

This could be the start of the fall of Ubuntu as de facto distro

  • Ubuntu is dropping support for 32-bit apps and games, so Steam is dropping support for Ubuntu

    Canonical’s Ubuntu operating system is one of the biggest names in desktop GNU/Linux. But if you plan to play PC games on Linux, you might want to start looking around for a different Linux distro.

    Ubuntu developer Steve Langasek announced last week that starting with Ubuntu 19:10, which comes out in October, Canonical would no longer provide 32-bit builds of applications and libraries. This being Linux, there will be workarounds — but many existing apps may not work out of the box anymore.

    Case in point: a number of games from GOG cannot be installed on a pre-release version of Ubuntu 19:10. So it’s not all that surprising that a developer for Valve says that now that Canonical is dropping support for 32-bit software, Valve’s Steam game client is dropping support for Ubuntu.

Ubuntu NOT Dropping 32-bit App Support After All?

  • Rumour: Ubuntu NOT Dropping 32-bit App Support After All?

    That’s according to Canonical’s Steve Langasek, the author of the original “end of 32-bit support” mailing list post that led to a colourful parade of opinions from users, developers and software projects over the past few days..

    Reaction to the mailing list post’s implication that Ubuntu will no longer support 32-bit apps culminated in a dramatic decision by Valve, who say Steam for Linux will not support Ubuntu 19.10.

    Now, in a forum reply on the Ubuntu Discourse, Langasek appears to row back on the notion that 32-bit libraries will be removed wholesale in the ‘Eoan Ermine’, writing:

    “I’m sorry that we’ve given anyone the impression that we are ‘dropping support for i386 applications‘. It is simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions.”

  • Would Steam Losing Ubuntu Support Make You Switch Distro? [Poll]

    Gamers the globe over were left open-mouthed by a Valve developer’s tweet that Steam for Linux is dropping support for Ubuntu as of the next release, Ubuntu 19.10.

    That snippet of shock followed an announcement by Canonical developers that there’d be no traditional access to 32-bit libraries in the next short-term release of the famed Linux distro.

    While confusion remains as to Canonical’s exact plans for the 32-bit Ubuntu archive — going away entirely? Just being frozen? Something else? — many Ubuntu users have taken to social media to state that if Steam goes from Ubuntu, so will they.

    Would a lack of official support for using the world’s biggest games distribution platform and shop store front on Ubuntu be enough to make YOU switch distro?

Steam Will No Longer Support Ubuntu : Valve

  • Steam Will No Longer Support Ubuntu : Valve

    Ubuntu users are having a bad week as now Valve says that steam won’t support Ubuntu any more. Valve developer Pierre-Loup Griffais revealed this shocking news in this tweet.

Valve Says Steam for Linux Won't Support Ubuntu 19.10

  • Valve Says Steam for Linux Won't Support Ubuntu 19.10 and Future Releases

    Valve's harsh announcement comes just a few days after Canonical's announcement that they will drop support for 32-bit (i386) architectures in Ubuntu 19.10 (Eoan Ermine). Pierre-Loup Griffais said on Twitter that Steam for Linux won't be officially supported on Ubuntu 19.10, nor any future releases.

    The Steam developer also added that Valve will focus their efforts on supporting other Linux-based operating systems for Steam for Linux. They will be looking for a GNU/Linux distribution that still offers support for 32-bit apps, and that they will try to minimize the breakage for Ubuntu users.

Steam Won’t Support Ubuntu 19.10 and Future Releases

  • Steam Won’t Support Ubuntu 19.10 and Future Releases

    Do you use Steam on Ubuntu? You may have to switch to a new Linux distro in the future. A Valve developer announced that Steam won’t officially support Ubuntu 19.10 or future releases. Ubuntu-based Linux distributions are also affected.

    This is all because Canonical announced plans to drop 32-bit packages and libraries from Ubuntu 19.10. These packages enable 32-bit software to run on 64-bit versions of Ubuntu.

    While most Linux applications will get along just fine, this is a huge blow to Valve’s Steam. Many Linux games on Steam are only available in 32-bit form—they work on 64-bit Linux distributions, but only with the 32-bit libraries. As Phoronix recently pointed out, this also affects the Wine compatibility layer that allows running Windows software on Linux—Wine won’t be able to run 32-bit Windows software anymore. Steam’s compatibility layer for running Windows games on Linux would also not work for 32-bit games.

Steam To Drop Support For Ubuntu Linux

  • Steam To Drop Support For Ubuntu Linux

    While the number of gaming titles being made available on Linux is increasing each month, it’s widely accepted that gaming remains one of the weakest points of all Linux based operating systems. There are options like Pop!_OS, Manjaro, etc., that deliver considerably better performance, but they’re also heavily dependent on the Valve-owned Steam game distribution platform.

    Just recently, we reported Ubuntu’s plans to completely drop the support for 32-bit packages. Earlier, during the Ubuntu 17.10 development cycle, Canonical announced its plans to ditch the 32-bit installation images. Along the similar lines, Canonical had also disabled the upgrades from Ubuntu 18.04 LTS to Ubuntu 18.10.

Another Response From Canonical/Ubuntu

  • I am running Steam/Wine on Ubuntu 19.10 (no 32-bit on the host)

    I like to take care of my desktop Linux and I do so by not installing 32-bit libraries. If there are any old 32-bit applications, I prefer to install them in a LXD container. Because in a LXD container you can install anything, and once you are done with it, you delete it and poof it is gone forever!

    In the following I will show the actual commands to setup a LXD container for a system with an NVidia GPU so that we can run graphical programs. Someone can take these and make some sort of easy-to-use GUI utility. Note that you can write a GUI utility that uses the LXD API to interface with the system container.

Steam to Soon Drop Support of Ubuntu

  • Steam to Soon Drop Support of Ubuntu

    The all-powerful folks over at Valve have announced that Steam will soon not support the Linux-based operating system Ubuntu. Starting from the upcoming version 19.10, all future versions of Ubuntu will not be supported and also won’t be recommended to users as a compatible OS.

Valve to drop Steam support for Ubuntu Linux

  • Valve to drop Steam support for Ubuntu Linux

    Valve has announced it is pulling support for its Steam digital distribution platform on Canonical's Ubuntu Linux operating system, after the company revealed plans to drop 32-bit support.

    Valve's interest in Linux is storied and ongoing: While the company focused, naturally enough, on Windows for the launch of its now-ubiquitous Steam digital distribution platform, the company announced Linux support in 2012 and launched in in 2013 via Canonical's Ubuntu Software Centre. When Valve announced its own Linux-based gaming operating system in 2013, it extended its efforts with the operating system; Steam Play, launched late last year, allowed Steam for Linux to play Windows games through a compatibility shim dubbed Proton.

    Now, though, Valve has indicated that it is to drop support for the popular Ubuntu Linux distribution - though not Linux in general - over maintainer Canonical's decision to stop developing 32-bit libraries.

  • Steam will no longer be officially supporting Ubuntu for future updates

    Valve‘s video game megastore Steam will no longer be supported for Linux operating systems after October of this year.

    Announced by Valve’s Pierre-Loup Griffais on Twitter, the company will officially be dropping support for future versions of the Linux distro.

    Those who frequently use Ubuntu will have until the OS’ next update, 19.10, to move another OS before Valve’s services become unsupported. The update is planned to release on October 17th, just four months away.

  • Ubuntu 19.10 looks DOA for gamers, with Valve dropping support for the OS

    Apple, Canonical and Microsoft may have switched to distributing 64-Bit OSs a few years ago, but Mac OS X, Ubuntu and Windows all still support the 32-bit architecture. Microsoft integrates Windows 32-bit on Windows 64-bit (WoW64) for example, while the current version of Ubuntu still supports 32-bit. That is, until now.

    Starting with 19.10 Ubuntu will contain only 64-bit code, with Canonical removing all 32-bit support. In short, no 32-bit applications will run on future versions of Ubuntu. This may not seem noteworthy considering that developers have had years to upgrade their software to 64-bit. However, Ubuntu 19.10 and newer will prevent even 64-bit applications from executing any 32-bit libraries or packages.

  • Steam is boiling as Ubuntu turns half its library into vapourware

    GAMING PORTAL Steam has announced it will ditch official support for Linux Ubuntu starting with the next release.

    Last week, Canonical announced it would not be offering 32-bit builds of its software in future, and Steam responded with an almighty "erm - no".

    Steam has pledged to do everything it can to avoid leaving anyone in the lurch but will be moving its attention to a yet-to-be-determined alternative Linux flavour soon.

    The big problem for Steam is that so many of its classic games were only ever made available in 32-bit. By dropping support for the ageing architecture, it is essentially putting Steam in a position of borking half of the games in its library, whether that be by hiding them in the GUI or having them throw up an error code. Either way, it's not a good look.

    Although there are lots of options, alternative operating systems, custom builds, emulators and so on, it's not the same as having an out-of-the-box experience.

  • Steam Linux likely to not support future versions of Ubuntu

    Steam’s Linux version will not support future versions of popular and newbie-friendly distribution Ubuntu, Valve have said. The news came after Ubuntu’s makers said they’d drop 32-bit as of the next big release in October, which sounded like it would leave the great many 32-bit Steam games unplayable. Valve said they were now planning to “switch our focus” to another Linux distro. Ubuntu have since pivoted to say they’re not dropping 32-bit, they’re just going to stop updating it, which is better but still a bit of a dead end.

  • Steam is Dropping Support of Ubuntu Soon

    If you use Linux-based operating system Ubuntu to play games on Steam, you might want to think about an alternative solution. As per a tweet from Valve coder Pierre-Loup Griffais over the weekend, future versions of Ubuntu will not be officially supported by Steam, nor will it be recommended to users as a compatible OS.

    The first version of Ubuntu to not be supported will be 19.10, which is scheduled to release on 17th October. That means Ubuntu users have just shy of four months to enjoy official Steam support before it's a thing of the past.

  • Steam to drop support for Ubuntu but Linux users shouldn’t panic yet

    The majority of the time that Linux gets dragged in the spotlight is when there are high-profile security bugs that remind people how Linux practically runs the world behind the scenes. This time, however, the controversy is ironically around one of the operating system’s weakest points: gaming. A Valve developer just “announced” on Twitter that the company will be dropping support for future releases of Ubuntu and, as expected, it has driven Linux users into a slight frenzied panic.

  • Out of Steam, Wine draining away? Ubuntu's 64-bit only decision is causing problems

    Canonical's decision to cease development of 32-bit libraries in Ubuntu 19.10 "eoan" means it won't support Steam gaming runtime and devs say the Wine compatibility layer for running Windows apps will be little use.

    The Steam news was reported on Twitter by Valve developer Pierre-Loup Griffais, who said "Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to our users."

    Ubuntu has caused anxiety with its announcement that "the i386 architecture will be dropped" in the next release. Some presumed this meant i386 libraries would not be shipped at all, meaning that no 32-bit applications would run.

Canonical Assures Users 32-bit Apps Will Run on Ubuntu 19.10

  • Canonical Assures Users 32-bit Apps Will Run on Ubuntu 19.10 and Future Releases

    Last week, Canonical announced that they will completely deprecate support for 32-bit (i386) hardware architectures in future Ubuntu Linux releases, starting with the upcoming Ubuntu 19.10 (Eoan Ermine) operating system, due for release later this fall on October 17th. However, the company mentioned the fact that while 32-bit support is going away, there will still be ways to run 32-bit apps on a 64-bit OS.

    As Canonical didn't give more details on the matter at the time of the announcement, many users started complaining about how they will be able to run certain 32-bit apps and games on upcoming Ubuntu releases. Valve was also quick to announce that their Steam for Linux client won't be officially supported on Ubuntu 19.10 and future releases, so now Canonical has clarified the situation a bit saying only updates to 32-bit libraries are dropped.

Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS

  • Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS

    Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS.

    We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed.

    Community discussions can sometimes take unexpected turns, and this is one of those. The question of support for 32-bit x86 has been raised and seriously discussed in Ubuntu developer and community forums since 2014. That’s how we make decisions.

More of 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS

  • Ubuntu To Provide Select 32-Bit Packages For Ubuntu 19.10 & 20.04 LTS

    It looks like my info from this weekend was accurate, "I'm hearing that Canonical may revert course and provide limited 32-bit support." Canonical issued a statement today that they indeed will provide "selected" 32-bit packages for the upcoming Ubuntu 19.10 as well as Ubuntu 20.04 LTS.

    Canonical announced that as a result of feedback, they "changed our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS...We will put in place a community process to determine which 32-bit packages are needed to support legacy software, and can add to that list post-release if we miss something that is needed."

  • Canonical returning 32-bit Ubuntu Linux support after gaming uproar

    At first glance, Canonical dropping support for 32-bit Ubuntu Linux libraries looked to be interesting -- the end of an era -- but of no real importance. Then, Canonical announced that, beginning with October's Ubuntu 19.10 release, 32-bit -computer support would be dropped. And both developers and users screamed their objections.

    Canonical listened and has changed course. "Thanks to the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community, we will change our plan and build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS."

Ubuntu Changed their stand

  • Ubuntu Changed their stand in dropping support of 32-bit i386 Packages

    Ubuntu gave a press release about their stand for 32-bit i386 packages. They will be building selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS. But not a full one.

    Last week, Canonical announced that they will completely dropping support for 32-bit (i386) hardware architectures in future Ubuntu Linux releases, starting with the upcoming Ubuntu 19.10 (Eoan Ermine) operating system.

    After this announcement, many of the users started complaining about how they will be able to run the 32-bit apps and games on upcoming Ubuntu releases.

    At the same time, after three days. Valve announced that Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to their users.

    They will evaluate ways to minimize breakage for existing users, but they will switch to a different distribution, currently TBD.

    Ubuntu has reversed their decision based on the community response.

Canonical have released a statement on Ubuntu

Additional coverage of Ubuntu's reversal on i386

  • Canonical backtracks on pulling 32-bit support from Ubuntu Linux

    Last week, Ubuntu announced it would end support for 32-bit applications, starting with its next release.

  • Ubuntu Reverses Decision, Says It Will Continue To Support 32-bit Apps

    Canonical has issued a statement on Ubuntu’s 32-bit future — and gamers, among others, are sure to relieved!

    The company says Ubuntu WILL now continue to build and maintain a 32-bit archive going forward — albeit, not a full one.

    In a response emailed to me (but presumably posted online somewhere) the company cite “the huge amount of feedback this weekend from gamers, Ubuntu Studio, and the WINE community” for persuading them to change track.

    That outcry, almost unparalleled in Ubuntu’s history, resulted in Valve, makers of the hugely popular games distribution service Steam, announcing that it would not support future Ubuntu releases.

    This, combined with worries from users relaying on legacy applications or Windows-only software ran through WINE, has resulted in a change of plans.

    Accordingly, Canonical says it “…will build selected 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS,” they say.

    Notice the word “selected” there. It seems the full 32-bit archive we enjoy now wont stick around, but a curated collection of libraries, tooling and other packages will be made available.

  • Raspberry Pi 4 on Sale Now, SUSE Linux Enterprise 15 Service Pack 1 Released, Instaclustr Service Broker Now Available, Steam for Linux to Drop Support for Ubuntu 19.10 and Beyond, and Linux 5.2-rc6 Is Out

    Valve developer announces that Steam for Linux will drop support for the upcoming Ubuntu 19.10 release and future Ubuntu releases. Softpedia News reports that "Valve's harsh announcement comes just a few days after Canonical's announcement that they will drop support for 32-bit (i386) architectures in Ubuntu 19.10 (Eoan Ermine). Pierre-Loup Griffais said on Twitter that Steam for Linux won't be officially supported on Ubuntu 19.10, nor any future releases. The Steam developer also added that Valve will focus their efforts on supporting other Linux-based operating systems for Steam for Linux. They will be looking for a GNU/Linux distribution that still offers support for 32-bit apps, and that they will try to minimize the breakage for Ubuntu users."

  • Canonical foolishly backpedals on 32-bit packages in Ubuntu Linux

    Having an open mind and admitting when you are wrong is a noble quality. Those that are stubborn and continue with bad ideas just to save face are very foolish. With all of that said, sometimes you have to stick with your decisions despite negative feedback because you know they are right. After all, detractors can often be very loud, but not necessarily large in numbers. Not to mention, you can't please everyone, so being indecisive or "wishy-washy" in an effort to quash negativity can make you look weak. And Canonical looks very weak today.

    When the company announced it was planning to essentially stop supporting 32-bit packages beginning with the upcoming Ubuntu 19.10, I was quite impressed. Look, folks, it is 2019 -- 64-bit processors have been commonplace for a long time. It's time to pull the damn 32-bit band-aid off and get on with things. Of course, there was some negativity surrounding the decision -- as is common with everything in the world today. In particular, developers of WINE were upset, since their Windows compatibility layer depends on 32-bit, apparently. True Linux users would never bother with WINE, but I digress.

  • Ubuntu Reverses Decision, Says It Will Continue To Support 32-bit Packages

    Canonical has issued a statement on Ubuntu's 32-bit future, saying it will continue to build and maintain a 32-bit archive going forward.

More coverage: Valve and Ubuntu

  • Steam is dropping support for Ubuntu, but not Linux entirely
  • Steam ending support for Ubuntu over 32-bit compatibility
  • Out of Steam? Wine draining away? Ubuntu's 64-bit-only x86 decision is causing migraines

    Canonical's decision to effectively ditch official support for 32-bit x86 in Ubuntu 19.10 means the Steam gaming runtime is likely to run aground on the Linux operating system – and devs say the Wine compatibility layer for running Windows apps will be of little use.

    As a result of the changes, Valve developer Pierre-Loup Griffais confirmed on Twitter: "Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to our users." This is because Steam relies on 32-bit x86, aka i386, support for running older games that are 32-bit-only. Without official 32-bit x86 support in Ubuntu, Valve is walking away from the Linux distro.

  • Ubuntu Compromises on 32-Bit App Support

    Canonical, the developer of Ubuntu, has backtracked on an earlier announcement that Ubuntu 19.10 will no longer update 32-bit packages and applications, announcing today that Ubuntu 19.10 and 20.04 will support select 32-bit apps.

    The news follows Valve and the developers of Wine, an open source compatibility layer for running Windows apps on other operating systems, saying they would stop supporting Ubuntu completely.

  • Steam to End Support for Ubuntu

    Canonical's decision to stop updating 32-bit libraries has seen Valve react by stating Ubuntu will no longer be officially supported from Ubuntu 19.10 onwards.

Comment viewing options

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

More in Tux Machines

today's howtos and programming bits

  • How to fix trailing underscores at the end of URLs in Chrome
  • How to Install Ubuntu Alongside With Windows 10 or 8 in Dual-Boot
  • Beginner’s guide on how to git stash :- A GIT Tutorial
  • Handy snapcraft features: Remote build
  • How to build a lightweight system container cluster
  • Start a new Cryptocurrency project with Python
  • [Mozilla] Celery without a Results Backend
  • Mucking about with microframeworks

    Python does not lack for web frameworks, from all-encompassing frameworks like Django to "nanoframeworks" such as WebCore. A recent "spare time" project caused me to look into options in the middle of this range of choices, which is where the Python "microframeworks" live. In particular, I tried out the Bottle and Flask microframeworks—and learned a lot in the process. I have some experience working with Python for the web, starting with the Quixote framework that we use here at LWN. I have also done some playing with Django along the way. Neither of those seemed quite right for this latest toy web application. Plus I had heard some good things about Bottle and Flask at various PyCons over the last few years, so it seemed worth an investigation. Web applications have lots of different parts: form handling, HTML template processing, session management, database access, authentication, internationalization, and so on. Frameworks provide solutions for some or all of those parts. The nano-to-micro-to-full-blown spectrum is defined (loosely, at least) based on how much of this functionality a given framework provides or has opinions about. Most frameworks at any level will allow plugging in different parts, based on the needs of the application and its developers, but nanoframeworks provide little beyond request and response handling, while full-blown frameworks provide an entire stack by default. That stack handles most or all of what a web application requires. The list of web frameworks on the Python wiki is rather eye-opening. It gives a good idea of the diversity of frameworks, what they provide, what other packages they connect to or use, as well as some idea of how full-blown (or "full-stack" on the wiki page) they are. It seems clear that there is something for everyone out there—and that's just for Python. Other languages undoubtedly have their own sets of frameworks (e.g. Ruby on Rails).

Kernel: Linux 5.3, DragonFlyBSD Takes Linux Bits, LWN Paywall Expires for Recent Articles

  • Ceph updates for 5.3-rc1
    Hi Linus,
    
    The following changes since commit 0ecfebd2b52404ae0c54a878c872bb93363ada36:
    
    Linux 5.2 (2019-07-07 15:41:56 -0700)
    
    are available in the Git repository at:
    
    https://github.com/ceph/ceph-client.git tags/ceph-for-5.3-rc1
    
    for you to fetch changes up to d31d07b97a5e76f41e00eb81dcca740e84aa7782:
    
    ceph: fix end offset in truncate_inode_pages_range call (2019-07-08 14:01:45 +0200)
    
    There is a trivial conflict caused by commit 9ffbe8ac05db
    ("locking/lockdep: Rename lockdep_assert_held_exclusive() ->
    lockdep_assert_held_write()"). I included the resolution in
    for-linus-merged.
    
  • Ceph Sees "Lots Of Exciting Things" For Linux 5.3 Kernel

    Ceph for Linux 5.3 is bringing an addition to speed-up reads/discards/snap-diffs on sparse images, snapshot creation time is now exposed to support features like "restore previous versions", support for security xattrs (currently limited to SELinux), addressing a missing feature bit so the kernel client's Ceph features are now "luminous", better consistency with Ceph FUSE, and changing the time granularity from 1us to 1ns. There are also bug fixes and other work as part of the Ceph code for Linux 5.3. As maintainer Ilya Dryomov put it, "Lots of exciting things this time!"

  • The NVMe Patches To Support Linux On Newer Apple Macs Are Under Review

    At the start of the month we reported on out-of-tree kernel work to support Linux on the newer Macs. Those patches were focused on supporting Apple's NVMe drive behavior by the Linux kernel driver. That work has been evolving nicely and is now under review on the kernel mailing list. Volleyed on Tuesday were a set of three patches to the Linux kernel's NVMe code for dealing with the Apple hardware of the past few years in order for Linux to deal with these drives. On Apple 2018 systems and newer, their I/O queue sizing/handling is odd and in other areas not properly following NVMe specifications. These patches take care of that while hopefully not regressing existing NVMe controller support.

  • DragonFlyBSD Pulls In The Radeon Driver Code From Linux 4.4

    While the Linux 4.4 kernel is quite old (January 2016), DragonFlyBSD has now re-based its AMD Radeon kernel graphics driver against that release. It is at least a big improvement compared to its Radeon code having been derived previously from Linux 3.19. DragonFlyBSD developer François Tigeot continues doing a good job herding the open-source Linux graphics driver support to this BSD. With the code that landed on Monday, DragonFlyBSD's Radeon DRM is based upon the state found in the Linux 4.4.180 LTS tree.

  • Destaging ION

    The Android system has shipped a couple of allocators for DMA buffers over the years; first came PMEM, then its replacement ION. The ION allocator has been in use since around 2012, but it remains stuck in the kernel's staging tree. The work to add ION to the mainline started in 2013; at that time, the allocator had multiple issues that made inclusion impossible. Recently, John Stultz posted a patch set introducing DMA-BUF heaps, an evolution of ION, that is designed to do exactly that — get the Android DMA-buffer allocator to the mainline Linux kernel. Applications interacting with devices often require a memory buffer that is shared with the device driver. Ideally, it would be memory mapped and physically contiguous, allowing direct DMA access and minimal overhead when accessing the data from both sides at the same time. ION's main goal is to support that use case; it implements a unified way of defining and sharing such memory buffers, while taking into account the constraints imposed by the devices and the platform.

  • clone3(), fchmodat4(), and fsinfo()

    The kernel development community continues to propose new system calls at a high rate. Three ideas that are currently in circulation on the mailing lists are clone3(), fchmodat4(), and fsinfo(). In some cases, developers are just trying to make more flag bits available, but there is also some significant new functionality being discussed. clone3() The clone() system call creates a new process or thread; it is the actual machinery behind fork(). Unlike fork(), clone() accepts a flags argument to modify how it operates. Over time, quite a few flags have been added; most of these control what resources and namespaces are to be shared with the new child process. In fact, so many flags have been added that, when CLONE_PIDFD was merged for 5.2, the last available flag bit was taken. That puts an end to the extensibility of clone().

  • Soft CPU affinity

    On NUMA systems with a lot of CPUs, it is common to assign parts of the workload to different subsets of the available processors. This partitioning can improve performance while reducing the ability of jobs to interfere with each other. The partitioning mechanisms available on current kernels might just do too good a job in some situations, though, leaving some CPUs idle while others are overutilized. The soft affinity patch set from Subhra Mazumdar is an attempt to improve performance by making that partitioning more porous. In current kernels, a process can be restricted to a specific set of CPUs with either the sched_setaffinity() system call or the cpuset mechanism. Either way, any process so restricted will only be able to run on the specified CPUs regardless of the state of the system as a whole. Even if the other CPUs in the system are idle, they will be unavailable to any process that has been restricted not to run on them. That is normally the behavior that is wanted; a system administrator who has partitioned a system in this way probably has some other use in mind for those CPUs. But what if the administrator would rather relax the partitioning in cases where the fenced-off CPUs are idle and going to waste? The only alternative currently is to not partition the system at all and let processes roam across all CPUs. One problem with that approach, beyond losing the isolation between jobs, is that NUMA locality can be lost, resulting in reduced performance even with more CPUs available. In theory the AutoNUMA balancing code in the kernel should address that problem by migrating processes and their memory to the same node, but Mazumdar notes that it doesn't seem to work properly when memory is spread out across the system. Its reaction time is also said to be too slow, and the cost of the page scanning required is high.

How the Open Source Operating System Has Silently Won Over the World

The current and future potential for Linux based systems is limitless. The system’s flexibility allows for the hardware that uses it to be endlessly updated. Functionality can, therefore, be maintained even as the technology around the devices change. This flexibility also means that the function of the hardware can be modified to suit an ever-changing workplace. For example, because the INSYS icom OS has been specifically designed for use in routers, this has allowed it to be optimised to be lightweight and hardened to increase its security. Multipurpose OS have large libraries of applications for a diverse range of purposes. Great for designing new uses, but these libraries can also be exploited by actors with malicious intent. Stripping down these libraries to just what is necessary through a hardening process can drastically improve security by reducing the attackable surfaces. Overall, Windows may have won the desktop OS battle with only a minority of them using Linux OS. However, desktops are only a minute part of the computing world. Servers, mobile systems and embedded technology that make up the majority are predominately running Linux. Linux has gained this position by being more adaptable, lightweight and portable than its competitors. Read more

Operating-System-Directed Power-Management (OSPM) Summit

  • The third Operating-System-Directed Power-Management summit

    he third edition of the Operating-System-Directed Power-Management (OSPM) summit was held May 20-22 at the ReTiS Lab of the Scuola Superiore Sant'Anna in Pisa, Italy. The summit is organized to collaborate on ways to reduce the energy consumption of Linux systems, while still meeting performance and other goals. It is attended by scheduler, power-management, and other kernel developers, as well as academics, industry representatives, and others interested in the topics.

  • The future of SCHED_DEADLINE and SCHED_RT for capacity-constrained and asymmetric-capacity systems

    The kernel's deadline scheduling class (SCHED_DEADLINE) enables realtime scheduling where every task is guaranteed to meet its deadlines. Unfortunately SCHED_DEADLINE's current view on CPU capacity is far too simple. It doesn't take dynamic voltage and frequency scaling (DVFS), simultaneous multithreading (SMT), asymmetric CPU capacity, or any kind of performance capping (e.g. due to thermal constraints) into consideration. In particular, if we consider running deadline tasks in a system with performance capping, the question is "what level of guarantee should SCHED_DEADLINE provide?". An interesting discussion about the pro and cons of different approaches (weak, hard, or mixed guarantees) developed during this presentation. There were many different views but the discussion didn't really conclude and will have to be continued at the Linux Plumbers Conference later this year. The topic of guaranteed performance will become more important for mobile systems in the future as performance capping is likely to become more common. Defining hard guarantees is almost impossible on real systems since silicon behavior very much depends on environmental conditions. The main pushback on the existing scheme is that the guaranteed bandwidth budget might be too conservative. Hence SCHED_DEADLINE might not allow enough bandwidth to be reserved for use cases with higher bandwidth requirements that can tolerate bandwidth reservations not being honored.

  • Scheduler behavioral testing

    Validating scheduler behavior is a tricky affair, as multiple subsystems both compete and cooperate with each other to produce the task placement we observe. Valentin Schneider from Arm described the approach taken by his team (the folks behind energy-aware scheduling — EAS) to tackle this problem.

  • CFS wakeup path and Arm big.LITTLE/DynamIQ

    "One task per CPU" workloads, as emulated by multi-core Geekbench, can suffer on traditional two-cluster big.LITTLE systems due to the fact that tasks finish earlier on the big CPUs. Arm has introduced a more flexible DynamIQ architecture that can combine big and LITTLE CPUs into a single cluster; in this case, early products apply what's known as phantom scheduler domains (PDs). The concept of PDs is needed for DynamIQ so that the task scheduler can use the existing big.LITTLE extensions in the Completely Fair Scheduler (CFS) scheduler class. Multi-core Geekbench consists of several tests during which N CFS tasks perform an equal amount of work. The synchronization mechanism pthread_barrier_wait() (i.e. a futex) is used to wait for all tasks to finish their work in test T before starting the tasks again for test T+1. The problem for Geekbench on big.LITTLE is related to the grouping of big and LITTLE CPUs in separate scheduler (or CPU) groups of the so-called die-level scheduler domain. The two groups exists because the big CPUs share a last-level cache (LLC) and so do the LITTLE CPUs. This isn't true any more for DynamIQ, hence the use of the "phantom" notion here. The tasks of test T finish earlier on big CPUs and go to sleep at the barrier B. Load balancing then makes sure that the tasks on the LITTLE CPUs migrate to the big CPUs where they continue to run the rest of their work in T before they also go to sleep at B. At this moment, all the tasks in the wake queue have a big CPU as their previous CPU (p->prev_cpu). After the last task has entered pthread_barrier_wait() on a big CPU, all tasks on the wake queue are woken up.

  • I-MECH: realtime virtualization for industrial automation

    The typical systems used in industrial automation (e.g. for axis control) consist of a "black box" executing a commercial realtime operating system (RTOS) plus a set of control design tools meant to be run on a different desktop machine. This approach, besides imposing expensive royalties on the system integrator, often does not offer the desired degree of flexibility for testing/implementing novel solutions (e.g., running both control code and design tools on the same platform).

  • Virtual-machine scheduling and scheduling in virtual machines

    As is probably well known, a scheduler is the component of an operating system that decides which CPU the various tasks should run on and for how long they are allowed to do so. This happens when an OS runs on the bare hardware of a physical host and it is also the case when the OS runs inside a virtual machine. The only difference being that, in the latter case, the OS scheduler marshals tasks among virtual CPUs. And what are virtual CPUs? Well, in most platforms they are also a kind of special task and they want to run on some CPUs ... therefore we need a scheduler for that! This is usually called the "double-scheduling" property of systems employing virtualization because, well, there literally are two schedulers: one — let us call it the host scheduler, or the hypervisor scheduler — that schedules the virtual CPUs on the host physical CPUs; and another one — let us call it the guest scheduler — that schedules the guest OS's tasks on the guest's virtual CPUs. Now what are these two schedulers? That depends on the virtualization platform. They are always different, in the sense that it will never happen that, at runtime, a scheduler has to deal with scheduling virtual CPUs and also scheduling tasks that want to run on those same virtual CPUs (well, it can happen, but then you are not doing virtualization). They can be the same, in terms of code, or they can be completely different from that respect as well.

  • Rock and a hard place: How hard it is to be a CPU idle-time governor

    In the opening session of OSPM 2019, Rafael Wysocki from Intel gave a talk about potential problems faced by the designers of CPU idle-time-management governors, which was inspired by his own experience from the timer-events oriented (TEO) governor work done last year. In the first place, he said, it should be noted that "CPU idleness" is defined at the level of logical CPUs, which may be CPU cores or simultaneous multithreading (SMT) threads, depending on the hardware configuration of the processor. In Linux, a logical CPU is idle when there are no runnable tasks in its queue, so it falls back to executing the idle task associated with it (there is one idle task for each logical CPU in the system, but they all share the same code, which is the idle loop). Therefore "CPU idleness" is an OS (not hardware) concept and if the idle loop is entered by a CPU, there is an opportunity to save some energy with a relatively small impact on performance (or even without any impact on performance at all) — if the hardware supports that. The idle loop runs on each idle CPU and it only takes this particular CPU into consideration. As a rule, two code modules are invoked in every iteration of it. The first one, referred to as the CPU idle-time-management governor, is responsible for deciding whether or not to stop the scheduler tick and what to tell the hardware to do; the second one, called the CPU idle-time-management driver, passes the governor's decisions down to the hardware, usually in an architecture- or platform-specific way. Then, presumably, the processor enters a special state in which the CPU in question stops fetching instructions (that is, it does literally nothing at all); that may allow the processor's power draw to be reduced and some energy to be saved as a result. If that happens, the processor needs to be woken up from that state by a hardware event after spending some time, referred to as the idle duration, in it. At that point, the governor is called again so it can save the idle-duration value for future use.