From what I read here, systemd is a lot less modular by bundling in a lot of services. Linux has had the virtue of modularity at is core, as exemplified by narrow-focus command line tools piped together to get work done. Modularity is something like cleanliness. If you leave crumbs all over your kitchen all the time, it generally isn't itself the problem. The problem is when roaches and mice move in and you can't get rid of them due to the crumbs you still leave everywhere. Granted, cleanliness (and modularity) can perhaps go too far (the person who scrubs the kitchen flour every five minutes). So, what is a healthy balance here? I don't know enough about the details to weigh in on that. You ask for specific problems, and while a reasonable sounding request, that is also a bit like asking people to send pictures in of specific roaches and mice. The specific problems are important of course, but what is at stake is the bigger picture, not stamping out each individual roach. What matters is increased risk. The more general issue is the management of risks from complexity, whereas modularity is one of the best (but not the only) approach for doing that.
I've seen how lack of modularity can damage other software communities -- particularly the early Squeak community, like I wrote about here
http://lists.squeakfoundation....
"I sympathize. I think the biggest issue of Squeak is issues with modularity and managing complexity. These issues translate to frustration for maintainers (and users :-). Anyway, I had related frustrations to yours many years ago and they are why I ended up doing a lot in Python and Jython on the JVM in the last decade, even to the point of working on PataPata. ... I think the most important single issue in maintaining any large system is managing complexity (documenting intent maybe comes next, including well-named variables and methods and functions). This has never been a priority for Squeak IMHO. ...
There are several ways to manage complexity, which include:
* modularity (namespaces, packages like Java or GNU Smalltalk or Debian, letting someone else do that hard work by leveraging libraries or VMs or languages, like Squeak does by using a C compiler to generate the VM)
* cleverness (brilliant redesign, like traits was hopefully going to be)
* laissez faire, and also to each his or her own image (that is what we have now, and it is not that bad an idea, if the *core* is small and well thought out, like Spoon, so the *image* instance becomes the *module*. But alas, it is not, witness how confusing Morphic is to unravel).
Modularity is the one way to manage complexity which seems to work best in practice, although the others have their role. However, if Squeak images could easily talk to each other and share some state, and we had Spoon-like remote debugging and development, then we could have just one application per image, and that would be easier to maintain (it would be modular to a degree but in an unusual way). But I would still suggest such a system built on well-though out (clever) modules would be more powerful and easier to use than a mess of spaghetti code, even if we had only one application per image."
With roots back to here in 2000:
http://lists.squeakfoundation....
"Squeak complexity in 2.8 has become a complex cat from the simple kitten complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov 1996 those prescient words: "The Squeak team has an interest in doing the world's simplest application construction framework, but I suspect that we will get sucked up with enough other things that this won't happen in the next two months (but who knows...)."
Squeak 2.8's complexity is now quiet (in terms of walkbacks) and stealthy (in terms of growing between releases without a complaint). And the complexity could be deadly. Witness the recent issue Stefan raised about some Squeak fonts possibly violating a Microsoft EULA. The question should never even arise of the legal integrity of the core release. We might as well just leap right into those jaws of complexity. ... "
Granted, Squeak has finally much improved since those years -- but the cost to the community as enormous from all the missed opportunity... Squeak limps along, and is a better and better system, and spinoffs like Amber Smalltalk and Pharo are awesome, but so many other systems grabbed Squeak's mindshare that Sqeuak faces big uphill struggle at this point. It never got to be the Flash replacement it could have been in browsers, or the Java-killer, or lots of other thing it could have been (the alternative to Python...).
For its own flaws (including those inherent in JavaScript), NodeJS seems to have gotten modularity right and can support that picture I painted above for Squeak of special-purpose application-focused servers talking to each other:
http://www.futurealoof.com/pos...
"All you people who added node_modules to your gitignore, remove that shit, today, it's an artifact of an era we're all too happy to leave behind. The era of global modules is dead."
Maybe what frustrates so many Linux developers is to see such an obvious problem going ignored, like for a master chef to have a new restaurant owner come in who is intentionally throwing bread crumbs all over the floor because is "looks nice"? Or, for another analogy, like an experienced firefighter being forced to live in a wood house overflowing with years of un-recycled newspapers supposedly protected by some funky new smoke detector system that is unproven and behind the scenes is implemented using a rat's nest of unlabelled wires?
That said, again, I don't know enough about systemd to know if it does indeed make good overall tradeoffs. I'm just building on the complaints about it I've read here. Things can be too clean. Humans need bacteria to survive. Evolution tends to produce odd efficiencies of unexpectedly interacting systems. So, I'll continue to watch how this plays out...
But Joey's biggest complaint seems to be about the social process. It seems to me that all social systems tend to attract parasites and rent seekers eventually. It can be hard to manage that sometimes without moving on and just waiting for the inevitable collapse before recolonizing. As Clay Shirky says:
"A Group Is Its Own Worst Enemy"
http://www.shirky.com/writings...
"What matters is, a group designed this and then was unable, in the context they'd set up, partly a technical and partly a social context, to save it from this attack from within. And attack from within is what matters. Communitree wasn't shut down by people trying to crash or syn-flood the server. It was shut down by people logging in and posting, which is what the system was designed to allow. The technological pattern of normal use and attack were identical at the machine level, so there was no way to specify technologically what should and shouldn't happen. Some of the users wanted the system to continue to exist and to provide a forum for discussion. And other of the users, the high school boys, either didn't care or were actively inimical. And the system provided no way for the former group to defend itself from the latter.
Now, this story has been written many times. It's actually frustrating to see how many times it's been written. You'd hope that at some point that someone would write it down, and they often do, but what then doesn't happen is other people don't read it.
The most charitable description of this repeated pattern is "learning from experience." But learning from experience is the worst possible way to learn something. Learning from experience is one up from remembering. That's not great. The best way to learn something is when someone else figures it out and tells you: "Don't go in that swamp. There are alligators in there."
Learning from experience about the alligators is lousy, compared to learning from reading, say. There hasn't been, unfortunately, in this arena, a lot of learning from reading. And so, lessons from Lucasfilms' Habitat, written in 1990, reads a lot like Rose Stone's description of Communitree from 1978.
This pattern has happened over and over and over again. Someone built the system, they assumed certain user behaviors. The users came on and exhibited different behaviors. And the people running the system discovered to their horror that the technological and social issues could not in fact be decoupled. ..."
So, systemd sounds nice in practice -- let's bundle all the important services together and finally get all the bugs fixed *this* time -- but in practice, experienced developers worry that the bundling creates a big technical and social problem of maintenance and debugging and related discussions and management.
I might have succeeded in 2000 with rallying Squeakers to make a better system back then, sparing years of frustration and bit rot for so many people, but there were several people (including a "lawyer") who claimed Squeak was just fine as it was, that the quirky non-open-source-recognized license did not matter and that modularity was not an import priority and so on... I'm glad those issues have been mostly fixed for Squeak in something lie Pharo, but it took many years of painful reality for the community as a whole to wake up to them become priorities, losing many good people along the way -- even losing Dan Ingalls to JavaScript...
http://www.infoq.com/interview...