Why every device will soon be running Nix and resistance is futile!

September 30, 2024 #Nix #DevOps #Google Playstore #Apple App Store #PC superpower

Nix (Series)

In the realm of software package management, Nix stands out as a groundbreaking tool. It redefines how we think about dependencies, reproducibility, and software distribution. Really this is one of those things you can do with benefits of hindsight, it makes you wonder why didn't people do things this way in the first place. It was actually a doctorate paper by some guy in the Netherlands.

TL:DR

( If you have issues with visability due to the index overlaping with the content, zoom out a little bit please. There's a weird little sweet spot where you can't scroll left and right and the index is overlaping the table, you probably won't even see it on the phones )

Aspect	Nix	Traditional Package Managers	App Stores	F-Droid
Dependency Handling	Purely functional approach.	Dependency resolution via metadata.	Bundled dependencies or minimal shared libraries.	Bundled dependencies, focuses on self contained apps
	Each package has its own isolated environment.	Shared library approach, managing dependencies centrally.	Often uses containerized solutions (e.g., Snap, Flatpak).	Uses APK format, typically includes required libraries.
	Avoids "dependency hell" by allowing multiple versions.	Can face "dependency hell" when conflicts arise.	- Dependencies are bundled with apps or minimally shared.	Avoids dependency hell by packaging dependencies.
Package/Binary Hosting	Nixpkgs and NixOS channels as main sources.	Central repositories (e.g., APT, RPM) managed by distros.	- Centralized app stores (e.g., Apple App Store, Google Play).	F-Droid repository hosting open-source APKs.
	Binary cache servers for fast downloads.	Mirrors and central repositories for binaries.	- Hosted binaries in app stores' servers.	Can add third-party repositories.
	Source code and build recipes included.	Often binary-focused, with some source packages.	- Binary-focused distribution.	Source code for apps is available, encouraging transparency.
Distribution	Declarative configuration for reproducibility.	Procedural updates, manual configuration.	- User-friendly, often automated updates.	Apps updated through repository or manual download.
	System state described by a single configuration file.	Package updates handled individually.	- Apps typically update independently and automatically.	Manual updates or repository-based updates.
Rollback and Versioning	Atomic upgrades and rollbacks for system-wide consistency.	Limited to manual intervention or specific tools.	- Some support for previous versions, mostly automatic.	Versions can be reverted manually, older versions available.
	Easy to revert to previous states with Nix.	System snapshots (e.g., Btrfs, LVM) needed for rollback.	- Older versions might not be available after updates.	Allows installation of multiple versions of apps.
Isolation and Sandboxing	Complete isolation per package.	Limited sandboxing, mainly relies on system-level isolation.	- Sandboxing varies, generally per app (e.g., iOS, Android).	Android app-level sandboxing.
	Prevents interference between packages.	Possible interference between installed packages.	- Apps isolated, limited system access (sandboxed).	Standard Android app sandboxing, enhanced privacy features.
Reproducibility	High reproducibility due to pure functional builds.	Varies widely, not inherently reproducible.	- Low, more dependent on specific device configurations.	Medium, builds are reproducible if source code is verified.
User Experience	More complex setup, targeted at power users.	Generally straightforward with good documentation.	- Designed for ease of use, typically very user-friendly.	Focus on simplicity, but manual updates can be cumbersome.
	Command-line and declarative focus.	Mix of command-line and GUI tools.	- GUI-centric, minimal command-line interaction.	GUI-centric, simple but less polished compared to major stores.
Flexibility and Control	High flexibility and control over package versions and environments.	- Moderate, depends on the package manager and distro.	- Low, users have less control over app versions and dependencies.	High, users can choose app versions and customize repositories.
	Custom environments and builds are easy to create.	Custom builds require manual setup and configuration.	- Customization is typically limited to app settings.	Allows addition of custom repositories.
System State Management	Entire system state managed declaratively.	System and package state managed separately.	- Focus on app state, system state management is separate.	Focus on app management, not system state.
Performance	Potentially slower builds due to isolation.	Varies, often optimized for the specific distro.	- Generally optimized for the specific device platform.	Performance is app-specific, Android optimizations.
Community and Ecosystem	Strong, niche community focused on advanced use cases.	Large, diverse communities with broad support.	- Wide user base, driven by platform vendors.	Dedicated FOSS community, smaller but active.
Security	Strong security through isolation and reproducibility.	Security varies, often relies on system security.	- App-level security with platform-level enforcement.	Security through open-source transparency, verified apps.
Integration and Compatibility	Excellent for integrating with other tools in a development environment.	Generally good, but can struggle with cross-distro compatibility.	- Seamless integration with the platform but limited to apps.	Integrates well with Android's ecosystem, focuses on open-source compatibility.

What is Nix?

Nix is a package manager and build system that promises deterministic builds and isolation from the traditional system state. It achieves this by treating packages and their dependencies as fully self-contained entities. Where as when a package is installed across the entire system ( Globally ) , it means that its files, configurations, and dependencies are placed in directories and locations accessible system-wide, rather than being contained within a specific isolated environment.

How Nix Manages Dependencies

Immutable Package Store: Nix stores each package in its own directory, isolated from others, identified by a cryptographic hash of all inputs, including dependencies. This guarantees that different versions or variations of a package do not interfere with one another.
Functional Approach: Nix uses a functional language to describe package build instructions. This means that each package's build is purely functional, producing the same output given the same input, ensuring reproducibility.
Declarative System Configuration: NixOS, the Linux distribution built on Nix, allows users to define their entire system configuration in a single declarative file. This file captures the exact state of the system, making it easy to recreate or roll back to previous states.
Garbage Collection and Rollbacks: Unused packages can be safely garbage-collected without risking system stability. Rollbacks are straightforward because the entire state is version-controlled.

Comparing Nix with Traditional Package Managers

Traditional Package Managers

Package managers like APT (for Debian-based systems) or Yum (for Red Hat-based systems) follow a more conventional approach:

Dependency Hell: They often suffer from "dependency hell," where different software packages require different versions of the same library, leading to conflicts.
Global State: These managers typically install software into global directories (like /usr or /lib), which can result in unintentional overwriting of files and version conflicts.
Less Reproducibility: The state of the system depends on the current state of the repositories and the user’s environment, which can vary and lead to less predictable outcomes.

Nix’s Advantages

Isolated Environments: By using unique paths for each package version, Nix eliminates conflicts and ensures that changing one package doesn’t affect others.
Reproducibility: Every build is reproducible and independent of the system’s state, which is ideal for development and deployment scenarios.
Declarative Management: The entire system state can be declared and versioned, making it easy to manage, replicate, or revert.

App Stores: A Different Paradigm

App stores operate differently from traditional package managers or Nix:

Centralized and Curated: Apps in stores are typically curated and approved before being made available, which helps maintain quality and security.
Self-Contained Apps: Applications are usually distributed as self-contained packages (like APKs for Android), which simplifies dependency management for the end user.
Focused on Applications: Unlike general-purpose package managers, app stores are focused on end-user applications, often neglecting the underlying libraries and dependencies that power them.

F-Droid: The Open Source App Store

F-Droid is a repository of free and open-source applications for Android. It:

Focuses on Free Software: Every app on F-Droid is open-source, adhering to the philosophy of free software.
Privacy and Security: F-Droid places a strong emphasis on user privacy and security, avoiding tracking and minimizing permissions where possible.
Independent from Google: Unlike the Google Play Store, F-Droid operates independently, providing an alternative for users seeking open-source options without Google's ecosystem. The servers are mainly ran by the project but due to the nature of the project your are free to essentially clone the entire repository and make your own build server to host it.

Conclusion

Nix introduces a transformative approach to package management with its functional, reproducible, and isolated system. It stands in contrast to traditional package managers and curated app stores like F-Droid, which have their own strengths but also face challenges that Nix elegantly addresses. Whether managing server environments, development tools, or entire operating systems, Nix’s model offers a robust solution for avoiding dependency conflicts and ensuring system consistency.

F-Droid - Free and Open Source Android App Repository

Nix - Best package manager