Forest @forestjohnson@pixie.town

@starless i like the color on this one🌿

I still think what I wrote there, my thesis, still holds up 10 yrs later:

> If your app doesn't have a URL, who's going to use it?

I just realized that I wrote this

TEN YEARS AGO

https://sequentialread.com/pragmatic-path-towards-non-technical-users-owning-their-own-data/

jeeezus im getting old

@seedlingattempt@kolektiva.social @benx@kolektiva.social

Yeah I don't actually know that much about the market for bandwidth at the commercial scale, I just know that its the most common thing that you get nickle-and-dimed for on the public cloud. It could be a little bit of a "gentlemans agreement" among the public clouds that they all get to overcharge for it.

But I think some of them don't, like hetzner for example offers 20x cheaper bandwidth compared to DigitalOcean.

In terms of real numbers, @f0x the owner of the mastodon server I use plus an active matrix server and some other stuff, saw something like 80TB of bandwidth in a month if I remember correctly. That's 4x the amount you get included with hetzner's $5/mo VPS

@seedlingattempt@kolektiva.social @benx@kolektiva.social

Honestly I would worry more about legal issues and regulations making it harder for the little guy to get access to public clouds. That's the only thing I can think of that would force people into livingroom servers.

But IMO it makes no sense for the government to do something like that, if they already have their 3rd party doctrine and everyone and their brother is happily occupying the public cloud panopticons, why upset the apple cart? Gov't would lose an incredibly powerful surveillance weapon by kicking the grassroots out of the public cloud.

@seedlingattempt@kolektiva.social @benx@kolektiva.social

@seedlingattempt@kolektiva.social I don't know... I don't think that a lot of the stuff you are talking about can come to pass.

Yes these hosting providers are driven by greed... But as far as we know, there's no monopoly, there's no syndicate. They **compete** with each-other.

Also, keep in mind that in many ways public clouds are sort of like a utility. Like water or electricity. The stuff they sell is fungible & you can purchase different amounts of it, generally the price per unit stays the same-ish for a given provider. In fact I would say it gets CHEAPER per unit as you buy in bulk, not more expensive.

IMO, this competition in a market for a water-like commodity means that we'll always be able to buy some if we want. The price isn't going to skyrocket. I don't see either supply drying up or demand exploding any time soon.

---

I worked in the enterprise software world for 5 years, for the last 1.5 years of that I worked as a DevOps specialist / SRE for a company that spent almost a million dollars a year on AWS EC2 instances and similar...

I'm extremely familiar with scaling software, the type of problems that come up at scale, and how that translates to the economics of the situation. In my opinion you are missing the most important aspect of the scale question:

**COMPUTERS ARE LIKE, EXTREMELY EXTREMELY FAST**

A computer can easily do a million things per second without breaking a sweat. Yes, even over a network, yes, even with on-disk persistence and each event being validated.

Computer science teaches us to ignore the "constant factors" (each event taking 5 microseconds to process versus each event taking 500 microseconds to process) and instead place a laser-like focus on the __Growth Rates__ of the CPU time and memory requirements as the scale of the problem grows.

In my experience at work, both things end up mattering, but if you don't get the growth rate stuff under control first, any optimizations that can be made won't change the overall picture much.

The problem here is that all too often, the "growth rate" of the CPU time, etc, the "Big O Notation" of your program or network, doesn't depend on what language its written in, it doesn't depend on what hardware it runs on or how fancy the network is. It purely depends on the DESIGN. The interface design. API design. How the parts fit together and move together.

All too often, software is designed quite well for one thing but ends up being used completely differently -- or it's just designed poorly. There is not always an upgrade path from poor design, especially with a networked community of servers like mastodon / ActivityPub. I don't know enough about ActivityPub myself to comment on how its design affects its ability to scale, but I do feel confident to say:

The API design of ANY software will affect its ability to scale 100x more than any economic issues like datacenter costs.

Those Enterprise cloud customers that pay $1M/year to AWS aren't paying that much "just because"... they are paying that much because its cheaper than trying to re-architect their system with a better design. They probably pay over $10M/year in salaries and benefits... It's simply a lot cheaper to hire a few hundred virtual machines to run inefficient code than it is to hire a team of professionals to figure out an upgrade path away from said inefficient code.

New ActivityPub servers like GotoSocial promise to explore the limits of ActivityPub optimization -- if ActivityPub's design allows for it, I predict that once properly optimized, a GotoSocial instance will be able to handle hundreds of users and thousands of federated connections WITHOUT needing a hardware upgrade. I predict Bandwidth will actually be more expensive than the computation side of things!!

That's just my 2c.

streaming work on a web application to provide students with an instant development and deployment environment (vscode in the web browser).

https://stream.sequentialread.com/

But no matter to me if hosted on cloud or self-hosted, i only want to get a MASTER DEGREE

@f0x 😛

@f0x something is wrong with youre web site

my first fermented drink project :X

https://sequentialread.com/fancy-homebrew-grapefruit-energy-drink/

@f0x What is the intended audience ? I thought it was fairly well written and easy-enough to understand, but also I've done a lot with react -- I bet someone who has never used react before would be slightly lost if they read it.

Regarding the part where it shows the normal react useEffect component and then describes what that code is doing -- I think it might be easier for folks who are new to react if it mentioned that in order to understand the next section, you probably need to understand react function components. Then it can offer a link to a primer on React function components and another link to a primer on useEffect.

When you get into explaining what the code does line by line, I think it might help to show the whole code block first, then go through it again line by line or section by section alternating between sections of the code block and explanation text.

(right now its just code block, then one big block of explanation text. By breaking the code and explanation into smaller chunks it reduces the amount of working memory that the reader has to allocate in order to understand what you wrote)

When you mention stuff offhand like the normal useEffect function interface specifying that any return value should be a cleanup function, I think it might be good to hyperlink that part to the docs that describe the spec and/or to an example code block that shows what that looks like. I didn't even know that this cleanup function return value existed! So I would have been delighted to click "open in new tab" on it and read more.

This isn't based on any theory of technical writing or anything I guess its just my 2c.

I never studied technical writing formally, but in my opinion if you study any form of writing like written journalism or creative writing, it will help your technical writing a lot too! When I was in college I took a lot of creative writing classes and I think those helped me considerably.