The Black Death sucked.
Most of the middle ages probably wasn't that bad, but the civilization-destroying plague destroyed civilization, and Renaissance-era propagandists exploited the living memory of the plague to make themselves look better.
2,413 karma · joined July 3, 2015
Most of the middle ages probably wasn't that bad, but the civilization-destroying plague destroyed civilization, and Renaissance-era propagandists exploited the living memory of the plague to make themselves look better.
The big downside was that, because it was turned on by default, a whole bunch of people who didn’t actually want it had it foisted upon them, so it got a very bad reputation right out the gate. Right algorithm, bad execution.
They aren't exactly the same thing, I suppose, but there's enough functional overlap that if you already have one, it's hard to justify adding another. You don't want too many of these "escape sequences", because every kernel-side keyboard interrupt becomes a thing that:
* Userland doesn't get to use that keyboard shortcut any more.
* Someone might accidentally trigger, and if they don't know what's going on, they become stuck.
* It's another thing that anyone building a captive kiosk has to know how to disable.
The countries that America is compared to and found wanting aren't running completely deregulated healthcare. What makes them different?
Specifically, if a plain router stops working, BGP will route around it, and all you did was drop packets. If NAT stops working, you don’t just drop packets, you drop whole connections. Applications don’t tend to tolerate dropped connections as well as they tolerate dropped packets.
I'm pretty sure there are a lot of those.
* A desktop package that isn’t a vehicle for ads (like Windows and ChromeOS).
* A desktop package that doesn’t require you to write your own one-off scripts to work around stupid deficiencies (like GNU/Linux).
* A desktop package that doesn’t constantly throw away all its “legacy” and break a bunch of stuff (like Mac).
If you ever need to debug code in a dependency, then you'll probably need to read code that targets a different edition than your home project does. Over a long enough time frame, you're going to need to at least be able to understand all of the editions.
* Restricting the rate of new releases doesn't necessarily mean you're reducing the average feature development rate. It might instead mean that you're releasing hundreds of new features per release, which is definitely worse than releasing a hundred versions with one feature each, because it can force people to rush things out to meet a release window instead of releasing them when they're actually ready.
* Restricting the number of feature bullet points per release doesn't necessarily mean you're reducing the amount of functionality being developed. It might instead mean that people try to develop huge "super-features" that technically count as one bullet point but actually gets used in dozens of different ways. Super-features are an easy way to wind up with a system where everything is possible, but the stuff you do every day is more difficult than it needs to be.
The bioweapon theory, however, is politically useful. If you want to start a war, or at least trade sanctions, a villain is a good place to start. Someone violating international law and gene splicing themselves a pandemic in a bottle is exactly the right kind of comic book supervillainy, without being technically impossible.
let mut buf = vec![0; DEFAULT_BUFFER_SIZE];
let database_frame_len = database_socket.read(&mut buf)?; // use 1
let database_result = Database::parse(&buf[..database_frame_len])?;
let html_template = HtmlTemplate::new(database_result);
let html_len = html_template.write(&mut buf)?; // use 2
socket.write(&buf[..html_len]);
The only advice I can really give to avoid this kind of bug is: don't reuse buffers unless it's actually a bottleneck.
//! The arena, a fast but limited type of allocator.
//!
//! Arenas are a type of allocator that destroy the objects within, all at
//! once, once the arena itself is destroyed. They do not support deallocation
//! of individual objects while the arena itself is still alive. The benefit
//! of an arena is very fast allocation; just a pointer bump.
You can see an example of how every ty::Ty<'tcx> in rustc winds up with the same lifetime, and an entry point for understanding it more, here in the dev guide: https://rustc-dev-guide.rust-lang.org/memory.html
However, arena allocation doesn't cover all of the dynamic allocation in rustc. Rustc uses a mixed strategy: there's both RAII and lots of arena allocated context that only gets destroyed at the end of a particular phase.
The only cases where I want sophisticated formatting features are for other people's documents, which means it's their business to pick the format. They don't always pick Office 365. Sometimes it's Confluence, or a company-branded tool that I don't even know what it actually is, or Zoho, or G Suite.
Between running some random word processor that someone else picked for me in my browser, and giving it unrestricted access to my home folder (or having to fiddle around to get it running in a container of some sort), I prefer the browser.
I definitely prefer the browser over imposing a monoculture on word processors. Not so much because I think there's much room to innovate in text editing itself (I often enough copy-and-paste between web-based word processors and Sublime Text), but because of the opportunity to innovate in the data model.
Here's what comes up on my (Fedora, obviously) machine when I run VIM with no filename specified:
VIM - Vi IMproved
version 8.2.5052
by Bram Moolenaar et al.
Modified by <bugzilla@redhat.com>
Vim is open source and freely distributable
Help poor children in Uganda!
type :help iccf<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help version8<Enter> for version info
No technical measures exist to stop you from removing this call for donations, but it's more work to patch it out then it is to just ignore it. This makes FOSS software a pretty good vehicle for political activism. Not just the fact that organizing a hostile fork to remove a message like this one is too much trouble and makes you look like a jerk, but also because political activism is a good way to motivate people to write and release software for free in the first place, making up for how difficult it is to really monetize FOSS software.
Was this idea considered? If so, why wasn't it done this way?
It's the butterfly effect. For example, a lot of software that actually gets written is a net negative to society, even if it functions perfectly. So does making it more efficient actually benefit anybody? And a lot of other software is embedded in organizations that will add features to the software until it fails, expanding like an ideal gas to fill whatever space it's given, so even if you make it more efficient and less failure-prone, you're only really delaying the inevitable anyway. However, making a bureaucratic organization less efficient might not actually stop it; consider, for example, how the Social Security Card was originally engineered to be unusable as a national ID, but got used as one anyway, so now the United States not only has a national ID that most citizens didn't want, but we're stuck with a bad one. However, identity theft might actually be considered just another case of externalities, and if the bureaucrats had to eat the cost of easy-to-forge national IDs, this problem might have gotten fixed.
I think you can analyze nonlocal harms, but not using informal reasoning in a chatroom. There are too many possible interactions in the real world to fit them all in your head. You end up with an impossible-to-analyze infinite regress.
Instead, nonlocal harms should probably expect real-world measurements to prove that they actually exist and aren't entirely being washed out by the much larger effect sizes of unrelated phenomena.
First of all, HN is full of entrepreneurs and wannabe entrepreneurs. A storefront that can't sell anything that doesn't have a good reputation outside the storefront is bad for small businesses, because nobody is willing to try anything new. A major part of the value proposition of a storefront is that the owners will vet the products they sell for a minimum standard of quality: it's not necessarily great, because greatness is subjective, but the food shouldn't poison you[1] and the AC/DC power converters shouldn't catch fire.
The second problem is that sellers will pass off counterfeit goods as being from major manufacturers when they aren't. I know I'm falling for selection bias, since I've probably bought counterfeit goods without knowing it, but that's not even really the point. The point is that I've bought stuff on Amazon that just didn't work, sold in packaging that's identical to stuff I've bought before that did work. I knew they were counterfeit and not just duds because the actual product didn't have the branding on it that genuine ones always have.
[1]: Well, okay, it might poison you if you have a special allergy. But anything with the common allergens like gluten or lactose will have labels.
According to MDN:
> More specifically, Firefox double-keys all client-side state by the origin of the resource being loaded and by the top-level site. [1]
They linked the definition of a "site" to the HTML5 spec, which says this:
> To obtain a site, given an origin origin, run these steps: [2]
> 1. If origin is an opaque origin, then return origin.
> 2. If origin's host's registrable domain is null, then return (origin's scheme, origin's host).
> 3. Return (origin's scheme, origin's host's registrable domain).
The HTML5 spec refers to the site's registrable domain according to the URL spec:
> A host’s registrable domain is a domain formed by the most specific public suffix, along with the domain label immediately preceding it, if any. [3]
Public Suffixes are defined according to a database that you have to explicitly register in [4]. If you aren't sure whether your base domain is registered as a public suffix, then it probably isn't.
[1]: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_P...
[2]: https://html.spec.whatwg.org/multipage/origin.html#site