Testing a Galileo Board in 2026, Part 2 of X

This is less a Part 2 than an interregnum on a walkthrough plan for booting an OS on my 2014-era 1st gen Galileo board that I purchased earlier this year. While it's a lot more productive to write code or actually get the board to boot, talking about what I'm doing might actually interest people who are late bloomers to this hobby (for lack of a better word).

I am hoping it doesn't take me all summer, but if it does, it will be a Summer of Code.

In the past few days, I have discovered some other hobbyists testing the Galileo board as recently as 2024 and 2025 (and likely 2026 too), who encountered some issues with SSHing into their system, both via the USB to Serial adapter, and via a LAN connection. There are various reasons why this might be, and since I am running an update on Rocky Linux 9.5, I have not included links to save bandwidth on a limited connection.

But the gist of the issue is that SSHing into the Galileo board may return a "connection refused" error. There can be multiple reasons for this. One is that SSH isn't installed on that particular image or it's not enabled. First, the minimal linux image isn't quite sufficient to run a more featured OS. Thus the first objective is to properly flash a working distro. I have found several, including a Debian 3.8 distro, which appears most promising, although some of its spinners have encountered issues with it, even returning to the original Yocto blend. This is a classic example of "the more you know," the more capable a hacker one can be. I am quite annoyed at myself because I remember thinking back to when I was 16, and seemed to be more creative with finding fixes to a PC than I do now. But that's not all. What I've started to think about is how different the Galileo/Edison boards are from the Raspberry Pi, and the things I like and don't like about both of them.

 While both the Pi and The Galileo have a bootloader, it is not readily accessible without a microSD card. This differentiates them from a x86 motherboard where a firmware is installed regardless if an OS is installed or not. It's a convenient recovery method when trying to set the right mode for a hard drive (e.g. AHCI or legacy IDE), or enabling the first drive to boot (such as USB before drive C: or D:). I often prefer to dual boot on separate drives, rather than separate partitions, in case there is some aggressive OS that likes to overtake the boot process (it seems Windows always tries to place itself first on an autoboot once a drive is selected first). I have installed CoreBoot on a Chromebook, which I find quite satisfactory (although sometimes it lags, possibly due to a slow SSD on board).

Since the Raspberry Pi is marketed as an educational board, it might make sense that it features a helpful coprocessor to facilitate booting. While I didn't bother to buy a Raspberry Pi until 2020 (I had long known about it since 2011, and even met Upton in NYC at the Queens Maker Faire), I didn't even know until 2023 or 2024 that it had a not-so-secret (or no longer secret) VideoCore IV processor that begins the boot process: https://news.ycombinator.com/item?id=12743235

From Fuzix developer David Givens:

"The Raspberry Pi is really a VideoCore IV processor with an ARM bolted on the side. At power on, a boot ROM loads an embedded OS image into the VC4 processor. That then sets up the hardware, powers up the ARM, and loads the OS image into that. The VC4 then continues running in the background servicing RPCs from the ARM.

What this is is a replacement VC4 operating system image which just fires up the ARM with an embedded image, sets it running, and then halts (assuming I'm understanding the docs correctly); so it can't (yet) actually load an OS into the ARM from disk or respond to RPCs etc.

In practical terms, this is the biggest, most difficult step forward towards running an almost completely open system on the RPi. (It could also be used as the core of a proper operating system running on the VC4 itself, which could be rather interesting.)"

Reading up on the history of why this was developed, I can see the practical reasons for it (in reverse order) :

david-given on Oct 19, 2016 | root | parent | next [–] I've written some bare-metal stuff on the Pi (somewhere I've got a 90% finished port of Fuzix for it), and oh god yes, that's so true. Being able to do complex stuff like set up a framebuffer by making a simple RPC call to the VC4, passing in a pointer and a descriptor block saying 'this big, please', is so much better than having to do it yourself. But this firmware doesn't contain code to initialise the GPU, it does contain initialisation code for one rather important peripheral, which is the DRAM. The VC4 has been pretty well reverse engineered for a while (I did one of the early C compiler ports for it), but the big missing piece was figuring out how to initialise the RAM. Without that, everything had to fit in the 128kB of built-in SRAM. This firmware's a huge step forward.

makomk on Oct 19, 2016 | root | parent | next [–] In practical terms, this seems to be quite a long way from running a completely open system - the VC4 is responsible for initializing a whole bunch of critical and I believe undocumented hardware that's required to enable any of the peripherals, and this doesn't. Basically, a whole bunch of stuff that'd be implemented by drivers on (say) most Allwinner SoCs I've looked at instead relies on the blob. This is probably part of the reason the Raspberry Pi has relatively good mainline kernel support - they don't have to deal with months of LKML hell to get basic things like clocking and power management working every time they release a new chip because that's all handled in the blob.

720p on 384Kbps? How? Here's how.

One of the marvels of new technology is the increasing efficiency of video codecs. The first video codec I recall was MPEG-1, along with .avi. It's been a long while since I had much of an interest in codecs, although I have on occasion preferred H.265 when available (over H.264), such as when recording with my Vega 56 GPU, which has a hardware based encoder. This helps keeps screen recording files smaller. I also have an SVT-AV1 software-based encoder on my Ryzen CPU.

AV2 and H.266 are being developed, and AV2 is probably going to be released later this year. This will allow more efficient 8k and 4k videos, but there are also improvements in the file sizes for smaller resolutions.

Since I have been testing a slow mobile data plan (with "unlimited" data beyond a 1GB alottment), I have been curious how much "bang" I could get on a budget MVNO plan. The answer might surprise you. A couple weeks ago, I was testing out a 128Kbps plan, which if most of the internet were still in 2000-era web design, might actually be somewhat tolerable. But since most websites need and do use more data, I had to upgrade to another plan that offered a bit more. I am not ready to upgrade to something in the MBps speeds (I have used that on wired plans, however) although I will soon, once I am done testing my Galileo board- I found an ethernet cable, and will get to that in another post. 

My current plan offers me 384Kbps unlimited, and I was curious how much streaming I could do with this, using my phone as a hotspot, since my desktop offered more controls.

First, I wanted to set some parameters for this test. It couldn't be a video that I could download, although that is an easier option since even a 128kbps could play 1080p or even 4k if one waits long enough (assuming the connection doesn't cancel or fail and restarts). Second, it had to be 720p, which is a little harder than streaming 480p (for most videos, that is the limit of what 384kps can handle, and even then, it might be slow on a higher encoded bittrate.

Third, it had to be production quality video, not something recorded on a smartphone (or at least a really cheap camera phone). I have long subscribed to RED camera channel on YT, which has a lot of technical videos on their cameras, along with sample footage from filmmakers. Some of the quality exceeds TV quality, so I thought this might be a good benchmark.

RED also has cameras that shoot in anamorphic, which is an ultra widescreen 2.39:1 format. Most widescreens are in the 16:9 format, and a few of their videos offer that format on Youtube, which apparently the latter now supports too (from the appearance of the maximum resized window showing that).

However, I determined that 2.39:1 on 384Kbps was too much data, so I wasn't going to be able to stream that without significant buffering. It wasn't my first choice anyways, but it was something I stumbled upon when testing a 2nd RED video after getting a smooth result on the first.

So how does it work? Right-clicking the video in a Chrome or Firefox browser will reveal "Stats for Nerds" option. Click that and you'll be able to see all the technical data of the video, including dropped frames, a crucial benchmark for smoothness.

The first thing I noticed is that RED was using AV1, which is great. I selected this in the Youtube settings to default when available. This offers up to 50% efficiency improvement over h.264 and 33% over VP9 (Old news but here's the link). The only problem, is that older computers don't have the decoder in hardware, and seem to use a software decoder to play it back. Fortunately, I was testing this on a 4-core, 8 threaded i7 from 2012. This was released in Q2 of 2012, which was quite a while ago. But it was able to play back AV1 smoothly, and only used 2 of the 8 threads, averaging around 25% of the CPU utilization. On a dual core CPU, especially older ones (and ones that are not dual threaded), that might not be enough to play back 720p video in a Chrome Browser, at least with AV1. 

Also, many smartphones released in the past 3 years include AV1 decoders, which is a plus because many phone resolutions have between 720p and 1080-1440p, although the latter uses more battery power. 128kbps can play back 144-240p and possibly up to 360p, but it depends on the codec.

The last part of this requirement turned up only by accident. I wasn't actively searching for 24p video, but since movies are typically shot in 24fps, they indirectly use less data than say, a 30fps TV show or network broadcast. I wasn't thinking that 30fps would be the straw that broke the camel's back, but in this case, it was. I was able to play this video with extremely minimal buffering without preloading the video (often at least 33% is recommended if it is on a slower connection so that it won't catch up by the end of the video). Chrome used to have browser extensions that would allow smarter prebuffering, but it seems that youtube allows more prebuffering than it used to- where it would pause at just 15 seconds ahead of the video to limit excessive bandwidth usage by users who might not complete the video. For smaller videos, however, this at least seems to have changed.

The video I tested was this: "V-RAPTOR XE REEL" 

A caveat is that the "Viewport/ Frames" indicator is actually the uncropped video that the video uploader sent to Google, whereas the Optimal Resolution is what Youtube crops for the format selected. While the fps can't be toggled (except when deciding between 480p and higher resolutions, which sometimes are encoded at 60fps starting at 720 and up (but only for videos that were recorded uploaded with 60fps), the 720p resolution shows 24fps, and this is actually preferred in this case since it will use less data. The Viewport is also sending more data to the browser than is being used, so the closer the resolution to the actual intended size requested for viewing, the less data that will actually be "wasted" (i.e. not seen, for example, on a 720p monitor that can't view resolutions above 1366x768- although up to 4x downsampling does result in a sharper image, except in this case there isn't the bandwidth for it). 

I will also point out that when AV1 was first released, some websites, maybe youtube included, would only encode the larger 1080p, 4k and 8k videos on it to save encoding resources, while leaving the smaller videos at vp9 or h.264. It's unclear if this changed for newer videos with additional resources/datacenter, but I still see a lot of videos encoded in vp8, even at higher resolutions (it's also a user preference for some). This can also also have the unexpected result of possibly seeing a 480p video encoded at a higher rate (in vp9/h.264) and size than a 720p video encoded in AV1. Higher encoding rate doesn't always equal better quality, although it might preserve some artifacts slightly better, depending on the  equipment, lighting and other filming techniques used.

I could have encoded these in .heic but Microsoft wants me to buy the codec from the Store.

As you can see from these screenshots, there is a bit of a dip in the bandwidth, and it was because I hadn't realized Chrome was updating its browser, which it does quite frequently (often 1-2x a week or more for minor and major security updates).

Another possible caveat is that the cell connection might not always be as strong, causing additional buffering delays. But I haven't had this issue so much as noticing unexpected system or browser updates, which seem to happen a lot more often than the once a week or every two weeks cycle. Fortunately, Firefox allows you to pause or postpone an update by clicking on "Help- About," whereas Chrome goes HAL9000 on preventing any manual override to the automatic updates. The same follows for Edge, which is a Chromium derivative too. As much as I prefer to use a Linux OS in the near future again, sometimes there is a convenience to using Windows (and I'm referring to 10, not 11). So there, this post was a brief analysis on how to get a decent, smooth production quality video playback on a throttled connection, even when:

1. Connected to 384kbps

2. Connected to a wireless hotspot

3. Running a memory-intensive browser such as Chrome or Firefox

4. Playing back HD quality 720p24 video- not 30fps nor 720p/60.

5. (Not  running any system or browser updates, including on any other devices connected to the same hotspot, including the phone itself)

6. Pre-buffering the video when/if necessary, usually at least 33% but less if you're feeling lucky.

7. Not in 2.39:1 format, only 16:9 or less, although still cool if you can, and 2.39:1 runs fine in 480p mode.

8. Also, 24fps is preferrable for historical reasons and TVs can display it properly when motion blur is turned off.

I'm building a parallel internet, and it's called The Thinnernet

               

Since 2020, I've taken on a Steve Jobs alter-ego (on a very, very part time basis, and often for humor purposes). The first essay I wrote wasn't even related to hardware, or solar powered-conscious operating systems that began around the same time. It was actually about one of my former jobs, regarding Knowledge Bases. Using one every day, I thought there had to be a better way to integrate steps taken into a ticket management system, to show proof of work. I won't say which system and which company, since it doesn't matter. I thought back at the time, where else did someone care so much about not only user experience, but the employee's experience? And I realize it was Steve Jobs. Here is the essay I wrote, on a higher level Knowledge Base called Experience Base, later included in part of a concept CMS called TicketMS.

A month ago, I read an article by Dr. Nathalie Martinek that basically described the exact problem my organization had- inability or unwillingness, or slowness to adopt new or improved changes to a workflow.

If you were a futurist and tried to predict the future using only today's news headlines as a indicator, you might think that the future will consist of a bunch of buzzing drones delivering Doritos and Dr. Pepper. That is for the most part true. However, what isn't really flashy or covered is what the internet will/might look like. Fiber optic tech has seen significant improvements, and it's likely that more households will have access to something like 1Tbps before 2050. But very few people will need that much data- maybe- I suppose 125GB/s might be useful for 16K uncompressed video, but I am not sure what else. Maybe lots of coordination feeds with other autonomous agents. 

In 2023, I started thinking and writing about a parallel internet:

You might also be wondering, wasn't Steve Jobs more of a device guy, and not an infrastructure or web design auteur? And the answer is yes! While he was one of the first to include a TCP/IP stack in his Unix OS & hardware in 1987, he wasn't really focused on laying down internet undersea cables. There was plenty of optimizing the user experience on the personal computer alone. Most desktop programs didn't even need an internet connection, and some still don't. Plus, internet traffic at the time was very limited, and there was very little damage any "CDN" or website could do. I say that because there was so little data being transferred, that few limitations could be placed on files, formats, protocols, browsers, and services.

If you were to wonder what a 21st century (post 2011) Steve Jobs "type" wanted to accomplish, he would be focused on the same exact thing: The user experience. But the user experience today is being shaped less by hardware and more the infrastructure and the social networks that many are dwelling on. Often times, still voluntarily. If Steve Jobs really wanted to ensure that users could get the same user experience as they reliably could on a spotty, but flat delivery of data on a 2G or 3G connection, he would be focused much more on ensuring the apps could use limited data. Because internet speed is part of the user experience.

There is a funny email that had been released after before Jobs's passing where a user complained of a spotty signal, and his advice was basically to not hold the phone in that direction (or with his hand over the top part where the antenna was positioned). One of the most influential CEOs at the time was basically suggesting rabbit ears fiddling like on analog television receivers. But I defend his actions, because 3G technology at the time wasn't robust, and one shouldn't have expected him to have all the solutions that were out of his control (even if they tried to build their own modem and it was inadequately developed compared to Qualcomm's, which DID happen, but that's not really a major part of the current issue). It's that all technologies take time to mature, and once a lot of the EMI kinks are worked out, a certain level of reliability becomes expected. And I have absolutely no proof, but I think that would be one new frontier that, had Jobs lived to 70 or 80, might have embarked on. 

What am I referring to? In order to ensure the user experience is consistent across every device, the entire transmission of application data/content would have to be completed in a real time deadline. Asynchronous communication is certainly welcome and important, but many features can be standardized to a point where digital interactions become constructable and replicable. Refresh rate is something Iphones have mastered with latency. But internet latency is a different story. It can be important when accessing a website or service and hoping to get the same format view, with the same data loading in the same amount of time. With static HTML, the page might be wide and the text small, because the browser has no auto-resize feature. But at least it might not have any problems loading the text (unlike a browser that can't display Javascript), and the text can be converted into a different view, like Reading View, which modern browsers offer. 

I wouldn't say this is leading to a homogenized user experience. What I think is lost in the era where everything requires a ton of bandwidth is that it is very hard to notice how much data is being transferred unless you're on a slow connection. Admittedly, I am testing a slow connection out, not that I am complaining about the connection speed when I have the option to upgrade. But that is not why I want others to try out a Thinnernet. It's because I'm suggesting a fallback in case the infrastructure can't handle an always on, always connected world where hundreds of GB are downloaded a day, yet can't deliver a single byte in an instance where there is an outage or an easily preventable network congestion issue. 

So what is Thinnernet? Imagine a fiber optic bundle of undersea cables- maybe a hundred or so 10Gbps cables comprising a large, round internet cable with a diameter of maybe 3 feet (highly weatherproof). These might have been manufactured 15 years ago. Today, they're likely higher capacity. Now imagine you have a very advanced computer from 2040 where your PC's ethernet port can receive that speed all at once with a single cable- maybe 1Tbps or 10Tbps. Now return to the original bundle, and pick one cable. That's your internet connection. It might be 10Gbps, even though the ISP can sell you a service for 10Tbps. 

Now instead of that 10Gbps cable, go back to the mid-1990s, and an undersea coaxial cable company is using maybe 10Mbps in each bundle for a total of 100Mbps or 1Gbps. Now connect a single coax cable to your PC (using the right modem or ethernet converter). You have 10Mbps. 

If you're Steve Jobs, and you want every application to have the same predictable experience, whether someone is using 1 Mbps, 10Mbps, or 1Gbps, there would need to be a minimized mode of traffic that ensures a certain set of apps can predictably access a subset of websites and "essential data" with known webpage sizes (e.g. under 100KB, or under 10KB), so they are more or less whitelisted for usability, and no guesswork by the user has to be done to figure out what sites can be accessed on a certain connection. The way the web is designed is still open, and rightfully so, with decentralized servers and DNSes. But applications themselves and the servers they access must be able to know where they can be used reliably. This is not really a single website's or network engineer's problem, but everyones. A big fish in a small pond is going to use a lot more data in a place where little data is typically used. In the mid 2010s, you could still find a lot of people using Symbian phones. At one point, I set up a twitter relay service on my phone, which allowed me to read and send tweets using just SMS and without an internet data plan! I recall Facebook offered this in India for relaying to their Messenger services but eventually got rid of it due to the costs.

In theory, using less data shouldn't be much of an issue or cost for a big company. But because it uses legacy infrastructure, or has fewer spam mitigation tools (e.g. with Carriers slow to ban numbers rather than having a software dashboard by a Meta employee) the costs are much higher than when using a higher speed technology such as Fiber. The same reason Verizon and other phone companies gradually phased out copper phone lines. 

History may be often boring, but it also offers alternatives and ideas that have long been forgotten. The internet as it was built today includes some very fast and amazing technology, but it also includes a lot of deliberately crummy software designed to get people to upgrade. While some people think this a healthy feature of capitalism doing its job, its also limiting the idea of capitalism to incumbent builders who are prioritizing bandwidth heavy platforms and not really offering an energy-lite way to access the web. An adaptable internet is really the best user experience a company can offer. Which is why I think Steve Jobs would have been the Cornelius Vanderbilt of the Information Superhighway, had he not died of cancer. And by that, I mean that everyone who could afford to ride on one of this trains or railroads would all get the same speed. Thomas Friedman once wrote

“Communism was a great system for making people equally poor. In fact, there was no better system for that than communism. Capitalism made people unequally rich.”

When people try to describe low tech or high tech, they inevitably use an ahistorical starting point to describe slow internet or a slow computer using terms or concepts that are often non-technical. The people who know how to run a fast internet on a slow data connection like me would be considered minimally proficient. The people who cannot get ANYthing to run on a slow data connection are non-proficient. The difference may be subtle, but new technology adoption often depends on a"lie" that something is broken or antiquated. While there are many new technology advances that might not have been possible had too few people adopted a highly profitable new product, it doesn't erase the historical truths of the efficiency and even security (not always) of older systems.  

And for that reason, a competent engineer could design five different speeds where the most important data still arives first, allowing the least bandwidth tiered user to still receive a static HTML of their email, while the highest paying customer receives a tacky, luxurious Javascript wrapper around their inbox (arriving at the same time, like that feather and hammer drop experiment on the moon): 

"Design reform began with Exhibition organisers Henry Cole (1808–1882), Owen Jones (1809–1874), Matthew Digby Wyatt (1820–1877), and Richard Redgrave (1804–1888),^[11] all of whom deprecated excessive ornament and impractical or badly-made things.^[12] The organisers were "unanimous in their condemnation of the exhibits."^[13] Owen Jones, for example, complained that "the architect, the upholsterer, the paper-stainer, the weaver, the calico-printer, and the potter" produced "novelty without beauty, or beauty without intelligence."^[13] From these criticisms of manufactured goods emerged several publications that set out what the writers considered to be the correct principles of design. Richard Redgrave's Supplementary Report on Design (1852) analysed the principles of design and ornament and pleaded for "more logic in the application of decoration."^[12]

Computer UX is entering its Arts and Crafts social reform era. Every internet user has witnessed the modern day Great Exhibition. History doesn't repeat, but it often rhymes: AI and Craps. 

(Edit 6/13/26: This post got over 26k views according to Blogger stats. Much of that is due to my sharing it on HackerNews, and I received some very interesting comments. One is from John Nagle, author of Nagle's algorithm). Some of the other commenters have voiced concern that the parallel internet idea would create a "walled garden" of sorts, separate from the larger websites. As several of my HN replies have indicated/rebutted, it is neither a separate physical web, nor closed from the actual "full stack" websites. Rather, it is more like a carpool lane, or a bike path, in a major city, where there are streets with cars but very little space for bikes. In both of those cases, they often share the concrete infrastructure (fiber backbone), but may have slight software (QoS) or hardware curb/sidewalk dividers that keeps the traffic separate but not completely blocked. In other words, an easement oor easeway.

I feel carpool metaphor is important for several reasons. Using a lane where the individual traveller is using less car space per person (e.g. 4 people in a sedan) compared to 1 in a SUV or van allows the possibility of those travellers to get a faster speed on the expressway. By requesting less data (when possible) they are rewarded with a faster trip. Thus the parallel internet is to encourage users that they have options when visiting websites, just like solar and wind energy creates competition from oil and gas providers. Just because oil infrastructure may be efficient, doesn't mean other modes of energy production/delivery can't be used.

The bike metaphor is also important, even if it might not make as much sense. No one pedals a computer to "surf" the web, unless is the Quixotic Low-tech magazine. But inputting data into an online search query does symbolize the manual nature of internet use on a fundamental level. Automatic retrieval and updates increase bandwidth requirements, whereas human-managed data is best allocated its own bike path, given protections from the ultra high speeds and system requirements that other protocols/websites require. For that reason, there are benefits or exclusions that can justify essential data lanes (if enacted via tagged packets for certain services).

MQTT & AMQP are other ones, with less header data. Thus, if internet traffic were analogized to a toll booth, bikes and headers with few packets (KBs, instead of MB), might be "tolled" less because they have fewer (or no) axles (analogous to headers and MB/GB). But taxing internet by data isn't really the suggestion here- as that is typically paid through subscription to an internet plan. The innovation here, is to encourage more liteweight versions and to explore how competitive/beneficial that can be for the overall experience (less time waiting in traffic, or decreased likelihood of causing other externalities-maybe someone else's internet experience won't be slowed). The city analog would be a less car-clogged city- more commuters and sidewalks filled and fewer streets for "cars only." Adding an expressway to Manhattan by Robert Moses was covered by Jane Jacobs in her book, and while I see the benefits to both sides, may not be the best metaphor here, except in certain platform-wide ecosystems. A WAN of WANs like the internet can retain its diverse aspects, but a concrete jungle like NYC has limited real estate for cars, as well as vertical farming...;)

5 things to lighten dependency on web apps

If you're like me, you've grown up on desktop "programs." In the late 00's, this got changed to "apps" because the mobile device market took away the leading attention span from computer users (mainly new ones). The first time I heard someone say the word "apps" to refer to mobile phone programs, it was 2011 or 2012. I knew something had changed. Programs no longer had the same pull as they once did, even though they were practically the same thing.

It's pronounced "programs."

Whenever you hear someone say "bring back this or that," they always sound like a person raising their fist at the sky. I remember someone who used to follow me on Facebook, who would like or share posts that said, "bring back X penalty for X crime" More often than not, they were just a lonely person.

So I am not going to say "bring back program" nomenclature. You can call it whatever you want. Even peach rinds. I know peaches don't have rinds, but now it sounds like they do. You might have been thinking of pork rinds, where I got the name, and then thought oranges have skin, and so do peaches, and so whatever skin peaches have, could be turned into peach rinds. But peaches can be eaten whole (except for the seed and stem), so that's not really a separate thing that anyone would ever need to make.

But it sounds funny because peaches might resemble, in color or shape, another thing that rhymes with rind.

I haven't gotten off topic. This was always probably going to be said. Initially, I wanted to write "5 lightweight programs," but then I thought, "what the hey, why not 5 light humored things to write about?" Actually it will be liteweight programs and whatever I already wrote. They might add up to 5.

In my recent posts, I covered Hugo. I am still working on that. But TCP/IP is a rigid protocol. There have been some clever protocols, both old and new, that can bypass that. If you need or use a lot of bandwidth, QUIC over UDP is a relatively modernized protocol that uses TLS 1.3. Cloudflare has a great write up on the mechanics of it, and major CDNs use it. If it makes your internet go faster, it can be very appealing. 

There's also Gemini/Gopher, for the extremely lightweight web, and believe it or not, I already started looking for ways to combine the two (with QUIC). Part of having a very experimental mentality is wanting to mix two completely unrelated things that were never envisioned together. Even TLS and UDP weren't really intended together, but that's how QUIC works. 

In theory, one doesn't need QUIC for smolnet, or a lightweight Gemini network. But if one had to surf a lot of websites to find something, or if someone wanted their website to be indexed...perhaps there might be use for QUIC on Gemini?

Chromium has a library for Quic: https://github.com/devsisters/libquic 

It was forked over 10 years ago, with over 288 forks:

"This repository is sources and dependencies extracted from Chromium's QUIC Implementation with a few modifications and patches to minimize dependencies needed to build QUIC library."

And it has only has one dependency on BoringSSL? Seems lite.

Is it possible that the original maintainers are working on a fork? Because there hasn't been a commit in that long. There is a browser called LaGrange that lets you browse Gemini: https://gmi.skyjake.fi/lagrange/ and other less known protocols.

I have used it, and think it's really calm. Now my Hugo site seems less important, but it's not. Developing a blog is still important, because I rust if I don't stay active.

You could call this detoxing from heavy social media, but it's more like "lite-toxing.' The terminology isn't great, but I don't want to sugarcoat it either. Some amount of digital computing is ok, but spending many, many hours daily isn't super healthy. Balance is needed.  Despite all this, or in spite of all this, I looked for an alternative mail client. Yes, I have used mail clients before (Thunderbird and Seamonkey)- around 2005-2011. Eventually I got sick of the POP duplicates and switched to IMAP briefly, only to return to webmail because I didn't want to have too many copies of emails when I was already cluttered with an internet connection (that doesn't sound exactly logical, nor does this paranthetical aside). But I returned finally to a desktop based client.

Initially I downloaded Sylpheed, because it was only ~7MB. But then I saw Claws, which had support for OAuth2, which would be helpful if I wanted to set up Gmail IMAP. But that took too long, and didn't seem fun after spending a half a day on the Google Developer Cloud platform trying to create a token.

I've heard & seen Claws before because, like Sylpheed, they are included in the hundreds of linux distros I've tested. So familiarity and reliability is important. Liteweight is also one of the main reasons I've looked for one, and at 37MB, Claws is not super large either. If it was over 50MB, I probably wouldn't use it. 

Fortunately, I already set up another email address, one that supports IMAP and POP3 with another provider. And I finally set one up- with POP3. I still use Gmail, and Proton, but Proton requires a Premium subscription and a Bridge "app" to allow IMAP/POP. So I skipped that too.

I now have a desktop app that lets me download email without needing to fire up a Chrome/Firefox browser with 16 pistons (or virtual threads, or whatever it expands onto/into).

This should be spring cleaning, but I was late to that, or technically it's been spring cleaning that's been happening very slowly over the course of several months. I think it's working, because relying on web apps for everything can be very, very weird. Maybe it's because I've been using cloud services for so long that offline apps have been neglected and it's becoming weirder (in a bad way) to ignore them than not.

The third client I recommend, and only because I'm using Windows at the moment, is Github Desktop. If I was using Ubuntu/Mint, and I might again soon, I would recommend Forjero, because it sounds cool. But I've been using the weblogin for Github for over 5 years (for the most part- occasionally I used the desktop version). But since I'm testing out a slower internet connection, I am starting to appreciate a desktop client for repositories (yes, I know there's a Git too, but I tend to edit files in the explorer and then push them back to Github). So do I really need the Git standalone? Not yet, but I have it installed anyways.

Someone else recommended Kristall instead of LaGrange, but it requires a new link to Microsoft 2010 C++ Distributable (9.8MB, if you're using Windows) since the one on their website is an old or broken link. I haven't tried it out yet.

If one is downsizing or putting their digital life on a diet, I can't think of much else other than simply using less. But if you have a smartphone or desktop with a lot of programs/apps installed, it's probably best to uninstall unused ones, even if you have plenty of space left. There's a lot of clutter in the desktop and it's easy to forget tasks when there's a bunch of icons on the actual wallpaper. Make a New Folder, and put all the shortcuts in there. Never Save to Desktop unless it's a really important file, because setting that as the default is a bad habit. Yes, I've done that before.

So the list is: 

1. LaGrange (for browsing and exploring, not for knowing where you will visit next)

2. Claws Email Client (and an alternative email service)

3. Github Desktop

4. I did use Chrome 148 to write this post, because it was already installed on my PC, and it would have taken more than a couple hours to download on a 128Kbps connection, so while I can't recommend it for lightweight use, it does actually use QUIC for Gmail and Youtube, and a lot of sites still depend on it (like banking). I do wonder how much faster modern browsers are because of some of these neat tricks, or whether it's just the horsepower of the machine that is sometimes doing the heavy lifting (using a 2013 era i7 with 8 threads).

One desktop client alternative to YouTube (an alternative also to their own desktop app) that I found really impressive was GTK Pipe Viewer - it can stream Youtube directly to a desktop app, typically on linux. On a lightweight machine, it is a godsend (I tested it on an Atom N450 with eXe Linux a few years back- buffering only from bandwidth, rather than performance). But you could also just use a different video sharing website, like PeerTube.

5. Any federated instance, made for desktop. Avoid Electron based (if you can), as they are heavier:

"Finding truly lightweight, native desktop apps for Mastodon on Windows can be tricky, as many are resource-heavy Electron ports. The most performant native and lightweight clients include: [1]

Top Lightweight Windows Clients

• Dowstodon: A modern, native client specifically built for Windows 10 and 11 using WinUI 3. It is highly optimized and provides a clean, native, and lightweight experience. You can get it directly on the Microsoft Store. [1, 2]
• Whalebird: Built as an Electron app, it is specifically designed to consume fewer resources while maintaining a multi-column, Slack-like interface. It’s highly efficient and includes great keyboard shortcuts. Download it from the Whalebird GitHub Releases. [1, 2, 3]
• Sengi: While it is also based on Electron, its interface focuses on displaying a single column at a time, making it very responsive and perfect for keeping on the edge of your screen. You can download the desktop version from the Sengi GitHub Releases. [1]

The Best "Lightweight" Alternative (PWA)

Because many standalone desktop apps act as web wrappers, many users prefer using Mastodon's built-in web client as a Progressive Web App (PWA). It is faster than heavy apps, requires zero extra downloads, and runs in a separate window. [1, 2, 3, 4]

How to set it up:

1. Open your preferred browser (like Chrome or Edge) and log into your Mastodon instance.
2. Click the Install or App Available icon (typically located on the right side of the URL bar).
3. The instance will now run as a lightweight, independent app on your Windows desktop. [1, 2, 3, 4]"

I also found Telephant: https://github.com/muesli/telephant 61.8MB. Sort of small?

I was searching for lightweight microblogging clients as early as 1999, when I used gAIM, Pidgin, mIRC, and Trillian for XMPP and AIM alternatives. One of the lightest apps I've used was Turpial, which was a Twitter and Identi.ca client in 2010, before the API keys became overpriced. 

So a lot of these new clients are just slightly more glazed over ham meat. Tusky probably has a bit more ivory (it's Android only), but who needs that when you can just use an IRC, or bulletin board? I kid. 

I will try out Telephant, Sengi (again) or a Go-To-Social Server (to host and to use). And maybe one of these Electron-based Akkoma clients. Update: Fedistar is only 13MB and supports MacOS, linux & Windows.

The Sierpiński triangle ideal of Internet bandwidth for applications

 I've had this want for a while, but I haven't been able to put it in words because I have not found a good metaphor for what I am trying to accomplish. While newer fiber optic internet and 5G carriers have been able to deliver magnitudes more bandwidth, a lingering problem for speed issues concerns gaps in service, and how to maintain optimum connectivity when bandwidth is intermittent or slows to a crawl, for whatever reason. For example, when internet is throttled to just 128kbps, one can implement a data saver mode on smartphones to limit background services and notifications. But there isn't really an easy or quick way to check ALL the services, nor toggle them all without spending an hour in the settings. It took me around 2 weeks to get accustomed to some of the finer-grained controls on my Android phone, in not only enabling Data Saver mode, which I have used for years in certain instances, but the permission levels and amount of times apps will "ping home" (a server somewhere). To do that, it's best to disable unused or lightly used apps altogether. You can check how much data certain apps use, as there is a Settings page which will show you how many MB or KB were used in the past 7 days or so. That may or may not be representative of more typical months, but you may be able to get a ballpark idea of what's using much of your bandwidth, and on 128Kbps, every byte counts.

A few days ago, I downloaded Hugo. It took me several tries, because I realized I couldn't browse other websites while it was downloading. The chances of it interrupting the download was too high. But even then, I still had interruptions. Eventually I got it. Then yesterday, I wanted to download the Go language. Similar issue. I thought there might be some congestion, because I couldn't figure out why it was running at 25-50% of the speed it should be capable of. I was only getting 32-64KBps. Hugo and Go were both around 60MB, so in ideal conditions they would only take an hour to download. For people who develop websites, 128Kbps is not really going to be useful or practical, especially if there's a lof other apps one needs to download. Today I started downloading Git (even though I should have an older copy somewhere), and ran into the same issue. It's only running at 1.6-3.2KB/s. On Windows, it might say there's more data downloading, although typically it's an average. With only one device connected to the hotspot, it's possible the website is throttling, or more likely, the network is running only at 1/2 speed.

The increasing size of websites is not a new problem. A 2015 talk was given on it, and it had been observed many years before that too. So I thought, what if there was a way to dynamically control how much data is being sent AND requested whenever network conditions change? There would need to be several components working in tandem, and I can count at least 3. For example on the client side, an application will actively monitor the bandwidth, and adjust the amount of data being requested. the network card can optionally forward this information to both the host and the client, or it can be counted locally (often a network monitor does this). The host could also slow down the speed, or extend the time to renew, so that the connection doesn't get permanently terminated. Of course, with dynamic conditions, it might not always sync with what the other side is seeing, and thus the counter would need to update quite rapidly, so that there isn't late requests for slow connections when a hiccup already passed.

One metaphor that I think best help visualize it is the Sierpiński triangle:

six magnitudes of triangle sizes

This metaphor may make more sense if you grew up with 5 magnitudes slower internet. In the 90's my first modem was a 14.4K dial up modem on a Pentium 100MHz PC. That translates into 1.8KB/s in ideal internet conditions- if the server was actually able to provide the maximum speed that you were requesting. Often times it would fall under 1024 bytes and one wouldn't see "KB/s" but "bytes per second." Yes, that slow. But I don't care about that. What I care about is that apps can be designed to be smart enough to not fail completely and become utterly useless, or worse, need to restart their download and waste even more bandwidth because they cannot save every packet that arrived. Each packet in a torrent should have instructions on how to recompile it. I think it involves a checksum but more secure files might even use some other technique to ensure it hasn't been tampered with by some malicious file sharerer. So the question I would ask a search engine, but haven't gotten around to finding the long explanation, is how do modern browsers manage a typical download whenever it briefly gets interrupted? Do they websites provide header files and offer agreements with CDNs and browsers on how they can go about that? Or is the non-technical user left completely clueless on what's actually going on behind the scenes? Packet reassembly isn't rocket science, but I won't trivialize it either. There should be an intelligent way that respects the user and developers time by showing them everything under the lid if they really want to check. "Inspect: elements is more about browser page loads than files themselves, and I would rather use a different program altogether if I don't need the browser. Tranmission is a linux client that I've used for torrenting, but I would like something that's lightweight that is browser-like, without the full stack of the browser. Kind of like a package manager - Synaptic or Software Manager in Linux, but one that actually shows you how much data was downloaded, the source (IP addresses) of where they all came from, and an optional log with granular data on when and what packets were downloaded from where throughout the entire downloaded. Yes, that might sound like a lot, except when you're wasting data, it wastes more users times.

There might only be a handful of apps that one needs to develop websites. Sometimes ordering a CD,  DVD, or USB stick with all the programs preinstalled might be faster than downloading them one by one. This was far more common in the 90s and 00s than it is today, but I learned or was reminded a lot of some great practices that were lost by today's 5G and fiber optic instant gratification era.There was even an article years back that calculated the internet speed of ordering a DVD or blu-ray by mail, and even when counting the days of a typical USPS delivery (5-7 days in worst case scenario), was still on average, faster and more data transferred than something like dialup interent. Because with 128Kbps, that's only 57MB an hour, and 1.38GB a day (if you can manage a connection for 24hrs). So by that logic, ordering a blu ray from a nearby state might only be 2-3 days to deliver, and one would receive over 25GB of data. So downloading a preinstalled ISO with Python, Git, Github Desktop, GNU Utils, Go, Hugo, and all these other apps needed to create a website wouldn't be needed, even though it might save a little time in installing them. It's far better to have a DVD of typical tools like that. I know a lot of linux distros offer lite (headless), desktop OS versions with minimal apps (such as Raspberry Pi OS), and full desktop OSes with tens of applications installed (KDE once offered a 4.7GB ISO like that, and probably still do).

In the early 00's my internet speed at university was a T1- we would routinely get Megabytes of internet in the dorm rooms. At home, we got our first DSL line, which was 1.5Mbps, but some areas offered up to 6Mbps on VDSL. I never got that speed, but 160KB/s was basically the max I had for SEVERAL years, until 2013, when I needed faster internet for work. Suddenly I got 60Mbps, which was 12MB/s, although eventually I saved a bit on costs by downgrading to 3Mbps. A 1.5MBps DSL upgrade from a 14.4K modem is more than a 100x increase in speed. I've had cable internet at speeds up to 400Mbps because DOCSIS 3.0 modems can go that fast. With fiber, I've had 100Mbps but the routers are provisioned up to 10Gbps- if I want to pay that much. In a matter of 30 years, the computers I've used went from 14.4k to 1.5Mbps to 400Mbps internet on less than $60/month. If you count the current speed I've used recently, that's nearly a 10,000x speed improvement: 14.4Kbps to 100Mbps. 

What hasn't improved though, is a parallel accessibility ramp that can dynamically scale between these two extremes. A given smartphone today *might* be able to dynamically hide how it limits bandwidth to make things seem fast when the connection is clearly not, but technical users want to see how that actually happens. It's unclear why Gmail on Android seems to run fast even on 128Kbps when on a desktop browser it seems to take 5 minutes even while saving cookies and website content. The browser should have all the elements it needs to recreate the site and only download the *new* emails. So why does it take so long? Hint: it's not the hotspot. It's that all these programs are not designed to seamlessly load a page as if it remembers everything it downloaded right before the browser was closed. There is still a lot of browser data that is being fetched on a desktop and mobile browser, and a lot of it is VERY heavy.

Some people might think that advances in data centers and cell phone towers in the next few decades will make this a non-issue. In developed countries, most people can find a relatively data provident internet plan at home or even on mobile, and some aren't too fussy about paying over $50 a month for that. But that also takes a lot of things for granted, and I don't think it's good to be complacent on thinking that someone will fix this in other places. No one will fix it, unless it's an actual thing people talk about. And there are few people who actually make this their job, outside of people who test software to make sure it runs in "normal" conditions. 

So when you see a triangle, it represents scalability. But it doesn't have to mean a data center scalability, where virtual machines all run 256MB of RAM and require a minimum of a 3Mbps internet connection so that they don't terminate an anemic dial up connection. 

No, that's not the scalability I'm referring to. It should be an infrastructure that is aware of 5 or so magnitudes of internet speeds- 14Kbps, 128Kbps, 1.5Mbps, 15Mbps, 150MBps and so on. So that the connection doesn't crap out whenever it sees a brief dip in internet speed. A delta of 3 or even 4 magnitudes shouldn't even alert the server that the speed needs more time. Everything is fine! Did a dog think otherwise? In a burning house?

So I downloade Hugo, but I also found a custom version that someone designed for blogs that allows the pages to be smaller than 10KB! Because I am not a savage, and I think Javascript should be a modern comfort. I don't want to deny it to others. What I care more about is the size of the website, rather than what components it uses. And a 10KB website loads in less than 1 second on a 128Kbps connection. Too small to matter. A 100KB webpage (a more typical Hugo site), would require 7 seconds to load on a 128KBps connection. Long enough to start wondering about the internet speed.

It only took me 90 minutes to download Go language. On average, it was around 15KB/s, or 120Kbps. A 59 megabyte file, I was able to download one of the main components to developing a website alongside Hugo and Git. Will I need more apps? Most likely. But for now, I was able to accomplish it all (or mostly all) on a very lightweight connection. I would like to compile a DVD with web development apps, because whenever I start a web design, I become surprised with so many other apps that are needed. If one can make a CD with a lightweight desktop that's less than 300MB, but then fill it with web design apps that are less than 350MB, you can create a web developer live image, or better yet, a microSD card that doesn't require much. What distros are best for this? I am not sure, but I prefer package managers that aren't obscure or have been updated in the past year (ones that are no longer maintained become hard to install if the URLS for sudo apt get aren't working, like on older distros).

If I am able to get the blog running, I will post it somewhere other that github pages, since I am trying to learn web publishing on other hosting sites (for the sake of knowing how to host)- My first ftp was in 2006- I seem to have forgotten certain skills. Website accessibility should be scalable. You should be able to do something even when the website isn't fully loaded. Useful application data should load first, and less useful data should load last.  

if you see http://localhost:1313/posts/ in your browser, you have succeeded (with creating a local page- now just need to deploy)!