5 ms·

Migrating Debian to nix might be possible, if that was desirable. You could have a compatibility layer for a while, and once everything is using the compatibili

Migrating Debian to nix might be possible, if that was desirable. You could have a compatibility layer for a while, and once everything is using the compatibility layer (in about 200 decades?), you deprecate the old package management details.

nobodyorother 9y ago
Makes me wonder what adding Guix build support to dpkg (and vice-versa?) would look like, or whether it would even be possible in a coherent way.
k__ 9y ago
I think Nix is the superior package manager, but you can already usw it with Debian for years now and not many people do it, so the problem seems to lie somewhere else...
- vertex-four 9y ago
  Nix doesn't integrate with Debian well - you can also use yum on Debian and nobody does that either. If you're using Debian, it's because you want to manage a Debian system with Debian packages.
  - sds2 9y ago
    Yeah, nix doesn't feel right on debian because it can't manage services and doesn't use the "standard" packaging idioms. Is there someone else with a different experience or a workaround?
  - madez 9y ago
    I use Debian and I do not like to manage the Debian system with Debian packages. I use Debian because it is the community-backed distro.
    - int_19h 9y ago
      A community-backed distro, surely? There's also Arch, and others.
- majewsky 9y ago
  Two things: 1. Too few marketing. I only heard of Nix for the first time last year. 2. When you boot a virtual server, the UI usually offers you Debian, Ubuntu and Centos/RHEL images, sometimes Suse/SLES or Arch. So again, less visibility, and if the hoster does not allow you to bring your own image, it's a pain in the ass to install anything else. 3. (Going off topic for a second: I probably would have switched to Nix(OS) already if it wouldn't entail effectively abandoning the configuration management tool that I maintain.)
  - GlennS 9y ago
    I think the marketing aspect has started to pick up recently. Whether through conscious effort or just word of mouth momentum I don't know.
GlennS 9y ago
I do think that Nix or something like it is the future. Or at least it will be if the tech community as a whole doesn't screw up. But I also really appreciate the massive effort that Debian maintainers make, and the sheer number of those maintainers. Combining whatever human processes Debian have in place to keep that going with Nix would be fantastic. Right now, to use Nix regularly, you really have to be willing to read a lot of Nixpkgs source code. Edit: I should also note that I do actually currently use Nix on top of Debian for my work machine. Servers are all NixOS machines deployed with NixOps though.
nextos 9y ago
It was discussed in the Debian mailing list long ago, when Nix was not so polished [1]. Honestly, I think it's a migration really worth it. Nix (and Guix) are quite mature now. The advantages they bring into the table are massive. The whole Debian ecosystem would become a lot more integrated and robust. It would be possible to develop packages at their own pace, without having to keep all dependencies in sync with the whole package tree. Besides, no more dist-upgrade breaking your whole system. It would look a lot like a rolling release, but with none of its disadvantages. It would be also possible to turn all Debian flavours into little declarative Nix blurbs. There are countless advantages. [1] https://lists.debian.org/debian-devel/2013/02/msg00374.html https://lists.debian.org/debian-devel/2013/02/msg00374.html
- throwaway2048 9y ago
  I think the risk of some software being kept on many versions old, full of security issues libraries is pretty significant, because the major impetus to force an upgrade has gone away, that is it wont even function without updating.
  - flogic 9y ago
    Should this issue be addressed at a technical level or a policy level? No matter how they manage the distro, so stuff is going to come down to policy and process. To me it seems like the sort of thing that should be handled with package audits.
  - Lorkki 9y ago
    The solution might be to keep nix for system software only and have third-party developers deploy snaps or flatpaks. Auditing package dependencies against a list of invalidated hashes should be easy enough.

nobodyorother 9y ago

Makes me wonder what adding Guix build support to dpkg (and vice-versa?) would look like, or whether it would even be possible in a coherent way.

k__ 9y ago

I think Nix is the superior package manager, but you can already usw it with Debian for years now and not many people do it, so the problem seems to lie somewhere else...

vertex-four 9y ago
Nix doesn't integrate with Debian well - you can also use yum on Debian and nobody does that either. If you're using Debian, it's because you want to manage a Debian system with Debian packages.
- sds2 9y ago
  Yeah, nix doesn't feel right on debian because it can't manage services and doesn't use the "standard" packaging idioms. Is there someone else with a different experience or a workaround?
- madez 9y ago
  I use Debian and I do not like to manage the Debian system with Debian packages. I use Debian because it is the community-backed distro.
  - int_19h 9y ago
    A community-backed distro, surely? There's also Arch, and others.
majewsky 9y ago
Two things: 1. Too few marketing. I only heard of Nix for the first time last year. 2. When you boot a virtual server, the UI usually offers you Debian, Ubuntu and Centos/RHEL images, sometimes Suse/SLES or Arch. So again, less visibility, and if the hoster does not allow you to bring your own image, it's a pain in the ass to install anything else. 3. (Going off topic for a second: I probably would have switched to Nix(OS) already if it wouldn't entail effectively abandoning the configuration management tool that I maintain.)
- GlennS 9y ago
  I think the marketing aspect has started to pick up recently. Whether through conscious effort or just word of mouth momentum I don't know.

GlennS 9y ago

I do think that Nix or something like it is the future. Or at least it will be if the tech community as a whole doesn't screw up. But I also really appreciate the massive effort that Debian maintainers make, and the sheer number of those maintainers. Combining whatever human processes Debian have in place to keep that going with Nix would be fantastic. Right now, to use Nix regularly, you really have to be willing to read a lot of Nixpkgs source code. Edit: I should also note that I do actually currently use Nix on top of Debian for my work machine. Servers are all NixOS machines deployed with NixOps though.

nextos 9y ago

It was discussed in the Debian mailing list long ago, when Nix was not so polished [1]. Honestly, I think it's a migration really worth it. Nix (and Guix) are quite mature now. The advantages they bring into the table are massive. The whole Debian ecosystem would become a lot more integrated and robust. It would be possible to develop packages at their own pace, without having to keep all dependencies in sync with the whole package tree. Besides, no more dist-upgrade breaking your whole system. It would look a lot like a rolling release, but with none of its disadvantages. It would be also possible to turn all Debian flavours into little declarative Nix blurbs. There are countless advantages. [1] https://lists.debian.org/debian-devel/2013/02/msg00374.html https://lists.debian.org/debian-devel/2013/02/msg00374.html

throwaway2048 9y ago
I think the risk of some software being kept on many versions old, full of security issues libraries is pretty significant, because the major impetus to force an upgrade has gone away, that is it wont even function without updating.
- flogic 9y ago
  Should this issue be addressed at a technical level or a policy level? No matter how they manage the distro, so stuff is going to come down to policy and process. To me it seems like the sort of thing that should be handled with package audits.
- Lorkki 9y ago
  The solution might be to keep nix for system software only and have third-party developers deploy snaps or flatpaks. Auditing package dependencies against a list of invalidated hashes should be easy enough.