proto_lambda

> everyone using ChatGPT knows that verification is part of the proccess

lol. lmao

> On Apple platforms or on Windows, you could look at the crash logs captured by the operating system’s built-in crash reporter, but on Linux that’s typically all you had to go on.

On modern linux distros, simply typing `coredumpctl debug` puts you right into gdb with the core dump loaded. If debuginfod is set up (not sure what the defaults look like there across distros), it will even automatically download debug symbols for all libraries loaded at the time of the crash.

Forced open source for everyone but them. They retain copyright and will continue to sell proprietary adaptions, while forbidding everyone else to do the same.

Yosys and nextpnr have been production-ready for years, they handle your average hobbyist FPGA project just fine (and 1-2 orders of magnitude faster than the vendor tools).

> Open source tooling is very primitive and not usable

Maybe you're working off old information, but the FOSS tooling (ghdl, yosys, nextpnr) is completely sufficient for hobbyists. If you're doing huge, high-speed designs on expensive FPGAs, sure, use the vendor tools, but for your average iCE40/ECP5-scale design, FOSS is the way to go.

There are such things are RAM encryption, but yes, overall it's more fragile from a security perspective than a strong plain passphrase.

With properly functioning secure boot and no bugs in the entire software stack, it doesn't matter if the disk is decrypted automatically, since you can't access the system without OS-level authentication. If you tried to replace system files to let you get in anyway, the secure boot measurements would no longer match up and the decryption fails entirely.

If you rely only on TPM for key storage, yes, the disk is unlocked automatically and any sufficiently broken userspace application you can get your hands on will let you access it. You can still combine TPM+passphrase/PIN though, at the cost of having to enter it at boot.

Thankfully that's just as illegal as tracking without consent (or in this case, explicit rejection).

That definitely exists, but AFAIK it requires special equipment to get the signal across transformers. Not much of a problem in urban environments, but e.g. in low-density areas in the US, where every house has its own transformer, it might be a problem.

There's also Brandweer Lunteren, which had to shut down for a while recently but seems to be sanctioned now. Not much traffic footage there though, being a pretty small town in the Netherlands.

> I'm not a fan of the fact that ÖBB couchette compartments don't have locks on their doors

The ones I know have both a turning lock that can be opened from the outside by the conductor or anyone else with a wrench (so more of a protection against someone mistakenly stumbling into your compartment in the middle of the night), as well as a deadbolt that can't be opened from the outside without ripping it apart.

> None of the above has anything to do with particular email message authenticity.

Only if you're on a shared email hoster. If you're the only one that has access to the mail server's signing keys, it's gonna be real hard to convince anyone that someone else signed that email.

The tweets are real, and a couple people joined in on the collaborative fiction at the time.

By the time you publish the key, it is no longer in your DNS records and thus no longer trusted by any receiving mail server.

> It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key

The point of publishing the keys is that _anyone_ can then sign messages, making "ownership of the domain" a meaningless factor, no matter how much you can prove it.

You'd get the opposite problem with "heavy" - correct in layman terms, nonsensical in a scientific context.

> It doesn’t seem that terrible to prohibit this (Probably some very good reason to counter this though!)

The simple reason is that the whole point of editions is that you absolutely do not have to worry about which one you choose. They are entirely localized to your crate, and code written in any edition can interact with code written in any other edition. With your suggestion, updating the edition used by a library crate would suddenly make it unusable for all code using an older edition.

If the subdomains aren't supposed to be public, the public also doesn't need to trust the TLS certs. Sign them with your own CA and trust it on the devices that should be able to access the domains.

If you're interested in or already comfortable with Rust, Amos (fasterthanlime) has a nice long-form series that goes into this, basically building a custom ELF loader in the end. The writing style isn't everyone's cup of tea, but maybe you like it: https://fasterthanli.me/series/making-our-own-executable-pac...

The package manager updates the browser, just like it updates everything else.

The main goal of using async for me is to not have to handle all the IO wait state machines myself. It does a pretty good job of that, and as long as my program consists of a bunch of tasks concurrently waiting for IO to finish, a single thread is perfectly fine.

There is no runtime (other than init/exit handling). The main thing that provides memory safety without a GC is the borrow checker, which is a language feature and independent of the smart pointer types in the standard library.

> Rust just took C++ std::unique and std::shared ptr and made those integrated directly in the language, and the only option for allocation

Not really. Both Box and Rc/Arc are first and foremost library features implemented using the equivalent of malloc() and free(). Box is a bit special due to its deref semantics, but other than that, there's nothing stopping you from implementing them or something else yourself.

That works until a country decides to hop across the international date line the day after they switch from DST to normal time, and the timestamp occurs three times ;)

It is indeed the latter, but it only knows about 19 so far: https://github.com/df7cb/sdate/blob/ace93c8d301c333a96ff354e...

Digital wrist watches can go 10+ years on a single battery, and they typically have transistors switching at 32kHz (as opposed to price tags, which could be completely static until you press a button).

There is no undefined behaviour in Safe Rust. You're right about Unsafe Rust of course.

Because you're not actually creating a filtered list, you're just filtering an iterator.

"One of the best things you can do for yourself is having enough money" yeah, no shit. Except many (or even most) people can't.