These take up 2 GiB every time anything in the minimal installer
changes, or up to 4 GiB per day. We already stopped building Amazon
images in 9426d90c67. Meaningful
installer changes are rare enough, and the couple of days it takes
for them to trickle down to the large channel acceptable enough,
that this is mostly a waste of space.
This should buy enough slack to build `stdenv` on `staging` without
contributing to cache size growth.
The Rust `switch-to-configuration-ng` rewrite was carefully written
to be compatible with the original Perl script, has been checked
against NixOS VM tests, and has been available on an opt‐in basis
for testing for the 24.05 release cycle.
The next step towards replacing the Perl script entirely is to
switch it on by default so that we can get real‐world testing from
a much greater number of users. Maintaining two implementations in
parallel is becoming a burden; we are having to adjust the systemd
service activation behaviour slightly to fix a long‐standing bug,
and backporting the changes to the Perl script is an unpleasant
process. We will do it anyway to ensure that the Rust and Perl
implementations keep parity with each other throughout the 24.11
release cycle, but we think the time has come to flip the switch.
Taking this step now will give us two to three months to test this in
the wild before the 24.11 release and gain confidence that there are
no regressions. If any non‐trivial problems arise before the final
release, we will revert to the Perl implementation by default. Doing
this switch ASAP will help to disentangle any problems that might
arise from the Rust implementation from problems that arise from the
systemd service activation changes, or the upcoming switch to using
systemd in stage 1 by default.
The main concern that was raised about replacing the Perl script in the
PR that added `switch-to-configuration-ng` was that it is currently
possible to run NixOS on systems that cannot natively host a Rust
compiler. This does not apply to any platforms that have official
support from NixOS, and as far as I know we do not know of any such
systems with users that are not cross‐compiling anyway.
My understanding is that these systems are already broken by default
anyway, as `systemd.shutdownRamfs.enable` is on by default and uses
`make-initrd-ng`, which is also written in Rust. Switching the default
while keeping the Perl implementation around will give us at least
an entire release cycle to find out if there are any users that will
be affected by this and decide what to do about it if so.
There is currently one known inconsistency between
the Perl and Rust implementations, as documented in
<https://github.com/NixOS/nixpkgs/issues/312297>; the Rust
implementation has more accurate handling of failed systemd units.
We slightly adjust the semantics of `system.switch.enable{,Ng}` to
not conflict with each other, so that `system.switch.enableNg` is
on by default, but turning off `system.switch.enable` still results
in no `switch-to-configuration` implementation being used. This
won’t break the configuration of anyone who already opted in to
`system.switch.enableNg` and is probably how the option should have
worked to begin with.
ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
Exposes all currently available command-line arguments that were
missing, including some that were impossible to use with the catch-all
option `extraArgs` alone, requiring changes to other parts of the
system.
Those are now all self-contained in the module.
The service now uses systemd's `DynamicUsers`.
With mautrix-signal v0.7.0 the bridge is built upon the bridgev2
architecture. With this, the configuration file was slightly rearranged.
Options like login_shared_secret_map and double_puppet_server_map were
dropped.
2.3.0 is the final release, the repo is now archived.
Also I don't use it anymore for quite a while, so it didn't have a real
nixpkgs maintainer either.
Closes#338712
For a long time now, the SDK and minimum target version for
`x86_64-darwin` has been stuck on macOS 10.12. In the past, the minimum
SDK was updated quite regularly; at first, the current situation was
just because updating the SDKs was excessively burdensome and nobody
was up for doing the work, but the introduction of `aarch64-darwin`
with its macOS 11 default SDK has resulted in a long‐term fracture
of the two platforms.
Per <https://endoflife.date/macos>, macOS 10.12 has not received
an update since 2017 and went out of security support 5 years
ago. Trying to support it in Nixpkgs has been a large burden on the
Darwin maintainers, resulting in workarounds, porting work, and even
patching functionality out of applications. The existence of Nix
users using a macOS version this old is, to my knowledge, entirely
theoretical, and we pay in both maintenance costs and functionality:
for instance, applications built for `x86_64-darwin` do not support
automatic dark mode switching by default.
This situation has always been suboptimal, but it is
now becoming untenable. Python, a critical component
of the Nixpkgs standard environment for builds, is
dropping support for versions older than 10.13 in 3.13:
<https://www.python.org/downloads/release/python-3130rc1/>. Qt 6 only
supports macOS 11 and newer. libuv only supports the versions Apple
does, and is a ticking time bomb due to its use in the standard
environment. QEMU only supports the last two macOS releases, and
won’t build with an SDK older than macOS 12; we previously vendored
a set of backporting changes and functionality‐removing reverts
to keep it building for 10.12, but this also became overly onerous,
and we gave up in <https://github.com/NixOS/nixpkgs/pull/338598>.
`x86_64-darwin` is a platform with a limited upstream future. Apple no
longer sells any hardware that runs it natively, and it is unclear how
much longer they will support it in the operating system. There are
still many users of the platform, myself included, so we shouldn’t
drop support for it prematurely, but it’s unreasonable to try and
patch the entire world to keep it supporting insecure versions of
the OS that only run on hardware that is no longer sold.
Therefore, this adds a release note to warn users ahead of time that
25.05 will only support macOS 11 and newer, as suggested by the 24.05
release team when the possibility of bumping the required version
was raised.
Why target Big Sur, rather than any other version? The
reason is simple: it’s the same SDK and deployment target as
`aarch64-darwin`. There are many packages that work on `aarch64-darwin`
but not `x86_64-darwin`, and Darwin maintainers frequently need to be
called in to fix things that work fine on the newer platform but not
the older one. This change will increase the health of `x86_64-darwin`
by aligning the SDK versions and support between the two platforms;
the vast majority of packages that work on one will Just Work on the
other. macOS 11 is almost four years old and has itself been out of
security support for a year now, but as the first version to support
Apple Silicon, it’s a far more compatible base for us to build our
Darwin packages for. Any future change in supported versions should
be synchronized between the two Darwin architectures.
When 25.05 is released, users on old, unsupported versions of macOS
will have the following options:
* Update to a new macOS version. For users that are on hardware
that Apple has dropped support for, OpenCore Legacy Patcher
(<https://dortania.github.io/OpenCore-Legacy-Patcher/>) can enable
the use of newer macOS versions on hardware even older than 10.12
supports.
* Install NixOS. That obviously precludes the use of macOS software
(though most of that software has already dropped support for 10.12),
but will give users a secure, supported operating system that we
can actually own the support for going forward.
* Keep using 24.11 forever. Since they’re not getting updates
to their OS and core applications anyway, this is likely to be
acceptable to many users.
* Switch to MacPorts. They support all the way back to 10.6 for
`x86_64-darwin` by building packages separately for every OS release,
though not every package is available for every version.
* Send patches. We *may* accept non‐invasive patches to keep
certain critical packages (such as the core `stdenv` packages)
building for old OS versions, on a case‐by‐case basis, but we
can’t guarantee it. This will ultimately have to be a decision
made by package maintainers and personally I doubt this will be a
viable path to sustainably support older versions.
