To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.
Indeed, and it doesn't need to be deprecated, because it's an API explicitly designed to give you low-level control where you need it, and because it is appropriately defined as an `unsafe` function with documented safety invariants that must be manually upheld in order for usage to be memory-safe. The documentation also suggests several other (safe) functions that should be used instead when possible, and provides correct usage examples: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.set... .
The reason is that classical grids are mostly self-correcting. Rotating inertia can stabilize frequency and can produce or absorb reactive power.
"Reactive power" sounds fancy, but it just means that motors can create a drag. The power lines are giant capacitors, and capacitors have the lowest effective resistance when they are discharged. So the current is greatest when the voltage crosses the zero mark. Inductive (rotating) loads are the opposite, their effective resistance is greatest when the current starts to rise or fall. So this limits the initial inrush of the current.
But there's more! When you have a transformer and a long line, you can essentially get a boost converter. The voltage from a transformer travels through a low-resistance wire until it reaches the end, and because the line can be modeled as a series of capacitors, you essentially get a "charge pump" ( https://en.wikipedia.org/wiki/Charge_pump ). From the viewpoint of the generator you have one large capacitor, but from the viewpoint of a consumer in the middle of the line, you have two capacitors in series.
As a result, the voltage in power lines can _spike_ if there's not enough rotating load. This is called Ferranti effect, and in Spain it was the primary reason for the faults.
This is all fixable, but it requires investment and regulation. And Spain (and other countries) have been neglecting that, by incentivizing the cheapest possible generation.
I think the tyre problem is not really a thing. EVs use synchronized motors and traction control to avoid extra wear due to uneven torque during normal driving.
I can't remember if it was here or on reddit, but I read from a tyre shop / mechanic, that some EV users replace their tyres very often, because EV cars make it easy to drive very aggressive.
My understanding is that the torque control speed is much faster though, so it's actually difficult to get the tires to slip. I can't screech my tires in my EV, but it'll do 0-60 ridiculously fast.
Anecdotally, my Kia Niro EV goes through tyres a lot faster than the two equivalent internal combustion vehicles in the family.
That said, the Niro weighs ~50% more than the other vehicles, and it has significantly higher acceleration/braking, so I'd hazard it gets driven harder on average.
Cisco is doing great. Sun got acquired by Oracle. Oracle itself is also fine (apart from it is Oracle). Akamai is doing fine.
From the pure software side, Macromedia got acquired. RedHat was doing fine before IBM gobbled it up. But I honestly can't remember any other "picks and shovels" software companies from pre-dotcom.
The glass-in-the-ground people went spectacularly broke. I also suggest you look up the stock price chart for JDSU. On the software side, Ariba and Commerce One.
Yeah, hardware companies got hit hard. But dotcom also coincided with the de-industrialization era, with manufacturing moving out of the US, with a double whammy of commodization. So it's hard to disentangle the causes.
And then I can't really remember many Internet-focused software pick&shovels companies from that era. I was only starting my professional career at that time, though.
Eh. Just start removing bike lanes. They're destroying businesses and making life worse for everyone.
And yes, I have numbers. In Seattle, the business receipts from areas with bike lanes declined faster than receipts from areas nearby that do NOT have bike lanes.
Correlation shmorellation.... I bet you were going to cite studies that were showing how bike lanes improved the business and how proprietors were surprised at the percentage of customers on bikes, right?
Yep, I have friends who ran small businesses who sold in cities (Seattle, Portland, SF) specifically because of how bike lanes destroyed their business.
People who are busy need to get around quickly and aren’t going to tolerate biking around. And it’s especially impractical with kids - not that this stops bike activists from trying to gaslight everyone into saying it’s totally possible and exactly the same effort. The bikes lanes almost always either displace traffic lanes or parking, so driving gets worse. And customers realize they have better things to do and alternative choices on where they spend money.
The bike lanes themselves are of course, often very poorly utilized. So traffic gets worse, businesses suffer, and it’s all for nothing. Now all these cities have left is intentionally crippling driving with low speed limits, speed bumps, and other hostile designs. It’s a way to try and claim that driving is no faster, even though it is trivial to keep driving fast and efficient.
mRNA is not a good example. If anything, it's a demonstration of why the Western capitalist model is superior to anything else. Most of the mRNA research was funded by venture capital as a high-risk high-reward investment.
In the world of government-sponsored research, mRNA likely would have been passed over in favor of funding research with more assured results.
That very cheap gigabit copper SFP was running hotter than I'd like -- it probably would have been fine, but this rig is meant to run outside while camping off-grid in the sun in central Florida. So I put some heatsinks from my 3D printing stash on there and so far they've stayed put.
In this system, the Hex S is running OpenWRT and is configured as a PoE-powered managed switch. In that role, it switches packets and does VLAN stuff fine, and is probably a bit of overkill.
But it's also one of several layers of manual redundancy, which is important in that environment: One does not simply go to the store and buy special electronics in central Florida. So it isn't included in the travel kit, then it doesn't exist.
With one shell script, it stops being just-a-switch and becomes a router with all the usual services, plus SQM tricks and multiple WAN ports. The rig works well.
RouterOS, although I'm only using the switch-related functionality.
I found that the temperature of the 10G modules has almost no relation to their cost. So far, the least hot modules are 10G Tek ones that are also the cheapest. Mirkotik's 10G modules are more expensive, and they are also hotter.
One another thing to try: set the MTU to 9000. But don't do this on your main interface, or you'll get haunted by traffic being blackholed.
At home, I have separate VLANs for the 9k packets. It has a separate subnet (both V6 and V4), so it works perfectly. The devices on this VLAN use it directly if they can, and everything else goes through the router that sends proper ICMP "too big" messages.
reply