Earlier quoted context omitted.
That is far, far more than transferring a byte of data. It's not the future though of course, this was well established in the 80s, it just so happens that it's a decent model for managing remote machines that outlasted over-engineered distributed designs like Plan9, VMS, MOSIX, etc. It's much more meaningful and useful than "something simple" "running little functions floating in the void" which just sounds like som…
> 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…
We are still early with the cloud
131–140 of 202 posts
Re: We are still early with the cloud
#132The HN conversation yesterday about the complexity of the proton, in particular how we poke and prod at it to suss out its qualities and quantities, got me thinking about the subatomic particles of my personal subjective conscious experience. We can trace, with quite a bit of precision, how a certain photon cocktail results in me perceiving the orange title bar at the top of HN. But where's the orange paint in my bra…
For a moment I thought there must be some faulty entanglement in my own brain, but now I think you actually meant to post your comment under a completely different story that's currently on the front page :) https://news.ycombinator.com/item?id=33272536
Re: We are still early with the cloud
#133Earlier quoted context omitted.
A cynical view would be the billing is designed to trip you up. As an example, if you use Azure with a Visual Studio subscription which includes credit, once the credit is used all of your services are suspended and no further charges are incurred. As a pay-as-you-go customer this option does not exist. You can set a billing "alert" but that doesn't stop the charges.
It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met. https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
> Note: There is a delay of up to a few days between incurring costs and receiving budget notifications. Due to usage latency from the time that a resource is used to the time that the activity is billed, you might incur additional costs for usage that hasn't arrived at the time that all services are stopped.
So still pretty useless. Apparently they do have real-time billing updates via PubSub, but then it's up to you to code what to do when you spend too much. If you're in an exploring phase for [GCP PRODUCT X] you're not going to preemptively write a safeguard to turn off [GCP PRODUCT X] in case of too high billing updates.
It's better than nothing, but kind of a slap in the face that they do have all the tools to really allow people to have a hard spending limit, but they don't.
I've heard the argument "but it's too dangerous, people might lose non-backed up data", but that also happens if you set a Billing Limit, just that the billing limit will kill all your projects AND still let you rack days of over-the-budget billing.
Re: We are still early with the cloud
#134Earlier quoted context omitted.
It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met. https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
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
Re: We are still early with the cloud
#135Earlier quoted context omitted.
It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met. https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
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
I updated my post to link to the section about capping costs, though that still has the delay and won't totally save you.
Re: We are still early with the cloud
#136Earlier quoted context omitted.
there are countless musicians who own the copyright to their own stuff and get peanuts from spotify even for non-trivial number of streams. until spotify pays from MY subscription the artists I listen to, they will not see money from me. bandcamp all the way.
> get peanuts from spotify even for non-trivial number of streams. Define "non-trivial". Easily 80-90% of all plays are by a handful of artists, the absolute vast majority of whom are owned by labels. Even if your non-trivial amount of listenings is in the tens of millions, it pales in comparison to Drake or Ed Sheeran. > until spotify pays from MY subscription the artists I listen to Your subscription is 15 dollars…
> These companies account for more than half of US market share. However, this has fallen somewhat in recent years, as the new digital environment allows smaller labels to compete more effectively
Which to me at least suggests that seperating hardware like CDs and LPs from the actual music is helping artists. Perhaps that should be taken with a grain of salt, though: I'm still optimistic and naive enough to think things may improve for artists.
Re: We are still early with the cloud
#137I 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…
Re: We are still early with the cloud
#138Earlier quoted context omitted.
It's kind of weird that it's not just a built in toggle button to the system but GCP has the primitives to let you suspend the system when a threshold is met. https://cloud.google.com/billing/docs/how-to/notify#cap_disa...
Disabling billing, from your link: > Note: There is a delay of up to a few days between incurring costs and receiving budget notifications. Due to usage latency from the time that a resource is used to the time that the activity is billed, you might incur additional costs for usage that hasn't arrived at the time that all services are stopped. So still pretty useless. Apparently they do have real-time billing updates…
Re: We are still early with the cloud
#139> I never ever again want to think about IP rules. I want to tell the cloud to connect service A and B!
DigitalOcean's firewall is a bit like this.
Re: We are still early with the cloud
#140It'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,…
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?