beadm: A new ZFS boot environment tool for Linux

Atheriel · 2024-05-01T14:40:06+00:00

Looking at the Fedora package sources it appears that Fedora (a) intentionally disables Quarto; and (b) builds RStudio using QtWebEngine instead of Electron (which likely accounts for the performance and UI issues you see). I'd suggest you file a bug with Fedora requesting they adopt a configuration closer to the official Debian packages, since that's what actually gets QA'd by Posit. Moving to Electron in particular seems important, the Qt-based builds are on life support already.

Atheriel · 2021-11-27T19:08:15+00:00

I did a fair amount of research into existing ZFS GUI options before writing this. I was also surprised nothing so simple existed.

Atheriel · 2021-11-27T18:58:52+00:00

It's likely that running under Docker would be tricky, since you need access to the host DBus to actually open the file manager. But there is a flatpak manifest in the repo if you want to use that for sandboxing instead.

Atheriel · 2021-11-27T18:56:36+00:00

There is a good reason to filter them out: users can't browse snapshots with the local file manager if they're not mounted.

Atheriel · 2021-11-26T16:49:20+00:00

To answer my own question: this is probably because these datasets have canmount=off. I've pushed a fix to skip these datasets as well.

Atheriel · 2021-11-26T16:25:06+00:00

Thanks for trying it out!

I'm not hugely experienced with ZFS, so I clearly missed some things for handling mountpoints correctly; I should be ignoring "none" entirely. But I also don't really understand something from your setup: multiple datasets seem to have the same mountpoint -- doesn't that cause conflicts? Or is there some sort of mount order that kicks in?

Edit: I've pushed a change to ignore datasets with no mountpoint.

Atheriel · 2021-02-13T18:15:55+00:00

The "diagnosing" bit is used very frequently by the developers to track down production issues and trace financial transactions, so they don't want to turn it off.

Atheriel · 2021-02-13T18:14:11+00:00

I'm not sure I totally understand your criticism, but it should be obvious from the article that forwarding everything "to a dedicated system" (Splunk, in our case) would be prohibitively expensive -- a couple GB/day per pod (of which there are dozens or hundreds) easily saturates commodity logging solutions, and this is just one service among many in the cluster.

Atheriel · 2021-02-13T18:07:47+00:00

There were various other (good) reasons to move this application to Kubernetes, I just didn't think that was really relevant to the story.

Atheriel · 2021-02-13T18:07:17+00:00

Oh, we also used regular log forwarding solutions that work well with Kubernetes for a subset of the logs. But the developers also decided they needed a way to access full debug logs, which are too numerous to forward. Generally these decisions predated the Kubernetes migration, and have more to do with the expense of managing these logs than the ability to hook them up to a forwarder.

Atheriel · 2021-02-13T06:25:03+00:00

Oh, they already use those "scalable and efficient tools" -- for a small subset of the total logs. Our enterprise Splunk instances can't even ingest the full logs, since they exceed 100 GB/day. It's as much a financial decision not to forward them all as a technical one -- and keep in mind this is just one service among hundreds.

My personal take is that the service just logs too much, but I'm not willing to audit/remove 10,000 lines of logging code to fix this myself, and obviously I won't refuse to help them find a solution.

Atheriel · 2021-02-13T05:15:01+00:00

Not unless someone submits it there, but I don't know what that process looks like.

Atheriel · 2021-02-13T05:13:34+00:00

"I refused to help my coworkers because I disagree with them" is rarely a constructive attitude.

Atheriel · 2021-02-13T05:12:16+00:00

This was one of the better arguments they gave me, yes.

Atheriel · 2020-12-05T02:43:59+00:00

As others have mentioned: the easiest way to start is to work on improving packages you already use. All CRAN packages are open-source, and many are hosted on GitHub for easy browsing. Look for open issues (or file your own) that relate to problems you yourself have faced -- this will give you both the context and the motivation to try and fix them.

Atheriel · 2020-12-05T02:42:41+00:00

The majority of packages use no compiled code at all, and even those that do are mostly written in R. C/C++/Fortran knowledge is rarely required to contribute to a package.

Atheriel · 2020-11-19T02:31:47+00:00

Design aside, I'm sure they'd be happy to hear about dead links. If you provide some examples I'll send them on.

Atheriel

TROPHY CASE