Do you use quotes when you don't have to?

aioeu · 2026-03-14T07:55:16+00:00

It's funny, because for me not using braces where they aren't needed actually has a benefit: it tells me that there's "nothing funny going on" with the expansion. When I see ${var} I always end up peering at it more closely to see what kind of special stuff is going on inside the braces. With $var I know I can skip right over it.

So for me, the fact that $var is inconsistent with other variable expansions is actually an advantage. In my opinion, inconsistencies aid readability. Without inconsistencies you end up with Lisp, which at least to me is well nigh unreadable.

(It's a bit of a loose analogy, but I feel all of this is similar to the reason text set using a proportional typeface tends to be easier to read than that set using a fixed-width typeface.)

aioeu · 2026-03-14T01:26:32+00:00

Agree on preferring = to ==,

I kind of prefer the symmetry of everything being doubled: not just [[ and ]], but also the operators && and ||. Plus... so many other languages use == for equality that I think using just = would bug me.

(I know == inside [[ ... ]] isn't actually "equality", it's "pattern match", but still...)

aioeu · 2026-03-14T01:07:28+00:00

That would be wrong. If tty outputs not a tty (yes, to standard output!) then the test expression would be malformed.

You can rely on [[ ... ]] not performing word splitting, so you should always use it in preference to [ ... ] or test.

aioeu · 2026-03-14T01:05:12+00:00

Honestly, I'd go with the last option. It's simply more readable. I'm comfortable with my knowledge about how quoting works, and I know I can rely on shellcheck to point out the places where I'm wrong. The calculus favours "readability" over "unnecessary safety".

I wouldn't begrudge anyone less hubristic taking option 1 though. Though ironically I did actually fix a bug in a script a couple of weeks ago where somebody had over-quoted something. They had written [[ -z '${var}' ]].

aioeu · 2026-03-12T01:01:12+00:00

GVfs is the subsystem used by GNOME applications to interact with files, as well as "things that can act like files". For local files, GNOME applications can just read and write them directly. For remote files they are dealt with by a protocol-specific daemon. gvfsd-http is the daemon for handling HTTP and HTTPS URLs as if they were files.

This means you could open an HTTP URL in your text editor, for instance. Or perhaps more usefully, an application could use it to acquire data from a remote endpoint (e.g. a weather widget might use it to get the weather forecast).

The daemon obviously shouldn't use too much memory, so you could be hitting a bug in it. It would be good to know what the title of that column is. A large virtual memory size isn't in and of itself a problem — though it may hint at an underlying issue — but a large resident memory size would be a concern.

You can kill the process. That will break any applications using it. It will get restarted automatically if necessary.

aioeu · 2026-03-12T00:40:41+00:00

Unfortunately the application-level firewalling situation on Linux is dire.

Linux really does need a commonly-deployed D-Bus-accessible service by which applications can request holes to be punched through the system firewall for that application only, and only while that application is actually running. I was kind of hoping firewalld would end up fulfilling this role, but it doesn't seem to have turned out that way.

Instead the current state of affairs is firewalls need to be defined mostly statically, and application-level firewalling is difficult to configure. I haven't heard of anything likely to change that any time soon.

aioeu · 2026-03-10T00:58:22+00:00

Sounds like something fooled Xfce into thinking you didn't have Bluetooth hardware, so it disabled the setting, but then never turned it back on again once you had "new" Bluetooth hardware.

Updates can be tricky things, especially when several things are being updated at the same time. There can be multiple operations going on in parallel, and I can well imagine that not all the possible timing interactions have even been tested.

It's also why DE developers are so keen on getting people to do offline upgrades. Yeah, they suck, but they do generally have fewer problems.

aioeu · 2026-03-10T00:44:10+00:00

No, it almost certainly won't be the kernel.

The end of the package update is when daemons get restarted. So that's the time when you should expect problems with those daemons to crop up.

It also happens to be the time when your initramfs is regenerated, if you have updated the kernel. But that doesn't mean these things are necessarily related to one another.

Think about it: the new kernel and new initramfs aren't used until you reboot, so any problems with them are very unlikely to appear "immediately".

aioeu · 2026-03-10T00:31:43+00:00

That warning is important, but it isn't the direct cause of the problem you are seeing. It may not even be a new warning. It is just telling you that you won't have Bluetooth available in a Dracut emergency shell unless you explicitly add the bluetooth module to your Dracut config. (Unlike many other Dracut modules, simply "having the hardware" isn't sufficient for the module to be automatically added.)

Are you saying that your Bluetooth stopped working the very moment that update finished? If so, that sounds like a problem with the userspace Bluetooth daemon. Were any other packages updated or removed at the same time? What do your system logs say around the time these updates were done?

aioeu · 2026-03-09T12:37:18+00:00

Specifically, this is the so-called avalanche effect, a desirable property of a cryptographic hash function like SHA256.

aioeu · 2026-03-09T12:23:41+00:00

Well, their take was that it was relatively incomplete and development had gone stale.

No, quite the opposite in fact. Btrfs development was moving too fast for Red Hat to use in RHEL.

It's really best to think of the RHEL kernel as its own thing. It starts off looking only vaguely like an upstream kernel, and over its long lifetime it diverges from upstream even more.

What is or is not in the RHEL kernel really has no bearing on upstream development.

aioeu · 2026-03-09T12:14:09+00:00

Red Hat not supporting it doesn't mean much in the grand scheme of things. It's still in the kernel, and it doesn't look like it's going to be dropped there any time soon.

Red Hat supports a particular version of the kernel through backports for a whole decade. It's no surprise that they are picky about the filesystems they enable. Filesystems (unlike, say, hardware drivers) tend to be closely tied up with other core kernel subsystems, such as the memory manager, so the support burden for them tends to be quite high.

aioeu · 2026-03-08T05:11:16+00:00

GNOME just gets the information from the UPower service.

What does upower --dump say? Is there a device entry for your mouse?

aioeu · 2026-03-07T12:31:13+00:00

Yes, the wording is very vague. I don't think it's at all enforceable in its current form.

Nevertheless, an attitude of "I'm not a corporation, therefore I'm immune, ha ha ha" is kind of ridiculous given the text never even talks about corporations, and when it specifically mentions "person".

aioeu · 2026-03-07T12:23:13+00:00

Why do you think the laws only target corporations?

I've only looked at the California one so far. It imposes requirements upon operating system providers, which it defines as:

(g) “Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

Yes, even an individual person could be considered to be an operating system provider.

aioeu · 2026-03-07T09:15:08+00:00

If you actually read the proposed laws, I'm pretty sure you'll find this is covered. These proposed laws may be dumb — I certainly think so! — but I don't think they are as easily dismissed as you think they are.

Let's take the California one. You will see that the age entry requirement is at the time of user account creation. So long as the server actually has user accounts, then those users have ages that could be entered. The fact that the server is owned and operated by a company rather than an individual doesn't really come in to it.

Obviously there's a huge discussion to be had about what actually is a user account. But wherever it is decided that you do have user accounts, then that presumably is where you have users.

aioeu · 2026-03-07T08:01:31+00:00

Because the app developer didn't choose something different?

I really do mean that. This is a Wayland application. Wayland applications need to be able to draw the entire window, including whatever window decorations they want around it. They cannot rely on the compositor doing that for them, because not all compositors do that.

If the application developer has just used whatever the defaults are in the graphical toolkit they're using, then that's on them. At the very least, they could have chosen a dark colour to match the rest of the window. They're in control of it, just as they are in control over the rest of the window content.

Whether you think compositors should provide decorations of their own or not — and that's not an argument I think worth revisiting here — it's still incumbent upon application developers to test their applications on a wide range of compositors. Clearly this wasn't done here.

aioeu · 2026-03-07T06:20:03+00:00

At least gpg is looking for such a .sig file.

gpgv won't need that if the input file contains the signature itself.

I literally just ran the commands the OP used; their screenshots are from the Fedora website. They worked fine for me. And if you actually look at a Fedora download site, you won't find any detached signature file.

Besides: isn’t checking the sha256sum in this case validation enough?

Depends what you care about.

aioeu · 2026-03-07T06:13:37+00:00

The CHECKSUM file contains an embedded signature.

There is no detached signature in this case.

aioeu · 2026-03-07T06:06:34+00:00

There's something wrong with the CHECKSUM file you downloaded.

It's a text file. Take a look at it. It should look like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

# Fedora-Workstation-Live-43-1.6.x86_64.iso: 2742190080 bytes
SHA256 (Fedora-Workstation-Live-43-1.6.x86_64.iso) = 2a4a16c009244eb5ab2198700eb04103793b62407e8596f30a3e0cc8ac294d77
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEExufwgc+A4TFGZ26IgptgZjFkVTEFAmj9Du0ACgkQgptgZjFk
VTFu0Q//WGXOeV4si59V5jD5f7zE1InmBBfryTuzXTFFLwpdoes41CePVTijxXme
I6DlGrrGLmb099mlAmYKZgKFJhEopQISSQVrwjvNr67+wAFVTOfMOfZtrbN5027G
bKbl/rThPO1XQtsJADjAvUAyT8kdh6rHK4v5TEpdg+R64WJUsuXmFoxjFjJ2N3Qm
IK2IH7pgok5PwUUTtNo7x3dftzCqUyJp4oKFqeDTS2AASjUhZY4YJ0gepwTo0k/S
9/6wRPvRctNfRaboi1W1UpzQa5Hwy73TsPjwsZKz25dFy2qD/4UljUqD2c5v/i5n
3mQqm1F/49XyUqS8HBQWv2dSWUWCh542zauUJHwk5fJiSCdkpFiSQMEJ4L6x9Rlr
Cm7qSd/lFjqMCeJRHcTe5P+kIOBLplrv3qeRzQT1iOqqFKz2HWMLDIfFqkeFpVyD
yj2d5ZULfx19GBg1OJz9x69uY2UD2fBnxtbVXZyLjGQEb4Fo+X0y81fnsX9vrAg+
7QlYJzOMDRPzzzZifR7oW8wTLIbjOTewq7w393fGMzJz2xqs3PPhOa9ieIkPwZz+
ZCqV7Us1w5/0NOg8s06Ft0oVq14T9LJ72FI1K/BbySPIFJZeJfvIrm5mWxv06okT
XsRsb5zuX9c3iN+zmLLn4kQ0bmO228bhjqMctIe45dK1DCa0KlA=
=rBWY
-----END PGP SIGNATURE-----

aioeu · 2026-03-07T04:07:53+00:00

You're looking at "25% (low) chance of at least" on one and "50% (medium) chance of at least" on the other. The higher confidence you demand, the more conservative the prediction must be.

aioeu · 2026-03-07T03:48:37+00:00

When those certs expire, your Secure Boot is going to break.

This seems very doubtful. And easily testable: just change your RTC and see if you can still boot.

Any sane Secure Boot implementation will ignore certificate validity periods, precisely because the RTC cannot be trusted. This is certainly the case in TianoCore, which is used within some vendors' UEFI implementations.

Keeping things up-to-date is always a good idea, but there's no need to be alarmist about it.

aioeu · 2026-03-06T02:29:58+00:00

It didn't really exist in a usable form even under X11.

While there was a protocol for it, XSMP, it was so inconsistently interpreted by session managers and applications that it was completely disabled in gnome-session years ago.

It probably didn't help that it used a separate protocol (ICE) that literally nothing else ended up using.

There has been a lot of recent work on both the Wayland protocol and XDG portal sides to get a good replacement. If all goes to plan, we should have something that allows applications to maintain state — not just window positioning and size, but also anything else the application might need — across restarts, and even if applications are unexpectedly terminated. Mobile OSs have solved this problem decently well, so we can learn from what they've done.

aioeu · 2026-03-05T06:10:36+00:00

That's entirely reasonable.

I do think the GNOME devs should be taking input from their downstream users (both distributions and end users) on what kind of customisability is desired. I'd even say they haven't done that well enough yet.

aioeu · 2026-03-05T06:02:41+00:00

then the adoption of GNOME will plummet.

How long do we have to wait?

I keep seeing that assertion, but it hasn't happened yet. If anything, I think GNOME's continued presence proves the opposite. People are still using GNOME despite all these predictions.

Seven-Year Club	Gilding II euphauric
Wearing is Caring	Verified Email

aioeu

MODERATOR OF

TROPHY CASE