Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:China (Score 3, Interesting) 31

Is this due to the recent reports of China all in on RISC-V?

It's because RISC-V is currently fragmented. Not the base ISA, but the base ISA isn't enough to build a device, and there are a lot of divergent extensions.

That wasn't a problem when RISC-V was only theoretical, but now that companies are working towards actual devices, having the "common" RISC-V support in the Android Common Kernel was a hindrance, not a help. The expectation is that over the course of a few years the RISC-V Android ecosystem will coalesce and settle on a common set of extensions to the ISA and it will then be possible to standardize the RISC-V support in ACK. Until then, it's better if ACK doesn't have any RISC-V support so chip vendors and OEMs can straightforwardly patch in what they need.

Comment Re:China (Score 1) 31

So that China can't easily deploy Andoid clones on RISC-V if the US decides for a ban on Android software and ARM licences.

That doesn't make sense.

Android devices in China are not Google Play devices (can't be, really, thanks to the Great Firewall), so the device makers are not obligated to use the Android Common Kernel -- or anything else. They're free to take the open source and build whatever they like. Removing RISC-V support from ACK does exactly nothing to hinder their ability to build and deploy RISC-V devices. If they want to stick with Google's kernel for whatever reason, they can simply reapply the patches that were removed. If they want something else, they can do that.

Comment Re:AND IN "NO SHIT, SHERLOCK" NEWS.... (Score 1) 46

They were popular but they were famously bug-ridden and unstable. Nobody misses Windows 95 or XP, btw.

Hell, NT was the first moderately stable OS they had, and that was just because someone had the bright idea to halt new feature development for a period of time and focus on fixing what they already made.

Comment Re:Why would any coal plant invest in carbon captu (Score 1) 147

We could see alternatives developed that come in at lower cost than coal. Isn't that the claim often repeated by solar PV advocates? That coal is dead because solar PV is cheaper?

Yeah, it probably will go that way, but it'll take longer than it should because PV is operating at a significant disadvantage due to coal plants free-riding on the environment. In the language of economists, pollution -- including CO2 -- is an externaity, a cost that is borne by a third party not part of the economic transaction. In this case, the parties in the transaction are the power plant operator and whoever buys their power, and the external third party is everyone else who has to cover the healthcare and climate impact costs of that transaction.

The EPA can't do it, but we really should implement a carbon tax to "internalize" (again, the economic term) the CO2 emission externality, so that whoever is emitting the CO2 has to include that cost in their operations, and of course pass it on to whoever buys it. With a carbon tax, the estimated future cost of climate change would be priced into every carbon-emitting process, creating a level playing field against carbon-reduced or carbon-free processes.

Without that, coal has an enormous built-in advantage. I expect that renewables will eventually win anyway, but it's going to take longer and create greater climate-change impact than necessary.

Ideally, we should also internalize other externalities, such as particulate pollution which increases healthcare costs. Make sure everyone is paying the full and accurate cost of their actions, then let the market optimize the outcome. But, one thing at a time.

Comment Re:Bandwidths is good, but damn is it laggy (Score 1) 61

This ain't gonna work for FPS games... ping times of 25 minutes!

More seriously, I wonder what sort of protocol they're using. I guess they could just use standard protocols, but with a freaking huge ACK window, but it seems more likely they'd use extensive FEC to reduce effective bit errors to extremely low rates, since NAKing and retransmitting corrupted packets would be incredibly slow. Or maybe that's okay. As long as they're only transmitting stored data which can be retransmitted a half hour later if needed, it might be fine to use simple error detection with retries. Dunno. This would be a fascinating problem to solve.

Comment Re:Ah yes, cheap batteries (Score 1) 100

The increase I'm talking about is just in deployed capacity... it's a manufacturing and installation problem, not a technology problem, and it's manufacturing and installation (as well as demand) that is doubling deployed capacity every year, not technological changes. If you want to claim that the current rate of growth is going to stop it's incumbent on you to explain why it will change.

That said, I think you're wrong that the technology is "done". There is lots of very interesting research going on, in both new chemistries and in new manufacturing techniques.

Comment Re:Ah yes, cheap batteries (Score 1) 100

To buffer a single day in the US you need 261x the GLOBAL capacity added in 2023. To effectively electrify society you will at least have to double that again.

Sure. So? 10 years is almost certainly not enough to get us to that capacity, but 20 years is. Like most such things, installed battery capacity is likely following a sigmoid curve, and we're in the exponential phase, with an exponent of around 2. Assuming we didn't level off, 20 years would see global installed capacity increase about 1,000,000X.

Slashdot Top Deals

Pascal is not a high-level language. -- Steven Feiner

Working...