@prologic@twtxt.net Why does twtxt.net still show my old avatar?

@Codebuzz@www.codebuzz.nl Welcome to the twt’verse 👋

@doesnm@doesnm.p.psf.lt finally someone read my blogpost ;)

@aelaraji@aelaraji.com Thank you, and yes I got more on my websites https://darch.dk/vj/ and https://algorave.dk/videos/

@prologic@twtxt.net it has been around for much longer (worked on Chrome, just recently does on Safari).

@anth@a.9srv.net that doesn’t work because you need encode that URL, like so http://a.9srv.net/tw.txt#:~:text=2024%2D10%2D08-,2024%2D10%2D23T18%3A59%3A49%2D07%3A00

I have muted the user. Everything is back to its peaceful “normality”. LOL.

@doesnm@doesnm.p.psf.lt someone started to follow a “dead” feed. And the feed’s owner is fed up with people following their dead feed, and they have come up with an “innovative” way to fight it.

@prologic huh? looks like someone flooding twtxt

THE LAST HUMAN POST ON THIS FEED IS MORE THAN FOUR YEARS OLD. PERHAPS TWTXT CLIENTS SHOULD THEN FETCH THE FEED VERY RARELY.

According to this it was only published as a specification/standard last year. It’s no wonder 💭

@anth@a.9srv.net I admit I didn’t know about text fragments. How new is this? 🤔

Hm, seems i breaking something in twet code for handling mentions

@sorenpeter ’s webmentions uses this trick: http://darch.dk/mentions-twtxt

For example, this links to the previous post, no crypto needed: http://a.9srv.net/tw.txt#:~:text=2024-10-23T18:59:49-07:00

Huh. I had long forgotten about text fragment URLs. Seems relevant for linking to discussions around linking to individual twtxt posts. https://alfy.blog/2024/10/19/linking-directly-to-web-page-content.html

@aelaraji@aelaraji.com As long as you’re having fun, you’re doing the right thing. 😅 (Kind of. 😂)

@lyse@lyse.isobeef.org Now I feel like an ant. 🐜 (Imagine how ants must feel when they see this! 🤯)

@bender@twtxt.net Consider me stumped! 😅 Yeah, I can imagine this not being super fast. 🥴

@movq@www.uninformativ.de allow me to stump you! Our Oracle team runs scripts, java, and a few others from NFS shares. That has become a true problem when VMs have moved to Azure, and NFS servers remain on premises. NFS doesn’t like latency, especially when laced with high I/O activity.

@prologic@twtxt.net right, but “regular” forks have parents. An edited twt—currently—has none. Edits just create a new branch-less leaf.

I guess crashing the program with a SIGBUS is intentional. Here’s a blog post that describes this exact thing when running binaries off of NFS:

https://rachelbythebay.com/w/2018/03/15/core/

It’s just that this also happens locally nowadays and, thus, much easier and more often (I bet few people run programs via NFS these days). 🫤

Not a fan of this. (Time will tell if I have the energy to discuss this on the Linux kernel mailing list.)

@movq@www.uninformativ.de In our case at work the new behavior can indeed be considered an improvement. systemd would then restart the new version automatically if the old one crashed. Still, crashing in the first place is very uncool. We don’t have a recent enough kernel version, though.

@slashdot@feeds.twtxt.net wut da fuq?! What happened? What da hell was the Australian federal police even doing or asking? da fuq? I didn’t even know Session was based in Australia?! 🇦🇺 Oh my 😱 – I think this is worth enough to raise this with my local Federal MP (Elizabeth Watson Brown). This is nuts. The Australia FP can get bent 🤦‍♂️ I’d like to learn more about wtf happened here, seriously this is unacceptable and an overreach at first glance.

Encrypted Chat App ‘Session’ Leaves Australia After Visit From Police
Session, a small but increasingly popular encrypted messaging app, is moving its operations outside of Australia after the country’s federal law enforcement agency visited an employee’s residence and asked them questions about the app and a particular user. 404 Media reports: Now Session will be maintained by an entity in Switzerland. The mo … ⌘ Read more

@lyse@lyse.isobeef.org Oh man that was very sexy indeed 🤣 The detail! Oh my 😮

Heck yeah, this is some amazing space porn from ESA! https://dlmultimedia.esa.int/download/public/videos/2024/10/023/orig-2410_023_AR_EN.mp4

@asquare@asquare.srht.site No need to apologise 😅 All very good points 👌

@asquare@asquare.srht.site This is absolutely true! 💯 However the natural behavior of editing a post is the same as forking. So from a community perspective, we’re actaully okay with how that works in reality. I think we’re all getting a bit too hung up on “exactness”. One of the things I think we’re finding hard to reconcile is the fine line between a decentralised ecosystem and distributed system.

I want it very much to remain decentralised. That means Content-based addressing makes sense, because you can have integrity about what a Twt Hash means. I don’t really mind if a thread gets forked because the OP was edited, that’s actually how forking works anyway 😅

@prologic@twtxt.net With respect, a client can not identify whether an edit took place. Not unless that same client witnessed both the original twt and the edited one. This won’t be the case if a person you’re following is joining a thread started by people you aren’t following after the first twt of that thread has already been modified. Or if you’re knocked offline by a multi-hour power outage that spans then entire time window between a twt getting uploaded and modified.

In any case, yes Content addressing can break threads when the original content is edited that’s for sure, however we’ve since agreed and realized that technically speaking, we can actually identify from a clients perspective, whether an edit took place.

@asquare@asquare.srht.site Iant yhay what I said? Or did I fat-finger my reply 🤣

@asquare@asquare.srht.site Yeah my UI skillz aren’t so great sorry 🤣

@asquare@asquare.srht.site correct 👌

It’s pretty hard to follow though, with the discussion being spread out over so many threads and with the https://search.twtxt.net UI displaying threads in a way that’s different than how https://twtxt.net does.

I finally figured out that https://search.twtxt.net is not the same as https://twtxt.net/search. The former is open to the general public, unlike the latter which is only for registered users of twtxt.net. Meaning that I finally have some kind of access to an archive of the aforementioned debate.

LMAO!!! The bitreich landing page is hilarious 😂

”… we only store good cake recipes, this complies with the GCPR - General Cookie Protection Ruling“

Alas, I can’t get myself to resist. Interacting with tech and software makes me feel like a kid in a candy shop: “I wanna taste all of it! Find my favorite Lollipop and wonder about where it came from, who made it? How is it possible to turn any kind of mushy juicy fruit into a hard, forever lasting candy in a freaking stick!? Oh, Wait!! Is THAT chocolate over there!!?”

I’m not even supposed to do be doing any of this, I should be making stuff* with Shapes, forms and color instead of poking at software with a stick like a caveman. 😆

*Stuff: Things I make and refuse to call Art, unless I have to in a resume and what not.

@movq@www.uninformativ.de Although my recent breakage/down time was more of a result of human error than it is something to blame on software itself, I do get your point; and will highly probably end up going the same route in the near future. It’s just that in order to south my forever itching curiosity, I have to learn and try some things first.

@movq@www.uninformativ.de My grandpa was very picky about the time and insisted on starting at 15:00 on time. Maybe that’s a Swabian thing, I don’t know.

I guess the question now becomes;

Why does it cause the running process to crash?

Just tried it: It did indeed crash my Wayland session and, since Wayland compositors are sensitive and critical, it froze all input devices. Only way to recover was to SSH into that machine and reboot it. 🤦

Not sure I’m happy with this.

Take this, for example:

https://codeberg.org/dwl/dwl/src/branch/main/Makefile#L64

The install target of a Wayland compositor uses cp to copy the compiled binary to your bin directory. So, as of Linux 6.11, when you recompile this compositor and reinstall it, it will crash your entire Wayland session. 🧟💀🧟

One way to avoid this crash is to use install instead of cp. install calls unlink() before copying the data, thus avoiding this situation entirely. Not all Makefiles do that, though.

It’s intentional:

• https://lwn.net/Articles/982034/
  
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853
  

Matching the behavior of most Unix systems, the Linux kernel has traditionally prevented writes to an executable file that is in use by a process somewhere in the system; that is the source of the “text file busy” message that some readers may have seen. This restriction is intended to prevent unpleasant surprises in running programs. Kernel developers have been phasing out this restriction for a few years, mostly because it does not really protect anything. As of 6.11, the kernel will no longer prevent writes to busy executable files; see this changelog for a lot more details.

Hm.

@movq@www.uninformativ.de Sounds like you’ll be submitting a bug report upstream though at some point when you have time? 🤔

This changed between linux-6.10.10.arch1-1 and linux-6.11.arch1-1 … Don’t have the time now to do a proper bisect. 🫤

@prologic@twtxt.net I haven’t narrowed it down yet. I’m running 6.11.4 at the moment.

@movq@www.uninformativ.de Is this on a particular Kernel version? 🤔

When you try to change a file that’s currently running, it used to say text file busy. Example:

First terminal:

$ cc -Wall -Wextra -o test test.c
$ cp test run
$ ./run

Second terminal:

$ cp test run
cp: cannot create regular file 'run': Text file busy

But on my machines today, it crashes the running program. 🤨 As soon as I run the cp, I get a coredump:

$ ./run
... time passes, I do "cp test run" in a second terminal ...
Bus error (core dumped)

How odd. Another mystery to solve …