I’m saying that if flatpak tried to implemenet machine-id obfuscation before releasing, they might not have ever released. By constraining their scope, they were able to focus on their other goals and release, and a lot of Linux users including me, are glad they did so. You can think of systemd’s machine-id situation in the same way

I was agreeing with you. Systemd breaks unix philosophy. You know what else breaks unix philosophy? The Linux kernel. It’s absolutely massive. If you want unix philosophy, switch to a microkernel.

Also another commenter in this discussion pointed out that flatpak does not actually obfuscate machine-id. You can read the issue tracker here: https://github.com/flatpak/flatpak/issues/4311

Basically comes down to a design decisions from 15+ years ago, in things that flatpak depends on. This is an open issue to this day. Would it have been better for flatpak to have delayed release until this was solved, possibly remaining unreleased to this day? Meanwhile everybody would have to use regular system packages, which not only have access to machine-id, but also the entire userspace, with zero sandboxing. I doubt that would be better.

Good call, I double checked and you seem to be right.

I found the github issue tracking this: https://github.com/flatpak/flatpak/issues/4311

This is easy to state but a lot less easy to solve.

Hiding /etc/machine-id isn’t going to be a meaningful improvement if “other device identifiers” can’t be hidden. The most obvious one is the MAC address of each network interface, which is globally unique and available to all processes that have network access.

To prevent access to the machine ID, xdg-dbus-proxy would have to block all org.freedesktop.DBus.Peer.GetMachineId() calls, which is an incompatible change. That method was intended as a way to determine whether two processes on the bus are running on the same machine; with hindsight, it would have been better as IsOnSameMachine(s: unique_name) -> b on the message bus, rather than GetMachineId() -> s on each peer, but running untrusted software was not really a thing when the Peer interface was designed 15+ years ago.

Just goes to show how much deeper these problems are than they appear on the surface. Design decisions from 15+ years ago haunting software of today

P.S. You can shorten your command to simply flatpak run --command=bash org.torproject.torbrowser-launcher -c "cat /etc/machine-id"

I use --command=bash a lot when I want to just enter a shell inside the flatpak environment

Saying Linus uses something is just appeal to authority by the way.

I was giving Linus as an example of a member of the Linux community, and a particularly prominent one at that. There are many indicators that Fedora is well regarded, and that is just one of them.

you either adopt them or it becomes increasingly difficult to run software on your distro.

Arguably, systemd made it easier to run software on Linux. The standardization made it easier for devs to write software that worked across distros. Devs didn’t have to fight fragmentation in the lower levels and could focus on building platforms on top like Flatpak, which in turn led to even more software and apps available on Linux. It’s way easier to find and run software than a few years ago.

I’m guessing what you were trying to say is that it’s harder to find and run software on Linux that doesn’t use systemd. That’s fair. Just like it’s hard to find apps nowadays that don’t use web technology, and require something like Electron or Firefox to run. But if we think of systemd as a platform (though I think it’s more complicated than that), does it go against the ideals of Linux?

The fundamental Unix principle is having small programs that do a single thing well and that can be composed together

First off, I know you didn’t say this but I want to just clarify: software principles are different from community ideals. Software principles are a means to an end. And they are often broken. Modular design is hard to get right. Microservices often end up messier than the monolithic approach. Ultimately it’s a balance. And strategy plays into this too. If monolithic design allows faster iteration, then even if it gets replaced with modular design later, you can use the lessons learned during those iterations to make the modular design.

It’s possible that someday Redhat tries to weaponize systemd and it ends up holding Linux back until we can replace it. But I doubt it. If you look at the recent backlash that Fedora and Firefox has gotten for AI, you can see that the Linux community is pretty vocal and active about their ideals.

I’m not sure if the principles have been gutted like you say. Fedora, for example, uses systemd, and is supported by the commercial RedHat. And yet it is well regarded in the Linux community, and has firmly stuck to open source and pro-privacy principles. They foster diversity too, like the Fedora Atomic and Universal Blue projects, which make it easy to fork distros and create new ones. Not to mention, Linus Torvalds uses Fedora.

One could say that Linux is already growing at its own pace. There are some that wish it would move slower, some that wish it would move faster. systemd wasn’t forced on distros. in fact Ubuntu fought it for years, since it was created by their competitor after all. Yet Ubuntu still adopted it in the end, so it must have been worth it.

The way I see it, back in the day, Linux was too fragmented in some areas, and at the same time lacking isolation in others. Systemd standardized and addressed the fragmentation, while containers introduced isolation where needed. The lines are being re-drawn. But I don’t think the principles of Linux were compromised that much.

I know humans that hallucinate more

Well one reason why adoption matters is network effects. Increased Linux popularity, means that more developers will develop for Linux. At a broader level it means that the ideology and principles of the Linux community, like software freedom and privacy, can produce quality results and products for the masses. That brings more power for the Linux community, and more adoption of their principles.

On the flipside, if the base Linux experience is mediocre, then nobody will bother developing apps and extensions for it.

If you are completely happy with Linux the way it is now, then that adoption probably doesn’t mean a lot. But I personally think there’s a ton more that can be done in the Linux and privacy world

I can see that actually. I guess the post points out two things:

1. the dev being a a bit deceitful, downplaying their use of AI when clearly the project is like 90% AI
2. the community being frustrated by the lack of quality signals in the new world. Previously programming took a lot more effort, so just the existance of an app already meant that the dev was mildly competent. And at the very least it meant that the dev could fix and maintain the app when something broke. Now those trust signals are gone.

but I was so new to the game I didn’t even know what those words meant

There’s nothing wrong with being new to something. But you shouldn’t be new to rust and releasing an app. Normally by the time you’ve written such an app you would be familiar with rust, but vibe coding allows you to bypass that wall

Many software decisions are more about strategy than philosophy. Compromising on ideals and principles to gain adoption. As mentioned before, I would not be surprised if dependence on machine-id was simply strategy.

Systemd might be replaced in future. But currently it’s used in all major distros. It’s design and ideas will probably inspire whatever replaces it. If they had spent their time clinging to philosophy and ideals rather than making compromises, then they might have never left the ground.

Those papers are based on dense model architecture. The MoE architecture that I mentioned a few comments ago, does not follow the same laws. Architectural changes could push us past the wall.

Not to mention if we reach 90% accuracy (which was defined in those papers to be AGI level), there’s no reason we will need to keep making new models and training them. AGI is good enough. After that we improve inference performance and bring inference cost down.

Well I’m not here to argue about systemd in general, that’s a far larger topic. All I’ll say is that from my experience, systemd felt cleaner than the competitors at the time and created a lot of conventions and standards that are taken for granted today.

For example, to bring this back to the original topic, another commenter in this thread mentioned that systemd provides an API for generating randomized machine-ids that flatpak utilizes.

Though flatpak is gaining more dependency on systemd, and I don’t think that coupling is necessary, so I’ve been keeping an eye out in that space.

Edit: researching a bit more on the topic, there’s some interesting comments here about how systemd is not as monolithic as people think

flatpak is not depending on systemd as a whole, they’re depending on a new component called systemd-appd…it is an API + a spec, just like what you’re asking for. But it’s implementation first, because any API + spec designed by committee rather than being driven by an implementation universally sucks.

[systemd] not a monolith, which is obviously true because there is no distribution that ships all of it turned on by default. Fedora comes close, but most other distros pick and choose which parts of systemd to use.

systemd-appd will likely depend on some but not all of the rest of the systemd system.

Well if we use vague metrics like those, then anybody can claim anything. “more than 1/20 tokens wrong” what does wrong mean? One view is that a computer program is never wrong, it does exactly what the code says. Another view is that if the AI ends up at a verifiably incorrect answer (for example if you prompted it with a math question), then all the tokens it gave out were wrong. But then humans can be wrong too. Are humans 1/20 neurons wrong on average?

For comparison, Moore’s law uses well defined metrics like computations per second. That’s what made it a useful concept.

Tbh I haven’t kept up with that issue for a while now. I’m guessing it still isn’t addressed. I usually disable JS anyways so that mitigates almost all attacks. But I have installed browsers in Distrobox before, installing the browser as a system package instead of a Flatpak. Do you know how the sandboxing works in that case?

There are obviously more such cases under a forced-digital regime

I wouldn’t just dismiss it as “obvious” when that’s the topic of the entire discussion. You first have to prove that digital methods make it harder to boycott certain companies. We already discussed how offline access can still use third-party services when processing the data (like OCR services). And on the flip side, digital methods can avoid third party dependencies (like the government hosting their own email).

Indeed in the end forced-digital is just all about saving a buck at the expense of our freedom.

Maybe try to convince the other citizens to pay more taxes in order to maintain an offline system. Forcing everybody to pay for a system that that most don’t care about, isn’t very “free” either

Maybe for initial testers and feedback, look for a community that would be super supportive. Like LocalLLaMa and Hacker News

I get the impression you’re not actually familiar with the history of Linux or Unix philosophy in general.

I’ve read enough mailing lists and issue trackers to know that they are far more complex than they look on the surface, so I definitely won’t claim authority about them.

Take this one that I found recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

It’s a bug report about Firefox’s favicon cache. They started looking into it, but found out that if they fix this bug, it creates fingerprinting risk, so they have to address that as well. And so the issue gets stuck in limbo for like 10 years, and is still open till today.

Regarding systemd, it had to be built on top of the existing architecture, and more importantly, had to appeal to the Linux community to be adopted, so it couldn’t change too much. I assume they have their reasons for depending on machine-id. It might not even be a direct dependency. Maybe it allowed easier adoption by the big players.

I don’t know, and honestly, I don’t really care about digging into every single fingerprinting vector (of which there are probably tons more), when I can just use containers. And while using containers might feel like a hack or workaround, if we look at Flatpak, it seems like containers are becoming the framework for app isolation on Linux, similar to what already exists on Android. So it may very well become the official solution to privacy and security on Linux.

My argument was that the models would get more powerful over time, even when controlling for size and energy usage. I wasn’t talking about waste

I’m no physicist, but afaik particle/wave duality was already a thing before quantum. So we were already representing the world as waves aka frequencies aka vibrations. But then we discovered that those waves were composed of smaller waves. The rabbit hole can go on ad infinitum, as we zoom in to these waves trying to figure out the equations behind them, but we keep finding more complexity, like a fractal.

I’m not familiar with the purposes or history of machine-id, I’d guess that it’s just a legacy artifact that can’t be easily removed now.

There’s definitely a lot to be desired when it comes to privacy on Linux. Unfortunately Linux was designed before many of the privacy and security best practices became established, which is why is it less secure than modern systems like Android (source). Trying to re-architect Linux at this point would be an insane undertaking. Machine-id is just one thing in a long list that would need to be changed. Nothing wrong with advocating for it, but I just wouldn’t expect it to happen for at least 5 years.

Containers are a modern technology with isolation and security as a core goal from the start. And by now, containers are already deeply integrated into the Linux community, for example look at how the entire Fedora Atomic project (including Bluefin, Aurora, Bazzite) uses container-based infrastructure to build the OS images. So that’s why I’ve been moving towards it as a solution for my privacy needs, and I recommend others look into it as well.

Edit: rewording some sentences