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

261–270 of 400 posts

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

#261

Post by anthk »

oefrha wrote: post #93
cycloptic wrote: post #59

Earlier quoted context omitted.

There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…

To replace anything in OpenBSD, you need way more than POSIX-compliance -- you need OpenBSD-compliance. Which means every non-POSIX option has to be implemented down to edge cases, every departure from or controversial interpretation of POSIX (POSIX is vague in many places) has to behave exactly the same. Or you'll definitely break scripts.

These nuts don't understand OpenBSD's base doesn't map to GNU coreutils, it ships SEVERAL more tools. They are so GNU and Rust blind they don't get anything.

.ls -1 /bin/ /sbin/ /usr/bin/ /usr/sbin/ | sort -u | wc -l

     671
Good luck reimplementing that.

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

#262

Post by stcredzero »

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…

However there is a rampant fiction that if you supply a new safer method everyone will use it.

A fiction indeed. This is how developers actually behave. If you build a better mousetrap, lots of developers will all too quickly give you n reasons why it's terrible, and why you won't be able to pry their (punch cards/assembler/compiler/favorite-language/favorite-tool) out of their cold, dead hands.

This has been true, literally since the modern era of computer programming began in the middle of the last century, and it shows no signs of abating.

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

#263

Post by dmitrygr »

busterarm wrote: post #230
bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

I'm not much for Rust, but I'm essentially a deploy/tooling engineer and supporting a build system for hundreds of engineers and tens-thousands of servers. I've worked in a few dozen languages at this point and have seen 20 years of the problems in this field. I'm going to tell you that static linking is the only way to go. The idea that needs to die is the personal workstation. It's just another deploy target. Ideal…

> Disk is cheap

Arguable, but I'll grant you this. But RAM ain't cheap.

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

#265

Post by spion »

inimino wrote: post #253
Uehreka wrote: post #206

Earlier quoted context omitted.

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…

You seem to be confused about how typical C/C++ projects are built. If you need globally installed dependencies, you're going to have to install them yourself. A typical makefile is not going to download a long list of random junk from the internet and install it your machine without asking. Although you'd be forgiven for thinking so if you're used to npm. If you don't like where the project installs its binaries or…

The system is not well designed. For example: if I have 3 projects I'm developing locally, each needing a dozen (somewhat overlapping) libxxx-dev dependencies to build, how can I automatically clean up the dependencies that are no longer needed when I delete one of the 3 projects?

Distro package managers are focused on providing a good experience for sysadmins while ignoring needs during development time. Unfortunately, docker and the developer-centric improvements in language package managers have come at the expense of worse sysadmin experience.

The situation will remain sub-optimal until both groups start working together to address both needs.

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

#267

Post by 013a »

zerpelin68 wrote: post #197
013a wrote: post #95

> Yes, now I am implying something: you won't bother to rewrite the utilities. > So we cannot replace any base utility, unless the toolchain to build it is in the base. Adding such a toolchain would take make build time from 40 minutes to hours. I don't see how that would happen. So, to summarize: "We're not going to include the capability to write core utils in Rust, and also, no one is bothering to do it." Its rath…

Censorship of opinionated entities speaking in a manner you disagree with is so popular right now how can you be wrong? The 'community' meaning my cloud/bubble/echo chamber as usual I guess? Theos take was refreshing honesty in my bubble.

He's allowed to say whatever he wants; I'm allowed to believe that its unprofessional for a community member of his stature; and I'm allowed to decide whether I would feel comfortable contributing to a project ran by someone like that.

None of this is censorship.

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

#268

Post by Conan_Kudo »

hu3 wrote: post #234
protomyth wrote: post #31

Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Is this true anymore or just a history note?

> For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Last I checked Rust needed more than 4GB of RAM to compile itself.

Yes, this is still true. :(

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

#270

Post by inimino »

spion wrote: post #265
inimino wrote: post #253

Earlier quoted context omitted.

You seem to be confused about how typical C/C++ projects are built. If you need globally installed dependencies, you're going to have to install them yourself. A typical makefile is not going to download a long list of random junk from the internet and install it your machine without asking. Although you'd be forgiven for thinking so if you're used to npm. If you don't like where the project installs its binaries or…

The system is not well designed. For example: if I have 3 projects I'm developing locally, each needing a dozen (somewhat overlapping) libxxx-dev dependencies to build, how can I automatically clean up the dependencies that are no longer needed when I delete one of the 3 projects? Distro package managers are focused on providing a good experience for sysadmins while ignoring needs during development time. Unfortunate…

If you've got some leftover libraries in /usr/local/lib on your development machine because of an experiment, why is that the end of the world? If you're worried about it, you shouldn't be.

The worst thing about Docker is that people think learning Docker is a substitute for basic competence as a sysadmin.

Post reply on HN