I suggest you track down source material and not constrain yourself to the news summary. The article links to the original BuzzAngle Music report for 2016, which mentions this:
There were 11,489 cassettes purchased during the Holiday Season (an increase of 140% over 2015).
As another poster mentions, pneumatic valve actuation in motorsports is not to meant to do away with fixed cam timing -- there's still a conventional camshaft present. In F1, MotoGP and similar sports, pneumatic valves are there to be able to run engines at higher rpm (> 18,000 rpm) without valve float, which is what happens when you rely on spring-actuated valve return. In sporting applications, it's not so bad to have fixed valve timing, so long as you have fine control of ignition timing and dynamic fuel maps.
Camless engines have been tried by BMW and maybe others in 1980's using electromagnetic actuation with computer controlled timing. I believe it didn't work well with the manufacturing and materials of the time. Another approach was tried by Lamborghini with a mechanical camshaft that had variable lobe profile from side to side and the camshaft could slide back and forth with servo motor that was computer controlled to maintain a match between effective cam lobe and rpm. Would be very interesting to see a system like that pushed further with modern electronics and metallurgy.
And of course we already have total cylinder shutdown on many production vehicles. I think this is generally done through hydraulic valve lifters that can be manipulated by cutting off oil pressure and closing the valve (no air or fuel gets in, but maybe a secondary compression release valve is opened).
You're asking two questions:
Why would North Korea attempt this, if it was indeed them?
North Korean society is not as isolated as it once was, in part thanks to smuggled IT, especially on the borders. North Korean population is starting to watch South Korean television and generally consume international news sources more and more, which means North Korean leadership is either finding themselves the ones at a certain informational disadvantage, not quite knowing if they are sitting on a powder keg of dissent, or they feel they know what's going on and want to reign public opinion in. Either way, showing they are still a player on the international stage, even with something so ridiculous as a "made you look" kind of stunt, probably does the job, sad as it is.
How would US investigators know that it is North Korea, if it was indeed them?
Not everything is being disclosed. It's possible that the investigators or those in charge of public relations on the western side are overplaying strength of evidence. In some way, if there is a desire to tie this to North Korean, then this is a perfect opportunity, regardless of whether it can proven or not. In that way, it makes sense from an international relations point of view. At the same time, there may well be counter-intelligence shedding light on this, that the western authorities don't feel they can disclose. What's peculiar about that, is that situations like this give governments good information without ability to act on it for fear of erasing an intelligence advantage somewhere else. This was the case with the Rosenbergs. At the time of their conviction and execution, intelligence officials knew of their innocence, but the evidence for that was obtained through covert means and could not have been used, thus the tragic events were allowed to unfold. In the end, it's very hard for anyone not involved in this to parse out what's really going on.
It should probably use all of those data points. Sometimes people want to branch off the main thread of discussion. Letting users create a new thread by changing the subject is a nice intuitive work flow.
Part of the problem is that a lot of standards around email are very old and focus on the mechanics of composing, transmitting, and accessing individual messages. If you're in the business of modernizing or even simply creating a normal modern email client, when it comes to more recent concepts like conversation threads, HTML, address books, calendar integration, documents, and other collaborative workflows, things aren't so clear. On the one hand, there are guidelines and room to innovate, on the other hand some ecosystems proliferate specific patterns that don't work at all in other ecosystems, but both are called email. The calendars are handled in Google domains vs Exchange are not the same, while solving same basic problems.
I had an interesting experience at my company this year. We switched from Exchange to Gmail and many people were initially excited about the possibility of using their own email clients of choice. It was always known that even if this was possible, many of our normal workflows would require using web interfaces beyond the native client. But even with that caveat, in the end our IT decided not to open IMAP to us for fear of end-user problems or complications they did not want to be responsible for.
DBs are not for chewing data -- they're for giving you just the data you need so you can chew on it. You use the right tool for the chewing job once you have the data. (Some DB pre-chew is fine in situations where it's efficient and easy -- group by's, mostly.)
Seems like there aren't many responses here talking about columnar databases. This a class of relational databases very well suited for data warehousing. I have been working with Vertica, which is a proprietary technology, but the license terms are much more favorable and fair than what you get out of Oracle (they aren't comparable anyway). It's a mindset change when you get into columnar databases, but on the whole they can be simpler than what you get trying to tune a traditional relational database for big data warehousing purposes.
You will still need to think about your ETL and reporting technologies. This can be difficult depending on the nature and stability of your data and reporting customers' needs. On the whole, some things to think about are adherence to standards, not being afraid to operate multiple data marts, separating different reporting functions into different applications (internal vs external, raw data extracts vs analytics, etc.), and look at some map-reduce technologies (some shared-nothing databases give you that under the hood for free, some make it explicit, like Hadoop).
This is barely a real problem. As someone else mentioned, it's not difficult to use revision numbers. Even today, there are inventory systems that understand compatibility between aftermarket manufacturers and OEM. I worked on a rudimentary system like that myself -- it's not rocket science. But there may be two things in this particular story that are worth looking into:
Firstly, did GM or its suppliers intentionally reuse a part number to obfuscate the change in design tied to known safety issues. Not saying they did. Maybe they didn't, but it would be great to clear that up in open court.
Secondly, is there a standard industry practice to reuse part numbers in general, where part numbers become misleading in relation to fit or compatibility? There is sometimes incentive on the part of manufacturers to publish obfuscated specifications or withhold this kind of information altogether as an anti-competitive measure against small repair shops (in favor of dealer networks) or to undercut aftermarket manufacturers' ability to improve on original designs.
"It is better for civilization to be going down the drain than to be coming up it." -- Henry Allen