I'm a Linux sysadmin and I run open source services for free on NixNet.
From Amolith to ~singpolyma/dev
Signed-off-by: Amolith <amolith@secluded.site> --- deploy/tel_inventory.sql | 18 ++++++++++++++++++ revert/tel_inventory.sql | 7 +++++++ sqitch.plan | 2 ++ verify/tel_inventory.sql | 15 +++++++++++++++ 4 files changed, 42 insertions(+) create mode 100644 deploy/tel_inventory.sql create mode 100644 revert/tel_inventory.sql create mode 100644 verify/tel_inventory.sql diff --git a/deploy/tel_inventory.sql b/deploy/tel_inventory.sql new file mode 100644 index 0000000..76fc583 [message trimmed]
From Amolith to ~singpolyma/dev
Signed-off-by: Amolith <amolith@secluded.site> --- The tel column is now a PRIMARY KEY so NOT NULL is no longer necessary there as primary keys are NOT NULL by default. I added indexes for locality, region, and available_after and removed the WHERE clause from the verify script. deploy/tel_inventory.sql | 17 +++++++++++++++++ revert/tel_inventory.sql | 7 +++++++ sqitch.plan | 2 ++ verify/tel_inventory.sql | 15 +++++++++++++++ 4 files changed, 41 insertions(+) create mode 100644 deploy/tel_inventory.sql create mode 100644 revert/tel_inventory.sql [message trimmed]
From Amolith to ~singpolyma/dev
>>+WHERE FALSE; > > why where false? I was referencing other verify schemas and the couple I looked at included WHERE FALSE, but I realise that's not helpful in this situation. I can just remove the WHERE clause in v2.
From Amolith to ~singpolyma/dev
Signed-off-by: Amolith <amolith@secluded.site> --- deploy/tel_inventory.sql | 17 +++++++++++++++++ revert/tel_inventory.sql | 7 +++++++ sqitch.plan | 2 ++ verify/tel_inventory.sql | 16 ++++++++++++++++ 4 files changed, 42 insertions(+) create mode 100644 deploy/tel_inventory.sql create mode 100644 revert/tel_inventory.sql create mode 100644 verify/tel_inventory.sql diff --git a/deploy/tel_inventory.sql b/deploy/tel_inventory.sql new file mode 100644 index 0000000..4a4e5a0 [message trimmed]
From Amolith to ~amolith/libremedia-discuss
> Hi, I created a channel[0] a while back and was planning to publish a > few short, educational videos on Emacs. Would you be so kind and grant > my account the upload feature. I would appreciate it very much :) For the time being, I'm unfortunately going to have to say no; I am actively maintaining the system when I can, but I periodically lose access because the server is physically managed by my co-admin and he periodically just disappears with no warning for months at a time. I don't want anyone to begin relying on LibreMedia only for everything to permanently break for the next six months because my co-admin disappears permanently.
From Amolith to ~bouncepaw/mycorrhiza-devel
Hello o/ I've been messing with Mycorrhiza a bit over the last couple of days and like it a lot! :) One feature I'm missing, though, is an equivalent to MediaWiki's Special:WantedPages page: https://en.wikipedia.org/wiki/Special:WantedPages It's basically just a list of pages that are linked to but don't yet exist. That workflow allows editors to brain dump, link pages as they go, then come back days later to fill in broken links from across the _whole_ wiki without having to look for them.
From Amolith to ~sircmpwn/sr.ht-discuss
> BTW, why are the public keys available publicly? > > I mean, I understand it should be harmless, but I expect that srht > wouldn't expose it just because it's supposed to be harmless: there's > presumably some good reason/usecase to expose it. I personally use the feature in some infrastructure tasks. I can just curl the URL and pipe it to .ssh/authorized_keys and I know all of my active keys will be there. This is especially useful when collaborating with other people; I can just list some usernames in my automation and it will create their users and fetch their keys then periodically refresh them.
From Amolith to ~sircmpwn/free-writers-club
Thank you all for the feedback. I've incorporated some of the suggestions and published the post :) https://secluded.site/pull-vs-push-intentional-notifications/
From Amolith to ~sircmpwn/free-writers-club
Hello all o/ I've drafted a new blog post, but would like some more eyes on it before I publish. Any feedback is welcome :) https://paste.sr.ht/~amolith/a06295a53b2397345c4ecd5f9c4038e3709d3f66 Cheers, Amolith
From Amolith to ~sircmpwn/sr.ht-discuss
Ingo Hoffmann <ingo@hoffmann.cx> writes: > I see where you're coming from. My main concern is that, IMHO, billing should > be more protected/has an extra layer of security. I had the same concern while initially reading the proposal. I checked the billing page and, personally, wouldn't have a huge problem with any of my employees having read-only access to the information here. It shows card type, last four digits, postal code, expiration month, and when you paid how much. If it showed more sensitive information, like more of the card details, I would absolutely want some knob to twist to disable read access. _Ideally_, that page could be hidden from all but a select few people