Neither, although I had friends who played hockey (field, not ice) and football (the round ball code).

At university I played and later refereed lacrosse (little brother of war it may be, uncivilised it isn't).

And I'll only admit to a very small familiarity with the penalty box.

I bow to a lacrosse player. Played pond and shimmy hockey later in life (parents wouldn' t pay for hockey when young and it was very expensive when I was young), a year of high school American football (Canadian rules which is not real football), soccer, basketball (boring). Tried lacrosse for a summer and it is more difficult to handle the ball then it looks. Takes some real skill. Had good teachers though and position was drilled into my head.

Lacrosse is savage and that is the beauty of it. One does not appreciate the skill behind it though until you try to play it.

I just skipped over the majority of this thread, for the single reason that it was derailed by yet another useless flame war over systemd. So if this question was anywhere asked along the way, just say so and I'll bow out with nary a disparaging word. What I would like to know:

What did systemd get right? And how could we improve BSD init based on that?

My own position (which I guess is relevant to this thread, still? Maybe?) is that while I respect Poettering's ability to design and implement complex systems, he doesn't seem to be self aware enough to realize he's been adding complexity to systemd as he goes, all the while adding bugs he doesn't seem to want to fix. Maybe I've got it wrong, but I honestly have stopped paying attention a long time ago. Surely by now, what systemd gets right can be identified by those of us that can't be bothered with the torches and pitchforks.

This is why I' am not too worried about systemD but the debate does have to be kept alive.

I think it will die. The beginning determines the end, and unix survived because it was born in an era of low resources: hard and soft. It had to do more with less. systemD was born in an era of gluttony. The way the IT industry has gone in the last 20 years, older timers than me will probably say 30-40 years, is directly because of an overabundance of resources: hard and soft. A catch 22. There will come a time when there will be crunch and when hipsters cannot use frameworks and tools upon tools upon tools anymore and they will become irrelevant. Then it will be down to survival of the fittest and that which survives will be that which is liberal in the input and conservative in the output, will be low resources, work well with other programs, and be taken apart and put back together from one base for different needs.

If systemD is not bad then ask why it does not exist in the embedded market? I' am not considering hobbyist Rasperry Pi tinkering in this statement. Because it takes a lot of space, it generates more heat which also means more power, it makes systems slower, and it is Humpty Dumpty; once it is taken apart it cannot be put back together again.

So once all the glamour and money is out of IT and people will have to get real jobs doing productive things instead of designing painful websites on frameworks bigger than Windows 98 was, then things like systemD will die.

Sorry, but this is an argument that doesn't hold much water, thanks in part due to several links like this: https://www.youtube.com/watch?v=ERS1OSOTGpg or this https://elinux.org/images/6/69/Demystifying_Systemd.pdf

Raspberry Pi's default OS (practically) is Raspbian OS, which runs with systemd, and systemd has been known to run fine under systems with less than 512MB of RAM. Down to Pentium II even (possibly earlier), is about the implementation and modifications you do that make it possible in the end anyway. (Many other ARM boards run a form of Linux which also includes systemd as the default init)

So yes, it is on that market and is doing very well so FUD like that won't work well here.

The point is to improve an init is to take away from it. There is many inits that one does not have to improve and can just switch out for what the need is. All the 'problems' against traditional inits were not the inits themselves but a lack of effort between the chair and screen. In the insane corporate world it was thought instead of learning shell to do 90% of what you need to do and 100% to run programs in the background with supervision you need to learn a whole new command syntax closer to pidgin English.



Even this, like all systemD talking points, was not even true anymore.



# systemctl start sshd
or
# service sshd start
or
# /etc/rc.d/sshd.rc start


# systemctl enable sshd
or
# /etc/rc.conf
sshd_enable="YES"
or
# chmod +x /etc/rc.d/sshd.rc


(runit is # ln -s /etc/rc.d/sshd.rc /var/service/sshd or similar)


Supposedly systemD reduces administrator complexity by a slightly different syntax. Slackware init and BSD inits are extremely simple to write and study with a little shell. systemD unit files are strange, not difficult but makes me wonder why a .desktop type file is doing defining how a daemon is supervised or put in the background.


(Disclaimer: not on a Slackware box so couldn' t ls and get exact sshd script name.)

512MB is a huge amount of RAM for real embedded. You are talking of consumer boards and devices. I' am talking real embedded. Industrial stuff that runs all the infrastructure we do not think about in the background. I clearly stated I was not talking about consumer hobbyist devices.


Gas pumps, traffic lights, all the stuff that oil and gas industry runs. Sensors and valves in refineries, dams, power stations, blah, blah, blah. Real embedded and real constrained devices that cannot fail for any excuse because millions of dollars, deaths, accidents happen when they do. In short real embedded devices and not consumer tinker devices that nothing depends on. The more serious the embedded device the faster Linux share diminishes too.

Before poeple accuse of FUD they should develop their reading comprehension skills further.

Almost:
/etc/rc.d/rc.sshd
and you can use the normal "start" and "stop" arguments (and even "restart").

1 members found this post helpful.

Then why would you need an OS in any or most of those? let alone systemd (which is more than an init itself), for why would I need something as big as an OS on sensors, traffic lights or gas pumps? for IoT? If you would care to explain.

I am not a systemd fanatic, again, neutral. But I want to doublecheck facts and not let myself be deceived or confused by people's statements on something. So before you accuse me that I should develop my reading comprehension skills further, first, I'd like to hear a full reasoning why do I need OSes for those objects, and then, why does systemd cannot work in opposition to other inits available, with benchmarks if possible.

ehartman: Ah, the beauty of autocomplete; don' t have to bother to remember trivial stuff. An hour earlier I would have remembered but this late... Thank you sir.

1 members found this post helpful.

Because you need an OS to run ANY hardware... o-p-e-r-a-t-i-n-g to operate and the s-y-s-t-e-m to do it. :-p

Really? Scroll up. In one post I have it so in one screen you can see yourself rattling on about Rasperry Pis and my statement that your was in response I specifically name them as something I was not talking about. Yes, that is called a reading comprehension problem you have demonstrated twice in a short amount of time.

In your original post, you claimed and I'll quote this "If systemD is not bad then ask why it does not exist in the embedded market? I' am not considering hobbyist Rasperry Pi tinkering in this statement."

I'll admit I did go to a bit of a tangent with Raspberry Pi and related ARM-boards because they are on an embedded market and proudly so, my original intention was to clarify regardless of what could be interpreted here (Yes, I did also mentioned the word FUD but this was in relation to the latter parts of your statement when it came to these tinkering devices)

But let's go back to you. You said "why does it not exist in the embedded market?" all right then, why don't you explain that yourself? how do you know it isn't popular in the embedded market? are you a professional in embedded devices? have you worked with companies who produce those and you know what kind of "OSes" are written for those?

Back to my previous post, I asked you that if those devices needed an OS, then, why did they needed one? let alone one with systemd. If they needed one, why couldn't it work with systemd instead of other inits? (No, your "takes more space, create more heat, etc." are only assumptions in my eyes, I need proof and evidence here) and I asked benchmarks, then you dodged all those questions with "Because you need an OS to run ANY hardware... o-p-e-r-a-t-i-n-g to operate and the s-y-s-t-e-m to do it. :-p" and proceeded to "Yes, that is called a reading comprehension problem you have demonstrated twice in a short amount of time"

For someone who likes to dodge questions, they sure love to ascertain about my "reading comprehension problems" seemingly. And neither your one line of explanation for the whole "OS to run any hardware" satisfies the original questions. Seemingly, it does makes you the one with reading comprehension problems or someone who does not wants to answer to my questions.

This is one of the issues that tells most people immediately when working with systemd that something is wrong. The commands and syntaxes are so un-unix like or unlike anything else we deal with that it immediately throws red warning signs. Commands are split unnecessarily into different commands and almost all commands use full words and comma and binds together double words etc instead of simply doing it like we're all used to. Say "sysctl -D xyz -a name -f something". Instead you end up with "systemctl-something something-something of something-something X -z do-something-else-too" and then you need to do something related but need to use an entirely different command even though it would make more sense to use the same.

So actually systemd adds complexity in my opinion, and introduced a new way of doing things that people don't really need, and need to learn as well. Rather than staying with conventions it does perfectly easy things difficult and obfuse in a different way, seemingly just to be different.

This for me flags systemd with a red flag immediately, but without looking at the code I couldn't say how the code it, but for a user, just knowing what systemd does and how just verifies that red flag from earlier.

As I've already said, I don't mind systemd, I just mind the tyrant, and I think systemd does some things in a really stupid and annoying way which makes me personally not want to use it if I have a better choice. I do use systemd on one distro, and yes things work well, but when they don't it can be a proper nightmare to try to fix it. Even just dealing with it randomly is annoying enough.

And thats's a good distro, not some ubuntu crap. My distro is fairly flexible in giving power to the user, despite systemd. I think part of the design of the distro is geared towards giving advanced users maximum freedom and choice. But systemd as part of the distro is another story alltogether and in some ways can hinder that, unless it just sits in the background and shut up. But instantly when it doesn't and you have to deal with anything systemd related it becomes and absolute nightmare.

For me that is down to how systemd is designed and the tyrant aspect of systemd, both of which makes me dislike systemd more than I like it, and from a purely philosophical viewpoint makes me hate systemd. So, in the end, I don't mind systemd, I even think it has some good points and some good use, but the way it goes about that is absolutely hate-worthy -xyz something-something of -d command-line do-something-else.

3 members found this post helpful.

Which makes systemd completely worthless for small distroes. None of them use systemd, they all use systemv (or in the case of tiny busybox). Puppy, bodhi etc, all sysv, because they cannot live with systemd because systemd is not viable.

512 mb is ALOT, people seem to forget that these days. 64mb is reasonable, 128 is reasonable. 512 is chunky. I'm not even talking about embedded, I just mean for minimalistic systems which I happen to like (being an old DSL'er).

In my humble defence to what I said regarding systemd. I said 512MB and less, because I know there's a project (and projects) who has significantly lesser requirements than that (I know of one that only makes it 128MB or so, I believe is a Debian based project which uses systemd) and ArchLinux32: https://bbs.archlinux32.org/viewtopic.php?id=2787

This community project which is a continuation of the original ArchLinux project targeting 32 bit computers have people discussing some of the computers they use. And the administrator of the forums running that community project stated that he has a Pentium II running the distro for server-purposes, but even they admit that with their i486 branch they should be able to use really crusty machines in the words of the admin there. If you feel that is false or not true, direct your doubts to their admin.