It can also be dangerous to reuse code that's poorly implemented or maintained. This is particularly true with cryptography. I often see libraries as a painful compromise because I know I could do a better job if I had the time to invest. Sometimes I can't make that compromise.
Conversation
Yeah, the flip side of “never write your own ___” is when everyone ends up uncritically using a poor off the shelf implementation, whose flaws then end up getting revealed
1
2
I wrote about on my feelings on this here to try to steer other people away from adding external dependencies and then being disappointed that I won't accept the code:
grapheneos.org/build#library-
I've often had bad experiences where I think a library looks good and am proven wrong.
1
1
This applies 10x to anything tied to web development. In most cases, if it's not supported by the browser or standard library, I have no interest in using it, especially on the client. Supporting only the latest versions of each browsers (Edge, not IE) helps a lot with that.
1
I have high standards for libraries and a deeply seated fear of them making backwards incompatible changes not considering my use case leaving me screwed. I won't touch anything tied to GTK+, GNOME, freedesktop.org. In some ecosystems (web), libraries come and go as fads.
1
2
2
Why freedesktop.org? I agree with you about GNOME and GTK+ but I thought free desktop.org was a cross-platform initiative
1
They're extremely guilty of replacing the standards / implementations over and over again because they don't invest the time in coming up with a reasonable design from the start. Flatpak in particular is another total joke and doesn't even learn from 2008 era app security...
1
1
If you think PipeWire replacing PulseAudio is going to be the end of that saga... or Wayland replacing X11...
When the replacements are so extremely flawed and impractical it's no wonder it takes no long to migrate to them and by the time it's getting done there's a replacement.
1
I could just point in the general direction of systemd and all the defacto standards tied to it. I don't understand the design approach. I don't understand writing all this new code in C either, particularly when the people doing it clearly don't have much understanding of C.
1
1
1
It's mostly completely oblivious to secure design and implementation approaches. Security is treated as if the way it's accomplishing is checking off a list of entirely optional user-facing features, with a completely insecure implementation / foundation underneath that.
1
1
1
Flatpak application security is literally opt-in and it's essentially designed around just giving access to everything and opportunistically eliminating it. Applications choose if they want to do things in a way that respects privacy and user consent or just use the old approach.
So, from the start, most of these technologies are disposable ones designed in a way that they need to be replaced. There's a weak attempt at making something incrementally better with the expectation that everyone puts in massive effort to migrate just for it to be replaced.
1
1
1
Anything using D-Bus which is most of this technology stack is dead on arrival since that's such an awful dead end approach. It was totally rejected for inclusion in the kernel which they needed to make it somewhat less bad. It's a massive security issue as it exists right now.
1
2
2
Show replies