trevor

RustDesk is the closest alternative, and I think it does a pretty good job.

Lol. It’s a close second, but at least Apple isn’t blatantly hostile toward users in the same way that Microsoft is.

Obligatory people getting mad at you for people suggesting you stop using software that is openly hostile toward you response.

Using containers on Linux has basically no performance loss compared to running on the host. They share a kernel and nothing needs to be virtualized (unlike containers on macOS and Windows), so anything you run in a container is basically the same performance as running it on the host.

I still agree though: using Nix is better than using Distrobox for many other reasons.

Nix has more packages , by far. Nix also automatically handles the dependent libraries for each package, which is something you can’t do with brew on immutable systems. This means that Nix can install software like espanso, which wouldn’t work on uBlue derivatives otherwise.

I really wish the uBlue maintainers would have opted for Nix over brew for that reason. It’s not much more difficult to do nix profile install nixpkgs#package-name over brew install package-name. They could have even aliased it to make it easier.

This is just me being pedantic, but I keep seeing this mistake when UTM is mentioned (specifically in headlines), so I feel like I have to say something:

UTM is not an emulator. It is virtual machine software that uses an emulator (QEMU) to virtualize operating systems.

The difference: emulators emulate hardware. On which, the virtualized operating systems run.

If someone could build a preconfigured image that has Phosh and basic phone apps, I would consider using this full time.

Servo cannot come soon enough. And yet… it’s so far from being even close to ready for real usage.

Seriously. The Luddites were mostly correct about their objections to technology being used to replace humans and making exploitation more efficient, making OP’s misuse of the terms that much funnier.

Synergy doesn’t work with Wayland, sadly.

Be warned: Synergy doesn’t work with Wayland.

This is all I want to know. If yes, I’ll pass.

Yeah. I hope as Helix grows more popular, our problems will solve themselves in both directions: where Helix can address them directly, and people start hacking Neovim to work more like it.

Out of curiosity: what issues with the LSP are you having and what distro do you run? I’ve found that most of my issues could be resolved by running Helix’s health checks and making sure that the binaries needed by the LSP are available in $PATH.

Unfortunately, I did start having issues with Go where it seems like the LSP might be crashing and I’ve yet to resolve that one for myself.

As someone that never really clicked with Vim, but has been enjoying Helix, I’ve been looking for the opposite: something that makes Neovim follow the selection-action paradigm, along with all of the Helix keybindings.

While I generally agree with your skeptical attitude toward this, I think the fact that they were targeting Apple’s Metal graphics API to built the most performant possible IDE makes sense. You can’t just snap your fingers and have a Linux graphical stack start working with your software.

I think the reason they targeted macOS first is probably because many of the dev team uses Macs.

As a Linux user, I’ll happily wait for software like this to get ported to native Linux APIs so we get performant text editors instead of more Electron crap.

Hello, fellow pirates.

Don’t mind me and my new account. Please run this binary on your computer 🤡

Thank you!

How do you get plain-text logs instead of the garbage binary format that journalctl forces on you?

Part of the problem also has to do with corporate-backed distros. Fully community-driven distros don’t suffer from that nearly as much, if at all.

I like Fedora, but stuff like that makes me worry about how it’s going to be as time goes on.

Here’s what I do in my docker images:

mkdir -p /lib-your-executable
ldd ./your-executable | tr -s '[:blank:]' '\n' | grep '^/' | xargs -I % cp % /lib-your-executable

Essentially, it’s the same thing that you’re doing, just automating getting the dependencies, and then copying everything in the lib-your-executable dir to your LD_LIBRARY_PATH. I don’t know of a better way, other than statically-linking the binaries.

EDIT: fix typo in commands.