Making email more modern with JMAP - <AUTHOR> https://fastmail.blog/2019/08/16/jmap-new-email-open-standard/ <comment><USER2> It will be interesting to see how this develops.

I've spent the last month implementing and testing IMAP support for my app [1].

It has... not been very fun.

Before we were limited to providers with a REST API, so implementing IMAP should in theory allow us to support a much wider range of email servers with a much lower support burden.

Although the protocol spec is tight, it seems like some providers randomly bug out or hang [2], respond with custom error messages, offer bespoke functionality [3], or generally don't comply with the spec in breaking ways [4].

As a result I'm more worried about this going forward than I had hoped.

I'll now also happily support anything that can help modernize email, so I'll apply to the developer program and will be watching JMAP closely.

[1]: [https://leavemealone.app/](https://leavemealone.app/)

[2]: Yahoo Mail always down ([https://downdetector.com/status/yahoo- mail](https://downdetector.com/status/yahoo-mail))

[3]: [https://developers.google.com/gmail/imap/imap- extensions](https://developers.google.com/gmail/imap/imap-extensions)

[4]: [https://github.com/mscdex/node- imap/issues/775](https://github.com/mscdex/node-imap/issues/775)

<comment><USER3> Having worked with IMAP before myself, the spec is very vague a lot. It's a bad spec.

We had our own IMAP server implementation and had all sorts of problems even between different versions of outlook.

Each project had an inbox which you could cc in, resulting in huge inboxes (for the 2000s at least). You could also drag and drop an email you'd received into the project folder to share it with colleagues. And we had mysterious disappearing emails, but only at some clients.

One (of the many) problems I remember is that messages could have an ID, but the spec declared that it could change between sessions, so one version of outlook stored that in a short uint (max 65535) because why would you need more for a temporary id. So have fun if you sent anything more than that. And of course the client had different versions of outlook on different sites so it took ages to even figure out what was happening.

Another was that you had to make several back and forths on every request, messages about the messages, to say the payload and number of messages, but the spec was gleefully vague about the order this should happen in. So back then what worked for one email client resulted in an empty inbox for another.

I don't think we ever got it working properly with Firebird.

<comment><USER4> Outlook is known to have a horrible IMAP implementation.

<comment><USER5> I've found Outlook's not too bad actually, and at least they support ActiveSync and MAPI for desktop and mobile. I always had the most problems with Gmail over IMAP.

</comment></comment></comment></comment><comment><USER6> Though I have no complaints about the way they went about implementing it (open standards hooray!), as a mail client author and someone with lots of experience with mail in general - I'm NACK to JMAP. I think that it comes with some questionable design decisions (HTTP? JSON?) which on their face I imagine look fine to the typical HNer, but in many ways is a regression from IMAP. I would prefer to see the limitations of IMAP addressed with a few carefully written extensions to the spec - which is already extensible and has a thriving set of useful extensions in the wild.

By no means is IMAP a particularly good protocol, but it is extremely broadly supported and designed more with email in mind than JMAP appears to be, which seems to focus more on bringing shiny web tech to email regardless of its utility in such a context. It's also one of many closely interlinked mail- related specifications, and JMAP fails to integrate well with many related specs imo.

<comment><USER7> JMAP is literally the _only_ positive thing that has happened to email in decades, please don't dismiss it (or do you know of anything else in the works that has any chance of success?).

HTTP and JSON are such an insignificant price to pay for the sliver of hope that email can be saved and not being in complete control of google et al.

<comment><USER8> The real positive thing that needs to happen to email, is putting an end to near-monopoly of gmail. Email is great. It's decentralized. You can simply roll your own. You can use whatever client you like. Apparently even using HTTP/JSON.

But you can't send mail to anyone using gmail, which is nearly everyone, unless you play by Google's rules. And even then they'll still put you in their spam folder, or just randomly blackhole you without any explanation or recourse.

JMAP vs IMAP vs POP is moot as far as I'm concerned. As long as my mail client continues to work, I'm good. If this gains any traction, I'm sure dovecot and the likes will add support for it (if they haven't already). But no amount of protocol fiddling can fix the fundamental issues of email centralization.

<comment><USER7> That's what I meant. And we need something better than IMAP/POP to have a fighting chance in challenging google. Because without it IMAP will, without doubt, loose market share even more - further cementing the dominance of larger players.

That is why protocol fiddling is an essential part of it. Not enough, but without something better than IMAP might as well give up yesterday (as most already have done).

<comment><USER8> > we need something better than IMAP/POP to have a fighting chance in > challenging google

How's that? I don't see how messing with IMAP/POP/JMAP will make a difference there. Mail _delivery_ , over SMTP, is what the Gmails and Outlooks of this world are so nasty about. They claim to protect their users from spam, but small mail servers get killed in the crossfire. Mail clients downloading mail over whatever protocol is a trivial problem by comparison, and they have zilch to do with SMTP abuse.

<comment><USER7> Yes, but it is all about market share.

If 99.9% of all mail originate from gmail+outlook then they can (and will) pretty much ignore the rest.

The less dominant they are the more they are forced to be reasonable.

JMAP will help diversify the market as well as simplify the process of creating competing products. And has the potential to vastly increase demand for native clients and proper support from webmail vendors.

All of the above will work towards lessen the dominance of gmail etc.

It isn't anything by itself but I believe it is a _requirement_ going forward.

Because IMAP doesn't cut it, so everyone has to create their own crap, which won't be as "good/easy/cheap" as gmail.

</comment></comment></comment></comment></comment></comment><comment><USER9> Pretty cool protocol. I've been following this for a couple of years. I had already written a library for an earlier version of JMAP (back then references worked differently / didn't exist); and it was interesting to see how that improved in the IETF process. I wrote a library [1] and a POC email client for Android [2] earlier this year. It takes a moment to fully understand a now fairly complex protocol but when you get the hang of it it becomes very powerful.

Sadly the server support isn't really there yet. The support for Cyrus hasn't been released yet (you need git) and some vital functionality like push [3] is still missing. Also no word from Dovecot yet.

[1]: [https://github.com/iNPUTmice/jmap](https://github.com/iNPUTmice/jmap)

[2]: [https://github.com/iNPUTmice/lttrs- android](https://github.com/iNPUTmice/lttrs-android)

[3]: [https://github.com/cyrusimap/cyrus- imapd/issues/2714](https://github.com/cyrusimap/cyrus-imapd/issues/2714)

<comment><USER10> Do you use Lttrs daily? I'm wondering if it works in practice (even when using non-standard setup) or if it's just a proof-of-concept (that'd mean it may take some time to mature).

<comment><USER9> No I don't use it daily. It can't even send emails yet and you have to set your login credentials at compile time. I got frustrated having to deal with HTML emails and now I'm waiting for the servers to mature a bit. And honestly also for dovecot to announce support. I mean I love what the fastmail+cyrus team is doing; but if Dovecot is not going to support it, it is probably not worth it to build a JMAP-only MUA.

</comment></comment></comment><comment><USER11> I'm a believer in open protocols, but in recent years, I'm also loving Exchange and ActiveSync. I know that's not going to be a popular opinion here. To be honest, I don't know much about how the magic works, but the configuration is simple, the push is reliable, and everything just works. It doesn't drain my mobile and it doesn't lose its indexing and download for hours like IMAP always seems to. And besides, it's mature -- Exchange and EAS have been around for many years.

So here's to JMAP becoming the open standard that replaces that.

<comment><USER12> Yes, but I can't tun it on my own low hardware at home for free.

<comment><USER5> Sure you can, I use z-push [0] integrated with Kopano which works great. You can also use z-push with IMAP, CalDAV and CardDAV. The only issue I know of using IMAP is that the z-push server polls your mailbox, so it's not true push, but vastly better than the battery drain of IMAP IDLE.

[0] [http://z-push.org](http://z-push.org)

</comment></comment></comment><comment><USER13> I dislike the details of JMAP's design.

While I appreciate the value it brings, I can see the 5 years of struggle in the sheer size of the multiple specs needed to define some pretty rudimentary mail client/server functionality (retrieve, send, push, pagination, etc).

At some points they use JSON (a data format) to describe procedures... like a programming language written in JSON. It feels a bit like using a screwdriver handle as a hammer.

How did we end up with JMAP instead of something simpler or modular, especially with GraphQL and other similar innovations on the radar?

<comment><USER14> > At some points they use JSON (a data format) to describe procedures... like > a programming language written in JSON. It feels a bit like using a > screwdriver handle as a hammer.

And folks laugh at me for suggesting S-expressions until I'm blue in the face!

Seriously, this is one of the areas in which they _excel_ (ref.: literally every line of Lisp ever written). They're a pretty nifty data format too (cf. [https://sites.google.com/site/steveyegge2/the-emacs- problem](https://sites.google.com/site/steveyegge2/the-emacs-problem)).

</comment></comment><comment><AUTHOR> From what I gather it should be possible to use 2FA with JMAP. I'm looking forward to no longer having to decide between using third-party email clients and properly securing the account that's probably most worth securing.

<comment><USER15> Would WebAuthn support be possible with JMAP? That would really move things forward.

<comment><USER16> One high level problem that jumps out at me is: When do we authenticate?

For web sites WebAuthn drops nicely into the existing login flow. The user knows what they're trying to do is log in, and so when they're prompted to touch the button or whatever it makes sense in that context.

But today most email apps just silently update all the time. So are we authenticating when the app starts and then re-using some credentials obtained to re-connect as necessary? Is that safe? Even if that's all we do (which might be safe) it means the user gets prompted for WebAuthn (to press the button) when the mail app starts, even if they aren't currently interested in email. If they dismiss it, when do we prompt them again? Because meanwhile they of course don't get any new email.

<comment><USER17> OAuth2 can handle this; you authenticate the mail client with an offline token that's valid for a long time. The mail client can refresh their tokens regularly and use a short-live token to authenticate their JMAP requests.

OAuth2 doesn't particularly care _how_ the token is obtained, so it can handle any arbitrary authentication flow, including WebAuthn.

And it's a widely supported protocol; there are libs for C++, Java, Go, JS and others, so it should be easy to integrate.

</comment></comment></comment></comment><comment><USER18> Fastmail should throw some engineering resources towards implementing JMAP support in some mail clients like Mutt.

<comment><USER19> The fastest route to MUA support is compatibility with existing MDAs like procmail, maildrop, and the like. At the very least a JMAP client that populates a local Maildir would get you Thunderbird, Evolution, mutt, and more.

<comment><USER20> Could a fuse filesystem do the trick for maildir emulation? Assuming that'd be beneficial to a full maildir, but I guess it'd only be so at large sizes.

<comment><USER21> Couldn't à hypothetical fuse fs emulate any file based store for email?

</comment></comment></comment></comment><comment><USER22> One thing I find weird (probably because I'm new to JMAP and still ignorant) is having _position_ AND _anchor_ + _anchorOffset_. Why have both? Surely the latter is sufficient and safer (as any _position_ is only guaranteed to be valid when the last response was written)? From a glance of the spec I didn't see any explanation of why. If anyone could shed more light it'd be much appreciated.

<comment><USER23> Both are necessary because you may not have the necessary IDs.

anchor + anchorOffset is useful when you use pagination and new entries might appear at the head of the list but you don't want them to mess with your pagination once you're inside.

position is useful when you have a total count and wish to jump in at the middle; as a concrete example, when you use lazy loading instead of pagination. For example, if I have a mailbox of 100,000 emails, and jump to the bottom: I don't want to need to fetch all the IDs (probably well over 1MB to fetch), just so that I can specify an anchor. I want instead to ask "give me the thirty messages from position 99,970".

(Note that when I speak of lazy loading I'm _not_ talking of infinite scrolling, but rather of when you know that you have N messages, and that each message is allocated M pixels of vertical space, so you can allocate an exact space, and provide a proper scrollbar. This is how Fastmail does it and how desktop email clients have historically done it.)

</comment></comment><comment><USER24> I read imap description long time ago, and I know what it does in principle (along with issues itt), but can someone explain what value does it serve today? I have two confusing thoughts.

First, imap seems to be an overkill for a line wider than 64kbps. Texts do not consume much traffic and an entire mailbox can be served easily to everyone. There are some huge mailboxes out there, but messengers have this problem too and they solve it somehow (I suspect trivial &last_date=... from programming tg bots).

Second, and this may be due to bad clients (haven't seen good however), imap is just sloooow. It doesn't update instantly, but instead I have to enter every folder and pull down with my finger to update it. It can show outdated messages which I deleted on a pc _for ten seconds_ before it figures out that they were deleted. My guess that it has something to do with an infinite number of roundtrips which this protocol is based on. Occasionally it shows N unread when there is none. Even push notifications fail to work properly most of the time (same server-side issues?) And with all these complications, I still have to download every attachment by finger. How come that heavy sites/forums/boards/messengers always instantly show new data and mail cannot? I know that I can simply use webmail, but wtf?

I'm a developer, but when I see software, I always try to evaluate it from user-only perspective. And from that, mail tech seems simply incompetent. I wish there was a port smtp->tg and tg->smtp, and special per-subj chats, so I could leave all that legacy for someone else to deal with and just talk to them without missing messages or _waiting_ for updates.

(Not even considering mail message formatting, spam mismatches, size restrictions and non-delivery laws)

<comment><USER23> The slow mail client issue you're describing is very probably an artefact of how IMAP IDLE is designed; JMAP fixes this design, as explained at [https://jmap.io/#push-mechanism](https://jmap.io/#push-mechanism).

</comment></comment><comment><USER25> "Modern", the darling adjective of startup lingo. We thank you for your service and efficacy. It's time to abdicate the throne. All hail "more modern" the rightful heir, protector of the realm.

Pre-modern -> modern -> more modern -> post modern?

Jokes aside I enjoyed the experience of Fastmail with the exception of the migration tools. Very responsive. Kudos for submitting JMAP as an open standard.

</comment><comment><USER26> I believe the filtering is for user-initiated search, right?

Would be nice to have some standardized support for sieve-like server side prefiltering. That's how I sort my mail into mailboxes, send spam (labeled elsewhere) to the spam trap, and the like.

<comment><USER27> What would this support look like, in the context of JMAP? By the time the email is in your inbox it's already gone through server-side prefiltering. So the only integration I can imagine is a way to fetch and store Sieve scripts so you can edit them from your mail client, but that seems like a very provider-specific thing.

For example, Fastmail themselves support Sieve, except they don't give you a single editable script, instead they convert your structured rules and spam settings into 8 labelled sections in a Sieve script and give you 4 free-form edit boxes to insert your own code at specific points (so you can't edit the code that they synthesize for you). I don't know how a protocol like JMAP would expose this in a generic fashion.

<comment><USER26> Two mechanisms: 1, the ability to write arbitrarily nested if all/any/none of various parameters (any/specific header w/restricted reflex) for server-side searches. The Mac mail app has these for the client side, as does my rss reader. A simpler grammar than needing _inMailboxOtherThan_ yet more powerful. Could be represented as a json tree. 2 - the ability to run that filter n incoming mail basically where sieve is run today, with a similar small grammar for specifying a small set of commands to run like file in mailbox, tag, etc.

</comment></comment></comment><comment><USER28> I didn't see anything about security. I understand sending is outside the scope. But if storage and downloading is to be portable, doesn't encryption have a place?

<comment><USER29> The encryption of the connection is orthogonal. That's what HTTPS is for.

And client-side encryption is managed by solutions like PGP. Doing it on the server-side is incompatible with the email protocol IMO.

<comment><USER28> So server side is secured how?

<comment><USER29> Not sure I understand the question. What's your threat model?

<comment><USER28> On the server, the emails are all encrypted like say passwords? Or are they stored as text?

<comment><USER30> Passwords aren't encrypted, they are hashed.

Every email service out there stores email in what by password standards is plaintext, but hopefully encrypted at rest.

</comment></comment></comment></comment></comment></comment><comment><USER31> So, how long until everything is JSON-shit over port 80 and how long until port 80 is old news and only port 443 is used for anything and everything? I can't claim to be familiar with IMAP, but it can't be worse than this garbage that requires an HTTP client and a JSON parser.

To process JSON, you must inspect every character, which is reason enough it's an awful ''format'' that only an ignorant could hold dear. Douglas Crockford brags about how smart he is for disallowing comments, but there's whitespace allowed everywhere. Let's not forget this asinine integer nonsense, because JavaScript lacks real integers.

I'm sure most people think HTTP clients and JSON parsers are standard-library affairs, nowadays, though; let's just entirely ignore matters of licensing and whatnot.

It's disgusting to see this as an IETF standard, but people have been complaining about how that moves along for decades; take a look at Google's robots.txt ''standard'' that doesn't do anything useful and effectively makes every existing file standard, rather than do much of anything worthwhile. The WWW and JavaScript are nothing more than a continuation of this worse-is- better filth that UNIX and C previously championed; decades ago, the IETF revised the RFC for the Finger protocol and warned about security, solely because some idiot wrote a shitty Finger server in C; now, we have useless and unnecessary standards such as this that only serve to further this next generation of idiocy.

I wonder when all of this will finally collapse under its own weight.

<comment><USER32> Can you provide some actual arguments as to what's wrong with JSON? It's a text format that can be inspected by humans, unlike binary formats. (Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases).

<comment><USER31> >Can you provide some actual arguments as to what's wrong with JSON?

It's a wasteful, textual format derived from a programming language vomited forth in under a week. It has asinine integer characteristics for no good reason; it's not a random-access format; validating it is even more work; hash table keys that appear multiple times, instead of being in error, instead overwrite each other, defeating most any kind of optimization; it is thus wildly inefficient to manipulate, as manipulating it correctly in all cases requires full and comprehensive parsing with checking. It is an asinine ''format''.

>It's a text format that can be inspected by humans, unlike binary formats.

Even then, there are much better textual formats that could be used, but I'm of the opinion that numerical (binary) formats are strictly superior, especially as they're used increasingly often. It's better to have good tools that will provide a human-readable representation, rather than pretend a single, inefficient representation for both man and machine is somehow the best option.

>(Maybe IMAP is a text format too, so this isn't an advantage inherently) And JMAP may have better semantics than IMAP, and there's nothing inherently wrong with JSON (other than edge cases).

Computer programs written by anyone competent are built around edge cases; that's much of what any reliable program is, accounting for edge cases. To disregarded edge cases, of which there are many in JSON, speaks to me that you have little concern for writing software correctly, but I imagine you'd deny this, as who doesn't want to write correct software? Simply understand that using a format with so many edge cases and other defects as JSON is foolhardy for much of anything.

<comment><USER32> >numerical (binary) formats are strictly superior, especially as they're used increasingly often. It's better to have good tools that will provide a human- readable representation, rather than pretend a single, inefficient representation for both man and machine is somehow the best option.

I'm working on a chiptune music composing program (FamiTracker), which saves projects in a binary format designed by my predecessor. I once repaired a corrupted file for someone else. It's borderline impossible to repair binary formats by hand, since inspecting the data on-disk provides no clues about the structure, which I don't know since I didn't write the program. I ended up merging the corrupted file and an older backup in Audacity (an audio editor) by sliding the two files back and forth relative to each other, because hex editors are awful at visualizing and aligning binary files (whereas diff tools are good at visualizing and aligning text files).

Additionally, the on-disk layout changes between versions, and the reader code is a mess of branching between different on-disk layouts based on the version number.

Additionally, it's impossible to check in your music project (binary blob) into Git, then get a meaningful diff between different versions, let alone being able to merge changes made in 2 branches. (Yes, I use Git for music. It's actually useful.)

Needless to say, I'm using a text format if I ever write a replacement. A text format may have trouble encoding binary blobs, but I don't like the idea of "transcoding .wav into binary files, and throwing away the parameters used". I'm more inclined to just use pointers to on-disk .wav, and store all metadata needed to reproduce the binary blobs, and possibly cache the binary blobs in base64 for speed and convenience.

<comment><USER31> _I 'm working on a chiptune music composing program (FamiTracker), which saves projects in a binary format designed by my predecessor. I once repaired a corrupted file for someone else. It's borderline impossible to repair binary formats by hand, since inspecting the data on-disk provides no clues about the structure, which I don't know since I didn't write the program._

That's interesting. If you're interested in discussing that more at some point, email me. Now, I've designed a numerical format for metadata involving machine code programs and, while I've not written this piece yet, an important aspect of this will be a repairing tool. The only reason a textual format would be easier to repair by hand is because you can use a text editor and it's more redundant. Now, good design is another quality; ideally, a numerical format would lack _holes_ that are invalid states and wouldn't be riddled with pointers or other things if feasible; it varies based on what you're doing, though.

 _I ended up merging the corrupted file and an older backup in Audacity (an audio editor) by sliding the two files back and forth relative to each other, because hex editors are awful at visualizing and aligning binary files (whereas diff tools are good at visualizing and aligning text files)._

That's again a simple matter of tooling that could be corrected.

 _Additionally, the on-disk layout changes between versions, and the reader code is a mess of branching between different on-disk layouts based on the version number._

A runaway format revision like that isn't ideal, I can agree. You can get the same mess with textual formats, however.

 _Additionally, it 's impossible to check in your music project (binary blob) into Git, then get a meaningful diff between different versions, let alone being able to merge changes made in 2 branches. (Yes, I use Git for music. It's actually useful.)_

I don't use git at all, so this is another difference between us. I'm largely of the opinion that the focus on _textual formats_ for UNIX-likes was due to sloth more than anything, as there's generally a lack of coherency between _/ etc/fstab_ to _/ etc/passwd_ and so on; I believe the focus was largely due to the advantage of ostensibly generic tooling, but reading or writing a configuration in a text editor, with the manual handy, and getting errors and other things upon loading it is worse than having a tool write it for you and show it to you at a high-level.

 _Needless to say, I 'm using a text format if I ever write a replacement. A text format may have trouble encoding binary blobs, but I don't like the idea of "transcoding .wav into binary files, and throwing away the parameters used". I'm more inclined to just use pointers to on-disk .wav, and store all metadata needed to reproduce the binary blobs, and possibly cache the binary blobs in base64 for speed and convenience._

I don't know the details of what you're dealing with, but again, if you're interested, email me and I can perhaps work on a repair tool or help design a replacement numerical format that will be easier to manipulate.

</comment></comment></comment></comment></comment><comment><USER33> So a few years back, everything was super fast on IMAP on my phone. But now it just crawls. On the Gmail App it's still pretty fast. So I just assumed it was slow because Google was being a dick and trying to get people to use their app instead of Apple Mail or Outlook. Is the protocol slow, or is Google throttling it?

<comment><USER2> Having just this month implemented an IMAP client I can tell you it's blazingly fast for Gmail & Outlook.

It's actually much faster and more efficient than using the Gmail API.

<comment><USER33> I just clocked it at 16 seconds to check for new mail in Apple Mail checking against a Gmail Account on an iPhone SE connected to Google Fiber. It feels pretty slow...

Meanwhile, same update vs same account in Outlook took about 6 seconds.

And in the Gmail App, about 4 seconds.

Not super scientific, just me looking at my watch and opening each app and seeing how long it took to update.

So maybe something with Apple Mail?

<comment><USER2> The slow part is opening the IMAP connection and authenticating, after that it's fast.

I guess it might depend on how these clients are maintaining their connections.

</comment></comment></comment></comment><comment><USER34> Give me the speed of fastmail with the encryption of protonmail, make the two talk to each other out of the box, and actually make something new instead of just the same old thing.

Actually, loan some of your devs to protonmail because both their mobile app and their imap bridge are embarrassing.

</comment><comment><USER35> They list the wrong RFC number "8261", but the linked RFC is actually "8621".

<comment><USER36> Thanks! Have fixed the copy. The link was going to the right place, but somebody (possibly me) put the digits in the wrong order.

For your efforts, please enjoy a joke: [https://comic.browserling.com/tag/multithreading](https://comic.browserling.com/tag/multithreading)

(that's my excuse - brain was running multithreaded output to the fingers)

</comment></comment><comment><USER37> [https://jmap.io/#push-mechanism](https://jmap.io/#push-mechanism) JMAP going to use rfc8030 push for mobile (3rd party service for notifications, really?) and EventSource (kind of http long polling) for desktop clients, as I understood. I don't like that idea, it's even worse than IMAP4 IDLE. Why not just WebSockets for mobile and desktop clients?

Or just building it on top of XMPP protocol (or any other chat protocol).

<comment><USER38> HTML5 Server Sent Events are better than long polling, and they're about as old as websockets, but simpler, as they maintain the concept of HTTP resources whereas websockets replace the concept. HTML5 SSE is also easier to implement.

Not hating on websockets, but saying HTML5 SSE is outdated tech is just wrong. If you were making a real time app that works over HTTP either would be fine.

<comment><USER37> > HTML5 Server Sent Events are better than long polling

But it works the same way: infinite http connection.

</comment></comment></comment><comment><USER39> Is the protocol itself important to users? or is it mostly important just to developers?

If it makes a practical difference to a user, how so?

</comment><comment><USER40> Lets ignore the biggest issue (spam) and focus on the bike shed.

<comment> dane-pgp No one's stopping you from coming up with your own anti-spam technology.

In fact, it's possible for individuals and organisations to work towards multiple goals at once. For example, Fastmail and the IETF have concurrently been working on RFC 8617, which allows for stricter spam filtering:

[https://dmarc.org/2019/07/arc-protocol-published-as- rfc-8617...](https://dmarc.org/2019/07/arc-protocol-published-as-rfc-8617/)

<comment><USER40> The reason people choose Gmail or Office instead of smaller providers, is 1) They get less spam 2) Less likely get their mail market as spam. This centralization is killing e-mail. But that's just e-mail. What protocols do people use to send messages ? Facebook messenger, Whatsapp, etc. More proprietary centralized solutions. We need a simple decentralized protocol, as simple as SMTP, bit it need to solve the spam issue, and it need not to be over-engineered (like XMPP). And no, it should not be built ontop of SMTP, SMTP has so many issues, like you can send mail pretending to be anyone. There are solutions like SPF, DKIM etc, but 1) they are built ontop of SMTP 2) They are not stopping spam. We need a new protocol that replaces SMTP, and have spam prevention, identify, etc built in.

<comment> dane-pgp Email could be free from spam if you configured your email client to only accept emails from people you manually added (and if SPF/DKIM was enforced). It's not clear how replacing SMTP with a different protocol would make the situation any better.

The reason why centralised chat systems can limit spam is that one company gets to decide who can and can't send messages to whom. Recreating that in a decentralised architecture is precisely the problem that needs to be solved, and the solution could then be used by email providers.

Now there are no technical reasons not to use SPF/DKIM, and recipients can enforce it more strictly, the problem seems to be determining which mail providers (i.e. which domains) can be trusted to stop their users from sending spam. Spammers have realised this too, of course, which is why a lot of spam comes from domains that are registered cheaply and quickly abandoned.

One solution that might be worth exploring is requiring that domain registrants provide a bond to their registrar if they want to send mail from that domain (grandfathering in all existing domains). The bond could be refunded after, say, 12 months of sending enough emails that recipients don't mark as spam.

The difficulty with this is creating a reporting mechanism that can't be gamed, either to unfairly cost a domain its bond, or to flood the system with fake positive reports to drown out the true negative ones. Fortunately, with DKIM, there is at least cryptographic proof that a given email was sent by a given domain.

<comment><USER40> Messages should be sent from client to client. The server layer can be skipped. But the client could of course be a cloud based email solution. Messages would need double opt in, which would be baked into the protocol. Id's would be a random hash. Personal messages could be trust based eg. "Do i know this person" and corporates could use certificates. Once a user has opted in to receive messages from a id/hash the receiver would generate a challenge at the start of each session, either using a shared secret or public key crypto (also baked into the protocol). The protocol should have a standard for sending simple text. But then allow extension protocols, for example implementing voice/video. With capabilities eg. Client tells the other client what formats it accepts.

</comment></comment></comment></comment></comment><comment><USER41> FINALLY

</comment><comment><USER42> Super happy customer of Fastmail of 7 years now.

It's a joy to use. Fast, responsive, and reliable. No pointless redesigns or 10 second loading screens like gmail.

<comment><USER43> .. what does this comment have to do with the actual article other than keying off of 'fastmail' in the title?

<comment><USER44> Fastmail's web interfaces uses JMAP under the hood.

<comment><USER45> Hmm. I'm a happy FastMail customer of >2 years, but sometimes the web app loses the connection with the host (especially when on flaky wifi) and fails to re-establish it. This is really aggrevating when you hit send on an email, which disables the input text box but then just hangs indefinitely in a "Sending..." state. I've already reported this to customer support. Symptom of JMAP, or just a run-of-the-mill bug somewhere?</comment></comment></comment></comment>


D3 v4.0.0 Released - <AUTHOR> https://github.com/d3/d3/releases/v4.0.0 <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11995332](https://news.ycombinator.com/item?id=11995332).

<comment><AUTHOR> Why were they moved there, when this was submitted an hour prior to the linked post, and upvoted significantly?</comment></comment>


Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly - <AUTHOR> https://github.com/icebreaker/floppybird <comment><USER2> This is just beautiful:

[https://github.com/icebreaker/floppybird/blob/master/src/mai...](https://github.com/icebreaker/floppybird/blob/master/src/main.asm)

Nicely structured code! I'm almost tempted to port it to amd64, just for fun. After all we really don't need any more x86/16bit example code, we need more amd64 code! :-)

<comment><USER3> I've been saying this to my co-workers over the past week as I've gotten into modern day assembly (ARM, but still): It's basically a high level language at this point! It's amazing how much structure you can actually give yourself with modern tools.

<comment><USER2> I'm not sure you really need much in the form of modern tools to achieve this -- the code base above is basically include macros and jump labels?

As mentioned by agumonkey, it feels a little bit like Forth.

In fact, I seem to recall a rather excellent tutorial on 68000 assembly featured very similar structure (even if I never finished it -- at the time I was defeated by my own bugs and the fact that those bugs, without an MMU or memory protection, could easily crash the entire machine. It was rather demotivating...).

For another example, see the original source of Apple II DOS, posted here a while back:

[http://www.computerhistory.org/atchm/apple-ii-dos-source- cod...](http://www.computerhistory.org/atchm/apple-ii-dos-source-code/)

Fundamentally I don't think the structure of the code is all that different? (Please correct me if I'm oversimplifying, or missing something).

</comment></comment></comment><comment><USER4> Thanks for wasting 4 minutes of my life! For some reason, I picked up a Wyse Winterminal S50 from Weird Stuff last week... a thin linux client box from 2006 that has some sort of underpowered x86 and very little memory.

So I was playing with it and it has this weird linux on it that lets you set it up to very slowly browse the web and such, but it wasn't very interesting, all told.

When I saw this project come up, I grabbed the .img, wrote it to a spare usb stick and damn if the thing didn't just boot up to floppy bird. Nice work! Now I wonder what other dumb PCs I have sitting around that can boot it...

<comment><USER5> Turns out after you have written the floppy IMG to a blank uFD or HDD, and it boots and plays the game, then you can partition the drive (I used Linux Mint), format it as FAT32 or NTFS, and use the full drive for mass storage without a conflict.

Same drive still boots to Floppy Bird only, unless you install some other OS or something which overwrites the Floppy Bird bootloader on sector 0, and give up the bird.

Partitioning and formatting alone do not overwrite the MBR, even if it is just a custom floppy boot sector at the time.

</comment></comment><comment><USER6> "Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly.

In other words it works on RAW METAL and doesn't require an Operating System."

The second statement doesn't quite follow the first. You can certainly write a 16 bit x86 assembly DOS application.

<comment><USER7> It's also not really running on "RAW METAL" because it's using BIOS interrupt routines for drawing and input.

It's still awesome, though, and the code is really cleanly written and easy to follow.

Because the code is so nice, this would be a fun project to try to port to Protected Mode with its own HAL and maybe drivers for one set of hardware (perhaps QEMU's). Could be a fun experiment in why OSes are hard and x86 is painful.

<comment><USER8> vga.asm copies bytes directly to video memory in a raw manner, once it's in VGA mode. It only uses BIOS to switch into VGA mode ("mov ax, 0x13" and then "int 10h"), and back to text mode before rebooting when you quit. It does use BIOS to read the keyboard. It also reads bytes from sectors of the disk using BIOS rather than the OS when it starts up. The sound is a beep created with raw "OUT" commands on the data ports (for the PC speaker presumably).

In other words, it's using BIOS for input, but not drawing.

<comment><USER9> ticks() and sleep() also use BIOS. The author could have implemented this by handling IRQ 0. :-) Come to think of it handling the keyboard interrupts isn't that hard either...

Also looks like boot.asm uses the BIOS to read the rest of the program...

<comment><USER5> Seems like if the "boot.asm" (actually sector 0 of the floppy) could be made relocatable away from sector0, then it could still be functional when stored in a filesystem (including on a HDD) not unlike BOOTSECT.DOS. The remainder of the floppy (sectors 1 through 16 proper) when copied to the same sectors (which are normally blank and unused) on a MBR/BIOS style HDD work just the same as from floppy without having to be in a filesystem themself.

Then you could easily chainload to Floppy Bird on a HDD from other bootloaders (like WinNT5 & NT6), with no changes to the main ASM program.

EDIT: the comments in boot.asm refer to sectors 1 & 2 since they are the first 2 sectors of the floppy, these two are officially numbered 0 & 1 in a disk editor or DD command.

<comment><USER9> This stuff is kind of annoying to write. When I wrote stuff on raw metal (hobby OS kernel) I mainly just built an ELF file that GRUB can load. (Surprisingly easy to do.) Or, in days before that when I used more Microsoft stuff, a small .COM file where ms-dos or freedos is a glorified bootloader. (DOS is totally cool with a program hijacking everything.)

</comment></comment></comment></comment></comment></comment><comment><USER10> Super sweet!

Does it have a switch that lets the computer cheat?

[http://www.catb.org/jargon/html/story-of- mel.html](http://www.catb.org/jargon/html/story-of-mel.html)

<comment><USER11> I had not read that before.. a great read. thank you.

</comment></comment><comment><USER12> First of all, this is really cool and I think the closest thing I have seen to 'readable' assembly.

Tiny nitpick: doesn't running asm still require an operating system? I haven't read all of the code but I assume that there are instructions for I/O or other traps that require the OS. Isn't the OS just the layer between the hardware resources and programs that want to access those resources?

<comment><USER13> It might or might not require an OS; you can implement the hardware access code directly into the program.

<comment><USER14> True, you could leave out the bootloader and some of the sys code and this would then nearly be a DOS program, at least the port to DOS would be easy. Leaving it as is allows it to boot without an OS.

</comment></comment></comment><comment><USER15> Is "I made a Flappy Bird/2048 clone with a TWIST" the 2014 equivalent of "I installed Linux on my hat"?

Although I admit this is more impressive than the usual "Floppy Bird only slightly different."

<comment><USER16> And all of that, in 24 lines of javascript.

</comment></comment><comment><USER17> I'm wondering: how hard would it be to add sound to this thing? I think it uses Piezo sound, which is probably easily addressed. But what about midi or PCM output? Would you have to target every manufacturer specifically?

I really liked how fast my computer "booted" into the game. I would totally start collecting games like these if there were a scene.

<comment><USER18> Correct me if I'm wrong, but I think you could cover fairly wide range of hardware with two generic drivers, AC'97 and HDA.

edit: for this project specifically there is the small problem that you probably need to enter protected mode for "modern" audio.

</comment></comment><comment><USER19> This is really cool. Is there a practical reason why you would write a game in assembly (speed? portability?)

<comment><USER20> Assembly is about as nonportable as you can get. Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. The second and third are _almost_ entirely outdated - storage of executables is free relative to storage of data; hardware speeds have made "slow" programs plenty fast for most things; and compilers can do better than you can _quickly_ do, very quickly. The first is still a valid reason to use assembly, but typically in the form of a small snippet of inline assembly in C/C++ code.

<comment><USER21> > _Hardware access (not exposed by other languages), speed, and possibly > executable size are the practical reasons one would write in assembly._

This is a bit misleading, accesses to physical memory, disks and to other devices are usually protected by the operating system, not by the language. So you don't have direct hardware access because you program in assembly, but because you run a program without the control of an operating system. This can be done in assembly, but also in C or in any other language that can generate native code.

The only thing that you _can_ do with assembly and that you can't really do with higher level language like C is accessing processor specific registers/instruction sets (e.g. SSE). And this is typically done using inline assembly snippets, as there is no reason to write a whole program in assembly when you only need to optimize a single function.

So I would say that having better hardware access is _not_ a good reason to write an entire program in assembly.

On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)

<comment><USER20> Hmm, I guess there is some room for misinterpretation.

First, you seem to think I was answering a slightly different question - "In what circumstances should I make the decision to write assembly?" The question I was answering was closer to "When people need to write assembly, why?"

The actual question, of course, was not _quite_ either of those.

Also, addressing a point of ambiguity:

I did _not_ mean "hardware access ([this is something that is] not exposed by other languages)" \- that is, in general, wrong.

I meant "hardware access ([when the particular thing is] not exposed by other languages)". This includes SSE (though that is starting to be included as builtins in some compilers). Outside of SSE, I grant that there isn't much _on x86 platforms_ that _is relevant to a game_ , since games on x86 platforms typically run under an OS. It can be relevant if you're writing a driver, though. And this can vary substantially by platform.

And no, it's not a good reason to write an _entire program_ in assembly unless a sufficient percentage of your program is calls to these things that the C inlines are just adding cruft.

 _" On the other hand, building small, standalone executable file that use very little (stack) memory is still relevant for programs that run on very small (usually embedded) hardware. Especially when they need to run fast or to have low energy consumption. So speed and memory usage are still pretty good reasons to use assembly :)"_

No, _that_ is substantially more misleading. Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick.

<comment><USER21> > _I meant "hardware access ([when the particular thing is] not exposed by > other languages ..._

Ok, I agree.

> _Like I said, you cannot quickly do better than a modern compiler, and a > compiler does it very, very quick._

I'm not sure what you mean by "quickly" but this submission proves that it can be done in reasonable time. And if you look at the code (for example here: [https://github.com/icebreaker/floppybird/blob/master/src/gam...](https://github.com/icebreaker/floppybird/blob/master/src/game/bird.asm)), it's obvious that you cannot produce anything nearly as compact and efficient with a compiler.

So, claiming that assembly is still a language of choice nowadays was maybe exaggerated, nevertheless it's nice to remember that no matter how good they are, compilers come with a cost. If you need some evidence simply compare the submitted code with any code produced with a compiler.

<comment><USER20> _" it's obvious that you cannot produce anything nearly as compact and efficient with a compiler."_

It's not obvious. We can argue over what's "nearly", but without even trying, manually converting the assembly to C I get 71 (1.5x) instructions out of gcc and that includes an inlining of animatebird. The resulting code is otherwise not so far from the original. It certainly _reads_ more poorly, but that's to human eyes not x86. I'm not sure which would be more performant, and playing more carefully with the code and optimizations it can probably get even better.

<comment><USER5> Well, on Android the original Flappy Bird was 894kb in size, and this Floppy Bird is only 8.7kb.

Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1.

The TAB key changes the bird's color scheme.

<comment><USER20> _" Well, on Android the original Flappy Bird was 894kb in size, and this Floppy Bird is only 8.7kb."_

You're actually making my point. Virtually the entirety of _both_ those numbers is going to be image (and, on the Android version, audio data). Using lower-resolution assets is not something reserved to assembly language, and the size of the code is just not an issue next to that, _most_ of the time. The biggest exceptions on desktops/servers being when executable makes the difference between spilling instruction cache and not. Things can get tighter on embedded, but there too tables and stuff are more often the cause of contention.

 _" Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1."_

Enough code to obviate the need for an OS (for this narrow use case, in Real Mode with BIOS calls available) is probably fewer bytes than enough metadata to convince Android to run you. But as mentioned, you're not actually comparing code size at all really.

 _" The TAB key changes the bird's color scheme."_

I'm not sure what your point is here. Cycling palettes is a neat trick, but nothing new, nothing complicated, and certainly nothing that couldn't have been done as easily in another language.

Edited to add: Perusing your other comments, you seem to have plenty more savvy than your comment would show... were you trolling or trying to make some oblique point that I missed or what?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Does anyone know why GIMP is listed as a build dependency?

I don't see it being called anywhere in the Makefile.

<comment><USER23> It's probably just used to create the .tga images loaded in [https://github.com/icebreaker/floppybird/blob/master/src/gam...](https://github.com/icebreaker/floppybird/blob/master/src/game/data.asm)

</comment></comment><comment><USER24> Floppy bird? Written in assembly, I half expected it to be called "Snappy Bird."

<comment><USER25> It's called like that because it's a booter[1], so it's loaded from a floppy disk at boot time.

1\. [http://en.wikipedia.org/wiki/PC_booter](http://en.wikipedia.org/wiki/PC_booter)

</comment></comment><comment><USER26> I would love to see a chart of when each of these ports came out. It would be a pretty interesting representation of the difficulty of building the exact same thing in various languages.

</comment><comment><USER27> For systems running Debian you might need to install a mkisofs replacement.

$apt-get install genisoimage $ln -s /usr/bin/genisoimage /usr/bin/mkisofs

builds fine after this.

</comment><comment><USER28> This simple game has gotten so much attention since it was released (and ten taken down).

</comment><comment><USER29> First time I'm understanding Assembly easily, very good this source code.

</comment><comment><USER30> Yes! Enjoying the assembly love recently. Awesome work!

</comment><comment><USER31> I like his girlfriend implementation better: [https://github.com/icebreaker/girlfriend](https://github.com/icebreaker/girlfriend)

</comment><comment><USER32> great work always looking forward to seeing amazing examples like this on HN. Thanks you

</comment><comment><USER27> Nice work, thanks for posting.

</comment><comment><USER33> just added this as a option to a fog server

</comment><comment><USER34> Mechanics seem... a little off.</comment>


Dropping out after Google internship? - <AUTHOR> I'm a sophomore working at Google this summer and I go to a no-name university. I've been considering dropping out since I feel like school isn't really working for me (also have a ton of loans), and was curious if Google allows you to join full time after an internship even if you don't graduate. Obviously this is barring passing the exit interview and everything, but does Google even allow it? I have friends who dropped out after their internships at Uber and Facebook, but Google seems to be a bit more bureaucratic. Has anyone been in this situation before? I understand the reservations about dropping out, but my school allows me to take time off and still come back to rejoin as a student, so in the worst case scenario I'll rejoin my university. <comment><USER2> Ask your recruiter or your manager, not randoms on the internet.</comment>


Greenland ice has shrunk beyond return, study finds - <AUTHOR> https://www.reuters.com/article/us-climate-change-arctic-idUSKCN25A2X3 <comment><USER2> Even if the world is warm enough to melt the sheet completely, that would take centuries, if not millennia; Greenland's ice is thousands of meters thick. In a bad scenario, the IPCC forecasts 21st century sea level rise to be a bit under a meter ([https://www.climatecentral.org/news/zeroing-in-on-ipccs- sea-...](https://www.climatecentral.org/news/zeroing-in-on-ipccs-sea-level- rise-warming-hiatus-16532)). This will certainly cause problems, but is nothing like the complete and rapid destruction some pundits describe.

Major action on carbon emissions is long overdue, and it's great that people are taking it more seriously now. But an overly-pessimistic scenario has the same problems as an overly-rosy scenario; if we're all doomed anyway, why do anything? Michael Mann, the climate scientist who famously brought global warming to public attention, now also spends time fighting doom scenarios which also discourage action:

[https://alumni.berkeley.edu/california- magazine/summer-2020/...](https://alumni.berkeley.edu/california- magazine/summer-2020/michael-mann-on-climate-denial-and-doom)

<comment><USER3> I like the way the 350.org science page put's it:

       1.  It's warming.
       2.  It's us.
       3.  We're sure.
       4.  It's bad.
       5.  We can fix it.

([https://350.org/science/](https://350.org/science/))

<comment><USER4> The 'its bad' section could use some work; it isn't immediately obvious why it is bad. It says things like 10% decrease in grain yield. World population has increased by ~40% in my lifetime; so a 10% grain yield is not the biggest problem we're facing for food security.

Ditto the 10 million migrant number. Australia has 7 million migrants living here right now; 10 million globally spread over many years is not particularly devastating.

Climate change is supposed to be a threat significant enough for people to abandon their way of life, not those so-so numbers.

<comment><USER5> Is there any evidence at all that global warming is causing any migration? I look at the problems in Syria and I'm definitely not saying "Yep global warming causes that."

<comment><USER6> Given that one of the 10 biggest countries in the world has virtually no elevation and is already having drinking water problems (Bangladesh), a migrant crisis is certain.

<comment><USER7> The water problems of Bangladesh seem to have little to do with climate change. It's a mix of political problems with neighboring countries, arsenic contamination of the soil, lack of sanitation.

</comment></comment></comment></comment></comment></comment><comment><USER8> Covid-19 has exposed how almost all world leaders are useless when faced with big challenges - any action taken will be far too late; too little and often times plain wrong.

So as I read about Greenland's ice sheets I can only conclude that we are all doomed. Raising awareness won't really help; the leaders who could do something about it simply won't.

It's sad and it's depressing and I've no idea what any of us can do to actually prevent this next global catastrophe.

<comment><USER9> >Covid-19 has exposed how almost all world leaders are useless when faced with big challenges

Many countries have done pretty well coordinating a useful response against this virus. The US has done terribly, but there are plenty of examples of other nations responding well to it.

<comment><USER8> I think you're mistaken. No one started to care until Italy happened weeks after the WHO warnings. China locking down 11m people didn't ring any alarm bells in the west.

Even when Italy happened not all countries reacted, instead thinking 'oh we don't have that problem we're fine'

And then as cases did go up other countries for 'creative' with their handling - the UK totally gave up on testing in March and was secretly thinking to 'ride it out' and go for herd immunity.

So the few examples where it was handled well (say Taiwan and South Korea) are irrelevant when considering the strength of the overall global response.

Now, for dealing with melting ice sheets we need more than a majority of countries working together to prevent an event that will displace millions of people but right now the response is similar to how we responded to COVID - but imo the stakes are higher now.

<comment><USER9> My point is that not all countries did bad. Many countries did poorly, but many others responded well to the crisis and have either kept cases down, had very few deaths, or managed to suppress their outbreaks.

> China locking down 11m people didn't ring any alarm bells in the west.

Yes it did. Australia and NZ started preparing very early for this outbreak. The results are very evident. The US and the UK responded terribly, and their people should be very angry.

</comment></comment></comment></comment><comment><USER10> What I find most interesting is that we, the Human species, do not know what this means. We estimate heavy losses, maybe near extinction, but we do not have a reference. We are imaginative but we collectively can not imagine the worst and act accordingly. This is perhaps why the worst will actually happen.

I am typing this on a keyboard, when I should be getting out there, convincing others to stop our immediate actions and brace for impact. But I will not do that because _some unclear calamity is 30 years away_. And I know most people around me will not change anything either.

<comment><USER11> > We estimate heavy losses, maybe near extinction

Do you mean human extinction or extinction of certain animal species? I can definitely see certain animal species dying out, I couldn't see a scenario where humans die out though. If you mean human extinction could you provide some further reading?

<comment><USER12> Might not be the most likely scenario, but a runaway green house effect is certainly possible.

If a positive temperature feedback loop happened to the earth's atmosphere we could definitely end up like Venus, where no living thing can survive.

And as engineers we understand that positive feedback loops cause changes in exponential progression. It can be "almost fine" for a while and then suddenly "there's nothing we can do" even in human timescales.

And it could happen fast enough that humans don't develop tech robust enough to survive other planets unsupported, so game over for humanity, better luck next time.

I personally don't think thats going to happen, but to be honest I wouldn't want to risk it.

<comment><USER13> Earth survived way higher co2 levels and we don't emit nearly enough sulfides. There is essentially zero chance of Venus event happening. I'm more inclined that climate change can cause catastrophic war than runaway to ultra high temperatures.

<comment><USER14> Past CO2 levels aren't relevant because over time things like solar irradiance change as well. The amount of CO2 needed to maintain a certain global temperature shrinks over long time frames (hundreds of millions of years) as the sun gets hotter and hotter until it finally dies.

<comment><USER13> Except sun hasn't become meaningful hotter in the past hundred mil years. Also, we would need lots of sulfer dioxides to get emited, which isn't happening.

Will earth suffer over the next billion years and lose atmosphere? Sure, but that's not what's happening now.

</comment></comment></comment></comment></comment></comment><comment><USER15> > The Arctic has been warming at least twice as fast as the rest of the world > for the last 30 years, an observation referred to as Arctic amplification.

I didn't realize this (or at least, am surprised it's _twice_ as fast). Apparently the key factor is loss of sea ice. Can anyone ELI5?

<comment><USER16> I'm not sure this is the reason for this specific observation, but one mechanism I've read of was that arctic air is very dry relative to equatorial, and any heating up increases its humidity, and in turn water vapor is a much more intense greenhouse gas than many other things, so it can cause more localized warming, which feeds a cycle. Why it isn't a complete runaway process i don't know, and I may be misremembering the details.

<comment><USER17> And of course, Siberia and Canada will start emitting vast amounts of methane as permafrost thaws.

<comment><USER18> At least if the northeast passage opens up, we'll have a sea route between china and europe that doesn't go past the resource-cursed middle east.

[https://en.wikipedia.org/wiki/Northeast_Passage](https://en.wikipedia.org/wiki/Northeast_Passage)

</comment></comment></comment></comment><comment><USER19> There is already a pile of canary bodies on the mine floor. Just toss this one on top of it.

Oil and gas is a multi-trillion dollar industry. It's not just an industry that a few companies rely on, or a few cities, or a few states: the economies of more than a few wealthy _countries_ rely fully or partly on oil and gas revenue.

Consequently, there has been a massively-funded multi-decade disinformation campaign w.r.t. climate change, calling itself "climate skepticism."

But: the brilliant part of this disinformation campaign was to politicize it.

If it were just: "we have questions about the science", well, once those questions are resolved, then climate skeptics have nothing left to stand on.

But once you politicize it: now it's more than the science. It's about your tribe and your team.

<comment><USER20> When "scientists" are openly pushing for particular solutions (always involving massive government control and global wealth redistribution), they are politicizing it too.

When the "green" movement also opposes the best alternative energy, nuclear, it's worth being very suspicious.

That is of course all orthogonal to whether it's actually real and preventable and worth acting on. Though that last question requires expertise beyond climate science. It also requires a fine understanding of economics and international power politics. When climate scientists pretend to have those too, people should be skeptical.

<comment><USER21> I personally believe in manmade climate change but when I read about things like the "global warming pause" I get concerned.[1]

About 5 years ago there was a lot of discussion about the "pause" in the warming trend between 1998 and 2012. Nature devoted an entire issue to it.[2]

But then I start reading that the pause never happened.[3]

And if you read the wikipedia page, it sounds like there is still a lot of controversy within the climate change community whether or not global warming actually paused.

I'm not a climate scientist, so maybe I'm missing something (happy to be educated), but shouldn't we be able to tell pretty definitively whether or not the planet had been warming over that decade? Isn't there a standard way to measure global temperatures? It seems like it would be difficult to spot trends if _how_ you're measuring it is changing over time.

I read about how "if you interpolate arctic temperatures" or "account for ocean temperatures" the "pause" disappears. But how do we know the new analysis is right and the old one was wrong? What's if it's the opposite?

[1][https://en.wikipedia.org/wiki/Global_warming_hiatus](https://en.wikipedia.org/wiki/Global_warming_hiatus) [2][https://www.nature.com/collections/sthnxgntvp](https://www.nature.com/collections/sthnxgntvp) [3][https://insideclimatenews.org/news/18122018/global- warming-h...](https://insideclimatenews.org/news/18122018/global-warming- hiatus-pause-never-happened-studies-explain-climate-change-risbey-oreskes- mann)

<comment><USER22> I would think us engineers would appreciate the complexity of accurately measuring total net energy absorbed by a whole damn planet. It's not just raw temperature readings from buoys. Incremental improvement of models and some debate to sort out the reasons for temporary inconsistencies is to be expected in science.

None of this is really any excuse to be doubting climate change in general, or the severity thereof. All of _that_ is just politics, not science. Scientists know that our models are just as likely to underestimate the effects of climate change as they are to overestimate them. It is only politically motivated opinionistas that focus exclusively on one of those possibilities.

<comment><USER21> I had a career in science so I completely understand how models that predict the future are refined over time, that isn't concerning at all. Saying "we predict temperatures will rise between 0.5C and 2.0C this century" is just smart science.

But my comment isn't around a future prediction, this is measuring _the temperature right now_. You mention "the complexity of accurately measuring total net energy absorbed by a whole damn planet", which I can understand is complex, but ignore "net energy absorption" for now, let's just focus on "what was the average temperature last year". Would I be correct saying we're still not sure how best to get that data?

<comment><USER23> The best way to get the data would be to measure how much energy the planet absorbs vs how much it emits. The earth just wants to be in equilibrium so if these amounts aren't equal the climate is changing and the difference can tell you to what degree (excuse the pun).

The problem is that the earth transfers energy between many of its systems (think Ocean conveyor belt) and it's incredibly difficult to keep track of the energy. So any measurements of the earth directly that don't measure all the systems are likely to be inaccurate.

Edit: yes there is a global average surface temperature but due to the reasons above it's not a great indicator.

</comment></comment></comment></comment></comment></comment><comment><USER24> Original paper _Dynamic ice loss from the Greenland Ice Sheet driven by sustained glacier retreat_ [1]

> We show that widespread retreat between 2000 and 2005 resulted in a step- > increase in discharge and a switch to a new dynamic state of sustained mass > loss that would persist even under a decline in surface melt.

[1] [https://www.nature.com/articles/s43247-020-0001-2](https://www.nature.com/articles/s43247-020-0001-2)

</comment><comment><USER25> HEADLINE: "Greenland ice has shrunk beyond return..."

FIRST LINE OF ARTICLE: "Greenland's ice sheet MAY have shrunk past the point of return..."

[my emphasis]

So f--king sick of clickbait headlines!

</comment><comment><USER26> What does "point of no return" mean in this title?

<comment><USER27> There's a Reuters article about this topic which states:

> Greenland's ice sheet may have shrunk past the point of return, with the ice > likely to melt away no matter how quickly the world reduces climate-warming > emissions, new research suggests.

<comment><USER28> The fact that we were just saying, as recently as 2016, that things hadn't become "catastrophic" yet, only to four years later make _yet another_ correction that vastly accelerates past existing predictive models is why climate change continues to be seen as debatable. We need to either admit that we _don 't know_ or start acting consistently like we _do know_.

Pushing out an article with a headline like, "Major-global-feature is past the point of return," is not exactly selling the idea of a carbon tax. And the only argument against the critics has been, "Well, it could get _even worse_!" You mean in 60 days, when we announce something like "China will be underwater by February 2022?" Investments to curb climate change start to look like snake oil when we're saying something can be fixed by it but then announcing 30 days later that it no longer can.

<comment><USER29> > The fact that we were just saying, as recently as 2016, that things hadn't > become "catastrophic" yet, only to four years later make yet another > correction that vastly accelerates past existing predictive models is why > climate change continues to be seen as debatable.

So they got the speed wrong, but it was still in the same direction.

Scientists have for years been worried about the state of the Greenland ice sheet, and have repeatedly said it's diminishing ever more quickly and that's not good.

It's not like they went 180 on this.

<comment><USER28> It's absurd I have to reply with this: _Climate change_ continues to be seen as _debatable_ because _climate change models_ keep being _corrected_ past the degree of correction most people understand _invalidates similar models_ in _other fields of science_.

So, using a pharmaceutical as an example: If Pfizer published findings that stated an HBP pill permanently reduced blood pressure by a specific amount after 60 days, then four years later came out and corrected that to _10 days_ , most people would be concerned that the extra _50 days_ of treatment carried significant risk of lowering blood pressure too far, and would ask whether Pfizer did enough to prevent such a significant risk of lowering blood pressure too far. And almost everyone would be more cautious about taking other Pfizer medications. Makes sense, right?

That's what people do with climate science models in the general public. When someone asserts confidence in a model one year then publishes a significant correction to that model the next, skepticism over the integrity of all of their models is reasonable. If they messed up so bad here, we need to know whether it's isolated in scope.

That said, the entire model was about _speed_. No one inferred a general direction of decline. They asserted high confidence in a model that, given additional data, completely changed. There is a rule of logic in data that as new records are added, each record becomes an increasingly smaller proportion of the overall dataset, and save for extreme anomalies, the expected rate of change for the model given each additional record declines on a curve. That is why random sampling of a population is used instead of the population. After a certain number of records, the relevance of any _N_ new records are insignificant to the output. If the addition of new data completely threw off their model, even as a time series, they're overfitting or underfitting, but either way, they are not going to be trusted as a source of reliable information.

What I'm saying is we need to _stop doing that_. If we talk about the models as just being marginally accurate, we're more likely to stem attempts to debate the entirety of climate science. Regardless of how smart or stupid you think those who debate climate change are, they do influence barriers to act.

<comment><USER29> > Makes sense, right?

No, because it's an entirely different scenario. It's not at all similar to making some blood pressure medication.

</comment></comment></comment></comment></comment></comment><comment><USER23> The way I see it climate change could be awful but it's never going to be catastrophic as long as we're alive. All we have to do is send up hella reflectors to block the sun and we can be cool again.

The real risk IMO is making the oceans acidic with all this co2. That has the potential to be really really catastrophic.

<comment><USER30> > All we have to do is send up hella reflectors to block the sun and we can be > cool again.

The amount of reflectors required would necessitate literally millions of conventional rocket launches. At 1 launch per day it comes out to thousands of years to accomplish a project like this- far too slow to effectively address climate change.

<comment><USER23> We don't need to block all of it or anywhere near. We have hundreds of years to do this, why wouldn't we make them in space?

If you read my comment you would realise I didn't say we could use it to address climate change but that climate change would never become catastrophic (read runaway greenhouse effect) because we could do it as a last resort.

</comment></comment></comment><comment><USER31> Given the record early and massive snowfall this year [1] the alarm can be reset - 5,5 gigaton fell on the 12th of august, 2,5 gigaton on the 11th and 4 gigaton on the 10th. Greenland is accumulating ice mass about a month earlier than normal.

Of course this is just as sensationalist as the Reuters article so take it with as much salt as you did when you read Reuters.

[1] [http://polarportal.dk/en/greenland/surface- conditions/](http://polarportal.dk/en/greenland/surface-conditions/)

</comment><comment><USER32> Greenland just had several days of record gains in ice in the middle of the melt season. 3 of the last 4 years were net gains in ice mass for Greenland. This is sensationalism. Climate shifts can absolutely occur in both directions.

To see latest Greenland ice charts:

[http://polarportal.dk/en/greenland/surface- conditions/](http://polarportal.dk/en/greenland/surface-conditions/)

</comment><comment><USER33> I feel like people saying 'who cares' haven't been looking. And also like affected places aren't crying loud enough. I was driving through Daytona earlier this year, and stopped just to see their coast. It was gone. The wooden steps leading down to the non-existent beach were half covered. That is, you couldn't even get to the bottom of the stairs. This is a beach people used to park on.

<comment><USER34> Coastal erosion is not the same thing as sea level rise.

Sea level rise can't account for that drastic of a change.

<comment><USER33> I feel like too many people report 'facts' without experience. I'm reporting experience without 'facts'. Maybe you're right, I just wanted to give a real life account from a low lying area.

<comment><USER35> Well that doesn't really help. If the reason is coastal erosion and not sea level rise, then you're not saying something that's relevant to the point.

<comment><USER33> I don't mean to be anti-science, I'm just reporting what I saw with my own eyes. And it wasn't just Daytona. I saw a fisherman in Indian River County standing on what had to be 2 foot of beach. Erosion happens, but why is the water so high to even erode it?

<comment><USER36> Water doesn't have to be high to erode the shore. It'll slowly sink into the water as the lower ground is washed away, regardless of whether the water level is rising.

</comment></comment></comment></comment></comment></comment><comment><USER37> The irony that maybe our ancestors escaped Mars eons ago after similarly destroying the planet to seed earth and start afresh. Untrue but plausible based on how we've handled things this far. Self-interest and the tragedy of the commons.

</comment><comment><USER38> So, what is there left to do?

<comment><USER39> There have been calls to put sulfur dioxide into the air above the artic to reduce sunlight about 2% and limit the amount of energy that reaches it. Sounds like we'll need to do something like that if we don't want to turn places like Florida and southern Vietnam into ocean

<comment><USER40> Yes, there's exactly 0% chance that this ends badly. I don't know why the lady swallowed the dog to chase the cat to catch the bird to eat the spider...

<comment><USER39> I'm not saying it's a good idea, just that it's a proposed solution. We'll need to do something rather drastic if we want to have any chance of saving the world as it is today

</comment></comment></comment></comment><comment><USER41> ...Until it freezes again

</comment><comment><USER42> So it's over, the planet will likely be rendered uninhabitable probably within the next century. Is there any point in even having a new child now?

<comment><USER43> >So it's over, the planet will likely be rendered uninhabitable probably within the next century.

I'm not sure how you come to that conclusion but the planet won't be uninhabitable. Certain areas will be uninhabitable and there will probably be massive displacement of people paired with food shortages. But complete resignation is not only unhelpful but also unwarranted.

<comment><USER44> "Massive displacement" is a tepid euphemism in sight of current politics around human migration, which will only get worse as resources become scarce. Should Canadians be as cruel as Americans have been to their southern neighbors. Hope ya like toilet water, eh.

<comment><USER45> It's a tepid phrase because the effect just won't be as big as you're thinking. Nobody in the United States is going to need to escape to Canada - the primary displacement problem is that the specific places which support effective agriculture will change.

<comment><USER44> There's also the matter of heat waves; summers are increasingly lethal and we've barely started.</comment></comment></comment></comment></comment>


Fannie Mae Logic Bomb Would Have Caused Weeklong Shutdown - <AUTHOR> http://blog.wired.com/27bstroke6/2009/01/fannie.html

<comment><USER2> I'm curious if Wired's account is to be taken as the literal truth (I know, bear with me). Why is someone being fired for a single scripting error? What the hell is QA for?

More-over how stupid does Fanny Mae management be to fire someone who can write and deploy logic bomb that meticulous in half a day? Let alone let any of their staff have that level of data center access.

I'm sure we aren't seeing the full picture here.

<comment><USER3> "More-over how stupid does Fanny Mae management be to fire someone who can write and deploy logic bomb that meticulous in half a day? Let alone let any of their staff have that level of data center access."

Among their lack of oversight problems, this seems to be one of the smallest.

<comment><USER2> Or management oversights is symptomatic of Fanny Mae generally.

</comment></comment></comment><comment><USER4> In a bit of a shadow of Office Space, the alleged bomb planter's employer was named OmniTech.

<comment><USER5> I wonder if the reporter meant OmniTI, <http://omniti.com/>.

</comment></comment><comment><USER6> This is why when an investment bank fires a trader, the security guard is there to pick him up after the meeting with his boss ends.

They mail you the stuff from your desk in boxes.

</comment><comment><USER7> You know, the really nasty attackers aren't going to waste time overwriting data with _zeroes_.

</comment><comment><USER8> _"Despite Makwana's termination, Makwana's computer access was not immediately terminated"_

Wow.

<comment><USER9> I don't find it that surprising... usually you'd hire people you can trust in the first place. And the guy might want to pick up his stray files before leaving. It sounds harsh to me to cut off everything before even talking to the guy.

</comment></comment><comment><USER10> This shows how fragile large systems really are.

<comment><USER11> If a grumpy Google engineer managed to cause their Chubby service (synchronized file write service) to start corrupting random files, then that might have a big impact on the integrity of end-user data.

My point is, even a well-designed system is vulnerable when someone has access to its internals. Give me a system and a day, and I could probably think of a few subtle (or not-so-subtle) ways to break it for the purpose of inflicting damage.

<comment><USER12> And as long as you don't rely on security-by-pageful-of-blank-lines, you just may get away with it too!

<comment><USER11> I looked in the indictment for any details about the code he posted. No such luck; on a tangent, this is confusing.

From the article:

 _"A logic bomb ... would have decimated all 4,000 servers at the company, causing millions of dollars in damage"_

From the indictment:

 _"The defendant ... did knowingly cause and attempt to cause ... damage without authorization to a protected computer, and by such conduct caused and would, if completed, have caused loss to Fannie Mae during any one year period aggregating at least $5,000 in value."_

So...

1) Why are they charging him with "attempting to cause at least $5,000 in damage" when the true damage would allegedly have been in the millions?

2) It's hard to believe "[the code] would have decimated all 4,000 servers at the company". Let's consider the worst case scenario, which is that all 4,000 computers run the infected script at 9AM with administrator privileges. Would something like 'rm -rf /' really _decimate_ the server? If they kept backups of each server, could the IT guys simply swap in old backups?

... Now that I've talked it out, it seems likely that really _would_ knock the server farm offline for about a week. It would be difficult to swap in backups of 4,000 servers in a timely fashion. That's a lot of boxen.

<comment><USER13> Check out the FBI affidavit at <http://blog.wired.com/27bstroke6/files/fannie_complaint.pdf>.

The accused seems to have done the following \- SSHed in with his user id and gained root access to a dev server. The DHCP address for the client IP was last assigned to his laptop

\- Created a cron job that ran a script. The script checked whether it was January 31st, 2009. If so, it did the following

       - Disable internal monitoring systems to disable alerts
       - Create a list of all servers,walk through them and disable logisn and clear out logs
       - Wipe out data by overwriting with zeros
       - Uninstall software and turn off the machines
       - Clear itself out and zero out the root filesystem

The 'smoking gun' seems tenuous at best- the person accused seems to use similar naming conventions for his personal temp files (the .x, .y format) which I agree is unconventional. I think the real smoking gun is the fact that his laptop and his login was used

<comment><USER11> I wish I could give you 20 karma for that. Nice sleuthing!

Do you think his attack would have worked?</comment></comment></comment></comment></comment></comment>


Brief encounters and romps in the park: George Orwell and women - <AUTHOR> https://thecritic.co.uk/issues/march-2020/brief-encounters-and-romps-in-the-park/ <comment><USER2> Oh, for FFS. Can we please stop with the SJW stories.</comment>


Fitness Apps Suck - <AUTHOR> https://medium.com/p/4dfd99a584d1

<comment><USER2> Or if you're suddenly going from your walking pace to 20-30-65-75MPH, you probably aren't the fastest human on the planet. You got on a bus and forgot to turn the darn thing off when you reached your bus stop. Just like most of the tracking apps have an "auto-pause" feature for when it looks as if you're taking a breather, they should have a settable max point where it will break the activity into a separate segment when you're clearly going faster than you can make yourself go.

Also, skip the UI sugar for the main purpose - TRACKING - of your app. If I want a map, I'd click over to the mapping application to see where I am. It should start quickly and start recording quickly, possibly notifying me that while it can trivially determine my location from the wealth of Wi-Fi signals permeating the campus, it's going to throw up a modal d-box and demand a click from me b/c the GPS doesn't get an immediate fix when they turn it on until you've made three taps into the program.</comment>


Ask HN: Has any small dev team successfully deployed a complex app with docker? - <AUTHOR> I've been pondering the implications of using Docker / Kubernetes to deploy a fairly complex application to production. We are a small team of a few developers, and although I personally deal with deployment using scripts, I'm by no means a devops expert or sysadmin.
Whenever I look into Kubernetes and everything that goes with it (maintenance, monitoring, logging, etc), I feel like it requires a full-time devops engineer to create and manage all of it. Our team will soon undergo a major rewrite of our application and the decision should be made to use Docker or continue using deployment scripts with ansible.
Have any devs here successfully learned docker and kubernetes, deployed it in production, and not regretted the decision later? What benefits did you obtain? Any tips about it for a dev? <comment><USER2> like another commenter said, start small. if your application(s) follow the twelve-factor app methodology[1], containerizing them should not be challenging. that is the first step.

we are in the middle of a somewhat long rollout of Kubernetes by one engineer (me). by far the most time has been spent on making our applications work as twelve-factor applications, but a lot of that work happened before I even touched a Dockerfile.

we're at the point that our development team is currently using Kubernetes locally as their development environment (but not yet in production). while at times I have had moments of self doubt and questioned our decision and approach, there have been many moments where the benefits have been made clear as day. the engineers are happy with the flexibility and consistency that Docker containers have brought to development, but it has come with more operational complexity.

ultimately, you need to decide what your target scale is for your engineering organization in 3, 6, 12, 24 months.. we are in the beginning stages of a rapid growth phase for our engineering team, and developing complicated cross- cutting concerns for our products was becoming cost-prohibitive simply because our development environment was too complicated to setup, maintain and debug. containerizing it temporarily relieved that pain and bought us time to then focus on scaling up those changes to production when appropriate.

[1]: [https://12factor.net/](https://12factor.net/)

</comment><comment><USER3> > I feel like it requires a full-time devops engineer to create and manage all > of it.

It does.

Kubernetes is a great piece of tech but it is pretty complicated and does add a fair amount of overhead on top of whatever operational concerns you application already has. If you don't have anyone that knows how to build and manage a cluster going to production with it would be extremely risky IMO.

I would recommend trying GKE, Google's managed k8s service, in staging/dev before even considering it as a serious path forward. If you are married to AWS or just don't want to use GCP then kops would be your best bet. I have friends working with EKS, AWS' managed k8s service, and it doesn't sound anywhere near as ready as GKE or as flexible as doing it yourself, frankly it sounds like a real pain. I haven't used k8s on Azure but I have heard that it's pretty good.

I also don't generally recommend deploying a new application as decomposed services either. Unless you have done this a bunch of time it will probably save you a bunch of time to just do it as a monolith and deploy it to standard cloud VM's or on-prem servers. Also be aware that Docker and by extension k8s are not the best way to run stateful applications. It can be done but it is definitely more work to get a k8s based DB working the same way as a non-k8s DB in terms of data retention. I imagine a complex application will need some kind of data store so even if you go with k8s you may still end up with non-k8s instances for you data.

k8s is great but it's overhead con easily outweigh it's benefits if you don't have a someone who can manage it. Start simple if you can and work from there.

</comment><comment><USER4> > I've been pondering the implications of using Docker / Kubernetes to deploy > a fairly complex application to production.

These systems are managed by dedicated _teams_ most of the times. Kubernetes has many moving parts and debugging issues can be a nightmare.

Using docker is the way of the future. Docker merges development/production environments, facilitates CI/CD, simplifies deployments/rollbacks/etc., it even enforces _best practices_ by separating layers (persistent vs ephemeral), so on and so forth.

You could deploy your application through ansible docker module on EC2 instances, droplets or what-have-you.

So the more subtle question is _why do you need an orchestrator?_

Container orchestrators solve the problem of _density_. Say, my stack is made of services running in 128MB of RAM. I want to scale them quickly in and out on-demand.

If you don't have a density problem, e.g. your application will need 2GB of RAM anyway, I would say go with docker & EC2 autoscaling. Much easier to handle, you won't have to debug weird network/logging issues and all the problems that orchestrators bring along.

If you choose to go with an orchestrator, then for a small team, I would advice to take a look to Docker Swarm. Swarm comes with service discovery, load balancing, secrets & config-handling build-in. That's a big win for smaller teams. The learning curve is rather small, if you're already using docker. What you will have to handle if you go with swarm is:

        - Cluster initialisation (if you chose to automate this part, you might not, but you'd better automate the rest)
        - Node-level autoscaling
        - Container auto-scaling
        - Dynamic routing (traefik or nginx + confd will solve this for you)
        - Security (same goes for k8s or any other orchestrator, security requires eye for detail & experience)

There are other minor issues (e.g. Swarm internal load balancer won't forward the real IP of the request to the internal service, which can be a PITA in some cases. There are workarounds mind you), but all orchestrators have minor issues and limitations.

Another word of caution about orchestrators: Most teams, don't need orchestration and don't have use cases that simpler setups cannot solve. Simple is smart, simple is genius. Keep it simple, until you can't keep _that_ simple anymore.

Oh, don't even think about adding a persistent layer inside the orchestrator! If a service uses a Redis for caching for example, could be deployed as a _stack_ in a swarm cluster. If you need persistence that goes beyond the lifecycle of the container, keep them out :-)

Good luck!

</comment><comment><USER5> start small, dont prematurely optimize</comment>


A Bed for Fifty People? - <AUTHOR> http://www.theparisreview.org/blog/2016/11/15/bed-fifty-people/ <comment><USER2> The discussion thread here strikes me as confused because people are looking at an era several centuries back and using current norms (both economic and cultural) to analyze it.

Beds used to be luxuries and having just 1 person per bed was very rare.

As late as Colonial America inns would put multiple people per bed. Heck, this persisted into the 19th century! Lincoln, as I recall, shared a bed. Much hay is made of this buy revisionists who want to use this fact to argue that Lincoln may have been gay. (FWIW, I don't know and don't care). But the mistake they're making is obvious.

Imagine if in 2150 people look at old pictures of people driving in the same car and whisper to each other "ooh, kinky! ...and there's a dog in there too!"

<comment><USER3> Growing up, our family of 4 slept on a single bed in a tiny one bedroom apt. I got my own bed when I moved out at age of 18. I know I shouldn't be embarrassed about it but I almost never mention this to anyone, esp in America.

</comment></comment><comment><USER4> The character of Scrooge McDuck sleeps in a giant bed.[1] Not to share it with anyone, but because he slept in a drawer as a child.

I think this 50-person bed is much more likely to be a status furniture than a bed for multiple guests.

[1] [https://4.bp.blogspot.com/-0zLC0vqKlhw/U-j3euxqRuI/AAAAAAAAM...](https://4.bp.blogspot.com/-0zLC0vqKlhw/U-j3euxqRuI/AAAAAAAAMpM/8NcUXmm- _Fo/s1600/US+Giant+Bed.jpg)

<comment><USER5> Yes! The donald duck comics are the best. I remember checking anthologies of them out from the library as a kid.

</comment></comment><comment><USER6> I don't get why he didn't consider orgies ... this is definitely for orgies, right? The drunk thing is a cover.

<comment><USER7> Thats why _I_ have a King bed downstairs.

<comment><USER8> _Only_ a king? _Everyone_ knows that only the best orgies can be had in a super-king. You should upgrade.

<comment><USER9> As far as my research indicates there is no bed bigger than a standard king. A California king is longer but narrower.

<comment><USER10> I sleep in a super king. 6'x6'6". It's a standard size in the UK.

<comment><USER11> The European King is 2.0 meters wide by 2.0 meters long.

Do the math.

We had a Euro King until we recently had to replace it. Buying sheets in Europe was no problem.

</comment></comment></comment></comment></comment></comment><comment><USER12> Assuming a group of people needs as much space as a single to sleep is a mistake. Feet to feet you can overlap. Further the average guest would probably have been shorter and thinner than we are used to.

I have seen six kids in a double with pillows at either end.

</comment><comment><USER13> A bed for fifty falling-down drunk people? If you are not asphyxiated by the morning (crushed by your neighbor or in the normal way), you can make a game of trying to identify the different varieties of puke that coat you like a varnish.

</comment><comment><USER14> Having shared a twin bed before, I can believe the accuracy of the 50 number.

<comment><USER15> Also, the uncomfortable part is falling off the side or being smushed into a wall. Being smushed into another person is more comfortable because people are soft and you have no danger of falling off.

<comment><USER16> Honestly, I was hoping the article was about a new trend for cooperative/group sleeping arrangements: people are soft/comfortable, sides/edges are not, so if you put more people on a bed, fewer need to deal with being on a side/edge.

<comment><USER17> Even better if you have a circular bed, no edges so long as it is at capacity.

</comment></comment></comment></comment><comment><USER18> BTW, "Da Vinci" was not Leonardo's surname. You may refer to him as either "Leonardo da Vinci", "Leonardo di ser Piero da Vinci" if there's a reason for the longer form or simply "Leonardo" when it is clear from context which Leonardo the author is referring to.

<comment><USER19> Thanks for reading! I thought it would be overly pedantic to diverge from the common usage of "da Vinci". However, I was overly pedantic in calling the Mona Lisa by its proper name, so I think it all evens out.

</comment></comment><comment><USER20> _I think de Beatis means the bed was about twenty-six feet by twenty feet, which is 503 square feet. A twin bed is about twenty square feet, so the bed could probably only fit twenty-five people comfortably. Durer was wrong!_

Oh, please. They said nothing about the fifty people being _comfortable._ Besides, you can absolutely fit 2 people into a twin bed. Plus, people were generally smaller a few hundred years ago than they are now. As I understand it, this is part of why older buildings so often have ceilings that are too low -- because we are generally taller than our ancestors were.

(And this is without even getting into how hand-wavy old measures were).

</comment><comment><USER21> > which is 503 square feet. A twin bed is about twenty square feet, so the bed > could probably only fit twenty-five people comfortably. Durer was wrong!

How so? Twin bed is for 2 people, so that makes about 50 people. Am I missing something?

<comment><USER22> The calculation of 25 people uses a twin mattress as a comfortable fit for one person, not two.

In the US, a twin mattress is the smallest adult size available, and is almost always seen as a one-person bed. I usually see queen-sized mattresses marketed as the average-size bed for two people, and full (one size up from twin) recommended as the comfortable choice for single sleepers.

[http://bettersleep.org/mattresses-and-more/mattress- sizes](http://bettersleep.org/mattresses-and-more/mattress-sizes) has a good overview of mattress size standards (at least for the US).

<comment><USER23> Twin bets aren't adult-sized, they're for kids. And full-size beds are basically obsolete, or just for short people. They're simply too short, given that people are taller now than they were 50 years ago. Queen size is now the minimum normal adult size bed in the US; that's why you see them marketed as the "average-size bed for two people".

If you're single and really want to save space, you can get "long twin" mattresses, which is exactly half the size of a king mattress, and also the size of the foundation used under a king mattress (x2). But most single people these days just get a queen size, because it's long enough for most people while providing plenty of space to spread out, but also gives you sufficient space in case someone spends the night with you... Limiting yourself to a (long) twin size makes it rather difficult to have a guest for the evening unless you're really thin, which Americans generally aren't these days.

</comment></comment></comment><comment><USER24> _However, European units of measurement before the metric system were a complete mess, the Italian units of measurement in particular._

Ironic how the author then gives the measurements in feet, after converting palmo to cm.

<comment><USER19> Thanks for reading! It is ironic, I agree.

</comment></comment><comment><USER25> I clicked into this expecting an invention for refugees.

<comment><USER26> Not too late to make your dream a reality.

</comment></comment><comment><USER27> Don't _lie_ down in that bed, people. Everyone knows that if you don't sleep in a sitting positions, your humours get shifted all out of whack. Don't these rich young Quincenntenials read their Galen anymore?</comment>