Live data from Hacker News

We are still early with the cloud

erikbern.com

151–160 of 202 posts

Re: We are still early with the cloud

#151
post #120

Earlier quoted context omitted.

> The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. The great thing about x86 instruction set as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. Only a handful…

Poor analogy. You're welcome to address what I wrote directly if you'd like though.

It's quite an appropriate analogy. We used to write a lot of code in assembly code. I used to write microcode and even modified a CPU. But it's been decades since I last wrote microcode (much less modified an already installed CPU!) and now the instruction sets of MPUs like x86 and ARM are mostly just abstractions over a micromachine that few people think about.

And an OS it the same: it used to be quite common to write for the bare iron, to which an OS is by definition an abstractional interface. I still do that, but it's an arcane skill frankly not in huge demand. Which is probably a good thing.

Nowadays most code is written at nosebleed levels of abstraction, which frankly is a good thing, even if I don't like doing it myself. But still, as developers do it, they are often dragged back down the stack to a level that these days few understand.

I think the person/company that cracks this will be the dominant infrastructure play of the decade.

Re: We are still early with the cloud

#152
post #7

It's crazy and destructive that we are still using the unix paradigm in the cloud. In the 70s we have transparent network fileststems, and by the 80s I had a more advanced cloud-native environment at PARC than is available today.* The Lispms were not quite as cloud native as that, but still you could have the impression that you just sat down at a terminal and had immediate window into an underlying "cloud" reality,…

Have you heard of urbit?

I did. Its use of intentionally obscure language that makes APL seem readable and consistent in comparison just because "only smart folks should be able to code in this" is something I simply can't accept. And I love obscure langauges!

Re: We are still early with the cloud

#153
post #150
post #120

Earlier quoted context omitted.

> The great thing about Linux as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. The great thing about x86 instruction set as the base layer is that it allows a commodity common ground with a very capable system that also facilitates more specialized layers to be implemented on top of it. Only a handful…

Well, arm and mips exist, are are no less capable than x86. And most apps don't really care which ISA they use. So that point is false. Now, what is that about alternate OS systems which can still do everything that Linux can, including handling network or service outages? (*well, there are BSDs, but I don't think thats what you had in mind)

My point is that the instruction set of these large CPUs (not AVRs etc) is itself just an abstraction to an inscrutable micromachine. That abstraction lets you develop a complex program without knowing the details.

Unix was specifically designed for small, resource starved machines and did not have the powerful abstractions of mainframe OSes like Multics or OS/360. It's OK, but as modern CPUs and IO systems have grown and embraced the mainframe paradigms that had been omitted from the minicomputers (e.g. memory management, channel controllers, DMA, networking etc) unix and linux have bolted on support that doesn't always fit its own fundamental assumptions.

That's fine, it's how evolution works, but "cloud computing" is a different paradigm, and 99.99999% of developers should not have to be thinking at a unix level any more than they think of the micromachine (itself a program running on a lower level instruction set) that is interpreting the compiler's output at runtime.

Re: We are still early with the cloud

#154
post #140
post #7

It's crazy and destructive that we are still using the unix paradigm in the cloud. In the 70s we have transparent network fileststems, and by the 80s I had a more advanced cloud-native environment at PARC than is available today.* The Lispms were not quite as cloud native as that, but still you could have the impression that you just sat down at a terminal and had immediate window into an underlying "cloud" reality,…

> Utterly the wrong paradigm When you emerge from the jungle, you may notice that not only UNIX conquered the world but even ""worse"" paradigms of Windows and iOS have proliferated. You have to ask why the situation that is so much worse is so popular: is it really everyone else who is wrong?

There are still a lot of fossil-powered automobiles being driven around by people. Doesn't mean they are the future.

Re: We are still early with the cloud

#155
post #7

It's crazy and destructive that we are still using the unix paradigm in the cloud. In the 70s we have transparent network fileststems, and by the 80s I had a more advanced cloud-native environment at PARC than is available today.* The Lispms were not quite as cloud native as that, but still you could have the impression that you just sat down at a terminal and had immediate window into an underlying "cloud" reality,…

“by the 80s I had a more advanced cloud-native environment at PARC than is available today.*” This statement is entirely false as admired in your footnote.

Architecturally and conceptually more advanced. There's a lot of literature about that environment so you can read what I was referring to.

Re: We are still early with the cloud

#156
post #129

I started my career in simpler times. Developers would produce a zip and handed it over to an admin guy. Dev and Infra/Ops clearly separated. No CI, sometimes not even a build step. I understand the power and flexibility of the cloud but the critical issue is the dependency on super humans. Consider a FE or mobile app developer. They already greatly struggle just to keep up with development in their field. Next, you…

> Developers would produce a zip and handed it over to an admin guy This is literally what the cloud is now for a fraction of the cost of the admin guy. Current gen serverless containers basically deliver that promise of ease of use, scalability, and low cost. For me, Google Cloud Run, Azure Container Apps, and AWS App Runner fulfill the promise of the cloud. Literally any dev can start building on these platforms wi…

And implement them poorly and then wish for an admin guy or SRE when things go sideways at 3AM and production is down.

Re: We are still early with the cloud

#157
post #116

Earlier quoted context omitted.

Shame it doesn't actually protect you, this startup [1] had a spending limit and they racked up charges so fast even Google's own billing system couldn't keep up. In typical Google fashion it's luck of the draw if you get saved or lose your home [2] [1] https://blog.tomilkieway.com/72k-1/ [2] https://news.ycombinator.com/item?id=25378899

Note that billing budget feature which they used, is, to use the technical term, fucking worthless. All that does is sends an email notification. I updated my post to link to the section about capping costs, though that still has the delay and won't totally save you.

> and won't totally save you

What a pointless (and perhaps malicious) feature. If something slow is going on, I can check it manually.

It is when something fast is going on that I need automated emergency stops.

Re: We are still early with the cloud

#158
post #129

I started my career in simpler times. Developers would produce a zip and handed it over to an admin guy. Dev and Infra/Ops clearly separated. No CI, sometimes not even a build step. I understand the power and flexibility of the cloud but the critical issue is the dependency on super humans. Consider a FE or mobile app developer. They already greatly struggle just to keep up with development in their field. Next, you…

And you're glossing over the pain points that drove the industry to coin DevOps - those times when the zip didn't contain everything it needed to run in production properly and the admin guy had to call the dev multiple times in the middle of the night because their app didn't start properly on deployment. Or the install/startup procedure wasn't documented properly. Or it changed and the document didn't get updated. Or there was a new, required environment variable that didn't get mentioned in documentation anywhere. Or a new, required library was on the dev's local workstation and not on the server. etc etc

Re: We are still early with the cloud

#159

Earlier quoted context omitted.

Without internet connection, most modern development grinds to a halt pretty quickly in any case. Github won't work. All those dependencies your build needs will no longer download. That issue tracker that tells you what you need to do is no longer reachable, and forget about copy pasting from Stackoverflow. Etc. There are things you can still do offline of course. But it gets inconvenient pretty quickly. There's not…

There are plenty of locations where internet connections constantly breaks, or the network equipment is just so poor that everyone's connections drop/connect once a day or so. Or that the latency is so high that most servers drops your connection before they even gave you a chance to connect. That's "offline" as well even though I'm not actually offline, my connection is just really slow. But the mindset you have exp…

Most software development simply does not happen in those places for that reason. Basically, it's a supply and demand thing. Software developers require decent connectivity and they'll move to where the connectivity is. Or they'll fix a decent connection (using star link or whatever).

Re: We are still early with the cloud

#160
post #149
post #119

Earlier quoted context omitted.

That has been true for as long as I have been programming. But: Similar statements have been made about high level programming languages. Nowadays most devs don’t understand how the CPU works, but write on the top of a tower of abstractions and nobody bats an eye. Many of those abstractions are quite complex! I can imagine that the same could apply to certain kinds of network activities. Look at how ppl use http as a…

We cannot afford the seamless distributed systems, and I don't think we ever will. I use Python because I don't care if adding two numbers is taking a microsecond instead of a nanosecond. But if netwotk call suddenly takes 1 sec instead of 10mS? well, thats a huge problem, let's add a memory cache and rack-level cache and a parallel fetch and a whole bunch of monitoring. The local compute is growing much faster than…

You could design a OS with abstractions built around latency, instead of physical machines. It would still allow you to find and use resources according to their constraints of use, but wouldn't force you to keep track on which exact machine they are located.
Post reply on HN