TaintTaul

joined 2 weeks ago
[–] TaintTaul@programming.dev 1 points 6 days ago

Linux, in general, is excellent for privacy. Period. Like, it literally can't get better than no telemetry.

Regarding Ubuntu, it has had some controversies:

I'd argue that the above just makes it hard(er) to trust them.

Consider taking a look at Privacy Guides' recommendations.

[–] TaintTaul@programming.dev 1 points 6 days ago

You're indeed describing workflows that suit servers better. Be it "immutable"(/atomic) or not.

But, atomicity (i.e., updates either occur as a whole or simply don't at all) have been used on our phones (source) for quite a while now. And we do all kinds of things on our phones.

Similarly, we might borrow other concepts for reliability: like e.g. making part of the root filesystem read-only at runtime. On Fedora Atomic (and its derivatives; OP's Bluefin being one of them), this basically only applies to /usr. This is the extent of its immutability. Most of the remaining root folder is symlinked to /var (source). Which, together with /etc, continues to be mutable. Thus, enabling it to become perfectly suitable for desktop workflows. Like, literally; there's very little you actually can't do on these. The main difference being how. Hence, it's more of a paradigm shift if anything.

Rant on the naming schemeUnfortunately, the name "immutable distro" doesn't do a great job at conveying the nuance described above. Heck, while atomic distro is definitely more descriptive, I don't think it helps to group/categorize these distros under one name beyond contrasting it to the traditional model. Simply, because the guts of these distros tend to differ a lot compared to traditional distros. I'm afraid that this will inevitably lead to a shift in how these convos will go: Instead of peeps making all kinds of assumptions because "immutability", they might make all kinds of assumptions based on their experiences with the popular kids; i.e. Fedora Atomic and NixOS.

[–] TaintTaul@programming.dev 1 points 6 days ago

I'm afraid that might be the case...

[–] TaintTaul@programming.dev 1 points 6 days ago

Thank you for clarifying! And apologies for being rather abrasive.

I never said it was impossible

True. Based on your writing, I kinda assumed you thought it was impossible (or, at least very finicky/bothersome). I'm genuinely sorry for responding by assumption instead of asking for clarification first.

The simple fact they don’t see an apparent way to install simple tools

I guess OP just didn't take the effort to look through Bluefin's documentation and find the related entry. Or, they simply chose to use 'us' (i.e., the community) as [insert your favorite search engine].

or modify fstab would be for me unacceptable

To be clear, modifying /etc/fstab on Fedora Atomic is literally no different than on any other distro.

So..., I suppose OP simply assumed a 'faulty' workflow for Bluefin, for whatever reason. And came here to ask the community for assistance when it didn't work out as they'd expect. Nothing wrong with that either.

I prefer freeballing my OS, thank you very much. I simply assumed op was more like me and less like you.

Here is where I need your assistance in deciphering 😜. Would you be so kind to explain what you mean by this? Please, provide ample examples/elaborations/explicitations to make it clear. Thank you in advance 😊!

[–] TaintTaul@programming.dev 7 points 6 days ago (3 children)

If you want to go play with /etc/fstab and you have a concept of "everyday cli tools"an immutable distro is not for you.

Please don't conflate stuff.

On Fedora Atomic^[And probably most distros that are -perhaps erroneously- referred to as "immutable", though the finer details might be different.], it's possible to:

  • Change the content of /etc/fstab. Heck, the same applies to everything under /etc. The only difference being that a pristine copy is kept at /usr/etc AND the fact that any changes to /etc are being tracked. Said changes can be accessed with ostree admin config-diff.
  • Install CLI apps just fine. Refer to this comment for more details.

An immutable distro is made for people that do not use a computer but use a browser.

False. Again.

While I agree that it's a very sane recommendation to the technologically inept, it would be a huge disservice to suggest it can't handle more advanced workloads. Because, quite frankly, there's very little it actually fails at. And most of its user base would vouch for this. And that list of restrictions/limitations is becoming smaller as we speak...

[–] TaintTaul@programming.dev 2 points 6 days ago (2 children)

I feel too limited when trying immutable stuff

Is this rooted in experience? Or mostly just on vibes?

[–] TaintTaul@programming.dev 9 points 6 days ago

No one mentioned it yet, but there's also AppManager.

[–] TaintTaul@programming.dev 3 points 6 days ago

Not in my experience. Though, I suppose I have to thank BlueBuild for the heavy lifting. It's not even restrictive either, even big^[relatively speaking] projects like secureblue depend on it.

[–] TaintTaul@programming.dev 10 points 6 days ago* (last edited 6 days ago)

Just to be very clear: the name "immutable distro" is unfortunately a misnomer. In practice, the restrictions found on so-called ~~"immutable"~~ atomic distros are very tame.

For example, on Fedora Atomic^[The atomic distro I'm most familiar with.], it's mostly a paradigm shift. That is, you can achieve (almost) everything that you can on a traditional distro, the only difference being how.

So, if we would take OP's query as an example, they are not able to do sudo dnf install vim btop. Instead^[Knowing that they're on Bluefin, a derivative.], they have to do brew install vim btop. Additionally, these changes persist, as you'd expect. Please note that this is just one of the ways/methods you can achieve this on Bluefin (and other Fedora Atomic derivatives). Other methods include:

  • Install within a distrobox and export it.
  • Simply layer it.
  • Make a custom image that installs these by default and switch to said custom image.
  • Install as a sysext.

As you'd expect, each one of these comes with its own set of tradeoffs.

[–] TaintTaul@programming.dev 3 points 6 days ago

I’ve had some issues with AppImageInstaller that I haven’t had with GearLever

Would you be so kind to elaborate? Being explicit would already make a huge difference. Thank you in advance!

[–] TaintTaul@programming.dev 2 points 1 week ago

Such a cool device. I hope many other vendors will eventually include that form factor in their lineup. I can't wait to get my hands on a high-end Thinkpad DUO.

[–] TaintTaul@programming.dev 3 points 1 week ago* (last edited 1 week ago)

I wonder if they'll one day just alias a bunch of stuff, kinda like what Ubuntu has done with forcing Snap down people's throats. So, like:

  • sudo dnf install bottles actually doing flatpak install bottles
  • OR, e.g., sudo dnf install tldr actually doing brew install tldr
  • etc...

I don't think it's necessarily bad as long as it's very transparent on what it actually does (and why). And..., offers choice where applicable*.

Or..., like, introduce a new package manager that basically functions as a front-end. Would that ((and/)or the earlier alias-thing) be worse than sticking to the development of a single package manager until it does all (à la Snap)?

view more: next ›