Recent twts from abucci
In-reply-to » 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.

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.

⤋ Read More

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.

⤋ Read More

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.

⤋ Read More
In-reply-to » is there any way to get the total uptime of all time? not from a reboot to another, but all cumulated? #openbsd

@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!

⤋ Read More