Praise the code! 🤘

I'm really surprised no one mentioned Terra Invicta!

Basically if the Three Body Problem series was a Grand strategy game.

In terms of grand strategy it is quite grand. So massive and complex that even 100 hours in, I haven't completed a game.

That being said, it's so addicting. I haven't really played any other Sci-Fi games where you can take over multiple countries on Earth, take over other bodies in the solar system, and field space Navy to defend the planet.

It's just my client. Boost for Reddit doesn't appear to show it correctly. It's the opposite though. It just shows the text. Spoiling it for me.

I'm on the Verizon variant of the software - so same version but with an .A1 tacked on.

Edit: Oh, also, Pixel 7 Pro here.

I dunno, my OLED panel has some notable image retention issues - and a screensaver does appear to help in that regard.

Eh, I went back to screen savers due to my use of OLED panels. Better than a static lock-screen image for sure.

Probably not feasible in our case. We sell our DB tech based on the sheer IOPS it's capable of. It already alerts the user if the write-cache is full or the replication cache is backing up too.

The problem is, at full tilt, a 9 node cluster can take on over 1GB/s in new data. This is fine if the customer is writing over old records and doesn't require any new space. It's just that it's more common that Mr. customer added a new microservice and didn't think through how much data it requires. Thus causing rapid increase in DB disk space or IOPs that the cluster wasn't sized for.

We do have another product line in the works (we call it DBaaS) and that can autoscale because it's based on clearly defined service levels and cluster specifications. I don't think that product will have this problem.

It's just these super mega special (read: big, important, fortune 100) companies have requirements that mean they need something more hand-crafted. Otherwise we'd have automated the toil by now.

Thank you for the measured take on this.

You are correct, I don't intend to pressure or cause harm! But I certainly see the results, and it is indeed pressure. As another commenter pointed out, there are many instance admins who work a bit closer to the team on the Matrix chatrooms and that's their preferred method of communication. Now that I know this, I'll let things cool down and join myself. I definitely intend to contribute where I can in the codebase, and I wouldn't dream of escalating to public pressure for smaller concerns.

However, I have a slight, and perhaps pedantic disagreement about making changes. In this case, the request was for not making a change. If it weren't for the fact that the feature was already ripped out it would be as simple as not removing it (or in this case re-working it a bit). I understand that it isn't the current reality, and that it required work to revert - and if not for a ton of spambots, I think It would've been easier to adapt.

Ultimately it will take time to discuss workarounds and help others implement them, and the deadline is ultimately the arrival of the version that drops the older captcha (or was, in this case - it's getting merged back in as we speak - might even be done now). With that reality, I had a sense that this could be an existential problem for the early Threadiverse.

I definitely didn't intend to suggest that the Devs were in any way at fault here. I read the github issues enough to come with the takeaway that a quick (relative to a new feature) reversion to the prior implementation. To me the feedback they were receiving seemed to be "Admins and devs alike are okay moving forward and opinions to the contrary are minimal, let's move forward". It was definitely intended to be a way to communicate using raw numbers (but not harassment). I'd like to think I'm fairly pragmatic in that if it IS working for folks, then that is a contrary opinion, and that it was missing.

Where I definitely failed was my overly emotional messaging. It's certainly not an excuse, but my recent autism diagnosis does at least help explain why I have an extremely strong sense of justice and can sometimes react in ways that are less than productive in some ways.

As for the licensing, I agree! I'm talking to some good friends of mine because I want to take my instance WAY further than most others - goal is a non-profit that answers to Tucsonans and residents of larger Pima county rather than someone not in the community. There's just a lot of features this concept would need that it might diverge so much from the Lemmy vision that it needs to be something new - and hopefully a template for hyper-local social networks that can take on Nextdoor.

Oh! I just remembered something. Isn't there a site that recommends a lemmy instance? Might it make sense that multiple users found your website because they change the recommendation to distribute new users to smaller instances (hourly perhaps)? Does that sort of pattern hold in this case?

I'm confused - that's almost exactly what I said, albeit in a very condensed form.

Once you take a Discretionary bonus and then make it into an incentive (i.e. This year the Christmas bonus must be earned by doing X, Y, Z) and adding stipulations to the bonus that are tied to worker output turns it into a non-discretionary bonus.

Promissory Estoppel is the basis for why non-discretionary bonuses are a category. There is a perceived promise of a bonus that people work for, but then are denied which can cause knock-on effects for the people to whom that bonus is owed. A bonus is discretionary up until the point it's used to get people to work longer or perform better.

Sure the general term is Promissory Estoppel, but that's a much weaker regulatory framework than Pay and Labor laws around non-discretionary bonuses.

If there is something else I'm not understanding here please enlighten me further. If it's not "accurate" I invite you to help me be more accurate.

You won't see me making call to action posts for undelivered features or other small-fry items. I'm a dev, I get it.

But there are always times were vulnerabilities come up and a dev might not otherwise know that it's being exploited. It's one thing to have a feature to fix that vulnerability and get to it as part of your own priority list. It's another when that vulnerability is actively impacting the people using the software - that's when getting vocal about an issue is appropriate to help me alter my priorities, IMO.

Sure, I agree that the current implementation isn't the most robust in stopping all conceivable bots. Heck, it's quite poor as some others have pointed out.

The reality is, though, that it is currently making a difference for many server admins, now, today.

Let's use a convoluted metaphor!

It's as if each lemmy instance has some poorly constructed umbrellas (old captcha). Now a storm has arrived (bot signups) and while the umbrella is indeed leaky, but the umbrella operator is not as wet as they would be without it. Now imagine that these magical, auto-upgrading umbrellas receive an update during this storm that removes the fabric entirely while they work on making a less leaky solution. It would be madness right? It's not about improving on the product, that's desired and good! It's about making sure the old way of doing things is there until the newer solution is delivered and present.

As a user of this "magical umbrella", I'd be scrambling because the sudden removal of a feature that was working (albeit poorly and imperfectly) doesn't exist at all anymore. Good thing I have a MUCH bigger umbrella that I pay $$$ for (cloudflare) to set-up in the meantime. However this huge umbrella is too big, and if I don't cut some holes in it, it'll be to "dark" to function. So not even this solution is perfect.