ShinTakuya

A lot of those laid off were doing fine financially anyway unless they blew it all on stupid things.

I can see this being useful on public transport where you don't want to bother people while taking notes verbally. It's not all about avoiding connection.

Once you start using subagents to get more done at once and split your work up into parallel subtasks it's very easy to blow through limits.

Usually an "alpha" implies it's at least partially working, even if it's quite buggy.

Going all the way to 100% doesn't automatically damage your battery. It's charging it to 100% all the time, and also operating it at 100% at long periods of time that reduces the lifespan.

I'm sure there's some arithmetic where more accurately charging to 80% instead of 85% wins out over never going to 100% in terms of battery life. Not saying Apple engineers did this, but I wouldn't assume they hadn't.

The reason the comparison is being made is because Jev and Luna 6 have similar levels of accuracy...

That's not one if, it's two big ifs. If you can to it offline. If you can batch. I wouldn't say that's all that common in the use cases Jev sells itself for. You often want the answer now, not "averaged across 20 items in a batch that took 20 times longer".

It's fair to note it, but I wouldn't say "batching solves this" so much as "batching can solve time insensitive use cases".

What if I told you that unless the battery is occasionally charged to 100% to calibrate the readings, the firmware actually can't tell if it's truly charged to 80%?

>The database doesn't sound like it'd be a factor, since the slowdowns are isolated to single nodes handling the area with players

It doesn't sound like it because you haven't been paying attention. By and large, the TiDi slowdowns are because of network IO (i.e. too many players connected to a single node), but the database causes stutters when large numbers of ships are exploded at once.

DB needs to update inventory, skills, implants, and killboards which requires multiple round trips. Moreover, while these round trips to the DB happen, the core processing threads often end up yielding waiting for the SQL Server instance to respond.

But again, I only mentioned it as part of the problem. The core of the issue is definitely Network IO. Someone activates a module or weapon, you need to send that info to 1-10k players as a packet update. That's the source of delays, not processing speed. Rust won't magically speed that up, the network layer is already written in C.

Rewriting it in Rust isn't automatically faster and more importantly Eve's gameplay is constantly being iterated on and Rust has proven to be bad for that.

Moreover, most of Eve's bottleneck isn't single server speed, it's mostly network IO and database queries and latency. The big TiDi skirnishes in particular are slow due to this.

I think it's not out of bounds to expect a company to go a little further to compensate for an issue. A prorated 1 hour refund doesn't reflect the reality that maybe that hour was more important to the customer because it was their only free time in the week. A free week is way too much but a free day sounds appropriate.

Well that would explain why you wouldn't need a git history.

I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).