u/ArchieTect

Forgive me if anything here sounds disjointed since I don't have experience with running AI models other than Gemini's web interface.

Do you have a dev shell flake that would require just a cd into the directory and run nix develop?

I run Proxmox with several containers and VMs assembled over time from Debian images. The goal is to move this to a NixOS host and then to child NixOS containers and VMs inside the NixOS host using Incus. To prep for that migration, I currently run a VM inside Proxmox which is the future NixOS host. I will dry-run the entire host as a virtual machine right up until the changeover.

Thus far, I ssh into the NixOS host and run `nixos-rebuild switch --flake` but thanks to this blog I learned about nixos-rebuild --flake .#flakeTarget --target-host user@remote-host --use-remote-sudo which is great.

So moving forward, I can add development to the host config on my main pc, and push the flake rebuilds from my main PC to the server. Once the inner NixOS VMS are established, I can run every VM flake switch from my main PC in a flat list like

nixos-rebuild --flake .#hostConfig --target-host user@<host_ip> --use-remote-sudo
nixos-rebuild --flake .#subVM1 --target-host user@<vm1_ip> --use-remote-sudo
nixos-rebuild --flake .#subVM2 --target-host user@<vm2_ip> --use-remote-sudo
etc.

But my question is, is there a way to declare all this in the host config? It would be great if there were 'turtles all the way down' so to speak, like a recursive config that triggers the inner configs.

There would need to be pseudocode like

if container vm1 does not exist, deploy image vm1. Then, proceed to flake switch vm1
...else if container vm1 exists, proceed to flake switch vm1
(repeat for each VM)

If you have any suggestions or insight, please share.

I can use Antlr to validate the syntax of an HTML document. What can I use to go a step further, and validate that the 'structure' of an html document is correct? i.e.

html: html_decl head body; head: head_item+; head_item: style|title|script; body: body_item+; body_item: div|p|h; etc

this seems like I just wrote some valid 'structure' validation rules in Antlr. I'm pretty sure Antlr is not meant to achieve this, but i'm ignorant of any implementations that could handle this and i'd like to know if it's possible.

The best I can figure is that I need to write two grammars, one to parse the raw source text, and then a second to parse the object types. Am I thinking about this correctly? Or is there another way?

I've been chipping away at learning all the Nix- aspects and wondering if i'm just misunderstanding something here.

I wanted to write the most basic flake.nix and so I did. This flake passes nix flake check :

{
  inputs = {};
  outputs = {self,...}:{};
}

It does nothing, of course, but it compiles without errors.

In fact, the schema of a flake file is exactly:

{
   description = ""; #optional
   inputs = {};
   outputs = {self,...}:{};
   nixConfig = {}; #optional
}

I can find these flake attributes documented here which outlines the above.

Great, now i'd like to go one nesting deeper. The same wiki page (https://wiki.nixos.org/wiki/Flakes) has sections for input schema and output schema. It says "for input schema, see the man page for nix flake check" which does not seem to have any schema info. It also gives a significant code block for the output schema which I guess I'm just too lost to understand. That being said, all attribute sets can be flattened, for example, I know from examples that

inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-20.03";

...exists and is a valid sub-nested attribute of type string... so the above is the same as:

inputs = {
   nixpkgs = {
      url = "";
   };
};

So in my own mental model, it's super obvious that we could refer to the above with an "absolute path" like this:

<flake.nix>.inputs.nixpkgs.url <string>

Now we could build an entire list of absolute paths to attributes that flake.nix accepts:

<path>                             <type>
<flake.nix>.inputs.*               <set>
<flake.nix>.inputs.nixpkgs.*       <set>
<flake.nix>.inputs.nixpkgs.url     <string>
<flake.nix>.description            <string>
<flake.nix>.outputs                <func<set,set>>
<flake.nix>.nixConfig.*            <set>
#note: this is very incomplete; the idea would be to have a giant list of all the absolute paths to the attributes. 

So hopefully by now you see where i'm going with this, where the following could be the documented schema of flake.nix:

<flake.nix>.*                    <set>
<flake.nix>.description          <string>
<flake.nix>.inputs.*             <set>
<flake.nix>.nixConfig.*          <set>
<flake.nix>.outputs              <func<set,set>>   # func<> means a function that takes a set and returns a set

So you can see that I used star notation where my understanding is "incomplete documentation" which in reality would lead to the next man page. I don't really know what the entire range of what the stars could be.

I find this model easy to understand what the range of allowable attributes are.

When it comes to outputs being a function that takes a set, the outputs function will only ever return a set, and therefore for documentation purposes we could probably just keep chaining the appropriate return value's set attributes like

<flake.nix>.outputs().nixosConfigurations.* #ignore this. see edit below. the revised version is just 
<flake.nix>.outputs.nixosConfigurations.*

Where foo() is a function and therefore everything after is an argument...

Edit: Once the outputs function is called by the build system, we can assume that outputs.nixosConfigurations is a valid attribute path, so I edited the code example. we don't need extra () junk in my example

So hopefully made the case for documenting things this way, now the question is: does this information exist in documentation in some master list somewhere, and i'm too dumb to find it, or can you point me to this information?

I might be misunderstanding media bridge mode.

I installed FreshTomato on an Asus router running media bridge mode. the tomato router is hardwired into my NAS ethernet port, in a different room than my main wifi router.

I have successful connection over wifi from the main router to the tomato router, through ethernet to my PC in the same room as the NAS. This setup is temporary for ensuring the media bridge works. I then remove the ethernet cable from my PC, and re-enable the PC's built-in motherboard wifi.

Doing so causes my PC to suffer slowdowns and connection problems. It seems that the problems are because the tomato router radio is broadcasting and my PC wifi cannot distinguish between the tomato bridge router radio and the main router radio.

I want the PC wifi to connect direct to the main router. The tomato router radio should be in a client-only mode and not be communicating with my PC.

Do I have settings mis-configured?

I have nearly achieved remoting into my home server except for this one problem.

I have 2 components, 1. a GliNet Comet (in my Tailnet), and 2. dedicated Asus wifi router running FreshTomato 2026.2 in Media Bridge mode. The media bridge serves one purpose: relay data from the main wifi router to the Comet. The PC itself has it's own wifi NIC. The Comet's only connection to the PC is via HDMI.

The media bridge + Comet are connected to a smart plug that cuts power when not needed. It shuts down the Comet and the media bridge. Powering the plug enables the Comet and the media bridge. The bridge auto connects to the main router, and the Comet appears in my Tailnet automatically.

In testing, I am at home and can successfully send WoWLAN magic packets. I can shut down the server and return an hour later of being stone cold off and the Comet will boot the server. This is using 5G over cellular to access the tailnet, which proves I can be geographically remote and still trigger the WoWLAN.

But when I power cycle the smart plug, it results in subsequent magic packets failing.

Media Bridge mode in FreshTomato means that all DHCP is done by the main router. In my main router, I have assigned a static table assignment for an IP to be assigned to the server MAC address. The server is directly connected to the main router over wifi. So the power cycle somehow interferes with the magic packet:

Phone->Comet Web UI -> phone tailnet client -> web -> home main router -> media bridge-> Comet -> wake request <- -> media bridge -> main router -> server NIC

As you can see, the media bridge and main router are the only steps in the signal chain that could interfere with the magic packet and 1. the main router is set up correctly, 2. the media bridge is a dumb relay and should not have any part in forgetting the ARP assignment.

Can anyone suggest what could be going wrong?