Suggested Linux distro for Nerves development?

[tj0]

@stevensonmt

I think you’re making a technical argument while I’m making a sociological one. My point was simply the state of the Linux ecosystem right now defaults to systemd and therefore a Linux novice will likely find things easier to manage.

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.

@dimitarvp

1. I like having a single tool for these problems. We the techies disperse our energy way too much. IMO it’s time we got our sh1t together and started contributing to something and not always going our own way and making the 179th tool.

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.

@dimitarvp

Having a mono-ecosystem in this case is beneficial because people will focus on fixing the errors you showed (though sometimes the maintainers are difficult; though I have no idea if that applies to systemd, any observations?).

@dimitarvp

Finally, have you tried reporting those issues?

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.

@dimitarvp

I disagree it breaks too often…Not saying this is a classic usage but you’re kinda exaggerating from where I am standing.

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.

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.

[dimitarvp]

@tj0

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.

Eh, you are stretching the definition of an init system, come on now. 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.

@tj0

My issue isn’t that it is a single tool or not. It is that the functionality that it replaces wasn’t there.

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.

@tj0

These issues I ran into have been reported which is why I knew the workaround was not to use systemd-network or systemd-resolved.

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

[tj0]

@dimitarvp

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

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.

@dimitarvp

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.

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.

@dimitarvp

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.

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.

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?

[TimButterfield]

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.

[wdtnh]

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.

[TimButterfield]

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.

[wdtnh]

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

[Daan.T]

For nerves, try ubuntu or debian for stability, arch for customization, and fedora or opensuse for lightweight options. Good luck!

[lawik]

Not an official recommendation really but safe bet should be a Debian derivative. If you have little Linux experience Ubuntu, Kubuntu or Mint should be the most straightforward.

Nerves can work with any Linux I reckon.

[shishini]

Not for any specific type of development but more for general purpose
Fedora is currently the preferred linux distro
Also check immutable distros such as silverblue or kinoite

The KDE Plasma desktop, in an atomic fashion