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

191–200 of 202 posts

Re: We are still early with the cloud

#191

Post by api »

furyofantares wrote: post #68
api wrote: post #3

I can't think about the cloud without immediately grasping its huge downsides: absolutely no privacy at all, data lock-in, forced migration, forced obsolescence, and things just vanishing if the rent is not continuously paid. I have files on my computer from the 1990s and 2000s. If we lived in the cloud-centric world those projects that I did back then would probably be gone forever since I'm not sure I would have ke…

> I have files on my computer from the 1990s and 2000s. If we lived in the cloud-centric world those projects that I did back then would probably be gone forever since I'm not sure I would have kept paying rent on them. On the other hand, I don't have any of my 90s/2000s projects because I would occasionally lose a hard drive before transferring everything to my new machine, or would occasionally transfer not-everyth…

With local stuff you can lose it. With cloud you will lose it eventually if it's dependent on any form of SaaS that you don't control.

Re: We are still early with the cloud

#192

Post by subradios »

pdimitar wrote: post #187
subradios wrote: post #45

Earlier quoted context omitted.

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.

Every repo at every FAANG company is full of dependency specifications pinned to versions several years out of date.

Re: We are still early with the cloud

#193

Post by gumby »

nairboon wrote: post #166
gumby wrote: post #151

Earlier quoted context omitted.

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 wr…

Are you advocating for more abstraction or less? As in a cloud without all the modern OS layers and cruft.

More abstraction

Re: We are still early with the cloud

#194

Post by pdimitar »

subradios wrote: post #192
pdimitar wrote: post #187

Earlier quoted context omitted.

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.

Every repo at every FAANG company is full of dependency specifications pinned to versions several years out of date.

Eh, if it's policy then that's another thing. I was responding to your comment that puts the blame on the programmers.

Re: We are still early with the cloud

#195

Post by gumby »

vanviegen wrote: post #83
verisimilitudes wrote: post #76

Earlier quoted context omitted.

That is far, far more than transferring a byte of data. Educate me. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like some vapid marketing pitch. That was a quick response to what I thought would be better than administrating a UNIX system on an Amazon machine. Don't be an ass. I've no experience with the real distributed computing syst…

> The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. If you want to disable overallocation and the OOM killer, be my guest. You'll want to install some extra banks of RAM though. Or is there a better way, provided by other OSes?

Sure, you push the failure into the processes, and most OSes I've used do this. Thus (to use unix terminology) sbrk and fork() fail and it's the program's responsibility to handle that, gracefully or not as it wishes. You also degrade more slowly via paging.

You shouldn't get to the point where a perfectly innocent process is killed to reclaim memory. A process can die, or even (in some cases) recover cleanly from running out of memory -- that should be the process's choice.

Re: We are still early with the cloud

#196

Post by [deleted] »

rsync wrote: post #26
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,…

"It's crazy and destructive that we are still using the unix paradigm in the cloud." # ssh user@rsync.net "test -f fileThatExists" #echo $? 0 ... from my cold, dead hands ...

[deleted]

Re: We are still early with the cloud

#197

Post by verisimilitudes »

rsync wrote: post #26
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,…

"It's crazy and destructive that we are still using the unix paradigm in the cloud." # ssh user@rsync.net "test -f fileThatExists" #echo $? 0 ... from my cold, dead hands ...

No post body was provided.

Re: We are still early with the cloud

#198

Post by shafyy »

vegasje wrote: post #107
shafyy wrote: post #79

Earlier quoted context omitted.

I've also switched all my dev work to Gitpod a year ago and I don't want to go back to developing locally anymore. I curse and swear every time I need to work on a project locally.

I've had interest in trying this dev flow out, but I haven't been able to determine how it would work for multiple projects that work in concert. For example, a web dashboard project with its own backend that also communicates with an API, which is a separate project. Does Gitpod (or Codespaces) support projects (repositories) that work together?

Gitpod URLs are generated every time you start a new environment (usually every time you start working a new feature/bug fix), and it doesn't have static URLs. So you would need to update the endpoint URLs manually.

If you use VS Code locally to connect to Gitpod instead of in the browser, all URLs are mapped to localhost, so then it shouldn't be an issue.

But I did some digging and it looks like they're aware of this limitation and are working on solution: https://github.com/gitpod-io/gitpod/issues/898

Re: We are still early with the cloud

#199

Post by dengolius »

fragmede wrote: post #94
pojzon wrote: post #87

Earlier quoted context omitted.

After talking to manager at Google during an interview and him explaining to me that almost all tools at Google are home baked because most if not all services are so huge you wont be able to use opensource solutions for that. Then I reminded myself about VictoriaMetrics that in benchmark outclassed Google Cloud Metrics by an order of magnitude. Ppl at Google think they are the smartest (and often are) but in some ca…

Mind linking the VictoriaMetrics benchmark? I found a couple of medium.com articles but not the benchmark itself but it sounds like a good read.

Some benchmarks are listing here - https://docs.victoriametrics.com/Articles.html#benchmarks and https://github.com/VictoriaMetrics/prometheus-benchmark by itself.

Re: We are still early with the cloud

#200

Post by hagen1778 »

fragmede wrote: post #94
pojzon wrote: post #87

Earlier quoted context omitted.

After talking to manager at Google during an interview and him explaining to me that almost all tools at Google are home baked because most if not all services are so huge you wont be able to use opensource solutions for that. Then I reminded myself about VictoriaMetrics that in benchmark outclassed Google Cloud Metrics by an order of magnitude. Ppl at Google think they are the smartest (and often are) but in some ca…

Mind linking the VictoriaMetrics benchmark? I found a couple of medium.com articles but not the benchmark itself but it sounds like a good read.

It might be the pricing comparison blog post for managed Prometheus solutions here https://victoriametrics.com/blog/managed-prometheus-pricing/
Post reply on HN