Skip Navigation

Posts
310
Comments
220
Joined
3 yr. ago

I'm a robotics researcher. My interests include cybersecurity, repeatable & reproducible research, as well as open source robotics and rust programing.

  • Not great for an uncontrolled user experience.

    • Interesting. What linux distros are optimal for that use case?
      • Specifically what properties of those distros make them ideal?
  • 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?

  • Yeah, I didn't hear much about the project over this summer.

    Switched from Gnome to Plasma a little after Unity expired, as I couldn't keep up with the churn of Gnome plugins, and hoping Cosmic could balance customizability with stability. KDE has been great with adding HDR support and Wayland features, though as a Rust lang fan, I'm still curious what Cosmic will bring to the table in terms of plugin API and tooling.

  • Some poignant questions for these new platform requirements:

    • How do you anticipate this being used against journalists and advocacy groups?
    • What research and statistical quantification will be done to evaluate the amount of harm these restrictions can inflict?
    • What precautions or safeguards will users have against malicious state actors or capitulating corporations?
    • How can developers protect themselves from liable damages due to service interruptions caused by third party verification?
    • Do you foresee legal restrictions in rollout due to national security concerns from differing nation states?
  • I've really enjoyed using Kokoro for generating audiobooks:

    Be sure to first try using this convenient API wrapper:

    Note that not all the modelled voices in Kokoro-82M are of equal quality, given disparities in limited training data from reference speakers. However, what's cool is that you can prescribe polynomial weights to multiple voices tags, enabling you to synthesize different variants weighted more heavily from the highest quality voices.

    One current limitation for Kokoro is that there's no way to prescribe emotion or intonation procedurally using markup tags like SSML in the source text, unlike other models like Orpheus. But Orpheus sometimes generate weird hallucinations like repeating sentences, injecting new phrases, appending radio silence or filter words, and generally increasing the tempo of words per minute as a sentence progresses. Still, this may be of interest if you want to add emotion like fear or urgency to your generated dispatches, and manage to tune the input temperature you want for the model.

    However, Kokoro is a lot more compute efficient and audibly consistent, requiring less scrutiny or manual supervision. The author behind Kokoro now also looks to be working towards an emotional variant as well:


    Reference project I've been following for audiobook generation:

  • Wow, that sounds damning. Where can one read more on this?

  • This is the flake config I started from, but am now refactoring for multi-host support:

    Simple and documented config templates to help you get started with NixOS + home-manager + flakes. All the boilerplate you need!

    I first learned of NixOS through this project, but decided on writing my own config for starters.Still, it has been a neat reference as an advance example:

    My main NixOS configuration. Features include a polished Hyprland environment. A fully configured NeoVIM environment, QMK support. A Keyboard shortcut menu pop-down available in the top bar and so much more!


    BTW, could you breakdown your hardware.nix configs?They look a lot different from my auto generated one from the ISO install, particularly for fileSystems:

  • Ah, that's a shame. Thanks for the context though.

    I did feel a little bit of that slight dismissal or elitism from the thread I linked above about the graphical installer ISO. Although I think the relative surge of new users after graphical ISO's implementation did end up changing some minds on the merit of its continual development.

    It seems like some tools just never fully realize their potential market demand until they're finally implemented and consequently adopted. Quite the catch 22.

    I also wonder if it's a bit of a motivational aspect for individual contributors, as in demand with mostly originate from novice users who've yet to master the Nix language, yet by the time one's gained enough experience to contribute to Snowflake OS, you've kind of grown out of outgrow the need for it. That kind of reflects my personal interests around graphical programming, as I became more familiar with various languages, my inkling for a graphical representation of control flow gradually waned.

    Still, I think lowering the barrier to adoption is in the long run best serves the community and in sustaining new contributors. Sort of like the conventional Greek proverb:

    A society grows great when old men plant trees whose shade they know they shall never sit in.


    Nix can create attribute sets from JSON, so there isn't a need to generate nix code.

    Is there a good way of mixing and mashing JSON attribute sets with conventional nix config files? Perhaps relegating some config to machine-generated JSON, and some hand crafted configs?

  • I'm using flakes as well, so that abomination sounds terrifying...

  • As a prior proponent of graphical programming interfaces, I've been thinking there'd be a good use case for a GUI based control panel for NixOS, something that could transcompile standard user selected options down to a nix config that could be abstract of the way from most users, like any sort of game save file.

    Given all options and packages in nixpkgs are already machine readable and indexed, supplying a GUI based tool to procedurally generate nix codes doesn't at first seem initially daunting, but given the past discussions around this idea perhaps proves it to be on the contrary:

    Although SnowflakeOS in particular looks promising:

    SnowflakeOS Simple, Immutable, Reproducible SnowflakeOS is a NixOS based Linux distribution focused on beginner friendliness and ease of use.

    https://snowflakeos.org/

  • Yep, with a Turing-complete DSL, there's never just one way to do something in Nix. I find the interaction between modules and overlays particularly quirky, and tricky to replicate from public configs that make advance uses of both.

    That said, I do appreciate being able to git blame into public configs, as most will include insightful commit messages or references to ticketed issues that include more discussion with informed community members you can follow up with. Being able to peek at how others fixed something before and after helps give context, and with the commits being timestamped, it also helps gauge current relevancy or chronological order to correlate with upstream changelogs.

    Are you using flakes with lock files, or nixpins to fix down the hashes of your nix channel inputs? I like fixating my machines to the same exact inputs so that my desktop can serve as a warm local cache when upgrading my laptop.

  • Thank you for the detailed reply, much appreciated!

    Any rough edges you've encountered yet? Like using USB peripherals, or networking shenanigans? I'm assuming it's using the host network driver by default, and maybe bind mounting /dev/bus/usb for USB pass through?

    Think I'll really dig into distrobox today.

  • 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.