4 ms·

> whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at

by jude- 12y ago

> whereas dbus and systemd and gstreamer can move fast and break things I think you will find that this attitude is exactly the opposite of what is expected at the plumbing layer. Move fast and break things is fine when no layers depend on you to remain stable (see also, the Web). Imagine how hellish life would be if Linus et al. took this attitude towards kernel development.

zanny 12y ago
The kernel does not have a stable ABI, and none of the developers really commit to significant backwards compatibility - they just maintain LTS kernel tree branches for those that want to stay in one spot. The same thing happened with the gstreamer 0.x and 1.x forks, except every Linux release is effectively a new GST release, albeit the APIs userspace uses against the kernel rarely break, it is a huge spread of APIs and one or another usually does change each release.
- pdkl95 12y ago
  Can I use software written for an release (lets say 0.8.x) of gstreamer, and have it run correctly against a modern release (such as 1.2.x or 1.4.x)? Because that works with th kernel, as it most certainly does have a stable userspace ABI. Internal stability is not a big concern unless you're trying to hide the source code (proprietary driver). Linus' guarantee about not breaking userspace is very widely known, so I'm sure you know this. The GP was absolutely correct: while you have the luxury of being able to "move fast and break things" as a leaf app that nobody depends on[1], for most everything else "reliability" and "doesn't give me lots of extra work" are far more important than any other feature. This is really just an extension of why it is considered a good idea to write maintainable, modular code instead of leaving people with a mess of spaghetti to debug. [1] That changes if your userspace grows and people ARE depending on it.

by jude- 12y ago

zanny 12y ago

The kernel does not have a stable ABI, and none of the developers really commit to significant backwards compatibility - they just maintain LTS kernel tree branches for those that want to stay in one spot. The same thing happened with the gstreamer 0.x and 1.x forks, except every Linux release is effectively a new GST release, albeit the APIs userspace uses against the kernel rarely break, it is a huge spread of APIs and one or another usually does change each release.

pdkl95 12y ago
Can I use software written for an release (lets say 0.8.x) of gstreamer, and have it run correctly against a modern release (such as 1.2.x or 1.4.x)? Because that works with th kernel, as it most certainly does have a stable userspace ABI. Internal stability is not a big concern unless you're trying to hide the source code (proprietary driver). Linus' guarantee about not breaking userspace is very widely known, so I'm sure you know this. The GP was absolutely correct: while you have the luxury of being able to "move fast and break things" as a leaf app that nobody depends on[1], for most everything else "reliability" and "doesn't give me lots of extra work" are far more important than any other feature. This is really just an extension of why it is considered a good idea to write maintainable, modular code instead of leaving people with a mess of spaghetti to debug. [1] That changes if your userspace grows and people ARE depending on it.