981 karma · joined October 27, 2011
https://www.retrodev.com/
Much harder to justify in a world with normal car EVs with decent range at fairly normal car prices. There are a fair number of choices below their $40K target price. I still hope they succeed, but hard for me to imagine buying one
The only state that requires a motorcycle endorsement for the Polaris Slingshot (an "autocycle" style trike) is Massachusetts, but that state's motorcycle definition exempts fully enclosed vehicles so it shouldn't apply to the Aptera. It's trickier to find a quick summary for helmet laws though. At least some states have exemptions for fully enclosed vehicles and some exempt all autocycles even if they're not fully enclosed. California has an exemption for enclosed trikes that meet certain minimum size and weight requirements which I expect the Aptera to meet.
The details remind me more of the Bluesky PDS though. It's nodejs-based and the only officially supported way to run it is via a largely self-contained docker container.
> Good thing is, this is actual Linux (And not uCLinux) so there's still stuff that can be disabled further if for some reason it can't fit still on the available memory.
Doesn't actual Linux require an MMU?
* Word RAM can be swapped between the 68Ks, or can be operated in a split mode where each 68K gets half. There's no mechanism to allow both 68K's to access the same bank simultaneously though.
[0] - See this Spritesmind forum thread https://web.archive.org/web/20190209161834/http://gendev.spr... (Internet Archive link because the live site is mostly unusable due to the scraper deluge)
On the MD2, they added audio output pins to the expansion port in addition to the existing audio input pins. This allows them to achieve the same effect with no mixing cable.
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.
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.
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
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.
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.
[0] https://www.construction-physics.com/p/can-we-afford-large-s...
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 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.
What it did not have was memory protection or virtual memory. You do need an MMU for those.
If we compare to the propulsive landing campaign for the Falcon 9 1st stage it's a bit more favorable. The first 8 attempts had 4 failures, 3 controlled splashdowns (no landing planned) and 1 success. I think in general it felt like they were making progress on all of these though. Similarly for the Falcon 1 launches they had 3 consecutive failures before their first success, but launch 2 did much better than launch 1. Launch 3 was a bit of a setback, but had a novel failure mode (residual first stage thrust resulted in collision after stage separation).
Starship Block 2 has had 4 consecutive failures that seem to be on some level about keeping the propellant where it's supposed to be with the first 2 failures happening roughly in the same part of the flight and this 4th one happening during pre-launch testing.