Its possible to install the nvidiaLegacy470 driver for the slightly outdated GPUs, but the documentation only has the hints how to install the drivers for the even older GPUs.
`beignet` saw no development since 2018 and was never ported from
`llvmPackages_6`. Is it's a library to support `OpenCL` on older GPUs
let's drop it from `nixpkgs`.
The Nixpkgs documentation on the linux kernel builders focused on
using and extending kernels that were already packaged, but never
mentioned that it's possible to also build a kernel almost "from
scratch".
The NixOS documentation went a bit deeper on manual linux kernel
configs, but that information wasn't particularly NixOS-specific.
This commit consolidates the information related to building the
kernel on Nixpkgs's documentation, while keeping any additional
NixOS-specific information on NixOS's documentation.
An additional README.md was created for contributor-facing
documentation.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
[Motivation](NixOS#257817 (comment))
`extraLayouts` was missed in #259891, so moving it to the other xkb
options with this PR.
Signed-off-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
[Motivation](https://github.com/NixOS/nixpkgs/issues/257817#issuecomment-1741705042):
- Having all the XKB options in the same attribute set clarifies their
relation better than using a common option name prefix ("xkb").
- `services.xserver.layout` is an XKB option, but this is not obvious
from its name. Putting it with the other XKB options clarifies this.
Co-authored-by: Michele Guerini Rocco <rnhmjoj@users.noreply.github.com>
this adds support for structural includes to nixos-render-docs.
structural includes provide a way to denote the (sub)structure of the
nixos manual in the markdown source files, very similar to how we used
literal docbook blocks before, and are processed by nixos-render-docs
without involvement of xml tooling. this will ultimately allow us to
emit the nixos manual in other formats as well, e.g. html, without going
through docbook at all.
alternatives to this source layout were also considered:
a parallel structure using e.g. toml files that describe the document
tree and links to each part is possible, but much more complicated to
implement than the solution chosen here and makes it harder to follow
which files have what substructure. it also makes it much harder to
include a substructure in the middle of a file.
much the same goes for command-line arguments to the converter, only
that command-lined arguments are even harder to specify correctly and
cannot be reasonably pulled together from many places without involving
another layer of tooling. cli arguments would also mean that the manual
structure would be fixed in default.nix, which is also not ideal.
this is a lot easier than adding footnote support for just the one
instance. if a use case for footnotes appears in the future (e.g. if we
wanted to render the nixpkgs manual with nixos-render-docs as well) this
decision should be reevaluated.
Document the `linux.override` way first, then `linuxManualConfig`.
Add a `linux.configEnv` passthru attribute for quickly getting a
`make nconfig`-ready shell.
I'm well aware that this issue is currently under discussion[1] and that
these things may change. Also, please don't misinterpret this as an
attempt to end the discussion.
This topic made it obvious that people are surprised by the way this
issue is handled and only finding out about this unwritten rule because
of asking is not a good state IMHO, so I decided to document the
following things:
* Right now we drop kernels as soon as they get out of maintenance (LTS
kernels even before the next stable NixOS that will exceed their
lifespan).
* The `latestCompatibleLinuxPackages` attribute from ZFS isn't
monotonic since latest only refers to the latest supported kernel.
* In fact `latestCompatibleLinuxPackages` doesn't seem to be documented
at all in the manual, so I also did that.
[1] https://discourse.nixos.org/t/aggressive-kernel-removal-on-eol-in-nixos/23097
