This was discussed before here: https://news.ycombinator.com/item?id=15843631
[deleted]
Re: Integrating "safe" languages into OpenBSD? (2017)
201–210 of 400 posts
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#202Earlier quoted context omitted.
How much do your programs really share? After libc, libm, and pthreads, the most common thing they link to is probably pcre, and I'm sure you can guess how many of your programs are using that. A good linker will shave off the parts of a library you're not using, and the parts which are left over are usually not very big. The problem isn't with static linking, it's that some "developers" think that bundling an entire…
Dynamic linking is pretty common in GUI applications (xlib, GTK/QT). Server-side there's also libssl, xml libraries, zlib, curl.
Outside of OS distro packaging, most Qt apps actually copy dynamically linked Qt binaries to the same app folder for re-distribution to end users within some form of installer or disk image. The same probably applies to Gtk apps too, as I think the last time I manually installed Gtk for Windows for a Gtk app was a decade ago.
Dynamic linking only works if you can guarantee ABI stability and folks haven’t had to deal with ABI changes since C++13 to the point where if the C++ folks can’t change the ABI by C++23 we will forget it was ever a problem because we’ll make the cost of change too hard. And the current C++ ABI currently makes some parts of C++ executables sub-optimal unless you hunt down your own standard-library alternatives.
Additionally, with dynamic linking, both code authors and code users now need to agree on versions to support under assumptions that newer features in newer libraries aren’t worth adopting quickly. To that end, some OSes do update dynamic libraries more quickly, but doing so theoretically requires a lot more recompilation and potentially you’re downloading the same binaries more than once. At that point, dynamic linking is worth less than a binary-optimized compression algorithm, no? Especially for distributing changes to said executables.
Which isn’t to say, for OS distros, that dynamic linking is bad, far from it, it tends to be the only valid solution for programming against OS core components, but that in our haste to update dynamic libraries independently of code compiled for them, we tend to forget ABI compatibility and the costs to maintain API compatibility across a wide variety of dependency versions for packagers and developers (or alternatively, the lack of updates to new library features for end users).
Windows APIs never changing is the reason Windows stagnates more than macOS, where Apple is less afraid to say your older app simply won’t run any longer. Linux suffers less from this, but as pointed out in the email, part of that is because POSIX implementations are relatively stable over decades, whether or not significant improvements are still possible for more modern UX or security, for example.
The details of dynamic linking on OS platforms can be found in this recent series of posts: https://news.ycombinator.com/item?id=23059072 (in terms of stability guarantees besides libc dynamic linking)
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#203Earlier quoted context omitted.
after you are done downloading all the source.
You can check that the source hasn’t been tampered with before starting the build, and know you’re building the right code base. Builds that curl junk and use a dozen language specific package managers don’t have that property.
That is exactly the set of properties you get with Rust and Cargo: that the source hasn't been tampered with, and that you know you're building the right codebase. It would be deeply irresponsible to build a package management system without those properties.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#204Earlier quoted context omitted.
You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.
> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for y…
Understanding make is the easy part.
Manual dependency resolution is a tedious waste of time, no matter how well you understand what you are doing. It can and should be automated.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#205Earlier quoted context omitted.
This rule is not just dumb, it is retarded. I maintain a quite popular open source project, and OpenBSD maintains a fork. They try to submit patches every now and then, but every time it happens, I ask them to please also submit a test that makes CI fail without the patch, and pass with it. They can't, so OpenBSD remains unsupported. The problem is that there isn't a supported cross-compilation toolchain from any maj…
I don't know what project this is but a blanket "add a test which fails without your patch for EVERY PATCH no exception" rule is a bit cargo-culty. Especially since the kind of test you're asking for, when written by a developer who is less than passionate about writing such a test but rather more passionate about just solving the problem his patch addresses, is probably not going to be worth much compared to a prope…
If you're saying great tests are better than adequate tests, nobody's disagreeing. But untested code puts a variety of burdens on project maintainers. I don't see why maintainers should be obliged to take on that burden when the person wanting the patch won't bother.
Also, I don't see your quoted rule in the post you're responding to. Instead I see them saying that in a specific case, they ask for tests with patches. How did you get from that specific case to such a universal, no-exceptions rule?
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#206Earlier quoted context omitted.
Agreed on a hundred thousand. I used to feel sheepish defending npm and the whole node package ecosystem against its critics, but once I started trying to run deep learning applications or WebRTC media servers I quickly realized that some of the critics are probably coming from a much worse package management system that they’ve merely grown familiar with. Want to have two pieces of software on one computer that rely…
"two different versions of libwebsockets" If your programs depend on different MAJOR versions of libwebsockets and libwebsockets' build system doesn't easily allow that to happen then complain to the developer of libwebsockets about it. If the developer of libwebsockets is not interested in solving this problem then complain to the developers of the programs which depend on libwebsockets that they should find a bette…
My issue is that the default behavior is to install these libraries globally, even when they could probably be installed locally for the thing you’re trying to build. (I picked libwebsockets out of the air, I don’t necessarily have a complaint with that particular library)
On my old MacBook Pro I have dozens of node projects that I’ve downloaded over the years just to mess around. If I ever want to clean up, I can delete a project’s folder, and know that everything it installed is now gone (because it would be in its node_modules folder).
On my linux desktop if I want to mess around with a cool project that’s written in C/C++ I immediately pull out Docker and start trying to build up an image, since I don’t want to pollute my global library folders with libraries that I might be downloading just to try out this one thing. I can then delete the docker image if I want to clean up. This works, but it feels like a workaround to the main problem of libraries being global.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#207Earlier quoted context omitted.
Why is number of packages and not package size the relevant metric here? Especially when all the packages live in the same repository, there's practically no more overhead to review each package qua package, versus just a bunch of directories in a package monolith. This "144 times longer" number seems pulled completely out of thin air.
Both are relevant. To their point, each additional maintainer is also a hidden dependency of each package, so the number of packages is relevant.
In the case in question the dependency count as crates is separate from the dependency count as git repos. In this case things that would normally be one big library where split in many different functional crates in the same repo.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#208Earlier quoted context omitted.
How can leaked memory, pragmatically, be considered safe? The language spec definition seems useless.
The only issue memory leaks can cause is being a DDoS vector. Memory unsafety can cause a host of other issues, and much more serious ones. It is also very difficult to come up with a definition of "memory leak" that doesn't include programmer intention, and so it's not clear that you can come up with static analysis to preclude it.
Agreed there is not much you can do about a programmer using memory in an unsafe way...so what is the point?
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#209Earlier quoted context omitted.
This is pretty much a judgment of Rust: Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future. I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.
> This is pretty much a judgment of Rust: I guess. It's really a judgment of Rust (specifically the compiler toolchain) for this one use case. > I would think that OpenBSD developers/users would care about security, Maybe. Again, I think "cat" and other system tools are really low on the list of priorities for anyone securing a system. Not to say that they don't represent attack surface, by any means, but there are j…
“cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy:
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#210Earlier quoted context omitted.
How much do your programs really share? After libc, libm, and pthreads, the most common thing they link to is probably pcre, and I'm sure you can guess how many of your programs are using that. A good linker will shave off the parts of a library you're not using, and the parts which are left over are usually not very big. The problem isn't with static linking, it's that some "developers" think that bundling an entire…
> bundling an entire Chromium build with their app is a good idea. Does Chromium offer any other type of linking? I mean, is the problem in the developer including it when another option is possible or the fact that no other option is possible?
The problem is reaching for Chromium to solve any problem in the first place.