20 lines
6.3 KiB
XML
20 lines
6.3 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|
<channel>
|
|
<title>Computer on acorneroftheweb</title>
|
|
<link>https://acorneroftheweb.com/categories/computer/</link>
|
|
<description>Recent content in Computer on acorneroftheweb</description>
|
|
<generator>Hugo</generator>
|
|
<language>en-us</language>
|
|
<lastBuildDate>Sat, 12 Jul 2025 19:56:56 +0200</lastBuildDate>
|
|
<atom:link href="https://acorneroftheweb.com/categories/computer/index.xml" rel="self" type="application/rss+xml" />
|
|
<item>
|
|
<title>"NixOS, or why I would love a new introduction"</title>
|
|
<link>https://acorneroftheweb.com/post/2025/07/12/nixos-or-why-i-would-love-a-new-introduction/</link>
|
|
<pubDate>Sat, 12 Jul 2025 19:56:56 +0200</pubDate>
|
|
<guid>https://acorneroftheweb.com/post/2025/07/12/nixos-or-why-i-would-love-a-new-introduction/</guid>
|
|
<description>
<p>
I have been using NixOS for the last 2 years now.
I got introduced to it by friends, who had changed their entire workflow to accommodate it.
I was a bit skeptical at the beginning, tried installing the package manager to my arch install at the time, but didn&#39;t fully understand how I was supposed to use it in conjunction with how I was my computer at the time.
However, in the summer of 2023, I decided to take the plunge, and go the full way, with a new install.
Having run this type of setup for two years now, I have to admit it.
NixOS makes certain aspects of using my computer easier.</p>
<p>
As of recent, I have had to change the laptop that I was using.
With Nix as the base, I was able to make it usable, in way faster time than I think I would have been able with an Arch installation.
There are some aspects that make it harder though, since that laptop needed to make sure it worked as intended, such as disabling TLP and patching the kernel.
It also allowed me to resume my work on my current master thesis, since I could just pull the git repo and use nix develop to get all the dependencies for that work in specifics.</p>
<div id="outline-container-headline-1" class="outline-2">
<h2 id="headline-1">
Configuration
</h2>
<div id="outline-text-headline-1" class="outline-text-2">
<p>A friend of mine recently decided to try and do the switch themselves.
He has been an avid Arch fan boy for the last 2 years, since he got mad at Fedora for bricking his install (I genuinely do not understand how that happened).
He has been a bit particular however, refusing to configure software to ensure that he is able to use them anywhere, and to not have to learn esoteric languages for just one program.
I find this very sensible, while I approach it completely differently.
I want software customized to me, for me to act as best as I can within it.</p>
<p>
Anyway, this has lead to some confusion about Nix, and why things are as they are.
For example, how is Git, as defined in Home-Manager, able to configure it as it does?
And that is an implementation detail, but it is quite important for a user of Nix.
Why does Nix gatekeep the most foundational aspect of using Nix according to most users behind an Experimental-feature wall?
Now, I don&#39;t have the answers for these, since I am not yet a contributor to Nix, or well versed in the ecosystem, if I am being honest.</p>
</div>
</div>
<div id="outline-container-headline-2" class="outline-2">
<h2 id="headline-2">
A better introduction
</h2>
<div id="outline-text-headline-2" class="outline-text-2">
<p>A comment was made about the <a href="https://nixos.org/manual/nixos/stable/">installation guide</a>, about how it is not adequate, and I wouldn&#39;t know, I didn&#39;t read it when I got NixOS.
Like most of Nix documentation, it is a bit overwhelming and hard to navigate.
I like <a href="https://wiki.archlinux.org/title/Installation_guide">Arch&#39;s install guide</a>, since it is easier to search, and it segments the parts into different pages.
So, if I were to change anything, I would split this up, making sure that they are condensed into small, concrete parts.
An approach of this that I like is <a href="https://github.com/rust-lang/mdBook">mdbook</a>. One could therefore keep the more general structure of the guide, but each subsection is it&#39;s own page.</p>
<p>
Another aspect that would change is that an introduction should try to convey one way.
NixOS tries to introduce flakes in the <a href="https://nixos.org/manual/nixos/stable/#sec-installation-manual-installing">Installing section</a>, but never explaining what it is, or linking further.
Either you introduce a concept, link to more info, or you do not mention it.</p>
<p>
There are also several ways of managing the system that are not a good way of handling NixOS specifically.
Why is the <a href="https://nixos.org/manual/nixos/stable/#sec-ad-hoc-packages">Ad-hoc</a> way of using Nix even introduced, when it goes against the ideals of having a reproducible system?
Why introduce manual user management?
Further, it talks about a lot of different programs that a user may want to install.
This does however not teach the user to actually figure out where to find options.
Why isn&#39;t <a href="https://search.nixos.org">search.nixos.org</a> introduced?</p>
<p>
An optimal guide would introduce how to create a system, using the most commonly accepted methods, such as flakes.
You can introduce flakes as adding the ability to create a lock file like <code class="verbatim">package-lock.json</code> from npm.
This would then go into creating a functional system, and then a show case of how you can modify it and common fixes for NVIDIA, or similar.
I am a bit tempted to try and make this, but I also wanna do some own development on packages.</p>
</div>
</div>
</description>
|
|
</item>
|
|
</channel>
|
|
</rss>
|