So far, I'd say the masses are augmenting with mobile, but as possible like to go to a full laptop experience because the mobile platform and form factor is just too limiting. This includes teenage relatives and my own child and their friends, they *all* wanted to have laptops *and* phones.
The problem though is that a 10 year old device (if it still works at all) is adequate for pretty much all casual usage, and the hardware update cycle is driven by hardware breaking, people mistaking software problems for aging hardware problems (or just not caring), and fashionable changes more than it is need to actually get new levels of performance.
I do however expect that volumes will never dip below say the mid 90s or so, even proportionally to the general population. The market for PCs exploded, and then for those less purely enthusiast customers, computers became good enough and their money got rerouted to extending their experience to their pockets.
One, you'd be surprised how consistent browsers in the last 3-4 years have been.
Two, 99% of the time if you are using java script to animate, you are failing to use the far more efficient CSS to do the same thing, and more easily degrade to accessible use.
Also, $() is a lot slower than the equivalent functions. I will admit to being annoyed by the tedium of the function names, but most editors will do a sane job of completion.
This is an obvious outcome. It's worth keeping in mind that filing a suit does not vindicate or disprove anyone, as there's no way to ascertain whether there will be merit in the suit at this point. All it means is there's enough lawyers willing to make a wager when faced with such a *huge* potential payout.
Actually, my thought was that for some things, there must be constraints.
For other things, so long as you have a *good* team that is self motivated, allowing the novel things to come as they are ready can work.
Of course, 'when it's ready' sometimes doesn't work and never happens because everyone is *too* laid back, so it's important to read the situation at hand, but sometimes it works great, for at least part of the work
One of the particular dangers of imposing an arbitrary deadline is that something that doesn't *really* matter is used as a reason to not do something else that *matters a lot*, because you are too busy trying to get something less important out in time.
When you are dealing with a situation with other folks depending on you, then the timetable may matter moreso than how creative it can be.
However novel new capabilities are not generally well served by making up a deadline if one does not naturally exist.
However that later situation drives managers/project managers insane. Why even bother trying if you don't know when you would finish, how can you 'grade' yourself if you don't know when you would deliver, so make up something.
Having a backlog of ideas without a milestone to make them due is a fine thing, but project management *must* have it on a roadmap or else get pissed.
The Pentium FDIV bug: No sane way to workaround at all, and no way to work around it in real mode operating systems, which mattered a lot at the time. Intel ultimately forced to do a recall because they could not provide accurate results for applications. Three models (60, 66, and 90mhz) exposed and caught *relatively* early and volumes were manageable.
F00F bug: Feasible OS workarounds for protected mode operating systems with no performance impact. Real mode operating systems still mattered, but if you were running real mode there were tons of other ways to freeze the whole system so F00F wasn't that interesting in real mode anyway. Workarounds looked *ugly*, but they were cheap. Intel screwed up, but software workaround was pretty appropriate.
Meltdown: There are workarounds, but could be very expensive. At the same time, they have two decades of exposed products and much higher volumes than they had before. So the scope of a recall would be way more massive. The workaround results in reduced performance, not incorrect results. If anything were to happen, I'd bet some sort of small rebate or credit for the performance loss, and telling the world to just deal with the performance impact if they care about security.
Intel pushes a microcode blob out to OSes and board/system vendors.
Those OSes and board/system vendors pull in the blob and issue updates that include them.
Some platforms allow the OS to update microcode at run time, others (particularly most server platforms) forbid microcode updates by the OS and must be applied by firmware.
Either way, the firmware installs some microcode at every boot, then the OS may or may not follow up with an update, so any microcode updates for any platform will appear in both places.
The challenge was that they started following chrome's lead after the exodus of users. The exodus was going to happen regardless.
It is fair to complain that rather than catering to their loyal users, they tried to compete with chrome by being more chrome like, but either way their user share was going to decline.
As someone more thoroughly said, the KPTI patch doesn't make the behavior impossible, it just takes the teeth out of it by unmapping all the juicy things they would want.
Note that partially flushing the cache after a misprediction would certainly mitigate, but there would still be a window where the memory has been cached speculatively and the fault being detected. You instead would have to maintain a mask of cached-but-not-yet-valid-for-issue cache memory, and ignore it in specific scenarios until everything checks out. Of course this probably would be unacceptably slow down on all cache (another lookup table to go through for all cache access), so presumably the more likely true fix is the former (which is also far more straightforward and less likely to have unforeseen hole).
The Harvard/Yale/CalTech/MIT may matter for connections, but at least at places I have worked we haven't afforded them particularly more consideration than other grads. They also don't stand out as seeming particularly more competent or better at interviewing than other schools.
They do some excellent work in academia, but the likely return on investment may be much lower than one might hope for how much it would take to attend those, versus a much cheaper yet reputable state college.
I used to be in the not eager to have kids category, but then upon having a kid, it has improved my life immeasurably and made me happier in ways I would not have imagined before.
It is interesting, as AWS is part of a bigger company that is on solid footing, and one that has a history of taking hits and playing through.
Azure has proportionally more revenue from "old" businesses, and also a part of a bigger whole, so they are in a decently strong position.
Google compute may be in the most precarious position of the big three in such an event, mainly because the larger whole has a habit of dropping things at the first hint of trouble.
But in any event, that entire industry will get a big hit when the bubble pops, and it will be interesting to see what happens to the existence and/or the pricing of those offerings (the latter of which is already enough to make the prospect of cloud hosting dubious unless you need the geographic distribution and/or needing to avoid capital expense at all cost). My general point is that last time a lot of vendors had solid looking financials, unlike a lot of the startups and looked solid by comparison, but were indirectly on shaky ground by association, and this time the cloud vendors are the big ones on the line. I may have overstated the risk to AWS a tad, but something is going to happen.
The amount of hype around those means that when one goes down, it'll take a great deal of the over-inflated tech industry with it as investors get obvious evidence that 'tech' companies are not fundamentally different than 'non-tech' companies.
Whenever that happens, it'll be 2001 all over again.
This will have some interesting downstream effects on vendors. 2001 pretty much ultimately killed Sun. This time, I'd have my eye on AWS as the troubled vendor this time around (a lot of expense to support revenue that would evaporate all at once in a bubble burst).
To mention HPC, effectively docker's business plan is equivalent to a commercial scheduler. In HPC those do exist (LSF, PBSPro, Moab) but they are mostly purchased for their UI to non-developer types, and those without that need just pick up slurm. A lot of that is informed by knowing that most HPC jobs are of a handful of off the shelf applications, and tailoring UI around those for non-programmer researchers.
Container management is not in that realm right now, and docker swarm doesn't do things in a friendlier way than kubernetes, so they don't have the benefits.
I will give them credit for focusing on integrating device mapper to provide snapshotting and for 'dockerhub' to have a centralized strategy for container sharing.
However, despite those being good ideas, they aren't *difficult* ideas, so it's very hard for them to milk those good ideas for a lot of money.
Saying a container speciliast company is viable is sort of like saying a specialist in fileutils (rm/cp/ls/ln) could be a company. The truth is containers are a solid technology because they are relatively straightforward.
Docker started by wanting to provide some alternative usage scenario to the stuff that LXC was providing. The hardest part of the work was the kernel namespaces, cgroups, and device mapper pieces. Docker had the admittedly good idea of focusing on more disposable application images rather than faking virtual machines. They found success because they were open and could be ubiquitous. If they had tried to be closed, an alternative would have sprung up in a matter of months (you could teach 3 college students about the C code to manipulate namespaces and have them craft a rudimentary docker alternative in a semester).
Then came the challenge of finding a path to profitability. Effectively docker was a really good uber-chroot, and that's not exactly sufficiently sophisticated to make a business out of. So they thought "multi-container management will be it!" and make swarm their commercial strategy.
The problem is, when all is said and done even that isn't exactly hard to craft, so Google came along and provided that essentially in their 'spare time'. If they hadn't bothered, Mesos would have fit the bill.
The state of container technology is such that it is actually underwhelming to use, and I mean that as a compliment. It doesn't feel like some big ordeal that warrants consulting and such, at least no more so than dealing with whatever software runs on top of that layer, which is inevitably much more complex than the effort of launching the containers. It's sort of like a mechanic specializing in only changing your oil filter, but only after you've bought all the supplies, lifted your car, and drained the oil yourself.
By number of tickets sold, it's terrible, yet by revenue it's nearly a record. This means the per seat price to go to a movie is astronomical, which feeds into their problems.
Taking the family out to a movie is one of the most expensive outings to do nowadays. Years ago, over the summer you might go every two weeks over the summer. Now that's not affordable even if you want to do it.
Yes this is also alongside people having gigantic TVs and fantastic sound along with really good furniture that's frequently better than the theater's. So while before you paid to see things on the 'big screen', now you can get that at home. Now you have to want the experience of the theater, the audience, and/or be so impatient to see things when only in theaters.
There's a difference in the operator of a licensed manned airplane and random guy who picked up a toy at Best Buy on a lark.
Both in terms of training and in terms of incremental difficulty of checking TFR compared to the general involved process of preparing for flying and taking off.
Besides, it's bad enough for accidental interference, but if there *is* something that the patrol would catch, then you have an antagonistic adversary and it would not be a good idea for them to be able to knock out air support with an unarmed drone.
Of course, in this case it was more dramatic presumably because they could afford to be. They had an extra vehicle in the patrol, so they could peel off. Replacing the blade is also because they could afford to, in a more urgent situation they could have probably done other options safely.
2. The Army should not have been flying below the drone ceiling.
One of the major points of a TFR is to allow relatively low altitude flying for helicopters patrolling. The incident was at 500 feet, which is a standard daytime helicopter patrol altitude. A helicopter couldn't provide patrol at 1,400 ft, they would just be too far away.
Either way, the software has to do it for the operator in a drone context. As you say, people will get lazy, particularly if taking off is a spur of the moment thing and after the first 20 times not seeing a TFR, you start overlooking it.
The transcode is more about the various embedded devices not having this or that codec available in hardware, and a puny cpu that can't use pure software codec..
I perosnally use emby+kodi. Kodi doesn't have a plex media server alternative, but emby covers that pretty well.
Plex's proprietary nature bugged me, so emby filled that gap. Both do want you to use a premium online connected account, but plex was really obnoxious about it no matter what. emby is more subdued (though I haven't checked out plex lately).
Note I use it to manage my own rips, not so much online videos or streaming services.
Slashdot Mirror
So far, I'd say the masses are augmenting with mobile, but as possible like to go to a full laptop experience because the mobile platform and form factor is just too limiting. This includes teenage relatives and my own child and their friends, they *all* wanted to have laptops *and* phones.
The problem though is that a 10 year old device (if it still works at all) is adequate for pretty much all casual usage, and the hardware update cycle is driven by hardware breaking, people mistaking software problems for aging hardware problems (or just not caring), and fashionable changes more than it is need to actually get new levels of performance.
I do however expect that volumes will never dip below say the mid 90s or so, even proportionally to the general population. The market for PCs exploded, and then for those less purely enthusiast customers, computers became good enough and their money got rerouted to extending their experience to their pockets.
Other than to *prove* it's not needed, at this juncture it seems an odd choice to remove capability.
Particularly to make such a declaration given the reality that the legal framework of operating fully autonomous cars is far from a known thing.
Done correctly, javascript can be a more efficient way of interacting with data server side, both client and server.
Rendering new whole pages is more expensive than manipulating DOM content to handle updates.
Now going over the top with ugly animations like a high schooler with power point.....
One, you'd be surprised how consistent browsers in the last 3-4 years have been.
Two, 99% of the time if you are using java script to animate, you are failing to use the far more efficient CSS to do the same thing, and more easily degrade to accessible use.
Also, $() is a lot slower than the equivalent functions. I will admit to being annoyed by the tedium of the function names, but most editors will do a sane job of completion.
This is an obvious outcome. It's worth keeping in mind that filing a suit does not vindicate or disprove anyone, as there's no way to ascertain whether there will be merit in the suit at this point. All it means is there's enough lawyers willing to make a wager when faced with such a *huge* potential payout.
Of course that's jumping from the 'e' line to the 'normal' desktop line. The closest match would now be i9-7940X or i9-7920X, 12 to 14 cores.
Actually, my thought was that for some things, there must be constraints.
For other things, so long as you have a *good* team that is self motivated, allowing the novel things to come as they are ready can work.
Of course, 'when it's ready' sometimes doesn't work and never happens because everyone is *too* laid back, so it's important to read the situation at hand, but sometimes it works great, for at least part of the work
One of the particular dangers of imposing an arbitrary deadline is that something that doesn't *really* matter is used as a reason to not do something else that *matters a lot*, because you are too busy trying to get something less important out in time.
When you are dealing with a situation with other folks depending on you, then the timetable may matter moreso than how creative it can be.
However novel new capabilities are not generally well served by making up a deadline if one does not naturally exist.
However that later situation drives managers/project managers insane. Why even bother trying if you don't know when you would finish, how can you 'grade' yourself if you don't know when you would deliver, so make up something.
Having a backlog of ideas without a milestone to make them due is a fine thing, but project management *must* have it on a roadmap or else get pissed.
The Pentium FDIV bug:
No sane way to workaround at all, and no way to work around it in real mode operating systems, which mattered a lot at the time. Intel ultimately forced to do a recall because they could not provide accurate results for applications. Three models (60, 66, and 90mhz) exposed and caught *relatively* early and volumes were manageable.
F00F bug:
Feasible OS workarounds for protected mode operating systems with no performance impact. Real mode operating systems still mattered, but if you were running real mode there were tons of other ways to freeze the whole system so F00F wasn't that interesting in real mode anyway. Workarounds looked *ugly*, but they were cheap. Intel screwed up, but software workaround was pretty appropriate.
Meltdown:
There are workarounds, but could be very expensive. At the same time, they have two decades of exposed products and much higher volumes than they had before. So the scope of a recall would be way more massive. The workaround results in reduced performance, not incorrect results. If anything were to happen, I'd bet some sort of small rebate or credit for the performance loss, and telling the world to just deal with the performance impact if they care about security.
Intel pushes a microcode blob out to OSes and board/system vendors.
Those OSes and board/system vendors pull in the blob and issue updates that include them.
Some platforms allow the OS to update microcode at run time, others (particularly most server platforms) forbid microcode updates by the OS and must be applied by firmware.
Either way, the firmware installs some microcode at every boot, then the OS may or may not follow up with an update, so any microcode updates for any platform will appear in both places.
The challenge was that they started following chrome's lead after the exodus of users. The exodus was going to happen regardless.
It is fair to complain that rather than catering to their loyal users, they tried to compete with chrome by being more chrome like, but either way their user share was going to decline.
As someone more thoroughly said, the KPTI patch doesn't make the behavior impossible, it just takes the teeth out of it by unmapping all the juicy things they would want.
Note that partially flushing the cache after a misprediction would certainly mitigate, but there would still be a window where the memory has been cached speculatively and the fault being detected. You instead would have to maintain a mask of cached-but-not-yet-valid-for-issue cache memory, and ignore it in specific scenarios until everything checks out. Of course this probably would be unacceptably slow down on all cache (another lookup table to go through for all cache access), so presumably the more likely true fix is the former (which is also far more straightforward and less likely to have unforeseen hole).
The Harvard/Yale/CalTech/MIT may matter for connections, but at least at places I have worked we haven't afforded them particularly more consideration than other grads. They also don't stand out as seeming particularly more competent or better at interviewing than other schools.
They do some excellent work in academia, but the likely return on investment may be much lower than one might hope for how much it would take to attend those, versus a much cheaper yet reputable state college.
I used to be in the not eager to have kids category, but then upon having a kid, it has improved my life immeasurably and made me happier in ways I would not have imagined before.
It is interesting, as AWS is part of a bigger company that is on solid footing, and one that has a history of taking hits and playing through.
Azure has proportionally more revenue from "old" businesses, and also a part of a bigger whole, so they are in a decently strong position.
Google compute may be in the most precarious position of the big three in such an event, mainly because the larger whole has a habit of dropping things at the first hint of trouble.
But in any event, that entire industry will get a big hit when the bubble pops, and it will be interesting to see what happens to the existence and/or the pricing of those offerings (the latter of which is already enough to make the prospect of cloud hosting dubious unless you need the geographic distribution and/or needing to avoid capital expense at all cost). My general point is that last time a lot of vendors had solid looking financials, unlike a lot of the startups and looked solid by comparison, but were indirectly on shaky ground by association, and this time the cloud vendors are the big ones on the line. I may have overstated the risk to AWS a tad, but something is going to happen.
The amount of hype around those means that when one goes down, it'll take a great deal of the over-inflated tech industry with it as investors get obvious evidence that 'tech' companies are not fundamentally different than 'non-tech' companies.
Whenever that happens, it'll be 2001 all over again.
This will have some interesting downstream effects on vendors. 2001 pretty much ultimately killed Sun. This time, I'd have my eye on AWS as the troubled vendor this time around (a lot of expense to support revenue that would evaporate all at once in a bubble burst).
To mention HPC, effectively docker's business plan is equivalent to a commercial scheduler. In HPC those do exist (LSF, PBSPro, Moab) but they are mostly purchased for their UI to non-developer types, and those without that need just pick up slurm. A lot of that is informed by knowing that most HPC jobs are of a handful of off the shelf applications, and tailoring UI around those for non-programmer researchers.
Container management is not in that realm right now, and docker swarm doesn't do things in a friendlier way than kubernetes, so they don't have the benefits.
I will give them credit for focusing on integrating device mapper to provide snapshotting and for 'dockerhub' to have a centralized strategy for container sharing.
However, despite those being good ideas, they aren't *difficult* ideas, so it's very hard for them to milk those good ideas for a lot of money.
Saying a container speciliast company is viable is sort of like saying a specialist in fileutils (rm/cp/ls/ln) could be a company. The truth is containers are a solid technology because they are relatively straightforward.
Docker started by wanting to provide some alternative usage scenario to the stuff that LXC was providing. The hardest part of the work was the kernel namespaces, cgroups, and device mapper pieces. Docker had the admittedly good idea of focusing on more disposable application images rather than faking virtual machines. They found success because they were open and could be ubiquitous. If they had tried to be closed, an alternative would have sprung up in a matter of months (you could teach 3 college students about the C code to manipulate namespaces and have them craft a rudimentary docker alternative in a semester).
Then came the challenge of finding a path to profitability. Effectively docker was a really good uber-chroot, and that's not exactly sufficiently sophisticated to make a business out of. So they thought "multi-container management will be it!" and make swarm their commercial strategy.
The problem is, when all is said and done even that isn't exactly hard to craft, so Google came along and provided that essentially in their 'spare time'. If they hadn't bothered, Mesos would have fit the bill.
The state of container technology is such that it is actually underwhelming to use, and I mean that as a compliment. It doesn't feel like some big ordeal that warrants consulting and such, at least no more so than dealing with whatever software runs on top of that layer, which is inevitably much more complex than the effort of launching the containers. It's sort of like a mechanic specializing in only changing your oil filter, but only after you've bought all the supplies, lifted your car, and drained the oil yourself.
By number of tickets sold, it's terrible, yet by revenue it's nearly a record. This means the per seat price to go to a movie is astronomical, which feeds into their problems.
Taking the family out to a movie is one of the most expensive outings to do nowadays. Years ago, over the summer you might go every two weeks over the summer. Now that's not affordable even if you want to do it.
Yes this is also alongside people having gigantic TVs and fantastic sound along with really good furniture that's frequently better than the theater's. So while before you paid to see things on the 'big screen', now you can get that at home. Now you have to want the experience of the theater, the audience, and/or be so impatient to see things when only in theaters.
There's a difference in the operator of a licensed manned airplane and random guy who picked up a toy at Best Buy on a lark.
Both in terms of training and in terms of incremental difficulty of checking TFR compared to the general involved process of preparing for flying and taking off.
Besides, it's bad enough for accidental interference, but if there *is* something that the patrol would catch, then you have an antagonistic adversary and it would not be a good idea for them to be able to knock out air support with an unarmed drone.
Of course, in this case it was more dramatic presumably because they could afford to be. They had an extra vehicle in the patrol, so they could peel off. Replacing the blade is also because they could afford to, in a more urgent situation they could have probably done other options safely.
2. The Army should not have been flying below the drone ceiling.
One of the major points of a TFR is to allow relatively low altitude flying for helicopters patrolling. The incident was at 500 feet, which is a standard daytime helicopter patrol altitude. A helicopter couldn't provide patrol at 1,400 ft, they would just be too far away.
Either way, the software has to do it for the operator in a drone context. As you say, people will get lazy, particularly if taking off is a spur of the moment thing and after the first 20 times not seeing a TFR, you start overlooking it.
The transcode is more about the various embedded devices not having this or that codec available in hardware, and a puny cpu that can't use pure software codec..
I perosnally use emby+kodi. Kodi doesn't have a plex media server alternative, but emby covers that pretty well.
Plex's proprietary nature bugged me, so emby filled that gap. Both do want you to use a premium online connected account, but plex was really obnoxious about it no matter what. emby is more subdued (though I haven't checked out plex lately).
Note I use it to manage my own rips, not so much online videos or streaming services.