I personally watched what Red Hat's big backer do for the fastest computer in the world after watching them complain about hardware and the software and how to control it. The NCSA finally said hey you either going to build this thing or give the grant money back. years of wasted time.
Cray stepped in and asked the software developers how can we help with building the controller.

In what way can we support you. This was never heard before. AMD and Nvidia stepped in with Cray and the system came to life very fast.

That is called team work. And it booted Linux. http://hardware-beta.slashdot.org/st...er-blue-waters
The fact is IBM treated the developers of the software for the hardware like they where numbers. Cray does support it was amazing how fast it went online.

Having a chance to talk to people that are very close to the project it was never about the money it was a hardware issue and how to control the hardware.

when asked what Cray and NCSA would use for a operating system it was The Linux kernel. There is a big deal how we handle the start up process with linux.
You would think Red Hat's backer would have learned by now.

Yes, it is easy to push analogies to the point that they break, but in this case the designers of the gear box are cognisant of the existing engine and should have been more willing to accept design advice when presented with evidence of a deficiency. That said, the stress test that was imposed has resulted in suitable engine and gearbox modifications.

Until we know more about how much functionality would be lost for actual kernel debugging, just to accommodate systemd, this to me sounds like "Hey! If we drive a boat at full speed into this rock in the middle of the channel... it sinks. Must be something wrong with the boat"

I would not say "simply". Systemd (the init process, not the project) is handling certain aspects of these processes that init hadn't previously (namely the opening of sockets and connections to buses). Systemd (the project, not the init process) has taken on the porting of this functionality to systemd (init) and, what is rather troubling to some, done so with little regard toward maintaining compatibility with other init processes.

The answer is in Lennart's reply to Greg I think
GNOME OS is the goal, everyone else f*ck off.

I added the bold to highlight why I will never buy a RHT product. Lurking the systemd-devel lists shows a lot of ugliness. Transparency cuts both ways, asshats.

none
they (the kernel ppl) are talking about rate limiting
/dev/kmsg is a ring buffer, and the problem was systemd dumped too much data in it in a short time

I, as an electrician, think the fault was more on systemd
as spamming anything anywhere is basically DoS-ing the destination

The systemd philosophy has always been the same e.g. 'we're obviously right and everyone else needs to fall in line'. I've no idea why there are so many vehement apologists floating around on forums...

My money is on Linus.

More than that:
1) systemd devs are ALWAYS right and ALWAYS know what is right, unlike mere mortals.
2) bugs are NEVER the responsibility or concern of systemd devs, for systemd devs are transcendental, they are on a different plane of existence, and so cannot have anything to do with nasty, despicable bugs.
3) systemd devs are required to respond in short, arrogant, dismissive phrases, it's part of their ethos and charm.

I was going by the diagram that is on wikipedia and is written almost like an advertisement with block diagrams and all. Those were all in a blue box with the label PID1. I'll stop and take the source apart at some point but I really haven't had the time. What I can say is I personally had a lot of issues until I ditched udev or eudev. When I saw all of the "not our problem" and "wontfix" thrown around at the freedesktop site, I didn't even bother to mention my issue... I just looked for an alternative.

That aside, I don't think these guys are trying to "destroy Linux" and I don't believe they'd put all that effort into it if they were. I do think a less dismissive attitude on their part would go a long way towards reducing hostilities, as well as making things more modular so that the hard dependency is less.

You know, looking at the source... It's incredibly difficult to sort out what is where.

systemd source folder: 4,273 Files in 215 Folders, 38.6MB.

SystemV init source: 68 Files, 5 Folders, 536KB.

Someone desperately needs to go read this touring lecture: http://larch-www.lcs.mit.edu:8001/~corbato/turing91/

There's a section of ESR's unix book that applies here to.

But, I'm done posting about it until I have to time to sort out what is all actually running in PID1. The source is pretty tangled.

It seems systemd fanboy Greg yanked down his topic on Google+ citing "You all suck!"

I think I now can see why people like Linus and Theo from OpenBSD are ass holes to people. Because they tire quickly of people like Kay and Lennart who think they're God's gift to their operating systems with shoddy code and cheap hacks.

Plus its a good insight into the mentality and maturity behind this... Or the lack thereof.

Of course the source folder is much larger, it does not only contain an init system, but also network daemon, session manager, system logger, ... . The point is that only a tiny bit of that functionality (AFAIK, only the init part, including cgroup management) is running in PID1, the rest is handled as usual daemons are handled and started with different PIDs.

So how do I build it with the init system, but without the network daemon or session manager? How do I build it with a logger, but not udev?

I can build GCC with C, C++ and not everything else. Or I can add Fortran, or Golang, or PL/I, or D. In the kernel I can build support for x, y or z in any combination.

This lack of modularity is often the number 1 complaint. I saw lennard chew out one guy just because he wanted to use ulibc instead of glibc, he was building for embedded. "Not our problem, doesn't contain features we use."

That guy was probably excited to give systemd a try on embedded until he walked into that flaming. All because he wanted an interop with an alternate POSIX lib. What a shame...

Linus and Theo *really* know their code and they do not suffer fools lightly. They tell the truth and they don't care what people think. They answer to themselves. They don't need to be diplomatic.