1. 12

    Seems that CentOS just lost the only reason people used it - being a free RHEL clone :)

    Now people that used CentOS will move either to Oracle Linux (same clone as CentOS just with Oracle logo) or to Ubuntu Linux LTS.

    Of course after FreeBSD adopted quite a lot Systemd Refugees it will as well welcome the CentOS Refugees :)

    1. 5

      Now people that used CentOS will move either to Oracle Linux (same clone as CentOS just with Oracle logo) or to Ubuntu Linux LTS.

      Well, maybe.

      At work we use CentOS because some of our our customers use RHEL, and it lets us do cheap CI and testing, with a final round on RHEL before release.

      On the other hand, we’re still using versions 6 and 7, so this won’t affect us for a while…

      1. 3

        Most CentOS users will wait for other to pickup from where CentOS left or move to OpenSUSE leap

        1. 2

          Oh, I remember this comment from Twitter. As I said there, it’s reductive to say that the only reason people used CentOS is because it’s a free RHEL clone. I use CentOS because it is RHEL-like and has a longer lifespan than Fedora. I use it at home on some systems and to run a server for my blog and other projects.

          Also, as I said there, it’s sad when people promote an open source project at the expense of others. I don’t know what your position is with FreeBSD but I hope the larger project has more empathy and general decorum. If your only selling points are “we don’t use systemd” then that’s not so hot. What’s the positive reason I’d want to adopt FreeBSD?

          • Disclaimer - I work for Red Hat. I’m in comms these days, though, and was not involved in this decision in any way. Overall I don’t think it’s nearly as bad for most users as is being made out, and for companies that are depending on a free clone for their production environments… “I hope a public company will indefinitely supply a part of my infrastructure at no cost” is not a plan I’d feel confident in.
          1. 2

            As I said there, it’s reductive to say that the only reason people used CentOS is because it’s a free RHEL clone. I use CentOS because it is RHEL-like and has a longer lifespan than Fedora.

            That reads very much like “People don’t only use CentOS because it’s a free RHEL clone, but I only use CentOS because it’s a free RHEL clone.” to me?

            1. 2

              I guess you can come to that conclusion if you squint hard and ignore the context of the discussion. My emphasis here is on the clone part. The chief complaint seems to be “CentOS won’t be almost exactly a package-for-package, version-for-version clone of RHEL anymore, it will be slightly different!”

              For my purposes that doesn’t really matter. It’s not like Stream is going to be so radically different from RHEL that what I know about working with RHEL won’t transfer, nor am I depending on it to be “identical” to RHEL. A RHEL-like OS that may have slightly newer packages that aren’t quite as well tested as RHEL is likely going to work just fine for my use case. I’m not trying to run certified software on CentOS rather than paying for a RHEL subscription. I just want a reasonably stable OS for light usage – if it were a production server that mattered for a business, I’d look at paying for a subscription.

              But I don’t want to, say, learn FreeBSD just to host my personal blog. I don’t want to worry about upgrading every year or so, so Fedora isn’t a good fit. It’s fine on my desktop, I want the latest GNOME and so forth - so I don’t mind upgrading once every six to 12 months. But for my web site and personal servers at home, that’s too often. I could use Debian or Ubuntu, but if I use an Fedora/RHEL-type OS in other situations, I might as well preserve my muscle memory for working with my other systems.

              I might be projecting, but I suspect a lot of folks are like me and have used CentOS for non-production uses because we know RHEL and it’s an easy drop-in for a lot of uses for a Linux OS. For a wide swath of use cases, it seems to me that it’ll do just fine.

              1. 1

                I don’t think your use case is so far off. A lot of people have been using CentOS as “a free, redhat-like distro”, which is 100% not a bad thing for private use (I am not opening the can of worms that is paying for RHEL or SLES).

                As per my other comment, I’ve hardly heard of people using Fedora for servers. Might be my debian-centric filter bubble though.

                For example we at work use it to build stuff that will run on customers’ server with RHEL (not certified, or our userspace daemons don’t matter) - and I think this is perfectly fine. We kinda NEED to build on this, but we’re not running it on RHEL, if someone would need to pay for a development license of this, then it’s the customer, not us. So we’re on CentOS 7 which will be fine until 2024, but no idea what will then happen.

                1. 2

                  My understanding is that Red Hat is planning to expand the no-cost RHEL plans to cover things like CI/CD (which you could do now with UBI if you have a container use case, but not for some other use cases). It’s not ready today, but my understanding is that we are planning to expand the no-cost subscriptions to cover some of the other CentOS use cases.

              2. 1

                Your perspective sounds valid for someone not having used Red Hat (without the Enterprise) Linux in the past.

                I can’t put my finger on it, maybe it’s simply “server vs desktop” but CentOS always seemed like a full “Red Hat Linux, as in 5.x 6x, 20y ago” replacement to me and Fedora did not.

                So it’s not really about being “free”, it’s about still using that thing. (I’m in the Debian/Ubuntu camp, thus my lack of real knowledge about Fedora)

                1. 1

                  Was this meant to be a reply to the parent comment? Because I don’t feel like it really relates to what I said. :)

                  1. 1

                    Actually it was meant for you, re: what you answered to jzb, because I didn’t see the focus on a “free RHEL”.

                    If I arrived at the distro scene today I’d see CentOS as a free RHEL - but my point was that if I want a server that my goal wouldn’t be “I need a free RHEL” but more “I want something that uses RPM and I don’t see Fedora as a server distro”. RHEL-compat is not important and a distro being free is more the norm than the exception.

                    But maybe I completely missed your point there.

          1. 20

            I thought most of the point of CentOS was “RHEL, but basically free”. If it’s going to be “what RHEL will be in the future”, then a lot of the value proposition goes away. Why not Fedora at that point?

            1. 7

              My interpretation is that this will be a new stepping stone for changes coming from Fedora before making their way into RHEL. Nevertheless that too doesn’t sound differentiated enough to be sustainable.

              1. 6

                While the Stream lifecycle is shorter than CentOS Linux, it is still 5 years. Stream will still keep the same kernel + rh patches for the full lifecycle, so very different from Fedora model. Stream will be a rolling release for the next minor release of RHEL.

                1. 2

                  Actually CentOS patches will go to rhel

                2. 5

                  According to the Stream page it’s intended to be “positioned as a midstream between Fedora Linux and RHEL”.

                  CentOS started out as an independent community project, but since 2014 it’s effectively been part of Red Hat, which owns the trademark and employs most of its developers. From Red Hat’s point of view all of this makes a lot of sense (Red Hat’s acquisition by IBM probably pays a part in this shift). But for people like you and me who want a “free RHEL” … yeah, it’s not a great change.

                  1. 2

                    Free doesn’t pay IBM nothing. They get with this a rolling beta release where they iron out bugs. The CentOS users get…well they get nothing. Maybe Scientific Linux or FreeBSD like other commenters suggested.

                    1. 6

                      FreeBSD is essentially a “rolling release” distro; it’s a fine system but not really a replacement for CentOS’ use case.

                      1. 6

                        That’s not quite true. FreeBSD is at either extreme, depending on what you’re looking at:

                        The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think). Anything written targeting these is guaranteed to keep working and get security updates for new versions. You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y. Any device ioctl from the base system will keep working in the same way. Anything written using control interface (e.g. the the network configuration interfaces used by ifconfig and friends) has the same guarantees. Between major releases:

                        • All syscalls will keep working via COMPAT interfaces in the kernel (which may optionally be compiled out for small / legacy-free systems).
                        • Control interfaces and device ioctls may change in any way.
                        • Core base system libraries will usually have symbol versioning and so will support old versions. Where there’s a complete ABI break, there’s a userspace compat package that installs the old version, though this may not get security updates.

                        The ports system, which contains all third-party software, is rolling release. If you depend on something like ffmpeg or Qt and want to avoid new versions then you need to either maintain a separate install of the version that you depend on (which is quite easy to do with a fork of the ports tree and configuring poudriere with a different LOCALBASE for all of your fixed-version things), bundle it with your program, or persuade the port maintainer to support multiple versions (a few things do this anyway. I think there are typically 3-4 versions of LLVM in the tree because a bunch of things depend on older ones).

                        In my experience, it’s pretty rare for software to break across even FreeBSD major version upgrades, unless it uses some third-party shiny buzzwordy dependency from ports that doesn’t provide any backwards compatibility guarantees.

                        1. 7

                          The base system, which includes the kernel, libc, and a bunch of core libraries and tools, is ABI-stable across an entire major release (supported for 4-5 years, I think).

                          CentOS is supported for ~10 years, if I’ve understood everything correctly. You also get SELinux and a bunch of other features that are nice for different reasons.

                          FreeBSD is nice in many, many ways, but it is not a replacement for CentOS.

                          1. 3

                            If you need SELinux on FreeBSD then you have MAC (Mandatory Access Control) and also a SEBSD module:

                            You also have other security mechanisms on FreeBSD like Capsicum.

                            1. 1

                              Didn’t know about MAC, cool! Not sure how I’ve missed it :-)

                              One nice thing with SELinux is that it’s included and enabled by default, not kernel patches et c to apply.

                            2. 1

                              Is that still the case?

                            3. 4

                              FreeBSD can be rolling release when you track STABLE or CURRENT and can also NOT be rolling release if you just use RELEASE version.

                              1. 1

                                Yes, but ports/pkg is always a rolling (or semi-rolling if you go with quarterly updates) which differs greatly from the CentOS way of doing it. I’m not saying it’s good or bad, it’s just different.

                                1. 1

                                  With CentOS/Red Hat approach you end up with very outdated packages very quickly.

                                  With FreeBSD approach you always have up-to-date packages.

                                  You can also use Poudriere to create and maintain your own packages versions: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-poudriere-build-system-to-create-packages-for-your-freebsd-servers

                                  1. 2

                                    With CentOS/Red Hat approach you end up with very outdated packages very quickly.

                                    Yes, agreed. But you get security updates for them as well.

                                    With FreeBSD approach you always have up-to-date packages.

                                    Yes, and that can be a problem in itself. Imagine that you can’t upgrade to a newer version due to breaking changes, but a new security vulnerability pops up. What do you do?

                                    I work in jurassic operations, it’s terrible and everything we run on is far too old. But we are not a developing organisation, we barely know anything about anything right now. Organisations like mine will always chose CentOS/similar if we get support for it, and we are willing to pay stupid amounts of money.

                                    I used to work in software development as a tester. But not even in a team with virtually no technical backlog (like really!) would we ever chose to use a rolling distribution. That is just wasted work, effort, and money. Imagine trying to reasonably test supported versions for your app if using a rolling distribution.

                              2. 1

                                You can write a kernel module for FreeBSD X.0 and it will keep working for all FreeBSD X.y

                                Only if you recompile. There is NO stable kernel ABI. Currently on 12.2 people must compile the GPU drivers locally, because the binary package is produced on 12.0 or 1 or whatever and it does not work.

                                1. 3

                                  I believe the GPU drivers are something of a special case here: They depend on the LinuxKPI module, which does not have the same stability guarantees as the rest of the kernel because it tracks Linux kernel interfaces that can change every minor release of the Linux kernel. For the rest of the kernel, they are much stronger binary-compat guarantees. There’s a process before branching each major release of adding padding fields to a bunch of kernel structures so that anticipated functionality can be added without breaking the KBI. This is the reason that a lot of Adrian’s work on WiFi didn’t get MFC’d: it depended on adding extra fields to structures at various places in the WiFi stack, which would have been KBI-breaking changes and so were not allowed into -STABLE without rewriting.

                              3. 1

                                I know, I’m just saying that people who habe been using CentOS because “it’s redhat but free” might want to move to sometging else. People who needed CentOS for ABI compatibility will have to work with IBM/Redhat on this. Because RedHat doesn’t want to work for free, obviously.

                          1. 2

                            I’d like an OS that can run a container or a VM (running itself or any other OS) as a simple kernel module. Actually, that idea is not new, L4 implements something like that. Of course, if a module crashes, the OS would handle it gracefully.

                            I don’t know if it’s feasible (outside academic research), but the idea seems elegant.

                            It’d be nice to also provide native primitives towards Rob Pike’s dream as well:

                            I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else’s problem, one I’m happy to pay to have them solve. Also, storage on one machine means that machine is different from another machine.

                            1. 1

                              I think OS should be ISC licensed. Must have features like reproducible, rump kernels, preferred language : ada , nim ,

                              But most things I like about an OS is already in NetBSD so I want similar features.

                              1. 3

                                OS108 is a fast, open and Secure Desktop Operating System built on top of NetBSD

                                https://os108.org/

                                Nowhere in the forum post is there an introduction or a link to “find out more”. Took me a few clicks to figure out what os108 was…

                                1. 1

                                  Oh. Should have also linked homepage link to forum :P

                                1. 2

                                  Why not PKGSRC?

                                  1. 2

                                    Pkgsrc is great, but Nix has a stronger emphasis on reproducibility and immutable state.

                                    1. 1

                                      Got it. I will try it out in VM.

                                  1. 15

                                    Considering how Linux-centric Wayland is (the devs seem to not care about anything else), I don’t think we’re about ready to drop Xorg.

                                    1. 36

                                      I’m the Wayland maintainer and I care about BSD. Some other Wayland-related projects (including Sway, wlroots for instance) have FreeBSD continuous integration. Edit: also the Hikari compositor has been designed on BSD. The only reason BSD patches aren’t upstream is that we haven’t figured out a good way to setup BSD CI on gitlab.freedesktop.org.

                                      1. 10

                                        I’m the Wayland maintainer and I care about BSD

                                        Thank you.

                                        1. 4

                                          I am not a FreeBSD maintainer and I haven’t used FreeBSD since 2012.

                                          I am curious though, what is the problem? Do you need someone to setup the pipeline, money or something else?

                                          1. 12

                                            The issue I’m facing is that gitlab.freedesktop.org uses Linux containers for CI, so we need to spin up a FreeBSD VM in the container to build Wayland and run the unit tests (making sure a commit doesn’t regress FreeBSD support). However official FreeBSD VM images don’t come with SSH enabled by default, and we have no way to edit the image filesystem to do this (UFS being read-only on Linux). Serial console is also disabled by default IIRC (and isn’t great anyways). We’d also prefer not to rely on custom images generated and hosted by an unofficial party (what should we do if it goes offline? what about updates/fixes?).

                                            There has been some WIP work on the FreeBSD infra side which may make SSH enabled by default, but someone still needs to wire it up to the CI image templates used on gitlab.freedesktop.org.

                                            If someone wants to pick that up and move this forward: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/3#note_563739

                                            I’ll gladly review any patches!

                                            EDIT: just thinking about it now, but the recent work to make FreeBSD buildable from Linux may ease the process.

                                            1. 3

                                              I think with NetBSD you can do testings http://www.gson.org/netbsd/anita/

                                              1. 2

                                                Interesting, thanks for the link!

                                            2. 3

                                              NetBSD lacks funds to do patching them selves still few contributors working on it : https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and

                                            3. 1

                                              I don’t know if this helps, but sr.ht has CI for the BSDs.

                                              Is OpenBSD on the roadmap?

                                              1. 4

                                                Yeah, I’m aware of sr.ht, in fact I’m an employee :P

                                                The main pain point is that GitLab doesn’t support well integration with third-party Ci services 1. Another concern expressed by some Wayland developers is the dependency on a third-party service.

                                                OpenBSD shouldn’t be too hard to add once FreeBSD is sorted out, I hope.

                                          1. 3

                                            That list is incomplete. It only shows committers associated with a GH account.

                                            1. 2

                                              Agreed. Wish it showed non linked using just nicknames, or email usernames.

                                              1. 6

                                                Incidentally, today I worked a bit on a tool to get author statistics on any git repo. It’s not quite ready, so no source yet, but here are the top authors (everyone with more than 2k commits) and the range during which they were active:

                                                282,220 commits by 453 authors from Jul 1992 to Oct 2020
                                                
                                                26,159  9%      Oct 1994–Oct 2020       christos <christos@NetBSD.org>
                                                12,844  5%      Jun 1995–Oct 2020       thorpej <thorpej@NetBSD.org>
                                                10,036  4%      Jan 2000–Oct 2020       wiz <wiz@NetBSD.org>
                                                8,786   3%      Apr 1993–Mar 2005       mycroft <mycroft@NetBSD.org>
                                                7,896   3%      Jul 1992–Oct 2020       mrg <mrg@NetBSD.org>
                                                7,286   3%      Jul 1997–Nov 2017       matt <matt@NetBSD.org>
                                                6,405   2%      Mar 1993–Mar 2005       cgd <cgd@NetBSD.org>
                                                6,283   2%      Dec 1999–May 2016       pooka <pooka@NetBSD.org>
                                                6,091   2%      Oct 1996–Aug 2020       lukem <lukem@NetBSD.org>
                                                5,324   2%      Dec 1999–Oct 2020       tsutsui <tsutsui@NetBSD.org>
                                                5,220   2%      Dec 2001–Oct 2020       jmcneill <jmcneill@NetBSD.org>
                                                4,662   2%      Jul 2000–Oct 2020       skrll <skrll@NetBSD.org>
                                                4,492   2%      Jun 1999–Mar 2006       itojun <itojun@NetBSD.org>
                                                4,435   2%      Mar 2000–Oct 2020       martin <martin@NetBSD.org>
                                                4,182   1%      Sep 2005–Jun 2020       joerg <joerg@NetBSD.org>
                                                3,928   1%      Mar 1999–Jun 2020       ad <ad@NetBSD.org>
                                                3,785   1%      Jul 1993–Feb 2005       pk <pk@NetBSD.org>
                                                3,706   1%      Jul 1999–Sep 2020       jdolecek <jdolecek@NetBSD.org>
                                                3,442   1%      Jun 2001–Apr 2015       yamt <yamt@NetBSD.org>
                                                3,388   1%      Nov 1997–Oct 2020       msaitoh <msaitoh@NetBSD.org>
                                                3,246   1%      Apr 1997–Mar 2006       augustss <augustss@NetBSD.org>
                                                3,125   1%      May 2011–Oct 2020       riastradh <riastradh@NetBSD.org>
                                                2,955   1%      Nov 1997–Oct 2020       simonb <simonb@NetBSD.org>
                                                2,798   1%      Jun 1997–Jun 2014       drochner <drochner@NetBSD.org>
                                                2,767   1%      Feb 2014–Sep 2020       maxv <maxv@NetBSD.org>
                                                2,638   1%      Oct 2002–Nov 2019       dyoung <dyoung@NetBSD.org>
                                                2,410   1%      Apr 1997–May 2014       kleink <kleink@NetBSD.org>
                                                2,389   1%      Jun 1997–Sep 2020       bouyer <bouyer@NetBSD.org>
                                                2,355   1%      Nov 2007–Oct 2020       dholland <dholland@NetBSD.org>
                                                2,106   1%      Jan 2003–Jun 2014       dsl <dsl@NetBSD.org>
                                                2,094   1%      May 2005–Oct 2020       macallan <macallan@NetBSD.org>
                                                2,091   1%      May 2001–Oct 2020       uwe <uwe@NetBSD.org>
                                                2,063   1%      Jun 1993–Mar 1998       jtc <jtc@NetBSD.org>
                                                2,029   1%      Feb 1995–Aug 2008       fvdl <fvdl@NetBSD.org>
                                                

                                                I don’t think this is quite accurate either, since people submitting patches to the mailing list and such will probably have the author set to whoever applied it. I see some occasional references to “patch from somesuch@example.com” in some commit messages, but it’s not very structured. I don’t think CVS records committer and author separately, so this is probably the best you’ll be able to get without trying to grep the actual authors out of the commit messages with some heuristic.

                                                The activity range is also a bit misleading, as some people went away for 10 years and then came back, and one author has almost 900 commits in a month (the HTML version shows this in a chart, but that’s not ready yet). Besides, “number of commits” is of course only a rough indication of actual useful contributions in the first place, but it’s more or less the best you can get with an automated tool.

                                                The full list is here: https://gist.github.com/arp242/ea24e64943622ea0678de9f77c11f53f

                                                Just the metadata without the actual file contents (git clone --filter=blob:none) is 441M by the way. For comparison, Linux is 1.2G (and that only goes back to 2005, as history before that isn’t in git).

                                                1. 2

                                                  Cool :)

                                            1. 1

                                              I’ve always wanted to try NixOS, but I don’t want to taint my computer with systemd.

                                              I’ll try it whenever somebody forks it and removes the systemd dependency or they release a systemd-free version.

                                              /shrug

                                              1. 5

                                                I don’t think that will happen, as NixOS uses several good features from systemd. You can also just try Nix, for handling packages and dependencies for your projects.

                                                1. 8

                                                  There was a talk at NixCon about abstracting out services in NixOS:

                                                  https://cfp.nixcon.org/nixcon2020/talk/TW79FU/

                                                  Allowing us to reuse the service configuration for launchd on macOS or various alternatives like supervisord.

                                                  1. 1

                                                    I might try the Nix sometime. But for now it looks like I can safely cross NixOS off the list of distros to try.

                                                    1. 17

                                                      If blind hatred of systemd here is what is holding you back, maybe try broadening your horizons a bit.

                                                      NixOS uses it to good effect.

                                                      1. 5

                                                        Did you really just assume that my hatred of systemd is blind?

                                                        That I, in no way, have a rational disgust for this software?

                                                        systemd is a horrible piece of software for many reasons:

                                                        1. The undeniable feature creep. While some people actually enjoy the features brought in from it (boot manager, network manager, login manager, home manager, etc), I find them to be nothing but bloat. An init system should be just that. An init system. Not <insert an exaggerated amount of functions here>.

                                                        2. It is slow. Slow to shutdown, slow to boot up, etc. Here are actual timed reboots from my machine using 3 init systems. systemd (2m3s), OpenRC (11s), Runit (7s). 2m3s vs 7s, which would you choose?

                                                        3. Due to the feature creep, there is a larger attack service for bugs and security vulnerabilities. And there are security issues with systemd.

                                                        4. This is the one that bothers me the most. It’s almost as if the dev(s) are completely oblivious or at least ignorant to the feature creep and security issues.

                                                        5. A lot of the time, we don’t even get the choice to not use systemd. There a lot of packages (and the list grows every day) of packages with a hard dependency of systemd, So unless you modify that program yourself, you literally won’t be able to use it unless you succumb to using systemd.

                                                        6. There are privacy issues with it. For example the hardcoding of Google’s DNS. “It’s a fallback”, that’s no excuse. At some point someone will be using that and their privacy will be ruined.

                                                        Now, some of these you could call nitpicks (like the reboot times). However I find issues 1, 4, 5, and 6 just unacceptable. Those are what absolutely keep me from using it.


                                                        This is my abridged list of issues, but I can make an even larger wall of text if you want me to.


                                                        And I really don’t appreciate your tone. You sound very stuck up and pretentious telling me to “broaden my horizons”.

                                                        On top of the fact that you just assumed that I had no reason to hate systemd. Honestly.

                                                        All you had to do was ask, “hey, may I know what about systemd you hate? why is it bad?”.

                                                        But no, you decide to insult me with your stupid response.

                                                        1. 10

                                                          You don’t have to use it forever, or even agree with its implementation! You don’t have to trash your daily driver!

                                                          But my dude, not even giving it a shot because of your issues with systemd (quite aside from whether or not those are valid, which I mostly think they are…I rather despise it for other reasons) is cutting off the nose to spite the face–especially since you also don’t want to try Guix.

                                                          I meant broadening your horizons in the literal sense: there is some really interesting stuff happening in those ecosystems, and even a brief foray into them may be really useful and neat–or it might not. But, like, if you refuse to even try because of NixOS’s use of systemd, you’re letting those developers harm you twice.

                                                          1. 4

                                                            I apologize for my rudeness. At the time I had literally just woken up, haven’t had any coffee or cigarettes, and the first thing I saw was someone telling me that I have a blind hatred and that I need to broaden my horizons.

                                                            Surely you can admit that from my perspective, that would be at least a little irritating.

                                                            I can agree with what you’re saying, but personally I can’t do it. Using an OS which uses systemd would be justifying it. And I can’t allow that. That would be hypocritical and unjust.

                                                            “Be the change you want to see”: By refusing to use anything with systemd, I as an individual am giving less power to it and it’s devs.

                                                            1. 2

                                                              No sweat–I probably could’ve found a gentler phrasing than “broaden your horizons”. My apologies!

                                                  2. 3

                                                    You can use Nix and nix packages without systemd… nix is a package management system, and does not itself run any services.

                                                    1. 1

                                                      I was mainly interested in the OS, not the package manager.

                                                      But at some point I plan on trying Nix. If I like it enough, I might run NixOS in a VM.

                                                    2. 3

                                                      What about Guix?

                                                      1. 2

                                                        No thank you. Guix is a rant for another time, but trust me when I say I hold a disain for it.

                                                        1. 7

                                                          I’d like to hear that rant some time, out of curiosity.

                                                          1. 2

                                                            I second this, even just a rought draft would do.

                                                            1. 1

                                                              Seconded. This person seems to have interesting opinions.

                                                              1. 1

                                                                Maybe sometime.

                                                                When I rant, it messes my whole day up. I’m still seething about the “blind hatred of systemd” thing.

                                                          2. 1

                                                            You can use systemD free version PKGSRC

                                                            1. 9

                                                              pkgsrc completely lacks the desired-state, functional language, and system management components of nix. It’s an apples and oranges comparison.

                                                              1. 1

                                                                Can you demonstrate how I can install multiple different versions of the same package without breaking the system install via pkgsrc?

                                                                As well as defining everything in a declarative way? I already use the “systemd free version” known as macos nix package manager. And I can do the same on any linux.

                                                                Also will need a way to do things like nix overlays which let me add custom patches to package builds.

                                                                Drive by comments like this without explaining how PKGSRC replaces or can be an alternative aren’t very useful. And as a note, I’ve set a super high bar for PKGSRC here but thats due to I get all of the above (and more) for free from the nix package manager. Nixos adds some more neat bits but ultimately its all on top of nix.

                                                            1. 3

                                                              Similar fate as Plan9/9front

                                                              1. 3

                                                                Playing around nim and ada. Getting Ada’s tools to work on NetBSD seems impossible for now.

                                                                1. 3

                                                                  Why not ada or nim?

                                                                  1. 2

                                                                    Or Pony

                                                                  1. 1

                                                                    it needs to run Windows applications. You’ll need to reconfigure NetBSD to allow this abuse, because by default NetBSD is fairly strict.

                                                                    Running NetBSD 10 or -current? Then you don’t need to do this.

                                                                    Does this mean that NetBSD 10 and newer is less strict? Or did they manage to find some alternative to the user LDT setting?

                                                                    1. 1

                                                                      Hi it means configuration to kernel needed to run wine will be turned on in Generic kernel