LLVM Considering An AI Tool Policy, AI Bot For Fixing Build System Breakage Proposed
Last week a request for comments (RFC) was issued around establishing an LLVM AI Tool Use Policy. The proposed policy would allow AI-assisted contributions to be made to this open-source compiler codebase but that there would need to be a “human in the loop” and the contributor versed enough to be able to answer questions during code review. Separately, yesterday a proposal was sent out for creating an AI-assisted fixer bot to hel … ⌘ Read more
New Patches Lay Out Linux Kernel Adjustments For RISC-V RVA23 Hardware
With the first of RISC-V RVA23-compatible hardware expected to be released in 2026, we are beginning to see more Linux developers prepare for this RVA23 profile and the now-mandated extensions. Sent out this week was an initial “request for comments” patch series on RVA23 adjustments for the Linux kernel… ⌘ Read more
AMD Working On Push-Based Load Balancing For Linux To Further Enhance Performance
One of the new Linux engineering initiatives out of AMD is working to further enhance Linux performance on today’s large core count systems by introducing push-based load balancing… ⌘ Read more
I kind of hate conventional commit messages: https://www.conventionalcommits.org/en/v1.0.0/#summary
but I am loving reading RFC 2119: https://www.ietf.org/rfc/rfc2119.txt
HQspinlock Proposal For Linux Shows Very Nice Performance Benefits For Large Servers
A Huawei engineer has sent out patches proposing HQspinlock as a Hierarchical Queued NUMA-aware spinlock for the Linux kernel. HQspinlock aims to addresss inefficiencies within the Linux kernel’s spinlock on modern NUMA-systems due to frequent and costly cross-NUMA cache-line transfers… ⌘ Read more
All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].
After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?
Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.
But that was it. All test green. \o/
Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation
TIL that RFC means Request For Comments
@lyse@lyse.isobeef.org agree on the HTTP stuff. I mean we could mention that for optimization see RFC yadda yadda should be followed for caching. but not have it part of the spec proper.
↳
In-reply-to
»
Trying to wrap my head around webfinger..
⤋ Read More
@prologic@twtxt.net Unfortunately the RFC’s are a bit light in this regard. While it makes mention of different kinds of accounts like mailto: or status services.. it never combines them. It does make mention of using redirects to forward a request to other webfingers to provide additional detail.
I am kinda partial to using salty:acct:me@sour.is, yarn:acct:xuu@txt.sour.is, mailto:me@sour.is that could redirect to a specific service. and a parent account acct:me@sour.is that would reference them in some way. either in properties or aliases.
I’m planning to include “gemini tinylogs” on the twtxt page on Antenna. As soon as I have the time and energy for it. (https://codeberg.org/bacardi55/gemini-tinylog-rfc)
@bml@twtxt.net Yup, several. My favorite is RFC 1149, another that’s since been implemented. https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments
Peter Saint-Andre: RFC 8838: Trickle ICE ⌘ Read more…
@xuu@txt.sour.is Not too happy with WKD’s use of CNAME over SRV for discovery of openpgpkey.. That breaks using SNI pretty quick. I suppose it was setup as a temporary workaround anyhow in the RFC..
RFC-61 — 365 RFCs https://write.as/365-rfcs/rfc-61
Update: scans of early RFCs — 365 RFCs https://write.as/365-rfcs/update-scans-of-early-rfcs
RFC-19 — 365 RFCs https://write.as/365-rfcs/rfc-19
RFC-5 — 365 RFCs https://write.as/365-rfcs/rfc-5
RFC-2 — 365 RFCs https://write.as/365-rfcs/rfc-2
RFC-1 — 365 RFCs https://write.as/365-rfcs/rfc-1
mnot’s blog: How to Read an RFC https://www.mnot.net/blog/2018/07/31/read_rfc
RFC 439 - PARRY encounters the DOCTOR https://tools.ietf.org/html/rfc439
@kas@enotty.dk The only thing stopping me from implementing webmentions by myself is RFC 5988. Crazy stuff…
briefly thinking about using RFC 5147 for message identifiers, e.g. https://buckket.org/twtxt_news.txt#line=2