Until you framed the context here I actually hadn't realized what the motivation for designing systemd like that could have been. As you've pointed out; while that mentality of hard-coding all these modules into pretty-little uniformly shaped candy shells will be super convient to deploy a few thousand disposable server instances it's going to make any hand-tuning a big pain in the ass.

The fact that one of the "sale points" of systemd is to have these localized initialization modules included in packages just re-inforces your point - and it makes me worry systemd is going to replace any customized modules each time a package is updated. Ugh.

This is the most insightful comment in this entire discussion. It's nested pretty deep though - maybe you should copy this and paste it as a new post. People need to see this.

Again, I don't hate him. I'm just curious as to why you defend him so much. And by "relationship" I mean do you know him? Have you worked with him? Have you been involved in the technical discussions his negative image arose from? I wasn't implying anything else... So why are you so bent on defending him?

> and using that hate in place of technical considerations
I think the problem here is a lot of the "hate" he's getting is from *him* ignoring technical criticism. At least that's what a lot of people have pointed out. He kind of projects this attitude of "I'm right because I know I'm right and my way is better" which is an extermely frightening considering how much of an integral and low level component of the system systemd is.

As developers we need to take criticism seriously. When someone says "I think this is wrong" or "I'm worried about this in this situation" or "Do you think this is really a good idea?" it is quite possible they may have noticed something we've overlooked or failed to consider.

SysV is significantly simpler in design and functionality than systemd and that is exactly why so many people want to stick to it rather than jump on the systemd bandwagon. systemd tries to do way too much and in turn gets itself tangled into parts of the system that SysV would never be involved in. That means that in cases where SysV has done its simple job and gotten out of the way systemd could have some failure in some unrelated part of the system that could have a residual effect on something else. What's damning is that there are quite a few recorded instances of this happening.

The fact of the matter is as much as SysV can be inflexible and occasionally difficult to deal with, it works and it rarely breaks. You need to consider the install base we're talking about and how much of a massive loss of time and money even a 1% increase in down time could cause. This is an issue we need to be certain on, we need more testing on, and as much as it would be great to just love new and shiny things we need to act like grumpy old men a little bit so we don't break parts of the world.

First off I don't hate him - I just don't trust him and I find the way he deals with people to be a bit childish.

As for the rest of your post:
> He's a famous, successful programmer.
He's kind of famous for not being liked by some other high profile programmers more than he's famous for delivering a stellar project. We can only hope systemd will turn out to be as fantastic as is promsied and everyone can just drop the issue and give praise [when and] where it is due. Mind you, that day has not yet come.

> none of whom are qualified for his job
He's not some sort of genius. There are many many incredible coders out there who would certainly be as qualified for his job - just few of them are so motivated or have been offered the incentive or opportunity to do it.

> All your hate ...
Criticism and/or lack of trust are quite different than hate. Again, I don't hate him. And I really, really want systemd to be good. I want to just transition into using it regularly and think "This is great! I'm so happy it turned out so good." And that possibility certainly exists as I regularly have deployment issues that hinge on sysv being a little too old and crusty to deal with newer things elegantly. Some of the things promised by systemd look like they will gracefully solve these problems but I have yet to see an actual build of it that did.

Seriously though, what kind of relationship do you have with him? It's obvious you have some sort of emotional or empathetic attachment to him and I'm curious as to what warrants that.

The terminal in OS X is OK if you install iterm2 - and in fact when I use OS X it's usually just a full screen terminal. The probelm lies in using the GUI. Aside from the fact that I'm not used to it and honestly don't really like it (and can't switch window managers like I can in Linux) there is a lot of functionality which has been strangely obscured. Case in point is showing hidden files in the finder. Maybe this has been improved since I last did it, but I actually had to modify some setting and restart finder. It seems to me a lot of the mentality in the design is "Grandma could accidentally do something if we let her see/access this. We should hide it.".

> in order to boost support revenue
I don't want to believe that's the reason systemd was pushed through, but if that statement has even a fragment of truth to it then someone at RedHat needs to have their skull busted.

I actually completely agree with you on most parts here. The "not very *nix like" thing is more referring to how the core of systemd is trying to do a lot more than it should and then is wrapping that in several layers. Then to make matters worse many of those processes are hard coded and not configurable without actually recompiling the module for that. As cluttered and dated as SysV is at least you don't have to take pieces of it apart to change what flags are being used to call some secondary command at boot time.

Of course I say this but you are correct in that the design states it should not be this way but it is. Or, to put it another way, let me just quote the last line of your comment:
> The basic concepts of what systemd does is good, this does not mean the execution has been particularly great.

I don't think you are familiar with the controversy surrounding him, but a quick google search dug up a rather good summary of the situation:
http://www.infoworld.com/artic...

The people involved are always important because the people involved will:
1. Shape how the project evolves.
2. The life of the project is usually dependent on those primarily interested in it staying interested in it.
3. A project needs to take criticism into account and look for opporunities to improve. Completely ignoring all critcisim could be ignoring fixes you could make now that could make things a lot smoother and avoid problems in the future.

Also I'm not defending SysV :P

Every time I've played with it I had things like weird locking issues - but this was maybe a year ago when I last tried it.

What bothers/worries me about it are the devs behind it. Poettering was bitching about how hostile the community was before but he completely deserved every bit of criticism. All the major devs on that project are known to have abandoned other projects. Several times they made mainline commits which completely broke things. They constantly pushed barely tested and poor quality code (which is why Linus got angry at one of them and banned them from making pull requests till they got their sh*t together). On top of that the design of systemd is not very *nix like so it does seem an odd fit. All this makes me uneasy, and I don't think I'm the only one, because from this I am expecting a big lump of poorly tested experimental play code that the lead devs will just abandon once they get interested in another project.

I'm of the complete opposite opinion but that's just because I'm more used to Linux than Windows or OS X. And I'll call you on the "usability considerations" thing - my father got a Windows 8 box and was completely frustrated with it - I threw Ubuntu on it and he loves it. OS X is the opposite in that it hides so much of the functionality behind a shiny and simple interface it's like being forced to wear mittions for a power user.

Do yourself a favour and put Linux on a machine you use regularly - then actually use it for a few weeks. Don't "try and learn it", just use it. As an IT guy I think you'll start to appreciate some of the amazing stuff you can do with a terminal and how awesome it is to have a package manager with a huge variety of packages just an apt-get away.

I hate to ask this, and I'm sure you're asking yourself, but: why didn't you just build on a desktop app platform? There's something preventing your users from running a full application?

Had this post been your original quesiton I think you would have gotten some better answers but I don't think you'll ever get a straight answer because there are so many unknowns. .NET matters in markets that use it. Anywhere that uses .NET is likely going to be strictly .NET. The open sourcing of .NET is certainly not going to dramatically change the landscape in favour of .NET but internal to the .NET ecosystem I can only see things improving.

Of course considering .NET a "no brainer" choice is a HUGE mistake. It has places where it works well, for sure - but trying to get .NET to do things it's not good at doing is not going to be fun. Look at project requirements, compare possible frameworks, see what fits your team; choose the best tool for the job.

Your reply is also somewhat confusing to me. I don't think you've actually looked into the issue. .NET popularity has gone downhill as more developers want to use more dynamic and developer-oriented solutions which are almost invariably open source. This is an actual trend; a real statistic, and essentially the reason why MS went ahead and open sourced .NET.

As for C and .NET you can use .NET quite easily with C. Even if your project is strictly in C#, if you know C I doubt you'd have much trouble with C# (other than maybe getting the hang of good-practices?).

There is no real demerit to learning .NET and it's not like it's a poorly designed framework. It's just that it's really designed with this enterprise approach in mind that was once its strengh but is now it's demerit. The "new wave" of large scale app dev isn't to build a Titanic in .NET, it's to build an armada of smaller multi-purpose apps that work together as a group each built with the language and framework that best suits it. There is also the fact that even though open-sourced it's really not easy to do development or deployment on anything but an MS platform, and really only MS products tie in well with it - so .NET still comes with some vendor lock-in and if you aren't an MS shop then that's a huge demerit.

1. I'm really sorry you wrote that long comment because I'm not necessarily disagreeing with you and I'm not some Enterprise Java nut (I actually really, really hate Enterprise Java).
2. "Lol, are you serious about that? That's not true at all! I work at a fortune 500 company" Awesome tone there; fuck you. So your big super rich company got sold on .Net and you're switching over to it. Good for you? I honestly don't care. Though I totally agree on most of your points comparing .Net to Java and by that criteria I can absolutely see why your company did the switch.
3. From what I have seen your saying Java is being "weeded out" is completely accurate. No disagreement from me there!
4. .Net isn't the only framework you can use with multiple languages - though I would question using one framework end to end when it may be more efficient and mangable to instead take a pre-module-framework approach with specialized dev teams on each module. Note that I said "may be" in the last sentence - definitely not one-size-fits-all.
5. Not bashing .NET but not my cup of tea. Keep your mind open, play with some alternative frameworks, and most of all have some fun.