@prologic thank you!

I have two emails left in my inbox. Should I push for inbox zero?

@prologic I mean I guess that would be nice but don’t go out of your way to add one

@awesome-scala-weekly@feeds.twtxt.net scala will never die 🤘

GoTo security breach update confirms hackers stole customer backups - The Verge

Wowowowowow, an encryption key for user data was stolen, too. What the hell kind of clown show is LastPass running over there? If you use that thing get out now!

William Lawvere, a mathematician who I’ve always been inspired by, passed away on January 23rd. RIP.

One approach to this problem that does work is to have a large stable of maintainers, which reduces the probability that all maintainers go absent simultaneously. Most projects don’t have that, though.

So it would seem that having a way of transferring control of a project from absent maintainers to aspiring active maintainers would be very nice to have. You don’t want that control to pass into the hands of some arbitrary person. But, let’s say there are people who are not currently maintainers issuing pull requests; and there are users submitting issues. You could imagine a mechanism whereby the pull request issuers can be “promoted” by community consent, where the community is the people submitting issues and other pull requests, plus anyone else who wants to be involved perhaps.

There are obviously dangers, but I don’t think they are meaningfully different from the dangers that already exist in the github model of software development. Maybe I’ve overlooked something important though.

I was musing today about how to solve the problem of projects going stale on github. It really is an annoying problem if you depend on a project where the main maintainers go absent without passing the project on to someone else. The project becomes trapped and dead. Usually (and rightfully), only the maintainers can push releases that can be used by a wider community. But that means if you’re depending on a ruby gem or an npm package or a java jar or any other build artifact on an official channel, you’re out luck because the release artifacts are no longer updated once the maintainers go absent. People can submit pull requests, but with no maintainers to accept them, the source code goes stale too. Though you can grab the pull release(s), the merge process often requires project-specific knowledge that has gone absent with the maintainers.

@prologic I don’t know…… by crawling? 🤔

@prologic oh, that’s how it works? Interesting.

I ordered some Euroscrubbies awhile back and they finally showed up yesterday. I don’t usually get excited about cleaning products but damn, these things are great.

@bender
Currently
Not
Exactly
Truthful

CNET’s AI Journalist Appears to Have Committed Extensive Plagiarism

First, the site was caught quietly publishing the machine learning-generated stories in the first place. Then the AI-generated content was found to be riddled with factual errors. Now, CNET’s AI also appears to have been a serial plagiarist — of actual humans’ work

Is it just me or is this stuff getting worse at an accelerating pace?

come on guys someone has to acknowledge my stupid joke!! https://www.youtube.com/watch?v=v2AC41dglnM

@Yarns@search.twtxt.net but you already existed!

@prologic no way!!! I’m Thunderstruck by this news @mckinley

UnifiedPush

I think UnifiedPush is coming along nicely, but I wonder why they don’t talk about IOS. The Conversations XMPP app for Android can now function as a UnifiedPush distributor, which is very cool–that means that any app that supports UnifiedPush can send notifications to you via XMPP instead of using Google’s proprietary spyware crap.

@obsidian-roundup@feeds.twtxt.net Come on.

Thanks @bender@twtxt.net, the README describes how to use the systemd service file, @eldersnake@we.loveprivacy.club

@eldersnake@we.loveprivacy.club I put an example yarnd.service unit
on the yarn git awhile back if you use systemd. It could use some work but a variation of that one is controlling my own pod well enough.

@prologic 🤷‍♂️

@prologic nothing wrong with that, but to believe it should be a coauthor of a science paper? What are people smoking?! 🚬

@prx@si3t.ch I was curious about this too, and here’s what I found for Linux. I’d suppose there are equivalents in OpenBSD?

1. run sudo tune2fs -l BLOCK_DEVICE | grep 'Filesystem created:' on a BLOCK_DEVICE whose filesystem was created at 1st machine use
   
2. run smartctl -a BLOCK_DEVICE | grep Power_On_Hours to check the total power-on hours of some BLOCK_DEVICE that’s been up since the machine’s 1st use
   

Obviously these both depend on having a block device (disk drive usu) whose life span is close to the machine’s total uptime. There are utilities like tuptime in Linux, which I think are also compileable on OpenBSD, that you can install when you first start up a machine to keep this cumulative uptime but that doesn’t help after the fact unless you solve time travel!

@bender You’re probably right about that.

@bender I write too much here 🫠