Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re: Integrating "safe" languages into OpenBSD? (2017)

marc.info

Post reply on HN
Print view View original

381–390 of 400 posts

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#381

Post by Ericson2314 »

cycloptic wrote: post #135
throwaway894345 wrote: post #99

Earlier quoted context omitted.

Yeah, there are lots of good build systems for C (didn’t know about this one; will have a look; thanks for sharing), but the problem is that they have tiny adoption, especially among “core” ecosystem packages, like coreutils and friends. The problem isn’t technical, it’s political and cultural. This ecosystem is hostile toward its users for no discernible reason. If anyone knows of a distribution that aims to use onl…

Bootstrapping and too many binary dependencies at the early stage is a known problem in GNU Guix and there are people working to fix it, such as the GNU Mes project to bootstrap the system using a minimal compiler, shell and set of utilities written in Scheme. Despite this, there are still many steps to bootstrapping a full system and the complete process is not simple. It's not for "no reason", in general you will n…

Actually focusing on cross generally usually forces when to be bootstrapping better.

The problem is most distros / deployed systems are managed and bootstrapped imperatively, which there is nothing pushing back against complicating the bootstrapping. Thus, entropy wins and it gets more complex.

As someone who as actually started about reproducing BSD bootstraps declaritively (https://github.com/NixOS/nixpkgs/pull/82131/files) they are way more entangled than they need to be, so Theo de Raadt has no ground to stand on.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#382

Post by Ericson2314 »

cycloptic wrote: post #358
throwaway894345 wrote: post #315

Earlier quoted context omitted.

Yeah, Nix is really neat. It's the right direction for sure, but it's mostly used as a wrapper around autotools and cmake projects by third parties and not so much as a first-class build tool by the maintainers of C/C++ libs (this isn't going to change because Nix prefers to be "innovative" and unfamiliar in just about every design decision--its core approach to reproducible builds is right on, but the execution leav…

Nix is a package manager, not a build tool. It's never been in-scope for it to figure out how to invoke a particular compiler or linker. All it can do is make it easier for you to invoke another build tool, of which there are quite a few. I would not recommend the use of autotools in new projects, but in my experience CMake with Ninja is fine for distro maintainers to deal with — All other modern build tools I've see…

> It's never been in-scope for it to figure out how to invoke a particular compiler or linker.

True

> Nix is a package manager, not a build tool.

False. Nix should be the go-to tool for executing and caching all dependency graphs. Just the planning of those graphs is domain-specific and out of Nix's purvue.

Build systems that use Ninja actually get the execution-planning separation right. (Try Meson if you hate CMake.) So basically, we just need to make Nix better than Ninja in every way, and then hook it up to these build systems (directly or with ninja2nix).

Of course, then we will demonstrate all the impurities and non-determinism in people's CMakeLists. That alone is the cultural problem to solve for normie evangelizing. Everything else is technical and there's use bemoaning Nix is just too weird.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#383

Post by damnyou »

burntsushi wrote: post #349
damnyou wrote: post #203

Earlier quoted context omitted.

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.

This is one of those things that's strictly true, but is kind of misleading because it doesn't capture the full picture. In particular, there is actually no guarantee that the source code you see on GitHub matches the source code you compile from crates.io. Now, most responsible maintainers tag each release and publish exactly that tag to crates.io. Which is good. But that's just a convention. There's nothing enforci…

You're right.

I've heard from reliable sources that this is actively being worked on.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#384

Post by jupp0r »

est31 wrote: post #189
jupp0r wrote: post #181

Earlier quoted context omitted.

I can see your point, but to give you a little more perspective on the breadth of the problem domain: I wish they went as far as Go with their ability to produce fully static binaries and allow for cross compilation. Go's ability to have one CI pipeline running on Linux that then produces binaries that run on every conceivable version of Linux, Mac and Windows is a huge productivity boost. For most of my use cases, t…

Note that Go implements most of its toolchain itself while Rust uses parts of the C/C++ toolchain (llvm, C++ linker instead of go's own linker, etc). Go even has its own library loader. Once you have that it's not hard to make it compile to any target you want. Also Rust is still evolving. They still have to add major new features to the compiler instead of being able to implement features like raw dylibs which would…

The problem is not the toolchain itself, it’s the runtime. Go’s runtime is interfacing directly with OS kernels, Rust is linking against glibc, etc. I wish the Rust community would invest in a runtime that inreracts with the kernel directly in the same way Go does. Current approaches aim to implement libc drop in replacements in Rust. There are also the musl targets which could make building static binaries easier. A completely rusty approach without going through the libc interface would have tons of benefits, though!

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#385

Post by est31 »

jupp0r wrote: post #384
est31 wrote: post #189

Earlier quoted context omitted.

Note that Go implements most of its toolchain itself while Rust uses parts of the C/C++ toolchain (llvm, C++ linker instead of go's own linker, etc). Go even has its own library loader. Once you have that it's not hard to make it compile to any target you want. Also Rust is still evolving. They still have to add major new features to the compiler instead of being able to implement features like raw dylibs which would…

The problem is not the toolchain itself, it’s the runtime. Go’s runtime is interfacing directly with OS kernels, Rust is linking against glibc, etc. I wish the Rust community would invest in a runtime that inreracts with the kernel directly in the same way Go does. Current approaches aim to implement libc drop in replacements in Rust. There are also the musl targets which could make building static binaries easier. A…

I meant to include the runtime in the "toolchain" term. See how I spoke about the library loader that Go implements.

The libc is only part of the greater issue of community tolerance of C components in the stack, like openssl or host OS TLS implementations, while Go mainly seems to just use the tls implementation of the language creators. There is rustls but it's not regarded as good enough and the defaults are using native-tls or openssl. And even rustls uses C components as it builds on ring which has C components of its own...

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#386

Post by loup-vaillant »

loup-vaillant wrote: post #53
dirtydroog wrote: post #24

Earlier quoted context omitted.

Is it 'really toxic', or just uninformed? Note that the email conversation was from a few years ago.

I'd say toxic. When you point out that "nobody has done this" in this way, there is a strong implication that it's not possible, not reasonable, or not wort the effort. Rust explicitly aims to be a systems language. It explicitly challenges C and C++ on their own turf. Implying that it's not suitable for serious systems work is insulting. > Note that the email conversation was from a few years ago. Remember that the…

Meta: if someone could explain to me where the 5 downvotes come from, I'd be curious to know which part of my comment triggered them.

Is Theo de Raadt above criticism? Is Rust actually failing at its primary goal? Are words like "toxic" and "insulting" under a soft ban? Right now all I have to go by is a dead flagged strawman from a throwaway account.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#387

Post by dirtydroog »

loup-vaillant wrote: post #386
loup-vaillant wrote: post #53

Earlier quoted context omitted.

I'd say toxic. When you point out that "nobody has done this" in this way, there is a strong implication that it's not possible, not reasonable, or not wort the effort. Rust explicitly aims to be a systems language. It explicitly challenges C and C++ on their own turf. Implying that it's not suitable for serious systems work is insulting. > Note that the email conversation was from a few years ago. Remember that the…

Meta: if someone could explain to me where the 5 downvotes come from, I'd be curious to know which part of my comment triggered them. Is Theo de Raadt above criticism? Is Rust actually failing at its primary goal? Are words like "toxic" and "insulting" under a soft ban? Right now all I have to go by is a dead flagged strawman from a throwaway account.

Don't worry about it. My comment seems to be up and down like a yoyo.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#388

Post by unilynx »

jerf wrote: post #278
ajross wrote: post #166

Earlier quoted context omitted.

> IMHO, that's basically not possible, so it isn't a fair ask Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too. Rust didn't hit any o…

"How about Docker? V8/node? Most of the wasm ecosystem dates from that period." Not a replacement of any previous tech, not a replacement of previous tech, and not a replacement of previous tech respectively. You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. It is "zlib, libjpeg, readline" I was suggesting is far too high a bar to clear to say a languag…

> You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing.

They're all parsers of foreign input. Somethings which C is extremely fast at, but also extremely dangerous at doing.

> I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages.

But did other languages have the same ambitions ?

As I understood, Rust wanted to be safer but just as fast as C. Which would make it an ideal language to replace those input parsers. It's a pity that still hasn't happened because we'll still be seeing plenty of CVEs for those libs..

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#389

Post by euler_angles »

LukeShu wrote: post #148
euler_angles wrote: post #121

Earlier quoted context omitted.

You can find many articles on the origin of the term. I like this one from 1959: https://www.scientificamerican.com/article/1959-cargo-cults-...

You're being downvoted--it's because you missed the pun. Everyone knows the term "cargo cult". The pun is combining that with that the Rust package manager is named "Cargo".

Okay, thanks for telling me.

Not everyone knows this term, surely.

And I didn't know the Rust package manager is called "Cargo".

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#390

Post by rurban »

burntsushi wrote: post #334
rurban wrote: post #293

Earlier quoted context omitted.

A lot is missing also. First he doesn't know about ripgrep, which is far better than GNU or BSD grep. Second,none of the known grep's can find unicode strings. Redhat carried along the uni patches for a while, but when people complained about performance on the new utf8 locales, they dropped it. coreutils is still missing unicode support, so we don't find equivalent strings with different bytes. No normalization, no…

> First he doesn't know about ripgrep ripgrep isn't POSIX compliant. Never was and never will be. So I don't think it's really applicable here. ripgrep is maybe an existence proof that a competing tool can be written, but it is certainly not a suitable POSIX compliant grep replacement. Building a fully POSIX compliant grep tool with good performance like GNU grep is pretty difficult. It could be done. It would probab…

Unicode search is not searching for byte equivalents. Unicode characters can be composed in different ways, with different bytes. What you see is a á but internally it can be composed of different bytes. the single a with accent or with a mark, a plus accent.

Unicode search needs do be optimized to normalize characters, and similar problems exist for case folding, grep -i

These problems are also security relevant btw. Many unicode strings are now identifiers, like names or file paths. that the stdlib still provides no functions to search and compare strings is a much bigger beef. grep is just a symptom of a much bigger problem

Post reply on HN