The Guix-like part

 The nearest Fruix equivalent today is:

 1. install a normal-ish Fruix node
 2. put your desired dev tools in the system declaration
 3. reconfigure
 4. work on the machine

 So conceptually, yes: declare the system, reconfigure it, use it for development.

 For Fruix today, that usually means editing something like:

 - examples/system/self-hosted-dev.scm

 and setting:

 - #:development-packages ...
 - #:build-packages ...

 then running on the installed node:

 ```sh
   /usr/local/bin/fruix system reconfigure /path/to/your-system.scm \
     --system self-hosted-development-operating-system
 ```

 Where Fruix differs today

 ### 1. Fruix does not yet have the same “just add packages to the normal system profile” feel

 In Guix, you usually think in terms of:

 - “this is my OS”
 - “these packages are on the system”

 In Fruix right now, the model is more split:

 - runtime system
 - development profile
 - build profile

 So instead of “all dev tools are just part of the normal system profile”, Fruix currently prefers:

 - a smaller runtime
 - a dedicated dev environment
 - a dedicated build environment

 That’s why the installed node provides helpers like:

 ```sh
   eval "$( /usr/local/bin/fruix-development-environment )"
   eval "$( /usr/local/bin/fruix-build-environment )"
 ```

 So the workflow is still declarative, but it is more profile-structured than Guix’s typical system-packages workflow.

 ────────────────────────────────────────────────────────────────────────────────

 ### 2. Self-hosting checkout development is still more explicit

 On a Guix machine, it’s common to install Guix and then hack on Guix fairly directly.

 On Fruix today, there are really two layers:

 - the installed node Fruix at /usr/local/bin/fruix
 - a source checkout Fruix via ./bin/fruix

 Those are related, but not identical.

 - /usr/local/bin/fruix is the bundled node-management CLI
 - ./bin/fruix is what you use when you are editing Fruix source code in a checkout

 So if you’re changing the Fruix codebase itself, you still want a checkout and usually a prepared builder root.

 That means Fruix self-hosted development works, but it’s not yet as seamless as “the installed tool and the hacked-on source tree are
 one obvious thing.”

 ────────────────────────────────────────────────────────────────────────────────

 ### 3. Fruix still has a bootstrap/builder distinction that Guix largely hides

 Guix feels like:

 - install Guix
 - use Guix

 Fruix currently still feels more like:

 - plain FreeBSD
 - fruix-bootstrap
 - prepared Fruix builder
 - Fruix checkout
 - then build/install Fruix systems

 Even on a self-hosted node, checkout-based development still assumes the builder world is prepared enough to run ./bin/fruix.

 So compared to Guix, Fruix still has more visible scaffolding around the build/eval environment.

 ────────────────────────────────────────────────────────────────────────────────

 ### 4. Package coverage and maturity are still narrower

 In Guix, “add the tools I want” usually means a large package universe is already there.

 In Fruix, the self-hosted dev profile is currently a curated working set, not a fully mature package ecosystem yet.

 It already includes useful things like:

 - clang
 - gmake
 - autotools
 - nodejs
 - npm
 - ripgrep
 - tmux
 - neovim

 But it’s not yet at the point where “anything I’d expect on a mature distro is just there.”
 For example, we’ve already noted that some things like git are not yet part of the current packaged development profile.

 So Fruix is currently:

 - good enough for serious development
 - not yet equivalent to Guix’s package breadth and polish

 ────────────────────────────────────────────────────────────────────────────────

 ### 5. Fruix’s package provenance is still more transitional

 Guix packages are broadly “normal Guix packages.”

 Fruix today still has a visible distinction between:

 - host-staged / bootstrap-oriented FreeBSD packages
 - newer native-built pieces
 - curated FreeBSD base/runtime artifacts

 That means the current system works, but under the hood it is still more transitional than Guix’s unified model.

 You can absolutely develop on it, but Fruix is still on the path toward:
 - one cleaner package model
 - native-first defaults
 - less bootstrap/history leakage in how users think about packages

 ────────────────────────────────────────────────────────────────────────────────

 ### 6. Installation and lifecycle are real, but not yet as polished as Guix’s normal story

 Guix has a much more established “install once, reconfigure forever” feel.

 Fruix now has a real installed-node lifecycle:

 - status
 - reconfigure
 - switch
 - rollback

 and that is working on real booted nodes.

 But the broader story is still uneven:

 - node-local lifecycle is in decent shape
 - deploy still needs more hardening
 - upgrade is intentionally deferred pending pin/ownership design

 So Fruix is already useful for self-hosting, but not yet at Guix’s level of end-to-end lifecycle maturity.

 ────────────────────────────────────────────────────────────────────────────────

 ### 7. Fruix is stricter/more explicit about privileged system assembly

 This is more architectural than user-facing, but it matters.

 Fruix now has an explicit privileged assembly policy for things like:

 - image creation
 - install to raw files
 - block-device installs

 with metadata and helper-script boundaries.

 Guix doesn’t really expose this in the same way.

 So Fruix is currently more explicit about the dangerous parts of installation/media assembly, which is good, but also makes the system
 feel less “just do the obvious thing” than Guix in some spots.

 ────────────────────────────────────────────────────────────────────────────────

 So what is the practical difference in one sentence?

 Guix today is closer to:

 │ “install normal Guix, add packages to your OS config, reconfigure, done.”

 Fruix today is closer to:

 │ “install a self-hosted Fruix node, declare dev/build profiles in the system config, reconfigure, and use the provided dev/build
 │ environments — while checkout-based Fruix hacking still has a somewhat explicit builder/checkout workflow.”

 ────────────────────────────────────────────────────────────────────────────────

 Is that bad?

 Not really — just less finished.

 In some ways Fruix’s current split is actually useful:

 - runtime stays smaller
 - development environment is explicit
 - build environment is explicit
 - native/base work has a clearer boundary

 That’s good for system integrity and reproducibility.

 But from a human UX point of view, it’s still not yet as simple as Guix’s ‘normal system plus packages’ mental model.

 ────────────────────────────────────────────────────────────────────────────────

 My honest assessment

 If your standard is:

 │ “Can I install Fruix, declare my development tools, reconfigure, and use it as a self-hosted Fruix development machine?”

 then yes.

 If your standard is:

 │ “Is this now as simple and mature as doing the same thing on Guix?”

 then not yet.

 ────────────────────────────────────────────────────────────────────────────────

 The shortest summary

 Fruix currently differs from Guix in these main ways:

 - dev tools live in explicit dev/build profiles, not just one normal system package set
 - hacking on Fruix itself still distinguishes installed-node Fruix from checkout Fruix
 - self-hosted source development still assumes a prepared builder environment
 - package coverage is still curated and incomplete
 - install/lifecycle is working but not fully polished
 - some package/build plumbing is still transitional