Felz

> Someone did a calculation that if the first cell had kept splitting at the rate it had, there'd be a ball the size of the solar system by now or something crazy like that.

What? That makes no sense as an exponential process. It'd be at least unfathomably larger than the universe by now, not just solar system sized. Or were they assuming it'd expand constantly only from the surface in all directions?

I don't think this article mentions it, but you should probably rotate your DKIM keys on a periodic schedule. Consequences for not doing so range from possible key compromise to losing the United States Presidency.[1]

[1] https://blog.erratasec.com/2016/10/yes-we-can-validate-wikil...

That doesn't seem true? Short-term memory is encoded in transient electrical patterns, but long term memory definitely is not. You definitely don't lose your personhood if you suffer an interruption to short term memory, or else everyone who's ever had a seizure is already dead.

https://en.wikipedia.org/wiki/Memory#Long-term_memory

Incidentally, I think SOMA is free on the Epic store today.

Yea, I think you basically do need one of these: https://en.wikipedia.org/wiki/Order_statistic_tree

They're somewhat obscure though.

As fanf2 said, MSNs != UIDs. Also, I didn't mean to imply that MSNs are an insurmountable limitation for performance, they just complicate things a lot.

I'm not familiar with Dovecot's code or very good at reading C, but I think part of how they handle it is here: https://github.com/dovecot/core/blob/81b5b188c478ec36bea8bda...

Basically, building a mail index for UID<->MSN translation that can serialize to disk, which would explain how it doesn't necessarily need absurd amounts of RAM and can select fast, probably at heavy cost when EXPUNGeing old messages. I'm sure there were worse implementations that did just maintain it all in RAM way back in the day, and still some that do (like the one I ran into).

IMAP was an okay protocol for its time, but in my experience it's basically mindbogglingly bad by current standards. The root of the reason why is the whole concept of "message sequence numbers", which as far as I know are extremely difficult to implement in a scalable and performant way.

Basically, all messages in a mailbox are numbered from 1 to N, and you can reference a message by number, and when a message is deleted all message numbers above it shift down by one. But since this could confuse clients that are sending inflight requests, you can't start translating from the new shifted-down-by-one numbers until you've told your clients about it, which could take a theoretically unbounded amount of time.

One implementation of this I've seen is to get a list of every UID in a mailbox at time of selection, and then update that as clients are informed of new or deleted mail. Needless to say, that's a bit problematic with short-lived or multiple connections.

So if your mailbox gets too big, too bad. This ends up complicating the client: probably influencing rules 1, 3, part of 5, and 8 listed here. (1) You can't have concurrent mailbox access because it might mess up MSNs reified to disk, (3) you can't have connections live too long because they passively eat up RAM with queued updates and a stored MSN list, (5) there are perfectly good UIDs to reference messages with that you have to learn alongside message sequence numbers, and (8) because opening a new session can be heavy.

Be careful trying to forecast that far into the future. Historically, most people have ended up very wrong.

I think the real limiter is people willing and stable enough to murder indiscriminately at scale in novel ways. Mowing down crowds of people with a truck is bizarrely recent, and the peak of mass murder is still one guy sniping at a concert from a nearby hotel. Everyone was relatively surprised that passenger planes could be used as destructive weapons.

The really effective means of mass murder I think would be subtle, though, and mass murderers don't seem to do subtle. E.g. leaving some radioactive material in an innocuous public place, worsening visibility at crash prone intersections, subtle and slow poisons mixed into food and drink…

> I think Youtube is overengineered as well, but at least Youtube has the good sense to prioritize loading the video first, and the recommendations/comments second.

One extremely annoying thing about this is that if your internet is slow, it can take a minute to load the title of the video you're watching. So if e.g. you get linked something without context and you may not actually want to watch it but do want to know what it is, too bad.

I think implicit in PG&E's decision to neglect maintenance was that they weren't allowed to raise rates and it wouldn't actually be very economical to do maintenance to reduce wildfire risks, so shareholders preferred profits were returned to them rather than reinvestment into e.g. maintenance. So adding the "motivation" to reduce wildfires might've made them more likely.

The real answer is actually the same in both cases: the bits (atoms) get used for something else. Although bones can linger for quite a while, not sure if there's a file parallel for that.

That's a bit of an open question right now, unfortunately. Using S3 to store Lucene indexes is a roll-your-own thing since last I checked, and the implementation I wrote currently deals with smaller indexes where files can be pulled to fully disk as needed. S3 does support range requests, which I'd think would mimic random access well enough.

Assuming whatever ElasticSearch implementation you're using is backed by SSDs there'd likely be more latency with S3, but I'd expect it to scale pretty well. Internally, a Lucene index is an array of immutable self-contained segment files that store all indices for particular documents. Searching in multiple indices is pretty much just searching through all their segments- which can be as parallel as you want it to be.

To be honest, I'm actually surprised the Elasticsearch company doesn't offer this as an option. Maybe because they sell hardware at markup?

Seems like it'd be more elegant (and probably cost effective) if you stored the Lucene indexes inside the buckets themselves.

Working on an email hosting company. Stack is Kotlin, Postgres, Docker, AWS.

It's likely been helpful because it's a stack I'm good with, and it has very mature tooling and libraries (via JVM). The alternative was basically C, which has higher quality mailserver libraries but seemed a lot harder to work with from my point of view.

Bit of a mixed bag here. The editor updates are nice, but they break all of the superior community created tooling. And a custom map I made a decade or so ago now seems to crash regularly, along with having a few minor but important pieces of it broken.

This is sometimes called the Gell-Mann amnesia effect.

https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...

What's it take to actually run a model like this, hardware-wise? I've been toying around with a gpt2 discord bot (https://github.com/ScottPeterJohnson/gpt2-discord) using just a CPU calculation, and already it takes up 2 GB RAM (and is slow obviously) on the 345M model. I might be able to get the 774M model running, but there's no way I can afford the full model, assuming linear RAM use. And that's just for CPU compute, I can't even begin to imagine how expensive GPU would be.

I don't know about throttling, but later Android versions are known to mess with email notifications.

See: https://github.com/k9mail/k-9/issues/3950

The point of the type system is that you can express your intent through an invariant or property at one place (i.e. the "head" function can specify that it should never be used on an empty list) and propagate that outwards so that it's enforced at all times.

This is more effective than trying to remember to always check the head function in every single place you ever try to get the first element of a list.

Yes, you can still write a compiling but wrong program. But it will likely be pretty close to what you actually want it to do, and it's easier to notice the behavior is not what you expected in one place, enforce that behavior via types, and see where you went wrong through compiler errors.

From working on Purelymail (which does offer mail for ~$1 a month), I would say that it's feasible to run such a service and be profitable, but that the $5/month services have a lot more leeway in marketing, hires, opportunity for huge profits, etc.

I want this a lot too, but the way we've built our software stacks has overwhelming path dependence on plaintext. There's a lot of tooling that's a bit broken, like git diffs, because the diffing algorithm can't actually capture what the logical changes really were, but it's close enough so we shrug and move on.

You can see how the accumulation of these little warts starts warping the rest of the devflow. E.g. since git can't do great diffs, it can't do great automatic merges. So we start using dev styles that minimize the pain of merging, and we start emphasizing continuous integration partly to prevent large merge buildups.

It irritates me to no end that the most important part of any code is the symbol names, but we've solidified and ossified those as the literal unchanging way you reference code. Want to fix a typo in a method name? Too bad, that's a breaking change.

Vanilla GPT2 actually does a half decent job of emulating the style of programming.

Try entering "public static int main() {" into https://talktotransformer.com/

For context, that'd be about 1.25 years of current world GDP [1]. If we maintain a 3.6% growth rate for 100 years, the economy will be 34 times larger, so it'd take two weeks of the world's total economic output to capture all that carbon. (In the worst case scenario there'd be about twice as much carbon by then, so stretch that to a month. [2])

Of course we might not be able to smoothly convert the entire world GDP to carbon capture plants for a fortnight, and there'd be deleterious global warming effects in the meanwhile, but overall napkin math paints a pretty optimistic picture for geoengineering.

[1] https://en.wikipedia.org/wiki/Gross_world_product [2] https://e360.yale.edu/assets/site/_600xAUTO_stretch_center-c... from https://e360.yale.edu/features/how-the-world-passed-a-carbon...

Really, that Mozilla would let a reported RCE vulnerability simmer for two months until it bit someone would seem to reflect very poorly on their priorities and competence. Can anyone postmortem why it took so long now that it's fixed?

Yea, that's kind of what I meant to say, although I wasn't thinking about AMP. Can Google really not use the vast amounts of data it ingests to deduce which sites have bad user experiences and are slow, though? Shouldn't that be their core competency?

This seems a bit like a complication that browsers shouldn't be handling? Like really, do we need this feature baked into the web forever, just to make it easier for websites to audit their performance?

A cynical part of me notes that adding more complexity to browsers just makes Chrome monoculture easier: I have no doubt that Google can win any war of "throw developers at it". But it feels like they're building a complexity debt nightmare that we'll all suffer from.

Edit: I guess the other and more direct angle for why Google would push this is that they can give "fast" sites a ranking boost in search, i.e. dictate what web pages do via soft power to make their job easier.

Is the quality of the dependencies you use really so bad that it'd take you more time to fix them than to write your own code and then fix that?

Like I can see where I'd make that tradeoff, but it'd have to be a small function in a really niche use case, which isn't really that common. (I work on the JVM though and don't know how good/bad Python libraries would be in general.)

This is cool. The world could definitely use more email server implementations, even if JS isn't my cup of tea.

Have you considered supplementing Mongo with block storage like S3, though? I've found it to be a pretty much perfect match for storing immutable mail messages.

Oh, sorry. I forgot to mark it as public. Feel free to try again.