Re: Anyone still using 16-32bit systems ?
- 🗣️ From: Rohan Kumar (seirdy (a) seirdy.one)
- 📅 Sent: 2021-07-15 20:34
- 📧 Message 6 of 8
I put a TLDR at the bottom of this giant wall of text.
On Thu, Jul 15, 2021 at 05:34:29PM +0530, Arun Isaac wrote:
> --8<---------------cut here---------------start------------->8---
> The embodied energy of the memory chip alone already exceeds the energy
> consumption of a laptop during its life expectancy of 3 years
> --8<---------------cut here---------------end--------------->8---
Agreed. If you're running a datacenter or homelab, then the footprint of
continued uptime could catch up to the manufacturing footprint quite
easily; however, I think we should move away from the "scale everything to
massive machines" approach in favor of simple software that can run on a
near-vintage computer or highly-constrained environment.
Implementation authors can be liberal in deciding what computers to
support/not support. When deciding what computers to support on a
- platform*, however, we should be more conservative. We should define what
computers to consider "vintage" and try to make it possible for
non-vintage computers to participate.
It's time to write what will definitely become a {web,gem}log post at some point. Oh boy.
## Part 1: Vintage computers
I loosely define a vintage computer to be any computer whose *hardware*
prevents it from being useful today for a hypothetical user whose use-case
hasn't changed since the computer was new, but wants to compute according
to current standards. Such a user might have used Gopher and unencrypted
IRC in 1996. Today, encryption in-transit has become an expectation for
many reasons; this user might now use Gopher-TLS, Gemini, IRC with TLS, or
a basic web browser for viewing Web 1.0 sites with HTTPS. Notice that I
haven't mentioned any particular software implementation by name; I'm only
mentioning implementation-neutral platforms and protocols.
Computers from the start of the millennium and earlier can't effectively
leverage secure cipher suites supported by most TLS implementations.
They're slow, lack SSE2, etc. Users who expect to be able to communicate
over the Internet might find themselves unable to use current protocols
(https+tlsv1.2, gemini) even if they only want to view very lightweight pages.
These vintage computers still have their uses, but they're better
relegated to domain-specific applications (distraction-free writing, dumb
terminal for another computer on the local network, etc) than
general-purpose computing, or they can be used in conjunction with a
non-vintage computer (e.g. a proxy that encrypts/decrypts traffic for TLS).
Another example: a user in 1999 might have hosted pages for others to
access over the Web on an old personal computer from their home. Today, to
do the *exact same thing*, this user might need a beefier computer due to
the prevalence of bots, crawlers, and a greater number of users. A server
that was just able to handle the load in 1999 might now be considered a
vintage server. This user might consider buying a more powerful computer,
such as a Raspberry Pi.
( Aside: project of note to bring a subset of modern TLS to the Internet
of Old Things: https://github.com/classilla/cryanc )
## Part 2: relevance to current discussion
Gemini's primary use-case is viewing hyperlinked documents over the
Internet. Today, use-case comes with default expectations, like
encryption, for a baseline level of privacy and authenticity. Two conclusions follow:
1. Some computers are now considered "vintage" in the context of the
use-case "viewing hyperlinked documents over the Internet" because they'll
be painfully slow when handling modern crypto.
2. Gemini must support transit-level encryption to properly meet its
stated use-case today.
This means that Gemini probably doesn't need to address computers whose
hardware prevents the usage of secure TLS. This does NOT mean that Gemini
needs to ignore all 32-bit computers; plenty of 32-bit machines can handle
TLSv1.2 (with strong cipher-suites) and TLSv1.3 just fine.
## Flaws in what I've written
- I haven't researched attempts to use modern crypto on old computers
very thoroughly; I kind of guessed that Pentium 4 with SSE2 should be the
"cutoff point" for modern crypto.
- I might want to pick a word besides "vintage" when describing computers
that can't meet the same use-case after requirements change; something
that specifically refers to a piece of a technology that isn't
necessarily old (it doesn't have to be old) or obsolete (too broad) but
is just unable to adapt to a use-case being "updated" to address current
requirements as security holes and bad actors pile up.
## SUMMARY/TLDR
If you're making an implementation, feel free to be as portable or
non-portable as you want. When deciding norms, *recommended*
implementations, and inherent platform limitations: conservatively
evaluate what computers cannot handle your desired use-case and try to
make sure all other computers are included to the best of your ability.
Don't "expire" computers unnecessarily.
-- /Seirdy (seirdy.one)
---
Previous in thread (5 of 8): 🗣️ Arun Isaac (arunisaac (a) systemreboot.net)
Next in thread (7 of 8): 🗣️ Jonathan Lane (tidux (a) sdf.org)
View entire thread.