Read it. It’s not long.
It’s not just that running servers is hard. It’s that decentralized control can cause ossification. A bunch of functionality that people want became implemented in OpenSea because they couldn’t roll it into Ethereum itself.
2,413 karma · joined July 3, 2015
It’s not just that running servers is hard. It’s that decentralized control can cause ossification. A bunch of functionality that people want became implemented in OpenSea because they couldn’t roll it into Ethereum itself.
https://developer.apple.com/library/archive/documentation/Se...
1. No spoiler effect. If you really want Green to win, but you think Blue is the lesser of two evils, voting Green and Blue at the same time is strictly better than voting only for Blue.
2. It's about as easy to understand as FPTP. No funny business where politicians mislead people about how the voting system actually works. Approval voting has a few downsides, but they are obvious downsides, so everyone is on equal footing.
3. You can still use those nice scantrons and hole punches.
4. No weird questions about "should I give the candidate I want most a 1, or should I give the candidate I want most the 10?"
5. It's a majority rules system and not a dictatorship.
The problem is, where I worked, my boss forced us to add a cookie banner even though we do not actually have any tracking cookies at all, and have no plans to add them, because that’s not our business model. It is just a legal CYA, because the business we’re in is highly regulated.
It’s the problem with government solutions. Everybody’s so paranoid that they wind up overcorrecting.
A good developer will crash the program, as soon as possible, if and only if it has a bug. If you want to write a program that never crashes, then you need to write a program with no bugs.
The reason you don’t want buggy code to limp along after it detects a bug, is that crashing isn’t the worst possible thing.
The worst possible thing is getting stuck in an infinite loop or a deadlock.
That’s essentially it, yes. My code should never actually panic. If it does, it means the state of the process has become deeply diseased, and attempting to “clean up” is likely to just make things worse. Of course, if it’s safe Rust, then it still won’t write past the end of a buffer or anything disastrous like that, but buggy code is still buggy code and there’s lots of stuff Rust won’t stop you from doing.
One of the more extreme things I’ve done in production Rust code was add a “watchdog thread”. It has a channel that takes unit and receives on a timeout, and the thread doing the actual work is expected to send it a message once a minute. If it doesn’t receive a message within a minute, it hard aborts the process. The default setup is run under a service manager like systemd to make sure it gets restarted, and that failures are actually logged somewhere.
This is meant to solve the problem that safe Rust is a Turing complete language, so is subject to the halting problem. The type checker can prove that you won’t read past the end of a buffer, but it cannot prove that your code will ever actually finish running. Which means, if you have a project like a web scraper that needs high uptime, you need to prevent it from getting stuck somehow.
* Entering an infinite loop can bring down everything. A separate thread might not, but since Rust provides no way to kill a thread without it cooperating, there is no way to stop a stuck thread without bringing down the whole process.
* Stack overflow is an instant abort, not a panic.
* Double panic, where panicking calls a destructor that itself panics, is an instant abort.
(Infant circumcision is morally wrong, because it is a medically unnecessary surgery done without consent, but it doesn’t make you infertile.)
A well-designed SSG, like all of the ones I've used, will interlock[1] updating the feed and the HTML. You can't easily update one without updating the other, just like you have to go out of your way to open a microwave oven without also turning it off.
Just copy the CSS from http://bettermotherfuckingwebsite.com/
Anything else is probably overkill.
If you're writing a blog, then you probably want a way for people to subscribe to it instead of making them visit your site manually. Unless you are confident that you not only CAN write a feed by hand, but will never forget to hand-update it after updating the post itself, you're going to want to at least have the RSS feed be auto-generated.
And once you've added the infrastructure to auto-generate the RSS index, there's very little point in not auto-generating the HTML index, too. If only because, that way, you won't forget to run it.
Because separate cores each have their own cache, and their own program counter, there's a lot of communication overhead between them. When you're using instruction-level parallelism[1], you can actually do stuff like "perform a single add and a single multiply in parallel, then add them together", and the system is designed so that you aren't adding any overhead when you do that.
[1]: MIMD instructions are one way of doing this, but the computer you're reading HN on is probably an out-of-order superscalar, which accomplishes the same thing implicitly.
Linux could change it if every single copyright holder consented, but that's even less likely than the FSF adding a field of endeavor restriction to the GPL. Google owns partial copyright to Linux. Other copyright holders are gone, and nobody knows who the heir is.
The Coca-Cola formula seems like a pretty good analogy, honestly. Most people can't tell the difference between different cola recipes, and there probably isn't anything in the recipe itself that's responsible for the company's success. Not as much as marketing, and simply being in the right place at the right time, anyway.
Compilers can rely on alignment even if the CPU doesn't. LLVM does, which is why older versions of rustc had segfaults when repr(packed) used to allow taking references. While it would be pretty easy to get rustc to stop emitting aligned loads, getting Clang and GCC to stop emitting aligned loads might be trickier. https://github.com/rust-lang/rust/issues/27060
You can take a pointer to an i32 and pass that pointer to C code as int32_t. This means it has to have the same alignment in Rust that it has in C.
If your API server is separate from your Frontend server, you don't just make maintaining it more reasonable (the "server colored functions" are now a strict subset of the "client colored functions"). You also get operational flexibility: run the Frontend server in an edge function system [1], while running the API server alongside your DBMS. Isn't that what edge functions are for?
I don't know, because nobody's actually posting a link to it.
I don’t think anyone wants to use a search engine that never delists anything. Ransomeware, Markov chain junk, plagiarism. A search engine that never delists anything is useless.
The problem is when delisting is used against the end-user’s interests.
CVE = The Yank flag. Cargo will refuse to add new yanked packages to a lock file, but if a yanked package is already in the lock file, it will still build. The package is not actually deleted. https://doc.rust-lang.org/cargo/commands/cargo-yank.html
Legal = Hard delete. Nobody will go to jail just to avoid breaking your build. Of course, since crates.io and kernel.org are in the same legal jurisdiction, is there any actual difference here?
Where would you even start to determine if that was true or not?