Ask HN: What's a good Linux OS and setup to build a dev “network” on my laptop?

In terms of security model it uses Xen to virtualize VM's and the default network isolation is decent enough for most people wanting network segmentation. The system administrator can either open up or further lock down the networking and firewall(s) to change how restricted VM's are from one another or the internet or the local networks. Their default implementation assumes that one may want to use a ram-only stateless or ephemeral OS to access Tor and another VM that can only talk to the Tor VM to a specific IP/port to prevent leakage. For other security scenarios people would have to create their own firewall rules and networking so that learning exercise would be on each person.

In terms of state actors there is really no way to answer that for any distribution as developers can be compelled into silence through assorted fear inducing tactics and lawful intercept can be a series of subtle design weaknesses that would not be spotted by the best external developers. These subtle design weaknesses can be a combination of OS libraries, combinations of hidden CPU registers and known x86 works as designed flaws.

I try to avoid virtual machines unless there is an absolute need to virtualise the hardware as well - in most cases single kernel, multiple containers is preferred.

Specifically, I use Debian with systemd-nspawn unprivileged (user namespaced) containers (managed by machinectl), defined and built using mkosi as BTRFS subvolumes (a BTRFS mounted on /var/lib/machines/ allows nspawn to create copy-on-write containers from a 'template' container).

The nice thing about nspawn is being able to create simple declarative configurations with private namespaces. With a private network namespace it has the concept of 'zones' which are containers that share the same (private) bridged network. systemd-networkd has built-in configs for both the host and containers to do automatic configuration.

I use this to create per-domain (e.g. example.com) zones with multiple function-specific containers (one for router/firewall, another for DHCP and DNS, others for single-sign-on, database, web, mail, and whatever else is required). I use veth to connect the zone selectively to the host interface public bridge interface providing external access if necessary.

This allows 'development' 'test' and 'production' domains using mkosi to define and build each repeatedly as needed. In the non-public domains the zone can be configured to use the same public IP addresses as production will use without it leaking outside the zone.

I use IPv6 only in the zones with both ULAs and global prefixes and DNS64/NAT64 in the 'router' container if the zone needs to make outbound connections (to IPv4 destinations).

I use netfilter rules applied to each zone's bridge interface to impose firewall restrictions.

Using veth pairs one can connect two containers (or zones) directly rather than using the common zone bridge interface.

I do dev work on the host itself; if you want to partition application usage I'd suggest keeping it simple by using multiple user accounts, one per 'task' so $USER configs and so on are all kept separate.

In the 'development' containers I do things like bind-mounting the base source-code directory, or project-specific directory, into the container. I do all source-code work on the host but build and test in the appropriate container.

For example I have 'linux-builder' container where I do out-of-tree kernel builds for multiple architectures. The container has the required crossbuild tools installed. Recently this has been used to build latest mainline kernel for amd64, arm64, and powerpc64 (for the Xbox 360!).

There are quite a few paper cuts in setting it up the first time. I recall it took about five hours before I finally had my first VM in the right place, with right size of disk space and ram and the version of linux I wanted. But after the learning curve it becomes very easy. Honest :)

There are products like encrypted phones. They are advertised as secure locked down devices designed for people who have high security requirements. They attract crooks and thus law enforcement that compromise their servers. This can go unnoticed for decades.

Of course this risk is there for any distribution, but we can compare one distribution with another.