Oinks

It's been a while since I last gave it a try, but I remember frequently ending up in strange states where a window wouldn't want to tile properly. Windows would also frequently end up overlapping or extending beyond the screen, in ways they just wouldn't when I was using Sway, Hyperland or Niri. IIRC mouse dragging and mouse resizing windows was extremely jank too.

Most of this is KWin's fault as far as I know, it's built for stacking window management and there's only so much you can fix with scripting around it. It's also the reason for the bad multi-monitor experience; the way it interacts with workspaces in particular is in my opinion not useful and never what I want.

Additional cons:

• Layouts break easily
• Multi-monitor is close to unusable

Yes, that is true. Curiously Qt kind of has the opposite problem of trying to be too flexible, and we have like four theming engines of which only one actually works (and it's the one that's tied to the Plasma desktop). GTK4 + Libadwaita is at least consistent in that it supports basically nothing.

GNOME theming discussions are weird. A lot of people will peddle cargo culted bad (broken) approaches when asked about it, but honestly it's not that complicated¹, just restrictive:

• Use gsettings [get|set] org.gnome.desktop.interface gtk-theme [new value] to set the theme that GTK3 apps will load. Libadwaita apps will ignore this setting.

• Use gsettings [get|set] org.gnome.desktop.interface color-scheme [prefer-light|prefer-dark|default] to control whether Libadwaita apps (and GNOME shell) will display in dark mode. GTK3 apps will ignore this setting.

  • prefer-light makes everything light mode.
  • prefer-dark makes everything dark mode.
  • default makes apps light mode but the panel will stay dark.

• If you insist on theming Libadwaita apps, put the theme in ~/.config/gtk-4.0/gtk.css. You can also have add an @import directive there to import a theme. Note that this file is only loaded at startup, so using this feature means that GTK4 apps can no longer respond to the dark mode toggle.²

All of the applications that promise to help in theming GTK/GNOME (regardless of whether you're talking about Tweaks, Refine, the theming settings of other DEs, Gradience, etc.) just flip some combination of these settings, mostly the first two.³

¹ It might seem complicated based on the length of this comment, but trust me that Qt is worse.

² The newest GTK version has media selectors, so if all of your applications are already updated to use the new GTK and your theme is updated to use media selectors then dark mode toggles should actually work now. Mine unfortunately haven't.

³ A handful (mostly random scripts from GitHub, but also more reputable stuff like home-manager) will also try some wrong ways:

• Setting the GTK_THEME environment variable will prevent applications from loading the default Adwaita stylesheet completely, which will break all kinds of things.

• You can also put a theme at ~/.config/gtk-3.0/gtk.css, but this does nothing you can't do with gsettings except preventing you from changing the theme without restarting all your apps.

Generally, no. You can't install Linux onto a Windows filesystem (NTFS). What you can do is one of these things:

• Back up the files you care about (Desktop, Documents, Downloads, whatever) in Google Drive, Dropbox, a thumb drive or anywhere else that you can access later. Then you can tell the Linux installer to wipe Windows and afterwards put your important files back.

• If you have a spare SSD you can put Linux on that. Then you can access the Windows drive from Linux. You might have to install an NTFS driver first, and you will definitely need to configure Windows to shut down properly instead of secretly hibernating, because that leaves the filesystem in a weird state and Linux won't be able to open it.

• If you don't have a spare SSD you can still do the same trick by shrinking the Windows/NTFS filesystem and installing Linux in the now-free space on the same drive. Among Sysadmins shrinking filesystems has a bad reputation because at least historically it could (rarely) fail and destroy all your data, so I would not recommend you do it but it is possible and in most cases it works without issues.

Each of these comes with some risk - You might forget to copy over important files onto your thumb drive, or you might make a mistake in the Linux installer and accidentally delete Windows when you didn't mean to. That said you should already have a backup strategy, because your PC could also just spontaneously die and lose the data even if you do nothing. If you have backups and you've tested them to know that you really can restore all the files you care about, then even that first option stops looking very scary.

I'm not a btrfs expert but AFAIK high unreachable space usage is usually a result of fragmentation. You might want to defragment the filesystem and see if that helps.

I will note that btrfs makes estimations of used/available space very difficult by design, and you especially can not trust what standard UNIX tools like df and du tell you about btrfs volumes. Scripting around du or using ncdu will not help here in any way. You might want to read this kernel.org wiki article as well as the man pages for the btrfs tools (btrfs(8) and particularly btrfs-filesystem(8)), which among other things provide versions of df and du that actually work, or at least they do most of the time instead of never.

I can't speak for everyday workflow (having discovered this project less than a week ago), but rebase being unnecessary and cherry-pick not creating duplicate commits seem like the most notable advantages to me.

There's an argument to be made that system software like filesystems and kernels shouldn't get too smart about validating or transforming strings, because once you start caring about a strings meaning, you can no longer treat it as just a byte sequence and instead need to worry about all the complexities of Unicode code points. "Is this character printable" seems like a simple question but it really isn't.

Now if I were to develop a filesystem from scratch, would I go for the 80% solution of just banning the ASCII newline specifically? Honestly yes, I don't see a downside. But regardless of how much effort is put into it, there will always be edge cases – either filenames that break stuff, or filenames that aren't allowed even though they should be.

The usual problems with parsing ls don't happen here because Nu's ls builtin returns properly typed data. You can work with it in pretty much the same way you would work with it in Python, except that Nu has a composition operator that doesn't suck ass (|), so you don't have to write as much imperative boilerplate.

I have a number of reservations regarding Nu (the stability of the scripting language, unintuitive syntax rules, a disappointing standard library) but this particular argument just doesn't apply.

One thing that bothers me about Nushell (even if it doesn't really matter) is honestly just how bloated the table style is, with three columns in each column margin and six columns of enforced line numbers. Why can't it display tables in the same style as regular UNIX commands?

Another thing that bothered me is that the "blessed" way to parse tables from external commands seems very fragile to me. Iirc the builtin parsing commands work solely off table headers, which are locale dependent for many commands, so a script might appear to work fine but suddenly break if an LC_* environment variable sneaks in somewhere. The size filter trick works nicely for ls, but doing the same thing becomes painful again when using df.

I also found the script syntax (implicit line continuations, command seperation, etc.) difficult to understand but presumably that's just a matter of familiarity.

I'll have to give it another try in the future but for now Fish is good enough for me.

No C program is written to satisfy a borrow checker and most wouldn't compile with one, so adding it would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?

Many people who don't know what they're talking about in this thread. No, used memory does not include cached memory. You can confirm this trivially by running free -m and adding up the numbers (used + cached + free = total). Used memory can not be reclaimed until the process holding it frees it or dies. Not all cached memory can be reclaimed either, which is why the kernel reports an estimate of available memory. That's the number that really matters, because aside from some edges cases that's the number that determines whether you're out of memory or not.

Anyway the fact that you can't run Linux with 16GB is weird and indicates that some software you are using has a RAM leak (a Firefox extension perhaps?). Firefox will use memory if it's there but it's designed to cope with low memory as well, it just unloads tabs quicker so you have to reload often. There are also extensions that make tab unloading more aggressive, maybe that would help - especially if there's memory pressure from other processes too.