<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://vtluug.org/w/index.php?action=history&amp;feed=atom&amp;title=Construct</id>
	<title>Construct - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://vtluug.org/w/index.php?action=history&amp;feed=atom&amp;title=Construct"/>
	<link rel="alternate" type="text/html" href="https://vtluug.org/w/index.php?title=Construct&amp;action=history"/>
	<updated>2026-10-01T16:13:52Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.31.1</generator>
	<entry>
		<id>https://vtluug.org/w/index.php?title=Construct&amp;diff=8327&amp;oldid=prev</id>
		<title>Clj: add construct page</title>
		<link rel="alternate" type="text/html" href="https://vtluug.org/w/index.php?title=Construct&amp;diff=8327&amp;oldid=prev"/>
		<updated>2026-09-18T18:03:42Z</updated>

		<summary type="html">&lt;p&gt;add construct page&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;[https://github.com/vtluug/construct/ Construct] is VTLUUG's pseudo-mono repo of the future. It contains [https://nixos.org NixOS] configurations for [[Bastille]], [[Vesuvius]], [[Rowhammer]], and more! It also has some [https://kubernetes.io Kubernetes] manifests, but they aren't automatically applied currently.&lt;br /&gt;
&lt;br /&gt;
== Why ==&lt;br /&gt;
Many person-hours have been spent on this repo, and we plan to spend many more, so it's reasonable to ask why Construct is the way it is. I think it's helpful to contrast with the &amp;quot;cowboy-style&amp;quot; system administration that you usually see at our scale:&lt;br /&gt;
# Notice problem&lt;br /&gt;
# SSH in&lt;br /&gt;
# Change some configs, reload etc&lt;br /&gt;
# Done!&lt;br /&gt;
Whereas the Construct way is more like&lt;br /&gt;
# Notice problem&lt;br /&gt;
# Make issue&lt;br /&gt;
# Make local branch&lt;br /&gt;
# Test/deploy loop (we don't have a staging environment :P)&lt;br /&gt;
# Make pull request&lt;br /&gt;
# It eventually gets merged into main&lt;br /&gt;
# Done…&lt;br /&gt;
The latter is clearly worse in the short-term, but in the long-term it means that:&lt;br /&gt;
* The reason for a change is documented&lt;br /&gt;
* We have (some) code review before pull requests are merged&lt;br /&gt;
* Fixes in shared configuration are actually shared&lt;br /&gt;
&lt;br /&gt;
== Why Nix(OS) ==&lt;br /&gt;
With NixOS, our deploys are an atomic unit. If a deploy fails, &amp;lt;code&amp;gt;nixos-rebuild&amp;lt;/code&amp;gt; will fully roll it back. In the [https://github.com/vtluug/construct/pull/31 near future], &amp;lt;code&amp;gt;nixos-version --configuration-revision&amp;lt;/code&amp;gt; will tell us what git commit a machine is currently running. NixOS modules make it easy to share common configuration while still overriding stuff where needed, and Nix + Nixpkgs makes packaging our own software in a reproducible way much easier.&lt;/div&gt;</summary>
		<author><name>Clj</name></author>
		
	</entry>
</feed>