I'm working on adding Sega 32X support to BlastEm [0], the Genesis/Mega Drive (as well as some related Sega systems these days) emulator. I've gotten most games working on this point, though still have some bugs to track down. Also want to increase timing accuracy (even if its not needed for games, it's helpful for homebrew development) and improve perfomance.
Yeah, with some effort it's possible (or at least it was) to extract the ROM from the Steam release and play it on the real hardware. They went to a fair bit of trouble to prevent that though. ROM isn't even stored in the clear in-memory while it's running. I guess they wanted to make sure they didn't cannibalize the cartridge release
I'm not sure it's even a particularly relevant comparison to an hour of use of various other electronic devices. I'm sure the median user is running a lot fewer queries than a Claude Code power-user, but I would guess it's still more than one in a typical session.
As someone with a self-hosted Mercurial instance dealing with this, I will say that the big names (OpenAI included, but not exclusively them) generally at least use proper user-agents and respect robots.txt, but they are still needlessly aggressive compared to traditional search indexers.
There are also scrapers that are hiding behind normal browser user agents. When I looked at IP ranges, at least some of them seemed to be coming from data centers in China.
Nothing stopping you from encoding h264 at a low frame rate like 5 or 10 fps. In webRTC, you can actually specify how you want to handle low bitrate situations with degredationPreference. If set to maintain-resolution, it will prefer sacrificing frame rate.
> They shared the polling code in the article. It doesn't request another jpeg until the previous one finishes downloading.
You're right, I don't know how I managed to skip over that.
> UDP is not necessary to write a loop.
True, but this doesn't really have anything to do with using JPEG either. They basically implemented a primitive form of rate control by only allowing a single frame to be in flight at once. It was easier for them to do that using JPEG because they (to their own admission) seem to have limited control over their encode pipeline.
You probably won't get acceptable latency this way since you have no control over buffer sizes on all the boxes between you and the receiver. Buffer bloat is a real problem. That said, yeah if you're getting 30-45 seconds behind at 40 Mbps you've probably got a fair bit of sender-side buffering happening.
> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect.
This would make sense... if they were using UDP, but they are using TCP. All the JPEGs they send will get there eventually (unless the connection drops). JPEG does not fix your buffering and congestion control problems. What presumably happened here is the way they implemented their JPEG screenshots, they have some mechanism that minimizes the number of frames that are in-flight. This is not some inherent property of JPEG though.
> And the size! A 70% quality JPEG of a 1080p desktop is like 100-150KB. A single H.264 keyframe is 200-500KB. We’re sending LESS data per frame AND getting better reliability.
h.264 has better coding efficiency than JPEG. For a given target size, you should be able to get better quality from an h.264 IDR frame than a JPEG. There is no fixed size to an IDR frame.
Ultimately, the problem here is a lack of bandwidth estimation (apart from the sort of binary "good network"/"cafe mode" thing they ultimately implemented). To be fair, this is difficult to do and being stuck with TCP makes it a bit more difficult. Still, you can do an initial bandwidth probe and then look for increasing transmission latency as a sign that the network is congested. Back off your bitrate (and if needed reduce frame rate to maintain sufficient quality) until transmission latency starts to decrease again.
WebRTC will do this for you if you can use it, which actually suggests a different solution to this problem: use websockets for dumb corporate network firewall rules and just use WebRTC everything else
FWIW, they still seem to have not actually pulled the trigger on the account requirement and they've removed the "Starting soon" portion of the nag bar text in the Hue app (though it's still on the web page you get to when hitting "Learn more"). I do wish they would either get it over with or make it clear they're not actually going ahead with forcing accounts though.
> This is not how nuclear works. Nuclear sets a low price that corresponds to its cost, then lets more expensive marginal energy sources set the final price.
This may be an accurate description for fully-depreciated nuclear plants, but it doesn't reflect the economics of new-build nuclear at all. You have to consider both operating and capital costs. Nuclear plants are cheap to operate once built, but those operations have to pay off the capital costs. If the load factor is low, then each unit of generated power has to bear a higher portion of the capital costs. If your capital costs are very high, then you either need a very high load factor or very high spot prices to bear those costs.
> Nuclear can by the way be modulated +20%\-20%
Net demand on CAISO can go from about 2 MW to 30 MW in the summer. 20 MW of that ramp occurs over just 3 hours. I'm sure you can build nuclear plants that ramp that fast, but you need a lot more than the range you're mentioning here. Regardless, I'm not making an argument about the physics of nuclear power plants, just the economics. Expensive plants generally need high load factors to pay off the capital costs.
> nuclear generation in France can go from 25GW to 45GW during a day.
Most of France's nuclear plants are old and thus fully depreciated. The only one built recently (Flamanville Unit 3), is a good example of the bad cost trend in nuclear. While this was a bit cheaper than Vogtle Units 3 and 4 in the US on a dollars per nameplate capacity basis, at 19 billion euro it's still very expensive (and also way over budget).
France also has high rates of curtailment, which is not necessarily a huge problem for them since so much of their generation is already carbon-free, but it does suggest they're already hitting the limits of their ability to ramp production up and down. Whether this is an engineering problem or something to do with the structure of their electricity market is a bit unclear to me
> New small modular reactors promise great improvements, as they can be pre-built in factories, require limited maintenance, lower risk, and as a result much lower cost per MW.
This has been the promise for years, but so far the low costs have yet to materialize and they are estimated to have a higher LCOE than traditional plants. Currently only 2 are actually operational, a demonstration plant in China and a floating power plant using adapted ice-breaker reactors in Russia. There are a few more in the pipeline, but they are all at least a couple years out from actually producing power.
You totally can do it with some combination of overbuilding, storage and increased interconnection. It just starts to get expensive the higher the portion of your generation you want to supply with renewables. There's a good Construction Physics article[0] about this (though it simplifies by only looking at solar, batteries and natural gas plants and mostly does not distinguish between peaker and more baseload oriented combined cycle plants).
Personally, while I'm not opposed to nuclear, I'm pretty bearish on it. Most places are seeing nuclear get more expensive and not less. Meanwhile solar and batteries are getting cheaper. There's also the issue that nuclear reactors are generally most economical when operating with very high load factors (i.e. baseload generation) because they have high capital costs, but low fuel costs. Renewables make the net-demand curve (demand - renewable generation) very lumpy which generally favors dispatchable (peaker plants, batteries, etc.) generation over baseload.
Now a lot of what makes nuclear expensive (especially in the US) is some combination of regulatory posture and lack of experience (we build these very infrequently). We will also eventually hit a limit on how cheap solar and batteries can get. So it's definitely possible current trends will not hold, but current trends are not favorable. Currently the cheapest way to add incremental zero-carbon energy is solar + batteries. By the time you deploy enough that nuclear starts getting competitive on an LCOE basis, solar and batteries will probably have gotten cheaper and nuclear might have gotten more expensive.
I have a 2017 Bolt as my only car and the slow L3 charging is definitely a downside, but I haven't found it to be a huge issue in practice. On a trip long enough to worry about fast-charging you're going to need to stop to eat periodically anyway so if you plan your charging around meals you don't end up waiting too long. Obviously gets a bit more annoying on trips that are long enough to require more than one fast-charge per-day, but I don't take trips that long frequently.
Day to day charging is generally all going to be L2 or even L1 depending on how far you drive and how long typically parked somewhere with a plug. That will be roughly the same speed in any car. Some cars do have higher capacity L2 chargers than the Bolt does, but most public L2 stations don't provide the higher current needed to see the difference.
If you compare it to the commuter rail systems in those places, BART feels impressive (though less so with the service cuts). I was a regular rider on the Metro North New Haven line and had experience with SEPTA and NJT commuter rail and I was really impressed with BART when I moved out here. Peak frequency was pretty good (at least on the Red line I primarily used) and when things were on time they were very on-time ("on-time" Metro North trains were always at least a few minutes late in my experience).
If you compare it to the NYC subway, it's obviously not impressive at all (though the tech is less dated). As a rapid-transit system, BART isn't exactly a commuter rail or subway system exactly, but I think it's closer to the former than the latter.
If you like the PDP11 instruction set, then you'll probably enjoy 68000 as well. It drew a lot of inspiration from the former. You lose the "deferred" addressing modes (though the 68020 adds something similar), but gain access to a few other useful ones. Conveniently it was used in a lot of consumer devices (Mac, Amiga, Sega Genesis, etc.)
Yeah. If you want to teach someone to implement a CPU, then the sort of simplicity the 6502 brings to the table is useful, but it's definitely not the most straightforward CPU to write code for.
The 68000 instruction set is very C-like (probably because it draws a lot of inspiration from the PDP-11 which was C's first target). Implementing it sucks (I know from experience) because the ISA is on the large side and all the little pragmatic exceptions add up. But because these exceptions are fairly pragmatic, they're not really a big issue when writing code.