Yeah, would definitely prefer using a package manager from a maintained repository like nix over raw dogging remote shell scripts. E.g. from nixpkg

nix-env -iA secretspec -f https://github.com/NixOS/nixpkgs/tarball/nixpkgs-unstable

I top linked the most recently published video mostly for the introductory breakdown in ternary logic equivalence, but the interview with the ternary researcher, Dr Bos, also linked in the description above includes a number of corrections and accurate description of the subject.

Yeah, definitely not a lost art or anything, as physical ternary signals already have applications in communication like high data rate interfaces. Still, would be interesting to see ternary expand into logic domains with emerging developments in TCMOS research.

Appreciate the detailed context, and thank you for your work!

Does anyone know of an Android app to install an additional 3rd party TTS engine that can then be configured to point to a custom Open-AI/Fast-API endpoint for self hosting higher quality voices that are not easily run/fit on mobile hardware?

If you just want to quickly create a local python develop environment on the side using Python module metadata, installing uv from nixpkgs, and enabling nix-ld to run pre-compiled binaries from PyPI keeps things simple, and replicating the same virtual python environment workflow you to have on any other distribution:

https://discourse.nixos.org/t/i-want-understanding-nix-packages-and-flake-basics/67365/3

If you wanted to package a python module for nix or for proper distribution via nixpkgs, you’d want to add a nix derivation file that encapsulates all the inputs, i.e. software building materials (SBOM). There are existing nix library functions that can automate most of the packaging, not unlike Debian macros:

https://wiki.nixos.org/wiki/Python

The second approach is more rigorous, and combined with something like flakes for pinning the exact hash for all inputs via lock file ensures reproducibility, like when sharing with other nix users. While as the first approach is more subject to your current system, i.e. linking to whatever system wide libraries are presently installed, but it’s less upfront effort to reuse existing python-package-managers than to nixify everything.

I’ll preface that NixOS may not be for everyone, as deviating from a conventional hierarchical file system is a radical departure from conventional distributions; but for those that want precise control over their system environment, it has a good deal of appeal.

For example, I appreciate being able to use the latest bleeding release of a number of tools while sticking with older trusted versions of other utilities, but if both relied upon different versions of similar dependencies, such package conflicts can be troublesome to resolve, as few Linux package managers gracefully deal with multi version installs.

For NixOS using the nix store, installing leaf packages that traditionally conflict is trivial, and as a user, I can spend less time managing every transitive dependency in order to use the software I want. Not having to wait for a disjointed ecosystem of packages to synchronize around dependencies, or resorting to compromise in package version selection is very liberating.

• https://nixos.org/guides/how-nix-works/

The functional language and documentation for nix itself is a bit quirky, as I wish it was stronger typed, but being able to declaratively express and version control my setup across workstations has been a time saver; installing/configuring something once and then have-done with it.

I think it stands for Managed Service Providers.

I would have liked the PyCon25 talk directly, but I don’t think the recordings have been published yet:

https://slides.com/bittner/pycon25-nixos-for-python-developers#/2/4

Hopefully the presenter discusses more on their later slides in using python on NixOS and working around python packaging’s use of dynamic linking.

I’m still using an old UC Gateway, doubt my homelab will outgrow it.

I hope this rust library can make its way back into Moonlight and Sunshine projects.

Looks like they introduce the use Traefik with NixOS here:

• https://youtube.com/watch?v=_e6K0dTTjwI

How does Traefik compare to a reverse proxy like Caddy?

I’m waiting on support for inserting PDF figures, the most common format my tools export.

• https://github.com/typst/typst/issues/145

For the faint of heart, such vicarious pain may require theatrical intermission(s).

Yeah, any details published so far have been rather vague. I like the prospect of writing my backend UI logic in a memory safe language, but that falls short of benefiting from doing so end to end.

Supposedly Qt would be in a decent position to use their own static analysis and testing frameworks for hardening such bridge interfaces, but using a memory safe system programming language for everything would be ideal. Are there any Rust based UI projects that are looking at ISO certification to ease integration as a Software of Unknown Pedigree?

Have you had any luck with projectors for coding? I’ve only ever used them for large mob-programming sessions, like during hackathons. I feel like the low/narrow contrast of projectors makes it hard to use for dark mode, not to mention the space real estate requirements. :P

Still kind of sad that the transflective display technology demoed in the $100 laptop project from a decade or so ago never took off.

https://youtu.be/CGRtyxEpoGg?si=50jL24kRA22-X_Bo&t=1470

Personally, I’ve been happy using an LG TV for a single monitor setup. I have had to switch to KDE Plasma v6 for better font rendering given its unusual OLED pixel layout, as well as for native HDR support. But it’s been nice to have a large physical font while still at default DPI. Although, I wouldn’t’t mind upgrading to 8K later when they get affordable, as the smallest 4K TVs at 42" happen to push the physical DPI down towards that of just 1440p panel.

https://programming.dev/comment/7921093

Tagging an image is simply associating a string value to an image pushed to a container registry, as a human readable identifier. Unlike an image ID or image digest sha, an image tag is only loosely associated, and can be remapped later to another image in the same registry repo, e.g latest. Untagging is simply removing the tag from the registry, but not necessarily the associated image itself.

Wow, the COPY directive got a lot more powerful. I’ve been waiting for the --parent flag for years, while the --exclude argument is also a nice touch. Didn’t know of the /./ pivot point before, but that’s handy.

Before this, I’ve just been using a intermediary leaf stage within a multi-stage build process to copy the build context and filter the dependency lock files of the entire super project into a matching parent structure that I could then deterministically copy from.

Ah man, I’m with a project that already uses a poly repo setup and am starting an integration repo using submodules to coordinate the Dev environment and unify with CI/CD. Sub modules have been great for introspection and and versioning, rather than relying on some opaque configuration file to check out all the different poly repos at build time. I can click the the sub module links on GitHub and redirect right to the reference commit, while many IDEs can also already associate the respective git tag for each sub module when opening from the super project.

I was kind of bummed to hear that working trees didn’t have full support with some modules. I haven’t used working trees with this super project yet, but what did you find about its incompatibility with some modules? Are there certain porcelain commands just not supported, or certain behaviors don’t work as expected? Have you tried the global git config to enable recursive over sub modules by default?