comments to this gplus post are interesting too

https://plus.google.com/111049168280...ts/Kd57G8s1cTD

5 members found this post helpful.

I posted the link on LXer just to have a little fun.

http://lxer.com/module/newswire/view/200597/index.html

1 members found this post helpful.

I seem to recall "she who must not be named" saying that if something gets picked up by an aggregator, its credibility skyrockets in her eyes. So: good going.

And on a purely technical level, it sounds to me like Linus is 100 percent right and Kay is 100 percent wrong.

1 members found this post helpful.

There I was, minding my own business administering my systems, when udev presented itself. I somehow broke Xsane, so I ripped out sane-backends and Xsane, then re-installed them. Sane-find-scanner finds the usb scanner, my custom /etc/udev/rules.d udev rule correctly sets the scanner permissions and changes the group to scanner, but Xsane just hangs for a while trying to find a scanner until impatience invokes kill or it just claims it can't find the scanner and goes away. I haven't done a postmortem yet, but this nonsense all happened when after a preview scan I pressed the scan button, the image flashed on the screen, then xsane *poof* vanished. Sew! off I go to compare things with a [aside: I put "fedora hat" into duckduckgo.com and it returned red hat. Go figure!] another system that was running the F-word to which I just referred. In /etc/udev, it had a hwdb.bin, so off I went to get smart on that. Seems the only reference I could find to any of the hwdb-related files on the F system was in the source tree of udev-182, which I was going to compile and install in desperation. Udevadm uses that file during run-time to find hardware. News to me, off I went to see if there was any skinny from the slackware experts herein only to find this amusing thread, since the only mention of a place to get udev source code, in hopes that there is a more recent version that works, had the Sievers e-mail address. In desperation, off I go to F-land to scan the documents my attorneys require, since the local Kinkos is usually packed with architecture students.
--
Obquote: "Fight, fight, fight, go ahead...." -Cary Grant, sitting on the staircase, "Arsenic and Old Lace (1944)"

I was looking for a reply to Borislav's (tongue-in-cheek?) suggestion that Linus should start his own init daemon project following the success of git.

1 members found this post helpful.

Now THAT would|could|might be exciting!

But even he would first need to remind us all, what is it that is broken with SysV init and why we need yet-another-init-system?

1 members found this post helpful.

If he does make one and defeats systemd, then he should be nominated for the greatest developer ever. He already qualifies, but still.

I've been watching this for months. People have serious concerns about the issues being created by systemd all over the place. I even read a chat log or two from the GNU devs wondering if more of the community leaders need to step up and say something.

The core issue with systemd isn't systemd, or udev, or d-bus, etc. The issue is the attitudes of a few of the freedesktop developers. The fact that they're trying to make Linux/GNU better is also not a problem. The problem is multiple displays of a callous & self-entitled attitude that have been carelessly tossed at anyone who's opinion differs from theirs. Linux, GNU, free software, etc., etc. are community projects. When a couple of people writing core services start behaving as if the entire community should work around the decisions they make without any possibility of compromise, you are going to have serious problems. Why? Because "collaborative dictatorship" is an oxymoron. Not only that, systemd seems to be almost marketed towards hard dependency by as many projects as possible. The net effect of that has been a whole host of frustrated people who either begrudgingly switch to systemd or virulently attack systemd and any related projects, some going as far as to drum up conspiracy theories.

The systemd situation is creating a rift in the community that is getting bigger by the day. Sadly, it's not a healthy rift about offering choice and instead is causing multiple rage forks. And, all of it because a couple of guys decided that behaving like systemd**s was the thing to do.

This is not a good place for the community to be and if it keeps up, I fear we're going to start seeing deliberate moves on either side to create incompatibility. That would be very sad for Linux.

(Oops missed already present link in earlier post...)

BTW: When I say, "deliberate incompatibility" I don't mean between kernel - systemd, or gnutools - systemd, etc. I mean less central projects posturing to either avoid a mandatory systemd by avoiding related components OR systemd components making forks difficult.

9 members found this post helpful.

The issue is Red Hat. Everyone is pretending they are just "independent freedesktop developers", but they aren't. They got an assignment and their attitude helps their employer to accomplish his goals without getting the bad press. They got hired for exactly this reason. It's the well known good cop bad cop scheme, which we see in action here.

6 members found this post helpful.

Agreed. When Red Hat decided it was their mission to profiteer off GNU/Linux the result was a downward spiral we've been forced into thanks to them. The only people who can break this destructive fall are the very people who are standing around wanting Linus to do something... the community. If the community wants to break Red Hat's hold on GNU/Linux, then it needs to do so.

If Linus could break the hold of UNIX with the efforts of GNU with Linux.

Why can't the community of GNU/Linux users stand up to Red Hat and strike them down all the same?

All the more the same, the cat's out of the bag. Time for more popcorn! :evil grin:

7 members found this post helpful.

One of the things that bothers me is: Why does systemd have to do... Well, everything?

Start Processes
Stop Processes
Backwards Compatible with initd
Optional Support for declarative startup configs (needed to prevent async race and dependency-ladder processes)
Classic Run levels run classic, moving processes to declarative scripts enables async.
Async groups are started by named declarative script, rather than a number... this clearly separates SystemV from Async behavior in unambiguous way.
Optional: Find and kill wayward forks.

That's all it NEEDS to do, and it's only a couple of more things that SysV does.

I mean, look at these: http://en.wikipedia.org/wiki/File:Sy...components.svg && http://en.wikipedia.org/wiki/File:Li...nd_systemd.svg

PID1: init, login, log, network, user session...

Even WINDOWS doesn't do that! SMSS.exe (initd equiv) is PID1 (I think), which calls csrss.exe (client/server mgr) and winlogon.exe (user session mgr) and monitors them.

Winlogon manages all user processes, csrss manages all daemon type processes (net, IIS, log, etc.) The only job SMSS has is to launch and watch those to, start one if it dies and trigger kernel panic if either is killed manually by an Administrator. Systemd appears to place all that functionality, and more... in PID1. You can't replace that without a reboot, it's one hell of a single point of failure.

3 members found this post helpful.

They can. By using Slackware, Gentoo, Crux, LFS, ...

1 members found this post helpful.

Ubuntu can quite easily revert is decision, and quite frankly so could Debian (and they should to but the politics on the Debian mailing list would be as bad as on the kernel list). Upstart is a viable system and it is probably one of the only things from Ubuntu that isn't used already that Debian should use. In other words it isn't to late, things could turn around on many fronts but it seems increasingly unlikely that the turnaround will be in systemd.

I do agree with Tobi though, not to often that happens, if systemd is creating a situation where the kernel is crashing the kernel obviously has a problem as well.

Not a good comparison at all. The problem could be as simple as engine timing or torque curve. Drop a 6 speed g/box with an 0.50 overdrive and expect an old carby v8 from the early 1960s in a 2 ton car to pull 100kmh and be happy with any acceleration in that gear you've got another thing coming. The g/box is not at fault, the owner should have done some research and s/he would have realised the engines torque and power curves are not suited to the new g/box.

1 members found this post helpful.

I've hesitated to make my mind up about Red Hat's role in this mess. But now we have more data. The person who raised the problem on LKML this week is a prominent kernel hacker for Red Hat, and he is evidently unhappy with systemd, and not frightened to stir things up. So (IMO) the Red Hat conspiracy theory needs, at a minimum, to be refined somewhat, and we certainly don't want to be unkind towards Mr Rostedt, who has achieved more against systemd than all the Debian systemd sceptics put together. Red Hat management needs to know that Mr Rostedt is making Red Hat look good.

IMO there has been a big problem with pro-systemd people not fully disclosing their allegiances in forum advocacy (not naming names, because that would be invidious, but LWN and Phoronix are two places where this is endemic). As a consequence of that, we've been saying 'Red Hat' when we should perhaps have been saying 'FDO people' or 'Friends of Gnome' or 'Fedorasts'. This is a trap laid by the other side. It would be far more effective to argue on the merits instead. See Graham's Hierarchy of Disagreement.

2 members found this post helpful.

That is simply factually wrong, you really should update your knowledge about systemd. Those things are not running in PID1.

1 members found this post helpful.