[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Systemd



On Fri, Apr 25, 2014 at 10:59 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Apr 25, 2014 at 11:31 PM, Joel Rees <joel.rees@gmail.com> wrote:
>
> We can expect a fork in the kernel fairly soon, about as soon as certain
> leaders in the community are confident they can make the current main branch
> the meaningless one going forward.

I'm a user, not a kernel dev, and definitely not someone who's majorly
into politics. A few years ago, unsatisfied with sysvinit, I started
installing Upstart on all my Debian systems, and apart from being
unable to use "apt-get dist-upgrade" (which asks to remove upstart and
reinstall sysvinit), everything worked fine. Now, with Debian Jessie
on the way, I've started learning systemd, because Upstart is
apparently a dead end, and systemd is the way to go.

Please, can someone explain - without too much on the politics, if
that's possible - whether it's right for me to invest time into
learning systemd?

This one is impossible to explain without bringing in stuff that the systemd/dbus/etc. crowd (using posts like the one that started this thread) have managed to paint over with the politics brush. (That's what I meant by poisoning the well.)

So, no, it's impossible to explain without "politics". 

On the other hand, you could learn to code, and then you could examine the code, and then you would understand why the acrimony goes all the way up to the top.

Of course, understanding why XML configuration files don't belong in boot-time code does take a bit more learning to code than simply understanding the difference between a pointer and an array. 

Or maybe that lack of understanding is part of the problem. Hmm. Except it would be more like a lack of understanding why you need a run-time stack that would be the source of the problem.
 
I get very tired of the endless arguments (Open
Office vs Libre Office, cdrecord vs wodim, ffmpeg vs avconv - at least
in those cases, the replacement is mostly drop-in), and frankly, I
have a highly pragmatic approach to my init system: it should boot my
system, and it should be possible for me to configure a program to be
invoked. So is systemd the future, or are we going to have another
massive argument?

I'll be a little less oblique than I was above. 

As near as I can tell, systemd, etc., are all good ideas that have been poorly executed, and have expanded way too far in scope. Unfortunately, they are also the tools that certain vested interests are using to subvert the entire open-source development process. (Apparently using? No. It's getting pretty obvious now.)

Historically speaking, good ideas poorly executed and/or pushed beyond their scope have been very convenient tools for politics. I can't think of a war that was not started with such a (thus, perverted) good idea. 

Therefore, my assertion that there will be a fork in the Linux kernel shortly. (This year? In five years?)

When it became clear that Microsoft's products were becoming the accepted standard in the business world, back in the 1980s, did you decide to learn MSVisual Basic? If you were too young then, knowing what you know now, would you learn MSVB? 

That's the kind of question you are asking when you ask whether you should invest effort in learning systemd and that group of tools.

I don't think it's the right question. If you're not game for the war, you don't really have a choice. You will use the winner of this war or you will quit directly using computers. The money, if you care about what the people with money do, looks to be behind systemd, for better or for worse.

If you're game for the war, start by learning to code. And you will likely need to learn systemd anyway, so you can help build the tools to provide an alternative. You should also start learning how to use the BSDs, especially openBSD.

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.

Reply to: