- rename hardware.opengl to hardware.graphics
- remove hardware.opengl.driSupport, which does nothing
- remove hardware.opengl.setLdLibraryPath, which should never be done
- rename hardware.opengl.driSupport32Bit to hardware.graphics.enable32Bit
- lost of small docs / formatting cleanups
I found this while perusing the manual thinking about whether or not to install NixOS on my new laptop. It threw me for a loop for a second but as best I can tell this meant to be ".org" like the rest of the example, and not ".com"
In the initial configuration the enablePHP config option is present. In the following abstracted example the commonConfig doesn't include it anymore.
Previous PRs #88505 and #284906 added the enablePHP config option to the commonConfig. @aanderse commented in https://github.com/NixOS/nixpkgs/pull/88505#issuecomment-632575200 the usage of enablePHP shouldn't be encouraged, `services.phpfpm` should be preferred whenever possible. So we remove the enablePHP config from theses examples.
that NixOS manual section talks a lot about Nixpkgs package
configuration, which really should not be there but rather in the
Nixpkgs manual itself. but this is a rabbit hole for another time.
Co-authored-by: Dominic Mills <dominic.millz27@gmail.com>
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.
