Approval voting would help, but neither party will ever vote in favor of it.

Matrix is the closest replacement, and XMPP can replicate some functionality too.

The information I’ve seen regarding deep discharge life-cycle for sodium ion is that the latest tech is actually extremely good, at least according to this. I don’t see how the lower voltage is a problem, since for grid situations you’ll have step-up transformers anyway, and the batteries can just be hooked up in series to increase the voltage.

They use abundant materials, will be much cheaper than lithium ion, don’t need to be actively cooled, and massively lessen the risk of rupture and fires.

The low density per unit of weight isn’t relevant for grid storage, so they seem pretty ideal.

Sodium batteries require very little rare earths in comparison to lithium batteries.

Sodium electric batteries, like the type that CATL developed? Or do you mean hot molten salt thermal batteries? Because I think the other poster is referring to the first kind.

Ah, that’s unfortunate. As an alternative, I have seen some online games name their bots with a random name generator that’s designed to sound somewhat real, like AnnoyingPidgen or WrecklessRaptor. If the voting account naming system was more like that, it would be easier to notice voting patterns/manipulation while still being anonymous.

Rock’n’roll racing got a pretty solid GBA port, it’s a fantastic little isometric battle racer from the 90’s

Regarding the voting account having no name, does that mean it will be a random string of letters and numbers? I get that it will still be possible to discover vote manipulation or mass downvoting with that, but I suspect it would be more difficult to detect initially or without some deeper analysis, since it’s harder to recognize or remember a random string compared to a human made username.

It’s extremely difficult for me to enjoy most 8-bit games, as there’s very little there to intrigue my tastes. However, there are a few standouts that I still play to this day on an emulator handheld, like H.E.R.O. or Mr. Do!

The good ones generally have a really solid little gameplay loop that’s quick to get into, with tight controls that let you get into a flow-state easily, and a difficulty curve that isn’t infuriating (something far too common from that era). The story heavy games from that era usually had mediocre or terrible writing paired with repetitive grinding gameplay, so the classics like Final Fantasy are sadly off limits for me.

H.E.R.O. is one of my favorites since it has somewhat uncommon gameplay where you control a man with a helicopter pack in a mine, avoiding various hazards to rescue a trapped miner at the end of each level. It rewards memorization, which is a knock against it, but even though I’ve played it heavily, I keep coming back to it as I never can quite remember the layouts of the later levels, and once control of the backpack is mastered, it just feels good to zip around all of these creatures and caverns of instant death without nicking yourself. I’m not sure how someone who has never played it before would feel about it, since it can take a while to get the hang of the controls, but I think it holds up pretty well from that era.

It also received a pretty massive number of ports to various consoles and home computers. The original Atari 2600 version is good, but personally I found the MSX port to be the most polished, and it adds some nice additional graphics as well.

What I saw over there was a large portion of his community pleading with him to delegate administrative tasks to the community, as it became increasingly clear the website was becoming too much for a single guy to manage (he was the only moderator of like 30+ communities that were full to bursting with spam, as well as the sole site admin). He never approved the many applications to help moderate, and said he was extremely slow to trust others, so never appointed a second admin, and instead just continued to silently work on the codebase as the site became unusable from spam.

I think his extreme distrust and desire to do everything himself combined with his medical issues led to extreme burnout, and ultimately its downfall.

The Eternity Dev has returned, and released a new update for it. Last I checked the update hasn’t released on f-droid due to the build failing, but it is available on aurora or play store.

There should be a tl:DW in the comments here.

Oh damn, even better than the estimates I found.

Ladybird is in a prime position if they keep up their steady progress, I really hope they succeed.

PNG is a lossless format, and hence results in fairly large file sized compared to compressed formats, so they’re solving different issues.

JPEG XL is capable of being either lossy or lossless, so it sorta replaces both JPEG and PNG

JPEG XL supports lossless compression with a roughly 35% reduction in file size compared to PNG.

That’s a good argument, and as a fan of permacomputing and reducing e-waste, I must admit I’m fairly swayed by it.

However, are you sure JPEG XL decode/encode is more computationally heavy than JPEG to where it would struggle on older hardware? This measurement seems to show that it’s quite comparable to standard JPEG, unless I’m misunderstanding something (and I very well might be).

That wouldn’t help the people stuck on an outdated browser (older, unsupported phones?), but for those who can change their OS, like older PC’s, a modern Linux distro with an updated browser would still allow that old hardware to decode JPEG XL’s fairly well, I would hope.

The video actually references that comic at the end.

But I don’t see how that applies in your example, since both JPEG and JPEG XL existing in parallel doesn’t really have any downsides, it’d just be nice to have the newer option available. The thrust of the video is that Google is kneecapping JPEG XL in favor of their own format, which is not backwards compatible with JPEG in any capacity. So we’re getting a brand new format either way, but a monopoly is forcing a worse format.

Existing browsers and apps can’t render jpegXL without adding a new decoder.

Why is that a negative?

Jpeg XL isn’t backwards compatible with existing JPEG renderers. If it was, it’d be a winner.

According to the video, and this article, JPEG XL is backwards compatible with JPEG.

But I’m not sure if that’s all that necessary. JPEG XL was designed to be a full, long term replacement to JPEG. Old JPEG’s compression is very lossy, while JPEG XL, with the same amount of computational power, speed, and size, outclasses it entirely. PNG is lossless, and thus is not comparable since the file size is so much larger.

JPEG XL, at least from what I’m seeing, does appear to be the best full replacement for JPEG (and it’s not like they can’t co-exist).