That is a very valid point you have there. But is there no way to disable it for people doing forensics?

My problem with systemd is that instead of the slackware minimalist approach where you have to enable and add things... systemd already comes with everything enabled and you need to disable it... This is something I definitely don't like about it and works against my common sense. Perhaps RHEL7 will fix and weed things out when it adopts it. After all Fedora is just a tesing distro for RHEL (the true reason for its support blatantly advertised).

So although I enjoy the fast boot. I dont understand why it loads so many things together from the beginning as enabled. Shit, if systemd is bragging about its boot speed, why not take advantage of parallel boot and start with minimal processes? That would make it even faster then it already is.
But now that I rethink. Back to what I just said... Take a moment and think why?.... Fedora is a testing distro for RHEL. So it makes sense to load everything on everyone so that people can see what works and what doesnt work or recieve feedback on what they like and what they dislike including bugs. I guess this just answered my question why everything including the kitchen sink is included in systemd startup. However, on a practical standpoint: A good system should have the minimal requirements and you as the admin should choose what to add into it.

Looks like I won't be using Fedora for too long more then as a hobbyist distro with this type of approach. I don't enjoy being a lab rat for their distro.

And thats what you always hear from Lennart. If you got a problem send in the Bugs!

Hahaha! My mind is clear now!

OK, I agree that you got me there. That was a very nice come back. Respect.
and peace. Apologies for my comments. Can we move on or are you going to continue to target me with everything you say.

I admit you got me good.

I am not a Slackware user, but I feel strongly about this issue. My main objection to systemd is that it is a large departure from the Unix standard without any real necessity to do so and sets a bad precedent. Should Linux forge ahead and establish itself as a completely different OS or should it stick closely to its Unix roots? I firmly believe that it should stick to its Unix roots. Sticking with the Unix standard offers the best cross-platform compatibility with a model that has stood the test of time.

I often see mentioned here about how much Redhat has contributed to the development of the Linux kernel. So what? Does that mean that they can't have bad ideas? Does that mean that they should never be criticized?

I have a huge problem with the way Ubuntu has deviated from Unix, but at least they are not cross-distro changes. I am really sorry to see that openSUSE has adopted systemd. I hope Slackware stands its ground on this issue. If so, I just might become a slacker.

Major distros always have adopted "posh" and "fad" software almost to the point they get severely broken, dependency hell inclined, and overburdened with issues from too much resource usage.

Red Hat, yes, may have contributed a lot to Linux, but should they be allowed to direct it's heading? No they shouldn't. The community of Linux users should be the ones to decide what standards are adopted for the various operating systems using Linux as it's kernel.

I've used major big brand distros in the past, and none of them have performed anywhere near as well as Slackware has over time. Mandrake was one of the first dives into Linux I took, and found it to be a load of garbage. I tried Red Hat, and again, garbage (esoecially because they wanted me to "buy" a license to get updates. I even tried SuSE and was lost in all the mess it was. I then tried Slackware. It was labeled than as a minimalist system, but was one of the oldest so I said, what the hell, and installed it... and I was hook in less than 15 minutes with it. It was easy to use, easy to work with, and was very back to basics and I actually "learned" Linux.

So for me big brand distros, are not someone I would trust with the direction of GNU/Linux at all.

bah

Oh, his opinion is shared by others.

2 members found this post helpful.

...

Attached Thumbnails

 

3 members found this post helpful.

Stay on topic please.

Interesting view on the matter. However, we need to understand how much of it is marketing speak, and how much of it is shaped by the author's situation of being a software developer familiar with the systemd implementation. As the philosopher says: "Being determines consciousness".

I am a software developer myself, but maybe that only makes me more wary of marketing speak, and of software complexity that will eventually eat all the perceived benefits of a piece of software. In that respect systemd worries me. But i must reserve judgement before i actually had a look at the thing.

What I do know is that the current line-up of init, hal, udev, dbus, hotplug, message-bus, console-kit, policy-kit, udisk and all the other shit is driving me insane and the complexity prevents me from troubleshooting and fixing problems. I wonder if that situation will improve or deteriorate under systemd.

I would hope very much that a policy like that can be easily configured in systemd configuration...

----

PS: another aspect: we'd have no issue if people were left with a choice of init system. However, using their influence on freedektop.org etc. to make systemd mandatory is just evil in my opinion.

Of course it is marketing speak. He describes all that "awesome" features that systemd should provide and do automatically, in theory, when it's done.

But the question is: Can THE developer in charge for systemd (not tomegun) successfully implement all that stuff, get it stable and interoperable? So it is usable in real world applications?

And the answer to this question is: No, he can't. because he is to inexperienced for the task at hand and knows nothing about Unix. This can be verified by looking at his track record in the FOSS community. And talking about "stable" and "interoperable", these are things, the developer in charge explicitly does not want. Just an example:

http://forums.freebsd.org/showthread.php?t=22444

Having /usr on different filesystem than / is "not supported"? How can someone who calls himself a developer be that ignorant about the Unix file hierarchy?

He obviously doesn't know why the /usr folder exists, yet considers himself competent to throw away the entire init system (developed over 40+ years) and replace it with a single daemon? He clearly doesn't know the first thing about the Unix philosophy either (or he simply doesn't agree with it).

This cannot possibly end well.

1 members found this post helpful.

His work reminds me of a quote :-

"Those who do not understand Unix are condemned to reinvent it, poorly."

Hasn't that been the accusation that Linux has faced from the BSD folk for over a decade or so?

I agree with the last post; there is a lack of cooperation between different projects:
http://forums.freebsd.org/showpost.p...58&postcount=9
Instead of solving problems (like the /usr split) software is rewritten adding more confusion and incompatibility.

I've currently written an article on a topic that I feel somewhat strongly about:
http://harishankar.org/articles/inde...ormIrrelevance

Though I don't mention systemd in that article, I think anything that makes it harder for us to use different *nix OSes interchangeably is a loss for the community as a whole. Working towards achieving cross-platform portability amidst *nix OSes might be beneficial to everybody involved.