Comment by viraptor | Hacker News Reader

Comment by viraptor | Hacker News Reader

Parent Full thread

While systemd has some good parts...

0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own.

1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common)

3: This is a strange claim when talking about an init system that effectively starts managing devices.

6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again.

8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here.

There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...

0: Kay wrote udev. He is now a lead contributor to systemd... 1: Upstart was hobbled by the Canonical CLA. Several systemd contributors cite this as the reason for starting systemd in the first place. 3: See 0 6: See 1 8: logind is developed as part of the systemd suite, but is entirely modular and in fact is used with non-systemd inits via systemd-shim.

I don't believe the CLA was the main reason for starting systemd. Otherwise they'd just fork upstart and continue to work on it without signing anything. CLA has nothing to do with technical features either.

I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system).

If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.

From Scott Remnant, who wrote Upstart when he worked at Canonical[1]:

"I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA

If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :)"

The CLA is absolutely why systemd exists. systemd didn't fork because there was no benefit to anyone in sharing code -- Upstart wouldn't take their patches. There are technical differences, but those could have been handled in code (like Scott says) if the CLA hadn't existed.

1 https://plus.google.com/+KaySievers/posts/C3chC26khpq

I just don't buy it. The license allows them to clone upstart. Why would they care about upstream taking their patches if they were ready to start a new project anyway? If technically there was no problem for upstart to be the successful project, then what was the reason they didn't simply rename it and start from there? Dropping the whole history and starting from scratch doesn't seem like a reasonable choice in that case.

...so you're saying that you don't buy the statements of both the people who started the systemd project AND the person who was running Upstart at the time, about what prevented them from collaborating?

Not about what prevented them from collaborating. The original claim I disagreed with was "Several systemd contributors cite this as the reason for starting systemd in the first place."

This does not make sense to me. They could fork it if it was good enough. If they started from scratch, then CLA wasn't the main issue. It's like "the corner store didn't have the milk I like today so I had to start my own farm".

This really isn't difficult to understand (again, just read the link above, the people actually involved go into it). The systemd people believed there were technical flaws in Upstart. They talked to the person in charge of Upstart, who was amenable to their points. They looked into collaborating, but the CLA stood in the way of that.

If there was no CLA, the folks who went on to develop systemd could have decided that the benefits of collaborating with an existing project were greater than the benefits of writing systemd from scratch. And everyone involved seems to agree that that's what would have happened. Yes, as a purely technical matter, the systemd people decided starting from scratch was better than forking Upstart. But the reason it was a purely technical decision was their refusal to sign the CLA, which meant the ONLY considerations were technical. But there are other considerations that could have swung the decision the other way if not for the CLA.

>Kay wrote udev. He is now a lead contributor to systemd...

Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.

Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).

Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.

From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.

Reply on news.ycombinator.com