I'm not sure. As of this last summer it still wasn't working very well.

But then, KDE is still working on BSD, which doesn't support systemd in any form.
Relatively simple. I've run both - What covers up the complexity is the use of external storage servers... and then partition the system into a lot of VMs. Each VM is relatively simple, the AGGREGATE can be complex - but partitioning the system that way uses up more resources. Not sure about how containers operate in the mix, those became big after I retired. They are supposed to be more lightweight than full VMs - but then the added overhead of systemd makes them heavier...

Lookup the collapse of PERT (a starting point at https://en.wikipedia.org/wiki/Progra...#Disadvantages). It doesn't scale well. This is exactly the problem systemd has. Adding a single node is not something that can be done easily. It ends up taking a LOT of trial and error.
They also had a lot of pain getting systemd working.

RHEL7 is sometimes -not- working.

At my employer, we kicked the tires on some alternatives before reluctantly deciding to start phasing in CentOS7. It has caused some problems (so far related to logging, automount interfering with RAID initialization, and shutting down services reliably), and my boss hates it but insists we'll just need to learn how to work around those problems.

I have friends at larger corporations where management makes decisions without the input of the technical people "in the trenches". Their managers are insulated from the consequences of their decisions and insist their underlings make their decisions work regardless of feasibility. They hate RHEL7 a lot, but have no choice but work with it because that is the will of management.

Sometimes even big industry-defining companies make horrible mistakes and take years to reverse course. Look at Intel's IA64 architecture, for instance. It took AMD coming out with x86_64 (which everyone loved, and is now the de facto standard) to make Intel see the error of its ways. Intel eventually stopped trying to "fix" IA64 and came out with their own x86_64 processors (to everyone's relief).

I figure systemd will be another IA64. Eventually Red Hat will stop trying to fix all of systemd's problems with increasingly byzantine unit file directives, conclude systemd itself is the problem, and ditch it in RHEL8. RHEL7 will be like Vista, the operating system everyone is glad to see disappear into the dusty annals of history.

Or at least, we can hope.

1 members found this post helpful.

That's good to hear. I hadn't heard of all the issues with implementing the enterprise systemd OSes in the field. Everything I've seen from RedHat shows systemd is working as expected. I really hope your comparison to Windows Vista and IA64 are accurate.

These are the problems with arbitrary ordering. Unless you can specify absolutely everything they have a strong tendency to fail sometimes simply due to random external timing.

The key word is SOMETIMES. When it works you can think you have it fixed. But the next boot/shutdown may show different. What works on one system may not work on the next.

lol, systemd reminds me on fortune's quotes of some obscure languages

surely some functionality was welcome, but the implementation just reminds so much to other proprietary products, one can't help but wonder?
What is the least common denominator to: Microsoft, Google and Redhat?
hint: management boards, golden parachutes and immunity for errors in decissions.
we need to coin a name for this, as it seems to reapear every so often?

MBA?

Sorry, looking for "tongue in cheek" smily and pressed the wrong button.

this?
I don't know, but it kind of makes some sense?

I meant:
and pick one?

Yeah, referring to the depressing number of high grade hardware manufacturers which suddenly start making garbage in an effort to make next quarter's figures look better (never mind the longer term, that'll be someone else's problem). Rediscovered fortune when I started with Slackware - and I have to admit it's one of the reasons I don't go straight to KDE.

And the smilie I was looking for is :‑J - should have gone here instead of playing "What does THIS button do?"

I do not have enough information about that, but systemd is not the only thing they replaced.

they replaced yum with dnf and iptables with firewalld.

firewalld helps you to declare zones, uses xml files . Is this not another complication ?

To be fair, firewalld doesn't replace iptables.

It provides an interface to iptables suitable for laptop use. A GUI if you will for iptables. The use of the daemon permits easier privilege isolation between the GUI and the system.

The problem I have with it is that I would like it to store the rules in iptables format, and use that for keeping the configuration. Instead, it puts them in multiple places, and in XML format, making it harder to follow what it is doing. And if you get it working, you can't then disable it and still have things work. Thus it locks you into using firewalld or never using it and doesn't provide any educational understanding.

sounds like drug dealers? 😏

@fido_dogstoyevsky thanks for the link 😏 ;B-] (although manual emoticons are always better 8:-) like moms cookies too)

I've never thought of systemd as a conspiracy and find the idea pretty far fetched. Especially since the cause of systemd is pretty obvious, to me anyway...

GPL3

How so? Look at the chain of events. GPL3 gets released mid-2007 in spite of repeated warnings of it causing Balkanization in free software. Next, the non-fun, not-so-glorious, yet paid work being pumped into the GNU/Linux plumbing evaporates. (By plumbing, I mean everything between the kernel & GUI.) Meanwhile, java and OO focused college grads still want to make yet another GUI while things in the middle start to actually break. (Have you compiled gpm recently?) Presto, along comes RH with an all-in-one solution to everything rotting between the kernel and the kiddies because, frankly, no one else will.

All IMHO, but that's how I see it.

RH is clearly trying to force people into learning what they create and making people dependent on it. The same strategy adopted by ? (Guess who)

This is primarily because of its influence and domination in the server market. I know there are LOTS of organizations who stress on RH certification as a basic qualification for the job, so they are forced to learn whatever RH makes.

RH makes a lot of money , their trainings are anyway exhorbitant for what they teach, consider jboss training for eg. over here 52k Rs + taxes if any for just 5 days.
Over here that is like one month's pay for a employee with good skills who works for like 8 - 10 hrs a day , and all they teach is the jboss admin console (web gui).

All this is fine, money is good, Im not against it, do what you want for business, but influencing others (which I strongly feel) , till the extent where they put systemd in desktop computers, and you cannot even replace it , is way out of line.

Even GNOME developers changed GNOME 3.x to suit their approach to systemd if I am correct ?

I don't think it is a deliberate conspiracy. It can be accidental - a "keeping up with the Joneses" issue.

And yes, The Gnome developers did make Gnome 3 depend on systemd. But that was due to it being the same group of developers (well, at least a rather large overlap) between the two "separate" projects.

I agree with your thoughts about the conspiracy theory... But I think you're over-simplifying things a bit with the rest of your post.

As a software author in the Linux world, you're free to license your software as you see fit. There are still many projects included in Linux distributions under other licenses. As far as I know, there is no distribution which has made GPL3 mandatory.

I'm not understanding what you're referring to with this: "the non-fun, not-so-glorious, yet paid work being pumped into the GNU/Linux plumbing" Could you please provide some examples of the projects or parts you think are rotting?

The third thing I'd like to mention is that gpm is used only by virtual consoles at the command line. The GUIs available for Linux do not require (or use) it at all. There is really very little use for it these days. That aside, what issues do you have compiling it?

One of the goals of systemd was to unify the Linux distributions and, in doing so, replace several competing standards. This is a noble goal... But history shows us how that always works out:

https://imgs.xkcd.com/comics/standards.png

That applies to everything from init systems for Linux to the cranks on bicycles. Nobody can agree. Everyone wants their say. What we end up with is a huge mess and people on internet forums struggling to find parts for their 10 year old bicycle...

RedHat don't care about unifying Linux. They're a commercial business. They want people to settle on standards that they've set, so that they can make more sales. And there's nothing wrong with that at all... but you can't dress it up to be more.