-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
vanitygen-plusplus
A vanity address generator for BTC, ETH, LTC, TRX and 100+ more crypto currencies.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
terraform-provider-libvirt
Terraform provider to provision infrastructure with Linux's KVM using libvirt
-
Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
Not true: there are many tools that allows directly running any binary, like nix-autobahn [1].
[1]: https://github.com/Lassulus/nix-autobahn
Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
Plugging my own thing here, but I have been experimenting with a Nix configuration for gaming only. My configuration is here (for Nvidia, which does not work without tinkering as AMD does) : https://github.com/jhvst/nix-config/blob/main/nvidia.nix
First, this is a whole system specification. This means that executing this on Nix will build you a whole OS image. You can build the image if you have Nix by running the first line on file. You can also use Docker with the instruction on my README: https://github.com/jhvst/nix-config
Back to elaborating on the Nix file from the gaming perspective. First, we have the overlays. These are like patches to the packages, and really useful for gaming because it allows building important packages like mesa from the source tip. This is particularly useful when new games or GPUs are released. Same thing for wayland: Nvidia and its proprietary drivers need some patching, but it's possible to get wayland (and sway) to work this way.
Then, I have taken the reproducibility of Nix to a next step in my opinion, and made the system stateless. This means that it runs from the RAM. It is easy to create installation media like kernel, initrd, and rootfs because you have all the steps to create the distribution. This means that here, Nix works as a meta-distro like Gentoo, on top of which you develop your own. Running from the RAM means that theoretically, if you have a working config, and two people with different hardware runs it, then they should have the same experience. If you look at ProtonDB, you often find that some people claim that game X works on their machine with drivers and mesa of Y and Z, but there is no way to copy their configurations because it's certain that the user has made some stateful changes which they have forgotten hence left undocumented, which is the reason it works for them. If everyone would be using Nix, you could reproduce their system and possibly fix your own, but this is not tractable with most OSs.
If you like to test my changes, you can read more about my approach here: https://github.com/NixOS/nixpkgs/pull/203750
For testing I distribute Nvidia as documented here: https://github.com/jhvst/jhvst.github.io/blob/main/ramdisk.m...
However, I have developed it bit further: if you manage to get into an iPXE shell, you can write `boot -a http://boot.ponkila.com/menu.ipxe`, then select the second option which is Nvidia (proprietary drivers), and with some waiting you will get into a shell prompt to which you can write `sway --unsupported-gpu`, which will launch sway. Cmd+Enter opens a prompt to which you can write `steam`, which will open Steam. Then, you have to mount some drive on another shell with `mount`, and add this as a Steam library via Steam's UI. Then you can play games. I use this on AMD and I have been very happy.
I run NixOS, but I'm relatively new to Nix. A couple weeks ago I was trying to get an old vanity key generator to build because it wasn't on nixpkgs (vanitygen++) and on a lark I decided to write my own derivation using some examples of similar C++ packages I found and figuring out what nix packages it needed to build. So I did, and the maintainer accepted the PR: https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3... Note that I am not a C++ developer and only know the basics about how to get C/C++ things to build.
So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix.
I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach.
And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it.
Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition.
NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
I appreciate your comment here, and the parent comment.
I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step.
My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting.
I appreciate the utility of OPNSense's web GUI when configuring and troubleshooting my router config. It would be awesome if something like that could be integrated with NixOS. Additionally, something like nsh[1] to provide a traditional router/switch style CLI would be a dream come true.
[0] https://opnsense.org/
[1] https://www.nmedia.net/nsh/
I appreciate your comment here, and the parent comment.
I've been using OPNSense[0] as my router for the past several months. So far, I am quite happy with it, but I've also thought that NixOS would be the next step.
My OPNSense router has 30+ VLANs and many layered firewall rules (my take on "zEr0 tRuSt") and so the task of converting it all to NixOS seems a little daunting.
I appreciate the utility of OPNSense's web GUI when configuring and troubleshooting my router config. It would be awesome if something like that could be integrated with NixOS. Additionally, something like nsh[1] to provide a traditional router/switch style CLI would be a dream come true.
[0] https://opnsense.org/
[1] https://www.nmedia.net/nsh/
Never mind traditional package managers... you plug it in right, you can run Nix on Silverblue!
https://gitlab.com/ahayzen/silverblue-nix
NixOS people will prefer NixOS, but Silverblue seems like a nice complement to Nix if you need an FHS base system and want to retain some Nix-ish features like rollbacks and atomic upgrades.
Well they are - but there are a couple of things blocking it from becoming the default. I think the main thing is this PR: https://github.com/NixOS/nix/pull/6530 - Eelco Dolstra gave a talk on this recently as well if you wanna know more: https://www.youtube.com/watch?v=JE-vLFMTXxM
Another thing that comes to mind is the ability to parametrize flakes so that they can be configured from the CLI: https://github.com/NixOS/nix/pull/6583
If you are looking for a simple interface that is an alternative to asdf, but uses Nix under the hood, you could check out Devbox (https://github.com/jetpack-io/devbox). Our goal is to make spinning up per-project dev environments easy and approachable, without having to write a full nix.flake.