maurice/snix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(website): remove all windows line endings

Browse source 
Change-Id: I340486d90a1fb74e26b31f1f330f61ee2b570c43
Reviewed-on: https://cl.snix.dev/c/snix/+/30139
Autosubmit: Paul Meyer <katexochen0@gmail.com>
Reviewed-by: Florian Klink <flokli@flokli.de>
Tested-by: besadii
This commit is contained in:
Paul Meyer 2025-03-19 12:00:09 +01:00 • committed by clbot
parent dd1ba855e2
commit 0b717258f0
17 changed files with 532 additions and 532 deletions
Download patch file Download diff file Expand all files Collapse all files

38
web/content/docs/components/architecture.md
View file

@ -1,26 +1,26 @@
---
title: "Architecture"
slug: architecture
description: ""
summary: ""
date: 2025-03-14T14:14:35+01:00
lastmod: 2025-03-14T14:14:35+01:00
draft: false
weight: 31
toc: true
---
Snix is more decoupled than the existing, monolithic Nix implementation.
---
title: "Architecture"
slug: architecture
description: ""
summary: ""
date: 2025-03-14T14:14:35+01:00
lastmod: 2025-03-14T14:14:35+01:00
draft: false
weight: 31
toc: true
---
Snix is more decoupled than the existing, monolithic Nix implementation.
In practice, we expect to gain several benefits from this, such as:
* Ability to use different builders
* Ability to use different store implementations
* Ability to use different builders
* Ability to use different store implementations
* No monopolisation of the implementation, allowing users to replace components
that they are unhappy with (up to and including the language evaluator)
* Less hidden intra-dependencies between tools due to explicit RPC/IPC
boundaries
boundaries
In addition to many individual backend implementations, Builders and Store
backends also provide a gRPC server and clients, allowing to plug in your own
implementation.
implementation.