Revisiting How We Put Together Linux Systems


I've been using Linux for decades and don't understand that at all. Considering it is coming from the systemd authors, no surprise.

(EDIT: Notice there are no comments allowed? :unsure: )
 
Last edited by a moderator:
Makes it clear where systemd is coming from and why it is crap.

That there is no generic solution for everything is basic and required software architect knowledge. People like the author of the above link are also useless as developers, because instead of contributing they spend valuable time on useless 'frameworks' and disrupt the work of the team by insisting on talking about irrelevant aspects. If by accident you have hired someone like this, you either fire them ASAP (therefore you can often detect them prior to hiring by their resume, fortunately) or if you work for the government like me where this is not an option, you put them on very small projects where they can't do much damage.
 
Oh my. The amount of bashing that will generate even before any details are revealed will be huge :p

The comments are probably disabled because they want interested parties contact them directly instead of drowning in a sea of knee-jerk reactions.

I'll reserve my judgement until they have something to show, but for now it's at least an interesting attempt to follow.
 
ho my gosh, no way... thanks for trying to fix something that is not broken...
Seems to me like the article outlines several ways in which things are, in fact, broken, they're just broken in ways we're aware of and accept as necessary.The problem with what they're trying to do, of course can be summed up in a three panel comic about stick figures.

standards.png
 
OT, it's an interesting article with shades of the discussions that led to the PND system and are leading to the Pyra's packaging system. I think they tend to overstate the problems of a heirarchical packaging system a little, and perhaps overstate the advantages of an appstore to a similar degree, but there are some ideas there worth considering.


However, I tend to only see problems arising from their proposals. They may be right that btrfs' dedup will save us from software from different sources all using different runtimes, but one of the advantages of a discrete packaging system is that you can patch bugs in libs without rebuilding everything else. Next time we get an OpenSSL gotcha, as much fun as that was, the work involved is not simply fix it and publish, it's fix it, publish, publish a new runtime, then republish all the apps that depend on the old runtime, unless I've skipped over part of the proposal that allows ad-hoc updates.
 
Tangentially relevant: article about a "boycott systemd" page (on phoronix) and a good refuting comment.

On topic, I agree with vinipsmaker above. Depending on features isn't bad, but depending on btrfs itself is a harder dependency than is needed. I'd rather they'd define some interface the system hinged upon, like "from this point on I expect this package to be mounted there", which could have implementations using btrfs subvolumes, unionfs or loop mounting and filesystem files. Btrfs might still well be the most used and performant one. In systemd they do stuff like this using dbus interfaces without depending on actual implementations of the services. Why not here?
 
Back
Top