@conrad They *just* posted an update that she died earlier this morning. 😥 There are no words.

@kirk @hagridaaron @mdm @giddie @mike @steven @joeld @cedric Pur containers are all proprietary custom-built apps, so there’s really no need to use anything from the store. Cloudfront/ALBs handle TLS termination and URL routing.

@zach @mike Arq Backup (arqbackup.com) plus one (or more) of any number of public cloud storage providers is a pretty compelling solution IMHO.

@giddie @kirk @mdm @hagridaaron @mike @steven @joeld @cedric ...and is very tightly integrated into the rest of their services. At some point of complexity, orgs will run into the bounds of what ECS can offer, and at that time, they'll need to consider k8s, but early on, I wouldn't recommend anything else. I consult with a number of early-stage healthcare tech companies, and have three of them using ECS heavily now, to great effect.

@giddie @kirk @mdm @hagridaaron @mike @steven @joeld @cedric Regarding k8s, I've played with it, and it's indeed impressive, though many orgs jump on the k8s bandwagon far too early. It's a *really* complex piece of software with lots of moving parts that need to be deeply-understood to use them well. I'm actually a really big fan of AWS's ECS orchestration product. It's very simple to get up and running with...

@giddie @kirk @mdm @hagridaaron @mike @steven @joeld @cedric Yeah, I agree with this. Containers aren't a panacea, but if you 1) don't rely on them as a security boundary and 2) don't use them as a VM (don't run more than one "thing" per container), they're a boon to enabling small teams to iterate through the software lifecycle quickly, and in a reliable/validatable fashion.

@mdm @hagridaaron @mike @steven @joeld @rainer @kirk @giddie @cedric That’s positive. I guess in addition to the root concerns, the all-in-one app/db thing isn’t ideal. I’ll play around with it to see how difficult it would be to containerize it. If it’s difficult, then maybe this is the most viable option.

@hagridaaron @mike @steven @joeld @rainer @mdm @kirk @giddie @cedric That said, as much as I’ve hopped on the container bandwagon for apps, my true greybeard self shows through when it comes to databases. At this scale, I generally prefer to not have those in containers, and to rely on OS vendor packages for them.

@mdm @hagridaaron @mike @steven @joeld @rainer @kirk @giddie @cedric I can give it a look. My experience with Marketplace apps isn’t great, due to (depending on restrictions imposed) not being able to get root on the box, difficulties upgrading, or customizing things if needed.

@mike @steven @joeld @rainer @mdm @hagridaaron @kirk @giddie @cedric Mike (and team). Late to the party, here, but I'll throw my hat into the ring as well to help. I design, deploy, and maintain largely F/OSS stacks on AWS for a number of healthcare tech companies, and have done a lot of db/app performance tuning. So, lemme know if you'd like another set of hands in the kitchen.

Current events, news, and privilege 

erik boosted

The most important question. @vishnu 

The most important question. @vishnu 

erik boosted

people should not have to justify their use of a particular theme or settings by disclosing disabilities or whatever, but also it seems that some people can never accept that a light theme option is an accessibility option.

So here are a couple of reasons someone may need a light theme:

astigmatism (can cause hazy text (halation) and visual disturbances looking at light text on dark background)

dyslexia (though a pure white background can be worse, generally black/dark text is helpful)

Show thread
Show more
The Liturgists

This is an instance for folks who follow The Liturgists Podcast, The Alien & The Robot, and other things The Liturgists create.