Searching We.Love.Privacy.Club

Twts matching #writing
Sort by: Newest, Oldest, Most Relevant
In-reply-to » @kat I've almost fixed this btw 🤗 Just testing it thoroughly and polihsing the code. In case you're curious, I do this style of development called "Observability Driven Development" (ODD) whereby I make observations of the system via metrics and internal observations and adjust the system's overall behavior to the desired outcome 😅

@lyse@lyse.isobeef.org Well you are being slightly rude 🤪 Sure you could write unit tests for this, but in practise testing emergent properties and behaviors of a system is actually a lot harder than you might realize. But I’m happy to always be proven wrong 😑

⤋ Read More

OSle: a tiny boot sector operating system
OSle is an incredibly small operating system, coming in at only 510 bytes, so it fits entirely into a boot sector. It runs in real-mode, and is written in assembly. Despite the small size, it has a shell, a read and write file system, process management, and more. It even has its own tiny SDK and some pre-built programs. The code’s available under the MIT license. ⌘ Read more

⤋ Read More

If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

Instead of

(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a>) hello foo bar

you would have

(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a> http://foo.com/tw.txt) hello foo bar

or maybe even:

(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a> 2025-04-30T12:30:31Z http://foo.com/tw.txt) hello foo bar

This would greatly help in reconstructing broken threads, since hashes are obviously unfortunately one-way tickets. The URL/timestamp would not be used for threading, just for discovery of feeds that you don’t already follow.

I don’t insist on including the timestamp, but having some idea which feed we’re talking about would help a lot.

⤋ Read More