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

311–320 of 400 posts

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

#311

Post by Arch-TK »

bluGill wrote: post #224
Arch-TK wrote: post #128

Earlier quoted context omitted.

Python's build ecosystem IS sane and well-designed. It's the pinnacle of package handling so far. A separate package manager which works together with a separate build system which still works when a distribution wants to package a python package. What build systems like cargo seem to think is awesome is probably the most backwards idea of build systems I've ever seen. Static linking and automatic downloading of depe…

Python packages don't interact well with the built in package manager on my os. It doesn't even try to, which is a major design flaw. Now if python had a way to do this and package managers refused to interopate (as I believe would happen) we would have a different discussion.

Pip doesn't need to integrate, it just needs to install elsewhere or give you a way of listing what will be installed. Cargo on the other hand just doesn't even bother letting you try to use it with a distro package manager.

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

#312

Post by ori_b »

throwaway894345 wrote: post #111
zozbot234 wrote: post #96

Earlier quoted context omitted.

> Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. Except that people have run into the exact same issue with stuff like rustc and cargo. Bootstrapping an entirely new platform is just hard, no way around it.

Comparing coreutils to a self-hosting compiler is a strained analogy. Bootstrapping a compiler is about as hard as it gets; there’s no reason coreutils needs to depend on itself.

> Comparing coreutils to a self-hosting compiler is a strained analogy.

What? Why? Unix is a self hosting environment. You can't even boot the OS you're building on without coreutils or the equivalent.

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

#313

Post by inimino »

spion wrote: post #272
inimino wrote: post #270

Earlier quoted context omitted.

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.

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.

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

#314

Post by anthk »

rurban wrote: post #293
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…

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…

- Theo doesn't give a shit on ripgrep, but grep(1) complying with standards and working under OpenBSD scripts.

- I am using grep(1) on unicode stuff in Spanish on XTerm just fine, even in ed(1). This is not a GNU craputils base, but the OpenBSD one. Heck, I type Spanish only characters with ed(1) in order to write my phlog. I can use nvi(1) from ports, but ed(1), fold(1) and ispell(1) are more than enough and I can forget about switching modes.

- That's a great example of Cargo Cult.

- On Unix and descendants, plan9 gave us UTF8, and fore sure it's grep supports more UTF8 stuff than your non-existant Rust based OS.

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

#315

Post by throwaway894345 »

yawaramin wrote: post #289
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…

Nix is becoming more of a name in dependency management systems: https://blog.galowicz.de/2019/04/17/tutorial_nix_cpp_setup/ Its claims to fame are support for multiple languages, reproducible builds, and system-wide package caching.

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 leaves a lot to be desired if you want to convince a community of developers to adopt it as a build tool). So anyone writing a Nix expression to package an autotools or cmake project (me, in this case) still has to deal with their nonsense.

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

#316

Post by inimino »

acdha wrote: post #279
inimino wrote: post #270

Earlier quoted context omitted.

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.

As someone who’s spent a lot of time as a sysadmin over the years, your last comment sounds backwards to me. The DevOps trend has pushed more general awareness and Docker has played a key role in three ways: making explicit automation requirements for the setup process (Dockerfiles have to work, unlike that MS Word document someone last updated 3 years ago), being private by default and requiring someone to reverse e…

> The key to understanding the benefit is the power of having done this in a standard, widely used way which is supported by many tools, used by an increasing fraction of projects, and which makes knowledge and training broadly portable.

You're talking about Makefiles here circa 25 years ago, right?

Makefiles have to work, and /bin/sh is still there last I checked on my machine. The problem with the broadly portable knowledge and training is that many people seem to think "don't bother with all that, just use docker" is an acceptable answer and "best practice" is not to learn Unix because it's not new and shiny.

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

#317

Post by hedora »

Beldin wrote: post #280
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.

True enough... but you still don't know what the dependencies do. E.g., one added ads. Another added use tracking. This could even be legitimately in line with the dependency's purpose. Unless you're manually vetting all the code, 400 dependencies means trusting a lot of third parties.

Trusting a lot of third parties is almost as irresponsible as not bothering with checksumming, etc.

See npm and pip for examples. I suspect cargo will have its share of incidents over time, unless it is somehow curated by a small group that tests and maintains the packages, but if it is, then it’s comparable to apt for c/c++.

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

#318

Post by pas »

spion wrote: post #260
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…

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.

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

#319

Post by busterarm »

busterarm wrote: post #238
eximius wrote: post #173

Earlier quoted context omitted.

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

Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.

Just to drive the point home.

If all of your engineers die in a fiery plane crash en-route to the company offsite, or your datacenter is wiped out in a flood, at least you have your statically linked binary that can run on commodity servers somewhere.

You have the peace of mind of knowing that your code as built should be able to run somewhere else in its current state without modification. You don't have to worry about the package availability of something that may have been around when you shipped your servers but may not be when you go to ship them again, or something that only coincidentally worked because your systems were installed via a certain upgrade path that's no longer reproducible.

It's a simple matter of business risk and minimizing surprises.

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

#320

Post by acdha »

inimino wrote: post #316
acdha wrote: post #279

Earlier quoted context omitted.

As someone who’s spent a lot of time as a sysadmin over the years, your last comment sounds backwards to me. The DevOps trend has pushed more general awareness and Docker has played a key role in three ways: making explicit automation requirements for the setup process (Dockerfiles have to work, unlike that MS Word document someone last updated 3 years ago), being private by default and requiring someone to reverse e…

> The key to understanding the benefit is the power of having done this in a standard, widely used way which is supported by many tools, used by an increasing fraction of projects, and which makes knowledge and training broadly portable. You're talking about Makefiles here circa 25 years ago, right? Makefiles have to work, and /bin/sh is still there last I checked on my machine. The problem with the broadly portable…

Saying makefiles solve that is like saying screws solved construction. They partially address only one of the concerns I mentioned, doing nothing for the others, and as the numerous tools in that space (automake, cmake, etc.) show they’re hardly a complete solution even for just the challenge of building things.
Post reply on HN