bashmount

Asahi Linux completely supports all the M1 Mini hardware.

But it does look the prices on these went back up because people use them for OpenClaw. 🙄

I run Asahi Fedora Linux on this hardware. It was a straightforward install and has been problem-free since.

It’s nice that some resources are being directed in this area, but it’s far from a total solution.

For example, the passport-saml Node module is popular and security related and is already fielding a number of AI-assisted security vulns.

Even when they are contributed by “security experts”, they still have to be carefully vetted to confirm they are correct and not themselves malicious.

While the patches may be good, it appears to be generating more unpaid volunteer labor for the maintainers.

Thankfully there some other fund’s trying to help out maintainers of critical open source projects.

The Code Rabbit link is about software in general, not the Linux kernel in particular. In many ways the Linux kernel is an outlier among software projects. When it comes to LLMs, I don’t expect devs will be using lower standards for code reviews in quality, while some other teams definitely are doing light “LGTM” reviews of AI code.

The second link expresses a lot of concerns about plagiarism by AI. Certainly related care needs to taken for contributions to the Linux kernel. As far as I could tell, no specific cases of plagiarized code in the kernel were cited.

M1 Mac Mini is quiet, fast, low power consumption and reasonably-priced used.

The log volume is dependent on which services are running and how they are tuned.

Gtklock.

I have a UPS that allows the server to survive an apocalypse of 15 minutes or less.

Store the secrets on a Yubikey. They are unstealable then.

Yubico has their own GUI app or you can wrappers for their CLI tool to use something like dmenu, rofi or Fuzzel to pick one.

If you run for office to be different from all the rest and win, do you immediately become corrupted upon election?

The marketing mixes metaphors, talking about gardening, growing, curating… all part of sustainable process that includes plants dying.

It also uses words like forever and permanent.

Having content live forever is at odds with metaphors of the natural world, where things naturally die.

How does it handle helm features that are not valid compose features? Silent failure or loud warning?

Or you could change the preference to enable the feature again.

To explain how HAproxy and competing tools solve this:

Two servers are prepared to be the single reverse proxy, but one is active. They constantly communicate with a “heartbeat”. When the active one fails to send a heartbeat, the secondary executes the steps to become the active primary. When the primary’s heart starts beating again, it becomes active again.

So there can be a few seconds of downtime, but the failover is automatic.

Yes, especially if people use the “latest” tag, trusting whatever the container might be updated to do in the future.

I am using Navidrome and if it has significant bugs, I haven’t run into them yet.

That’s not what the FAQ says, rather it says Flatpaks are often sandboxed but not fully containerized. Containers don’t need to have a performance penalty because they run on the same kernel as the host. Container tech applies a chroot, disables some capabilities within the container and that’s about it. They are in contrast to virtual machines that need to boot an entire additional OS before doing anything.

Part of the app resides on the GitHub infrastructure, where GitHub stores, processes and displays results. So their costs are not zero.

But GitHub could take a “tax the rich” approach to pricing by charging enterprise customers more for self-hostingand leave it free for others.

A lot of open source is funded like that— most funding for a project comes from a very few companies and everything else uses it free or for very low donations or costs.

My job involves maintaining Linux servers so there are no problems with Linux as my desktop.

Currently Arch Linux as the desktop OS.