emulio

btw, llama-swap provides a nice UI for monitoring performance and logs, and even the ability to stop an infinite session that consumes GPU resources (sometimes that happens).

Does the llama.cpp UI provide the same? If not, it is too early to say that llama-swap is “superseded/no longer needed.”

A package (like a .deb) is a static artifact. It can be hashed, mirrored, and GPG-signed. Package managers usually verify that signature before any pre/post-install scripts. A "curl <some_url> | bash" pipe is a dynamic stream; the server can perform targeted attacks: sending a clean script to 99% of users and a malicious payload only to a specific IP address or User-Agent. This allows for targeted attacks that are invisible to the rest of the community.

Yes, running third-party code is always a leap of faith, but why choose a delivery method that removes the possibility of verification and opens the door to targeted injections? Convenience shouldn't be an excuse to ignore basic security hygiene.

The installation method they officially propagate is dangerous. curl -fsSL https://mimo.xiaomi.com/install | bash

This is usually a PoC (Proof of concept) way to install something on a temporary container or temporary VM, but not for production use during daily desktop operation.

I was hoping their documentation would provide better installation instructions. But strangely, only for Windows do they recommend "npm install -g @mimo-ai/cli," which is a much better approach to managing installed packages.

For Mac/Linux, they have the strange recommendation to use the dangerous "curl <some_url> | bash." Quote:

> (for the best experience, Mac users are strongly encouraged to use iTerm or the VSCode Terminal) > curl -fsSL https://mimo.xiaomi.com/install | bash

:(

Why is OpenCode awful?

This appears to be an LXC-style alternative for macOS; however, unlike native LXC on Linux, this tool relies on VMs. While Docker and Podman also utilize a VM on macOS, they offer the advantage of the Docker Compose format. In my view, the ability to use YAML for declarative configuration is the most critical feature for any container tool. I have nothing against CLI tools in general, but I prefer avoiding repetitive manual commands that could be easily automated via Docker Compose or Kubernetes manifests.

I hope Opera will be resurrected on the old Presto engine. It was amazingly fast. Back then, Chromium and Firefox were much slower.

I do. I use it, alongside other browsers, because I prefer different browsers for different types of tasks.

Honestly, I'm reacting a bit against the "YOLO" install culture common on Windows and macOS – just double-clicking and hoping for the best. I specifically use CachyOS, an Arch-based Linux distribution, because it emphasizes a more deliberate, package-managed approach. I prefer relying on the maintainers' work and pre-defined steps within packages whenever possible. It allows me to understand what is being installed and how it's being configured, rather than an all-in-one script potentially making changes I didn't anticipate.

Not for Linux. I am using Linux on my desktop.

That's a nice idea, but I'm hesitant to use automatic installation scripts like this, even if I review them carefully. I prefer manual steps – downloading the file, placing it in the correct directory. Also, I use custom profile directories for my web browsers, so this script wouldn't apply to my setup.

I wish to use Graphene OS, but I can't force myself to buy a Pixel Phone, I don't like the design.

> it was too complex to maintain and Microsoft decided to take the easy road.

This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft.

This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that