Suggested Linux distro for Nerves development?

I did recommend Debian/Ubuntu as a first distribution and both use systemd, so in principle we’re in agreement. I think there are a lot of reasons to choose a distribution (rolling vs point, package manager, size of repos, patches, foss stance, 3rd party support, etc), but wouldn’t include init system.

My point was that there are a lot of good reasons to not use Arch / Void / Alpine, but I wouldn’t disqualify any of them based on init system. At this point, I wouldn’t go out of my way to avoid or to use systemd.

My issue isn’t that it is a single tool or not. It is that the functionality that it replaces wasn’t there. Aka - setting up bonded+bridged+vlans or split-dns or whatever thing I was trying to do at the time. So the systemd ecosystem decided to replace something for whatever reason, but either it was adopted by distros too early or the functionality was never completed. Not sure which one.

These issues I ran into have been reported which is why I knew the workaround was not to use systemd-network or systemd-resolved. Not really sure about maintainers. It’s the internet so it all seems like drama. I haven’t met any of these people, so I wouldn’t know. All I can comment on is the technical aspects of the software.

How so? The amount of times an init system should break is zero.

In the past two weeks, for me, systemd has been involved in

  • breaking networking on a router by renaming eth0
  • an RCE/backdoor with ssh thru xz

So I count that as two breakages. Definitely, greater than zero. :rofl:

And then there’s all the times I’ve had to work around the non-init functionality in the past, which I doubt most people would run into. I’m guessing this is why you may feel that it is stable.

Eh, you are stretching the definition of an init system, come on now. :smiley: The xz fiasco was a social failure, the maintainer got pressured into allowing a malicious maintainer. Nothing to do with systemd.

As for the network interface problem, I agree this shouldn’t have happened. They really should look into it because it’s inexcusable.

Not my goal to change your mind, I wanted to show another perspective so the discussion is not one-sided. You prioritize one thing, I – another. :person_shrugging:

Fair, I don’t disagree per se. It’s just that my experience tells me that declarative instructions > code itself. It’s the future of software (unless AI eats everything in the meantime) and that’s why I am standing behind systemd and other declarative tools.

Another thing I can give you as an example is Makefile-s. You don’t tell it how to do its stuff. You describe tasks, sources and destinations and their relations, then you tell it “make me X or Y” and it figures out how to do it. That’s how software should be and I am sad this is still not the current state of affairs.

I wrote a thousand clever scripts in my 22 years of career and most found a way to break subtly. I am honestly sick of shell scripting and started migrating some of them to Golang. It too has footguns but compared to bash / zsh scripts it’s like comparing a sealed vacuum chamber vs. Swiss cheese.

But that’s a different topic. As I age I really want to see some progress in our area and I am taking it upon myself to do it. Might open-source a collection of scripts aimed at complete system backups at one point, if there’s even a need for such a thing – is one example.

For now. I really do hope the recommendation changes because that’s super defeatist.

1 Like

You’re right, but I’m only stretching it very slightly to make a point. Systemd was the vector by which xz got access to ssh. Here’s the relevant email excerpt:

It was a beautiful attack and if it wasn’t thru systemd, the attacker would have found another vector. However, systemd has become complex enough and touches so many other systems that it is a very interesting attack point.

I don’t think declarative/imperative change too much in the space of init/service supervision?

From the late 1990’s to around 2015 (pre-docker/kubernetes), most of the teams I’ve been on used some variant of a process supervisor to start services. Daemontools, s6-something, runit, supervisord, etc. Sysvinit was for bootup which happened maybe twice / year and just not very relevant.

When systemd came out, there was no longer a need for separate process supervision which is great. But the rest of the systemd ecosystem replacements seem “incomplete” and also provide a nice attack surface. Not sure if I like that tradeoff.

Completely. People should use whatever they want, but it is good for them to know the tradeoffs. I’m not a philosopher. I just need the damn thing to work and stay working.

I don’t use google services because they will change their API’s and it could cost months migrating to whatever new thing. On a smaller level, Ubuntu and Red Hat have their own corporate agenda’s and I have no interest in being a beta tester for whatever half-baked creation they have concocted.

That’s why I think Elixir ecosystem is incredible. :smiling_face_with_three_hearts:

If the Elixir ecosystem kept super-stable like Erlang, I would have been happy. But I’ve been using it in production for 8 years, and in addition to stability, have gotten meaningful improvements to building software with Liveview, etc. and only needed minor changes.

How much software can we really say that about?

1 Like

If it is an option, you may try to install something like VMWare and experiment with several different distributions to see which you prefer. That may be easier than wiping the laptop if you want to make a change. You can always backup to an external and then wipe/install/restore later once you have decided on a longer term preference.

See your point but I’m probably far more hesitant with that approach given the high probability that I’ll be crossing my fingers that I won’t screw things up.

lol This is one of the benefits of a VM. If there is an issue, it is very easy to wipe and replace just that VM without affecting the host or other VMs you’re testing. By comparison, replacing the host OS is often a much more tedious affair.

I’ll look into it. Thanks again for the feedback. Definitely helps me.

1 Like