Not commenting on the merits of CA or Federal tax credits, but these cars end up getting sold as used cars in states that don't have tax credits. They still have value and are definitely not being scrapped.
I experienced what was eventually classified as a microburst and the effects on the ground were largely indistinguishable from a tornado. I'm not sure the article really made this clear, or if there are multiple, potentially different definitions for the term. This is also an area that frequently experiences tornado activity so we have ample experience with those events for comparison. We had winds that were likely in excess of 125mph and there were around 100+ houses damaged, 6-8 were completely destroyed and 30+ sustained severe damage. Flooding was not an issue but we have unique geography that makes that very unlikely.
A big problem for machines of this vintage is HTTPS everywhere. Google still works pretty well and will let you access it over HTTP, but the rendering of the search results is a bit janky.
This is not recent, part of the compulsory licensing for covers is that the cover does not substantially alter the original song. This boils down to substantial alterations of the melody or (possibly) lyrics.
I think this article is unreasonably lumping together the concept of covers and remixes. Cover songs are covered by compulsory licenses in the U.S.A. These are very 'mechanical' and you can in fact obtain them for virtually any recorded song at a fixed rate. It is possible that companies like Soundcloud may be streamlining the process or helping the publishing rights holders but there is not much preventing covers from being created.
The situation for remixes is much different. Remixes inherently involve the use of a PERFORMANCE, not a composition. Licensing is as you mention in the article very difficult and is up the discretion of the rights holder. If there are platforms that want to reduce friction here I think that is great, but the artist should still have discretion in how their performances are used.
I think this is a difficult concept for people because our brains do such a good job compensating for mixed lighting. Our built in auto-white balance is too good. One example I use to explain this is the classic Hollywood 'moonlight' trick, which is achieved by using a daylight balanced source like a large HMI, and then using film or a camera that is balanced for tungsten. Looks like daytime to the eye, but on camera it looks like moonlight.
There are even special gels just for correcting various light sources CTO (color temp orange) CTB (color temp blue) and minus green (correct gross flo lights). The rest are usually regarded as 'party colors' since they are for non-technical corrections.
I think the author has somewhat conflated the concept of CRI and color temperature in the article. An incandescent bulb or a candle has 100 CRI because they are almost by definition close to the ideal. That said a typical incandescent bulb is going to be somewhere in the 2500-3500K color temp. Lots of cheap flo bulbs tend to be both relatively low CRI and have a color temp in the 5000-6000K range which is more like 'daylight without benefits'. They tend to have lots of blue and greens and nothing else. Lots/most LED lights fall in this range as well. My personal opinion is that lighting products should be required to list CRI and color temp, just like nutrition information on food. :)
There are two broad categories of approaches you use when dealing with sound. One is controlling sound transmission, and the other is shaping/controlling diffusion. In general these types of foams act as diffusers, which influences the sound inside the room, but have very little impact on sound transmission, which is what most people think of when they say 'sound proofing'. Dealing with sound transmission generally requires lots of mass, isolation, and careful attention of air-tightness. Think about how a thermos is constructed and you start to get the idea.
Voxel data is just a bunch of points, the rendering mechanism makes it no more or less 'voxely'. Ultimately you have some scheme to take your voxel data and turn it into triangles that you can display if your goal is 3d. If you use plain cubes, you will get Minecraft-esque things, at least if you get close enough to the surface. If you use a technique like marching cubes or tetrahedron you can make very fluid or blobby looking things but it is very hard to make a flat surface or a sharp corner. There are methods like dual-contouring which can do both sharp corners and fluid surfaces, but are a more complex, and require combining various densities of voxel data to render fine details. Stitching the voxels of different densities has its own challenges, at least without creating gross artifacts at the edges.
The car actually randomly asks you permission to do this. You will start the car up and there will be a dialog asking you to continue to allow the computer to communicate with Nissan. If I recall, you also need to enter in some credentials into the car's computer for it to communicate with Nissan.
The unfortunate part here is that the previous API used authentication, and the credentials were the same as your owners credentials for the Nissan portal. They released this version at the beginning of the year. The previous API endpoint appears to still exist and work.
I suspect that they may have dropped the credentials for the new API because they had so many problems with users figuring out what credentials to use for their mobile app. This is obviously a terrible solution, just speculating.
I wondered about hijacking cars by taking their VIN, but the process is not automated. It requires a call or two to Nissan to verify ownership before they will transfer the vehicle over to your account. This isn't to say you couldn't social engineer you way into the car, but you need more than the VIN. Incidentally you can't unlock the car remotely, at least not with the known endpoints :)
You would think a BBC article on this topic would mention the bizarre postscript, where Lunokhod 2 and Luna 21 were sold at auction for around $70K USD to Richard Garriott.
I have just been scheduling a 100% charge overnight when its below freezing to compensate for the loss of battery efficiency. Normally I just charge to 80%. This is mostly just for peace of mind, my trip is about 20 miles each way.
The LEAF has a heat pump and it works till about freezing at which point it switches over to an electric heater. The loss of efficiency due to cold weather really dwarfs the cost of heating/cooling in the vehicle.
Just for comparison here, I have a 2013 Leaf. In December I drove 920 miles and with my utility prices the cost of electricity to cover those miles was about $28. You still need either an extremely efficient car or quite a bit lower gas prices to beat this. This also does not account for the fact that you can routinely get free electricity for your EV.
My experience is that the decrease during cold weather is more a function of the lowered performance of the battery than the result of the cabin heating. The battery draw at freeway speed is maybe 30kw. The baseline draw from the accessories in the vehicle ( radio, console ) and no heating/cooling/defroster is around 0.5kw. With the heat cranked up all the way and all the various heaters turned up to high the additional draw above baseline is 2-2.5kw.
When I was working on one of our SDKs (pre Swift 2.0), I found it rather maddening that the Swift string class had native support for emoji, but developers were left to create their own implementation of very basic features like indexOf, length, subString, etc.
A few years ago when I needed to write collision detection for a variety of specialized cases, I found the book "Real-Time Collision Detection". It is one of the few really comprehensive resources I was able to find on the topic. The example sources are C++ but the concepts apply to 3d in any domain. The website for the book is http://realtimecollisiondetection.net/
My experience with Typescript is that I have spent the majority of what I would call 'wasted' time either messing with type definitions, or fumbling with getting modules to play nicely with code that needs to be used in the browser and in Node. My impression of the language is fairly positive, however I'm not currently using it for backend development because the burden of the type definition files is too great. Having to write a type definition file yourself for a library where none exists has been fairly painful in my experience.