Double congrats, @thecanine@twtxt.net! \o/

I’m not a fan of the gemtext limits. This being only a single page (which probably doesn’t get updated a whole lot), the efforts of having two dedicates files are not all that big, or so I’d at least naively imagine.

I always recommend checking the W3C validator results, even though I’m very guilty of not doing that myself. It just doesn’t occur to me in the heat of the moment. I reckon if I were writing HTML on a more regular basis, I would pick up on making that a real habit. Anyway, your HTML being generated, you probably can’t address the findings, though. So, might not be even worth the time heading over to the validator.

From a privacy point of view, personally, I would definitely host the CSS myself. Other than that, nice link collection. :-)

@prologic@twtxt.net yeah I should probably update. Version 0.15.1@31958f89 2025-06-29T20:35:20+10:00 go1.23.1

Linux Patches Updated For Snapdragon X Elite Powered TUXEDO Elite 14 Gen1 Laptop
In mid-2024, Bavarian PC vendor TUXEDO Computers began teasing a Snapdragon X Elite powered Linux laptop with hopes of having it available by Christmas 2024. As we approach Christmas 2025, there still are no immediate signs of this new ARM-based TUXEDO laptop soon shipping but there are signs of life still with new Linux kernel patches posted for enabling this Snapdragon X Elite laptop… ⌘ Read more

Fwupd 2.0.17 Released With More Hardware Support & Features
Days after the Linux Vendor Firmware Service celebrated 135 million firmware downloads, a new version of the Fwupd utility is now available for firmware updating systems and peripherals under Linux… ⌘ Read more

Linux 6.19 To Support Additional Arm Mali & Vivante Graphics Hardware
Sent out today to DRM-Next was the latest weekly batch of drm-misc-next patches for enhancing the various smaller Direct Rendering Manager drivers within the kernel. Included with this week’s update is supporting some additional Mali and Vivante hardware as well as continuing to enhance the in-kernel accelerator “accel” drivers… ⌘ Read more

Open Container Initiative “OCI” Runtime Spec v1.3 Released With FreeBSD Support
The Open Container Initiative unveiled today the OCI Runtime Specification v1.3 update for this standard around operating system process and application containers. This runtime specification continues to evolve for outlining the configuration, execution environment, and lifecycle of a container. Notable with the v1.3 revision is introducing official FreeBSD support… ⌘ Read more

Cool. I think I’ve improved this abit. Update going out shortly… Also added optional support for displaying gravatar(s) if you supply your email address (optional of course).

GTK2 about to be removed from the official Arch repos: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/2BDHYLEFSYQBDTMUOZT5J6AFTA5M3FO6/

It’ll probably all be dropped to the AUR, so I can build this myself, because I still have some stuff that depends on it (and will never receive further updates).

@dce@hashnix.club Arch is the most stress-free OS I’ve ever run (I last reinstalled it 14 years ago, only rolling updates since then) – but to be honest, I sometimes wonder what role my general choice of software plays. I mostly run minimalistic software or programs that I wrote myself. I guess that greatly reduces the chance of breakage. 🤔

Okay, I give up. The “shopping list” app™ on my phone broke for no reason whatsoever, there wasn’t even an update. I’m going back to pen and paper.

@zvava@twtxt.net It is just completely impossible to make v2 backwards-compatible with v1.

Well, breaking threads on edits is considered a feature by some people. I reckon the only approach to reasonably deal with that property is to carefully review messages before publishing them, thus delaying feed updates. Any typos etc., that have been discovered afterwards, are just left alone. That’s what I and some others do. I only risk editing if the feed has been published very few seconds earlier. More than 20 seconds and I just ignore it. Works alright for the most part.

Global update: Trump in Scotland says EU trade deal has 50-50 chance as tariff row grows. Gaza sees 9 more starvation deaths (122 total); UN says famine is deliberate. Thai-Cambodia clashes kill 16, displace 135k. US raid in Syria kills top ISIS leader & sons.

I have a Python script that transforms the original YouTube channel Atom feed into a more useful Atom feed by removing the spam description and replacing it with the video duration, filtering out videos by title, duration, etc. I just updated it to exclude the damn Shorts garbage more efficiently. Finally, YouTube updated their Atom feed generation, so that the video URL contains /short/ if it’s of this useless kind. Never thought that they ever actually will improve their Atom feeds. Thank you, much appreciated!

In all fairness, GOG says that Forsaken is only supported on Ubuntu 16.04 – not current Arch Linux. If you ask me, this just goes to show that Linux is not a good platform for proprietary binary software.

Is it free software, do you have the source code? Then you’re good to go, things can be patched/updated (that can still be a lot of work). But proprietary binary blobs? Very bad idea.

Speaking of Wine, Arch Linux completely fucked up Wine for me with the latest update.

• 16-bit support is gone.
  
• Performance of 3D games is horrible and unplayable.
  

Arch is shipping a WoW64 build now, which is not yet ready for prime time.

And then I realized that there’s actually only one stable Wine release per year but Arch has been shipping development releases all the time. That’s quite unusual. I’m used to Arch only shipping stable packages … huh.

Hopefully things will improve again. I’m not eager to build Wine from source. I’d rather ditch it and resort to my real Windows XP box for the little (retro)gaming that I do … 🫤

Unless your Terms of use update email looks and reads the same as the one I got yesterday from mastodon.social, I don’t wanna know about it, nor do I agree to it.

Hmmm 🧐 Not what I thought was going on… No bug…

 time="2025-06-14T15:24:25Z" level=info msg="updating feeds for 8 users"
 time="2025-06-14T15:24:25Z" level=info msg="skipping 0 inactive users"
 time="2025-06-14T15:24:25Z" level=info msg="skipping 0 subscribed feeds"
 time="2025-06-14T15:24:25Z" level=info msg="updating 80 sources (stale feeds)"

RIP GitHub https://github.blog/changelog/2025-05-08-updated-rate-limits-for-unauthenticated-requests/

Good thing I left long ago.

@anth@a.9srv.net happy birthday, “youngster!”

Domain Name: NETBROS.COM
Registry Domain ID: 1193243_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.cloudflare.com
Registrar URL: https://www.cloudflare.com
Updated Date: 2025-03-29T04:08:33Z
Creation Date: 1998-04-29T04:00:00Z

After yarnd v0.16 is released and the next round of specification updates are done and dusted, who wants me to have another crack at building Twtxt and activity pub integration support?

I figure Eris is getting and update. A real certificate this time? Time will tell!

Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! – I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social’s 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

Just like we don’t write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

Today I added support for Let’s Encrypt to eris via DNS-01 challenge. Updated the gcore libdns package I wrote for Caddy, Maddy and now Eris. Add support for yarn’s cache to support # type = bot and optionally # retention = N so that feeds like @tiktok@feeds.twtxt.net work like they did before, and… Updated some internal metrics in yarnd to be IMO “better”, with queue depth, queue time and last processing time for feeds.

@bender@twtxt.net Time to update my machines! 😅

@prologic@twtxt.net @bmallred@staystrong.run Ah, I just found this, didn’t see it before:

https://restic.net/#compatibility

So, yeah, they do use semver and, yes, they’re not at 1.0.0 yet, so things might break on the next restic update … but they “promise” to not break things too lightheartedly. Hm, well. 😅 Probably doesn’t make a big difference (they don’t say “don’t use this software until we reach 1.0.0”).

@lyse@lyse.isobeef.org Just needed to update the version of the tool I packaged as an OCI image 🤣

I updated wordwrap.[ch] to more closely match the interface for string(2); it’s now just that plus a margin. I also updated litclock and marquee to match. http://a.9srv.net/src/index.html

Hmm I think I can come up with some kind of heuristic.. Maybe if the feed is requested and hasn’t updated in the last few mins it adds to the queue. So the next time it will be fresh.

if it hasn’t updated in a while so i put the request rate to once a week it will take some time before i see an update if it happens today.

I need to figure out a way to back off requests to feeds that don’t update often.

@andros@twtxt.andros.dev Awesome! I’ve seen the demo earlier on mastodon, things are getting better and better with each update 👌 Good luck!

Ahh yes, what I like to call “wild wild west” upgrading.😂
Felt like that when I upgraded/updated an Arch Linux machine that had been sitting for a couple years unused.

Here’s a twt from @andros@twtxt.andros.dev ’s new version of Twtxt-el 🥳 It feels WAaaaaY better! although it freezes on me as soon as I navigate to the next page complaining about some bad url, but the chronological sorting of the feed as well as the navigation buttons (links?) are a great addition. Looking forward to the next update already! 😁 🥳🥳🥳

@prologic@twtxt.net @lyse@lyse.isobeef.org it seems a recent update reset my pod settings to open registration.

That’s pretty awesome @ ! I’ve seen your contributions to twtxt-el and wondering if you’ve been updating the same one or made another from scratch. either way, I can’t wait to give it a try! 🙌 cheers

I wrote about making Glenda’s Joy Division cover (with updated colors and a link to source): http://a.9srv.net/b/2024-11-23

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

@movq@www.uninformativ.de pretty cool! Switched, and pulled. Nice update on README!

@prologic@twtxt.net I’m not sure what this update does, but

https://twtxt.net/external?uri=https://google.com&nick=lovetocode999

still exhibits the same problem, on your pod and on mine, after the latest update.

@prologic@twtxt.net OK, I just updated to commit 77d527, which looks to be the same one you’re running right now. I forgot to blow away my cache before restarting, so I just deleted the cache file and restarted.

@prologic@twtxt.net What? I compiled, updated, and restarted. If you check what my pod reports, it gives that 7a… SHA. I don’t know what that other screenshot is showing but it seems to be out of date. That was the SHA I was running before this update.

@prologic@twtxt.net This does not seem to fix the problem for me, or I’ve done something wrong. I did the following:

1. Pull the latest version from git (I have commit 7ad848, same as on twtxt.net I believe).
   
2. make build and make install
   
3. Restart yarnd
   
4. Refresh cache in Poderator Settings
   

Yet I still see these bogus /external things on my pod when I hit URLs like the one I sent you recently. When I hit such a URL with curl I think it’s giving an error? But in a web browser, the (buggy) response is the same as it was before I updated.

So, this problem is not fixed for me.

@prologic@twtxt.net Aha, now it gives an error. OK I’m updating to this to see if it fixes the issue on my pod! Thank you.

@prologic@twtxt.net I think there’s more to it than that. I’ve updated, yet hundreds of gigabytes of junk is still accumulating.

@prologic@twtxt.net I’m still getting this crap:

abucci@buc:~/yarnd/yarn$ ls -lh /tmp/yarnd-avatar-*
-rw------- 1 abucci abucci 863M Jul 25 14:19 /tmp/yarnd-avatar-1594499680
-rw------- 1 abucci abucci 7.8G Jul 25 14:19 /tmp/yarnd-avatar-2144295337
-rw------- 1 abucci abucci 9.8G Jul 25 14:19 /tmp/yarnd-avatar-2334738193
-rw------- 1 abucci abucci  10G Jul 25 14:14 /tmp/yarnd-avatar-2494107777
-rw------- 1 abucci abucci 9.5G Jul 25 13:59 /tmp/yarnd-avatar-2619243454
-rw------- 1 abucci abucci  11G Jul 25 14:04 /tmp/yarnd-avatar-2922187513
-rw------- 1 abucci abucci 7.5G Jul 25 14:14 /tmp/yarnd-avatar-349775570
-rw------- 1 abucci abucci  10G Jul 25 14:09 /tmp/yarnd-avatar-3640724243
-rw------- 1 abucci abucci 901M Jul 25 14:19 /tmp/yarnd-avatar-3921595598
-rw------- 1 abucci abucci 9.5G Jul 25 13:59 /tmp/yarnd-avatar-609094539
-rw------- 1 abucci abucci 9.3G Jul 25 14:04 /tmp/yarnd-avatar-755173392
-rw------- 1 abucci abucci 7.9G Jul 25 14:09 /tmp/yarnd-avatar-984061000

Something like 100 Gbytes of this junk has accumulated since I updated and re-started the server. I’m now running the latest version of yarnd, so the update did not fix the problem. Something else is going wrong.

How are temporary files growing to 10 Gbytes in size? The name of the file is “yarn-avatar”, but why would avatars be so large?

@prologic@twtxt.net Aha, got it. Thanks for looking into it. I’m updating now and we’ll see if that stops it.

@New_scientist@feeds.twtxt.net It’s insane that a single botched software update can have worldwide impact. We’ve messed up badly.

So updated. Seems to duplicate here in the ui. And what is this “Read More” on every twt now?

@prologic@twtxt.net Well ain’t that grand? I’ll get it updated.