This week, we talked about the Embedded Online Conference and our experience learning Zephyr.
Listen to episode 475: https://embedded.fm/episodes/475.
We also talked about writing vs reading code.
Here's Chris' take:
it's so strange that despite being fairly tired (after a 3h train trip today) i'm... not in acute pain? even at the trough of the painkiller concentration? (i am not actually confused) how is this possible?? is this real??? did someone substitute the universe around me with a fake one that's inexplicably better????
#STS and adjacent people, I'm looking for reading recs on scifi + "capital S monolithic Science" as religion/pseudoreligion
not looking for the actual historical ties between religious institutions and research disciplines (tho I won't be mad if you share those too)
looking more for stuff like... how we went from early scifi tales and allegories at a time when many disciplines and methods where only starting out, to the rampant Scientism and TESCREALism of today... how that's played into technocracy and modulated colonial narratives and education and actual R&D initiatives and etc...
there's tons of individual connections to make between religious narratives and contemporary scifi-treated-as-reality, like general AI as both gods and eschatological prophecy. interested in that sort of thing too
For context: A lot of R API stuff got marked as "non API" or "internal", which then precipitates a lot of new NOTEs for established packages.
See for example the CRAN check page for {rlang}: https://cran.r-project.org/web/checks/check_results_rlang.html
Lots of packages are using SETLENGTH() (for example) - should it be part of the public API since people need it to write packages?
Some days ago, the CRAN check with R-devel started to raise "Found non-API calls to R" NOTE. I'm not sure if they are serious on disallowing these not-so-minor APIs, but what should I do? Do you take some action or just wait? #stats
For example, rlang package now has these NOTE:
File ‘rlang/libs/rlang.so’:
Found non-API calls to R: ‘R_ClosureExpr’, ‘R_PromiseExpr’,
‘SETLENGTH’, ‘SET_ENCLOS’, ‘SET_ENVFLAGS’, ‘SET_TRUELENGTH’
https://cran.r-project.org/web/checks/check_results_rlang.html
I really do miss Swiftkey which was superior in almost every way, but I'd rather use subpar software than live in fear of more Microsoft "AI" features being turned on one day without me knowing it
I think that with a combination of debouncing how frequently the reading server requests from the OP server, and only asking tetiary (replier) servers for new posts off the results from the context
request that it isn't any more of a DoS problem than normal masto operation. Recall that masto is already pretty dang inefficient (eg. if you expand a post, masto will already fetch the profile, which includes fetching pinned posts, preview cards for all links in bio and pinned posts, etc.), and expanding the context of a post would be a directly triggered behavior that matches i think normal expectations: when i look for the replies to that post, i should see the replies to that post. This would tie into any existing privacy controls - a 'followers only' reply wouldn't be reported in the response from the OP -> reading server, the reading server would have to abide by AUTHORIZED_FETCH
, blocks would still hold, etc.
The costs of not having fetch all replies are pretty bad - first is that fedi can feel vacant on smaller servers. it takes actually quite a lot of people with quite a lot of follows to start having anything resembling a conversation among ppl more then 1-deep in a social graph. One of the primary criticisms of the fedi (mastodon specifically) is the high number of reply guys, and if you have ever had a post with even a moderate amount of popularity you are aware how exhausting it is to get exactly the same reply over and over again, as well as pointing well-intentioned people to information/replies/etc. that already exist elsewhere in the replies.
I'll stop there, but I think that the benefits of having fetch all replies pretty strongly outweigh the costs, and so that's why i want to do it efficiently. This is an especially important behavior if we want to get to a point of making the fedi p2p, where we can make sparse state updates more of the norm <3
@spoltier no exactly! Like it's relevant and real based on your experience but I'M CRAWLING UP A WINDOW HERE
Final coffee thought for this morning is this image popped into my head while someone was giving me unasked for advice and now you must be subjected to it:
imagine I am climbing up the outside of a skyscraper mission impossible style with all kinds of wild gear I made for myself and from inside the skyscraper on the other side of the windows, which they can't perceive, people yell advice based on their experience of navigating to the top by pressing elevator buttons
As you were
I made a new Mastodon bot, called "I Hope This Email Finds You.” Twice a day it proposes a novel way to conclude that sentence. (It uses phrases from Google Books that include the phrase “finds you.”) I've been having fun reading these, so I turned it into a bot because you, too, might have fun reading them. https://botsin.space/@thisemailfindsyou/112295528875440987
I hope you find this toot... at all
https://botsin.space/@thisemailfindsyou/112295448756810404
Hear me out:
Cross-posting is killing the challenger social media platforms.
Why? Well, when I visit [whatever-trying-to-grow-platform], 80% of the content I see is stuff I've already seen elsewhere. Sometimes several times already. It makes it unsustainable to use more than one platform, and if people get pushed to choose a single platform - well, it's going to be the biggest one.
🕵️🔎🔎📱 The “repackaged” EU Council version of #chatcontrol still includes #MassSurveillance & serious threats to #encryption. Fortunately 🇩🇪🇵🇱🇫🇷🇦🇹🇳🇱🇪🇪🇫🇮 have acknowledged the severe concerns. We call on EU Member States to reject this dangerous position.
https://epicenter.works/content/open-letter-eu-councils-chatcontrol-is-still-mass-surveillance-undermining-encryption
We've released #PuTTY version 0.81. This is a SECURITY UPDATE, fixing a #vulnerability in ECDSA signing for #SSH.
If you've used a 521-bit ECDSA key (ecdsa-sha2-nistp521) with any previous version of PuTTY, consider it compromised! Generate a new key pair, and remove the old public key from authorized_keys files.
Other key types are not affected, even other sizes of ECDSA. In particular, Ed25519 is fine.
This vulnerability has id CVE-2024-31497. Full information is at https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html
code / data wrangler in Switzerland.
Compulsive reply guy. Posts random photos once in a while.