Not just single thread performance, performance per watt in the 80+W TDP area is actually really advantaged toward AMD and Intel. The ARM vendors did a fantastic job of typical power consumption in frequent sleep and providing serviceable performance in low power envelopes, but have not yet demonstrated good performance in high power usage environments.
Part of it is the relative lack of experience, a great deal of it is that Intel has invested in all sorts of third party and first party compiler and library performance for x86. ARM could catch up, but as of now it seems few companies even have the ambition to try, and are refocusing on the embedded space which is less 'glamorous', but sells tons of volume.
On the one hand, he has a point, developer-friendly form factors are x86 and that's unlikely to change due to the propensity for developers to have some x86 app they want and better to hedge your bets.
However, the presumption that cloud providers would prefer x86 because it can carry a price premium fails to acknowledge that the providers can potentially get wider margins out of an ARM ecosystem. In x86, you have two vendors and thus they only get so desperate to compete against one another. In ARM server space, at one point you had Marvell, Qualcomm, Broadcom, AMD, Cavium and more vying for the space. The big providers love pitting many vendors against each other as generally *someone* is desperate enough to take a big loss just to get the business. This probability decreases as you have fewer viable vendors.
But it's also been a bit rough. Most of those ARM vendors have since given up their server ambitions. Of the ones that made it to market, none of them could deliver the performance or even performance/watt near the x86 offerings. Many of the advantages they have enjoyed in mobile space (notably better idle behavior) erode in a server setup with high utilization.
His article hinges upon the assumption that Netscape was screwed over by the rewrite. In reality, they were almost certainly screwed on the business side to the extent no amount of technical effort could overcome their position.
To the extent they had technical woes, it may well have been the case they couldn't sort out how to make the improvements they wanted to make given their current design.
Now there are valid points, that 'old code' may look crusty but there is a good chance it is crusty for a reason and that sort of thinking should be ever present while making such a call, to try to understand *why* it is crusty before throwing it out. However sometimes it is for bad reasons: -Written against a once-presumed 'winner' of the market that becomes defunct. Your shockwave website has to be rewritten because the supporting technology is toast, and you better be scrapping your flash website soon if not already. -Maybe the runtime is still around, but *your* ability to find willing developers is difficult, so you have to switch languages/runtimes to align with the labor market -The people doing it didn't know what they were doing and did it incorrectly. Optimally, this is the same team that recognizes they painted themselves into a corner so they know what to do next time. -The code is full of workarounds for third party libraries that no longer apply. True this doesn't scream 'rewrite', but one of his points was that the ugliness of code is due to fixes for things long forgotten that still matter, but it's frequently the case they do still matter.
In short, like all opinions be informed and influenced, but no simple answer is ever 100% correct no matter what. Internalize the points and evaluate in your scenario.
Well for one, as others mentioned even if *you* try to have no relationship with these companies, they still capture data about you, so it's not only the willing.
Also, it takes an even more 'shit of money' to do broadcast television and somehow it's been being provided free to viewers without surreptitious monitoring of its consumption. So it's not a given that free or reasonable pricing can only come with excessively intrusive mining.
Biting insects are merely a 'nuisance' when not carrying an epidemic or with reasonable feeding levels.
Biting insects may have propagated a devastating plague applying pressure to the population. The warm climate might have also facilitated an overpopulation of biting insects so severe it would actually substantially impact the nourishment of the animals they fed on.
I suppose the 'novelty' is that a 'single' system can exhaust keyboard-appropriate 8 character sequences in 2.5 hours for NTLMv1 hashes, which is relatively short. However constraining to a single server is an odd limitation to pay any mind to.
In the case here, assumption was that GPS firmware would know which window of 20 years would make most sense. A GPS designed to be remotely viable over a large timespan would generally have to have persistent writable storage for map data, so storing the current general 20 year window should be feasible.
Similarly, I seem to recall some man page back in the day defining the timestamp as being in terms of the 'current' epoch and explictly saying the epoch would change. Of course I don't think any agreement was made on how to denote the current epoch so I don't know what was expected of developers in terms of handling that tidbit in that man page. I suppose they presumed a consensus would be eventually reached and software could be updated to deal, since the hardware they were working on would definitely not be making it to 2038 anyway, so an epoch change is the least of their worries in terms of problems to solve to be runnable software in 2038.
I have seen container images that live eternally and get randomly changed and 'docker committed' and no one is comfortable knowing how to get back to that state.
To the extent I have authority to do so, I make sure that images do not stray from a specific build process that comes from the same teams that release the OS platform and do not tolerate processes that involve 'change stuff in a container and commit to capture changes'. In that scenario it is a useful tool.
The parent laments at least resemble my dread: when a project talking about downloads gives only 'docker pull', then almost universally the software is crap held together by duct tape they barely could sort out to get run once. The preceding fad was 'virtual appliance', where the same thing held: developers lacking the competency to properly design their software to work sanely in a well controlled environment. Attempts to use those software have non-trivially more frequent incidents of falling over and no one on earth able to figure out what went wrong because they never unified how the software produces debug and they spew out in random places through third-party code the vendor doesn't really understand. Also they have a tendency to have some decrepit versions of software dating back to when they first did a 'docker pull' when they started development and never bothering to refresh dependencies.
Sure, there will be examples of well maintained software and people doing the right thing in dockerhub, but there are a lot of crappy things there too. Sometimes things will look quite nice at first and then after using and configuring you quickly enter a configuration they didn't think about and poof.
The question is, what in the world is the downside of curbing our CO2 activity? Why would anyone be so vehemently against doing that. Sure, make arguments we need to continue research and measure the effects and don't presume victory, but at least make a go of our current best guess, with the undeniable side effects of conserving petroleum (that won't last forever) and reducing related pollutants.
What would one possibly hope to accomplish by fighting *any* attempt at mitigating the situation?
So to take this comment at face value, the question is what is the hypothetical course suggested by denying that mankind is driving climate change?
If the hypothesis that mankind driving climate change is somehow incorrect, then the 'misguided' actions to fix it would have produced cleaner environment and mitigated our consumption of resources that we cannot renew once exhausted.
If the hypothesis is correct but we reject it and instead demand proof and instead go full coal rolling and burn hydrocarbons full tilt assuming it doesn't do anything; then we are basically killing ourselves. Not the planet, *us*, the planet does not care what we do, it'll be around no matter what the climate does to us.
So all this posturing about 'oh there's faith without adequate proof' is far more risky than erring on the side of caution and doing the right thing.
I see the point, the frustration to me is that the reality has produced highly vertically monolithic cloud 'things' rather than federated services.
By and large 'cloud storage' is the key part. Live collaboration on a document is currently only viable through a 'all-in' experience, but there could have been a standard for bidirectional content streaming that applications could have used.
In such a case, hypothetically google suite and ms office could collaborate on the same content live, rather than having to pick which stack.
It particularly annoys me with the volume of electronics that are locked into a cloud vendor and at the whims of that vendor in terms of when that electronic gadget becomes junk (see the Lowes shutdown of their smarthome line that is going to brick all the customers that bought into it)
Note that on the quarterly reports, they've already taken the move to defer and amortize benefit of windows 'transactional' revenue over years to make it resemble a recurring revenue picture rather than transacitonal.
Buying into the subscription and having your content held hostage in OneDrive is the supreme deal for them.
The problem for Microsoft is that the term is indefinite, even when they plan otherwise.
For example, they had to extend XP support well beyond their planned EOL, due to pressure and perception that XP being a gigantic security hole reflects on their current products, not just that they EOLed XP, and that MS doesn't care about security if they don't keep those guys up to date.
However I don't think Office has the same problem. Anyone using Office 97 won't get away with blaming microsoft for infections, for some reason.
I think it depends on exactly *how* these 'predictions' are used. If it is used to plan patrols, then in *theory* having patrols in the area should be nothing to fear. If it is used as 'evidence', that would be dumb. If it is used to influence sentencing, that too is dumb and has already been shown to be a problem.
In the planning patrols use case, it only seems wrong because the relationship between the police and citizenry is dysfunctional. In an ideal system, law-abiding citizens *shouldn't* feel persecuted just because there are police patrols nearby. In fact, it should be reassuring. However that is largely not the relationship that has been cultivated between the police and other folks.
In that terminology, 'intermediate' does not refer to a MITM intermediate, but instead if your server cert is signed by a subordinate CA that is in turn signed by a really trusted authority. For example, lets encrypt certs at least at one point *required* that the servers offer up the full chain, since the server cert was not directly signed by any authority installed in the browsers.
To be fair, to the extent they can offer any protection against attack from javascript to browser they would have to pull this sort of trick. Replacing certificate with either a trusted or untrusted one so long as the CA private key is unique per endpoint and the software correctly validates before passing it on. It is of course ugly as hell, but at least not crazy bad in security.
Of course, on the practical side I'd want to see some examples of them actually doing anything on that front. Compared to 'download and run executable', the browser security models are a lot more restrictive and I can't think of specific scenarios where 'anti-virus' steps in rather than site operators fixing their CORS rules or similar in the face of an attack. I suppose if you are not updating your web browsers there could be risks, but updating web browsers would be easy enough...
Is that Java was the 'correct' choice at the peak of the 'gold rush' around the turn of the century. This meant hordes of people without particular interest in programming going into the field because of money, and their total lack of interest carried showed in their work.
So to me Java transformed from a flawed implementation that was very slow and inefficient to an implementation that largely addressed the fundamental limitations but used by a bunch of people who are barely passable at programming.
Currently the language that has borne the brunt of the current 'gold rush' mentality has been Javascript, which explains in part why that ecosystem is pretty messed up.
In a scenario where power is split, both parties love to go to town with heavy rhetoric and the bills to back it up, safe in the knowledge that the other party will block it and take the blame. They get to largely throw any semblance of nuance out the window on divisive issues and *appear* to be ready to go all in to get that bill passed. Like a dog chasing a car being very loud.
Then when the dog catches the car, suddenly things are different. When one of the parties control the legislature and executive branch all that rhetoric can finally go. Well, actually they are not really a fan of those seemingly simplistic perspectives, and suddenly things grind to a halt. We want socialized medicine say the democrats that know they will be vetoed. They get power in congress and the executive branch, things get watered down and Obamacare happens. On the flipside, Republicans with a president that will absolutely veto anything that would threaten obamacare: 'we have passed many bills that would dismantle obamacare'. Republicans win congress and the presidency, 'oh... well, we don't *really* want to repeal it....'
It's a large cause of the seesaw. The tough reality is that some nuanced approach is generally best but the voters are bored by that so they vote for the energized oversimplistic view that sounds straightforwarde enough.
Checksums aren't secure. All an attacker has to accomplish is to generate a file with some garbage data in order to match the checksum. In other words, they only need to find a hash collision.
Signatures are just checksums that have been signed. If you could find a sha256 collision (good luck) then signing packages would also be useless. Releases contain the cryptogrophically solid checksums of packages and then it in turn is signed, establishing a chain to valiate.
No, it was a way to provide a package that didn't match the checksum, with the addition of a header that said that it did.
I thought that at first as well, but upon deeper exploration, his trick in practice was to sneak a.dpkg file into the contents of a pem file and induce apt to process that pem file as a dpkg...
yum is secure against those attacks.
And with a fix, apt is also secure against those attacks. Granted having multiple layers is better, but the design does provide a full path from gpg key to the individual packages.
Yep, the 'ignore the fact the data came in useless' can create terrible behaviors and gigantic opportunity for security vulnerabilities.
"If (suspiciousthing) securityteam.alert()" clearly means that if somehow securityteam is null, then nothing should happen of course...
Particularly disappointing as the last time I read about this without concrete examples, I gave them the benefit of the doubt. They presumably did something that would be very sophisticated and detect the full obscure paths through execution and then you can determine how to accommodate. Now that I see they basically just preface every call with 'if null return', it's absurd how loud and proud they are about this mess. It's also amazing to call *not* doing that a 'coding error'.
Almost any company can make a platform with the technical attributes of those offerings.
What triggers the acquisition is when some 'brand' magically is deemed the 'hot' platform. At that point there is no technical thing you can do to capture that population and your solution is useless because nobody is on it. So a company has little choice but to just fork over tons of money to take over the brand and users.
Of course the risk of chasing these fads, on a whim suddenly everyone decides some other random equivalent technology is cool instead and your investment evaporates.
It's a rather challenging thing to do since you have no way of knowing that a change of fad is around the corner.
Slashdot Mirror
Not just single thread performance, performance per watt in the 80+W TDP area is actually really advantaged toward AMD and Intel. The ARM vendors did a fantastic job of typical power consumption in frequent sleep and providing serviceable performance in low power envelopes, but have not yet demonstrated good performance in high power usage environments.
Part of it is the relative lack of experience, a great deal of it is that Intel has invested in all sorts of third party and first party compiler and library performance for x86. ARM could catch up, but as of now it seems few companies even have the ambition to try, and are refocusing on the embedded space which is less 'glamorous', but sells tons of volume.
On the one hand, he has a point, developer-friendly form factors are x86 and that's unlikely to change due to the propensity for developers to have some x86 app they want and better to hedge your bets.
However, the presumption that cloud providers would prefer x86 because it can carry a price premium fails to acknowledge that the providers can potentially get wider margins out of an ARM ecosystem. In x86, you have two vendors and thus they only get so desperate to compete against one another. In ARM server space, at one point you had Marvell, Qualcomm, Broadcom, AMD, Cavium and more vying for the space. The big providers love pitting many vendors against each other as generally *someone* is desperate enough to take a big loss just to get the business. This probability decreases as you have fewer viable vendors.
But it's also been a bit rough. Most of those ARM vendors have since given up their server ambitions. Of the ones that made it to market, none of them could deliver the performance or even performance/watt near the x86 offerings. Many of the advantages they have enjoyed in mobile space (notably better idle behavior) erode in a server setup with high utilization.
His article hinges upon the assumption that Netscape was screwed over by the rewrite. In reality, they were almost certainly screwed on the business side to the extent no amount of technical effort could overcome their position.
To the extent they had technical woes, it may well have been the case they couldn't sort out how to make the improvements they wanted to make given their current design.
Now there are valid points, that 'old code' may look crusty but there is a good chance it is crusty for a reason and that sort of thinking should be ever present while making such a call, to try to understand *why* it is crusty before throwing it out. However sometimes it is for bad reasons:
-Written against a once-presumed 'winner' of the market that becomes defunct. Your shockwave website has to be rewritten because the supporting technology is toast, and you better be scrapping your flash website soon if not already.
-Maybe the runtime is still around, but *your* ability to find willing developers is difficult, so you have to switch languages/runtimes to align with the labor market
-The people doing it didn't know what they were doing and did it incorrectly. Optimally, this is the same team that recognizes they painted themselves into a corner so they know what to do next time.
-The code is full of workarounds for third party libraries that no longer apply. True this doesn't scream 'rewrite', but one of his points was that the ugliness of code is due to fixes for things long forgotten that still matter, but it's frequently the case they do still matter.
In short, like all opinions be informed and influenced, but no simple answer is ever 100% correct no matter what. Internalize the points and evaluate in your scenario.
Well for one, as others mentioned even if *you* try to have no relationship with these companies, they still capture data about you, so it's not only the willing.
Also, it takes an even more 'shit of money' to do broadcast television and somehow it's been being provided free to viewers without surreptitious monitoring of its consumption. So it's not a given that free or reasonable pricing can only come with excessively intrusive mining.
Biting insects are merely a 'nuisance' when not carrying an epidemic or with reasonable feeding levels.
Biting insects may have propagated a devastating plague applying pressure to the population. The warm climate might have also facilitated an overpopulation of biting insects so severe it would actually substantially impact the nourishment of the animals they fed on.
Well, /etc/shadow rather than /etc/password.
I suppose the 'novelty' is that a 'single' system can exhaust keyboard-appropriate 8 character sequences in 2.5 hours for NTLMv1 hashes, which is relatively short. However constraining to a single server is an odd limitation to pay any mind to.
On the other hand, focus on character classes causes people to pick short passwords because they can only remember so much of that crap.
Focus on password length *and* character classes and people just can't do it.
Focusing on password length alone is the way to win, 'password' is a much worse mindset than 'passphrase'.
In the case here, assumption was that GPS firmware would know which window of 20 years would make most sense. A GPS designed to be remotely viable over a large timespan would generally have to have persistent writable storage for map data, so storing the current general 20 year window should be feasible.
Similarly, I seem to recall some man page back in the day defining the timestamp as being in terms of the 'current' epoch and explictly saying the epoch would change. Of course I don't think any agreement was made on how to denote the current epoch so I don't know what was expected of developers in terms of handling that tidbit in that man page. I suppose they presumed a consensus would be eventually reached and software could be updated to deal, since the hardware they were working on would definitely not be making it to 2038 anyway, so an epoch change is the least of their worries in terms of problems to solve to be runnable software in 2038.
I'm going to make a cloud service that will provide nothing other than CP/M instances to the users.
The reality is that it can support both.
I have seen container images that live eternally and get randomly changed and 'docker committed' and no one is comfortable knowing how to get back to that state.
To the extent I have authority to do so, I make sure that images do not stray from a specific build process that comes from the same teams that release the OS platform and do not tolerate processes that involve 'change stuff in a container and commit to capture changes'. In that scenario it is a useful tool.
The parent laments at least resemble my dread: when a project talking about downloads gives only 'docker pull', then almost universally the software is crap held together by duct tape they barely could sort out to get run once. The preceding fad was 'virtual appliance', where the same thing held: developers lacking the competency to properly design their software to work sanely in a well controlled environment. Attempts to use those software have non-trivially more frequent incidents of falling over and no one on earth able to figure out what went wrong because they never unified how the software produces debug and they spew out in random places through third-party code the vendor doesn't really understand. Also they have a tendency to have some decrepit versions of software dating back to when they first did a 'docker pull' when they started development and never bothering to refresh dependencies.
Sure, there will be examples of well maintained software and people doing the right thing in dockerhub, but there are a lot of crappy things there too. Sometimes things will look quite nice at first and then after using and configuring you quickly enter a configuration they didn't think about and poof.
The question is, what in the world is the downside of curbing our CO2 activity? Why would anyone be so vehemently against doing that. Sure, make arguments we need to continue research and measure the effects and don't presume victory, but at least make a go of our current best guess, with the undeniable side effects of conserving petroleum (that won't last forever) and reducing related pollutants.
What would one possibly hope to accomplish by fighting *any* attempt at mitigating the situation?
So to take this comment at face value, the question is what is the hypothetical course suggested by denying that mankind is driving climate change?
If the hypothesis that mankind driving climate change is somehow incorrect, then the 'misguided' actions to fix it would have produced cleaner environment and mitigated our consumption of resources that we cannot renew once exhausted.
If the hypothesis is correct but we reject it and instead demand proof and instead go full coal rolling and burn hydrocarbons full tilt assuming it doesn't do anything; then we are basically killing ourselves. Not the planet, *us*, the planet does not care what we do, it'll be around no matter what the climate does to us.
So all this posturing about 'oh there's faith without adequate proof' is far more risky than erring on the side of caution and doing the right thing.
I see the point, the frustration to me is that the reality has produced highly vertically monolithic cloud 'things' rather than federated services.
By and large 'cloud storage' is the key part. Live collaboration on a document is currently only viable through a 'all-in' experience, but there could have been a standard for bidirectional content streaming that applications could have used.
In such a case, hypothetically google suite and ms office could collaborate on the same content live, rather than having to pick which stack.
It particularly annoys me with the volume of electronics that are locked into a cloud vendor and at the whims of that vendor in terms of when that electronic gadget becomes junk (see the Lowes shutdown of their smarthome line that is going to brick all the customers that bought into it)
Note that on the quarterly reports, they've already taken the move to defer and amortize benefit of windows 'transactional' revenue over years to make it resemble a recurring revenue picture rather than transacitonal.
Buying into the subscription and having your content held hostage in OneDrive is the supreme deal for them.
The problem for Microsoft is that the term is indefinite, even when they plan otherwise.
For example, they had to extend XP support well beyond their planned EOL, due to pressure and perception that XP being a gigantic security hole reflects on their current products, not just that they EOLed XP, and that MS doesn't care about security if they don't keep those guys up to date.
However I don't think Office has the same problem. Anyone using Office 97 won't get away with blaming microsoft for infections, for some reason.
I suppose the question is how much corruption/fraud requires a party to go back and modify records rather than falsifying them in the first place.
I think it depends on exactly *how* these 'predictions' are used. If it is used to plan patrols, then in *theory* having patrols in the area should be nothing to fear. If it is used as 'evidence', that would be dumb. If it is used to influence sentencing, that too is dumb and has already been shown to be a problem.
In the planning patrols use case, it only seems wrong because the relationship between the police and citizenry is dysfunctional. In an ideal system, law-abiding citizens *shouldn't* feel persecuted just because there are police patrols nearby. In fact, it should be reassuring. However that is largely not the relationship that has been cultivated between the police and other folks.
Oh, whoops, yeah that is an... interesting phrasing...
In that terminology, 'intermediate' does not refer to a MITM intermediate, but instead if your server cert is signed by a subordinate CA that is in turn signed by a really trusted authority. For example, lets encrypt certs at least at one point *required* that the servers offer up the full chain, since the server cert was not directly signed by any authority installed in the browsers.
To be fair, to the extent they can offer any protection against attack from javascript to browser they would have to pull this sort of trick. Replacing certificate with either a trusted or untrusted one so long as the CA private key is unique per endpoint and the software correctly validates before passing it on. It is of course ugly as hell, but at least not crazy bad in security.
Of course, on the practical side I'd want to see some examples of them actually doing anything on that front. Compared to 'download and run executable', the browser security models are a lot more restrictive and I can't think of specific scenarios where 'anti-virus' steps in rather than site operators fixing their CORS rules or similar in the face of an attack. I suppose if you are not updating your web browsers there could be risks, but updating web browsers would be easy enough...
Is that Java was the 'correct' choice at the peak of the 'gold rush' around the turn of the century. This meant hordes of people without particular interest in programming going into the field because of money, and their total lack of interest carried showed in their work.
So to me Java transformed from a flawed implementation that was very slow and inefficient to an implementation that largely addressed the fundamental limitations but used by a bunch of people who are barely passable at programming.
Currently the language that has borne the brunt of the current 'gold rush' mentality has been Javascript, which explains in part why that ecosystem is pretty messed up.
In a scenario where power is split, both parties love to go to town with heavy rhetoric and the bills to back it up, safe in the knowledge that the other party will block it and take the blame. They get to largely throw any semblance of nuance out the window on divisive issues and *appear* to be ready to go all in to get that bill passed. Like a dog chasing a car being very loud.
Then when the dog catches the car, suddenly things are different. When one of the parties control the legislature and executive branch all that rhetoric can finally go. Well, actually they are not really a fan of those seemingly simplistic perspectives, and suddenly things grind to a halt. We want socialized medicine say the democrats that know they will be vetoed. They get power in congress and the executive branch, things get watered down and Obamacare happens. On the flipside, Republicans with a president that will absolutely veto anything that would threaten obamacare: 'we have passed many bills that would dismantle obamacare'. Republicans win congress and the presidency, 'oh... well, we don't *really* want to repeal it....'
It's a large cause of the seesaw. The tough reality is that some nuanced approach is generally best but the voters are bored by that so they vote for the energized oversimplistic view that sounds straightforwarde enough.
Checksums aren't secure. All an attacker has to accomplish is to generate a file with some garbage data in order to match the checksum. In other words, they only need to find a hash collision.
Signatures are just checksums that have been signed. If you could find a sha256 collision (good luck) then signing packages would also be useless. Releases contain the cryptogrophically solid checksums of packages and then it in turn is signed, establishing a chain to valiate.
No, it was a way to provide a package that didn't match the checksum, with the addition of a header that said that it did.
I thought that at first as well, but upon deeper exploration, his trick in practice was to sneak a .dpkg file into the contents of a pem file and induce apt to process that pem file as a dpkg...
yum is secure against those attacks.
And with a fix, apt is also secure against those attacks. Granted having multiple layers is better, but the design does provide a full path from gpg key to the individual packages.
Yep, the 'ignore the fact the data came in useless' can create terrible behaviors and gigantic opportunity for security vulnerabilities.
"If (suspiciousthing) securityteam.alert()" clearly means that if somehow securityteam is null, then nothing should happen of course...
Particularly disappointing as the last time I read about this without concrete examples, I gave them the benefit of the doubt. They presumably did something that would be very sophisticated and detect the full obscure paths through execution and then you can determine how to accommodate. Now that I see they basically just preface every call with 'if null return', it's absurd how loud and proud they are about this mess. It's also amazing to call *not* doing that a 'coding error'.
Almost any company can make a platform with the technical attributes of those offerings.
What triggers the acquisition is when some 'brand' magically is deemed the 'hot' platform. At that point there is no technical thing you can do to capture that population and your solution is useless because nobody is on it. So a company has little choice but to just fork over tons of money to take over the brand and users.
Of course the risk of chasing these fads, on a whim suddenly everyone decides some other random equivalent technology is cool instead and your investment evaporates.
It's a rather challenging thing to do since you have no way of knowing that a change of fad is around the corner.