013a

Officials have been going on about how this is the fastest vaccine ever produced and distributed. Then they backpedal slightly on that when the populace verbalizes legitimate concern that it was too fast to guarantee safety. Meanwhile, people like myself (and I assume you) are on the opposite side; this was too slow.

This virus could have been much, much worse. Not to be insensitive, we (as a species) got off easy with the transmissibility of this virus and its mortality rate. Viruses such as the measles transmit so readily that a shedding individual breathing into a room will infect people who walk through that room up-to hours later (COVID-19's r-value is somewhere around 3; measles' is closer to 15). Viruses like the smallpox, thank god now thought to be eradicated, exhibit a mortality rate higher than 30% (versus COVID's ~0.5-3%). Viruses are genetically and physically capable of extraordinary destruction, and its impossible to predict when one will make that single mutation necessary to wipe out ten percent of the human population, just due to a genetic accident.

Moderna, at least, was able to develop this COVID vaccine in literally days; the rest was testing and regulation, which was certainly sped up comparative to the severity (or relative lack-there-of) of COVID. My fear is the next one. Let's say one day we get an actual super-virus which rampages through the population. More or less, we've got some amazing development platforms out there, production is difficult but solvable, but then we hit testing and regulation. Either the government stays the course with traditional testing, and tens of millions definitely die, or they expedite traditional testing even more than we did with COVID and hundreds of millions maybe die due to an unproven vaccine.

I'm not fooled for a second by the safety claims behind these COVID vaccines. To be clear: I will still get one the moment I'm able to. But I'm going in fully aware that these companies have little idea what this vaccine is going to do to the human body in four years, in N% of patients, or how it will react with the millions of different medications people take, in different combinations, or how some weird little genetic abnormality in 0.5% of the population may affect its efficacy. There's no new safety & testing processes which enabled them to productionize this vaccine in ten months; they're just forgoing long-term studies (and getting liability waivers in the process).

Its 2020; we launch rockets to outer space every day then recover and reuse them, half the population carries in their pocket a computer capable of accessing all the world's information instantly and performing trillions of calculations per second on it, and our best-in-class state-of-the-art method of testing vaccine interactions on the human body is still "hey, uh, do you wanna come in and we're going to inject you with this thing and you tell us if you get covid, ok? we'll pay you a hundred bucks."

I believe three things very strongly: (1) the medical research community should be proud of the incredible results they've achieved in vaccine research; the speed at which Moderna and others were able to produce the first iteration of this thing is right on the money, but (2) they should also be critically ashamed of the lack of progress we've made in being able to expedite testing despite the insane and incomprehensible technology every sector around them has provided to help. (3) Fixing this needs to be humanity's number 1 priority. This is life or death for our species. Our goal should be from viral sequencing to a reasonably safe production-ready vaccine in two weeks.

This is excellent; hopefully we get native Rust support on Lambda soon maybe? :)

Yes; and from what I've seen in Apple's support documentation, you can install linux on the new M1 machines.

I think the broader point is that the support isn't very good. Its not specifically disallowed by Apple or Microsoft, but the manufacturers, tertiary driver providers, and community just haven't put a lot of time into making it great. I expect the situation will improve, but its unlikely we'll see any support from Apple or Microsoft, which absolutely should be a concern when picking these devices for Linux.

Just now? When you search for Firefox or Chrome on Bing (the default search engine on Edge), the first result in large font and contrasting background is "Microsoft Recommends You Keep Using This Browser" (referring to Edge). When you visit the Settings to change your default browser to something else, Edge has the line "Recommended for Windows 10" below it in bright letters, and switching it to anything but Edge pops open a confirmation window that reads "Before You Switch: Try Microsoft Edge" with the primary action being to do that, and the actual switch option below it in small gray lettering. OS updates spontaneously reset your default browser back to Edge, and every once in a while the OS will decide to send you a notification helpfully reminding you that Edge just got an update (it didn't) and you should check it out.

This is unrelated to Edge, but among the most despicable things I've seen Microsoft do was to promote their "Your Phone" app by popping up a notification that reads "You Got A Message". I didn't just get a message, and there's no way they could know that because I hadn't even installed their crap on my phone! Its like they're just pretending its all connected and displaying message notifications on your PC to get people to click it, then go through the setup.

Microsoft is a big company, with many divisions that are doing really great work. Their Windows division is so unimaginably the opposite of this, and has been for near a decade, that I'm beginning to think their push toward services and the cloud is only to hedge against this division, like leadership knows left to their own devices they'll crash into the ground and take Microsoft with them and no one can stop it.

I think there's an angle to the plausible deniability that many people are missing.

Email servers get hacked all the time, right? A disgusting amount. Its almost like security is really difficult; in fact, its difficult to secure both the emails and the DKIM private keys. They're usually on the same server, after all.

If a DKIM private key gets hacked, and the world relies on DKIM to provide non-repudiation in the verification of email leaks, then a hacker who obtains someone's DKIM private key could forge an email to contain any content they want, sign it with that private key, then leak that. The world says "its DKIM validated, Trump really did kill a litter of puppies twelve years ago", Trump tries to say "no, my email server was hacked, i never did that but they got my DKIM key" and who the hell would believe him? The headlines have already been written, and the argument against it is some crazy technical terminology a hundredth a percent of the population actually understands?

Ok, well, maybe you should rotate DKIM keys. Not necessarily make the private portion public, but at least rotate them and totally destroy the old private keys. But, again, if an email server is misconfigured enough to leak data, then its likely the admin is incompetent enough to also not be rotating keys. Moreover, unauthorized access to a server could happen over a period of years, during which hackers collect the rotated DKIM private keys while letting the admins think they're being deleted correctly.

The problem here isn't really DKIM; its the public's perception of what it was designed for. Technologists invented something, journalists discovered it, read a wikipedia article, and thought "woah we could use X for Y". So, I think it makes sense that we need a big name like Google to come out and say "Stop, this is not what this was designed for, it has major limitations in being used for that, and we're talking about real-world consequences like ruining potentially innocent peoples' lives."

> As a follow up, several people point out that it could happen to me or a family member, but this seems even further reason to have DKIM so that if someone attempts to blackmail me based on the contents of my email, checking the DKIM signature makes it even easier to disprove a bad blackmail attempt.

I think his point is that the DKIM signatures could be used to verify that you did, in fact, send something worth being blackmailed over, rather than having the plausable deniability of saying that your DKIM private key from that period is already public and thus could be forged.

Which, to me, sounds similar to the classic XKCD "Theoretically, I use 2048bit RSA encryption and the hackers can't get my data. In Reality, they just beat me with a hammer until I give up the password." Maybe a public DKIM argument would hold up in court, but if we're just talking reputation blackmail among family and friends, it aint it chief.

Impossible to know until we get the hard numbers.

But, just looking at A14 performance and extrapolating its big/little 2/4 cores to M1's 4/4; In the shortest tldr possible; Yes.

M1 should have stronger single-core CPU performance than any Mac Apple currently sells, including the Mac Pro. I think Apple's statement that they've produced the "world's fastest CPU core" is overall a valid statement to make, just from the info we independent third-parties have, but only because AMD Zen 3 is so new. Essentially no third parties have Zen 3, Apple probably doesn't for comparison, but just going on the information we know about Zen 3 and M1, its very likely that Zen 3 will trade blows in single core perf with the Firestorm cores in A14/M1. Likely very workload dependent, and it'll be difficult to say who is faster; they're both real marvels of technology.

Multicore is harder to make any definitive conclusions about.

The real issue in comparison before we get M1 samples is that its a big/little 4/4. If we agree that Firestorm is god-powerful, then can say pretty accurately say that its faster than any other four-core CPU (there are no four-core Zen 3 CPUs yet). There's other tertiary factors of course, but I think its safe enough; so that covers the Intel MBP13. Apple has never had an issue cannibalizing their own sales, so I don't think they really care if Intel MBP13 sales drop.

But, the Intel MBP16 runs 6 & 8 core processors, and trying to theorycraft what performance the Icestorm cores in M1 will contribute gets difficult. My gut says that M1 w/ active cooling will outperform the six core i7 in every way, but will trade blows with the eight core i9. A major part of this is that the MBP16 still runs on 9th gen Intel chips. Another part is that cooling the i7/i9 has always been problematic, and those things hit a thermal limit under sustained load (then again, maybe the M1 will as well even with the fan, we'll see).

But, also to be clear: Apple is not putting the M1 in the MBP16. Most likely, they'll be revving it similar to how they do A14/A14x; think M1/M1x. This will probably come with more cores and a more powerful GPU, not to mention more memory, so I think the M1 and i9 comparisons, while interesting, are purely academic. They've got the thermal envelope to put more Firestorm cores inside this hypothetical M1x, and in that scenario, Intel has nothing that compares.

M1 has 16MB of L2 cache; 12MB dedicated to the HP cores and 4MB dedicated to the LP cores.

Another important consideration is the on-SOC DRAM. This is really incomparable to anything else on the market, x86 or ARM, so its hard to say how this will impact performance, but it may help alleviate the need for a larger cache.

I think its pretty clear that Apple has something special here when we're quibbling about the cache and power draw per core differences of a 10 watt chip versus a 100 watt one; its missing the bigger picture that Apple did this at 10 watts. They're so far beyond their own class, and the next two above it, that we're frantically trying to explain it as anything except alien technology by drawing comparisons to chips which require power supplies the size of sixteen iPhones. Even if they were just short of mobile i9 performance (they're not), this would still be a massive feat of engineering worthy of an upgrade.

My guess is that they'd still keep the efficiency cores around, but provide more performance cores. So likely a 12 or 16 core processor, with 4 or 6 of those dedicated to efficiency cores.

The M1 supposedly has a 10w TDP (at least in the MBA; it may be speced higher in the MBP13). If that's the case, there's a ton of power envelope headroom to scale to more cores, given the i9 9980HK in the current MBP16 is speced at 45 watts.

I'm very scared of this architecture once it gets up to Mac Pro levels of power envelope. If it doesn't scale, then it doesn't scale, but assuming it does this is so far beyond Xeon/Zen 3 performance it'd be unfair to even compare them.

This is the effect of focusing first on efficiency, not raw power. Intel and AMD never did this; its why they lost horribly in mobile. Their bread and butter is desktops and servers, where it doesn't matter. But, long term, it does; higher efficiency means you can pack more transistors into the same die without melting them. And its far easier to scale a 10 watt chip up to use 50 watts than it is to do the opposite.

If you believe that, then you've either been accidentally ignoring Apple's chip R&D over the past three years, or intentionally spinning it against them out of some more general dislike of the company.

The most powerful Macbook Pro, with a Core i9-9980HK, posts a Geekbench 5 of 1096/6869. The A12z in the iPad Pro posts a 1120/4648. This is a relatively fair comparison because both of these chips were released in ~2018-2019; Apple was winning in single-core performance at least a year ago, at a lower TDP, with no fan.

The A14, released this year, posts a 1584/4181 @ 6 watts. This is, frankly, incomprehensible. The most powerful single core mark ever submitted to Geekbench is the brand-spanking-new Ryzen 9 5950X; a 1627/15427 @ 105 watts & $800. Apple is close to matching the best AMD has, on a DESKTOP, at 5% the power draw, and with passive cooling.

We need to wait for M1 benchmarks, but this is an architecture that the PC market needs to be scared of. There is no evidence that they aren't capable of scaling multicore performance when provided a higher power envelope, especially given how freakin low the A14's TDP is already. What of the power envelope of the 16" Macbook Pro? If they can put 8 cores in the MBA, will they do 16 in the MBP16? God forbid, 24? Zen 3 is the only other architecture that approaches A14 performance, and it demands 10x the power to do it.

That's not what they said during the keynote.

They said the Macbook Air (specifically) is "3x faster than the best selling PC laptop in its class" and that its "faster than 98% of PC laptops sold in the last year".

There was no "in its class" designation on the 98% figure. If they're taken at their word, its among every PC laptop sold in the past year, period.

Frankly, given what we saw today, and the leaked A14x benchmarks a few days ago (which may be this M1 chip or a different, lower power chip for the upcoming iPad Pro, either way); there is almost no chance that the 16" MBPs still being sold with Intel chips will be able to match the 13". They probably could have released a 16" model today with the M1 and it would still be an upgrade. But, they're probably holding back and waiting for a better graphics solution in an upcoming M1x-like chip.

The other option is: Pick any of the above licenses and don't tie your entire financial identity to this thing.

I think its a legitimately weird thing specific to software where people release something interesting as open source and free, it gets used, they feel an obligation to make building it their job, and then they feel anger when they don't make money from it. I understand the feeling of being slighted when there are billion dollar corporations using your software, but it was also a situation you opted in-to in the first place, with no expectation of reciprocity until now.

I support the idea of asking people to pay for your time. That's totally fair. I think its also a little icky to say "pay me six figures or fork it"; so, is there no intention to actually make this an open source project? One where people contribute code instead of money and its supported by its users in that way? This project has over 100 contributors.

I think any timebox-based batching strategy would effectively just trade frontend performance for backend performance. Your backend would have to deal with fewer requests, and there's always a number of "things" the backend needs to do with every request regardless of the content (e.g. check a token against a database), so fewer requests is nice. But, some components would have to wait up-to X milliseconds to get their data, and if we're talking about a network request that takes 100ms, balancing the value of X to be big enough to actually have an impact, while being small enough to not double the time it takes for some components to get data, would prove very difficult.

The backend performance you could gain is kinda spurious anyway. We're talking about N requests being coalesced into 1 mega-request; I would rather clients send me N small requests, not 1 mega-request. Horizontal scaling is easy to set up and quick to do in real-time; vertical scaling is harder.

And I think, while a solution like this is interesting in the domain of "you've got two sibling components rendered at the same time who's queries could be combined", that's not exactly the issue I described a few comments up. Caching really doesn't enter into play here; it would not be measurably faster to just issue one mega-request for one component and let the other wait for the cache (which is, in the end, what we're talking about). I mean, it saves one network request, but 90% of a network request is just waiting on IO, and if there's one thing Javascript is really good at, its sitting around and waiting. It can wait for dozens of things at a time.

The issue is more specifically surrounding two components being rendered at different times. Imagine a User Preview card which displays a user's first name; the user clicks on that card, which takes them to a new page, the User Profile, which displays both their first and last name. Short of using a God Query for the Preview which covers a broad set of common user fields, like firing a shotgun and hoping you've got the cache saturated for unknown upcoming components, this situation will take two requests. The shotgun approach is what we do, and what many companies do; it works, but its imprecise. It can hurt the performance of the leading components which pulled the short stick, if that God Query gets too big, and as an application evolves you're gonna forget to keep that God Query updated with new things you may need.

This problem is enticing because it feels like there should be a solution, and we just haven't, as a community, found it. I think GraphQL, at its core, has the capability to solve this; its not like REST which is so undefined and hazy that any solution to something super-complex like this would only work in the domain of one company's "way of doing things". I hope one day we can figure it out, because I suspect that a general, easy to use way of preemptively saturating a cache like this would be a MASSIVE performance boost to every GraphQL client that's ever been written.

No, its still an issue. If you have QueryA which requests User { firstName } and QueryB which requests User { lastName }, those queries both have to request their data in order for both fields to be cached.

If, instead, you have QueryC which does User { firstName, lastName }, but two usages of it (QueryC1/QueryC2), after QueryC1 requests, QueryC2 can use the cached results. This works whether you're doing Query/Operation level caching or Field/ID level caching. The former example works in neither. And QueryC is trivially faster than QueryA+QueryB because of network overhead.

This isn't necessarily an issue with GraphQL (and, I thought I was clear about this, but: I'm not against GraphQL). Its a behavior of both typical REST implementations and GraphQL. And, to be clear, GraphQL's out-of-box caching story is more powerful than any REST implementation I've seen short of hyper-engineered FAANG companies, because it enables really powerful field/ID level caching across multiple queries. But it doesn't work in this case.

The point is that its still very immature. Even the thought leaders (Apollo being the biggest one and worst offender) write these blog posts filled with Best Practices and Recommendations that often convey horrible advice and flat-out misrepresent GraphQL's actual advantages compared to REST. GraphQL solves a lot of REST's problems; it does NOT solve REST's "god-object" class of problems, like the grandparent comment suggests; and it introduces many new classes of problems that remain unsolved in the ecosystem because of how immature it is (one great example is OSI L7 inspection in many tertiary tools a typical SaaS app has. Many products like Datadog, CloudFront, AWS ALB, etc are capable of doing some really cool and powerful stuff out-of-the-box just by inspecting standard HTTP headers. REST is basically just standard HTTP; your resource is in the path, query parameters, http headers, its very standard. GraphQL is not, so many of these tools don't work out-of-box with GraphQL. People are catching up, but again, its immature).

We have a `user` GraphQL type. It has 200+ fields and resolvers into other data. Fortunately, clients don't need to pull everything.

Well, within one of our frontend apps, someone wrote a "GetUser" query fragment, wrapped it in a react hook to make it easy to use, and now anytime anyone anywhere wants to get a user, even with one field, they're getting 100+ fields they don't want. Anytime someone needs a new field on a user, they don't create a new query; they just add the field to that "GetUser" query.

Now, I've told several GraphQL advocates that setup (in our local community and online), and unfailingly they balk at it. Well, you're doing GraphQL wrong, everyone makes mistakes, you should be more selective, etc etc etc. I think that's fair; being more specific sounds like a good pattern.

Except, we are not certain the performance wouldn't suffer should we move everything to more selective queries. The issue is caching. If you have ten queries each requesting one field, the cache can't saturate until after ten network requests. But, one mega query, and now the remaining nine queries can just pull from the cache. Sure, the mega query takes longer than one mini-query, but its not longer than ten mini-queries.

I only outline this to say: GraphQL is not a magic bullet. Every single thing you can do which would ruin a REST API is also possible in GraphQL. REST API responses naturally evolve into god objects. GraphQL APIs solve the god object issue server-side by saying "god objects are fine", then push the responsibility of not abusing it onto the client (and it should be obvious, the client is the worst place to solve almost every problem, but that's another topic).

GraphQL is easier and better for some things, far harder for other things. At the end of the day, its no worse than REST. I don't recommend it, but that's only just because its new; unless a new technology offers some very easy to express, tactile benefits for your business, just wait for it to mature. When you get down to it, GraphQL's benefits are definitely not tactile, but they're still there, and I think over time it will evolve into something very interesting.

Right, and that's my biggest fear.

The process side of this industry is in a really scary spot right now. TSMC is killing it. Nvidia is using Samsung to fab the RTX 3xxx chips, and there's some rumblings that low yields are a reason why those are in such short supply (not to mention, whenever Samsung releases a new phone only some regions get the Exynos chips, because historically they couldn't produce enough of them; Samsung used to have a pretty cool relationship with Qualcomm whereby Snapdragons were fabbed with Samsung, but more recently, they've moved to TSMC).

On the high performance side, everyone is moving to TSMC. If Samsung and Intel's fabs continue to exhibit issues at these smaller process node sizes, the monoculture is only going to get worse. We need Intel to get their act together, not just because it pushes better design innovation from AMD and Nvidia (not that they need it right now), but because their fabs are a critical, independent part of the software supply chain. They're the last western company with any form of high yield fabrication on high performance chips. At this point, we shouldn't just be worried about Intel's bottom line; we need to start being legitimately worried about national security (both in tactile cyber-warfare terms, and also more nebulous economic terms with regard to western manufacturing).

You may be underestimating the size and scope of some of the big WhatsApp channels. Beyond a certain point they really look like a traditional social network, and not an isolated group of people sharing something in common.

As an example; the official Valorant Discord server has 200,000 people online right now. Not total; online, actively receiving messages. Some of these private WhatsApps, Discords, etc have tens of thousands of active members, and the content shared goes far, far beyond whatever the title of the channel indicates. The companies behind these isolated social network islands may do some light moderation on the overall server/channel, like not allowing terrorist groups to communicate, but very very rarely do they moderate any deeper; that's left up to the owners of the channel/server, and if they're complicit, it'll never be cleaned up.

Of course, WhatsApp, Discord, Telegram, etc, they don't do discovery. They just let third parties handle that [1]. They get a ton of plausible deniability, which is even further empowered by the push for E2EE.

[1] https://top.gg/servers/list/top

Github Actions really is a freakin awesome product. Yeah, there's lock-in, but their free plan (and cheap Pro plan for individuals) offers a great value. And, really, CI is CI; if you ever need to migrate, even for this guy with hundreds of projects it should only take a couple days. Once you've seen one CI yaml file, you get the gist of what all of them do.

Other options:

* Gitlab CI. Good value, great integration with Gitlab, has integration with Github.

* CircleCI. Something of a gold standard in CIaaS among growing companies. But, it goes down a lot, and the new UI isn't an improvement. But, it works and its a good value. Word of advice, I'd avoid using their "Orbs" if I were you. You can accumulate a lot of lock-in with those, and they're infamous for stability issues. Instead, use their docker builder and just build a base docker image with all the stuff you need installed.

* Buildkite. Really cool product; they handle the control plane and the UI and webhooks, you host the runners. Its a simple binary or docker image you can install anywhere. If you're looking for something with low lock-in that's still easy to manage, Buildkite is a great option. I'll warn you though: if you're going to do any kind of cloud hosting for your runners, and you want to build docker images, best to avoid their dockerized runners. Just install natively on a linux box, either manually, with an AMI, etc. Docker-in-Docker sucks; not impossible to get working, but not worth your time.

* Jenkins/JenkinsX. If you want something with zero lockin but also hard to manage.

* AWS CodeBuild/CodePipeline/CodeDeploy. There is, like, no one I feel comfortable recommending these options to, but people still use them because they're AWS.

What high watermark? Was that when MongoDB switched their licensing on v4.0 to force all hosted service providers to open source their entire software stack if they wanted to host it, a requirement they themselves are exempt from with Atlas? Was it in 2017 when Docker locked important pieces of the Docker ecosystem behind the closed-source Enterprise Edition?

Its risky to mistake a golden age of open source with "these companies just had infinite VC funding for a while, before realizing they need a sustainable business". So they try to strike a balance, which makes everyone unhappy because the open source advocates say they're turning back on their promise to the community, while enterprise advocates say they're too focused on hyperscale and not enough on solving actual enterprise problems. Some have survived, some are still in the VC honeymoon phase, many died (RethinkDB, CoreOS, etc).

These companies, and the products they made/make, do not represent a high watermark of open source because generally speaking their products die with them. There's no community to sustain it when the corporate sponsors disappear. And here's the funny thing: If there were a community, if you built a product so awesome that people love it and develop for it and use it by the millions, you're now Docker. The open source gets you to where you are, and now you just handed all of your competitors not just market validation, but the literal specification on what to build. And what it takes to protect from that would make you MongoDB; kinda open source, definitely not FOSS, lots of closed source components, enterprise, no community. Neither of these are model high water mark open source companies, because one is bad open source, and the other is a bad company (financially).

What's the best kind of open source? Code which was written to solve a problem a company (or person) has in their business (or personal life), then released because more people than they are having this problem. Golang? Made at Google as a language that was simpler to write and harder to mess up for engineers right out of college. Rust? Improving Firefox reliability. I almost weep at the strong story behind these projects; the technology wasn't created just to sell, it had a purpose that was validated (to some degree). Not technology for the sake of technology, nor technology directly for the sake of money, but for problem solving. Docker, MongoDB, CoreOS, none of these companies had problems; they invented problems, or inherited problems from previous jobs, then sold solutions.

Are the Postgres developers mad that AWS makes money via RDS? Are the (unaffiliated) Linux developers mad that DigitalOcean makes money via a compute offering? Are the (unaffiliated) Kubernetes developers mad that Microsoft sells their product on Azure?

Unaffiliated being a critical part there, because of course Microsoft, AWS, etc contribute back to these projects. But, many, many of the developers on these projects are unaffiliated, often working at smaller companies/consultancies with no affiliation to the megacorps that make billions on the software.

Yet, I've not once noticed a single instance of aforementioned drama. What makes Docker, MongoDB, etc different? They're open source products developed and monetized by singular corporations, not communities or non-profit cross-functional organizations like The Linux Foundation. Its a big corporation slighting a smaller corporation.

This may reveal a bias in online discourse, especially on HN; we revere corporations, not people. We want to protect venture-backed Docker, but the individual developers working on, say, Postgres? Less deserving. Peter Eisentraut, Bruce Momjian, and Dave Page are core maintainers of Postgres, all working at a company named EnterpriseDB, who sell managed Postgres offerings. Why doesn't anyone complain about AWS screwing over Postgres?

Well, there's something bigger at play: Its actually, totally alright if megacorps use Linux, Postgres, whatever in this way. Developers enter these projects knowing it'll happen, and these projects are healthier than ever. That's a beautiful relationship right there! No drama. No one slighted. If these companies give open source back, that's great, but I don't expect them to (exempting GPL requirements of course), just like no one expects me to contribute every bit of code I write just because I coded it on Ubuntu using vim and linux and gnome and docker and such.

With Docker (and similar corporations), someone is slighted; its the company that was also trying to make money on it. And I think that's just mismanaged expectations at every level; the company believing they could build an OSS community of users and builders while still extracting profit, the leaders for accepting venture capital, and the users believing a company could solely develop and distribute something as complex as core application containerization or a database.

To be clear: I have a lot of respect for Docker continuing to run Hub for free as long as they did. They're an awesome company. No qualifications around that; I hope they find success in the market. I just don't believe that success will come at the scale and valuation they expect, because they aren't selling what customers want to pay for. AWS is.

> As consumers if we just keep taking the freest lunch without any care or love for the general OSS ecosystem there will be a ton of adverse effects. This is a pretty F’ed up way to do business.

Open source doesn't care about the way you (/we) do business.

I know its easy to get this defeatist view about OSS, like, "the linux desktop is losing the war" or "iOS is killing open computing" or whatever, but even if that were what was happening here (its not), open source persists. There is no war. Its just people writing code to help other people. In fifty years AWS, Apple, Google, whoever, might be dead, but code will still be here.

In this specific case, here's how I view this situation. Docker provides an indispensable public service via Docker Hub. They have had six plus years to monetize it, but it turns out, monetizing public services is nearly impossible. AWS has the scale to step in and take over some of the load, and they already have a monetization strategy. Good on AWS for this; Docker couldn't handle it, so AWS will.

Really? Alright then, right now, off the top of your head: What are the set of TLS ciphers which are generally regarded by the security community to represent the highest security standards?

I have no clue. The AWS ALB 2016-08 security policy allows for ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES256-GCM-SHA384 and another 16 or so.

Of course, that's the default ALB policy. I didn't know that. There's a more strict TLS policy available: TLS-1-2-2017-01. Do you know what the difference between the 2016-08 and TLS-1-2-2017-01 policies are? I don't. I could look it up. Well, beyond disallowing TLS 1.0 and 1.1, TLS-1-2-2017-01 also disallows the ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA and ECDHE-ECDSA-AES256-SHA ciphers. Cool.

This shit is VERY domain specific. Its arcane. The way I worded those last three paragraphs was patronizing, to establish a point: No one knows this off the top of their heads. This naturally leads to two things I believe are true at any company (beyond a certain "garage"-scale): As few people as possible should worry about this, and even those people should encode it in some kind of automation that guarantees they don't have to be hands-on when configuring future resources which need this information.

Otherwise: YOU WILL GET IT WRONG. Guaranteed, at some point, maybe today, maybe in eight months, if you let every developer at a company worry about TLS ciphersets, one of them will screw it up. That's not patronizing; that's human nature. We're fallible. We don't all have massive domain expertise, and even the ones who do make mistakes. Manually configuring things is a guaranteed recipe for mistakes.

I'm using ciphersets as an example, but these things are everywhere. I don't trust any developer, including myself, to remember that by default most JWT libraries allow an alg of "none" to pass verification. I don't trust anyone to remember that S3 buckets by default allow per-object public read settings without a separate non-default bucket-level setting to block it. I don't trust anyone to remember that SQS FIFO queues only allow one concurrent reader per read group (nor understand what that means in practice, because this issue is Literally a weekly thing on /r/aws), or to know that hosting a public website on S3 is startlingly easy to DoS via egress network charges and AWS wont refund it.

Capital One, one of the biggest banks on the planet, was hacked because of a misconfigured S3 bucket. I have relieved myself of the hubris of believing I can do this on my own, a hubris every developer needs to relieve themselves of. Encode this stuff into automation and have every eye you can find inspect your changes. And while there's room to give developers a lot of power in this setup, part of that is not "here's an AWS account, have fun".

The correct answer to "What company would provide developers direct access to raw compute resources in the cloud" is "one that is deeply misguided."

At the most simple level, it seems like progress. Now every developer can get their own server and push their code, test it, do whatever, think of the agility. But, realistically, all that's happened is the creation of hundreds of silos, each configured differently, possibly being abused, possibly containing restricted data, mis-configurations leading to breach, denial of service, running up the company card, all sorts of bad things.

In other words, it doesn't matter whether those raw compute resources are available in the cloud or in a company data center. The cloud enables developers broader access to provisioning, but there's substantial evidence that may not be a good thing. A company data center is a 1780s-era musket; the cloud is a M249 machine gun.

That's why we need to talk in abstract functional primitives. Developers shouldn't worry about which TLS algorithms are accepted, or that the storage bucket they want has proper read/write access; not just because a ton of this stuff is very arcane and domain specific, but also because humans will ALWAYS get it wrong unless its managed at a higher, centralized, and totally automated level.

And at that point, raw access to AWS doesn't make sense. Developers don't actually want an EC2 instance; they want their app running on a server. Let Operations (or Heroku, or whoever) handle that for you.

I think your core argument is in the right place, but: What Big Company enables typical developers personal provisioning on their cloud accounts?

I've never seen this before. Its always handled through an operations team. The cloud definitely simplifies the operations team's job, and you may be able to get something more specific faster than whatever gray box the IT Of Years Past has available, but I don't think you're getting around the Cloud Boilerplate of worrying about IAM, CloudFormation/IaC, repeatability, security, granting access, cleaning up...

I think this position is missing the bigger picture; it shouldn't matter where you've got something deployed. That's the Operations Team's problem. Instead, we need to talk about, lets call them, Functional Primitives. For example: If you want a docker image deployed w/ x vCPU y memory z replicas etc, behind a URL. That's a functional primitive. It shouldn't matter whether its in ECS or in Kubernetes in the closet or wherever. That's on the operations team, and its also on them to get that provisioned quickly for you.

In other words, you're still thinking that its the operations team's job to provide servers, so of course the quickest way to get a server is the Cloud. But that should not be their role; their role should be to provide capacity at a higher level of abstraction.

There are (at least) 66 distinct contributors, according to the commit history.

The thing about the Future is, there's always more of it.

Of course that would be a better solution; but its not a feasible one at this point. Our governments are corrupt and businesses are too large; the best we can hope for is protecting consumers as much as possible in attainable ways.

I would like to see a law which states that businesses cannot revoke your access to any discrete good you've purchased. Arguably, media companies wouldn't be the primary aggrieved party of a law like that; it really hurts Amazon (et al) more than anyone, being legally forced to continue serving video files you've purchased even in the face of Terms of Service breaches and such.

Which is perfect. That's exactly what we want. If Amazon has to guarantee access to content, the easiest way to fulfill that requirement is to offer downloads for customers (which I think should be a fulfillment of that requirement, and its alright if they terminate an account so long as a download was offered for all content). Of course, the Media companies Definitely don't want that, so now we have the media companies and tech companies fighting each other. Laws which disrupt the alignment of incentives between companies are the best kind of laws.

"Indefinitely" does not mean "forever"; it means "the end is not defined". The end could be tomorrow, or in a thousand years; its just unknown and not communicated at this time.

This is a similar misconception to the word "infinite", which many people believe means "an unending amount" but actually just means "not finite"; an amount large enough that it can't be quantified, but still an amount nonetheless. This comes into play in mathematics when talking about some infinities being larger than others.

If you take a nihilistic view of the universe, then everything is temporary, and thus even the DVDs you've purchased should have been advertised as a temporary rental. That's not very useful, though.

I do believe it would be a great thing for these buttons to read "Rent Indefinitely" rather than "Buy", and also force these companies to outline in clear and short language within a popup near the button the general conditions under which the rental will be revoked. Like, "Company X may revoke your access to this content in situations where your account breaches the terms of service outlined [here], or if the original rights holders of the content force us to." Not even full ToS, just something to inform people that its possible.

And to be clear, there's a massive swath of digital content that needs regulation like this. Amazon movies, Kindle books, Steam/Xbox/PSN digital games, iTunes music purchases (though in situations like this, I think the word "Buy" is valid given that you're allowed a DRM-free download, but I think the popup should still be required with the language changed to read "...may revoke your access to re-download this content...").

Also important to note that it had Smart Memory Access on, which requires a Ryzen CPU (and furthermore, did they say specifically a Ryzen 5xxx CPU?)