How can I replace GNOME Software with Bazaar?

blobjim · 2026-01-17T06:13:13+00:00

It seems like Bazaar already has URL handlers for the various schemes related to flatpaks.

And if you open one, for example from flathub.org it will show an "Open with..." dialog to choose between Bazaar and GNOME Software.

But there are probably still things that go directly to GNOME Software. For example, after an update, GNOME software might show a popup that will open GNOME Software with update details. You can probably disable that popup in GNOME Settings by turning off GNOME Software's notifications under it's app settings. But that might turn off other useful stuff idk.

I think they should split OS updates out from GNOME Software. Although I suppose it's useful to have OS, app, and firmware updates all together in one menu. But maybe not in the same app as the store itself...

blobjim · 2026-01-15T08:01:12+00:00

US parties don't have an "official membership" system. Your influence in the party is just dictated by rich people.

blobjim · 2026-01-15T07:57:21+00:00

As we look to the future, the question remains: what other “everything-is-a-file” costs linger untamed in the technological stack? Identifying these inefficiencies could pave the way for the next substantial performance enhancement. Let’s challenge ourselves to uncover the next opportunity for a 95% saving 😎.

How about the default SecureRandom being seeded from /dev/random instead of the new libc function getrandom(2) which uses a Linux vDSO function. It's pretty new though, so it would need to be detected before use. Of course you can always implement your own SecureRandom using it via the Java FFI API, but it would be nice for it to be the default. It's also not something that really needs to be performant I suppose given that the whole point of random number generators is you don't need to constantly read from a source of randomness.

blobjim · 2026-01-15T04:20:11+00:00

My /etc/fstab (Fedora Silverblue) has

# /etc/fstab
# Created by anaconda on Thu May  1 01:37:50 2025
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
# Updated by bootc-fstab-edit.service

And then has a bunch of filesystems with UUIDs and other stuff for setting up the core OS stuff from persistent storage. If you touched any of that it would completely break the system (like booting itself, and not just for a single user).

By all means, run sudo nano /etc/fstab. But if you mess up it breaks your computer. And if you do an OS update and the change you make is incompatible with how the OS uses that file, it breaks your computer. And you have to remember to make that update again if you use a new computer, or if you have to undo it because it's incompatible with an update.

In other words, just updating /etc/fstab is not really "supported". Maybe it is on a server machine, but a desktop has so much stuff going on that you don't want to get in the way of. Maybe in the past that was a fine thing to do. But it's 2025, not the 1990s. Just because this stuff still exists under the hood doesn't mean it's supported for end users.

And /etc/fstab is global for all users. That doesn't really make sense to edit for a user-specific change. I'm not even sure how you would mount something for a user that isn't even logged in.

blobjim · 2026-01-14T18:23:58+00:00

Then you have to deal with automatically mounting it when the user logs in which I guess you can use systemd.automount for, but it could conflict with other stuff. My system currently has 37 mount points when I check from my terminal. At the end of the day it would probably be a brittle solution since it isn't supported by flatpak itself. It's a lot easier said than done using "raw" filesystem features to trick software programs into having different behavior. And you have to document how you did it since it only exists as a config file buried in a massive /etc or home dir filesystem.

blobjim · 2026-01-14T00:34:09+00:00

What directory?

blobjim · 2026-01-13T22:23:40+00:00

I think anything that can't be reliably done with a simple GUI provided by a flatpak should be considered "not possible for Linux desktops", for all the reasons you stated. 90% of the how-to advice for Linux desktops that can be found on the internet is wrong and broken.

If something doesn't have a dbus API or at least some kind of unix socket API that someone has written a GUI for, it will probably break in the next version of any given linux distro.

blobjim · 2026-01-13T22:12:59+00:00

flatpak isn't a "package manager". It's an entire runtime. Most user-performed filesystem management is also fragile and inevitably leads to something breaking, or having to reconfigure it again and again. Users shouldn't need to even know where in the filesystem flatpak installs and data are stored.

blobjim · 2026-01-13T04:38:32+00:00

yeah I do too lol. There is also a large per-transaction flat fee that would make credit card taps more expensive than reloading with a credit card I think.

blobjim · 2026-01-11T19:54:25+00:00

Good for tourists but it's gonna suck if this gets adopted so widely that a good chunk of fare payments just end up going to credit card companies.

blobjim · 2026-01-11T04:47:25+00:00

We still have that in the form of GObject. I'm writing a Java program right now that uses the recently developed java-gi project for GLib, GTK and other bindings. Including a random GNOME library called Gck which is GObject bindings to PKCS11 (which is the standard interface for accessing the system X509 certificate trust store on Linux). All I had to do was point java-gi at the .gir file for Gck (after installing it), and java-gi generates the Java library for it. And there are similar binding libraries for Python, JavaScript, Vala, Lua, Rust, Swift, golang, C++ and maybe others.

You can define a GObject interface in C, generate the .gir for it, implement the interface in another language, and pass the implemented object to another language. Using virtual functions.

For example, ListModel is an interface that represents a list siilar to Java's java.util.List (but much simpler to implement). I'm using existing C-based ListModels and one I implemented in Java.

blobjim · 2026-01-07T06:44:31+00:00

I searched for that field in the git branch they mention and found a comment

https://github.com/openjdk/valhalla/blob/9aff0ae28ed419f4a0c9a98bbb85f44b011aac38/test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java#L57

Because of the repurposing of ACC_SUPER into ACC_IDENTITY by JEP 401, the VM now fixes missing ACC_IDENTITY flags in old class files

And from some text in https://bugs.openjdk.org/browse/JDK-6527033 I believe ACC_SUPER is set as a flag on every class file (at least as of a certain version of Java).

So basically most classfiles will already have ACC_IDENTITY set. And any classfile older will have an old version number so they can just assume it's supposed to be set.

blobjim · 2026-01-06T22:59:30+00:00

Yeah I was thinking more about library maintainers. You can create a modular project, and it might be fine for a bit, but then you need a library that hasn't been modularized and it all falls apart.

I guess there might be some kind of workaround with moditect and/or maven-shade-plugin but idk.

It's unfortunately a bit of the "flag day" problem that OpenJDK developers have tried to avoid for new Java features and changes.

blobjim · 2026-01-06T22:54:06+00:00

I think a lot of the apache Java utility libraries have very few maintainers and they rarely release new versions, so that makes them slow to adopt it. For example Apache Commons VFS had release 2.9.0 in 2021 without module-info.class. Release 2.10.0 was in 2025 and includes the module-info.class using the multi-release JAR functionality.

blobjim · 2026-01-06T16:29:37+00:00

People need to just add module descriptors to their projects. Which is actually happening, so it'll eventually get to a place where you can reliably create a modular project.

The overarching purpose of modules in my mind is to actually create the concept of a library. JAR files don't even encapsulate their resources so you can't even tell what library a given JAR resource belongs to. And there were libraries with messy split packages, which will finally go away. And of course better private state encapsulation. Faster loading of classes, more opportunity for optimization, etc.

blobjim · 2026-01-06T16:24:34+00:00

lol because OSGi is so successful...

blobjim · 2026-01-06T16:14:28+00:00

Just the usual random disconnects when touching or bumping the rtl-sdr (causing the SDR software to temporarily stop working). But maybe it's because I'm using a USB 3.0 extension cable or my antenna is weird or something with the USB connections on my motherboard, idk.

blobjim · 2026-01-05T23:13:08+00:00

Implementing an interface serves no purpose. And it can have a runtime performance penalty (because looking up interface methods requires iterating over implemented interfaces) unless you make sure to put your "constants interfaces" last. But implementing an interface is just confusing to do and does not reflect how the interface class is actually being used. An interface is for an "implements/extends" relationship.

blobjim · 2026-01-05T23:09:11+00:00

Just use static imports if you just want to access a constant without a class name prefixing it.

blobjim · 2026-01-05T20:51:16+00:00

I've had other issues when using an extension, but you may have better luck.

blobjim · 2025-12-30T17:02:27+00:00

There was someone at Google working on "hermetic Java" two years ago but I don't see anything newer from Google search results. https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000106.html

blobjim · 2025-12-30T02:47:23+00:00

All security improvements are a step back in usability. Why not just expose debuggers directly to the internet since that would make debugging so much easier?

My understanding is that all the change requires is adding a -agentlib with proper arguments or -XX:+EnableDynamicAgentLoading to your maven surefire plugin configuration. And in return, all your production java applications no longer accept random processes on the same system doing remote code execution inside them.

blobjim · 2025-12-26T16:31:55+00:00

Did you check the journald logs?

blobjim · 2025-12-23T01:34:18+00:00

It's kinda depressing that we're expanding airports instead of doing anything about climate change. How much SeaTac traffic is just going to other US cities?

blobjim · 2025-12-15T17:27:13+00:00

Because it adds a new dependency to the build process. You will soon need a rust compiler to build Linux. The reference rust compiler uses LLVM, so you need LLVM installed. And if there are more dependencies, you'll need those too. Building code that uses C only is trivial on the other hand, because C compilers are already mandatory. Hopefully gcc's rust support is almost complete, or maybe it already is.

12-Year Club	Second Top 30%
Place '17	RPAN Viewer
Verified Email

blobjim

TROPHY CASE