ruffsl

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?

I'm not the original author, even with the YouTube title being as is, but what do you mean? Perhaps relying that the desired services exist as nix packages, or that nix packages have desired defaults or exposes desired config parameters?

There are two other nix media server config projects I can think of, but I think this approach mostly facilitates the install, but not the entire initial config setup, given that a lot of the stack's internal state is captured in databases rather than text config files. So simplifying the backup and restoration of such databases seems the next best thing to persist your stack configs with nix.

• https://github.com/rasmus-kirk/nixarr/issues/3
• https://github.com/notthebee/nix-config/blob/892878506094fa2189aac0ae4e9d3aea3d0a2fbc/homelab/services/backup/default.nix#L58

On top of that, it'd be nice for the Bluetooth spec to roll out a higher bitrate version of HFP, as it's common 16 kHz monaural configuration is awful when listening to multimedia while on video calls, like for remote watch parties or just listening to music or playing video games while hanging out on discord. I ended up just buying a USB to TRRS adapter with pass through Power Delivery in order to use my Android device with proper AV quality.

• https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Hands-Free_Profile_(HFP)

Any particular reason that those OEMs made that decision when releasing those boxes? Was that range blacklisted in firmware because of the legacy specification? I thought the spec just forebode range's public allocation, but not necessarily its internal use.

Could you explain a little more on that? Just curious.

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

I hope compatibility with git submodules gets ironed out soon. I'd really like to have multiple branches of a superproject checked out at once to make it simpler to compare source trees and file structures.

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?