Nixpkgs Documentation

repository·master·Indexed 12 days ago

https://github.com/nixos/nixpkgs

A massive collection of over 140,000 software packages for the Nix package manager and the foundation for NixOS. This documentation covers contributing to the Nixpkgs manual, using CommonMark extensions for technical literals and admonitions, and detailed guides on the `lib.fileset` and `lib.path` libraries.

Tokens
413.5K
Snippets
1.3K
Records
1.8K
Agent score
97%

What's inside Nixpkgs

  1. Overview of cusolvermp

    master

    cusolvermp is a library provided by NVIDIA for high-performance linear algebra operations. It is part of the CUDA ecosystem and is used for solving dense and sparse linear systems.

    For detailed information regarding the library, visit the official NVIDIA redistribution link: https://developer.download.nvidia.com/compute/cusolvermp/redist/

    Before using this library, ensure your system meets the necessary hardware and software requirements specified by NVIDIA: https://docs.nvidia.com/cuda/cusolvermp/getting_started/index.html#hardware-and-software-requirements

  2. Overview of cuTensor

    master

    cuTensor is a library provided by NVIDIA for high-performance tensor operations. It is designed to accelerate tensor computations on NVIDIA GPUs.

    For detailed technical documentation and support requirements, refer to the official NVIDIA resources:

  3. Overview of nixos-render-docs

    master
    nixos-render-docs is a specialized CommonMark and man-pages renderer designed specifically for the NixOS and Nixpkgs manuals. It implements RFC 72 to enable a lossless port of documentation from DocBook to CommonMark using custom extensions. It is a single-purpose framework designed to avoid the limitations and breakage associated with general-purpose documentation tools.
  4. Overview of nixos-init

    master

    nixos-init is a system designed for the initialization of NixOS. Its primary purpose is to work around Filesystem Hierarchy Standard (FHS) constraints imposed by tools like systemd during the boot process.

    Design Principles:

    • Minimalism: It performs only the minimal work required to start systemd. Any task that can be deferred until after systemd has started should be deferred.
    • Robustness: It aims to eventually replace system.activationScripts for booting, enable bashless activation, and improve overall NixOS robustness.
    • Non-extensibility: It is explicitly not designed to be extended dynamically by downstream users; functionality should only be added when strictly necessary.