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

211–220 of 400 posts

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

#211

Post by Uehreka »

pastage wrote: post #192
Uehreka wrote: post #104

Earlier quoted context omitted.

Agreed on a hundred thousand. I used to feel sheepish defending npm and the whole node package ecosystem against its critics, but once I started trying to run deep learning applications or WebRTC media servers I quickly realized that some of the critics are probably coming from a much worse package management system that they’ve merely grown familiar with. Want to have two pieces of software on one computer that rely…

There are a lot of package ecosystems, but more packages, and one of these packages will always depend on something implicit. Building a new system is not going to help. Xkcd 927 about standards applies

I agree that we shouldn’t try and wrangle npm, gems, cargo, etc. into one package manager. I have no problem with different communities having different package ecosystems.

My main problem is that when it comes to C/C++ dependencies, the package ecosystem defaults to installing globally and has no standard way to specify dependencies aside from having instructions to “sudo apt install these 20 libs”.

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

#212

Post by sergeykish »

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…

It is certainly possible to use Rust with COM, like Rust/WinRT [1].

I'm currently building Firefox, it takes ages. It is marvel such complexity still manageable on customer hardware. Emacs is from another age.

[1] https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-w...

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

#213

Post by afiori »

throwaway894345 wrote: post #90
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…

Most scripts don’t depend on the POSIX standards anyway, they depend on GNU or BSD programs. CPython’s configure script, for example, blows up if the system grep is BSD and not GNU. The whole C build ecosystem is duct tape anyway and things rarely build without tons of manual effort (figure out what versions of which dependencies need to be installed to which locations in the file tree and then maybe things will buil…

I believe a main point of the article is that while linux might be fine with this state of affairs, OpenBSD is not and actually care about having a specific standard.

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

#214

Post by busterarm »

staticassertion wrote: post #167
adev_ wrote: post #158

Earlier quoted context omitted.

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. I will be mean, I am sorry but this kind of attitude piss me off. If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. W…

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

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.

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

#215

Post by adev_ »

staticassertion wrote: post #185
adev_ wrote: post #182

Earlier quoted context omitted.

> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for y…

> I am curious of your notion of "gatekeeping" Repeatedly telling people that they're bad developers, should walk away from a computer, that they are "script kiddies", because they do not know or enjoy some arcane technical artifact. I call this gatekeeping.

> enjoy some arcane technical artifacts

Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry.

These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences.

That is not 'gatekeeping', there is no gate to keep here. I name more that fight laziness and understand your tooling.

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

#216

Post by qppo »

aidenn0 wrote: post #106
qppo wrote: post #102

Earlier quoted context omitted.

How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

To me the question is moot if the problem is llvm. I don't know if that's the case or not.

Modern tools require modern hardware. If the problem is that the target constraints don't allow modern tools to be used, the problem is the constraints and not the tools.

But maybe I just don't understand their stance here.

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

#217

Post by tyg13 »

adev_ wrote: post #158
throwaway894345 wrote: post #72

Earlier quoted context omitted.

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. I will be mean, I am sorry but this kind of attitude piss me off. If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. W…

The reason most of these things aren't replaced is sheer inertia. You're asserting they got this position due to merit. I assure you, spend any appreciable amount of time working with Autotools, or any of the "traditional" Unix build systems, and you'll find their success in large open source projects is only due to

1. Actually being better than the hodgepodge of shell/sed/awk/perl/etc scripts that people used before Autotools came around

2. The massive amount of work done by people to fix all of the corner cases where Autotools didn't work

I think you're maybe looking at them with rose colored glasses. When you've spent hours trying to track down obscure, undocumented `./configure` options, dealing with vague linker and compile issues, implicit, circular or broken dependencies, buggy and arcane configuration scripts... I can go on and on and on about the problems of building open source software. Building things from source is a yak shaving exercise -- always chasing your tail. It's great when you're using a configuration that has been tested and mostly fixed up, but step outside of those parameters and it can be hell.

It's not that newer build systems don't have their own issues, they just try to address the historical problems that people have experienced from using things like Autotools for decades. You can scoff all you want, but no sane individual is going to use Autotools as their modern build system. They're going to use something like CMake, or Bazel, or their language's build system.

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

#218

Post by ddevault »

adrianN wrote: post #138
aidenn0 wrote: post #106

Earlier quoted context omitted.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

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.

You are ultimately responsible for your dependencies. No program is innocent of its dependency graph.

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

#219

Post by zozbot234 »

Uehreka wrote: post #104
throwaway894345 wrote: post #72

Earlier quoted context omitted.

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

Agreed on a hundred thousand. I used to feel sheepish defending npm and the whole node package ecosystem against its critics, but once I started trying to run deep learning applications or WebRTC media servers I quickly realized that some of the critics are probably coming from a much worse package management system that they’ve merely grown familiar with. Want to have two pieces of software on one computer that rely…

> Want to have two pieces of software on one computer that rely on... idk, two different versions of libwebsockets?

You've pointed this out yourself, but this works just fine in any sensible OS. You just have two or more versioned instances of libwebsockets in your /usr/lib directory, and a symlink (or multiple symlinks with different partial-semvers) that points to some appropriate default. I think even Windows is doing something like this nowadays, as part of the whole WinSxS mess.

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

#220

Post by [deleted] »

adev_ wrote: post #158
throwaway894345 wrote: post #72

Earlier quoted context omitted.

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. I will be mean, I am sorry but this kind of attitude piss me off. If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. W…

[deleted]
Post reply on HN