This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
| Introduction | https://epiktistes.com/introduction |
|---|---|
| GitHub | https://github.com/toddsundsted/ktistec |
| Pronouns | he/him |
| 🌎 | Sector 001 |

@rahul you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do care, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know! (if you are running off "main" then you are probably not affected.)

@jayvii you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know!

i added code to log slow queries in ktistec and it's already paying dividends. most are obviously missing indexes and it's great to fix them, but the latest example—which is missing an index—is querying a table that only has one row (in my single user instance). should that table need an index on that column? i mean, just return that row...
fwiw, a slow query is currently anything that takes longer than 50msec. i wonder if that is tight enough...?


i depend on visual patterns and cues, and i need so so so many colors!

after all these years it still amazes me how often i fat-finger ^X^C and accidentally exit emacs...

getting consistent query performance, for all but the simplest queries, across different versions of sqlite feels like playing wack-a-mole. the best practice seems to be distributing a version of sqlite that's tested and works vs. depending on the system installed version?

one thing ktistec related that i haven't had the time for is working on build and deployment tools. there are a bunch of outstanding requests—and a few PRs—for docker builds, packaged deployments for various hosting environments, etc.
if you're interested in contributing, let me know. you only have to agree to maintain them—i won't be able to.


i went to a show and bought a cd and then had to figure out how to rip it, because that's not a workflow i've used in a while...
my vintage (c2010) macbook pro—one of the last with a cdrom drive—came to the rescue. i haven't touched it in years but thankfully it booted without problem!

buying concert tickets online is just one dark pattern after another...

In our room of requirement we have a 7’ wooden shipping crate. It’s now going to hold a 6’6” mummy that I made for Halloween.

I built the mummy out of chicken wire and 3" strips of gauze and muslin. If I had more time, I'd stain the cloth to age it—not this year!

It's anachronistic but I'm leaving the styrofoam in place just in case I need the crate for its original purpose!

🎃 HAPPY HALLOWEEN 🎃