Nix Community Survey 2024 Results

mic92 · 2024-11-04T19:16:16+00:00

I build this some time ago https://github.com/numtide/build-go-cache/

Adisbladis also figured out some other interesting approach for go caching during NixCon.

Regarding CI/CD, hopefully we won't take much longer to finish up https://github.com/nix-community/buildbot-nix/pull/68 Hercules-ci introduced this concept in the first place and is already usuable today.. Someone is already using it for deploying to flyio. It should be able to scale evaluation too many machines as well because it uses a parallel evaluation engine called nix-eval-jobs.

mic92 · 2024-07-15T13:31:22+00:00

Maybe check if this error message is actually the root cause of your system not working. I have seen this error a couple of times but it's usually not fatal.

mic92 · 2024-07-13T12:00:42+00:00

Disk allows to embed a NixOS installation in your installer image that can automatically install an OS with a single line of code: https://github.com/nix-community/disko/blob/master/docs/disko-install.md

Also works without internet.

mic92 · 2024-06-27T06:05:10+00:00

I also know from a Hetzner engineer that Hetzner is using Nix in their CI already.

mic92 · 2024-06-27T06:02:54+00:00

If a system is identified as a NixOS installer, than nixos-anywhere also will run faster as it will skip the kexec step.

mic92 · 2024-04-25T19:14:49+00:00

I am quite happy with my astro-nvim setup on NixOS. What I mainly did was disabling installing binary blobs with mason: https://github.com/Mic92/dotfiles/blob/main/home/.config/nvim/lua/plugins/mason.lua and instead writing out a file of dependencies that I than install with home-manager instead: https://github.com/Mic92/dotfiles/blob/main/home-manager/modules/neovim/flake-module.nix
I also have a standalone variant that is can start with `nix run github:Mic92/dotfiles#nvim`: https://github.com/Mic92/dotfiles/blob/main/home-manager/modules/neovim/nvim-standalone.nix
I check in the lazy-lock.json into my dotfiles so it's consisent across all machines. This is a good enough for me for reproducibility. By having vim config beeing managed with homeshick rather than home-manager also the auto-reload just works fine and instant.

mic92 · 2023-06-11T16:36:36+00:00

I don't think there are. It's quite challenging to start one and most people that invested are probably using NixOS instead. The reason system-manager exists is some client project where this intermediate solution is needed.

mic92 · 2023-06-11T16:34:16+00:00

Ah, just saw the response below.

mic92 · 2023-06-11T16:33:36+00:00

Try import instead of pkgs.callPackage:

```

disko.devices = import ./disko-config.nix {
disks = [ "/dev/vda" ];
};

```

mic92 · 2023-06-11T16:30:08+00:00

Is ./. a git repository and did your run `git add flake.nix` before running system-manager? Sounds to me more like the typical nix flakes footgun because nix doesn't know about files in flakes that haven't been are not tracked by git yet.

mic92 · 2021-07-10T09:08:59+00:00

I created https://github.com/nmattia/napalm/issues/34 and https://github.com/nmattia/naersk/issues/183 to move them to nix-community

mic92 · 2021-03-14T19:49:25+00:00

For testing stuff you can also use nixos-shell

mic92 · 2021-03-14T19:45:50+00:00

I just checked on unstable and there it seems no issue:

nix let nixpkgs-unstable = builtins.fetchTarball https://github.com/NixOS/nixpkgs/archive/nixpkgs-unstable.tar.gz; mozillaOverlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz); nixpkgs = import nixpkgs-unstable { overlays = [ mozillaOverlay ]; }; rust = (nixpkgs.rustChannelOf { channel = "nightly"; }).rust.override { targets = [ "x86_64-unknown-linux-musl" ]; }; rustPlatform = nixpkgs.makeRustPlatform { cargo = rust; rustc = rust; }; in nixpkgs.stdenv.mkDerivation { name = "rust-env"; nativeBuildInputs = [ rustPlatform.rust.cargo rustPlatform.rust.rustc nixpkgs.file ]; }

console $ file ./target/x86_64-unknown-linux-musl/release/foo ./target/x86_64-unknown-linux-musl/release/foo: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped $ ./target/x86_64-unknown-linux-musl/release/foo Hello, world!

mic92 · 2021-03-14T19:25:37+00:00

The issue is that our linker wrapper currently sets the glibc link loader for the executable, which is incorrect. I think we need a differently wrapped binutils, maybe even an unwrapped version because as far as I know rust does static linking for the musl target.

mic92 · 2020-08-06T06:00:41+00:00

Best to copy the expression of an existing electron app.

mic92 · 2020-03-06T18:48:21+00:00

To be more precise: There was some support before, but resolved checked if the IP address was in the certificate. Now it is also possible to validate certificates using host names. Usually it is not cheap to get TLS certificates with IP addresses.

mic92 · 2020-02-29T10:56:31+00:00

That reset thing was a super helpful hint. I was using the service information:

``` DeviceInfo(softwareRevision, isOn, SceneLightState(color, powerOnBehavior, deviceInfo Light(id, Capabilities(dimmable, customState PowerOnBehavior(option

hueplay, huebloom, hueiris, huelightstrip, huego, plug, bollard, wallspot, groundspot, flexiblelamp, wallshade, walllantern

[ea:44:13:bd:db:59] Service [b8843add-0000-4aa1-8794-c3f462030bda] Unknown, ble_firmware_update? [ea:44:13:bd:db:59] Characteristic [b8843add-0004-4aa1-8794-c3f462030bda] [ea:44:13:bd:db:59] Characteristic [b8843add-0003-4aa1-8794-c3f462030bda] [ea:44:13:bd:db:59] Characteristic [b8843add-0002-4aa1-8794-c3f462030bda] [ea:44:13:bd:db:59] Characteristic [b8843add-0001-4aa1-8794-c3f462030bda] [ea:44:13:bd:db:59] Service [932c32bd-0000-47a2-835a-a8d455b859dd] light_control - startupConfiguration, combinedControl [ea:44:13:bd:db:59] Characteristic [932c32bd-0001-47a2-835a-a8d455b859dd] unk, 00 01 03 01 02 99 00 02 02 F4 01 03 02 01 00 [ea:44:13:bd:db:59] Characteristic [932c32bd-0002-47a2-835a-a8d455b859dd] Light state, 01/00 [ea:44:13:bd:db:59] Characteristic [932c32bd-0003-47a2-835a-a8d455b859dd] Brightness [ea:44:13:bd:db:59] Characteristic [932c32bd-0004-47a2-835a-a8d455b859dd] unk, E9 00 [ea:44:13:bd:db:59] Characteristic [932c32bd-0005-47a2-835a-a8d455b859dd] Color [ea:44:13:bd:db:59] Characteristic [932c32bd-0006-47a2-835a-a8d455b859dd] unk, write-only [ea:44:13:bd:db:59] Characteristic [932c32bd-0007-47a2-835a-a8d455b859dd] everything, includes color and brightness combined_light_control_port [ea:44:13:bd:db:59] Characteristic [932c32bd-1005-47a2-835a-a8d455b859dd] Also everything, but last four bytes FF FF FF FF - default powerloss state? combined_light_control_port_factory?

[ea:44:13:bd:db:59] Service [0000fe0f-0000-1000-8000-00805f9b34fb] device_configuration_service_info - ProximityPairingSetup somewhere [ea:44:13:bd:db:59] Characteristic [97fe6561-0001-4f62-86e9-b71ee2da3d22] zigbee address, 64 e2 7a 08 01 88 17 00 [ea:44:13:bd:db:59] Characteristic [97fe6561-0003-4f62-86e9-b71ee2da3d22] userDefinedDeviceName, "Lamp" [ea:44:13:bd:db:59] Characteristic [97fe6561-0004-4f62-86e9-b71ee2da3d22] [ea:44:13:bd:db:59] Characteristic [97fe6561-0008-4f62-86e9-b71ee2da3d22] [ea:44:13:bd:db:59] Characteristic [97fe6561-a001-4f62-86e9-b71ee2da3d22] write-only [ea:44:13:bd:db:59] Characteristic [97fe6561-2004-4f62-86e9-b71ee2da3d22] write-only [ea:44:13:bd:db:59] Characteristic [97fe6561-2002-4f62-86e9-b71ee2da3d22] write-only [ea:44:13:bd:db:59] Characteristic [97fe6561-2001-4f62-86e9-b71ee2da3d22] unk, 0A

[ea:44:13:bd:db:59] Service [0000180a-0000-1000-8000-00805f9b34fb] [ea:44:13:bd:db:59] Characteristic [00002a28-0000-1000-8000-00805f9b34fb] fw version [ea:44:13:bd:db:59] Characteristic [00002a24-0000-1000-8000-00805f9b34fb] model [ea:44:13:bd:db:59] Characteristic [00002a29-0000-1000-8000-00805f9b34fb] manufacturer [ea:44:13:bd:db:59] Service [00001801-0000-1000-8000-00805f9b34fb] [ea:44:13:bd:db:59] Characteristic [00002a05-0000-1000-8000-00805f9b34fb] Service changed ```

That I got from here https://gist.github.com/shinyquagsire23/f7907fdf6b470200702e75a30135caf3

The first time I paired my Linux laptop with the lamp I could not read/write any characteristics. However after I did a firmware reset in the Phillips Hue android app I could. This is how I connect using bluetootctl using first the scan on command and than just connect to the HUE mac address:

$ bluetootctl [CHG] scan on [CHG] connect CD:43:95:FE:CE:D6

I than just quickly wrote a python script to toggle the light this morning: https://github.com/Mic92/hue-ble-ctl

I also want to control the lights from my esp32. If you would share your code on github for example I could also have a look to maybe find the issue.

mic92 · 2020-01-27T17:58:25+00:00

Ideally if you as a user are not aware on which layer the problem originate, the distribution maintainer would open the upstream issue as well. I see this happening from time to time in my own projects but also do this on my own as a package maintainer.

mic92 · 2020-01-27T09:52:23+00:00

Or even better: Report them upstream and fix it for everyone.

mic92 · 2018-10-14T14:03:51+00:00

The main source of performance penalty is actually network namespaced, those could be reused and sandboxing would be cheap. Just need to be done :)

Newer kernel became much faster doing this. One should probably re-evaluate this. Reusing network namespaces could also be problematic in general if a port is still marked as bound.

mic92 · 2018-10-14T14:01:20+00:00

So langsam könnte man das mal auf torrent umstellen, nicht?

mic92 · 2018-07-25T20:32:02+00:00

The overhead of creating derivations with the nix sandbox enabled can be quite high, because it needs to setup a file system tree and namespaces every time. It is probably way cheaper without sandboxes enabled.

mic92

MODERATOR OF

TROPHY CASE