21–30 of 41 posts
https://fosdem.org/2026/schedule/event/UJKT3L-dial-up-howto/
I'm assuming these numbers are flagged as VOIP (which limits their use as a lot of apps/sites/companies hate VOIP numbers), however the discover is interesting. I thought home phones were dead and buried.
Semi-related note:I learned this morning that there are companies that offer in-home (non-cellular) phone service via wifi/the internet. Think: classic cordless phone, however the base station connects via wifi. Some of those companies offer free unlimited service as well...and the one I was looking at has a companion app for iOS/Android that allows you to make calls from via home number from anywhere as long as you…
Earlier quoted context omitted.
There are services which will remove all but the text when browsing and make it greatly lighter. 20+ mb is the weight of all the javascript javascripting, ultimately to arrange and display an html page.
20+ mb is also the weight of rendering the HTML inside each client, instead of at the server. It is the weight of continuous disdain for users, and of 30 years of not giving a fuck about adding yet another abstraction layer and making it someone else's problem.
Earlier quoted context omitted.
20+ mb is also the weight of rendering the HTML inside each client, instead of at the server. It is the weight of continuous disdain for users, and of 30 years of not giving a fuck about adding yet another abstraction layer and making it someone else's problem.
You can somewhat "fix" this by using your slow link to connect to a VPS somewhere that then connects to the Internet, either via links or a similar text-mode browser, or other bandwidth-saving gateway.
Earlier quoted context omitted.
You can somewhat "fix" this by using your slow link to connect to a VPS somewhere that then connects to the Internet, either via links or a similar text-mode browser, or other bandwidth-saving gateway.
In the article and my pi-isp project, I use MacProxy Classic to strip heavy stuff from web pages through a local proxy service running on the Pi. This helps a lot, but if a page has 20 MB of resources, it can only do so much (without completely disabling JS and images).
If you ever want more phone lines than that, you can pick up an old Cisco VG-224 from Ebay for less than half the price of that line simulator, and you get 24 lines. There is a configuration that will let you use it as a standalone unit where all the lines can call each other with custom phone numbers (here's some notes [1]). The main catch is that they have a 50-pin Centronics style connector on them which you will…
> The main catch is that they have a 50-pin Centronics style connector on them which you will have to break out somehow to your RJ11s. This is just another lost art (traditional phones are either dead or are instead IP) that I once learned a fair bit about: The name varies regionally (I've heard them called Centronics, cinch, and CHAMP; though around here, we call them Amphenols). The Easy Method is the same regardle…
I know we ripped out similar, a plastic panel/wall mount version, at an old job when we went VoIP. The Centronics came out of the PBX. Probably find on eBay or surplus. Maybe talk to IT and they have one hanging around in a junk pile.
> The name varies regionally
Micro Ribbon connector https://en.wikipedia.org/wiki/Micro_ribbon_connector
Earlier quoted context omitted.
20+ mb is also the weight of rendering the HTML inside each client, instead of at the server. It is the weight of continuous disdain for users, and of 30 years of not giving a fuck about adding yet another abstraction layer and making it someone else's problem.
You can somewhat "fix" this by using your slow link to connect to a VPS somewhere that then connects to the Internet, either via links or a similar text-mode browser, or other bandwidth-saving gateway.
What can happen, instead: I can dream.
In this dream, the process of loading a web page identifies the viewing platform well-enough and the server delivers content that is shaped for it, so it can be downloaded quickly and displayed simply by the end-user device. It's not one-size-fits-all at all, or even one-size-fits-most: It's a pile of of simplistic HTML and maybe some minimal javascript and CSS that is meant for whatever the user is using right now.
In this way, the same layout jiggering, varnicating, and transfabulation is done as it is done today, but the work of doing so principally happens on the server instead of the client.
Also in this dream, I can hear people saying "But that's a can of worms!", and they're right. It's a damned mess -- but it's a mess either way. This just moves the mess from the client to the server.
I can also hear shouts of "But there will be hundreds or even thousands of layout paths!" And all I can think is: If there's a thousand unique device types hitting a given dynamic page, and that scales poorly with the server side doing the work, then that's a problem for the systems guys to direct instead of the web guys.
Which is fine: The web guys hacking away however they want is how we got into this mess of 20 megabyte Javascript downloads just-to-view-a-web-page to begin with. They've quite broadly proven that they're shit at this kind of work, and in my ideal world they'd be relieved of that duty.
(And yeah, to be sure: After I wake from this dream I'm still going to go outside and yell at the clouds, just as I do every day.)
Earlier quoted context omitted.
You can somewhat "fix" this by using your slow link to connect to a VPS somewhere that then connects to the Internet, either via links or a similar text-mode browser, or other bandwidth-saving gateway.
That's a lot of stuff that I don't want to deal with or maintain. It's simply beyond the tolerance of my gumption, so it's not going to happen. :) What can happen, instead: I can dream. In this dream, the process of loading a web page identifies the viewing platform well-enough and the server delivers content that is shaped for it, so it can be downloaded quickly and displayed simply by the end-user device. It's not…
A couple of news sites have a low-bandwidth version: https://text.npr.org
[flagged]
Jeff mentioned in his video that just loading the front page of CNN would take something like an hour and a half (20+ MB). 33.6Kbps is not practical for much on the modern Internet in 2026. As mentioned in a sibling comment, Starlink (even in standby mode) would be much better. lite.cnn.com would load in about 10 seconds which is pretty good, but there's not much else like it left anymore. What's amazing is how great…
Simple weather radar image on Compuserve took about a minute to load. Billing was by the minute too!
What’s more amazing is with 10000x the communication speed and about 1000x the CPU, 1/20th the latency, things now are only about 30x faster…
Today, that damn weather page should have been fully loaded and rendered before one even realized they pressed the enter key.