Every single software product is dealing with the question about what to do with “AI”-generated code, but the question is particularly difficult to answer for open source operating systems like Linux distributions and the various BSDs, which often consist of a wide variety of software packages from hundreds to thousands of different developers. On top of that, they also have to ask the “AI” question for every layer of their offering, from the base install, to the official repositories, to community-run ones.
As users, we, too, are asking these same questions, wondering just how much “AI” taint we’re willing to spread across our computers. I understand the difficult position Linux distributions are in with regard to “AI”. I mean, when even the Linux kernel itself is tainted by “AI”, a no-“AI” policy is basically an empty gesture for them at this point. Personally, I find a policy of “we don’t do ‘AI’ in our work, but we don’t have control over the thousands of components we consist of” to be an entirely reasonable, if deeply unsatisfying, position to take. What else are they going to do? You can’t really be a Linux distribution without, you know, the Linux kernel, which is, as I’ve already said, utterly tainted by “AI” at this point.
Still, in the back of my mind, I always had a trump card: if all else fails, we’ll always have OpenBSD. Its project leader Theo de Raadt is deeply principled, every OpenBSD user and contributor I know hates “AI” deeply, and the project routinely sticks to their principles even when it’s difficult or inconvenient. Yes, this makes OpenBSD not the most ideal desktop operating system, but I’d rather use that than something that embraces the multitude of ethical, environmental, quality, and legal concerns regarding “AI” code completely.
Imagine my surprise, then, to discover that OpenBSD already contains slopcode in its base installation, with the project’s leaders and developers remaining oddly silent about it. My friend and OSNews regular Morgan posted this on Fedi a few days ago:
Nearly six weeks later, and the question of whether “AI” generated code in tmux — not tool-assisted bug finding, not refactoring, actual LLM-generated slop with questionable license(1) — that was consequently merged into OpenBSD base, is considered acceptable by the lead devs, remains unanswered. Despite Theo de Raadt’s concrete stance against any code of questionable license origin polluting the project — and the tmux merge was indeed questionable — it seems this is being swept under the rug. This makes me extremely uncomfortable; it’s like seeing a fox in the henhouse but the farmers are all looking the other way and no one can convince them to admit they can see it and root it out.
I really don’t know what to do being just a user; I feel like even if I tried to chime in on the mailing list I would just be ignored like the others trying to raise the alarm. I hope, as they do, that this is being discussed internally, away from the public list, and that a positive outcome is near. Maybe they are waiting for the 7.9 release before setting anything in stone.
Or maybe the “AI” disease has infected one of the last pure operating system projects we have left and there’s no going back.
I obviously share Morgan’s concerns, and like him, I’m also afraid that opening the door to a few drops of slop in base will quickly grow into a torrent of slop as time goes by. Yes, it’s just a patch to tmux, but it’s in base, and the “base” of a BSD is almost a sacred concept, and entirely the last place where you want to see code that raises ethical, environmental, quality, and legal concerns. For all we know, this patch of slop or the next one contains a bunch of GPL code because it just so happens that’s where the ball tumbling down the developer’s pachinko machine ended up.
GPL code that would then be in the base of a BSD.
I echo the call for the OpenBSD project to address this problem, and to set clear boundaries and guidelines regarding “AI” code, so users and developers alike know what level of quality and integrity we can expect from OpenBSD and its base installation going forward.
Microsoft is currently testing a brand new performance-enhancing feature in Windows 11.
Microsoft, too, is introducing something to Windows 11 called “low latency profile” and it this will work irrespective of the processor, be it AMD64 CPUs like Intel or AMD or ARM64 ones like from Qualcomm. Essentially what this new tech will do is apply a maximum available clock frequency boost for a very small span of time, like for one to three seconds, when a user launches any app. The idea is that the app launch time will reduce while the quick clock burst should not impact the overall efficiency of the system by much.
Unsurprisingly, boosting the processor’s clock speed to its maximum for a few seconds will make a menu or application open a little faster. I’m not entirely sure why anyone seems surprised by this, but here we are. Yes, the Start menu will load faster and applications will be ready quicker if you boost the processor to its full potential, but that does raise the question of why Windows 11 would need to do that just to open a menu or load an application in the first place.
According to Microsoft’s Scott Henselmann, who defended Microsoft’s approach (weirdly enough he did so on a nazi platform called “Twitter” that I’m obviously not linking to), every other modern operating system does the exact same thing, pointing specifically to macOS and GNOME and KDE on Linux. He also pointed out that the Start menu today does a lot more than the same Start menu back in Windows 95, including making network requests and rendering everything in HiDPI.
I just want a cascading menu of stuff I can run and don’t want my launcher to make network requests, but alas, I guess I’m old.
Anyway, I don’t know enough about the intricacies of how modern processors work to make any statements about how this affects battery life, but instinctively, you’d think this would not exactly be conducive to that. I also wonder if this will trigger a lot of laptops to spin up their fans whenever you open the Start menu, because the few seconds your processor goes full tilt raises its temperature just enough to make that happen. Once this new feature comes out of testing and is generally available, I’d be quite interested in seeing battery tests, as well comparisons to other operating systems to see how it fares.
Luckily, there’s really very little in the form of lock-in with GitHub, unless you really value your stars or whatever. There are countless alternatives, and if you’re a programmer, it’s probably absolutely trivial for you to run your own instance of any of the various available forges. If you’re still on GitHub, you should really be thinking about, and planning for, leaving, as it seems it’s circling the drain.
Big news from the Debian release team: Debian is going for reproducible package builds.
Aided by the efforts of the Reproducible Builds project, we’ve decided it’s time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can’t be reproduced or existing packages (in testing) that regress in reproducibility.
Reproducible means, in short, that you can verify that the source code used to build a package is indeed that source code. This provides a layer of defense against people tampering with code or otherwise trying to fiddle with the process between source code and final package on your system. This effort constitutes a tremendous amount of work, but it’s massively important.
ymawky is a small, static http web server written entirely in aarch64 assembly for macos. it uses raw darwin syscalls with no libc wrappers, serves static files, supports GET, HEAD, PUT, OPTIONS, DELETE, byte ranges, directory listing, custom error pages, and tries to be as hardened as possible.
why? why not? the dream of the 80s is alive in ymawky. everybody has nginx. having apache makes you a square. so why not strip every single convenience layer that computer science has given us since 1957? i wanted to understand how a web server actually works, something i know little about coming from a low-level/systems background. the risks that come up, the problems that need to be solved, the things you don’t think about when you’re writing python or c.
this (probably) won’t replace nginx, but it is doing something in the most difficult way possible.
Ada is incredibly well designed. One way this shows is that it takes the big, monolithic features of other languages and breaks them down into their constituent parts, so we can choose which portions of those features we want. The example I often reach for to explain this is object-oriented programming.
Sculpt OS, the operating system based on the various components that make up Genode, has seen a new release, 26.04. A lot of the new features and changes to Genode that we’ve been talking about for a while now are part of this release, most notably the new human-inclined data syntax that replaces XML as the configuration language for Genode. That’s not the only major improvement, though.
Regarding technical advances of the new version and device support in particular, all Linux-based drivers have been updated to kernel version 6.18, making the system compatible with most modern Intel-PC hardware. Laptop users may appreciate the new USB networking option that is now offered by default.
Software-wise, the new version comes with a longed-after update of Qt6 along with the Chromium-based Falkon browser, downloadable at the depot of cproc. In the same menu, one can find the experimental first version of the Goa SDK running natively on Sculpt OS without the need of a Linux VM. For the first time, Genode components can now be developed, compiled, and tested using Sculpt OS on its own. The amazement of walking without crutches.
Sprite scaling. It is the coolest effect of the 2D arcade era, a must-have for games from Space Harrier to Real Bout Fatal Fury Special. Home consoles pretty much lacked it– sorry, Nintendo, but Mode 7 only scales a background, not sprites. So therefore you might be surprised to hear that Sega’s plucky underdog Master System could do it. Well, don’t get your hopes up; this is far too limited– calling it scaling is overstating things. But let’s dig in anyway!
The ways in which Google can lock you into their ecosystem are often obvious, but sometimes, they’re incredibly sneaky and easily missed.
CAPTCHA tests are annoying, but at the same time, they can help protect websites from bots. While these tests are already the bane of our internet existence, they are going to get worse for some Android users. A requirement for Google’s next-generation reCAPTCHA system will make it a lot harder for de-Googled phones to browse the web.
A Reddit user has highlighted a seemingly innocuous support page for Google’s reCAPTCHA system. The page in question relates to troubleshooting reCAPTCHA verification on mobile. In the document, it says that you’ll need to use a compatible mobile device to complete verification. If you have an Android phone, then that means you’ll need to be running Google Play Services version 25.41.30 or higher.
When was the last time you actively thought about reCAPTCHA being a Google property? Even then, when was the last time you imagined something as annoying but ultimately basic as a captcha prompt could be used to tie people to Google Play Services, and thus to “blessed” Android? Every time we manage to work around one of these asinine ties to Google Play Services, another one pops up to ruin our day. We’re so stupidly tied down to and entirely dependent on two very mid – at best – mobile operating systems, and it’s such a stupid own goal for especially everyone outside of the US to just sit there and do nothing about it.
Worse yet, it seems we’re only tying ourselves down further, while paying for the privilege.
At the very least we should be categorising certain services – government ID services, payment services, popular messaging platforms, and a few more – as vital infrastructure, and legally mandate these services have clearly defined and well-documented APIs so anyone is free to make alternative clients. The fact that many people are tied to either iOS or “blessed” Android because of something as stupid as what bank they use or the level of incompetency of their government ID service should be a major crisis in any country that isn’t the US.
I don’t want to use iOS or Android, but nobody is leaving me any choice. It’s infuriating.
With that context, I always found it strange that the designers of ASCII included 6 characters after uppercase Z before starting the lowercase letters. Then it hit me: we have 26 letters in the English alphabet, plus 6 additional characters before lowercase starts: 26 + 6 = 32. If you know anything about computers, powers of 2 tend to stick out. Let’s take a look at the binary representations of some characters compared to their lowercase counterparts.
I only have a middling understanding of the rest of the article and thus the ultimate reason why ASCII includes those six characters between Z and a, but I think it comes down to making certain operations on uppercase and lowercase letters specifically more elegant. In some deep crevices of my brain all of this makes sense, but I find it very difficult to truly understand and explain as someone who knows little about programming.
Many Bourne shells go slightly beyond the POSIX sh specification to also support a ‘-l’ option that makes the shell act as a ‘login shell’. POSIX’s omission of -l isn’t only because it doesn’t really talk about login shells at all, it’s also because Unix has a special way of marking login shells that goes back very far in its history. The -l option isn’t necessarily what login and sshd and so on use, it’s something that you can use if you specifically want to get a login shell in an unusual circumstance.
Bourne shells also have a ‘-c <command string>’ option that causes the shell to execute the command string rather than be interactive (this is a long standing option that is in POSIX). It may surprise you to hear that most or all Bourne shells that support -l also allow you to use -l and -c together. Basically all Bourne shells interpret this as first executing your .profile and so on, then executing the command string instead of going interactive. One use for this is to non-interactively run a command line in the context of your fully set up shell, with $PATH and other environment variables ready for use.
Now, what if you want to detect the use of these two options combined, for instance to make it so certain parts of your .profile are ignored? It turns out very few Bourne shells actually support this, and that’s what Siebenmann’s latest post is about.
On the Fedora forums, there’s a long-running thread about a proposal for Fedora to build a variant of the distribution aimed specifically at “AI”. The “problem” identified in the proposal is that setting up the various parts that a developer in the “AI” space needs is currently quite difficult on Fedora, and as such, a bunch of technical steps need to be taken to make this easier. Setting aside the “AI” of the proposal and ensuing discussion, it’s actually a very interesting read, going deep into the weeds about consequential questions like building an LTS kernel on Fedora, support for out-of-tree kernel mods, and a lot more.
To spoil the ending: the proposal has already been approved unanimously by the Fedora Council, meaning the efforts laid out in the proposal will be undertaken. This means that, depending on progress, we’ll see a Fedora “AI” Desktop or whatever it’s going to be called somewhere in the timeframe from Fedora 45 to Fedora 47. As a Fedora user on all my machines, I’m obviously not too happy about this, since I’d much rather the scarce resources of a project like Fedora goes towards things not as ethically bankrupt, environmentally destructive, and artistically deficient as “AI”, but in the end it’s a project owned and controlled by IBM, so it’s not exactly unexpected.
What really surprised me in this entire discussion is a post by Fedora Project Leader Jef Spaleta, responding to worries people in the thread were having about such a big “AI” undertaking under the Fedora branding causing serious reputational damage to Fedora as a whole. These concerns are clearly valid, as people really fucking hate “AI”, doubly so in the open source community whose work especially “AI” coding tools are built on without any form of consent. As such, Fedora undertaking a big “AI” desktop project is bound to have a negative impact on Fedora’s image. Just look at what aggressively pushing Copilot has done to Windows 11’s already shit reputation.
Spaleta, however, just doesn’t care. Literally.
As the Fedora Project Leader, I am absolutely not concerned about the reputational damage to this project that comes with setting up an entirely new output attractive to developers who want to make use of Ai tools.
I’ve been looking at this line on and off for a few days now, and I just can’t wrap my head around how the leader of an open source project built on and relying on the free labour of thousands of contributors says he doesn’t care about reputational damage to the project he’s leading. Effective and capable open source contributors are not exactly a commodity, and a lot of the decisions they make about what projects to donate their time to are based on vibes and personal convictions – you can’t really pay them to look the other way. Saying you don’t care about reputational damage to your huge open source project seems rather shortsighted, but of course, I don’t lead a huge open source project so what do I know?
In the linked thread alone, one long-time Fedora contributor, Fernando Mancera, already decided to leave the project on the spot, and I have a sneaking suspicion he won’t be the last. “AI” is a deeply tainted hype on many levels, and the more you try to chase this dragon, the more capable people you’ll end up chasing away.
Another month, another progress report, Redox, etc. etc., you know the drill by now. This past month Redox saw improved booting on real hardware by making sure the boot process continues even if certain drivers fail or become blocked. Thanks to some changes on the RISC-V side, running Redox on real RISC-V hardware has also improved. Furthermore, tmux has been ported to Redox, CPU time reporting has been improved, and Orbital, Redox’ desktop environment, gianed support for partial window pixel updating, which should increase UI performance.
On top of that, there’s a brand new web user interface to browse Redox packages (x86-64, i586, ARM64 (aarch64), and RISC-V (riscv64gc)), as well as the usual list of improvements to the kernel, drivers, relibc, and many more areas of the operating system.
Time for another Sun Ray blog post! I’ve had a few people email me asking for help setting up a Sun Ray server over the last few months, and despite my attempts to help them get it going there’s been mixed results with running SRSS on OpenIndiana Hipster 2025.10.
my Sun Ray server is still on an earlier OI snapshot, so I figured it was about time to try to actually follow the new guides myself.
Ever since my spiraling down the Sun rabbit hole late last year, I’ve tried for a few times now to get the x86 version of OpenIndiana and Oracle Solaris working on any of my machines, exactly for the purposes of setting up a modern Sun Ray server. Sadly, none of my machines are compatible with any illumos distribution or Oracle Solaris, so I’ve been shit out of luck trying to get this side project off the ground. My Ultra 45 is sadly also not supported by any SPARC version of illumos or Oracle Solaris, so unless I buy even more hardware, my dream of a modern Sun Ray setup will have to wait.
Of course, virtualisation is an option for many, and that’s exactly what this particular guide is about: setting up OpenIndiana on a Proxmox virtual machine. I actually have a Proxmox machine up and running and could do this too, but I’m a sucker for running stuff like this on real hardware. Yes, that makes my life more complicated and difficult, and no, it’s not more noble or real or hardcore – it’s just a preference. Still, for normal people who pick up a Sun Ray or two on eBay for basically nothing, running OpenIndiana in a virtual machine is the smart, reasonable, and effective option.
If you’re sick of Chrome OS on your Chromebook, or can find a Chromebook for cheap somewhere but don’t actually want to use Chrome OS, have you considered postmarketOS?
Since I was kind frustrated with ChromeOS, I decided to take a look at something that I knew supported my Lenovo Duet 3 for some time: postmarketOS. For those who don’t know, postmarketOS is an Alpine Linux based-distro focused in replacing the original OS from old phones (generally running Android) with a “true” Linux distro. They also seem to support some Chromebooks because of their unique architecture and, luckily, they support my device under the google-trogdor platform.
PostmarketOS is aimed at smartphones primarily, but supports other formfactors just fine as well. The Duet 3 is one of the tablet-like devices it supports, and it seems most things are working quite well. In fact, judging by the postmarketOS wiki, quite a few Chromebooks have good support, and with Chromebooks being cheap and dime-a-dozen on eBay and similar auction sites, it seems like a great way to get started with what is trying to become a true Linux for smartphones.
There is a persistent misconception among sighted developers: if an application runs in a terminal, it is inherently accessible. The logic assumes that because there are no graphics, no complex DOM, and no WebGL canvases, the content is just raw ASCII text that a screen reader can easily parse.
The reality is different. Most modern Text User Interfaces (TUIs) are often more hostile to accessibility than poorly coded graphical interfaces. The very tools designed to improve the Developer Experience (DX) in the terminal—frameworks like Ink (JS/React), Bubble Tea (Go), or tcell—are actively destroying the experience for blind users.
The core reason should be obvious: the command-line interface, at its core, is just a stream of data with the newest data at the bottom, linearly going back in time as you go up. Any screen reader can deal with this fairly easily, and while I personally have no need for such a tool, I’ve heard from those that do that kernel-level screen readers are quite good at what they do. TUIs, or text-based user interfaces, made with modern frameworks are actually very different: they’re “2D grid[s] of pixels, where every character cell is a pixel. [They] abandons the temporal flow for a spatial layout.”
It should become immediately obvious that screen readers won’t really know what to do with this, and Reeves gives countless examples, but the short version is this: the cursor jumps all over the place with every screen update, which makes screen readers go nuts. Various older TUIs, made in a time well before these modern TUI frameworks came about, were designed in a much more terminal-friendly way, or give you options to hide the cursor to solve the problem that way. Irssi, for example, uses VT100 scrolling regions instead of redrawing the whole screen every time something changes.
I had never really stopped to think about TUIs and screen readers, as is common among us sighted people. The problems Reeves describes seem to stem not so much from TUIs being inherently inaccessible, but from modern frameworks not actually making use of the terminal’s core feature set. I really hope this Reeves’ article shines a light on this problem, and that the people developing these modern TUIs start taking accessibility more seriously.
Backing up in modern times, we’ve had ZFS snapshots and replication to make this task extremely easy. However, you may not have access to another ZFS endpoint for replication, need to diversify risk by using a non-ZFS tool for backup, or are simply using UFS2, living the old skool life.
For these situations, my first recommendation is to lean on Tarsnap for its ease of use and simplicity, making restoration just as easy as backing up. But some situations call for a different approach. Maybe you have a strict firewall at your company that doesn’t allow Tarsnap data streams to egress from your corporate network, or you have internal/easy access to storage endpoints, such as S3-compatible object storage or a large-file storage location with SFTP access.
When you are faced with the latter, the duplicity (sysutils/duplicity in ports) utility is available as an easily installable package onto your FreeBSD system.
Earlier this year, Mac OS and Windows NT-capable ROMs were discovered for Apple’s unique AIX Network Server. Cameron Kaiser has since spent more time digging into just how capable these ROMs are, and has published another one of his detailed stories about his efforts.
Well, thanks to Jeff Walther who generously built a few replica ROM SIMMs for me to test, we can now try the “2.0” MacOS ROMs on holmstock, our hard-working Apple Network Server 700 test rig (stockholm, my original ANS 500, is still officially a production unit). And there are some interesting things to report, especially when we pit the preproduction ROMs and this set head-to-head in MacBench, and even try booting Rhapsody on it.
With Windows being as old and long-running as it is, there’s a ton of old and outdated bits and pieces lurking in every nook and cranny. I have always found these old relics fascinating, especially now that over the past few years, Microsoft has attempted to replace some of those bits and pieces with modern replacements (not always to great success, but that’s another story). One of those parts of the UI that’s been virtually unchanged since the release of Windows 95 is the Run dialog, but that’s about to change: Microsoft has released a completely new Run dialog to early testers.
Windows Run, also known as the Run dialog, is a surface that has been around for over 30 years. It has become a heavily relied upon tool for developers and advanced users alike. Users have decades of muscle memory where they hit Win+R, navigate through their Run history, and hit Enter to quickly access various paths and tools. We all have our favorite tool we launch there as well. For us, some of our favorites are wt (Windows Terminal), mstsc (Remote Desktop) and winword (Microsoft Word). But it’s more than jUsT a TeXt BoX tHaT rUnS tHiNgS. The Run dialog can handle navigating both local and network file paths as well. And everything it does, it does fast. Win+R opens the run dialog seemingly instantly.
If we wanted to modernize the Run Dialog to fit the modern Windows 11 design style, we had to make sure it did everything just as well as before. We needed to maintain the same performance while also keeping the user interface minimal, just as Windows 95 intended.
The new Run dialog looks like it belongs in Windows 11, which is a nice improvement, but the most important part is that they actually seem to have made it a little faster. Sure, they may have only shaved off a few milliseconds from its opening time, but considering virtually everything else they’ve touched in Windows over the years got considerably slower, that’s a good showing for Microsoft. The new feature they’ve added is that by typing ~\, you can open your home directory. The one casualty is the browse button, which according to Microsoft’s data, literally nobody ever used.
I know it’s just a small thing and in the end not even a remotely consequential one, but with an operating system as old and storied as Windows, replacing these ancient parts that millions of people rely on every day absolutely fascinates me. There must be a considerable amount of pressure on the people developing something like this new Run dialog, especially with Windows’ reputation being at one of its lowest points, so it’s good to see them being able to deliver.
The new Run dialog is available today for testers, and if you’re on the Windows Insider Experimental Channel, you can enable it in Settings > System > Advanced. Coincidentally, on my Windows 11 machine that I use for just one stupid video game, this Advanced page displays a loading spinner for five minutes and then just dies. Also, Notepad won’t start (one time it showed this dialog), and using the terminal to load it causes the old Win32 version of Notepad to open after 5 minutes of waiting, which then hangs and crashes.
While I’m normally a KDE user, I do keep close tabs on various other desktop environments, and install and set them up every now and then to see how they’re fairing, what improvements they’ve made, and ultimately, if my preference for KDE is still warranted. This usually means setting up a nice OpenBSD installation for Xfce, Fedora for GNOME, and less often others for some of the more niche desktop environments. Since GNOME 50 was just released, guess who’s time in the round is up?
Since everybody’s already made up their mind about their preferred desktop eons ago, with upsides and downsides debated far past their expiration date, I’m not particularly interested in reviewing desktop environments or Linux distributions. However, after asking around on Fedi, it seemed there was quite a bit of interest in an article detailing how I set up GNOME, what changes I make to the defaults, which extensions I use, what tweaks I apply, and so on.
Of course, everything described in this article is highly personal, and I’m not arguing that this is the optimal way to tweak GNOME, that the extensions I use are the best ones, or that any visual modifications I make are better than whatever defaults GNOME uses. No, my goal with this article is twofold: one, to highlight that GNOME is a lot more configurable, extensible, and malleable than common wisdom on the internet would have you believe. It’s not KDE or one of those cobbled-together tiling Wayland desktops, but it’s definitely not as rigid as you might think. And two, that GNOME is good, actually.
Tools of the trade
The first thing I do is install a few crucial tools that make it easier to modify and tweak GNOME. I really dislike lists in articles, but I will begrudgingly use one here:
GNOME Tweaks: this tool gives you easy access to some hidden settings, most notably to easily switch themes.
Extension Manager: the easiest way to find, install, update, and manage GNOME extensions. With this application, you won’t need to use the browser for extensions at all.
dconf Editor: a tool to fiddle with even more obscure GNOME settings.
Add Water: an application with an odd name, designed entirely to easily install and update the Firefox GNOME Theme, which transforms Firefox (or LibreWolf, in my case) into something that much more closely resembles a GNOME/libadwaita application.
After installing all of these tools, the actual tweaking can commence.
Visual tweaks
I didn’t use to like GNOME’s Adwaita visual style, but over the years, it started growing on me to the point where I don’t actively dislike it anymore. With the arrival of libadwaita, it has also become effectively impossible to theme modern GNOME applications, so even if you do change to something else, many of your applications won’t follow along. If consistency is something you care about, you’ll stick to Adwaita, but that leaves one problem unresolved: applications that still use GTK3. These applications will follow a much older version of Adwaita, making them stand out like eyesores among all the modern GTK4 stuff.
Luckily, since GTK3 applications are still properly themable, this is easily fixed: just install the adw-gtk3 theme, either by hand, or through your distribution’s repositories. To enable it, first install the user themes extension through Extension Manager, and then enable the theme in GNOME Tweaks for “Legacy Applications”. Any potential GTK3 applications you still use will now integrate nicely with modern libadwaita applications.
The one part of GNOME I really do deeply dislike is its icon theme. I can’t quite explain why I dislike this icon set so much, but it runs deep, so one of the very first things I do is replace the default GNOME icon set with my personal favourite, Qogir. This is a popular icon set, so it’s usually available in your distribution’s repositories, but I always install it from its GitHub page. Changing GNOME’s icon set is as simple as selecting it in GNOME Tweaks. You can’t get much more personal taste than an icon set, and there are dozens of amazing sets to choose from in the Linux world. Changing them out and trying out new ones is stupidly easy, and it’s definitely worth looking at a few that might be more pleasing to you than GNOME’s (or KDE’s) default.
Lastly, I open Add Water and enable the amazing GNOME theme for LibreWolf. Add Water basically makes this as easy as flipping a switch, so there’s no need to copy any files into your LibreWolf profile or whatever. The application also provides a few more small tweaks to fiddle with, like enabling standard tab widths so tabs don’t grow and shrink as you close and open tabs, moving the bookmarks bar below the tab bar, and many more.
Extensions
Since the release of GNOME 3 in 2011, extensions have been the most capable way to modify GNOME’s look, behaviour, and feature set. As far as I can tell, while the extension framework is an official part of the GNOME Shell, the extensions themselves are all third-party and not part of a vanilla GNOME installation. By now, there are over 2800 listed extensions, but that number includes abandoned extensions so it’s hard to determine the actual number of currently-maintained ones. Whatever the actual number is, there’s bound to be things in there you’re going to want to use.
Here are the extensions I have installed. Let’s just start at the top and work our way down. I guess I’m forced to do another list.
AppIndicator and KStatusNotifierItem Support: for reasons that are clearly beyond my limited understanding of the world, GNOME does not support AppIndicators, KStatusNotifierItems, and legacy system tray icons. This must-have extensions fixes this inexplicable omission.
ArcMenu: a very configurable application/Start menu kind of thing. Has tons of options and preconfigured layouts, and is an absolute must for me as I’m a basic guy whose second GUI was Windows 95.
Blur my Shell: as the name implies, adds a nice configurable blur effect to various parts of the GNOME shell. An entirely aesthetic thing that adds little in functionality.
Dash to Dock: adds a dock to GNOME. An absolute 100% must for me. I used Mac OS X back when it didn’t suck (10.2-10.6), and my love for the dock metaphor is one of the few things from that time that stuck.
Date Menu Formatter: GNOME is remarkably limited and rigid when it comes to configuring locale-related settings, as it forces you to adopt every individual aspect of a locale (contrary to KDE, which has a very detailed settings screen for every aspect of locale). Even though I’m Dutch and live in Sweden, I always use all my software in US English, which in the case of GNOME also means adopting things like US currency, date formats, and so on. This little extension allows me to manually format the date in the top bar to be actually readable.
Gtk4 Desktop Icons NG (DING): GNOME does not support desktop icons. I think this is a bizarre design decision. This extension brings desktop icons back, with a nice collection of settings to adapt them to your needs.
Junk Notification Cleaner: whenever an application receives a notification, GNOME puts them in its notification center in the top clock menu. Sadly, this is also the only place where you can dismiss them. With this extension, you can set it so that the notifications of an application are cleared when you focus its window, close it, or both. I set it to both.
Just Perfection: this extension provides you with a massive set of toggles and switches to change tons of little aspects of the GNOME Shell. I use to hide a slew of buttons and toggles from the clock and top-right menu on the top panel that I never use, as well as to move the notification OSD to the top-right.
Lock Keys: ads a little Caps Lock icon in the top panel when Caps Lock is engaged. Very useful, especially when your keyboard lacks indicator LEDs.
User Themes: allows you to set GNOME Shell themes from your home directory.
Weather or Not: one of the many extensions that adds the weather to the top bar. We have two toddlers and live in the Arctic – we absolutely must have frictionless instant access to the current outside temperature.
There are countless more extensions to choose from, and you’re definitely going to find things you never even thought could be useful.
Miscellaneous tweaks
There’s a few other things I modify. In GNOME Tweaks, I make it so that double-clicking a window’s titlebar minimises it while right-clicking it lowers it; two features I picked up during my years as a BeOS user that I absolutely refuse to give up. I configure the dock from Dash to Dock so that it always remains on top and never hides itself, no matter the circumstances. In Settings, I disable virtual desktops entirely (I don’t like virtual desktops), and I make sure tap-to-click is disabled (if I’m on a laptop).
GNOME is good, actually
After making all of these changes, I feel quite comfortable using GNOME, at least on my laptop. It’s a nice, coherent experience, and offers what is probably the most polished graphical user interface you can find on Linux, even if it isn’t the most full-featured. The third-party application ecosystem, through modern libadwaita applications, is also quite healthy, moreso than what you find on KDE. To get there, however, I need to make a lot of changes to fix, undo, or work around some of the more… Peculiar defaults in GNOME, primarily through extensions.
And I think this is a problem.
The GNOME extension ecosystem is lively and active, but it also highlights a potential shortcoming of GNOME. I don’t think I’ve ever seen anyone use GNOME without extensions, and it’s honestly not hard to see why. Things like desktop icons and a system tray are pretty basic features of any modern desktop, and it’s not surprising that people seek them out, regardless of any grand design vision the GNOME team may have. GNOME developers can and should do whatever they want and what they think is right, but perhaps some of the most popular extensions should become official parts of GNOME if they are as popular as they seem.
For now, GNOME extensions kind of feel like the little block holding up the entire stack in that xkcd comic. Is it really wise to leave this linchpin to third parties, especially considering extensions run code on your machine? Sure, they make GNOME a lot more configurable and extensible than prevailing sentiments would have you believe, but perhaps not in the most convenient and safest way. Also, several of them break every time GNOME does a new release. Bummer.
In the end, though, GNOME is a product of its developers, and they alone get to decide how they want it to behave, what it looks like, and which features it will and won’t have. With how popular GNOME is, you have to be a real dishonest person to argue that what they have built isn’t a damn fine desktop environment, even if it makes some design decisions some of us find baffling. It won’t replace KDE as my desktop of choice, but having two excellent desktops like these that far outshine whatever “AI” and ad-ridden crap the proprietary vendors have to offer is truly an embarrassment of riches for the open source desktop world.
Submitted by 
