I didn't say they would agree. I think I understand what they want and what they do get out of it, and don't agree with them. I don't call them idiots or anything, they have their perspective, I have mine. I see their points and will acknowledge and explain why my perspective doesn't agree with the value.

In this particular thread, there has been some people saying 'right on' and there have been some pretty angry sounding posts calling me a troll. There was a pretty level headed systemd advocate as well, so I guess not all of them are that way, just some of the most vociferous, but maybe that's just the nature of the beast in any discussion.

I do also want to say that your post is a credit to systemd advocacy. Level headed discussion of the issues rather than senseless ranting.

While there is a grain of truth, the rules are a bit more straightforward in SYSV. SYSV was created by people that were largely starting out and did KISS out of necessity. So one needed only to understand some relatively basic bourne shell and you could figure it out from there as needed, even if you didn't know it. In his example, environment variable fell out of the sky. In init script, you know it had to be set *SOMEWHERE* from that script. It sourced another file, bingo, there it is in plain text. There are some things in SYSV that are a little weird (runlevels being arbitrary numbers, but there's a handful of them and inittab was a relatively short file), but generally it was quite discoverable given relatively simplistic understand of shell scripting. In systemd, if the config files pan out right, then they are simpler than the SYSV scripts. When things go wrong beyond what the author had intended, sysadmin is less likely able to figure out what the developer did wrong and correct. This I think is the fundamental breaking point. systemd adds some features that I can't readily imagine being acheivable from shell scripts, but it's harder for a layman to dig into something that went wrong. This means software vendors can deliver more service automation and such more easily under something like systemd, so many software developers appreciate it. Sysadmins on the other hand cede the ability to be able to look under the hood themselves. It's a tricky walk.

udev is actually another beast that could use a lot of improvement, alongside DBUS. dbus, systemd and udev start straying from 'everything is a file' and start creating invisible constructs in a namespace that isn't really explorable. 'Everything is a file' sentiment has been lost. What people forget is that everything is a file really just means a pretty straightforward yet capable organizationed model that a client can explore. It's like RESTful in webservices are supposed to be (though that facet is also frequently unusable in some web frameworks, many do get it right).

Your results called out the Piledriver explicitly as 'per module' rather than 'per core' to make the numbers match. It basically validates the point you respond to. In practice, it's more complicated and can outshine hyperthreading in some cases, but in your specific citation the processor measures up if you pretend module==core rather than saying it is an 8 core system.

That scenario doesn't involve the special nature of pid 1 at all. Any pid can screw up a system. Traditional init is a handful of lines of compiled code and systemd is significantly more to assure services cannot escape their cgroup and other such tricks.

If pid 1 crashes, the only thing I can really do is sysrq. The division between kernel space and user space pid 1 is largely academic for a sysadmin afflicted by a crashing bug in either one of them. Yes there are thnigs kernel c code can do beyond the reach of user space code, but that was really not the point of the discussion.

If that were the case, why would systemd exist at all? Systemd exists because they wanted to pull off some tricks they couldn't do in an init system that could be followed by a simple 'set -x' in key locations. Like Windows, when things work, they appear simple enough on the surface. Like Windows when things go wrong, you are pretty well in a weird world.

Do you really not acknowledge the existance of FreeBSD, NetBSD, OpenBSD, AIX, Solaris, HP-UX, and more?

If the people who like straightforward init scripts don't bitch, then their preferences will go unheeded. It's better to bitch than be silent as your perspective is steamrolled out of the way. It's not 'old garbage' no more than the wheel is 'old garbage'. Just because something does the job and hasn't been mucked with in years does not mean it should be presumed garbage and replaced.

Well it does solve some problems, just not problems many server administrators largely cared about while creating problems some systems administrators really do care about.

-Services cannot reparent themselves out of the launching context, meaning init system *always* knows how many processes it is and resources it consumes. It's nice and structured, too bad that ps axf and grep largely serve the same purpose when things went south, but the systemd approach is certainly more structured. Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.

-Bake in more advanced log processing to mitigate the need for log analysis tools. The problem of course being that those log analysis tools tend to work well enough while leaving the plain text behind in a manner that can be trivially opened and perused in Windows or whatever.

-Starting up /bin/sh hundreds of times during boot is wasteful and slows boot. Systemd mitigates that by enabling more lightweight service start. However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.

-Sequential startup of services is silly when many can be started in parallel. Of course now you have to debug a less deterministic boot process to enable such a thing, with the same inscrutable code paths for the sake of a faster boot very few people needed.

The complaint about systemd is that it adds complexity to the base function of the OS, not that it fails to do what it advertises. It's not that people take issue with the way you deal with systemd, it's that when things don't go according to plan, it's a mess compared to the alternative.

For the services, you do have SysV for example still. You write one SysV script and systemd can make use of it just like the other init systems can.

What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.

Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.

No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).

And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).

What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just that buzzwords have come to recognize how a good system admin has gotten his job done all along.

Yes systemd more thoroughly captures a child daemon into a cgroup. Yes systemd can do faster boot through avoiding the start of relatively expensive script interpreters repeatedly and also making services boot in a fashion. Yes journald files can more quickly accommodate more complex searches against the data. Critics don't say this is inaccurate, they say usually it is worthwhile or could have been done with a better design to cater to the sensibilities of those who really need to be able to handle unfortunate bootup scenarios as well as they can today without becoming systemd specialitsts.

On the other hand, hourly employees are generally held to 40 hour workweeks because they get expensive beyond that.

Frequently salaried individuals have their exempt status abused by making them work 60 or more hours a week. I personally am fortunate enough to not suffer this, but a lot of shops will burn out their coders with ever present threat of finding cheap replacements.

Hence why I compared it very carefully to IBM'S SMT rather than Hyperthreading. IBM SMT has componentsto handle each 'thread' while sharing common components (including FPU in SMT8 but isn't shared in SMT4). It isn't 8 threads in the hyperthreading sense, but neither is it 8 'cores' with respect to how any other CPU vendor calls things cores. IBM is the only other microprocessor vendor that has something that resembles the AMD design, and they do not refer to the components as 'cores'.

I haven't seen any FP intensive code work better than Ivy bridge equivalents (1 ivy bridge core =~ 1 piledriver module no matter what I tried with respect to running one or both of the 'cores'). Haswell of course can roughly double ivy bridge perf when avx2 can be put into optimal play.

AMD is sadly little more than a 'budget' player right now. Releasing inefficient designs to compete roughly with Intel. Though NetBurst was sadder, as you were expected to pay *more* for the crappy inefficient product than the rather good (for the time) Athlons. Here's hoping they get their stuff back.

Indeed, even after installing the software, upgrading is easy. Excepting some DRM crap that could fire if you change too much, but that is BS.

I am actually married and a father too. I can't disappear into a 'mancave' every day for hours on end or spend all our money on high end gaming equipment, but I don't catch flak for spending my time gaming for a short while many days and the occasional 'bender' of gaming. If I covered the house in gaming paraphernalia or something maybe, but as long as I don't go overboard on time or expense, there's no issue.

I'm not saying the IPC is netburst like, but that the overall performance characteristic is low performance relative to what the competition *would* be at '8 cores'. Just like a NetBurst 3.0 ghz would have been trounced by the contemperary AMD at 3.0 ghz (and even much lower), an '8 core' is bested by something with much lower core count. For example, in the url you cite, they effectively consider the FX 8350 as a quad core rather than 8 core solution for the performance to be comparable. This is with a workload that does not take advantage of AVX2 (which would have the Haswell parts pull well ahead of the competition). A quad core 4.1 ghz ivy bridge would have matched the '8 core' 4.1 ghz 8350. So if you get the '8 core' thinking 'twice as fast as ivy bridge quad core', that would be incorrect assumption that AMD is counting on marketing wise.

In short, AMD has '8 cores' that performs like 4 cores, but with heat and power characteristics more closely resembling 8 than 4 cores. Just like an Athlon at 2 ghz could match the performance of a Pentium 4 at 3 ghz, but with much less power/heat than the Pentium 4.

Why not actually try the games that you want and then decide if things are too slow at all, rather than listen to some people that will evangelize how cool new stuff is with impunity since it is not their money they are justifying spend on...

What could be pathetic is neglecting responsibilities or pissing away family savings on superfluous stuff. If one takes care of their responsibilities appropriately and is prudent in their spending, it doesn't really matter if a grown man plays computer games or watch telly tubbies or whatever they like so long as it doesn't screw up other people's lives.

If IBM did the processor, they would have called it 4 Core with SMT2. Basically you have 4 modules, with 2 of many of the components, but a lot of shared components. Notably, each of the 4 modules has a single FPU (so it's more like IBM's SMT8 versus SMT4 mode if you talk about their current stuff).

So it's more substantial than hyperthreading, but at the same time not reasonable to call each chunk a 'core'. I think it behaves better than Bulldozer did at launch *if* you have the right platform updates to make the underlying OS schedule workload correctly, but it's still not going to work well (and some workloads work better if you mask one 'core' per module entirely).

Basically, it's actually pretty analogous to NetBurst. NetBurst came along to deliver higher clock speeds since that was the focus of marketing, with some hope of significant workloads behaving a certain way to smooth over the compromises NetBurst made to get there. the workloads didn't evolve that way and NetBurst was a power hungry beast that gave AMD a huge opportunity. Now replace high clock speed with high core count and you basically have Bulldozer/Piledriver in a nutshell. I'm hoping AMD comes back with an architecture that challenges Intel agin, just like Intel came back from NetBurst.