421–430 of 508 posts
Earlier quoted context omitted.
trait Handler { fn handle (&self, input: &'a str) -> Result ; } fn process_handler ( handler: Box , input: &'a str, ) -> Result { handler.handle(input) }
> > really extreme use cases with lots of lifetime annotations and generic bounds You choose as your example a pretty advanced use case.
Earlier quoted context omitted.
> Where are they coming from? One is in lives in Brazil and I think the other lives in the Middle East. They both have old second hand 32 bit laptops from the 00's. > but you seem to paint it as some kind of affordability frontier... Yes because there are people still using old hardware because they have no choice. Also, whats the problem with supporting old architectures? Plan 9 solved the portability problem and a…
> whats the problem with supporting old architectures? It's not free, it's not easy, and it introduces hard to test and rarely run code paths that may or may not have problems on the target architecture. I think there's a pretty strong argument for running hardware produced in the last 10 years for the next 10 or 20 years. However, I think it should be recognized that there was massive advances in compute power from…
I have stopped replacing machines (and smartphones) because they became outdated: the vast majority of compile tasks is finished in a fraction of a second, applications basically load instantly from SSD, and I never run out of RAM. The main limiting factor in my day-to-day use is network latency - and nothing's going to solve that.
My main machine is a Ryzen 9 3900X with 32GB of RAM and a 1TB SSD. And honestly? It's probably overkill. It's on the replacement list due to physical issues - not because I believe I'll significantly benefit from the performance improvements of a current-gen replacement. I'm hoping it'll last until AM6 comes around!
Every task is either "basically instantly", "finishes in a sip of coffee", or "slow enough for a pee break / email response / lunch break". Computers aren't improving enough to make my tasks upgrade to a faster category, so why bother?
Earlier quoted context omitted.
>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly…
It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.
Very few people are forcing “rewrite in rust” down anyone’s throats. Sometimes it’s the maintainers themselves who are trying to be forward-thinking and undertake a rewrite (e.g., fish shell), sometimes people are taking existing projects and porting them just to scratch an itch and it’s others’ decisions to start shipping it (e.g., coreutils). I genuinely fail to see the problem with either approach.
C’s long reign is coming to an end. Some projects and tools are going to want to be ahead of the curve, some projects are going to be behind the curve. There is no perfect rate at which this happens, but “it’s battle-tested” is not a reason to keep a project on C indefinitely. If you don’t think {pet project you care about} should be in C in 50 years, there will be a moment where people rewrite it. It will be immature and not as feature-complete right out the gate. There will be new bugs. Maybe it happens today, maybe it’s 40 years from now. But the “it’s battle tested, what’s the rush” argument can and will be used reflexively against both of those timelines.
Earlier quoted context omitted.
It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access. Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provi…
> It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom). Their signed package formats (there are two) add extra…
APT does not verify package-level signatures (and nobody uses them anyway), so this is irrelevant.
my biggest problem with rust is. i can't read it. i never know what this symbol means. is it a keyword? a type, a variable, a constant or a macro? Sure loading it into a IDE with a language server may help understanding the code.
Earlier quoted context omitted.
> The grammar could've used `Generic[Specific]` with square brackets and avoided the need for the turbo fish. But then people would grouse about it using left-bracket and right-bracket as brackets in a type "context".
The problem here is that angle brackets are semantics dependent syntax. Whether they are brackets or not depends on semantic context. Conversely square brackets are always brackets.
The announcement says: >In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages and a stronger approach to unit testing. I can understand the importance of safe signature verification, but how is .deb parsing a problem? If you're installing a malicious package you've already lost. There's no need to exploit the parser when the user h…
The parser can run before the user is asked for permission to make changes. The parsed metadata can then discourage the user from installing the package (e.g. because of extremely questionable dependencies ). Dependencies are probably in the apt database and do not need parsing, but not everything is, or perhaps apt can install arbitrary .deb files now?
Earlier quoted context omitted.
>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust. The whole coreutils saga was pretty much entirely caused by Canonical, The coreutils rewrite project was originally a hobby project iirc and NOT ready for prod. for the most part the coreutils rewrite is going well all things considered, bugs are fixed quickly…
It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.
Earlier quoted context omitted.
> let v = Vec::new(); // Crap, I want to specify the type of Vec This kinda implies you've gone wrong somewhere. That doesn't mean there aren't cases where you need type annotations (they certainly exist!) but that if `Vec::new()` doesn't compile because the compiler couldn't deduce the type, it implies something is off with your code. It's impossible to tell you exactly what the problem was, just that ` >::new()` is…
Nah, there's lots of times you need to specify the types of Vec, either because 1. You don't want the default `i32` integer type and this is just a temporary vector of integers. 2. Rust's type inference is not perfect and sometimes the compiler will object even though there's only one type that could possibly work. Edit: The >::new() syntax is definitely never used though.
Which I guess i typical stumbling block when the compiler can’t infer what type to collect into.
Earlier quoted context omitted.
I mean... Pentium Pro is 30 years old at this point. I don't think it's unreasonable that modern software isn't targeting those machines.
So anyways, here's the netbsd docs for running the latest release on VAX: https://wiki.netbsd.org/ports/vax/