07.06.22
Gemini version available ♊︎Internet Rot (or Web Rot) Will Worsen as a Result of Bloat and Upgrade Treadmills (Short Maintenance/Support Cycles)
Video download link | md5sum 465f3740daf0417989d6c5e2b23e274f
The Web Has a CMS Problem
Creative Commons Attribution-No Derivative Works 4.0
Summary: In order to avoid link rot and in order to fully preserve the past (archives of pages and documents) we’re migrating Tux Machines to a new system, whose development shall start shortly; if it goes well, we might do the same to Techrights
THIS video and article are the first of a likely long series regarding an ongoing journey.
I’ve been making sites for 25 years and I was closely involved in the WordPress project in its early days in 2004. In recent years I — like many others — became concerned about the direction the Web had taken. Future parts of the series might touch on the pertinent problems (there are so many of them).
Technical debt is becoming a major factor, many things become obsolete very fast (causing Internet rot as it’s sometimes called), and I’m trying to keep online (and fully functional) a site that was created in 2004 (more than 18 years ago). It’s not a bunch of “static” HTML files, it uses a database and upgrade routes are notoriously deficient to say the least.
“Technical debt is becoming a major factor, many things become obsolete very fast (causing Internet rot as it’s sometimes called), and I’m trying to keep online (and fully functional) a site that was created in 2004 (more than 18 years ago).”Among the factors to consider we have HTTPS (self-signed certificate), improved speed, lower I/O (burden on the underlying systems), better security, faster backups, and versatile RSS feeds. It would be nice to add Gopher/Gemini support as an optional protocol, but not a must. Techrights has that already.
As if stands at the moment, we’ll craft our own simple and site-specific CMS for Tux Machines, then use some of the same code here in Techrights. That’s part of a process and in later parts we’ll explain why we’re basically rejecting existing content management software/systems. Some is too bloated, some feels like a hobby*, and some does not actually tackle the core issues, such as complexity. We want something that can be managed (and repaired easily when necessary) for 10 or 20 years to come, knowing the Web might not live that long; after 50 years since its birth it’ll probably be some “legacy” protocol already.
“Assuming we start development of our own custom-made solution, changes will be visible in Git and we’ll give status reports.”After a lot of research I intend to do another long video about the state of the Web and software for managing Web sites (I’ve tried a lot in my personal and professional life). I’ve seen and sometimes used/extended/upgraded some really awful software and I saw organisations getting stuck with systems they could no longer support (e.g. Squiz Matrix or django CMS, not to mention Mambo, PHP-Nuke, Zope and many others). Assuming we start development of our own custom-made solution, changes will be visible in Git and we’ll give status reports. The plan is to first try this as a beta subsite of Tux Machines, then consider cases where Techrights can “borrow” the same tools. As of today, we have 14.3K lines of code and we plan to keep new code short, concise and simple. Only this way it’ll stay trivial to maintain/debug. More in the video above. █
_____________
* A lot of “static” or “flat-file” or “headless” stuff uses bloated networks retrieved via untrustworthy sources such as Microsoft/GitHub/NPM, which themselves may perish, in effect dooming dependencies. “Crates”, “containers” and Node/frameworks themselves have become a bloat factor, even if projects that utilise them are fairly small.
ᶃ Gemini Space
This post is also available in 
Content is available under CC-BY-SA