Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
40

The First Pride Was a Riot, and So Are These Updates

from elementary Blog [alt+shift+b] in programming

Questionable puns aside, it’s Pride Month and we’re excited to celebrate by bringing you these updates hand-made by real LGBTQIA+ community members from around the world!—and possibly some straight cis folks too. This rainbow of releases includes some important accessibility updates, tons of bug fixes, and of course a few new features. Window Manager & Dock Another absolutely massive release of our window manager is out that fixes about 20 reported issues and a brand new Gesture Controller thanks to Leonhard and Leo. You can now Swipe up in Multitasking View to close windows, app titles in Multitasking View are now always shown—making them accessible for touch screen setups—and screenshots taken with a keyboard shortcut will send a notification that you can use to view it in Files, just to name a few headlining features. If you want to read the full release notes, Good Luck Babe they’re quite long. A new release of our Dock is also out which brings back a couple of old Plank features: showing multiple dots for apps with multiple running windows and cycling through app windows when you hold a drag-n-drop over its icon. Plus you can now open context menus with a long-press. And there’s a number of bug fixes including things related to hide modes and memory usage. Thanks again to Leo and Leonhard for their hard work here. System Settings Leonhard fixed a crash when setting custom hotcorner commands and we now only show the Applications Menu hotcorner action in its corresponding panel corner—that’s top-left for folks reading left-to-right and top-right for folks reading right-to-left. Plus there’s a new option to enable hotcorners even while an app is fullscreened. As a follow up to last month’s fixes, choosing light or dark mode in System Settings will now properly snooze your schedule instead of disabling it all together—a great convenience for those of us who suffer from eye strain or headaches and need to occasionally reach for that dark mode during the day. Plus,...
2nd Jun 2025

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from elementary Blog

Who Monitors The Monitor?

Monitor The first release of Monitor as an elementary OS default app is here! Monitor is an app for monitoring your system resources and running processes, including with optional panel indicators. Since its last release, we’ve completed the port to GTK4, rewrote the settings menu, and a ton more under the hood. Massive thanks to Stanisław, Ryo, and more for their hard work here. Monitor running processes and available resources Monitor should be automatically installed on your next update, but if you for some reason don’t get it, you can install Monitor with the Terminal command sudo apt install io.elementary.monitor. Window Manager & Dock Another massive bug fix release of our Window Manager has landed with 19 fixed issues including improved performance, fixes for HiDPI, and better animations. We’ve fixed issues with dock menus sometimes appearing behind the dock, apps will now launch correctly when you switch between Classic and Secure sessions, and more. Blur effects have landed in the window switcher and are coming to the Dock Plus, this release introduces a new blur effect. You’ll first notice it in the Alt + Tab window switcher, but in future updates we will also blur behind the Dock and Notifications. Big thanks to Leo and Leonhard for their hard work on this release. Icons We landed a highly requested redesign of folder icons thanks to newhoa. The new folder design is more rounded and more closely matches the design of the Files app icon. Folder icons have been redesigned with rounded corners Icons featuring a computer mouse have been slightly redesigned to include a scroll wheel. And, icons featuring a mouse pointer have been updated to match the new pointer design, thanks to William. Mouse and Pointer icons have been updated Plus a number of smaller clean ups including adding missing sizes for certain icons, adjusting lighting, and rounding a few edges. Finally, we now fall back to Adwaita icons when an app is missing a non-standard icon name, thanks to David Lapshin. Code In the symbols sidebar, tooltips for C language symbols are now more information like their Vala counterparts. When you clone a git branch, we now send an unobtrusive toast to let you know cloning has completed. Global searches now respect your search case sensitivity settings. Opening a second window no longer results in duplicate project entries in the project chooser. And the “Open Folder” keyboard shortcut has been fixed. Shoutouts Jeremy for his hard work on Code. Files Jeremy also fixed a number of small issues with Files including expanding trashed folders in the list view, refreshing views properly when files are deleted, and preventing a potential freeze when the Templates folder contains too many files and subfolders. Plus, Files now shows a setting for Date & Time format. And More In Power settings we now show a small warning about increased energy usage with certain options. The Sound menu now uses a toggle icon like Quick Settings instead of a switch to quickly mute. And media keys for volume now work on the Lock Screen thanks to Leo. Get These Updates As always, pop open System Settings → System on elementary OS 8 and hit “Update All” to get these updates plus your regular security, bug fix, and translation updates. Or set up automatic updates and get a notification when updates are ready to install! Early Access We’re laser focused on preparing to release OS 8.1 so big new features will almost exclusively be targeted to OS 9 from now on. We don’t have OS 9 builds available yet for you to try, but we are working on them already! We’ll let sponsors know first when OS 9 builds are available in Early Access to test. But for now, we have just one more thing. 64-bit Universal ARM builds from the stable updates channel are now available on our Builds website. These builds replace the old device-specific builds for platforms like Raspberry Pi and Pinebook, plus they add support for other ARM devices supported by Linux. This is thanks to the hard work of NN708 who has been dedicated to seeing this project through over the several months it took to complete. Sponsors At the moment we’re at 24% of our monthly funding goal and 324 Sponsors on GitHub! Shoutouts to everyone helping us reach our goals here. Your monthly sponsorship funds development and makes sure we have the resources we need to give you the best version of elementary OS we can! Monthly release candidate builds and daily Early Access builds are available to GitHub Sponsors from any tier! Beware that Early Access builds are not considered stable and you will encounter fresh issues when you run them. We’d really appreciate reporting any problems you encounter with the Feedback app or directly on GitHub.

5th Nov 2025 • 11 votes
More Apps, More Features, More Cowbell!

Hot off the release of OS 8.0.2, we’ve got a great new batch of feature updates for you as we get closer to the release of elementary OS 8.1! Maps The first stable release of elementary Maps is now available for download on any Linux OS. For now we’ve focused on some of the basics like showing your current location, searching for locations, and handling geo:// uri links. You may recall that Maps evolved from the Atlas code base originally written by Steffen Schuhmann for elementary OS. Ryo has worked hard to maintain the code and update it for the latest platform libraries like GTK4. Since the rename, we’ve updated the app to match the latest elementary styles and design conventions. We’ve also added an illustrated view switcher between Explore and Transit maps and when you search you’ll see color coded place type icons next to search results. Keyboard navigation,screen reader accessibility, and performance should also be slightly improved. Plus we have a modernized app icon, shoutouts to Micah for providing art direction. Get Maps on AppCenter AppCenter On the Home page, the “Updates & installed apps” button is now properly labeled for screen readers. We’ve fixed a minor visual bug with banner shadows. And the “Education” category now has an icon. In app info views, we now show a simple percentage-based app rating when ratings are available from ODRS—the same ratings server used by apps like GNOME Software. Expect future versions of AppCenter to expand our support for ratings and reviews, but for now we have some groundwork laid out. App info views also now show content warnings with a more compact layout. Italo updated our “End of Life” warnings to contain more accurate language, and licensing information now shows more detail and a simplified summary. Plus, we now show when a game supports playing with controllers. Leonhard added support for app addons, and we’ve simplified the “What’s New” section to show just the latest release, with the option to view more releases in a separate version history window. Apps now show ratings, controller support, simplified release notes, and license summaries Leonhard did a ton of work in this release to make app updates faster and more reliable. The code has been massively streamlined and we’ve resolved reported crashes that some folks were experiencing while checking for updates. Plus we’re now using GTK 4’s FilterListModels for improved performance. The “Last checked” time is now updated every minute while the updates view is open and the gear menu can now be opened with the keyboard shortcut F10. We’ve made a few changes to the way installed apps are shown to make it easier to keep up with what’s new when you have automatic app updates turned on. Installed apps are now sorted by release date instead of alphabetically. The Releases dialog got a slight redesign and you can now see recent releases for all installed apps. And we’ve adjusted where the version number and store origin labels appear to clean up their layout. You can check past release notes for all installed apps. Occasionally, app icons can take a little longer to load; When this happens they’ll now fall back to a nicer placeholder and cross fade into their proper icons once available, thanks to Italo. We’ve changed the label of the action button for free apps from “Free” to “Install”, according to your feedback. “Recent” apps in Category views should feature a more up-to-date selection and be a bit faster to load. And Search Results will now show in two columns when enough space is available so that you can see more results at once. Dock When we ran our desktop survey 75% of you told us that you expected to see background apps in the Dock, so we now have Background Portal support in the Dock thanks to Leonhard! Here you can see a list of apps running the background without a window, their supplied reason for running the background, and you have the ability to force them to quit. You can always further manage app permissions in System Settings → Applications and choose which apps are allowed to run in the background. Background apps now show in the Dock New contributor Sebastian fixed issues with the placement of app name tooltips, added a shake animation when you try to open a new window on a single-window app with middle-click, and fixed an issue where re-arranging app icons in the dock could cause them to shake indefinitely. Leonhard fixed an issue where maximized windows would be behind a portion of the dock when hiding is turned off. And William improved the color of the indicator dot for apps which are active on another workspace. Panel & Settings In Quick Settings, we’ll now show a message when you try to turn on the onscreen keyboard in a Secure Session since it’s currently only available in a Classic session. And we’ve added a couple of nice animations when you toggle Dark Mode or Rotation Lock. Some toggles—like Rotation Lock—are now animated Vishal fixed a potential crash when using the network indicator on the Lock Screen. And we’ve improved Airplane Mode: it will now only disable networking radios, not Bluetooth or wired networks. Plus you can now jump to System Settings when middle-clicking networking toggle buttons. Application settings now has a setting to select your default Maps app, and you can start typing to search apps right away instead of having to select the search icon first. Login & Lock Screen Leo put a ton of effort into this latest release of the Login ∓ Lock Screen, including support for the automatic accent color and Dark mode! We now also sync more of your settings like panel transparency and power settings. We’ve improved keyboard navigation, and will automatically select the Classic session if accessibility features are used, for example, during Initial Setup. We’ll also do a better job of remembering your last selected user card and their session type. And More Jeremy also pushed another round of maintenance updates for our developer tools!. Files now does a better job when drag-n-dropping files into other apps, and Properties windows now show a more precise date and time for file modification. Code’s terminal pane now does a better job syncing with your Terminal app settings, and he fixed an issue where exiting a shell would break the terminal pane. In the Terminal app, he improved unsafe paste warning detection for commands that contain newlines, and the search bar now takes up a more appropriate amount of space. Get These Updates As always, pop open System Settings → System on elementary OS 8 and hit “Update All” to get these updates plus your regular security, bug fix, and translation updates. Or set up automatic updates and get a notification when updates are ready to install! Early Access We landed blur-behind in a couple of more places in Early Access! The Dock is now slightly more transparent and things behind it will be blurred. This improves legibility when for example busy text is behind the dock. And we’ve also merged some updates styles for Notifications including slight transparency, blur-behind, more rounded corners, and softer shadows. Plus Leo cleaned up Notification close animations. If you’re not a fan of transparency and blur effects, you can always turn off “Panel Transparency” in System Settings → Dock & Panel. The Dock and Notifications now have transparency and blur-behind effects Subhadeep has merged in initial support for fingerprint enrollment in User settings. We’re still working out the experience for fingerprint authentication dialogs for example, but if you have a compatible fingerprint reader you should be able to start testing support and send us feedback about what is and isn’t working. Initial support for enrolling fingerprints was merged Plus, daily and release candidate quality builds will now use the Secure Session by default. We’ve received a ton of feedback that since the updates we’ve made since the release of OS 8 have made the experience of using the Secure session much better than the Classic session for most people, including improved performance and fewer bugs encountered. So we’re really excited to make it the default experience going forward. Sponsors At the moment we’re at 24% of our monthly funding goal and 321 Sponsors on GitHub! Shoutouts to everyone helping us reach our goals here. Your monthly sponsorship funds development and makes sure we have the resources we need to give you the best version of elementary OS we can! Monthly release candidate builds and daily Early Access builds are available to GitHub Sponsors from any tier! Beware that Early Access builds are not considered stable and you will encounter fresh issues when you run them. We’d really appreciate reporting any problems you encounter with the Feedback app or directly on GitHub.

6th Oct 2025 • 15 votes
elementary OS 8.0.2 Available Now

It’s been about 6 months since our last minor release and the team has been busy! For all of the details about what’s new since OS 8.0.1, make sure to check out our posts from May until now. In this post I’ll just be covering our progress over the last month up until the release of OS 8.0.2. OS 8.1 is due to be released before year end and that post will be The Big One™ that wraps up every change since OS 8.0. So without further delay, let’s dive into what we did last month that made it in OS 8.0.2! Installer & Initial Setup The latest Installer incorporates fixes for a number of issues raised during accessibility testing. The “Before Installing”, “Try or Install”, “Choose a Disk”, and “Encryption” views should all have much improved accessible labels, things like password quality feedback will now be read aloud by the screen reader, and we fixed a couple instances where the screen reader would announce text style markup. Plus, Leo added a few more safety checks for the custom install view that should prevent crashes with certain complex partition layouts, and the Installer should now always appear centered on screen. Initial Setup also includes the same password quality feedback improvements for screen readers and it will always appear centered on screen. Plus trailing hyphens and underscores are now allowed in usernames and we use a more reliable source of information for keyboard layouts, thanks to Ryo. Music The latest release of Music includes a number of important new features for managing the queue, including performance improvements for large queues. You can now remove individual track from a track’s context menu or clear the entire queue thanks to Oowoosh0. Jeremy and Leonhard implemented searching by track name. The queue and the last played track will be saved and restored thanks to Stella, and she added the keyboard shortcut Ctrl+O to add new files. Ryan added the Ctrl+Q shortcut to quit, and album art will now show in media controls in the panel and elsewhere. Plus Oowoosh0 fixed a couple of issues with long artists names or when using large system fonts. Terminal Leo Fixed an issue that caused keyboard focus to not be inside the first tab when opening a new window, and he fixed an issue where dropping in text that contain # would be cut off. Jeremy also fixed an issue with incorrect line breaks when pasting or dropping text while a process is running, made sure to always clear process finished icons when a tab is selected, and removed an old misfeature that would cause window sizes to be odd on certain display sizes. Hardware Enablement OS 8.0.2 includes the latest long-term support Hardware Enablement stack from Ubuntu, including Linux 6.14. This new version of the Linux kernel brings improved performance—especially while gaming, reduced power consumption for certain AMD and Intel chipsets and GPUs, new security features, and support for more gamepads, wifi devices, microphones, and more. And More Main menus are now properly marked in Camera, and Videos and can be opened with the keyboard shortcut F10. In Calculator, Alain replaced the “Del” button with an icon, and the “New Window” action now shows in icon in places like keyboard shortcut settings. Trevor fixed a crash with screenshots which are much taller than they are wide and Ryo fixed an issue that caused screenshots not to be saved to custom locations. Get elementary OS 8.0.2 elementary OS 8.0.2 is available as a pay-what-you-can purchase at elementary.io today. Localized direct downloads and a torrent magnet link are provided. OS 8 FAQ Download elementary OS 8.0.2 Sponsors have been able to download OS 8.0.2 release candidates since the beginning of the month, so if getting things before anyone else is important to you, consider sponsoring us on GitHub And Even More Expect another blog post soon detailing all of the new features that have been released since OS 8.0.2 was built and what’s available to test in Early Access—there are a number of big ones!

22nd Sep 2025 • 11 votes
Developer Tools, Hardware Enablement, and Multitasking Futures

Your monthly updates post is here! This month we have a couple of releases for our developer tools, plus plenty of improvements to Bluetooth, as well as a hardware enablement boost from Ubuntu and plenty to talk about in Early Access. Let’s dive in! System Settings The previously mentioned redesign of Bluetooth Settings has arrived! This redesign not only brings a bit more visual separation between paired devices and nearby devices, but also improves the keyboard navigation and screen reader experience. Plus, you can now double click rows to activate them. We resolved an issue where sometimes devices would be duplicated in the list and fixed issues when a pairing request requires entering passcodes—like with some keyboards. You’ll now also see fewer unnamed devices when discovering, enabling and disabling Bluetooth on devices that have been hardware locked should now work reliably, and to top it all off performance when listing lots of devices has also been improved. Bluetooth settings has a new design Leonhard and Ryo fixed a couple of issues with sidebar selections when navigating directly to a setting from search. Ryo fixed an issue where Sharing Settings lost its window controls when a network was not connected. And there’s now an action to jump directly to the System Updates page from the context menu in the Dock or Applications Menu or via search. Code Working with Git projects continues to get better thanks to Jeremy! There’s now a new feature to clone git repositories directly from inside Code via the projects menu in the sidebar. The item for opening project folders has moved there as well, so managing your open projects now happens all in one place no matter where they come from. You can now clone Git projects in Code He also fixed an issue with blank tooltips appearing in empty sidebar folders, a crash when deleting selected text while using the “Highlight Selection” plugin, and a freeze when editing lists with the “Markdown” plugin. Plus, the Symbols sidebar now shows a loading spinner when searching symbols takes longer than usual, and filters have been fixed for C symbols. Terminal Terminal will now warn about pasted commands that include options to skip confirmation like -y, --interactive=never, and --force. Plus we now make sure to show all found warnings about a pasted command, not just the first one found. For example, if a command like sudo apt update && sudo apt install -y fuse is pasted, we will warn about use of admin privileges, multiple commands, and that it skips confirmations, not just that it uses admin privileges. Terminal warns about more potentially dangerous commands Corentin fixed an issue where long commands could resize windows. Jeremy fixed an issue where tab labels didn’t properly update when using screen or ssh. And he made sure we properly close tabs when using the exit command. And More A few small bug fixes for our Window Manager: Corentin resolved a potential crasher, Leo improved dock hide animations, and Leonhard fixed an issue with revealing the panel over fullscreen apps. A new Hardware Enablement stack has arrived thanks to Ubuntu! This includes Linux 6.14 and Mesa 25 which brings support for newer hardware as well as some big performance gains and potential battery life improvements. OMG! Ubuntu! breaks down all the nerdy details here Get These Updates As always, pop open System Settings → System on elementary OS 8 and hit “Update All” to get these updates plus your regular security, bug fix, and translation updates. Or set up automatic updates and get a notification when updates are ready to install! Early Access Maps Last month, Ryo made the last release of Atlas on AppCenter because we’ll soon be shipping it by default in elementary OS as Maps! As part of our work to improve the experience on computers you take with you—like notebooks and tablets—we’ve been working on features that use your location, and shipping a Maps app is part of that work. An in-development version of the new Maps Our hope with Maps is to improve support for mapping and location features in our platform libraries and to improve experiences in other apps like Tasks and Calendar as well as 3rd party apps in AppCenter. We’ve also already made a tiny improvement to the wider Freedesktop ecosystem by documenting a standard location icon used across desktops and in Portals. We’re really looking forward to getting your feedback and learning how we can improve experiences for apps that use your location in elementary OS. Window Manager & Dock First up is some new eye candy. We’ve heard requests for transparency and blur over the years and I’m happy to report we’re now experimenting with some new effects in shell elements like the alt + tab Window Switcher. We want to make sure to carefully balance shiny effects with performance and legibility, so be sure to send in your feedback. We’re also on track to apply some blur behind the Dock soon, so watch out for that. Blur effects have landed in the window switcher and are coming to the Dock Speaking of the Dock, you may have noticed that it’s now sticking around when in Multitasking View! We’ve replaced the old workspace switcher and you can now launch apps from the Dock directly into different workspaces to quickly get things set up exactly how you like. We’ve also merged in a new feature to monitor background apps that use the cross-platform Background Portal. Here you can not only manage background apps, but also see an explanation of what exactly they’re doing while running. With these features, we’re seeing years of design and development work come together: an improved way to multitask on elementary OS whether you use a mouse at your desktop, multitouch gestures on your laptop or tablet, or rely on keyboard shortcuts to get the job done. I’m extremely proud of what the team has done here and look forward from hearing more from you about it! Background apps now show in the Dock And that’s not all. Building on the previously mentioned Gesture Controller, the new Touchpad backend for multitouch gestures has also landed. This replaces Touchégg in the Secure Session as the way to track multitouch gestures, fixes bugs, and enables new features like two-dimensional swiping between workspaces and the full Multitasking View. So if you are a fan of gestures on your notebook, we’d love for you to try it out and report back before we ship it for everyone. Hardware Support Last but not least, we’re now building Universal EFI install images for ARM64 processors. This means instead of building unique ARM images for every hardware platform, we can build a single universal image for platforms like Pinebook, Raspberry Pi, and M-series Macs. These builds are still experimental and come with a few bugs, but we’d love folks to give them a spin in a virtual machine or on a spare computer and report back. If everything looks good, we may be able to offer stable ARM64 downloads starting with OS 8.1 later this year. Sponsors I want to give special thanks this month to Ryan Prior for his extremely generous one-time sponsorship! Ryan noted that this sponsorship was dedicated to the hard work of Renato who has been translating elementary OS into Brazilian Portuguese. Thanks a ton for your work Renato! At the moment we’re at 22% of our monthly funding goal and 332 Sponsors on GitHub! Shoutouts to everyone helping us reach our goals here. Your monthly sponsorship funds development and makes sure we have the resources we need to give you the best version of elementary OS we can! Monthly release candidate builds and daily Early Access builds are available to GitHub Sponsors from any tier! Beware that Early Access builds are not considered stable and you will encounter fresh issues when you run them. We’d really appreciate reporting any problems you encounter with the Feedback app or directly on GitHub.

11th Aug 2025 • 33 votes
Supporting Disability Is Our Social Responsibility

July is Disability Pride Month, an opportunity for us to consider how we’re serving our disabled community and work on breaking down barriers to access. Last year we had the pleasure of being introduced to Florian—a fully blind cybersecurity enthusiast—and thanks to his feedback we completely rewrote navigation in Onboarding to be more keyboard and screen reader friendly, as well as took another look at Installation and Initial Setup to vastly improve our entire first run experience for blind folks. Plus, we implemented the screen reader interface in the Alt + Tab window switcher. Thanks to this feedback, elementary OS 8 can be installed and set up completely blind, an important win for maintaining your independence as a person with vision disabilities. Danielle Foré Founder & CEO Wed, Jul 3, 2024 7 min read Since the release of OS 8 we’ve been working on things like improving contrast, support for Dark Mode screenshots and brand colors in AppCenter, turning on or snoozing Dark Mode without canceling your schedule, expanding the scope of the “Reduce Motion” setting, and adding more options to reduce distracting notification bubbles. Plus, thanks to feedback from Aaron who you may know from his blog series on Linux accessibility, Notifications and the Shortcut Overlay both got releases that add screen reader support. As a community that includes folks with a range of disabilities ourselves, we’re deeply invested in improving access to Open Source software. We succeed at our mission when we build open computing experiences that are available regardless of ability and fail when accessibility is considered an afterthought or a nice-to-have. This month and always, Inclusive Design is at the core of what we do and we will continue to strive towards that ideal. If you want to follow along or help us address accessibility issues in elementary OS, we’d love your help! We’re tracking issues in this GitHub project. If you discover a new issue—accessibility related or otherwise—we’d love to get your feedback and we have a handy contributor guide to help you file a report here. Code A big new release of Code is here, thanks primarily to Jeremy. This release closes 19 reported issues including a couple of crashers. The “Open in…” menu is now sorted and includes an option for the Terminal pane. Plus the Terminal pane now follows Natural Copy/Paste settings from the Terminal app. The Vala symbols pane now shows a lot more information about symbols in their tooltips. Numbered lists are now handled correctly by the Markdown plugin. The Highlight Word Selection plugin now works with selections of more than one word. Several enhancements were made to managing git branches including sorting branch names alphabetically, the ability to switch to remote branches, and you’ll now be asked how to handle uncommitted changes when switching branches. You can now create edit marks by clicking in the source view gutter. They can be jumped between via the context menu or with the keyboard shortcuts Alt + ← / →. If you’re using the Flatpak version of Code on another OS, the “Open in…” menu is no longer empty and operations that require a network should now work. Plus performance was improved in several cases. Window Manager & Dock This month Leonhard and Leo closed another 19 issue reports in our window manager, including several issues related to multi-monitor, the Multitasking View, and Dock behavior. A crash that could occur when closing LibreOffice windows was fixed. Picture-in-picture will now select the correctly window when its area selection is drawn over an app’s shadow. Non-flatpak apps that don’t correctly match their launchers can now sometimes be matched by the Dock anyways. If you have “activate hotcorners in fullscreen” turned on, you can also now access the Applications Menu with Super while playing a fullscreen game, for example. Plus we made some performance improvements to drawing shadows. System Settings In Keyboard → Shortcuts → Custom you can now choose from a list of installed apps and their actions—in addition to being able to execute custom commands—thanks to Leo. This makes it super straightforward to add a keyboard shortcut for your most common workflows like composing a new email or adding a new Calendar event. You can now create custom keyboard shortcuts for apps and their actions System Settings will also now warn you if your desired keyboard shortcut conflicts with a common system shortcut like “Copy”, “Paste”, or “New Tab”. Plus we fixed an issue that would prevent certain Housekeeping configurations from running, and the “Automatic” accent color option now works more reliably. And More The Screencast Portal now features an improved design for selecting which display or window should be captured, as well as respecting options for capturing the pointer. Plus we fixed issues that prevented screenshots from including window shadows in some cases, and screenshot notifications now open the Image Viewer when clicked. Screencasts portal has a new design Jeremy fixed a number of issues in the latest release of Files including issues related to file renaming, drag-and-drop, ejecting removable drives, and an issue activating context menus from certain parts of the sidebar. And he also fixed an issue preventing bluetooth file sharing from working. Plus, Leo made sure that panel transparency and orientation lock settings get synced to the Login & Lock screen. Get These Updates As always, pop open System Settings → System on elementary OS 8 and hit “Update All” to get these updates plus your regular security, bug fix, and translation updates. Or set up automatic updates and get a notification when updates are ready to install! Early Access Bluetooth Settings got a redesign and a reworking of its list sorting logic that should improve performance, reliability, and its screen reader experience. Especially of note, we now sort out more bluetooth devices so the list of nearby devices should be more concise and useful. Plus we fixed a few issues related to devices that require a passcode to pair, like some keyboards. This includes some fairly large changes so we could really use help testing for regressions before releasing this update for everyone. Bluetooth settings has a new design We’re also now building daily ARM64 Native images thanks to new contributer NN708. This is a universal ARM UEFI image, which means it should be a single image that runs on platforms like Raspberry Pi, Pinebook Pro, and Apple M-series Macs. This makes it a lot simpler for us to support ARM processors in future releasses of elementary OS. Please test these images on your ARM devices and report back! We now include additional processor architecture options in our issue report template to track any problems you experience. Download ARM64 Builds Sponsors At the moment we’re at 23% of our monthly funding goal and 322 Sponsors on GitHub! Shoutouts to everyone helping us reach our goals here. Your monthly sponsorship funds development and makes sure we have the resources we need to give you the best version of elementary OS we can! Monthly release candidate builds and daily Early Access builds are available to GitHub Sponsors from any tier! Beware that Early Access builds are not considered stable and you will encounter fresh issues when you run them. We’d really appreciate reporting any problems you encounter with the Feedback app or directly on GitHub.

2nd Jul 2025 • 47 votes

More in programming

Clip of me singing Despard in Ruddigore in 2013

A clip of me singing a funny song from Gilbert and Sullivan’s Ruddigore back in 2013

7 hours ago • 1 votes
How and Why fork() Uses Copy-on-Write

In this video, we look at why fork() needs copy-on-write, how it works inside the kernel, and a memory usage problem that Instagram encountered with Python.

13 hours ago • 1 votes
What we lost when we lost comments

Comments require commitment, but they’re worth it.

19 hours ago • 1 votes
Lighthouse map

Lovely global map with animated lights sweeping the waters

21 hours ago • 1 votes
Warming up the Puma master before it forks

Basecamp 5 runs on Puma in cluster mode: one master process with preload_app! and 63 single-threaded workers per host, deployed as a Docker container with Kamal. We serve Basecamp from several sites. Each site has its own web hosts and a read replica of the database, and writes go to a single primary database in one of them. On our busiest hosts, each deploy left up to 2,000 requests waiting while the new workers warmed up. We reduced those queues by running signed-in requests through the app in the Puma master, before it forked the workers. Why 63 single-threaded workers? Basecamp has always served web requests from processes rather than threads. It ran on Unicorn, which only does processes, until we moved to Puma in January 2025, and we kept the same setup: workers (Concurrent.physical_processor_count * 1.3).ceil threads 1, 1 preload_app! On a 48-core host that’s 63 workers, each handling one request at a time. We chose 1.3 after benchmarking HEY in 2023, when we moved our apps out of the cloud and onto our own hardware. We tested several combinations of workers and threads with a mix of GET and POST requests on a 32-vCPU VM. Every multithreaded configuration we tested was slower and handled fewer requests than single-threaded workers. Adding workers beyond about 1.2 to 1.3 per vCPU brought little benefit. The threaded workers spent a lot of their time waiting for Ruby’s global VM lock. That made single-threaded workers a good fit for this workload, and we use the same setup for Basecamp. An app that spends more time waiting on its database or other services may benefit from more threads, so benchmark your own app. The other reason is the app itself. Basecamp has class-level state in places and has never needed to be thread-safe. With one request per process, it still doesn’t. Processes do use more memory than threads, and preload_app! reduces the difference. The master loads the app once and the workers share its memory through copy-on-write until they write to it. Shopify’s comparison of Ruby execution models explains the trade-off well. In the HEY benchmark the best setup came to about 260 MB of PSS per core, where PSS counts each shared page once, split between the processes using it, and the gap to a threaded setup was smaller than we’d expected. What Puma does on each host when a container starts: one master, then 63 forked workers that share its memory until they write to it. Two things about this setup matter for the rest of the post. A worker that’s compiling or loading something is fully blocked — there’s no other thread to pick up the next request. And whatever the master has in memory before it forks, all 63 workers share. Whatever they build after the fork, they build 63 times. What happens when we deploy Kamal starts the new container alongside the old one, and kamal-proxy moves the host’s traffic across as soon as the health check passes. At that moment, the new workers have handled health checks but no customer requests. preload_app! means the master loads the app once and the workers inherit it through fork. That covers the code. It doesn’t cover anything Ruby and Rails set up on first use: YJIT compiled code. YJIT compiles a method once it’s been called a certain number of times. The master calls very little during boot, so every worker compiles the same methods again on its own first requests. Compiled templates. Action View turns each ERB template into a Ruby method the first time it’s rendered. The schema cache. Active Record reads each model’s columns from the database the first time that model is used. Inline caches and memoized values throughout Ruby, Rails and the app. All 63 workers did all of this at once, while serving the traffic the old container had been handling a second earlier. In the test environment with YJIT on, the first request to a project page on a cold process took 652 ms, 151 ms of it YJIT compiling. The same request to a warm process took 28 ms. In production, CPU time per request peaked at around 200 ms while kamal-proxy moved traffic to the new container, against about 30 ms once the workers had warmed up. A host with spare CPU absorbs this. Every one of our web hosts has 48 cores and 63 workers, but each Amsterdam host serves around 250 requests per second, against 25 to 60 at our other sites. In Amsterdam the slow first requests turned into a queue. At a peak-hour deploy, the Puma backlog on an Amsterdam host reached anywhere from 250 to 2,238 requests, and kamal-proxy’s p99 response time hit about 10 seconds. Eron, our Director of Operations, had been tracking this since June. Another server in Amsterdam would help, but it would take weeks to arrive, so we also wanted to make deploys cheaper on the hardware we already had. What didn’t work We tried a few things first. In June, Donal tested the first two on a single Amsterdam host, comparing it with its neighbors, and they ruled out two likely causes. Warming each worker’s database connections. Puma’s before_fork hook clears the master’s connections, and each worker opened its own on its first request. Opening them in before_worker_boot instead made no difference. Queries on a freshly booted production host were already under a millisecond, so connections weren’t the problem. A synthetic request in each worker. Next, each worker made a few requests in before_worker_boot to an internal controller that touched every model. That ran the middleware, routing and Active Record paths, but it ran them in 63 workers at once — exactly the CPU spike we were trying to avoid. And a request with no real data renders no real views, so most of the app stayed cold. Spreading YJIT compilation out. Delaying YJIT in each worker by a random interval spread the compiling out over a few minutes, but every worker still ran interpreted until its delay ended. The queue didn’t change. Reforking from a warm worker. This is what Shopify’s Pitchfork does: let one worker serve traffic until it’s warm, then fork the others from it. Puma has an experimental version called fork_worker, and on beta it worked — the reforked workers were warm after three to five requests, where fresh ones took up to 30 seconds. But with fork_worker the template is worker 0, and it keeps serving requests. If it exits, the workers waiting to be forked never start (puma/puma#3596). If it gets no traffic, the refork never happens, which is what we saw on beta. Instacart have a mold_worker patch that promotes a warm worker to a template that stops serving, but it isn’t in a Puma release. We have a branch of it, and we may come back to it. That last experiment did show us where the fix was, though. Everything a warm worker has that a cold one lacks is in its memory, and fork copies memory. The master already has the app loaded. It just never runs it. Run the requests in the master So now, before the master binds its socket and forks, it makes the app’s own requests, in-process, the way a signed-in user would. Rack has a hook for exactly this. Rack::Builder#warmup takes a block that’s called once with the built app, before the server starts. rails server builds the app from config.ru, so the change to boot is one line: require_relative "config/environment" warmup { WarmUp.configured.run } if ENV["WARM_UP"] run Rails.application With preload_app! this runs in the master, and the workers inherit whatever it did. Puma binds its socket after the app is built, so until the warm-up finishes the health check’s connection is refused and kamal-proxy keeps retrying. No request reaches a worker that hasn’t been warmed. The warm-up has three steps. After precompiling the views, it gives the page requests and schema loading a shared 20-second budget, checked before each page or model. 1. Precompile the views actionview_precompiler reads every template for its render calls and compiles each one with the locals it’s passed. For us that’s 1,394 templates in about two seconds. A first request to a project page then compiles 2 templates instead of 44. 2. Request the pages, signed in A small browser class makes the requests through Rack::MockRequest, with the two cookies a real sign-in sets, then goes back for each page’s lazy Turbo frames: class WarmUp::Browser def initialize(signed_in_as:) @client = Rack::MockRequest.new(Rails.application) @headers = { "HTTP_USER_AGENT" => "Basecamp warm-up", "HTTP_COOKIE" => cookie_for(signed_in_as), "bc3.warm_up" => true } end def visit(path) page = get(path) frames_in(page).each { |id, src| get(src, "HTTP_TURBO_FRAME" => id) } end private def get(path, headers = {}) @client.get("https://#{host}#{path}", @headers.merge(headers)) end def frames_in(page) Nokogiri::HTML5(page.body).css("turbo-frame[src]").map { |frame| [ frame["id"], frame["src"] ] } end end The requests are signed in. The user is a monitoring account we already use for automated checks, and the pages are its own project, Campfire, to-dos, documents and messages. Public pages weren’t enough: after warming up with signed-out pages only, the first signed-in request to the projects page still took 131 ms, because authentication, the signed-in controllers and their views had never run. With signed-in pages it took 40 ms. cookie_for writes the same signed cookie the sign-in controller does, using the app’s own cookie jar, so there’s no API token and no secret to store. The frames are followed. The busiest HTML requests in production aren’t pages at all but Turbo frames — the sidebar badge, the inbox, the navigation menus. The browser parses each page and requests its <turbo-frame src> URLs with the Turbo-Frame header, so those controllers and views get warmed too. Our first four pages turned into 60 requests. The requests are excluded from rate limiting. They are internal, so they do not count against the rate limits that apply to real visitors. 3. Load the rest of the schema The page requests load the schema for the models they touch. The last step loads the rest, from the read replica: ApplicationRecord.reading do models.lazy.take_while { time_left? }.each { |model| model.load_schema if model.table_exists? } end The step checks 261 models and loads any schema information still missing. Those database round trips add up when the primary is far away: outside a request, Active Record uses the writing role, and from a host a long way from the primary each round trip is tens of milliseconds. Reading from the local replica brings the step down from about 20 seconds to 3.5. The pages go first because they load most of the schema anyway. If the time budget runs out, the step stops, logs how many models it got through, and the workers load the rest on first use like they always did. Rails can also load the schema from a dumped cache file at boot (bin/rails db:schema:cache:dump), which would make this step unnecessary. We don’t ship one in our image yet, because the dump needs a database to read from at build time, and we have several databases to cover. It’s on the list. What to close before the fork Running requests in the master opens things the master never opened before, and every worker inherits them. Two processes writing to the same socket will corrupt each other’s traffic, so you need to know what’s open before you fork. The way to find out is to list the master’s open file descriptors — ls -l /proc/<pid>/fd — before and after a warm-up, in an environment set up like production. Development wasn’t enough for us: it stores files on disk, so our S3 connections only showed up in production. Then, for each thing that’s open, check how its library handles a fork. We found three kinds: Already handled. Plenty of libraries detect a fork on their own, either by recording the PID they connected from and reconnecting in the child, by opening per-process files, or by resetting their thread pools. Redis clients, metrics libraries and concurrency libraries tend to be in this group. Check, but you probably don’t need to do anything. Already closed. Database connections are the classic one, and most Puma configs already clear them in before_fork. Anything else that’s opened per process — we have a SQLite cache the workers open on boot — needs closing when the warm-up finishes. Needs a new step. HTTP clients with keep-alive connections are the ones to look for: cloud SDKs with connection pools, tracing exporters, error reporters. They usually have no fork handling at all. We empty the aws-sdk connection pools in before_fork, and we run the warm-up untraced so the OpenTelemetry exporter never opens its connection to Tempo in the first place. Once that’s done, before_fork finishes with Process.warmup, which Ruby 3.3 added for this purpose: a major GC, a heap compaction, and every surviving object promoted to the old generation, so the memory pages the workers share change as little as possible afterwards. Choosing the pages The first list was the four pages that ran the busiest requests on beta. Once the warm-up was live, production showed us which endpoints were still cold. For one deploy, we compared each endpoint’s mean duration in the six minutes after kamal-proxy moved traffic to the new container with the same endpoint an hour later, then multiplied the difference by the number of requests in those six minutes. That gives the extra time each endpoint cost us because it was cold: Endpoint Cold Warm Requests in 6 min Extra seconds Campfire 246 ms 70 ms 6,490 1,140 Projects (JSON API) 84 ms 50 ms 22,077 771 Docs & Files 262 ms 177 ms 4,996 421 To-dos tool 205 ms 113 ms 4,018 371 To-dos (JSON API) 33 ms 16 ms 18,738 320 The pages already in the warm-up showed what to expect: the project page kept a 36 ms gap after a deploy, and the to-do page 10 ms. We’ve proposed adding these five requests, and expect them to add about five to seven seconds to the page step. The two JSON endpoints were a surprise. The warm-up’s page list had no API requests in it, so nothing on the API path had run before the first real request: not the API controllers, and not the Jbuilder templates rendering real records. Precompiling the views covers JSON templates too, but it isn’t a substitute for running the request. Results The warm-up is on for all 68 web hosts. With the first four pages it took 12 to 16 seconds per host: about 2 seconds to precompile the views, 7 to 9 for the 60 requests, and 3.5 for the schema. Deploys take that much longer per host, and we raised the deploy timeout from 30 to 60 seconds to cover it. In Amsterdam, at a peak-hour deploy: During deploy Before After Peak Puma backlog per host 250–2,238 requests 19–223 requests Peak kamal-proxy p99 about 10 s 2.4–4.8 s Peak CPU time per request 201–214 ms 88–132 ms Peak database time per request 56–69 ms 39–47 ms The same eight hosts at three deploys on 1 October, an hour apart, as the warm-up went from one host to four to all eight. The deploy in the middle, with four hosts warmed and four not, shows why every host needed the warm-up. Each warmed host recovered faster on its own: mean request duration peaked at 130 to 173 ms, against 203 to 311 ms on the hosts that weren’t warmed. But the backlog on all eight was about the same, because they were all waiting on the same database. Mean request duration on each host at the 07:21 UTC deploy. Blue hosts warmed up in the master before forking, orange hosts did not. Memory came down too. The workers now share compiled templates, YJIT code and the schema with the master instead of each building their own copy. On beta, the view precompiler alone took a busy worker’s private memory from 174–202 MB to 119–135 MB. Thirty minutes after the deploy, the web containers used about 39 GB less memory than the previous day’s containers at the same age and traffic. Amsterdam served most of our traffic at the times we tested. In Amsterdam, each new container used about 2 GB less just after traffic moved to it, which lowers the peak while the old and new containers overlap. Working with Claude Claude Code helped throughout. It combed through the per-worker backlogs and per-endpoint timings in Prometheus and Loki after each deploy, worked out the cold-versus-warm cost of each endpoint, and prepared the changes and the pull request descriptions with the benchmarks in them. We decided what to try, deployed it and read the results. If you do this Warm the master before it forks. Compile common code and templates and load their schema in the master, so workers inherit that work. With preload_app!, Rack::Builder#warmup runs before the workers start accepting traffic. Use the app’s real requests. Public pages, internal endpoints and synthetic queries warm the paths they run and nothing else. Signed-in requests to real records, frames included, run what production runs. Measure the cold penalty per endpoint. The difference between an endpoint’s cold and warm duration, times its request count after a deploy, ranks the pages worth adding. Ours weren’t the ones we’d have guessed, and two of them were JSON. Check what the warm-up leaves open. List the master’s file descriptors after a warm-up and account for every one before the fork. Two of ours needed changes. Set a time budget. A warm-up that runs long on one slow host fails the deploy on that host. Ours gives the page requests and schema loading a shared 20-second budget, checked before each page or model, puts the most valuable pages first, and logs what it skipped. Reforking from a warm worker, as Pitchfork does, solves the same problem continuously rather than once at boot, and it would warm paths no fixed list of pages covers. We may still get there: our branch brings Instacart’s mold_worker up to date with Puma’s main branch and fixes the bugs we found in it. But warming the master works with the Puma we already run, took a few days to implement, and substantially reduced the queues after deployment.

yesterday • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in