Garden with sunflowers in the backgroundMore scenery: https://lyse.isobeef.org/waldspaziergang-2024-08-25/
Neither of us has ever seen such a marmelade bun mushroom:
Marmelade bun in the woods, ah, no, it's a mushroom
GET /twt/<HASH> with Accept: application/json:
$ curl -sH 'Accept: application/json' https://twtxt.net/twt/fgthxaq | jq
{
"twter": {
"nick": "prologic",
"uri": "https://twtxt.net/user/prologic/twtxt.txt",
"avatar": "https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q"
},
"text": "(#tkjafka) @<falsifian https://www.falsifian.org/twtxt.txt> @<movq https://www.uninformativ.de/twtxt.txt> You actually only really want the missing root Twt. You could just fetch this from any Yarn pod. There are scripts I built way back when yo do this 😅",
"created": "2024-08-23T00:54:04Z",
"markdownText": "(#tkjafka) [@falsifian](https://www.falsifian.org/twtxt.txt#falsifian) [@movq](https://www.uninformativ.de/twtxt.txt#movq) You actually only really want the missing root Twt. You could just fetch this from any Yarn pod. There are scripts I built way back when yo do this 😅",
"hash": "fgthxaq",
"tags": [
"tkjafka"
],
"subject": "(#tkjafka)",
"mentions": [
"@<falsifian https://www.falsifian.org/twtxt.txt>",
"@<movq https://www.uninformativ.de/twtxt.txt>"
],
"links": []
}
> […] Putting mentions before the hash is still supported but discouraged. […]
> \n Putting mentions before the hash is still supported but discouraged. \n
https://staystrong.run/user/bmallred/twtxt.txt returned 200 but no Last-Modified header - can’t cache content :-)Another modification I made is to actually cache it anyways. Otherwise,
tt wouldn't show anything. I implemented that for some other feed that doesn't exist anymore.
twtxt client by buckket to actually fetch and fill the cache. I think one of of the patches played around with the error reporting. This way, any problems with fetching or parsing feeds show up immediately. Once I think, I've seen enough errors, I unsubscribe.tt is just a viewer into the cache. The read statuses are stored in a separate database file.It also happened a few times, that I thought some feed was permanently dead and removed it from my list. But then, others mentioned it, so I resubscribed.
Getting to this view felt suprisingly difficult, though. I always expected my feeds I follow in the "Feeds" tab. You won't believe how many times I clicked on "Feeds" yesterday evening. :-D Adding at least a link to my following list on the "Feeds" page would help my learning resistence. But that's something different.
Also, turns out that "My Feeds" is the list of feeds that I author myself, not the ones I have subscribed to. The naming is alright, I can see that it makes sense. It just was an initial surprise that came up.
ErrDeadFeed is never actually checked anywhere. It's only set and that's it.
410 and Gone did not reveal anything. Maybe, maybe it is handled by another library. But I kinda doubt it.
The right™ way is to signal 410 Gone if the feed does not exist anymore and will not come back to life again. But that's hard to come by in the wild. Somebody has to manually configure that in almost all situations.
But yes, as @falsifian points out, exponential backoff looks like a good strategy. Probably even report a failure to users somehow, so they can check and potentially unsubscribe.
And aren't there any other hosted yarnd instances? Maybe it was never really implemented, but I remember @prologic thought about hosting dedicated yarnds for others in the past. Could be well over a year ago, not sure.
Another possibility might be a forgotten development instance idling around (or not so much :-D) in the background. I think the default user agent points to txtxt.net, not example.com. At least when I last checked the yarnd code. That was also several months ago.
@movq It's very yummy. :-) Unfortunately, the mustard manifacturer changed the traditional slip-on caps to screw caps. Haven't seen the old jars anymore.
Jelly in drinking glass The rest is cooling off on the bench outside.
I consequently make use of the UTF-8 encoding and state that in each end every one of the HTML files. This keeps me from surprises later on. The web server in the end is configured to automatically include the
Content-Type header with the right character encoding (super easy as it is always UTF-8) in the response, so this is very bullet-proof in my mind.My editor simply does not auto-"correct" anything. This almost never works in my experience. Especially when dealing with computer languages.
Oh I bet, nearly getting hit by lightning is very frightening.
Fighting kestrelsMore peaceful before that: https://lyse.isobeef.org/turmfalke-2024-08-07/
When I woke up at 5am, I had a quick look in the Northern sky and saw a tiny shooting star. I then happily went back to bed. :-)
tt, I have to press r to toggle the read status for each and every message. The disadvantage is that I have to mark all messages read explicitly, the advantage is that I have to mark all read explicitly, and hence no silly automation messes with me and causes wild surprises. But in theory it would be possible to automatically mark a message read when it is selected for three seconds or something like that. Not sure, though, how well any of that would work with a web UI.
Again, I could completely misunderstand the use case here. But assuming it's not connected to the internet, since you just have HTML and plain text files on the USB stick, no PHP or other stuff that needs to be interpreted first, you could just view these files locally in any browser (via local
file:// protocol) without the web server (via http(s)://) in between. Much simpler.
All sky covered in clouds, except to the East. No chance of witnessing the stars shooting around. Still 25°C. Bah.
But I'm wondering how you discovered it a week later. Are you somehow regularly checking complete recent feed histories?
-eq is for numerical comparation only. Weird error message, though. Tells something about the implementation.
libapache2-mod-php* if you want to make use of PHP.Typically, systemd will automatically start your webserver during system startup. Your package manager (
apt) does not prompt you, because the package maintainer has chosen some defaults for you which works with the rest of the system. So there is simply no need. Why would you want to change the installation directory anyways?Also, right after installation, I'd assume that Apache2 is automatically started. If you want to start Apache2 by hand, you can
sudo systemctl start apache2, there are also the stop and restart verbs.The tutorial linked by @prologic seems a bit outdated to me (old Ubuntu version and SysVInit), you might be better off with: https://ubuntu.com/server/docs/how-to-install-apache2 Even though, that's probably also not so beginner-friendly.
Oh boy, the week is already over and I haven't accomplished much useful stuff when I look back on it. Gotta check the vacation calendars of my workmates tomorrow and take one or the other week off soon.
apt-get install apache2 Its configuration file is probably _/etc/apache2_/apache2.conf_ these days. https://ubuntu.com/server/docs/how-to-install-apache2_
Yeah, like with everything, quality has its price.
I'm wondering, what's the reason behind the carpet for the chickens? To help with cleanup?
Wheat just tastes good. I'm a sucker for bread. But not limited to wheat only, the majority sure is, though.
With the summer on full blast here, it's funny to read about frost. I'd immediately trade your weather. :-D
@movq LOL²!
make test. I will look into that.
hunter2!!
It happens to each bracketed text individually: https://lyse.isobeef.org/tmp/bracketed-text/triple.png
But then the question still is, why on earth does it happen to old twts, too? I'm getting into my code excavator.
make dev. After registering a user and logging in, I then entered a twt with double bracketed text (without the equal sign on the second one, though) and it was expanded into eight brackets. So, this is clearly a bug. Let me dig deeper.I hope I zoomed in enough, so you can read the stuff on my screenshot: https://lyse.isobeef.org/tmp/bracketed-text/bug.png
However, since this all relates to bracketed text, I do not find an attack of some sort very likely. It's probably just a bug somewhere.
I just set up a cronjob to fetch and analyze both feeds every six hours. I probably have to do some dedup, otherwise the list gets out of handy rather quickly.
How do the feeds look on disk? Do they already contain this bracketed text?
For reference, I just placed a copy of the feed here: https://lyse.isobeef.org/tmp/bracketed-text/bender-2024-08-04-10-34.txt
I haven't marked the changed twts by @mckinley as read last time, so I don't know if something changed there as well. In any case, current snapshot: https://lyse.isobeef.org/tmp/bracketed-text/mckinley-2024-08-04-10-39.txt
Yarnd gossipping might be the reason for the truncated stuff, @prologic. Who are your peers? Any obvious broken yarnd version or even some kind of an attacker involved? But there must be something else broken in yarnd for the bracketed text to be duplicated.
Haha, yeah. I also thought a few times that such a utility would be handy. :-)
Last time, it was @bender's feed that showed me new weird twts in my client. I don't remember the details, but I'm pretty sure it was this week. Refetching his feed a couple of times (across multiple days) and I got new messages.
And it just happened again, this time with @mckinley's feed. This twt from 2023-01-09T22:42:37Z here newly popped up, it contains magic bracketed text:
> \n I'll bet we could find that information and put "\n\n\n\n\n\n\n\n" in the title for premieres and remove it when the video is available.
Currently, its hash is
puxvjcq. There is no sign of evidence that this twt existed ever before. Maybe I'm doing something wrong. But https://twtxt.net/twt/puxvjcq 404s and the search engine also just gives me "error loading twt from archive" (quite a generic error message): https://search.twtxt.net/twt/puxvjcqJust open https://twtxt.net/user/mckinley/twtxt.txt and search for
][Scheduled or =][ to find even more. This also reveals some "\n\n" stuff. Is that maybe coming from Clownflare?In https://twtxt.net/user/bender/twtxt.txt it felt to me that the bracketed text from 2024-03-28T18:34:36Z always got duplicated each time it changed for whatever reason: "\n\n" etc.
mckinley and bender, do you recall actually typing that out or somehow updating your feeds on yarnd? Or am I just doing something wrong here? But the fact, that my browser shows the same stuff, I'm pretty sure it's not my client, that's messing things up here.
Any idea, @prologic?
Last time, it was @bender's feed that showed me new weird twts in my client. I don't remember the details, but I'm pretty sure it was this week. Refetching his feed a couple of times (across multiple days) and I got new messages.
And it just happened again, this time with @mckinley's feed. This twt from 2023-01-09T22:42:37Z here newly popped up, it contains magic bracketed text:
> […] I'll bet we could find that information and put "[Scheduled][Scheduled][Scheduled][Scheduled][Scheduled][Scheduled][Scheduled][Scheduled]" in the title for premieres and remove it when the video is available.
Currently, its hash is
puxvjcq. There is no sign of evidence that this twt existed ever before. Maybe I'm doing something wrong. But https://twtxt.net/twt/puxvjcq 404s and the search engine also just gives me "error loading twt from archive" (quite a generic error message): https://search.twtxt.net/twt/puxvjcqJust open https://twtxt.net/user/mckinley/twtxt.txt and search for
][Scheduled or =][ to find even more. This also reveals some "[email protected][email protected]" stuff. Is that maybe coming from Clownflare?In https://twtxt.net/user/bender/twtxt.txt it felt to me that the bracketed text from 2024-03-28T18:34:36Z always got duplicated each time it changed for whatever reason: "[162.159.205.11][162.159.205.11]" etc.
mckinley and bender, do you recall actually typing that out or somehow updating your feeds on yarnd? Or am I just doing something wrong here? But the fact, that my browser shows the same stuff, I'm pretty sure it's not my client, that's messing things up here.
Any idea, @prologic?
Last time, it was @bender's feed that showed me new weird twts in my client. I don't remember the details, but I'm pretty sure it was this week. Refetching his feed a couple of times (across multiple days) and I got new messages.
And it just happened again, this time with @mckinley's feed. This twt from 2023-01-09T22:42:37Z here newly popped up, it contains magic bracketed text:
> […] I'll bet we could find that information and put "[Scheduled]\n[Scheduled]\n[Scheduled]\n[Scheduled]\n" in the title for premieres and remove it when the video is available.
Currently, its hash is
puxvjcq. There is no sign of evidence that this twt existed ever before. Maybe I'm doing something wrong. But https://twtxt.net/twt/puxvjcq 404s and the search engine also just gives me "error loading twt from archive" (quite a generic error message): https://search.twtxt.net/twt/puxvjcqJust open https://twtxt.net/user/mckinley/twtxt.txt and search for
][Scheduled or =][ to find even more. This also reveals some "[email protected]\n" stuff. Is that maybe coming from Clownflare?In https://twtxt.net/user/bender/twtxt.txt it felt to me that the bracketed text from 2024-03-28T18:34:36Z always got duplicated each time it changed for whatever reason: "[162.159.205.11]\n" etc.
mckinley and bender, do you recall actually typing that out or somehow updating your feeds on yarnd? Or am I just doing something wrong here? But the fact, that my browser shows the same stuff, I'm pretty sure it's not my client, that's messing things up here.
Any idea, @prologic?
Last time, it was @bender's feed that showed me new weird twts in my client. I don't remember the details, but I'm pretty sure it was this week. Refetching his feed a couple of times (across multiple days) and I got new messages.
And it just happened again, this time with @mckinley's feed. This twt from 2023-01-09T22:42:37Z here newly popped up, it contains magic bracketed text:
> […] I'll bet we could find that information and put "[Scheduled][Scheduled=][Scheduled][Scheduled=][Scheduled][Scheduled=][Scheduled][Scheduled=]" in the title for premieres and remove it when the video is available.
Currently, its hash is
puxvjcq. There is no sign of evidence that this twt existed ever before. Maybe I'm doing something wrong. But https://twtxt.net/twt/puxvjcq 404s and the search engine also just gives me "error loading twt from archive" (quite a generic error message): https://search.twtxt.net/twt/puxvjcqJust open https://twtxt.net/user/mckinley/twtxt.txt and search for
][Scheduled or =][ to find even more. This also reveals some "[email protected][email protected=]" stuff. Is that maybe coming from Clownflare?In https://twtxt.net/user/bender/twtxt.txt it felt to me that the bracketed text from 2024-03-28T18:34:36Z always got duplicated each time it changed for whatever reason: "[162.159.205.11][162.159.205.11=]" etc.
mckinley and bender, do you recall actually typing that out or somehow updating your feeds on yarnd? Or am I just doing something wrong here? But the fact, that my browser shows the same stuff, I'm pretty sure it's not my client, that's messing things up here.
Any idea, @prologic?
After 3-4 hours, I unclamped it and handplaned it to its final shape, so it can become the last rung of my "ladder" for the laundry shelf. Yeah, I'm still on that project over half a year later. You can call me a really lazy ass. ;-)
When I was about to round over the long edges with my handplane, the bananas suddenly came apart. Both ends still held, so I had some kind of an "O". The glue had not fully set yet. It was still a tiny bit moist in the inside. I scraped off the leftovers with a chisel. To increase my odds the second time, I roughed up the surfaces with 40 grit sandpaper and a rasp, so that the glue has something to bite into. Didn't do that the first time. I reckon that majorly contributed to the fail, because the boards were fairly smooth, maybe even coated with something, who knows. Any kind of finish is bad for glueing.
Now, I'm also using a few more clamps and let it sit over night. Well, two days in fact, since I cannot bang around tomorrow. Unfortunately, I can't finish this frame/ladder today. But maybe on Monday.
Usually, I let wood glue set at least over night, even though a couple of hours should™ suffice I'm told. I will definitely go back to that regular setting period. Especially when mechanical forces are working against me and there is stress in the wood. Never can go wrong with a longer waiting time. I have always had good experience with this in the past. In fact, whenver the wood glue failed on me, it was either removing the clamps too early or a sloppy glueing surface preparation. Or both. ;-)