Many people argue systemd is an example of code that’s easy to delete being replaced with code that’s hard to delete.

They’ve deleted init, the dns client, dhcpd, the whole xdm family, various small open desktop protocols, kernel-level file permissions enforcement on certain device files, rsyslog, countless shell scripts for running background tasks via ssh, and I’m sure hundreds, if not thousands, of other well-modularized programs. None of the collateral damage is in subsystems related to init. Instead, it is subsystems that worked well, but that were easy to delete.

One the other side of the coin, look at all the effort people are spending to rip systemd out. Multiple Linux distributions exist solely to contain the damage it’s doing.

It’s unclear if gnome will even survive the war if systemd loses.

It’s also wasting the time of end users, so the damage can greatly exceed the total resources put into building Linux distributions.

A few days ago, I ran an “apt-get fullupgade” on my headless Raspberry Pi, and some systemd subsystem wedged during the upgrade. Now networking is broken. I want to use this raspberry pi in an embedded I2C application that run for last decades. So, I need to find an operating system that:

(a) doesn’t use systemd - fool me once, shame on you, fool me twice, well this is well past the second time.

(b) runs on raspberry pi

(c) has userspace tools to work with the i2c bus on the pi

(d) has a working upgrade path.

This is a huge pain, and it’s all to delete one software package that I don’t even care about, and that is irrelevant to the use case for this machine.

/rant

Try Alpine Linux. It ticks a, b and d. I don't know about i2c userspace tools, but it is the easiest of these to add yourself.

You might be able to put something together using Raspup or Ultibo. IIRC, both should be able to run on all Pi models. Both are pretty lightweight, simple, and they could be a good base for building what you are looking for.

Raspup is a Puppy Linux for Raspberry Pi. It uses Raspbian Buster as base. I haven't messed with I2C on my Pi, but if there are any userspace tools in Raspbian Buster's repo then you can use them on Raspup. The working upgrade path is the biggest annoyance here. Package management on Puppy in general is a pain for anything but simple install and removal. It seems like the Puppy community either doesn't upgrade or upgrades by installing the next Puppy version (which is usually fast).

Ultibo is not Linux but a Free Pascal kernel that doesn't implement a complete OS. It is for using a Raspberry Pi board more like a microcontroller, but you can use it as a base for anything. For example, someone made a Z80 CP/M emulator that runs pretty fast. Besides the Free Pascal library, the tools here are pretty much what you write. This is probably the simplest option for a Pi that may be alright if you don't plan on using the full functionality of a Linux machine or you want to avoid the Linux kernel scheduler.

Raspberry Pi hardware is not really suited for "decades" reliability. If you want to use it for an application like this, you need to arrange to recover/replace the devices in the field and plan how to upgrade out of production models in a controlled way. (And you need to rehearse/test doing it too so it works when you need to do it, especially as things change between RPi hardware generations)

> So, I need to find an operating system that...

Check out buildroot linux. I have had very good luck with this distro for professional embedded applications. It doesn't have the same annoyances that other common embedded linux distros have. It is easy to hack on, easy to customize, and if you must, it is easy to understand.

You can use Slackware

http://arm.slackware.com/

Openbsd checks all these boxes!

Try Win10 for RPI.

> some systemd subsystem wedged during the upgrade. Now networking is broken.

All software has problems. Without specific details, blaming your problem on systemd specifically seems just as unreasonable as blaming “Linux” or even “Unix”. In fact, in past years during the old OS wars, there were many such rants, blaming “Unix”. (See for instance The Unix-Haters Handbook.) Become a curmudgeon, and idolize the past, at your own peril.

I recommend, instead, to live in the present, to use currently normal software, and to fix every problem as it appears. Ceasing to upgrade permanently (possibly by moving to an obviously dead-end fork) is never a sensible option in the long run.

Don't bring the Unix-Haters Handbook into this. A fun, self-consciously curmudgeonly romp like that has about as much in common with the systemd debate as P.J. O'Rourke does with Bill O'Reilly.

I don’t know who any of those people are.

I think the point of the parent was that systemd will be much harder to replace than other init mechanisms once something better comes along, because it grows into every part of a Linux setup. And if that's true, then systemd actually hinders progress and innovation, because the cost of replacement will be too high.

Possibly, but that was not the part which I chose to comment.

I think the one thing we do wrong with code is when we document it, we write what the function does. Code is largely self-documenting and this because stale quickly anyway.

IMO, the thing we should be doing is documenting WHY this function needs to exist. That is the question that is hard to answer three years later.

I like your comment, but for the wrong reason: Explaining what a method DOES, goes against encapsulation principles. It creates coupling to implementation details, when what should be provided is just the interface. Any explanation can be exposed in business domain logic and documentation.

There are multiple pieces of documentation. Documenting what a method does is one of them, but primarily intended for maintainers of the system. Documenting its interface is meant for its users.

Both have great value, but at different times and to different people.

Indeed, was thinking the same thing while posting.

In practice though, I've mostly encountered lack of comprehensive developer docs, or they became outdated years ago. Most devs will point to source itself for documentation, unless for critical or certified software. If not the latter, the internal logic is usually scattered and not cohesive. So need to check dozens of files for each hypothesis about the original intentions and context.

I am working on some code I last touched 12 years ago. I think good documentation is essential, it saves time in the long run. Knowing the why is very helpful.

It is like the Murphy's law of deletable code "Anything that can be made hard to delete will be made hard to delete".

More like a variant of the Peter principle: all code tends to be refactored to its level of unrefactorability.

Having just completed a change that should have been small, but ended up spanning ~75 files, I can attest to this. It would have been small, up until the point where one of the excitable members of the team discovered Uncle Bob and got excited.

Which, disclaimer, I generally like what Uncle Bob has to say. But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve.

> But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve.

All of OOP is like this. The most enthusiastic OOP adherents create the biggest OOP messes. Maybe every style of programming suffers from this problem eventually? The style has a go-to form of abstraction and a characteristic kind of mess that results from overapplying that form of abstraction. Once people get comfortable dealing with that kind of mess, they realize, if I program zealously and dogmatically in this style, this is the only kind of mess I will ever have to deal with, and the comfort of always dealing with a familiar kind of mess they know they can slog through outweighs every other consideration.

I once encountered a take on this that rang quite true to me, though I can't for the life of me find where I read it.

The observation was that good object-oriented design is inherently unstable. With even slight perturbations, they can quickly spiral away into a mess. And those perturbations tend to happen almost constantly in real life, because writing SOLID code requires vastly more skill, knowledge and effort than not writing SOLID code. So keeping the code clean requires a constant, almost aggressive effort by some (probably self-) designated caretaker who understands and can defend the design. The social factors there are terrible, though, because now you've got a person on the team whose very job is more-or-less to nitpick and have arguments with the rest of the team. Frankly, it might be better to let the code be messy than it is to risk creating that kind of work environment.

I play this role in my team, and as a team lead I take it as one of my responsibilities. What works for us is that when I don't approve something I explain why and work out an alternative implementation plan with them.

If we cannot come up with an alternative or cannot convince ourselves that it is indeed better, then the original implementation goes in. Otherwise we move forward with the new plan. I'd say that that (when I challenge an implementation) around 4 out of 5 times we end up with a new implementation.

The team is very happy with this approach, or so I've been told. It wastes some time in the short term (hey the thing worked, why are you overhauling it?) but our manager's perception of good team motivation and resulting quality is what buys me the leeway to keep doing it.

I have seen many a TDD enthusiast create many more problems in terms of test maintenance than they solved in code quality. Doesn't mean TDD is bad, it just means like anything it is not a silver bullet

I certainly don't think TDD is bad; I do it myself. Though I will say that the Classicism vs Mockism debate is alive and well, and it is my (a classicist's) opinion that test-induced design damage is largely a by-product of getting so caught up in the red-green-refactor flow that the tests start to become an end in and of themselves. At which point maintainability has taken a back seat to mockability.

I'd rather have a slow test that doesn't unnecessarily concern itself with implementation details, than a test that is fast, but achieves its speed by getting its dirty little fingers all over the implementation details, and throws a tantrum and refuses to let go of them every time you attempt some spring cleaning.

I was thinking this too, but on closer scrutiny I don’t think it’s true unless the “goal” of code is to be rewritten. If the goal of code is to work as well as needed and no more, then it won’t move in that direction.

The “goal” of employees in a corporate environment can be to be promoted and get paid more, on the other hand, leading to the Peter principle.

I can live happily without promotions, as long as “pay me more” part is working.

Good code disappears, bad code stays.

"Anything that can be made hard to delete, will be made harder to delete, even when we try to make that specific part of code easier to delete."

I have had pretty good luck with just dropping a comment where something would be expanded. I find for myself sometimes it is easy to add bunches of code for cases that never happen. Mostly because you are in the moment thinking about all the different cases and have in a crazy way missed the specific case you are working on. Sometimes (not always) it is better just to ack that you are being an over-engineer.

A good example of that is adding boost to your code base. Once you've added boost to implement one simple feature, eventually someone will use boost to do preprocessor magic or other meta-programming. Then there is no going back, because there is (almost) no way you will be able to reverse that decision.

Analogous to Gresham’s law: “bad money drives out good” (https://en.wikipedia.org/wiki/Gresham%27s_law):

Good code is easy to replace, bad code is hard to replace. Therefore, all good code will, absent other forces, eventually be replaced by bad code.

Actually, beside the facetious aspect of this, there is a subconscious value into having code-mass. Heavy means stable at times.

I'm not sure what you mean. Evidence indicates that code attracts more code, and big elements are frequently changed.

They grow. They change. But they can't be killed or conquered.

Not clear in my head either, but I just experienced the value of heavy structures at times.

I don't find the analogy working for software (a large structure is hard to change).

Software is always easy to alter, hack in some code here and there, move some functions around, add and rename files. The larger the software the more places to make changes.

It's unlike a physical structure where a 1000 tons wall really can't be moved.

informational mass (complexity) is hard to change in a way

you can always delete for free but there's no system anymore, and if you change randomly the system might fail

Funnily enough I usually experience the opposite. I've worked with very heavy systems and very light systems, and I always find more stability with the really light weight stuff. Obviously there are more bugs at first, but once you go through your first wave of code fixes I'm usually sitting pretty for awhile until I change more stuff.

I don't see your point. Code that's more modular, pluggable is by definition easier to delete. That should not be a reason to prevent us writing easy to delete code.

It took me a while to get it too: someone else downthread summarised it neatly as a version of the Peter principle:

> all code tends to be refactored to its level of unrefactorability.

This was a neat way to look at it!

It's not a side effect, but a rule of Nature.

It will happen either you follow the advice or not, and the article is about how to slow that process down.

Adverse selection at play

uh, indeed, sounds like thermodynamics.