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

171–180 of 400 posts

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

#171

Post by staticassertion »

adev_ wrote: post #169
staticassertion wrote: post #167

Earlier quoted context omitted.

"If you are not able to run a ./configure / make / make install & 3 apt-get properly." Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.

> Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience. I tend to name a "magic bulshit bloat tool" that will makes me download 350MB of crap to compile an 'hello world' a "godawful tooling experience". We are all free to have our own definition.

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.

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

#172

Post by yjftsjthsd-h »

adamnemecek wrote: post #38

If you can write C as well as the OpenBSD people, be my guest, keep writing C. It might take you like 20 years to get somewhere interesting.

> It might take you like 20 years to get somewhere interesting.

Perhaps it did, but they started 25 years ago.

(Much like the bit, "staying closed-source set back clones by weeks or months... years ago".)

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

#173

Post by eximius »

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 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 guarantees that make dynamic linking possible. https://gankra.github.io/blah/swift-abi/ is a great, accessible read on some of the challenges of making a stable ABI, so I certainly don't expect it SOON.

I do wonder if there is some scheme that could be adopted in a performant way for making the ABI stable as of the Rust Edition, even if it were only for core and std, statically linking everything else?

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

#174

Post by Zenst »

Interesting read and raises one big issue:

We need to make memory safe languages accessible and with that, the tools and other frameworks for a new language isn't an easy path.

Which gets to an aspect in many walks of life - if you are doing something from scratch - you can use the latest knowledge and enforce that, but knowledge moves on and bringing up the rest of the system inline with a what is needed to use that new language/knowledge is not an overnight task, it's a slow process - and even if you provide something better, you can not guarantee it will be embraced at a needed pace to keep the momentum going.

Much like anything in life, you have better trains than you did when they was invented, but legacy infrastructure precludes an instant/overnight switch, due to impact upon what is used currently.

So case of, requirements for something better like rust support, is a bit of a catch-22 as you need it there to get the people to use it so tools get written, but to get it there you kinda need the tools so that people use it to write the tools. Hence the first step is always the biggest.

Which makes you wonder how intertwined aspects of the OS and programs are, even with standards like POSIX, there is clearly a bigger larger standard needed.

This along with the dependances and you can see why docker and other application level virtualization has much going for it.

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

#175

Post by all_blue_chucks »

zdw wrote: post #10

As with most things Theo says, they're aligned with being the right answer for OpenBSD's niche, which is probably not your niche. Any new tools that have high resource needs, don't support all the more exotic/esoteric platforms that it supports, are all nonstarters if your goal is a very small core system that compiles quickly on all supported platforms.

Yes but if he had an iota of social intelligence he would say "it is an interesting project but it is not nearly ready for inclusion in OpenBSD for reasons X, Y, and Z."

Instead he personally attacks people.

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

#176

Post by alqx »

quotemstr wrote: post #161
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…

I got the same vibe from the email. It reads just like bigcorp turf defense. When a smart but curmudgeonly component owner just doesn't want to accept some outsider's change, there's no end to the technical objections that component owner can raise against the outsider's change --- but these objections are just a smokescreen, and addressing them is futile, because the real problem is that the component owner has done…

> In the corporate world, to resolve this problem, you usually have to go up the management chain and emphasize to leadership that certain people are making important work impossible. In the FOSS world, you just have to fork.

Typical Machiavellian talker who overestimates his own abilities, derails a working project and moves on to the next company after two years to continue the damage there.

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

#177

Post by eximius »

He might just be wrong: https://github.com/uutils/coreutils

The only reason he might still be right is if they don't aim to be POSIX-compliant. The page doesn't explicitly call out compliance as a goal, but given that it has some busybox tests, it's probably compliant or very close.

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

#178

Post by legulere »

ddevault wrote: post #137
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…

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.

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

#179

Post by eximius »

james-mcelwain wrote: post #156
hedora wrote: post #146

Earlier quoted context omitted.

If you care about security, api stability and legal compliance, you should minimize the number of developers and packages you trust. My rule of thumb is that, for a team of ~10 developers, each package dependency adds a week or two of developer maintenance time each year or so. Having a dozen packages where one will do, and having them do the same thing recursively means you need to spend 144 times longer dealing wit…

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.
Post reply on HN