Skip to content

Commit

Permalink
Merge pull request #3 from ryan4yin/fix-grammers
Browse files Browse the repository at this point in the history
Fix grammers
  • Loading branch information
ryan4yin committed Jun 24, 2023
2 parents 6c19122 + 2195c65 commit 23ee345
Show file tree
Hide file tree
Showing 18 changed files with 54 additions and 86 deletions.
5 changes: 2 additions & 3 deletions docs/best-practices/debug-with-nix-repl.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@

## Debug with `nix repl`

We've used `nix repl '<nixpkgs>'` many times to check the source code in this guide, it's really a powerful tool to help us understand how things work in Nix.
We've used `nix repl '<nixpkgs>'` many times to check the source code in this guide, it's a powerful tool to help us understand how things work in Nix.

Better take a look at the help message of `nix repl`:

Expand Down Expand Up @@ -141,4 +140,4 @@ outputs.nixosConfigurations.ai.config.home-manager.users.ryan.home.file..config/
#......
```

As you can see, we can check every attribute of my flake in the REPL after loading it, which is very convenient for debugging.
As we can see, we can check every attribute of my flake in the REPL after loading it, which is very convenient for debugging.
6 changes: 2 additions & 4 deletions docs/best-practices/remote-deployment.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@

## Remote deployment

Some tools like [NixOps](https://github.com/NixOS/nixops), [deploy-rs](https://github.com/serokell/deploy-rs), and [colmena](https://github.com/zhaofengli/colmena) can all be used to deploy NixOS configuration to remote hosts, but they are all too complicated for me.
Expand All @@ -22,12 +21,11 @@ ssh-add ~/.ssh/ai-idols
nixos-rebuild --flake .#aquamarine --target-host 192.168.4.1 --build-host 192.168.4.1 switch --use-remote-sudo --verbose
```

The commands above will build & deploy the configuration to aquamarine, the build process will be executed on aquamarine too,
The commands above will build & deploy the configuration to `aquamarine`, the build process will be executed on `aquamarine` too,
and the `--use-remote-sudo` option indicates that we need to use sudo permission on the remote server to deploy the configuration.

If you want to build the configuration locally and deploy it to the remote server, just replace `--build-host aquamarinr` with `--build-host localhost`.

Instead of use ip address directly, we can also define some host aliases in `~/.ssh/config` or `/etc/ssh/ssh_config`, for example:
Instead of using IP address directly, we can also define some host aliases in `~/.ssh/config` or `/etc/ssh/ssh_config`, for example:

> ssh's config can be generated completely through Nix configuration, and this task is left to you.
Expand Down
11 changes: 5 additions & 6 deletions docs/best-practices/run-downloaded-binaries-on-nixos.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,11 +2,11 @@

NixOS does not follow the FHS standard, so the binaries you download from the Internet will not likely work on NixOS. But there are some ways to make it work.

Here is a detailed guide which provides 10 ways to run downloaded binaries on NixOS: [Different methods to run a non-nixos executable on Nixos](https://unix.stackexchange.com/questions/522822/different-methods-to-run-a-non-nixos-executable-on-nixos), I recommend you to read it.
Here is a detailed guide that provides 10 ways to run downloaded binaries on NixOS: [Different methods to run a non-nixos executable on Nixos](https://unix.stackexchange.com/questions/522822/different-methods-to-run-a-non-nixos-executable-on-nixos), I recommend you to read it.

Among these methods, I prefer creating a FHS environment to run the binary, which is very convenient and easy to use.
Among these methods, I prefer creating an FHS environment to run the binary, which is very convenient and easy to use.

To create such an environment, add the following code to one of your nix modules:
To create such an environment, add the following code to one of your Nix modules:

```nix
{ config, pkgs, lib, ... }:
Expand Down Expand Up @@ -42,7 +42,7 @@ To create such an environment, add the following code to one of your nix modules
}
```

after applying the updated configuration, you can run `fhs` to enter the FHS environment, and then run the binary you downloaded, e.g.
After applying the updated configuration, you can run `fhs` to enter the FHS environment, and then run the binary you downloaded, e.g.

```shell
# Activating FHS drops me in a shell which looks like a "normal" Linux
Expand All @@ -57,5 +57,4 @@ $ fhs

- [Tips&Tricks for NixOS Desktop - NixOS Discourse][Tips&Tricks for NixOS Desktop - NixOS Discourse]: Just as the title says, it is a collection of tips and tricks for NixOS desktop.


[Tips&Tricks for NixOS Desktop - NixOS Discourse]: https://discourse.nixos.org/t/tips-tricks-for-nixos-desktop/28488
[Tips&Tricks for NixOS Desktop - NixOS Discourse]: https://discourse.nixos.org/t/tips-tricks-for-nixos-desktop/28488
4 changes: 2 additions & 2 deletions docs/best-practices/simplify-nixos-related-commands.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## Simplify nixos-related commands
## Simplify NixOS-related commands

I use Makefile to simplify nixos-related commands, which is very convenient.
I use Makefile to simplify NixOS-related commands, which is very convenient.
You can also use other similar tools to do this job, here I will only introduce my usage as a reference.

My Makefile looks like this:
Expand Down
17 changes: 7 additions & 10 deletions docs/introduction/advantages-and-disadvantages.md
Original file line number Diff line number Diff line change
@@ -1,30 +1,27 @@
## Advantages & Disadvantages of NixOS


## Advantages

- **Declarative configuration, Environment as Code, can be managed with Git**
- Nix Flakes lock dependences's version through a lock file named `flake.lock`, to ensure that the system is reproducible. This idea actually borrows from some package managers such as npm, cargo, etc.
- Nix Flakes lock dependencies' version through a lock file named `flake.lock`, to ensure that the system is reproducible. This idea actually borrows from some package managers such as npm, cargo, etc.
- Compared with Docker, Nix Flakes provides a much stronger guarantee for the reproducibility of build results, because Dockerfile is actually an imperative configuration and there is no such thing as `flake.lock` in Docker, Docker's reproducibility relies on sharing the build result(which is MUCH MORE LARGER than Dockerfile itself) through image registry(e.g. Docker Hub).
- **Highly convenient system customization capability**
- By changing a few lines of configuration, various components of NixOS can be easily customized. This is because Nix encapsulates all the underlying complex operations in nix packages and only exports concise and necessary declarative parameters.
- By changing a few lines of configuration, various components of NixOS can be easily customized. This is because Nix encapsulates all the underlying complex operations in Nix packages and only exports concise and necessary declarative parameters.
- Moreover, this modification is very safe. For example, switching between different desktop environments on NixOS is very simple and clean, you just need to change several lines of the configuration.
- **Rollback**: The system can be restored to any historical state at any time(except the state that are NOT managed by NixOS, such as docker containers, postgresql data, etc...), and NixOS even adds all old versions to the boot options by default to ensure that the system can be rolled back at any time even though it crashes. Therefore, NixOS is also considered one of the most stable Linux Systems.
- **Rollback**: The system can be restored to any historical state at any time(except the state that is NOT managed by NixOS, such as docker containers, postgresql data, etc...), and NixOS even adds all old versions to the boot options by default to ensure that the system can be rolled back at any time even though it crashes. Therefore, NixOS is also considered one of the most stable Linux Systems.
- **No dependency conflicts**: Because each software package in Nix has a unique hash, its installation path also includes this hash value, so multiple versions can coexist.
- **The community is very active, and there are quite a few third-party projects**. The official package repository, nixpkgs, has many contributors, and many people share their Nix configuration on Github/Gitlab. After browsing through it, the entire ecosystem gives me a sense of excitement in discovering a new continent.


## Disadvantages

- **High learning curve:**: If you want the system to be completely reproducible and avoid pitfalls caused by improper use, you need to learn about the entire design of Nix and manage the system in a declarative manner. You cannot blindly use `nix-env -i` (which is similar to `apt-get install`).
- **Chaotic documentation**: Flakes is still an experimental feature, and there are currently few documents introducing it, Most of the Nix community's documentation only introduces the old cli such as `nix-env`/`nix-channel`. If you want to start learning Nix directly from Flakes, you need to refer to a large number of old documents and extract what you need from them. In addition, some of Nix's current core functions are not well-documented (such as `imports` and Nix Module System), to figure out what it does, it is best to look at the source code...
- **Relatively high disk space usage**: To ensure that the system can be rolled back at any time, Nix preserves all historical environments by default, which can take up a lot of disk space. It can be a problem especially on some resource-constrained Virtual Machines.
- **Error messages may be obscure**: Sometimes you may come across some strange error messages and don't understand what's going on.
`--show- Trace` may throw you a stack of errors that are of little help.

- **Relatively high disk space usage**: To ensure that the system can be rolled back at any time, Nix preserves all historical environments by default, which can take up a lot of disk space. It can be a problem, especially on some resource-constrained Virtual Machines.
- **Error messages may be obscure**: Sometimes you may come across some strange error messages and don't understand what's going on.
`--show- Trace` may throw you a stack of errors that are of little help.

## Summary

Generally speaking, I think NixOS is suitable for developers who have some experience in using Linux and programming and want to have more control over their systems.

I don't recommend you getting started with NixOS if you are new to Linux, it can be a very painful journey.
I don't recommend you get started with NixOS if you are new to Linux, it can be a very painful journey.
12 changes: 5 additions & 7 deletions docs/introduction/index.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@

## Introduction to Nix & NixOS

Nix package manager is a declarative configuration management tool. Users need to declare the expected system state in some configuration, and Nix is responsible for achieving that goal.
Expand All @@ -17,18 +16,17 @@ home-manager is designed to manage user-level packages & configuration files in

Due to Nix's features such as declarative and reproducible, Nix is not only used to manage desktop environments but also widely used to manage development environments, compilation environments, cloud virtual machines, container image construction, etc. [NixOps](https://github.com/NixOS/nixops) from the Nix official and [deploy-rs](https://github.com/serokell/deploy-rs) from the community are both operations tools based on Nix.


## Why NixOS?

I heard about the Nix package manager several years ago. It uses the Nix language to describe system configuration, and the Linux distribution built on top of it, can roll back the system to any historical state at any time(In fact, only the state declared by nix configuration files can be rollback). Although it sounds impressive, it requires learning a new language and writing code to install packages, I thought it was too troublesome and didn't study it at the time.
I heard about the Nix package manager several years ago. It uses the Nix language to describe system configuration, and the Linux distribution built on top of it can roll back the system to any historical state at any time(In fact, only the state declared by nix configuration files can be rollback). Although it sounds impressive, it requires learning a new language and writing code to install packages, I thought it was too troublesome and didn't study it at the time.

But I recently encountered a lot of environmental problems in the process of using EndeavourOS, and I spent a lot of energy to solve them, which made me exhausted. After thinking about it carefully, I realized that the root cause was that EndeavourOS do not have any version control and rollback mechanism, which caused the system to be unable to be restored when problems occurred.
But I recently encountered a lot of environmental problems in the process of using EndeavourOS, and I spent a lot of energy solving them, which made me exhausted. After thinking about it carefully, I realized that the root cause was that EndeavourOS do not have any version control and rollback mechanism, which caused the system to be unable to be restored when problems occurred.

So I switched to NixOS.

I am quite satisfied with NixOS, even more than expected.
The most amazing thing is, now I can restore the entire i3 environment and my commonly used softwares on a fresh NixOS host with just one command, that's really fantastic!
I am quite satisfied with NixOS, even more than expected.
The most amazing thing is, now I can restore the entire i3 environment and my commonly used packages on a fresh NixOS host with just one command, that's really fantastic!

The rollback capability of NixOS gave me a lot of confidence - I no longer fear breaking the system any more. I even tried a lot of new things on NixOS, such as hyprland compositor. (On EndeavourOS before, I wouldn't have dared to play with such new compositors - it would have been a big hassle if something went wrong with the system and I need to fix it manually through various tricks.)
The rollback capability of NixOS gave me a lot of confidence - I no longer fear breaking the system anymore. I even tried a lot of new things on NixOS, such as hyprland compositor. (On EndeavourOS before, I wouldn't have dared to play with such new compositors - it would have been a big hassle if something went wrong with the system and I need to fix it manually through various tricks.)

So that's why I chose NixOS.
7 changes: 3 additions & 4 deletions docs/nixos-with-flakes/downgrade-or-upgrade-packages.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,11 @@

## Downgrade or upgrade packages

After using Flakes, most people are currently using the `nixos-unstable` branch of nixpkgs. Sometimes you will encounter some bugs, such as the [chrome/vscode crash problem](https://github.com/swaywm/sway/issues/7562)

To resolve problems, we may need to downgrade or upgrade some packages. In Flakes, all package versions and hash values are one-to-one corresponding to the git commit of their flake input.
Therefore, to downgrade or upgrade a package, we need to lock the git commit of its flake input.

For exmaple, let's add multiple nixpkgs, each using a different git commit or branch:
For example, let's add multiple nixpkgs, each using a different git commit or branch:

```nix
{
Expand Down Expand Up @@ -57,7 +56,7 @@ For exmaple, let's add multiple nixpkgs, each using a different git commit or br
}
```

And then refer the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub module, a home manager's sub module as an example:
And then refer to the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub module, a home manager's sub module as an example:

```nix
{
Expand Down Expand Up @@ -86,6 +85,6 @@ And then refer the packages from `pkgs-stable` or `pkgs-fd40cef8d` in your sub m
}
```

After adjusted the configuration, deploy it with `sudo nixos-rebuild switch`, then your firefox/chrome/vscode will be downgraded to the version corresponding to `nixpkgs-stable` or `nixpkgs-fd40cef8d`.
After adjusting the configuration, deploy it with `sudo nixos-rebuild switch`, then your firefox/chrome/vscode will be downgraded to the version corresponding to `nixpkgs-stable` or `nixpkgs-fd40cef8d`.

> according to [1000 instances of nixpkgs](https://discourse.nixos.org/t/1000-instances-of-nixpkgs/17347), it's not a good practice to use `import` in sub modules to customize `nixpkgs`, because each `import` will create a new instance of nixpkgs, which will increase the build time and memory usage as the configuration grows. So here we create all nixpkgs instances in `flake.nix` to avoid this problem.
8 changes: 3 additions & 5 deletions docs/nixos-with-flakes/get-started-with-nixos.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
## Get Started with NixOS


After learning the basics of the Nix language, we can start using it to configure our NixOS. The default configuration for NixOS is located at `/etc/nixos/configuration.nix`, which contains all the declarative configuration for the system, such as time zone, language, keyboard layout, network, users, file system, boot options, etc.

If we want to modify the system state in a reproducible way (**which is also the most recommended way**), we need to manually edit `/etc/nixos/configuration.nix`, and then execute `sudo nixos-rebuild switch` to apply the modified configuration, it will generate a new system environment based on the configuration file we modified, sets the new environment as the default one, and also preserves & added the previous environment into the boot options of grub/sytemd-boot. This ensures we can always roll back to the old environment(even if the new environment fails to start).
Expand All @@ -13,7 +12,7 @@ Now first, let's learn how to manage NixOS through the classic method, `/etc/nix

As I mentioned earlier, this is the classic method to configured NixOS, and also the default method currently used by NixOS. It relies on data sources configured by `nix-channel` and has no version-locking mechanism, making it difficult to ensure the reproducibility of the system.

For example, to enable ssh and add a user "ryan", simply add the following content into `/etc/nixos/configuration.nix`:
For example, to enable ssh and add a user `ryan`, simply add the following content into `/etc/nixos/configuration.nix`:

```nix
# Edit this configuration file to define what should be installed on
Expand Down Expand Up @@ -65,12 +64,11 @@ Any reproducible changes to the system can be made by modifying `/etc/nixos/conf

All configuration options in `/etc/nixos/configuration.nix` can be found in the following places:

- By searching on Google, such as `Chrome NixOS`, which will provide NixOS informations related to Chrome. Generally, the NixOS Wiki and the source code of Nixpkgs will be among the top results.
- By searching on Google, such as `Chrome NixOS`, which will provide NixOS information related to Chrome. Generally, the NixOS Wiki and the source code of Nixpkgs will be among the top results.
- By searching for keywords in [NixOS Options Search](https://search.nixos.org/options).
- For system-level configuration, relevant documentation can be found in [Configuration - NixOS Manual](https://nixos.org/manual/nixos/unstable/index.html#ch-configuration).
- By searching for keywords directly in the source code of [nixpkgs](https://github.com/NixOS/nixpkgs) on GitHub.


## References

- [Overview of the NixOS Linux distribution]( https://nixos.wiki/wiki/Overview_of_the_NixOS_Linux_distribution)
- [Overview of the NixOS Linux distribution](https://nixos.wiki/wiki/Overview_of_the_NixOS_Linux_distribution)
Loading

0 comments on commit 23ee345

Please sign in to comment.