Full Width [alt+shift+f] FOCUS MODE Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
36
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...
2 months ago

Comments

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from elementary Blog

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.

a month ago 23 votes
The First Pride Was a Riot, and So Are These Updates

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, the Reduce Motion setting now covers a whole new range of animations—perfect for folks who get motion sick or find animations distracting. Leonardo tackled a couple of crashes in Display settings including one when mirroring, and another when new displays are attached while System Settings is open. We fixed an issue that prevented CalDAV accounts from connecting in Online Accounts settings. And Alain snuck in a few design tweaks, fixing button alignments etc. And More Thanks to feedback from Aaron, Notifications and the Shortcut Overlay both got releases that add screen reader support. Corentin addressed some Flatpak sandbox issues with an updated Apparmor Profile—especially notable if you’d had trouble with Steam. We now use BeaconDB as our location services provider. And thanks to Ryo we’re now shipping the latest version of GNOME Web which brings improved performance and web compatibility as well as a redesigned bookmarks sidebar. 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! Community Pride I want to take a little space to say that our community is for everyone regardless of gender or sexual identity. We’ve long been made up of lots of different kinds of folks and I’m really proud of that. Open Source software should never be a space that is restricted to a narrow set of identities. In a time where many companies are withdrawing their support for the LGBTQIA+ community, I think it’s incredibly important that we make a strong statement against hate and don’t give in to the pressure to erase queer people in some sad attempt to be “apolitical”. Free Software has always been political, and its politics are freedom and inclusivity and so are ours. Sponsors At the moment we’re at 23% of our monthly funding goal and 336 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.

3 months ago 33 votes
A Little Bit Now, A Lotta Bit Later

In mid-March we released a big bug fix update—elementary OS 8.0.1—and since then we’ve been hard at work on even more bug fixes and some new exciting features that I’m excited to share with you today! Read ahead to find out what we’ve released recently and what you can help us test in Early Access. Quick Settings Quick Settings has a new “Prevent Sleep” toggle Leo added a new “Prevent Sleep” toggle. This is useful when you’re giving a presentation or have a long-running background task where you want to temporarily avoid letting the computer go to sleep on its normal schedule. We also fixed a bug where the “Dark Mode” toggle would cancel the dark mode schedule when used. We now have proper schedule snoozing, so when you manually toggle Dark Mode on or off while using a timed or sunset-to-sunrise schedule, your schedule will resume on the next schedule change instead of being canceled completely. Vishal also fixed an issue that caused some apps to report being improperly closed on system shutdown or restart and on the lock screen we now show the “Suspend” button rather than the “Lock” button. System Settings Locale settings has a fresh layout thanks to Alain with its options aligned more cleanly and improved links to additional settings. Locale Settings has a more responsive design We’ve also added the phrase “about this device” as a search term for the System page and improved interface copy when a restart is required to finish installing updates based on your feedback. Plus, Stanisław improved stylus detection in Wacom settings preventing a crash when no stylus is found. AppCenter We now show a small label next to the download button for apps which contain in-app purchases. This is especially useful for easily identifying free-to-play games or alt stores like Steam or Heroic Games Launcher. AppCenter now shows when apps have in-app purchases Plus, we now reload app icons on-the-fly as their data is processed, thanks to Italo. That means you’ll no longer get occasionally stuck with an AppCenter which shows missing images for app’s who have taken a bit longer than usual to load. 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 Our development focus recently has been on some of the bigger features that will likely land for either elementary OS 8.1 or 9. We’ve got a new app, big changes to the design of our desktop itself, a whole lot of under-the-hood cleanup, and the return of some key system services thanks to a new open source project. Monitor We’re now shipping a System Monitor app by default By popular demand—and thanks to the hard work of Stanisław—we have a new system monitor app called “Monitor” shipping in Early Access. Monitor provides usage information for your processor, GPU, memory, storage, network, and currently running processes. You can optionally see system information in the panel with Monitor You can also optionally get a ton of glanceable information shown in the panel. There’s currently a lot of work happening to port Monitor to GTK4 and improve its functionality under the Secure Session, so make sure to report any issues you find! Multitasking The Dock is getting a workspace switcher Probably the biggest change to the Pantheon shell since its early inception, the Dock is getting a new workspace switcher! The workspace switcher works in a familiar way to the one you may have seen in the Multitasking View: Your currently open workspaces are represented as tiles with the icons of apps running on them; You can select a workspace to switch to it; You can drag-and-drop workspaces to rearrange them; And you can use the “+” button to create a new blank workspace. One new trick however is that selecting the workspace you’re already on will launch Multitasking View. The new workspace switcher makes it so much more accessible to multitask with just the mouse and get an overview of your workflows without having to first enter the Multitasking View. We’re really excited to hear what people think about it! You can close apps from Multitasking View by swiping up Another very satisfying feature for folks using touch input, you can now swipe up windows in the Multitasking View to close them. This is a really familiar gesture for those of us with Android and iOS devices and feels really natural for managing a big stack of windows without having to aim for a small “x” button. GTK4 Porting We’ve recently landed the port of Tasks to GTK4. So far that comes with a few fixes to tighten up its design, with much more possible in the future. Please make sure to help us test it thoroughly for any regressions! Tasks has a slightly tightened up design We’re also making great progress on porting the panel to GTK4. So far we have branches in review for Nightlight, Bluetooth, Datetime, and Network indicators. Power, Keyboard, and Quick Settings indicators all have in-progress branches. That leaves just Applications, Sound, and Notifications. So far these ports don’t come with major feature changes, but they do involve lots of cleaning up and modernizing of these code bases and in some cases fixing bugs! When the port is finished, we should see immediate performance gains and we’ll have a much better foundation for future releases. You can follow along with our progress porting everything to GTK4 in this GitHub Project. And More When you take a screenshot using keyboard shortcuts or by secondary-clicking an app’s window handle, we now send a notification letting you know that it was succesful and where to find the resulting image. Plus there’s a handy button that opens Files with your screenshot pre-selected. We’re also testing beaconDB as a replacement for Mozilla Location Services (MLS). If you’re not aware, we relied on MLS in previous versions of elementary OS to provide location information for devices that don’t have a GPS radio. Unfortunately Mozilla discontinued the service last June and we’ve been left without a replacement until now. Without these services, not only did maps and weather apps cease to function, but system features like automatic timezone detection and features that rely on sunset and sunrise times no longer work properly. beaconDB offers a drop-in replacement for MLS that uses Wireless networks, bluetooth devices, and cell towers to provide location data when requested. All of its data is crowd-sourced and opt-in and several distributions are now defaulting to using it as their location services data provider. I’ve set up a small sponsorship from elementary on Liberapay to support the project. If you can help support beaconDB either by sponsoring or providing stumbler data, I’d highly encourage you to do so! Sponsors At the moment we’re at 23% of our monthly funding goal and 336 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.

4 months ago 44 votes
elementary OS 8.0.1 Available Now

It’s been a little over 100 days since elementary OS 8 was released, and we’re proud to announce another round of updates, including a fresh new download. We’ve been hard at work this winter addressing issues that you reported and we’ve added a couple new creature comforts along the way. This bug fix release also includes the latest Ubuntu LTS Hardware Enablement Kernel, so it’s worth checking out if you downloaded OS 8.0 and it disagreed with your hardware. AppCenter We now properly use dark mode brand colors and dark mode screenshots thanks to Italo. Plus, when developers provide screenshots for multiple desktop environments, we now prefer the ones intended for our desktop environment, Pantheon. We support the new <Developer> Appstream tag, thanks to Juan. And we now support the contribute URL type. AppCenter now shows dark mode screenshots when available Italo also fixed some issues with release notes overflowing out of their container, and we slightly redesigned the release notes window in the Updates page. He also addressed a few other issues in the Updates page that could occur while things were being updated or refreshed and made sure AppCenter recovers gracefully when its cache is emptied. Release notes dialogs have been slightly redesigned Search is also much faster thanks to Leonhard. And for developers, Ryo fixed loading your local metadata for testing with the --load-local terminal option. Files & Terminal Jeremy fixed another half-dozen reported issues in Files, including an issue that prevented entering file paths in search mode, an issue that prevented scrolling after deleting files, and an issue where files would disappear when dropped on an unmounted drive. The New file submenu now respects the hierarchy of folders in Templates. We now also respect the admin:// uri protocol for opening a path as an administrator, and Files is now styled correctly when run as administrator. He also fixed an issue where Terminal tabs took multiple clicks to focus, and an issue where keyboard shortcuts stopped working for tabs that had been dragged into their own new window. Plus, file paths and names are also now properly quoted when drag-and-dropped from Files into Terminal. System Settings System Settings now allows configuring its notifications in System Settings → Notications. So you can turn off bubbles if you don’t want to receive notifications about updates, for example. We’ll also no longer automatically download updates when on metered connections and send a notification instead, thanks to Leonhard. Plus we no longer check for updates in Demo Mode. Updates now show their download size and you can see progress towards our monthly sponsorship goal In System, Vishal made sure we show how large an update will be before downloading it and that we skip held-back packages—such as phased or staged updates—when preparing the updates bundle so that it will more reliably succeed. Alain added a progress bar while downloading. And Ryo made sure the last refresh time is more accurate when no updates are available. Alain also added a new progress bar that represents how close we are to meeting our monthly sponsorship goal. In Applications, you can now disallow notifications access. This is especially useful for apps which use the notifications portal, but don’t properly report their notification usage and can’t be controlled in the Notifications settings page. Reign in apps that don’t appear in Notifications settings In Network there are two new settings: whether a network should be automatically connected to when available and whether to reduce background data usage when connected to that network. Disable autoconnect or mark a network as metered We also updated the pointer icons in Mouse & Touchpad settings and the checkmarks in Locale settings will now respect your chosen accent color. Plus settings pages with sidebars now remember the width you adjusted them to, thanks to Alain. Installation & Onboarding David fixed a crash with certain partitioning schemes in the Installer’s custom install view. And the Encryption step was redesigned to fit on a single page, solving an issue with confusing navigation. Plus, onboarding will now always stay centered on the screen, even when resized. Panel & Quick Settings Ilya fixed an issue with the panel height when using the Classic session and HiDPI displays. The app context menu in the Applications menu now shows a “Keep in Dock” checkbox, just like in the Dock thanks to Stella. In the Power menu, we now show the device model if available, and avoid erroneously showing an empty battery icon thanks to Alain. In the Sound menu, Dmitry fixed loading album art from certain apps like Google Chrome, and we fixed an issue where player icons could become too large. See who else is logged in and quickly switch accounts from Quick Settings In Quick settings, Leonhard fixed an issue with performing updates while shutting down. And Alain added a new page where you can see which other people are logged in and quickly switch between accounts. Dock Leo added a bit more spacing between launchers and their running indicators, and fixed an issue where larger icons could be clipped at the peak of their bounce animation. Apps who don’t notify on startup will no longer bounce in the dock indefinitely, thanks to Leonhard. We fixed an issue where the dock would still receive click events while hidden in the Classic session. Plus the dock now has an opaque style when “Panel Translucency” is turned off in System Settings → Desktop → Dock & Panel. Window Manager We have another huge release of our window manager thanks to Leonhard and Leo. This release fixes five potential crashes, over a dozen reported issues, fixes related to both the Classic and Secure sessions, issues related to HiDPI, and more, plus performance improvements. It’s worth reading the full release notes on GitHub if you have been waiting for the fix for a specific issue. And More OS 8.0.1 includes the latest long-term support Hardware Enablement stack from Ubuntu, including Linux 6.11. This brings improved performance for AMD processors, support for Intel “Lunar Lake” processors, and filesystem performance improvements in some cases. Plus support for certain webcams, USB network devices, joysticks, and more. Leo fixed an issue where connecting Bluetooth devices could cause the Lock Screen to freeze. You can now close the captive network assistant with the keyboard shortcut Ctrl + Q, thanks to Stanisław. And Alain fixed copying screenshots to the clipboard. We fixed an issue where wired network connections could fail to connect due to a change in Ubuntu. We’re pursuing this issue upstream and working on a way to ship the fix as an update, but for now fixing this issue requires either manual intervention through Terminal or a reinstall. We also now pre-install an AppArmor profile that fixes a number of Flatpak-related issues like not being to install certain runtime updates or apps not launching in the guest session or Demo mode. Special thanks to Uncle Tallest for investigating this issue and helping folks in our Discord who ran into it. And of course this release comes with a ton of translation updates! Special thanks to our hard-working internationalization community and especially Ryo who fixed a number of issues with things that couldn’t be localized properly in the previous release. Get elementary OS 8.0.1 elementary OS 8.0.1 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.1 Sponsors have been able to download OS 8.0.1 release candidates since last week, so if getting things before anyone else is important to you, consider sponsoring us on GitHub

5 months ago 72 votes

More in programming

Performant Full-Disk Encryption on a Raspberry Pi, but Foiled by Twisty UARTs

In my post yesterday (“ARM is great, ARM is terrible (and so is RISC-V)), I described my desire to find ARM hardware with AES instructions to support full-disk encryption, and the poor state of the OS ecosystem around the newer ARM boards. I was anticipating buying either a newer ARM SBC or an x86 mini … Continue reading Performant Full-Disk Encryption on a Raspberry Pi, but Foiled by Twisty UARTs →

11 hours ago 3 votes
Words are not violence

Debates, at their finest, are about exploring topics together in search for truth. That probably sounds hopelessly idealistic to anyone who've ever perused a comment section on the internet, but ideals are there to remind us of what's possible, to inspire us to reach higher — even if reality falls short. I've been reaching for those debating ideals for thirty years on the internet. I've argued with tens of thousands of people, first on Usenet, then in blog comments, then Twitter, now X, and also LinkedIn — as well as a million other places that have come and gone. It's mostly been about technology, but occasionally about society and morality too. There have been plenty of heated moments during those three decades. It doesn't take much for a debate between strangers on this internet to escalate into something far lower than a "search for truth", and I've often felt willing to settle for just a cordial tone! But for the majority of that time, I never felt like things might escalate beyond the keyboards and into the real world. That was until we had our big blow-up at 37signals back in 2021. I suddenly got to see a different darkness from the most vile corners of the internet. Heard from those who seem to prowl for a mob-sanctioned opportunity to threaten and intimidate those they disagree with. It fundamentally changed me. But I used the experience as a mirror to reflect on the ways my own engagement with the arguments occasionally felt too sharp, too personal. And I've since tried to refocus way more of my efforts on the positive and the productive. I'm by no means perfect, and the internet often tempts the worst in us, but I resist better now than I did then. What I cannot come to terms with, though, is the modern equation of words with violence. The growing sense of permission that if the disagreement runs deep enough, then violence is a justified answer to settle it. That sounds so obvious that we shouldn't need to state it in a civil society, but clearly it is not. Not even in technology. Not even in programming. There are plenty of factions here who've taken to justify their violent fantasies by referring to their ideological opponents as "nazis", "fascists", or "racists". And then follow that up with a call to "punch a nazi" or worse. When you hear something like that often enough, it's easy to grow glib about it. That it's just a saying. They don't mean it. But I'm afraid many of them really do. Which brings us to Charlie Kirk. And the technologists who name drinks at their bar after his mortal wound just hours after his death, to name but one of the many, morbid celebrations of the famous conservative debater's death. It's sickening. Deeply, profoundly sickening. And my first instinct was exactly what such people would delight in happening. To watch the rest of us recoil, then retract, and perhaps even eject. To leave the internet for a while or forever. But I can't do that. We shouldn't do that. Instead, we should double down on the opposite. Continue to show up with our ideals held high while we debate strangers in that noble search for the truth. Where we share our excitement, our enthusiasm, and our love of technology, country, and humanity. I think that's what Charlie Kirk did so well. Continued to show up for the debate. Even on hostile territory. Not because he thought he was ever going to convince everyone, but because he knew he'd always reach some with a good argument, a good insight, or at least a different perspective. You could agree or not. Counter or be quiet. But the earnest exploration of the topics in a live exchange with another human is as fundamental to our civilization as Socrates himself. Don't give up, don't give in. Keep debating.

9 hours ago 2 votes
first-class merges and cover letters

Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it’s not yet clearly superior to Magit. But I have been following jj discussions with great interest. One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn’t have branch names that always automatically refer to the tip. This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git’s branches are unsatisfactory, and what could be done to improve them. branch merge rebase squash fork cover letters previous branch workflow questions branch One of the huge improvements in git compared to Subversion was git’s support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can’t merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development. The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence. Let’s consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point. merge A basic merge workflow is, create a feature branch hack, hack, review, hack, approve merge back to the trunk The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk. Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit message for merges, that hides what you did to resolve the conflicts. If the feature branch is a linear record of the work then it can be cluttered with commits to address comments from reviewers and to fix mistakes. Some people like an accurate record of the history, but others prefer the repository to contain clean logical changes that will make sense in years to come, keeping the clutter in the code review system. rebase A rebase-oriented workflow deals with the problems of the merge workflow but introduces new problems. Primarily, rebasing is intended to produce a tidy logical commit history. And when a feature branch is rebased onto the trunk before it is merged, a simple fast-forward check makes it trivial to verify that the merge will be clean (whether it uses separate merge commit or directly fast-forwards the trunk). However, it’s hard to compare the state of the feature branch before and after the rebase. The current and previous tips of the branch (amongst other clutter) are recorded in the reflog of the person who did the rebase, but they can’t share their reflog. A force-push erases the previous branch from the server. Git forges sometimes make it possible to compare a branch before and after a rebase, but it’s usually very inconvenient, which makes it hard to see if review comments have been addressed. And a reviewer can’t fetch past versions of the branch from the server to review them locally. You can mitigate these problems by adding commits in --autosquash format, and delay rebasing until just before merge. However that reintroduces the problem of merge conflicts: if the autosquash doesn’t apply cleanly the branch should have another round of review to make sure the conflicts were resolved OK. squash When the trunk consists of a sequence of merge commits, the --first-parent log is very uninformative. A common way to make the history of the trunk more informative, and deal with the problems of cluttered feature branches and poor rebase support, is to squash the feature branch into a single commit on the trunk instead of mergeing. This encourages merge requests to be roughly the size of one commit, which is arguably a good thing. However, it can be uncomfortably confining for larger features, or cause extra busy-work co-ordinating changes across multiple merge requests. And squashed feature branches have the same merge conflict problem as rebase --autosquash. fork Feature branches can’t always be short-lived. In the past I have maintained local hacks that were used in production but were not (not yet?) suitable to submit upstream. I have tried keeping a stack of these local patches on a git branch that gets rebased onto each upstream release. With this setup the problem of reviewing successive versions of a merge request becomes the bigger problem of keeping track of how the stack of patches evolved over longer periods of time. cover letters Cover letters are common in the email patch workflow that predates git, and they are supported by git format-patch. Github and other forges have a webby version of the cover letter: the message that starts off a pull request or merge request. In git, cover letters are second-class citizens: they aren’t stored in the repository. But many of the problems I outlined above have neat solutions if cover letters become first-class citizens, with a Jujutsu twist. A first-class cover letter starts off as a prototype for a merge request, and becomes the eventual merge commit. Instead of unhelpful auto-generated merge commits, you get helpful and informative messages. No extra work is needed since we’re already writing cover letters. Good merge commit messages make good --first-parent logs. The cover letter subject line works as a branch name. No more need to invent filename-compatible branch names! Jujutsu doesn’t make you name branches, giving them random names instead. It shows the subject line of the topmost commit as a reminder of what the branch is for. If there’s an explicit cover letter the subject line will be a better summary of the branch as a whole. I often find the last commit on a branch is some post-feature cleanup, and that kind of commit has a subject line that is never a good summary of its feature branch. As a prototype for the merge commit, the cover letter can contain the resolution of all the merge conflicts in a way that can be shared and reviewed. In Jujutsu, where conflicts are first class, the cover letter commit can contain unresolved conflicts: you don’t have to clean them up when creating the merge, you can leave that job until later. If you can share a prototype of your merge commit, then it becomes possible for your collaborators to review any merge conflicts and how you resolved them. To distinguish a cover letter from a merge commit object, a cover letter object has a “target” header which is a special kind of parent header. A cover letter also has a normal parent commit header that refers to earlier commits in the feature branch. The target is what will become the first parent of the eventual merge commit. previous branch The other ingredient is to add a “previous branch” header, another special kind of parent commit header. The previous branch header refers to an older version of the cover letter and, transitively, an older version of the whole feature branch. Typically the previous branch header will match the last shared version of the branch, i.e. the commit hash of the server’s copy of the feature branch. The previous branch header isn’t changed during normal work on the feature branch. As the branch is revised and rebased, the commit hash of the cover letter will change fairly frequently. These changes are recorded in git’s reflog or jj’s oplog, but not in the “previous branch” chain. You can use the previous branch chain to examine diffs between versions of the feature branch as a whole. If commits have Gerrit-style or jj-style change-IDs then it’s fairly easy to find and compare previous versions of an individual commit. The previous branch header supports interdiff code review, or allows you to retain past iterations of a patch series. workflow Here are some sketchy notes on how these features might work in practice. One way to use cover letters is jj-style, where it’s convenient to edit commits that aren’t at the tip of a branch, and easy to reshuffle commits so that a branch has a deliberate narrative. When you create a new feature branch, it starts off as an empty cover letter with both target and parent pointing at the same commit. Alternatively, you might start a branch ad hoc, and later cap it with a cover letter. If this is a small change and rebase + fast-forward is allowed, you can edit the “cover letter” to contain the whole change. Otherwise, you can hack on the branch any which way. Shuffle the commits that should be part of the merge request so that they occur before the cover letter, and edit the cover letter to summarize the preceding commits. When you first push the branch, there’s (still) no need to give it a name: the server can see that this is (probably) going to be a new merge request because the top commit has a target branch and its change-ID doesn’t match an existing merge request. Also when you push, your client automatically creates a new instance of your cover letter, adding a “previous branch” header to indicate that the old version was shared. The commits on the branch that were pushed are now immutable; rebases and edits affect the new version of the branch. During review there will typically be multiple iterations of the branch to address feedback. The chain of previous branch headers allows reviewers to see how commits were changed to address feedback, interdiff style. The branch can be merged when the target header matches the current trunk and there are no conflicts left to resolve. When the time comes to merge the branch, there are several options: For a merge workflow, the cover letter is used to make a new commit on the trunk, changing the target header into the first parent commit, and dropping the previous branch header. Or, if you like to preserve more history, the previous branch chain can be retained. Or you can drop the cover letter and fast foward the branch on to the trunk. Or you can squash the branch on to the trunk, using the cover letter as the commit message. questions This is a fairly rough idea: I’m sure that some of the details won’t work in practice without a lot of careful work on compatibility and deployability. Do the new commit headers (“target” and “previous branch”) need to be headers? What are the compatibility issues with adding new headers that refer to other commits? How would a server handle a push of an unnamed branch? How could someone else pull a copy of it? How feasible is it to use cover letter subject lines instead of branch names? The previous branch header is doing a similar job to a remote tracking branch. Is there an opportunity to simplify how we keep a local cache of the server state? Despite all that, I think something along these lines could make branches / reviews / reworks / merges less awkward. How you merge should me a matter of your project’s preferred style, without interference from technical limitations that force you to trade off one annoyance against another. There remains a non-technical limitation: I have assumed that contributors are comfortable enough with version control to use a history-editing workflow effectively. I’ve lost all perspective on how hard this is for a newbie to learn; I expect (or hope?) jj makes it much easier than git rebase.

yesterday 6 votes
ARM is great, ARM is terrible (and so is RISC-V)

I’ve long been interested in new and different platforms. I ran Debian on an Alpha back in the late 1990s and was part of the Alpha port team; then I helped bootstrap Debian on amd64. I’ve got somewhere around 8 Raspberry Pi devices in active use right now, and the free NNCPNET Internet email service … Continue reading ARM is great, ARM is terrible (and so is RISC-V) →

2 days ago 4 votes
Many Hard Leetcode Problems are Easy Constraint Problems

In my first interview out of college I was asked the change counter problem: Given a set of coin denominations, find the minimum number of coins required to make change for a given number. IE for USA coinage and 37 cents, the minimum number is four (quarter, dime, 2 pennies). I implemented the simple greedy algorithm and immediately fell into the trap of the question: the greedy algorithm only works for "well-behaved" denominations. If the coin values were [10, 9, 1], then making 37 cents would take 10 coins in the greedy algorithm but only 4 coins optimally (10+9+9+9). The "smart" answer is to use a dynamic programming algorithm, which I didn't know how to do. So I failed the interview. But you only need dynamic programming if you're writing your own algorithm. It's really easy if you throw it into a constraint solver like MiniZinc and call it a day. int: total; array[int] of int: values = [10, 9, 1]; array[index_set(values)] of var 0..: coins; constraint sum (c in index_set(coins)) (coins[c] * values[c]) == total; solve minimize sum(coins); You can try this online here. It'll give you a prompt to put in total and then give you successively-better solutions: coins = [0, 0, 37]; ---------- coins = [0, 1, 28]; ---------- coins = [0, 2, 19]; ---------- coins = [0, 3, 10]; ---------- coins = [0, 4, 1]; ---------- coins = [1, 3, 0]; ---------- Lots of similar interview questions are this kind of mathematical optimization problem, where we have to find the maximum or minimum of a function corresponding to constraints. They're hard in programming languages because programming languages are too low-level. They are also exactly the problems that constraint solvers were designed to solve. Hard leetcode problems are easy constraint problems.1 Here I'm using MiniZinc, but you could just as easily use Z3 or OR-Tools or whatever your favorite generalized solver is. More examples This was a question in a different interview (which I thankfully passed): Given a list of stock prices through the day, find maximum profit you can get by buying one stock and selling one stock later. It's easy to do in O(n^2) time, or if you are clever, you can do it in O(n). Or you could be not clever at all and just write it as a constraint problem: array[int] of int: prices = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8]; var int: buy; var int: sell; var int: profit = prices[sell] - prices[buy]; constraint sell > buy; constraint profit > 0; solve maximize profit; Reminder, link to trying it online here. While working at that job, one interview question we tested out was: Given a list, determine if three numbers in that list can be added or subtracted to give 0? This is a satisfaction problem, not a constraint problem: we don't need the "best answer", any answer will do. We eventually decided against it for being too tricky for the engineers we were targeting. But it's not tricky in a solver; include "globals.mzn"; array[int] of int: numbers = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8]; array[index_set(numbers)] of var {0, -1, 1}: choices; constraint sum(n in index_set(numbers)) (numbers[n] * choices[n]) = 0; constraint count(choices, -1) + count(choices, 1) = 3; solve satisfy; Okay, one last one, a problem I saw last year at Chipy AlgoSIG. Basically they pick some leetcode problems and we all do them. I failed to solve this one: Given an array of integers heights representing the histogram's bar height where the width of each bar is 1, return the area of the largest rectangle in the histogram. The "proper" solution is a tricky thing involving tracking lots of bookkeeping states, which you can completely bypass by expressing it as constraints: array[int] of int: numbers = [2,1,5,6,2,3]; var 1..length(numbers): x; var 1..length(numbers): dx; var 1..: y; constraint x + dx <= length(numbers); constraint forall (i in x..(x+dx)) (y <= numbers[i]); var int: area = (dx+1)*y; solve maximize area; output ["(\(x)->\(x+dx))*\(y) = \(area)"] There's even a way to automatically visualize the solution (using vis_geost_2d), but I didn't feel like figuring it out in time for the newsletter. Is this better? Now if I actually brought these questions to an interview the interviewee could ruin my day by asking "what's the runtime complexity?" Constraint solvers runtimes are unpredictable and almost always than an ideal bespoke algorithm because they are more expressive, in what I refer to as the capability/tractability tradeoff. But even so, they'll do way better than a bad bespoke algorithm, and I'm not experienced enough in handwriting algorithms to consistently beat a solver. The real advantage of solvers, though, is how well they handle new constraints. Take the stock picking problem above. I can write an O(n²) algorithm in a few minutes and the O(n) algorithm if you give me some time to think. Now change the problem to Maximize the profit by buying and selling up to max_sales stocks, but you can only buy or sell one stock at a given time and you can only hold up to max_hold stocks at a time? That's a way harder problem to write even an inefficient algorithm for! While the constraint problem is only a tiny bit more complicated: include "globals.mzn"; int: max_sales = 3; int: max_hold = 2; array[int] of int: prices = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8]; array [1..max_sales] of var int: buy; array [1..max_sales] of var int: sell; array [index_set(prices)] of var 0..max_hold: stocks_held; var int: profit = sum(s in 1..max_sales) (prices[sell[s]] - prices[buy[s]]); constraint forall (s in 1..max_sales) (sell[s] > buy[s]); constraint profit > 0; constraint forall(i in index_set(prices)) (stocks_held[i] = (count(s in 1..max_sales) (buy[s] <= i) - count(s in 1..max_sales) (sell[s] <= i))); constraint alldifferent(buy ++ sell); solve maximize profit; output ["buy at \(buy)\n", "sell at \(sell)\n", "for \(profit)"]; Most constraint solving examples online are puzzles, like Sudoku or "SEND + MORE = MONEY". Solving leetcode problems would be a more interesting demonstration. And you get more interesting opportunities to teach optimizations, like symmetry breaking. Because my dad will email me if I don't explain this: "leetcode" is slang for "tricky algorithmic interview questions that have little-to-no relevance in the actual job you're interviewing for." It's from leetcode.com. ↩

2 days ago 6 votes