151–160 of 400 posts
> 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 10 years for adoption, let people should switch languages? DELUSION. Yeah, I agree: if the sole value proposition were 'security' it would be a really slow roll. cargo is the killer app IMO. Anyone who's walked a big dependency tree - download, b…
Earlier quoted context omitted.
Well OpenBSD has this "dumb" rule that snapshots/releases are never cross compiled and be done on real hardware. So it's pretty much a rule that every hardware platform has to be self hosting. Microcontrollers are the exception, but then they don't run a full blown OpenBSD stack anyways.
This rule is not just dumb, it is retarded. I maintain a quite popular open source project, and OpenBSD maintains a fork. They try to submit patches every now and then, but every time it happens, I ask them to please also submit a test that makes CI fail without the patch, and pass with it. They can't, so OpenBSD remains unsupported. The problem is that there isn't a supported cross-compilation toolchain from any maj…
Especially since the kind of test you're asking for, when written by a developer who is less than passionate about writing such a test but rather more passionate about just solving the problem his patch addresses, is probably not going to be worth much compared to a properly thought out set of tests which target the class of problems which the patch solves. Or possibly even an adjustment to existing tests on the basis of what the patch solves.
Finally, surely you get plenty of patches which do small useful things like cleanup but which it would likely be impossible to write a test for.
Earlier quoted context omitted.
Clang is written in C++. The large majority of modern compilers and languages are either bootstraped or written in a mix of the language itself and C++.
And it took them forever to get anywhere. Compare LLVM with cranelift. Cranelift made so much progress very quickly.
Hm. Rust needs more than 4GB to compile itself?
Earlier quoted context omitted.
> Is this really appropriate for a core system component to have this many dependencies? Absolutely not. The entire OpenBSD base system can be built without an internet connection.
after you are done downloading all the source.
Builds that curl junk and use a dozen language specific package managers don’t have that property.
Earlier quoted context omitted.
> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded. One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/core…
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…
This "144 times longer" number seems pulled completely out of thin air.
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…
> Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough. 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? I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.
OpenBSD's website says things like "Only two remote holes in the default install, in a heck of a long time!", but remote holes in the default install is such a small surface on any OS (besides e.g. Windows XP). When was the last time you saw a remote hole in the default install of, say, Ubuntu desktop? macOS? The Amazon Linux AMI?
The interesting vulnerabilities are in server software that isn't running by default, local privilege escalation, etc.
Also, weren't there like four security bugs in December, at least one of which was remotely exploitable?
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…
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…
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. Whatever the language and the build system.
These "dumpfires" have been able for 20 years to build program scaling from 10 lines to 100M lines... On platforms that are maybe older than you (AIX, HP-UX...) and ranging from micro-controlers of few KB of RAM to the biggest supercomputers in the world... They work for for kernel mode and user mode... and are also able to build an entire OS distribution like OpenBSD.
They are indeed not perfect.... but they deserve at least a little bit of respect, even from the script kiddies not able to understand them.
And honestly, an other point where Theo is right: I bet that none of their (your) '3.0 Modern successor' will be able to replace them in the next 15 years.
Earlier quoted context omitted.
> the gatekeeping implied here [...] is really toxic It's Theo de Raadt, toxic rhetoric is sort of his brand. But... he has a real point here. It's not about grep or cat or whatever really, those are just the use cases for which OpenBSD would care. It's that as Rust is reaching the second decade of its history, and despite some outrageous wins in press, evangelism, and general developer mindshare... Rust just hasn't…
> It's that as Rust is reaching the second decade of its history Sort of. It's only been five years since it was actually stable enough for production use. (with a few exceptions of folks who were really invested)
> Where are the pervasively used compression libraries in Rust? Video and audio codecs? Network stacks? Database engines? System management utilities? PKI and encryption stacks? All that stuff is still in C.
How many of those projects in any language are less than five years old? The ubiquitously used stuff is mostly much older. But among the projects which are that young, Rust has substantial representation.
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…
Just setup the correct flag / env variable. That's not named a "hack", that's named knowing how to use a computer.
If you do not know how to compile and link an hello world in C. Then indeed, you should probably stay with an hello world in NPM/JS and its 1500~ packages dependencies.