Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are still early with the cloud

erikbern.com

Post reply on HN
Print view View original

181–190 of 202 posts

Re: We are still early with the cloud

#181

Post by theamk »

TuringTest wrote: post #160
theamk wrote: post #149

Earlier quoted context omitted.

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.

I am not sure what do you need new OS for, and what could you get from OS that you cannot get from today's computing.

If you want user to know they are talking to remote machine, but don't want them to care about which exact machine it is, we have a ton of great solutions already: load balancer, connection pools, service mesh, anycast, dynamic dns, etc...

If you want remote calls to be indistinguishable from local calls on the source code function level, this is also solved! Many RPC frameworks and remote SDKs provide class-based interface which acts the same as the local class.

The only place where OS can help is if any OS function can be magically located on another machine. But even then.. we have remote filesystem (NFS), remote terminal and execution (ssh), remote graphics (x11), remote audio (alsa/pulse)... What is left for the new OS? process management? is it worth it?

Re: We are still early with the cloud

#182

Post by rtpg »

j-bos wrote: post #109
rtpg wrote: post #92

Earlier quoted context omitted.

you could easily imagine some Python-esque shell language (xonsh?) and have that be: print(os.path.exists("ssh://user@rsync.net:fileThatExists")) A boolean, a still (relatively) terse line of code. And when you end up wanting to do something even a bit more complicated it'll be a smooth gradient of difficulty. As with every discussion around shells, though, the amazing terseness of scripts is great, but every form of…

Am I understanding correctly that the concern is syntax based? If so, why not build a wrapper over the existing shell language? If not, can you please clarify?

Well my first thing is I would want a defacto norm adopted in the same way that bash is basically available everywhere. And of course we would want it to be something that doesn't have the busted dependency story of Python. And I would like for third party programs to have a rich interface be provided through this new shell.

For example, you can interact with docker in Python with a lib, but it would be amazing if the docker binary just exposed an RPC interface and API for script languages so you wouldn't have to parse out things from output or otherwise try to figure things out when writing shell scripts. This is, of course, the PowerShell thing, but PS's aesthetics displease me and many other people.

Computers are, of course, turing complete. You can do whatevery you want, really. But for example I end up using zsh instead of xonsh because I want to use what other people write as well.

Re: We are still early with the cloud

#183

Post by verisimilitudes »

throwawaylinux wrote: post #179
verisimilitudes wrote: post #171

Earlier quoted context omitted.

I'm being trolled by someone who finds a DNS lookup and an encrypted TCP connection to send a textual command to another machine is somehow impressive, rather than entirely basic and, again, unimpressive. It then puts the result into a form that can be used programmatically by the local shell. That does sound better than returns one octet with two well-defined values , sure. And already the expert. Impressive. I know…

You seem quite unhinged for a self-proclaimed expert. Maybe it's time for a break from the internet.

It's easy to support the status quo, until someone points out numerous issues with it, I know.

At least read my website before calling me unhinged.

Re: We are still early with the cloud

#184

Post by j-bos »

rtpg wrote: post #182
j-bos wrote: post #109

Earlier quoted context omitted.

Am I understanding correctly that the concern is syntax based? If so, why not build a wrapper over the existing shell language? If not, can you please clarify?

Well my first thing is I would want a defacto norm adopted in the same way that bash is basically available everywhere. And of course we would want it to be something that doesn't have the busted dependency story of Python. And I would like for third party programs to have a rich interface be provided through this new shell. For example, you can interact with docker in Python with a lib, but it would be amazing if th…

Understandable, the challenge is beating the xkcd one more universal standard.

Re: We are still early with the cloud

#185

Post by throwawaylinux »

verisimilitudes wrote: post #183
throwawaylinux wrote: post #179

Earlier quoted context omitted.

You seem quite unhinged for a self-proclaimed expert. Maybe it's time for a break from the internet.

It's easy to support the status quo, until someone points out numerous issues with it, I know. At least read my website before calling me unhinged.

It's even easier to shit on the status quo without having anything better.

> At least read my website before calling me unhinged.

No. I've seen countless tech prophets peddling snake oil over the decades, and it's always the same. Everything is dumb, poorly versed in the state of the art and history, but this magical ill-thought-out thing will somehow solve everything. It's very boring and predictable.

Re: We are still early with the cloud

#186

Post by pdimitar »

pjc50 wrote: post #140
gumby wrote: 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?

Appeal to the currently incumbent solution is not convincing. Very often the majority of people simply choose the lesser evil -- not what's of the best quality or with the biggest productivity.

Or need I remind you that hangings at sunrise and sunset were commonplace and people even brought their kids to them?

I'm sure back then people defended it as well, and it's likely that if you heard their arguments you'd facepalm.

Re: We are still early with the cloud

#187

Post by pdimitar »

subradios wrote: post #45
andersco wrote: post #2

I am not a cloud expert but so much of this rings true, esp the following quote: “Why is Bob in the ops team sending the engineers a bunch of shell commands they need to run to update their dev environment to support the latest Frobnicator version? For the third time this month?” I just couldn’t stop laughing.

Because devs will not update their Frobnicator for seventeen years, choosing to solve leetcode instead. Eventually the Frobnicator that the devs are using will be so security vulnerable the fact that the source code exists in the package repository is itself a CVE. Because you're a dev, when this happens it's a funny story, but for Bob it's seventeen meetings and having to listen to Franz, the director of development…

You might be exaggerating here. Anecdotal evidence and all but even the juniors I work with are mostly diligent in keeping their important tooling up-to-date.

Re: We are still early with the cloud

#188

Post by TuringTest »

theamk wrote: post #181
TuringTest wrote: post #160

Earlier quoted context omitted.

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.

I am not sure what do you need new OS for, and what could you get from OS that you cannot get from today's computing. If you want user to know they are talking to remote machine, but don't want them to care about which exact machine it is, we have a ton of great solutions already: load balancer, connection pools, service mesh, anycast, dynamic dns, etc... If you want remote calls to be indistinguishable from local ca…

> If you want user to know they are talking to remote machine, but don't want them to care about which exact machine it is, we have a ton of great solutions already: load balancer, connection pools, service mesh, anycast, dynamic dns, etc...

Those resources are complex to program against. An OS should offer a simplified abstraction layer to make them as transparent as possible. And yes, process management is worth having a unified programming model that doesn't force you to keep track of where each process instance is being located - that's essential for massively parallel computing.

Of could this could be done with platforms for massively parallel computing. The point of building an OS would be to put these platforms as close to the metal as possible to improve their efficiency.

Re: We are still early with the cloud

#189

Post by RamblingCTO »

kajecounterhack wrote: post #85
RamblingCTO wrote: post #82

Do we really want to develop in the cloud? My gut says no. I have no real opinion about that, but seems worth investigating. Is anybody working with a proper dev environment (no, sorry, a small react-only project doesn't cut it, I'm talking jvm driven, ran by docker kind of thing) in the cloud here?

Yeah, as another commenter mentioned, all Google SWEs have developed in the cloud for a long time. It allows you to write, run, and test code performantly on any computer with a browser. Some of OP's wishlist are realities at Google. E.g. - When I compile code, I want to fire up 1000 serverless container and compile tiny parts of my code in parallel. - When I run tests, I want to parallelize all of them. Or define a…

Thank you! So I think for us the only attractive thing is to have cloud runners for our sadly very resource-heavy tests.

Re: We are still early with the cloud

#190

Post by imwillofficial »

gumby wrote: post #155
imwillofficial wrote: post #56

Earlier quoted context omitted.

“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.

That’s a hand wavey way to make a claim that can’t be backed up.

What you had then was in no measurable way more advanced architecturally or conceptually. Name one facet in which it was more, could do more, or faster, or better.

You can’t because it couldn’t. No part of your setup was cloud native. Nothing was abstracted away, a core tenant of the cloud.

You can’t just redefine words however you want.

Post reply on HN