10 ms·

I'll take bloat over dependency hell every day of the week. Feels like every single app is a bundled web browser these days anyways.

palata 3y ago
> dependency hell Dependency hell comes from bad dependencies that don't do semver properly. Choose your deps carefully, and that's perfectly fine. > Feels like every single app is a bundled web browser these days anyways. Yep, that's apparently the best way to use the bad libraries people want to use and not give a damn about semver.
- hn_go_brrrrr 3y ago
  Semver is nearly impossible to do "properly" because of https://xkcd.com/1172 https://xkcd.com/1172. With a sufficient number of users, all bug fixes are breaking changes. If the behavior can possibly be observed in any way, some user will be depending on it, deliberately or otherwise.
  - Ar-Curunir 3y ago
    Semver defines what is breaking and not-breaking. E.g., Rust semver says that "code should continue compiling with a minor version bump, but not necessarily for a major version bump"
    - steveklabnik 3y ago
      Yes. The very first line of the spec: > Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. If it's not in the API, it is not bound by the rules. Many ecosystems come up with various norms, like Rust has, to help guide people in this. But it's almost certainly not a semver violation to make the change described in the XKCD because "handle unknown unknowns" is not possible. That doesn't mean that we should throw out the entire idea of software assisted upgrades to dependencies.
  - palata 3y ago
    I would argue that https://xkcd.com/1172 https://xkcd.com/1172 is a case where the user "deserves" the breaking change, because they relied on a hack in the first place. That's the thing: I feel like people tend to call "dependency hell" what I would consider downright malpractice. "Shared libraries don't work because they require good practice" is, IMO, not a good argument against shared libraries. If you need to design your tool with the constraints that "users will use it wrongly", then it's already lost.
  - dwattttt 3y ago
    Semver doesn't stop people from depending on unstable/implementation-specific behaviour; it needs to be coupled with a strong mechanism for defining what behaviour is defined by an API, and the result is that "the bug" is with all those users who depend on un-guaranteed behaviour. The breaks happen regardless, but you have a principled way of defining whose fault/problem it is.
- IshKebab 3y ago
  There are various kinds of "dependency hell". To be honest I can't think of any that are due to not doing semver properly. Usually it's: 1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby's advice for how to install Ruby is "use your package manager; you will get an old version btw fuck you". 90% of the time it's bloody glibc. Every Linux user has run into the dreaded glibc version error dozens of times in their career. 2. Software that can't install multiple versions of the same package, leading to diamond dependency issues. Python is very bad for this.
  - palata 3y ago
    > Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro. Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?
    - IshKebab 3y ago
      > maybe you don't want that distro Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work). But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I use is closed source so that's not even an option. The only real option is Docker (or Apptainer/Distrobox etc), which sucks. The fundamental model of "we'll just ship all software that exists; all software is open source" that most distros try to use is just fundamentally wrong. Snap and Flatpak are trying to fix that but in my experience they aren't remotely ready yet.
- avgcorrection 3y ago
  It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago and which has been adopted in some communities but not in many others. And besides there is plenty of (1) human judgement about what is breaking and not (which goes against machine-readability), and (2) worrying about the minutiae of what is a “patch” and a “feature”, and (3) weird implicit social taboos about doing major releases “too often” (?).[1][2] Most things might be solved by everyone doing SemVer. And for all I know some communities might be running like greased pigs in a chute exactly because they use SemVer (I don’t tend to hear about the everyday everything-is-working stories on HN). But also doing static linking a bit more seems like it would help a lot with the same problem. [1] All based on discussions I’ve seen. Not really personal experience. [2] Again, making a spec/manifesto which is both about machine-readability and about shaming people for vague things is very muddled. Although I don’t know how much the latter is about the culture around it rather than the spec itself.
  - palata 3y ago
    Good points. > It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago Well by "semver" I mostly mean "change the major number to indicate a change of ABI", I don't mind so much about the other numbers in this case. But that's a good question: I don't know when it started being a thing. I would guess much, much earlier than GitHub, though. > human judgement about what is breaking and not Hmmm... ABI compatibility for the public interface is not really subjective, or is it? > weird implicit social taboos about doing major releases “too often” Yes I don't get that one and I fight hard against it. > But also doing static linking a bit more seems like it would help a lot with the same problem. Well I am not fundamentally against static linking; to me it makes sense to do a mix, with the caveat that if you link something statically, then you are the maintainer of that code. Whereas if you link a system library dynamically, you merely depend on it. My problem is about moving to "static linking only" (or "by default", but I don't even know if Rust allows dynamic linking at all?).
nerpderp82 3y ago
Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. Instead we still create environments that look like replicas of whole hosts. Might as well go all in and use something with pervasive virtualization like Qubes. https://www.qubes-os.org/ https://www.qubes-os.org/
- deleted 3y ago
  [deleted]
- palata 3y ago
  To be fair, QubesOS does not really solve the problem of bad libraries creating dependency hell. If you need to ship every app with its own rootfs because you can't handle dependencies, then you will have to do that on QubesOS as well (you don't want one VM per app). Also the biggest problem I had with QubesOS is that it doesn't support GPU (for security reasons). It feels like that was a big cause for the reduced performance. I wish there was a solution for the GPU, and then I would love to daily-drive QubesOS.
  - soulofmischief 3y ago
    Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.
    - TimeBearingDown 3y ago
      I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-linux-hvms-for-cuda-applications/9515 https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qubes-os-with-virtualgl/20265 https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qub... Yes, the passthrough is probably a huge avenue for attacks. Possibly VirtualGL too, I know less about that.

palata 3y ago

> dependency hell Dependency hell comes from bad dependencies that don't do semver properly. Choose your deps carefully, and that's perfectly fine. > Feels like every single app is a bundled web browser these days anyways. Yep, that's apparently the best way to use the bad libraries people want to use and not give a damn about semver.

hn_go_brrrrr 3y ago
Semver is nearly impossible to do "properly" because of https://xkcd.com/1172 https://xkcd.com/1172. With a sufficient number of users, all bug fixes are breaking changes. If the behavior can possibly be observed in any way, some user will be depending on it, deliberately or otherwise.
- Ar-Curunir 3y ago
  Semver defines what is breaking and not-breaking. E.g., Rust semver says that "code should continue compiling with a minor version bump, but not necessarily for a major version bump"
  - steveklabnik 3y ago
    Yes. The very first line of the spec: > Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. If it's not in the API, it is not bound by the rules. Many ecosystems come up with various norms, like Rust has, to help guide people in this. But it's almost certainly not a semver violation to make the change described in the XKCD because "handle unknown unknowns" is not possible. That doesn't mean that we should throw out the entire idea of software assisted upgrades to dependencies.
- palata 3y ago
  I would argue that https://xkcd.com/1172 https://xkcd.com/1172 is a case where the user "deserves" the breaking change, because they relied on a hack in the first place. That's the thing: I feel like people tend to call "dependency hell" what I would consider downright malpractice. "Shared libraries don't work because they require good practice" is, IMO, not a good argument against shared libraries. If you need to design your tool with the constraints that "users will use it wrongly", then it's already lost.
- dwattttt 3y ago
  Semver doesn't stop people from depending on unstable/implementation-specific behaviour; it needs to be coupled with a strong mechanism for defining what behaviour is defined by an API, and the result is that "the bug" is with all those users who depend on un-guaranteed behaviour. The breaks happen regardless, but you have a principled way of defining whose fault/problem it is.
IshKebab 3y ago
There are various kinds of "dependency hell". To be honest I can't think of any that are due to not doing semver properly. Usually it's: 1. Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). E.g. this very day I ran into a bug where some Asciidoctor plugin craps out with an error because my version of Ruby isn't new enough. Ruby's advice for how to install Ruby is "use your package manager; you will get an old version btw fuck you". 90% of the time it's bloody glibc. Every Linux user has run into the dreaded glibc version error dozens of times in their career. 2. Software that can't install multiple versions of the same package, leading to diamond dependency issues. Python is very bad for this.
- palata 3y ago
  > Software depending on versions of libraries that are newer than the latest version available on the distro you have to use (cough RHEL 8). That is a fair point, but it raises a question: if you absolutely need to use software that is not packaged by your distro of choice and that you cannot package yourself (are you sure you can't maintain a "community" package yourself with RHEL?), maybe you don't want that distro. Different distros come with different goals. If you take a "super slow but secure" distro, it will be slow and secure. If you take a rolling distro, you get updates very quickly but it has drawbacks. It depends on the use-case, but going for a "slow and secure" distro and then building tooling to work around that choice ("nevermind, I'll ship new and less mature software anyway, statically linked") seems to defeat the purpose of the distro... right?
  - IshKebab 3y ago
    > maybe you don't want that distro Well I definitely don't want RHEL 8 but unfortunately I have to use it because some software I use requires it (RHEL 9 doesn't have old enough versions of some libraries) or is only certified on it (this is for work). But even if I was using a more modern distro, none of them have all software packaged. And no I obviously don't want want to become a packager. Some of the software I use is closed source so that's not even an option. The only real option is Docker (or Apptainer/Distrobox etc), which sucks. The fundamental model of "we'll just ship all software that exists; all software is open source" that most distros try to use is just fundamentally wrong. Snap and Flatpak are trying to fix that but in my experience they aren't remotely ready yet.
avgcorrection 3y ago
It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago and which has been adopted in some communities but not in many others. And besides there is plenty of (1) human judgement about what is breaking and not (which goes against machine-readability), and (2) worrying about the minutiae of what is a “patch” and a “feature”, and (3) weird implicit social taboos about doing major releases “too often” (?).[1][2] Most things might be solved by everyone doing SemVer. And for all I know some communities might be running like greased pigs in a chute exactly because they use SemVer (I don’t tend to hear about the everyday everything-is-working stories on HN). But also doing static linking a bit more seems like it would help a lot with the same problem. [1] All based on discussions I’ve seen. Not really personal experience. [2] Again, making a spec/manifesto which is both about machine-readability and about shaming people for vague things is very muddled. Although I don’t know how much the latter is about the culture around it rather than the spec itself.
- palata 3y ago
  Good points. > It seems impossible to solve this by just everyone adopting a manifesto that one GitHub guy wrote many years ago Well by "semver" I mostly mean "change the major number to indicate a change of ABI", I don't mind so much about the other numbers in this case. But that's a good question: I don't know when it started being a thing. I would guess much, much earlier than GitHub, though. > human judgement about what is breaking and not Hmmm... ABI compatibility for the public interface is not really subjective, or is it? > weird implicit social taboos about doing major releases “too often” Yes I don't get that one and I fight hard against it. > But also doing static linking a bit more seems like it would help a lot with the same problem. Well I am not fundamentally against static linking; to me it makes sense to do a mix, with the caveat that if you link something statically, then you are the maintainer of that code. Whereas if you link a system library dynamically, you merely depend on it. My problem is about moving to "static linking only" (or "by default", but I don't even know if Rust allows dynamic linking at all?).

nerpderp82 3y ago

Dynamic Library hell is why Docker exists. If operating systems had less global state and less ambient authority, our systems would be vastly more tractable. Instead we still create environments that look like replicas of whole hosts. Might as well go all in and use something with pervasive virtualization like Qubes. https://www.qubes-os.org/ https://www.qubes-os.org/

deleted 3y ago
[deleted]
palata 3y ago
To be fair, QubesOS does not really solve the problem of bad libraries creating dependency hell. If you need to ship every app with its own rootfs because you can't handle dependencies, then you will have to do that on QubesOS as well (you don't want one VM per app). Also the biggest problem I had with QubesOS is that it doesn't support GPU (for security reasons). It feels like that was a big cause for the reduced performance. I wish there was a solution for the GPU, and then I would love to daily-drive QubesOS.
- soulofmischief 3y ago
  Same, I love Qubes' philosophy and UX, but GPU passthrough support was a dealbreaker in the end and I switched to a KVM system.
  - TimeBearingDown 3y ago
    I’m pretty sure GPU passthrough does work in Qubes HVMs, although I haven’t tried it myself. Here are three quick and recent tutorials I found including one with a newer VirtualGL approach that offloads work instead of passing the entire card. https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://neowutran.ovh/qubes/articles/gaming_windows_hvm.html https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-linux-hvms-for-cuda-applications/9515 https://forum.qubes-os.org/t/nvidia-gpu-passthrough-into-lin... https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qubes-os-with-virtualgl/20265 https://forum.qubes-os.org/t/seamless-gpu-passthrough-on-qub... Yes, the passthrough is probably a huge avenue for attacks. Possibly VirtualGL too, I know less about that.