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.
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.
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
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?
- run
sudo tune2fs -l BLOCK_DEVICE | grep 'Filesystem created:'
on a BLOCK_DEVICE whose filesystem was created at 1st machine use
- 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 š«