vinipsmaker
Member
Reminds me of the package format threads we sometimes have: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Revisiting How We Put Together Linux Systems
- Thread starter vinipsmaker
- Start date
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.
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.
bzar
A Commando
Oh my. The amount of bashing that will generate even before any details are revealed will be huge 
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.
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.
sebt3
homebrew player (P. & C.)
ho my gosh, no way... thanks for trying to fix something that is not broken...
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
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.
levi
Still fresh, damnit!
Ob. linkback to XKCD so you can at least see the mouse over message (which is surprisingly pertinent to this community).
levi
Still fresh, damnit!
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.
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.
vinipsmaker
Member
I don't have a problem with the dependency against *features* from btrfs, but depending on btrfs is problematic.
And I agree with everything you said.
bzar
A Commando
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?
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?
