epchris

While it's running, have you checked docker stats to see how much memory/cou the container is using? What's the host, what're it's total resources and what are you using to run the vm?

Paperless-ng (or ngx, but I don't run that flavor)

I bought an Nvidia Quadro p400 for this purpose on eBay, but I dont ever have more than one stream going so I couldn't say how many it could support

I'm not opposed to operators trying to make money, if some server brings some feature that I find valuable, I won't begrudge them trying to make money off it. I think the hopeful thing with federation is that when one feels that an individual server is being abusive or doesn't like their monetization approach or is unhappy for some other reason they have the choice to go elsewhere. Competition is good.

This is a struggle. I've found it helpful to use skip-level 1:1's to discuss this topic, and make sure my skip level knows ahead of time (and on an ongoing basis) that building this map (and helping to guide others through it) is a priority of mine so they can prepare at their level to provide information that I might be missing.

It's also a great opportunity to provide that same skip-level with the perspective from the engineers in the organization on the "flip side' of that coin. You're facilitating communication and alignment in both directions.

I've been using solargraph with some success in a rather large project. I hear there are other ruby Language Server Protocol implementations but I haven't tried them.

love this approach and it's what I usually use. I also don't rebase after opening a PR (GitHub) because force pushing ruins reviewer context in the GH UI. so after the PR is open I merge main/master in instead of rebasing.

I used emacs for a long time and then switched to vscode for most stuff I work on except Kotlin projects, so I found the new UI much more of a match for what I'm used to and prefer it.

Yeah I agree, but for us this would mean like 30 containers. We've tried several times to have some kind of flexible setup where devs could choose which parts to run, but that got complicated with all the various permutations of the containers and devs needing different setups in different situations.

It just became a lot to try and manage/support

Thanks for all of the suggestions!

Right now our guidance is that each developer is given a namespace and a helm chart to install and the wording is such that developers wouldn't think of it as an ephemeral resource (ie. people have their helm installation up for months, and periodically upgrade it).

It would be nice to have user's do a fresh install each time they "start" working, and have some way to automatically remove helm installations after a time period, but we do have times where it's nice to have a longer-lived env because you'd working within some accumulated state.

Maybe there's something to automatically scaling down workloads on a cadence or after a certain time period, but it would be challenging to figure out the triggers for that.

Others have said it already, but I love my Framework laptop. I have one of the first gen ones, running Ubunut, and I'm looking forward to upgrading it to the new AMD motherboard they're releasing later this year. The fact that they have upgrade paths for their laptops is amazing.