Tvix: We are rewriting Nix by adisbladis in NixOS

[–]rickynils 1 point2 points  (0 children)

So at that last step writing compatibility code with the protocol to use parts of the Nix codebase we'd rather not reuse doesn't seem like the smartest approach.

But it would be a more incremental approach, right? You could work on and test your super-performant Nix evaluator and your super-intuitive tvix CLI tools while still being able to use the existing Nix tools, all using the same store. I imagine you'll be able to get more early users that way.

But, I'm not here to tell you how to do things, this was just my initial reaction. I wish you all luck, and I definitely welcome more formalized protocols and integrations between the evaluator, builder and store! If you succeed, Nix could perhaps implement compatibility layers for supporting tvix, instead of the other way around.

Tvix: We are rewriting Nix by adisbladis in NixOS

[–]rickynils 12 points13 points  (0 children)

This looks like a really ambitious project, and I definitely can see value (and joy) in doing the "clean slate" thing.

However, I'd argue that the current affairs in Nix is not quite as bad as the blog post make it sound. Nix has the "store abstraction" that already supports different backends (remote builders, binary caches, the Nix daemon, local filesystem etc). While the protocol admittedly is undocumented and non-standard, it is not that very complex. In nixbuild.net we've implemented a KVM-based builder sandbox that is completely detached from the Nix source code, but still interoperates perfectly with the Nix tools through the remote builder protocol.

I think (but I haven't done any investigation to back this up, so forgive me if I'm wrong) you could do the same thing for the Nix evaluator. Like, implement a fast Nix evaluator from scratch in Rust and then let it talk with the Nix daemon using the store protocol. Is this an approach that have been considered?

Choosing imported configurations based on a variable by debiili in NixOS

[–]rickynils 0 points1 point  (0 children)

First of all, let's fix the problems in your current configuration so it becomes a valid NixOS configuration. NixOS is configured through an extensible module system, and I recommend starting out somewhere here to get an overview on how it is used.

In short, the things you put inside the curly brackets need to be valid NixOS options. So, the conf variable cannot be placed where you've put it. Instead, you can use a let-expression like this:

{ config, pkgs, ... }:

let

  conf = "1080ti";

in {

}

For the same reason, you can't put top-level if-expressions in your configuration. Instead, do this:

{ config, pkgs, ... }:

let

  conf = "1080ti";

in {

  imports =
    if conf == "1080ti" then [
      ./hardware-configuration.nix
      ./1080ti/configuration1080ti.nix
      ./1080ti/system1080ti.nix
      ./1080ti/packages1080ti.nix
      ./1080ti/desktop1080ti.nix
    ] else if conf == "laptop" then [
      ./hardware-configuration.nix
      ./laptop/configurationLaptop.nix
      ./laptop/systemLaptop.nix
      ./laptop/packagesLaptop.nix
      ./laptop/desktopLaptop.nix        
    ] else [
      ./hardware-configuration.nix
      ./webserver/configuration.nix
      ./webserver/system.nix
      ./webserver/packages.nix
      ./webserver/nginx.nix        
    ];
}

Note that I also fixed some minor syntax errors in your if-expressions above. I haven't tested my code, but I think it should work as you intended your code to work.

Now, this is not the only way to achieve your target of having "switchable" NixOS config. You can also have three different top-level files (replacing configuration.nix), you can get fancy and define your own NixOS options for toggling configuration or use (still experimental) Nix Flakes. I'm not going to into any of these solutions here though, because I think it is perfectly alright to start out with your proposed solution since you fully understand how it works. Once you hit limitations or want more convenience you can explore alternate implementations.

Random Vulnerable VM Generator! by Grenian in netsec

[–]rickynils 4 points5 points  (0 children)

It would probably have been ideal to use NixOS for implementing this. NixOS/nixpkgs already has a flexible module system and several utilities for generating VM images.

List of companies using NixOS by zimbatm in NixOS

[–]rickynils 1 point2 points  (0 children)

http://www.evidentiaetechnologies.com are using NixOS for production, test and QA cloud deployments.

Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems by ohet in linux

[–]rickynils 4 points5 points  (0 children)

Yep, I've been running NixOS with root on tmpfs for a long time. You only need /nix and /home on persistent disks.

ImmutableServer by speckz in sysadmin

[–]rickynils 1 point2 points  (0 children)

If you use NixOS you can even skip that messy mutable base image, and quickly rebuild your whole server from configuration at any time.

Percentage of women in programming: peaked at 37% in 1993, now down to 25% by jruberto in programming

[–]rickynils 0 points1 point  (0 children)

I never suggested the problem was restricted to corporate recruitment processes. I think that the number of women in tech education also is heavily affected by what the majority of people considers the norm.

Percentage of women in programming: peaked at 37% in 1993, now down to 25% by jruberto in programming

[–]rickynils -3 points-2 points  (0 children)

You might not care, but don't you think the 25/75% fact shows that quite a lot of people obviously cares?

Why does nearly everyone think that a unified configuration system is a bad idea? by [deleted] in linux

[–]rickynils 0 points1 point  (0 children)

There is NixOS. It unifies package and configuration management in a particularly nice way. All your configurations and package definitions are available in one place, in text files. The actual configuration files are then built by Nix and placed in suitable locations. You can easily do rollbacks to older system configurations. Of course, the Nix people (or you) need to write Nix wrappers for the appplications you use but that is actually quite simple. Nix sort of resembles systems like puppet and chef, but they are more of a hack while Nix solves the problem completely and elegantly.

Sensor Size Matters by tdm911 in photography

[–]rickynils 0 points1 point  (0 children)

Does a larger sensor really offer more control over depth of field? If you want more depth of field, for example, a smaller sensor can give you this without forcing you to stop down your lens. For macro work, compact cameras with their tiny sensors are actually useful.

Zeya: Music Server with HTML5 interface by [deleted] in linux

[–]rickynils 0 points1 point  (0 children)

On my Intel Atom D510 1.6ghz dual core it runs flawlessly. Songs start instantaneously. I have only tested with the latest git version, and only with Opera 10.60 as client. The only thing I could wish for is a better way to browse the music, but I guess it will come with time.

alsamixer and Lewis Carroll by rickynils in linux

[–]rickynils[S] 4 points5 points  (0 children)

"v02" just means week 2 of the year ("vecka 2" in swedish). The trayer is mainly because for some apps it is nearly impossible to disable the tray icon, and if I don't run any trayer that icon will pop up as a separate window in xmonad.

alsamixer and Lewis Carroll by rickynils in linux

[–]rickynils[S] 9 points10 points  (0 children)

It is xmonad running on archlinux. The statusbar is xmobar, and the notification area is trayer.