ruffsl

nix-ld has been really helpful. I wish there were some automated tools where you could feed at the binary, or a directory of binaries, and it would just return all of the nix package names you should add include with nix-ld.

Also if there were some additional flags to filter out redundant packages because of overlapping recursive dependencies or suggest a decent scope of meta package to start with for desktop environments, that'd be handy.

I think the other 99% would appreciate having some deterministic config, and not necessarily even using Nix either.

I'm kind of perplexed as to why no other distro hasn't already supported something similar. Instead of necessitating file system level disk snapshots, if the OS is already fully aware of what packages the user has installed, chron jobs and systemd services they've scheduled, desktop environment settings and XDG dot files, any Debian or Fedora based distro could already export something like a archive tarball that encapsulates 99% of your system, that could still probably fit on a floppy disk. Users could backup that file up regularly with their other photos and documents, and simplify system restoration if ever they get their laptops stolen or their hard drive crashes.

I think Apple and Android ecosystems already support this level of system restoration natively, and I think it'd be cool if Linux desktops in general could implement the same user ergonomics.

Let's say you're building a gaming desktop, and after a day of experimentation with steam, wine, and mods, you finally have everything running smoothly except for HDR and VRR. While you still remember all your changes, you commit your setup commands to a puppet or chef config file. Later you use puppet to clone your setup onto your laptop, only to realize installing gamescope and some other random packages were the source of VRR issues, as your DE also works fine with HDR natively. So you removed them from the package list in the puppet file, but then have to express some complex logic to opportunistically remove the set of conflicting packages if already, so that you don't have to manually fix every machine you apply your puppet script too. Rinse and repeat for every other small paper cut.

I find a declarative DSL easier to work with and manage system state than a sequence of instructions from arbitrary initial conditions, as removing a package or module in Nix config effectively reverts it from your system, making experimentation much simpler and without unforeseen side effects. I don't even use Nix to manage my home or dot files yet, as simply having a deterministic system install to build on top of has been helpful enough.

How does distrobox implement display forwarding? Does it support Wayland, or is it using bind mounts for xauth and X11 unix sockets?

With approach does it use for hardware acceleration? Does it abstract over Open Container Initiative's plugin system, e.g. Nvidia container tool kit or AMD's equivalent?

Is it inconvenient if any of your applications use shared memory, like many middleware transports used for robotics or machine learning software development?

I'm more familiar with plain docker and dev containers, but am interested in learning more about distrobox (and toolbox?) as another escape hatch while working with NixOS.

Oh, neat! Is this the project you're referring to?

• https://universal-blue.org/

Looks like Bazzite is listed as an example derivative image. I've heard good things about that OS from newer Linux users' perspectives. But is ublue something an individual user could personally customize, or more like something a development team or community project would build up from?

The landing page referencing layers and the Open Container Initiative, so is this more like a bootable container using overlay file system drivers?

One attraction I appreciate with Nix is the ability to overlay or overload default software options from base packages, without having to repeat/redefine everything else upstream, e.g. enabling Nvidia support for btop to visualize GPU utilization via a simple cuda flag. Replicating lazy-level-evaluation with something buildkit ARGs would be hectic, so do they have their own Dockerfile/Containerfile DSL?

It's a steep learning curve, but because much of the community publishes their personal configs, I find it a lot simpler to browse public code repos with complete declarative examples to achieve a desired setup than it is to follow meandering tutorials that subtly gloss over steps or omit prerequisite assumptions and initial conditions.

There are also plenty of outcroppings and plateaus buttressing the learning cliff that one can comfortably camp at. Once you've got a working MVP to boot and play from, you can experiment and explore at your own pace, and just reach for escape hatches like dev containers, flatpacks or appomages when you don't feel like the juice is worth the squeeze just yet.

However, you then don't have to mentally remember every change you made when you eventually migrate to a new machine or replicate your setup across your laptop and desktop while keeping them synchronized. It takes me a few hours to setup and verify that everything is how I need on a normal distro, though that may be a byproduct of my system requirements. Re-patching and packaging kernel modules on Debian for odd hardware is not fun, nor is manually fixing udev and firewall rules for the same projects again and again.

You inspect the /proc file tree or ps utility command:

• https://www.baeldung.com/linux/process-environment-variables

Not really confident, but is the LSP running from a separate child process? Is that child process inheriting all of the anticipated environment variables from the shell that launched Neovim?

I've been using TTS systems for decades with accessibility use cases, so other than quality audio books that necessitate a skilled performing narrator, I no longer mind.

In fact, I prefer legacy Bayesian phonetic models over the newer convolutional and recurrent neural networks, as their hard consonants and robotic consistency in pronunciations and intonation are much easier to listen and discern at higher words per minute, like at 3x or 4x natural speech rates for everyday blind reading, as compared to modern mumbling/slurring of syllables or artificial stridor and other breathy sounds.

I recall the author saying they're not a native English speaker, and preferring international intelligibility over regional voice-over, plus the production convenience while traveling and script writing without a quiet audio recording environment. See around 7 min mark:

• The most common question on my channel - Core Dumped
  • https://youtube.com/watch?v=FlOVA8NLGDQ

From the video notes, this alternative to nix-serve looks promising:

• https://github.com/nix-community/harmonia