391–400 of 400 posts
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".)
Earlier quoted context omitted.
Address space ≠ required RAM.
It does require more than 4GB of RAM during its own build, though.
And what can I say - after about 3 hours and max memory usage of about 31% (or a little less than 1.8GB) the compile finished without errors.
So could you please point me to the source of your claim? Did I just uncover some magic loophole that allowed me to achieve this feat while using less than 2GB of RAM? What did I do wrong/right?
Earlier quoted context omitted.
It does require more than 4GB of RAM during its own build, though.
That's simply not true. After I couldn't find any such requirement in the build instructions for Rust, I was curious and actually setup a VM with 4GB of RAM (3.8GB usable), checked out the current rust source tree and had my machine compile the whole shebang in the background. And what can I say - after about 3 hours and max memory usage of about 31% (or a little less than 1.8GB) the compile finished without errors.…
Earlier quoted context omitted.
> Deployability really should be king. Not everyone values deployability as much as you (or employers, I suspect) do. On my personal computer I care about getting security patches and disk usage.
Lots of people don't measure risk very well and get hit by black swan events. Over 65% of startups have less than 6 months of cash reserves right now and 74% have been laying off staff. It turns out the majority of people are poor long-term planners. I personally don't care about how you manage your personal workstation, but you're not who most of us are building for. Most of us aren't building tools to support you.…
Earlier quoted context omitted.
That's simply not true. After I couldn't find any such requirement in the build instructions for Rust, I was curious and actually setup a VM with 4GB of RAM (3.8GB usable), checked out the current rust source tree and had my machine compile the whole shebang in the background. And what can I say - after about 3 hours and max memory usage of about 31% (or a little less than 1.8GB) the compile finished without errors.…
We regularly hit memory exhaustion when building Rust on Fedora and openSUSE for 32-bit architectures. It's even worse for openSUSE since we wind up having to build LLVM at times too. What you're probably missing is building the debug symbols. A release build with no debug symbols will likely be fine. See: https://github.com/rust-lang/rust/issues/45854
Your builds don't need more memory, they need more address space. You can convince me otherwise by enabling PAE and still running into the issue. Until then I stand by my point.
Earlier quoted context omitted.
We regularly hit memory exhaustion when building Rust on Fedora and openSUSE for 32-bit architectures. It's even worse for openSUSE since we wind up having to build LLVM at times too. What you're probably missing is building the debug symbols. A release build with no debug symbols will likely be fine. See: https://github.com/rust-lang/rust/issues/45854
No you don't hit memory exhaustion. You hit address space exhaustion. There's a difference and it's an important one, because 64-bit architectures don't suffer from this. Your builds don't need more memory, they need more address space. You can convince me otherwise by enabling PAE and still running into the issue. Until then I stand by my point.
Earlier quoted context omitted.
> First he doesn't know about ripgrep ripgrep isn't POSIX compliant. Never was and never will be. So I don't think it's really applicable here. ripgrep is maybe an existence proof that a competing tool can be written, but it is certainly not a suitable POSIX compliant grep replacement. Building a fully POSIX compliant grep tool with good performance like GNU grep is pretty difficult. It could be done. It would probab…
Unicode search is not searching for byte equivalents. Unicode characters can be composed in different ways, with different bytes. What you see is a á but internally it can be composed of different bytes. the single a with accent or with a mark, a plus accent. Unicode search needs do be optimized to normalize characters, and similar problems exist for case folding, grep -i These problems are also security relevant btw…
A grep tool that did normalization would be extremely slow. You'd probably be better served by a specialized tool. Or even better, it should be possible to write a fairly simple wrapper that puts everything into your desired normal form before searching.
Earlier quoted context omitted.
Lots of people don't measure risk very well and get hit by black swan events. Over 65% of startups have less than 6 months of cash reserves right now and 74% have been laying off staff. It turns out the majority of people are poor long-term planners. I personally don't care about how you manage your personal workstation, but you're not who most of us are building for. Most of us aren't building tools to support you.…
Not everyone who uses software is a software engineer…
Earlier quoted context omitted.
Not everyone who uses software is a software engineer…
Not everyone who uses a hammer is in the trades either, but that's who hammers are designed for because that's who is buying.
Earlier quoted context omitted.
Not everyone who uses a hammer is in the trades either, but that's who hammers are designed for because that's who is buying.
I think most of the people who use computers are not software engineers.