ben-schaaf

Anyone making this claim just hasn't played a lot of factorio, because this just isn't true. Player feeding is fast in the early game, but it just doesn't scale. There's too many buildings to feed and it takes too long to walk between them. People have already made tool assisted speedruns, and as expected it involves building a huge automated factory as quickly as possible.

You don't need an OLED to get poor text rendering on macOS, that came for free with Mojave when they removed subpixel antialiasing.

I agree it's fine and good that they want to sell this and keep it accessible for individuals, but modifying a CC-NC license and then calling this "open source" is not it.

If everyone followed this model instead of open source, then Corridor Key itself would have to cover dozens of software licenses for all it's dependencies.

The execute stage very much modifies state; in fact it always modifies state. Any non-memory instructions modify registers, and any memory instructions either write to registers or to memory. Even a noop will increment the instruction pointer, so you're always modifying a register regardless.

Reading that code there's a 48-bit counter used for each millisecond, so ~281 quadrillion UUIDs per second.

Not sure the point you're trying to make, it sounds like you're agreeing that dumb TVs should be cheaper than equivalent smart TVs?

Monitors have also gotten incredibly cheap, and there's Sceptre who sell dumb TVs that are pretty cheap. So I don't really buy that they're selling TVs at a loss.

That's why Anthropics C compiler worked so well; because they had gcc's huge repository of tests to lean on. Oh wait...

Quake DOS is from a year earlier to Shadow Warrior and it would get around 60fps at 320x200 on a Pentium II 266. The Xeon from that video is from 2008, and from geekbench 2 results it's ~30 times faster than the pentium. 1600x1200 is 30 times the pixels of 320x200.

Additionally Shadow Warrior used some newer rendering techniques, so it's possible they don't scale well to higher resolutions.

Sources: * https://framebuffer.io/project/quake * https://browser.geekbench.com/geekbench2/327940 * https://browser.geekbench.com/geekbench2/529270

So if you compare a diesel to a petrol-hybrid, and you use the diesel's NEDC rating and compare it to the hybrid's WLTP rating, then number bigger!

Lets make a real comparison: The NEDC combined rating for the 2025 e-POWER is 5.4l/100km (FWD). The 2018 diesel version you linked uses 5.6l/100km, and the petrol 2018 version uses 6.2l/100km.

For a truly fair comparison you could have looked at the non-e-power versions from 2025, which come in at 7.4l/100km.

That's still (usually) the public paying for it. Parking permits are generally hilariously cheap compared to the market value of the land they reserve.

This doesn't ring true. Shit goes wrong all the time, and we put people in the loop to fix things when it does.

Plugins are a frequent culprit of issues like this. Depending on how you're tracking memory usage you may already be able to at least narrow down the culprit by looking at which process is using too much; plugins run on a separate process and may launch additional processes from there.

Unfortunately tracking individual plugin memory usage is not possible without invasive (and slow) tracing. If the plugins are causing big memory usage in the main process it can be hard to nail down due to that state being shared between all plugins.

Most plugins just work in Python 3.14. Python didn't break backwards compatibility that much.

Hard to compare the two programs over a week of uptime. ST memory usage does get larger as caches get filled over time, but I've had uptimes of months without issue. I'd expect similar results from other editors.

Do you have a specific memory issue where it keeps using more over time?

If you compare like for like, ie. take the process node out of the picture, then you need to compare the Ryzen 9000 series to the A16, as both use TSMC's 4NP process.

Thanks, we've got a fix for this in the works.

We put a fair amount of effort into reducing our resource footprint, so I'm curious what you find lacking in our memory management. From a quick test we use a similar amount of memory to Zed.

You'd need to keep the python 3.3 plugin host disabled, but otherwise yes. OpenSSL 1.1 will be removed along with 3.3 in the next development cycle.

Long term prospects for Sublime Text look good. The business is healthy and there is consistent work being done by a small but dedicated team.

As for why specific issues aren't addressed, it's merely a prioritization thing. It's a large task, and I'm sure if you asked 100 people they'd all give you different answers for which "basic usability" thing needs to be addressed.

There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.

The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.

There's reserve tanks or more generally reserve fuel for emergencies. Other than that there's no propulsion backup for when the fuel runs out, instead redundancy comes from multiple independent fuel tanks.

You need to include extra files and enable a flag for EAC to work on Linux. You don't do that by accident.

You also don't advertise that it works on the steam deck by accident.

No, it means Linux. They enabled the easy anti cheat flag to allow running on Linux.

They've stated in their patch notes that they made a change specifically to run on the steam deck. Regardless of what they say now, they have actively supported linux in the past and so should be liable for breaking the game for those customers.

https://www.ubisoft.com/en-gb/game/for-honor/news-updates/6j...

Rust already has this, it's called editions. The tricky part is it needs to stay ABI compatible to be able to link dependencies from other editions.

Neat! Hopefully these new architectures can beat the Pi5, though even that's still far away from Zen 1 let alone Zen 3.

> and even substantially faster than a Pi 5 for multi-core and vector stuff

I'll push back a little on this. It can be faster under certain workloads, but is not universally. It's behind in geekbench https://browser.geekbench.com/v7/cpu/compare/146501?baseline..., and in compilation workloads: https://www.phoronix.com/review/spacemit-k3-pico-itx/3

I've seen this claimed before, and just going by SiFive's specint claims the P870 at 2.6GHz should match Zen 3.

But for SiFive's last silicon, the HiFive Premier P550, they claimed a specint2006 of 8.65/GHz. That should put the silicon only about 20% slower than an intel i5-6400. But if you look at geekbench scores it's about an order of magnitude slower.

Correct me if I'm wrong, but Tenstorrent has yet to ship any of their own cores? They do make very similar claims to SiFive.

Personally I'm very skeptical that these cores will be anywhere near Zen 3. I recon their performance claims are based on best-case CPU simulation, rather than a real measurement. I'd expect Raspberry Pi 4 levels of performance, a bit over double SiFive's current state of the art. An impressive improvement, but nowhere near Zen 3.

Given how appalling the thermal throttling behaviour is on the Neo - sustained workloads can lose up to 50% performance, making it substantially slower than an M1 Air - you should instead be asking for a fan in the Neo.

> How do they implement it?

In firmware.