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

361–370 of 400 posts

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

#361

Post by pnako »

hvs wrote: post #69
staticassertion wrote: post #61

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

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.

They do care about security. They just don't care about Rust.

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

#362

Post by iainmerrick »

adev_ wrote: post #256
throwaway894345 wrote: post #232

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... 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…

> The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make. 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 th…

Yes! It’s ridiculous how modern languages all try to do package management too, and how they’re all mutually incompatible.

I’m not so sure about language-specific build systems, though. Trying to set up a custom asset pipeline in most build systems is a pain, when they want you to shoehorn everything into a single language rather than just calling out to external tools and scripts (ideally including tools built as part of the same project!) Bazel gets this right.

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

#363

Post by pnako »

cosmojg wrote: post #187
staticassertion wrote: post #150

Earlier quoted context omitted.

> You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right? Yes, I think it is fair to say that I am very familiar with all of this information. I work in information security, and was quite into Linux kernel security for a while. I disagree with your assertion about it being the most secure general purpo…

> I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :) Could you please go there? I'm very curious what the contenders for "most secure general purpose OS" might be.

Well, there is only one real "general purpose" OS that runs on supercomputers, mainframes, servers, laptops, tablets, mobile and embedded, and that's Linux. So it's also the most secure.

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

#364

Post by staticassertion »

pnako wrote: post #361
hvs wrote: post #69

Earlier 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.

They do care about security. They just don't care about Rust.

They can not care about more than one thing.

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

#365

Post by pnako »

alrs wrote: post #348
estebank wrote: post #330

Earlier quoted context omitted.

He's not comparing cargo to clippy, he's talking about clippy, a community driven linter that checks your code style beyond what rustc itself does. It is executed with the command `cargo clippy` once it is installed.

Thanks for the context, I would not have expected anyone to name anything after the most-hated piece of software ever written.

Clippy is not dead! His spirit is alive in every website that has a useless, stupid chat bot at the bottom right.

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

#366

Post by spion »

inimino wrote: post #313
spion wrote: post #272

Earlier quoted context omitted.

I'll put it in context. Let's say I have leftover garbage in usr/local/lib. I clone a new project that I need to patch because it's broken. I try to fix the new project but the fix isn't working. I have no idea why. I spend hours trying to trace down the problem. What was the issue? The project picked up some of the old garbage libraries I had in usr/local/lib, which had a bug that made my fix not work. For developer…

> I spend hours trying to trace down the problem. This is the problem. Once you understand library loading, once on your system, and learn, once , how to query the system and see what libraries are being loaded and from where, you won't have to waste hours on this problem again. Until that point, you're operating a system without understanding, and that will always lead to breakage.

Of course I understand how it works. I just can't constantly keep in mind what garbage I played around with 3 months ago that might be responsible for the issue I'm looking at right now. I don't expect it, and more importantly, I shouldn't have to expect it.

It's a basic tenant of development. Eliminate all additional sources of issues and complexity by presenting a clean, well-controlled sandbox in order to effectively diagnose it and fix the real bug.

In fact, you should be able to try a newer version of a dependency, an older one, or run 10 variants (containers) each with different versions to e.g. test whether the project you're working on is widely compatible with a flexible range of that dependency. These things are done all the time.

The tools are inadequate, not the developers. Engineers on both sides need to stop assuming everyone else is an idiot.

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

#367

Post by spion »

pas wrote: post #318
spion wrote: post #260

Earlier quoted context omitted.

The benefit of global libraries is that they are easier to update or patch. If there is a vulnerability in an npm package, you will need to update it in all your node projects (and/or rebuild all your docker images analogously). 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…

yarn uses a global cache and symlink if I remember correctly. and npm has an "audit" feature, which is default on, so there's quite a bit of movement in JS land to address the disadvantages of having a myriad small packages.

Its not about the size of the packages, its about managing an entire system, for whatever definition of the word "system"

In the "olden" days, you would patch the vulnerable dependency and be sure that all services running on the machine have been updated to the new version. (in theory - if everything works great and there is ABI compatibility etc etc).

Since the library is installed in a well-known system location, there are only a few paths in the filesystem that you would need to check to make sure it's up to date. This makes machine maintenance easier.

Nowadays, to patch a vulnerable dependency you need to potentially go to all individual projects, check whether they depend on it, update the version for that project, make sure to rebuild any containers that... contain it. Rinse, repeat.

There is also not a single place where the dependencies live, so you can't just run the same command across multiple machines to do the check - you have to check the directory structure of every individual service.

This can be very slow and painful.

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

#368

Post by dang »

zozbot234 wrote: post #359
dang wrote: post #277

Earlier quoted context omitted.

Yes, we've changed the title from "Theo de Raadt on Rust", which broke the site guidelines: " Please use the original title, unless it is misleading or linkbait; don't editorialize. " https://news.ycombinator.com/newsguidelines.html

(2017)

Oh good grief. I don't know how we missed that. Added now, thanks!

HN has enough sensational Rust discussions with fresh articles and didn't need to supplement those with a 3-year-old one. Oh well, win some lose some.

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

#369

Post by 7532yahoogmail »

Gate keeping is a thing ... And I smell bad odors here and there from the bsd folks, but on the whole ... It's true: nobody is gonna trade across for equals on grep, ls, whatever. If rust wants to be some OS dev language it's going to have to make a better os or competive one (eg nextstep or k42 and similar efforts) ... It's going to have to go much bigger. And finally serious safe code would be accompanied by frama-c / tla+ proofs .. just pointing out rust is not the high ground.

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

#370

Post by pjmlp »

fluffything wrote: post #338
staticassertion wrote: post #76

Earlier quoted context omitted.

Maybe I shouldn't have said that, because it's contentious, but I do believe it to be true. I believe Rust's success has less to do with memory safety, which I think most developers (anyone coming from a GC'd language) consider table stakes, and much more to do with great documentation and incredibly powerful primitives and ecosystem such as the type system, cargo, crates.io, etc.

A GC only protects you from memory errors, not threading errors. In general, Rust allows you to write software that doesn't break silently. That's a quite good value proposition for large scale software, where other languages often require programers to be super careful with refactorings, while in Rust you can really refactor all the things. The reason people are afraid to do large refactorings in say C++ is often "s…

Rust's type system also only protects about threading errors if they happen to be data races for in-process data structures.

If they are external resources, there is little it can do.

While an improvement, it isn't a full solution, specially in the domain of distributed computing.

Post reply on HN