she/they
The biggest drawback of not providing any SSDs even as a fallback is obviously... what if the app just doesn't draw CSDs?
There are many new Linux users who try to get something like DaVinci Resolve running and then can't maximize it because it doesn't have CSDs. For these users it just makes using Linux feel broken for basically no reason.¹This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it's a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?
¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn't draw the window buttons. That's certainly a choice... I think the overall point isn't too affected but this specific app isn't a good example since it would still be broken if GNOME had fallback SSDs.
That's a largely unrelated topic... You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I'm not aware of a project actually taking this stance).
There's apparently a ZSH plugin for this with a quite a few stars, though I haven't used it and can't speak for how well it works. In other shells what you want just doesn't exist to my knowledge, though it should be possible to script it with enough effort.
The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:
- Terminal emulator keybindings will step on shell keybindings, and the shell will never know about it because it can't actually see the keys being pressed.
- Even if the terminal doesn't care about a key, it might be impossible or error-prone to detect anyway. This applies to surprisingly regular keys like Tab.
- As you've noticed some terminals try to get clever and do things like making Ctrl-C copy if you've selected text. The shell doesn't know about this either.
- Most shells and TUI apps have selection modes. These are independent from terminal selections.
- There's no standard way of using the clipboard in Linux, but multiple different ones that may or may not work.
All of these problems gets worse if you add multiplexers like tmux by the way.
Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don't quite share your idea of what reasonable keybindings look like (and it's also a little bit broken, though for mostly unrelated reason).
Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).
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
You can also use
<C-C>to quit command mode instead (and this one works in keymaps). It also works in Insert mode but doesn't trigger theInsertLeaveevent, which might upset some plugins.As far as I know the character pending mode thing that
rdoes is a bit unique in that it isn't insert mode, but also not quite replace or operator pending mode. If there's a way to remap any key to work withrthen I'm not aware of it.Have you considered instead remapping
<Esc>on an OS level? The XKB optioncaps:escapeturns your Caps Lock key into an additional Escape key, which is even easier to type than<C-Space>.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-lightmakes everything light mode.prefer-darkmakes everything dark mode.defaultmakes 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@importdirective 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_THEMEenvironment 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 withgsettingsexcept 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.
Extensions aren't apps. Imagine all mods would break if a game is updated and you'd have to wait... oh yeah you do, because that's how these things work.
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
dfanddutell you about btrfs volumes. Scripting aroundduor usingncduwill 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 particularlybtrfs-filesystem(8)), which among other things provide versions ofdfandduthat actually work, or at least they do most of the time instead of never.- JumpDeleted
Permanently Deleted
You're welcome, glad I could help :)
- JumpDeleted
Permanently Deleted
FN keys are usually handled at a firmware, sometimes BIOS or driver level. This makes them completely inaccessible to keyboard remappers (they have no idea when it is pressed), which is why none of them can do this.
This Stackexchange answer looks like it should contain the information you need, but I don't have a 2014 MacBook to test it.
You could make the same kind of articles for the old coreutils if you really wanted to. Just creatively "rewording" the bugfixes from the recent 9.8 release:
- GNU Core Utilities Are Causing Failures [when copying between NFS and non-NFS filesystems with ACLs]
- GNU Core Utilities May Cause Data Corruption [with copy ranges larger than 2 GiB]
- Correctness Bugs Found in GNU Core Utilities [
tail --pidmay race with reused PIDs]
I feel like the reactions regarding
uutilsare a bit... off in general. There seem to be a lot of people who are pathologically negative towards open source projects for, frankly, bullshit reasons, like vague complaints about "Rust evangelism" (what?) or how permissive licensing is against the spirit of open source (WTF).Phoronix isn't helping with these clickbait articles which border on content farming and their failure to moderate their comments of course, but these negative attitudes seems to cut across sites, also including Lemmy, Reddit and even Hackernews.
The
uutilsteam seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.You could always swap out crons, syslog, init systems, and it would not affect Gnome.
That just isn't true. Both GNOME and KDE already have hard dependencies on systemd-logind. GNOME hasn't supported non-systemd Unixes since 2015! The only reason it works is that the elogind project provides a systemd-logind implementation decoupled from the rest of systemd. The GNOME team has elected to give users of elogind (despite not being officially supported) advance warning that they'll have to do some amount of extra work in the future if they want to ship GNOME 50. Honestly I think that's quite fair of them.
There are more GNOME features that don't work without systemd even if it launches, like application isolation using systemd scopes. Fundamentally this is about not having to reinvent the world. Why should every DE have bespoke implementations of user, login and service managers instead of just using the ones that 99% of user systems already have?
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.
Nu's
findbuiltin isn't a GNUfindrepacement. I think what you actually want islspiped intowhere:nushell
ls **/* | where type == fileI do question the choice to alias a well-known program with a builtin that does something entirely different. You can also use
^findto avoid calling the builtin. I would've expected\find(bash-like) orcommand find(fish-like) to work as well, but alas...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.
This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can't draw SSDs (or signals that it doesn't want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.
It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they're made for GNOME, a.k.a. anything using Libadwaita) or they don't really have a use for them like regular Qt apps.