251–260 of 400 posts
Earlier quoted context omitted.
No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.
Interesting point. Does anyone know how much memory is needed to compile llvm+clang? GCC?
Earlier quoted context omitted.
"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 de…
If you don't like where the project installs its binaries or libraries, you can configure that before `make` or `make install`. You can install it to your home directory, have a separate directory tree for experiments, or whatever you want, and clean it up whenever it is convenient. You can also install things in usr/local and just ignore them. The system is actually well designed if you learn how to use it.
If you need a dependency, use your package manager to install it and you can trivially delete it later... and if you try five different frontends for the same library, you only install one copy of it.
Docker is a workaround for a lack of Unix awareness and sysadmin experience.
Earlier quoted context omitted.
OpenBSD is. Just because you can't think of a use case doesn't mean they don't exist.
I'm asking about the quality of the reason. Is there a real reason to not cross compile in 2020?
Earlier quoted context omitted.
> 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: https://www.cvedetails.com/cve/CVE-2014-9471/
Earlier quoted context omitted.
Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.
> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. Bazel and especially Nix are really interesting and d…
They are good for 'quick & dirty' dev usage. And terrible for everything else. Specially integration.
If they were perfect, you would not see things like lerna in JS (https://github.com/lerna/lerna) or Conda in python (https://docs.conda.io/en/latest/) to go around them.
> And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.
And they are right to be so. Build system and Package manager should be separated, or at least should be usable independently.
If your environment is multi-languages or system oriented, there is no possible practical way you can get a tool that reliably do both and scale. It would imply to rewrite every the language specific builder of every language.
I would say that in an ideal world, we would have language specific build system and one generic & portable set of dependency resolution tools (package managers).
In our current world, every language is its own isolated island and making them interoperate is a mess.
Earlier quoted context omitted.
I don't think the position of the language teams is that static linking is better than dynamic linking. I think that static linking is a significantly easier target for a relatively new language whose _novel_ features make it difficult to define a stable ABI. Under the very specific constraints that Rust is operating in, static linking is currently the best option. That said, I wouldn't mind seeing some kind of ABI g…
Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.
Earlier quoted context omitted.
"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 de…
A hybrid solution where the package manager is aware of all installed versions, can symlink to a globally installed copy and can update all symlinks would probably work.
Unfortunately, there is very little interest in fixing the problem on both sides (distro PMs and language PMs) since they both believe their own approach is right and don't care about the other group's problems.