when you think about it, the idea that software should scale is actually really weird. "sure this garden is nice, but how nice can it be if it doesn't grow to cover the entire surface of the earth?"
(just thinking about https://runyourown.social — the "More on scale" passage in particular, and how it's weird that Darius has to present "the notion that software does not have to scale" as some kind of tendentious heresy instead of, like, a default so obvious that it goes unstated)
@aparrish this weirdness kinda feeds my "most software isn't engineered" take -- it seems to me that very little of the software industry designs with limits in mind
@aparrish The related idea that a modern corporation must always seek growth at all costs.
So do cancer cells.
@aparrish i think it betrays the real purpose of writing software for many people, which is that it's only really meaningful as a vehicle for power
@aparrish /me unpacks old internet uncle mode
Actually, scale used to mean that it supports more users/things *on the same hardware*. It was a question of how well optimized the software was. I still support this idea of scalability as a measure of good engineering (more or less; separate discussion).
Scaling to multiple cores (vertically) or machines (horizontally) has often been used to avoid optimization. Which is kinda dumb, unless you can just throw money at your problem.
> Scaling to multiple cores (vertically) or machines (horizontally) has often been used to avoid optimization.
Often, but not quite.
Sometimes a task done in parallel with multiple low-power cores is completed faster than when done with one high-power core. Like compression, for instance. If you still don't use pigz, try it.
A lot of times, a task run by multiple machines provides the fault-tolerance and possibility to safely maintain one node while the other is working.
Let's say you have N cores. You may complete a task in (T/N)+D time instead of T time by spreading it to those N cores. The D is a delta you introduce by managing the parallelization, it's often small enough, but...
... well, first off, this is wall time, not CPU time. That may be all you care about, sure. But then you may want to...
@drq @aparrish ... scale to more tasks, M. Now your total wall time is M*((T/N)+D), or M(T/N) + MD. It becomes particularly visible when M=N that parallelization can hurt, because instead of just using a single core per task (each in time T in parallel), your extra parallelization introduces an overhead of MD.
It may still be the better choice for reasons of CPU utilisation, or because your single task wall time matters, etc.
Anyway, optimizing that...
@aparrish Part of the design of Cwtch is that it davka DOESN'T scale well -- it becomes less efficient the more groups use a specific Cwtch server, and also it's very easy for groups to move servers, leading to loads naturally spreading.
(Servers are also -- assuming cryptography isn't broken -- untrusted with any data other than "some information is being exchanged, probably".)
@nightpool https://openprivacy.ca as an organization --
Sarah Jamie Lewis, Erinn Atwater, Dan Ballard mostly as the individual people coding.
Code is on their Gogs instance: https://git.openprivacy.ca/cwtch.im/ui
(and other repos. Somewhere there thee's in implementation of OV-Net anonymous voting that they've used.)
@aparrish This is a great insight!
As a SW dev myself, I feel it's part of being competent for SW devs to understand how well their code scales. But the only actual requirement is that it scales "appropriately."
In some cases "appropriately" might not be very much at all.
Or even, if you're worried about centralization or and things, "appropriately" might actually mean "not too much."
@aparrish I have been toying a lot with the metaphor that the internet is the most ambitious terraforming project undertaken by civilization so this comparison resonates
@aparrish this is one of the key reasons software has become so bad.
(the same diseased thinking infects other products, but it happens slower).
@aparrish All I can see in this thread is the different type of Factorio players. Just one more ore patch...
@aparrish Nevertheless, it's always bothered me. Similar to how things are deemed failures when the only have a few million users.
@email@example.com I used to overengineer my software because I was worried about being able to scale it up, now I overengineer it because it's fun
+ more colonial legacies
+ also capitalism's neverending search for new markets
it's about the humans (and their minds) more than any intrinsic qualities of software
@aparrish The problem is that Silicon Valley (and capitalism in general) holds the same criteria of success as cancer.
@aparrish Depends on what you mean by "scale".
Scale along what metric? Scale depending on what metric?
@aparrish If the software is meant for a computationally demanding task, for instance, like rendering an image or a video, and it doesn't scale along my system resources (like, it only uses one CPU core to work), this is a bad piece of software, because it leaves a lot of its own performance on the table.
@aparrish If the task is comparatively lightweight - like shoveling text strings around and the software demands a lot of resources per user per task instance, I would also say that's a bad piece of software because it scales badly along the user count, costing (me and the environment) too much to operate.
Which is one of pet peeves I have with Mastodon, for example. All it does it sends and receives text. Why does it need so much resources? Because it's thrown together using RoR, which is famously voracious.
@aparrish But the same Mastodon, supposedly scales well along multiple nodes in a cluster if you want to run a large fault-tolerant infrastructure or something.
Speaking of which, centralized web services always boasted how they "scale better". But over time we see that they really don't: Facebook and Twitter don't really scale along their sheer number of users, which causes problems with moderation fake news, political polarization, etc. etc. On the other hand, I see decentralized systems (like E-mail and Fediverse) scale awesomly by individual servers being largely detached from one another. I mean, E-mail is still with us since the 70s, and is used by people of all walks of life. Fediverse spans across all the social and political spectrum.
@aparrish Same with hardware. There's seemingly a threshold to the number of compute devices working in parallel efficiently. It's called Amdah's law. You can only throw so much CPU cores at a problem until you start hitting diminishing returns and adding more resources to the system does almost nothing.
In other words, "scaling" is complex, and demands context. It means nothing without it.
@aparrish IMHO it's false to compare physical with immaterial.
Moreover, scalability from my point of view is to extend the software to solve a problem the original author not even imagine for. Serving more users is just a subset.
When the robustness, reliability, stability, and simplicity is software craft, the scalability and wording is software art.
Hometown is adapted from Mastodon, a decentralized social network with no ads, no corporate surveillance, and ethical design.