LCDs have refresh rates; but they don't 'flicker' the way CRTs do(unless the video source instructs them to).
Even when displaying a static image, CRTs show substantial variations in brightness(easily visible with video gear; really annoying to the naked eye with lousier hardware) as the electron guns scan about keeping the right phosphors pumped.
LCDs may flicker at the PWM frequency of the backlight LEDs, if LED backlit; but refresh rate reflects only how often a new image can be sent to the panel, not how often the electron gun redraws the image; so unless the input video is flickery, an LCD won't show appreciable flicker at any refresh rate. The only real issue is if the refresh rate is low enough that you can no longer generate a convincing illusion of continuous motion for things like mouse pointers(opinions vary; but 30Hz drove me nuts for that reason).
You joke; but games are actually one of the places where Flash(though not Adobe Flash) is arguably most tasteful and inoffensive(plus, since it isn't trying to render arbitrary stuff from wildly untrustworthy sources all the time, probably safest).
I haven't seen it as much as I used to; but 'Scaleform' is a reasonably popular middleware package that allows you to embed vector art assets authored with Flash tools into 3d engines; typically used for drawing UIs, 2D labels, etc. for 3D engines that had needs for which polygon-based stuff wasn't the best approach. Civ IV's UI, among a variety of others, was done that way.
I'm told that, as the supply of artists familiar with Flash has declined, along with Flash's popularity, the trend has been toward embedding a tame webkit derivative and using its text rendering and SVG support instead; but for all its sins on the web, Flash isn't a particularly illogical choice if you need to add some vector graphics to a 3d environment; and Scaleform was the implementation optimized for doing that.
This is basically never the reason why hideous giant webpages are bloated(or why lean, bandwidth friendly websites aren't); but complexity and bulk are actually pretty weakly related.
In the most extreme cases, you have the demoscene and procedural generation types using relatively compact, but mathematically hairy, techniques to avoid pre-canned art assets as much as possible; on the other side you have audio, video, and images uncompressed or with primitive codecs that offer really, really, trivial implementation but are absolutely enormous.
In the case of websites, most of the big ones are just bloated; and most of the small ones are just KISS-based; but with something like 3d engines; the complexity is substantially greater; but a lot of 'a different sprite for every possible combination of angle and action' art assets were eliminated in favor a polygon model with some textures. A great deal more math involved; but not necessarily bigger files(though this led to an unfortunate period where a number of franchises discarded really nice looking 2D engines, primitive; but with excellent production values and art direction, in favor of 3D engines that were just muddy, bland, low-poly messes on any hardware you could actually afford at the time. Mostly a solved problem now; but it was an ugly transition).
Even if the unpredictability ends up being a software issue that can be ironed out, so that repeated runs of the same workload at least produce the same results; it's hard to imagine the overall story on battery life is going to be a happy one. The 13in model was cut from 74.9WHr to 49.2; and the 15in from 99.5 to 76.
Apparently they've improved the efficiency of the screen; but more or less all of the efficiency improvement in the move from Broadwell to Skylake CPUs has been in the low power modes; and how quickly the CPUs can move in and out of them; but draw when under load is pretty much the same. In the models with a discrete GPU that might kick in, the difference between idling and load will be even more dramatic.
The new ones might well sleep more soundly than their predecessors; but Apple hacked off 25-30% of the battery capacity without being able to do much about consumption under load. That is going to make them more sensitive to what you are using them for than previously, even assuming perfect avoidance of unnecessary load, spurious wakeups, etc.
Even if the cause of the results were some really oddball bug like that; why would that matter?
If I'm a user of one of these devices and between 8% and 19% of page loads trigger atypical load on odd numbered days my battery life will also be unpredictable and short; which would make me an unhappy customer with a problematic device.
It's only a testing flaw if it's one of the nasty Heisenbugs that are actually caused by the fact that you are testing(eg. if safari's freaky rendering issue occurs only under certain circumstances where it is being script-driven in a particular way; but never otherwise). Otherwise, it may be a really cryptic issue that the tester doesn't know enough to actually diagnose; but if their tests are sufficiently representative of real-world loads; it's a cryptic issue that users risk running into as well, so the test is providing exactly the information it is supposed to. The point of this sort of testing is to attempt to simulate real world use and see how it goes; not to elucidate the deep mysteries of the product. That sort of testing does require avoiding test procedures that cause wildly unrealistic things to happen; but requires no particularly deep understanding of the system being tested, since you need only to do a slightly more automated and quantified version of what the end user is expected to do.
That does seem like a question at least worth throwing some mice at; but also one that may be aging itself out: I can't really remember the last time I actually used a CRT for any length of time; and the nasty iron ballast fluorescent drivers seem to be less common as well, though not as aggressively replaced if they aren't failing.
At this point, most of the flicker has moved well away from mains-induced frequencies and up into PWM brightness control; that could also have an effect; but it's a much, much, higher frequency flicker unless somebody did a really obnoxious job.
No disagreement here on the quality of craftsmanship that goes into the average webpage. On the other hand; can you imagine how...glorious...the web would be if everyone who didn't have John Carmack on staff still needed to hammer out a bunch of clever tricks in C to get a site up and running?
It isn't at all elegant; but unless someone discovers a way to churn out good programmers with unprecedented efficiency, I can't say too many mean things about tools that let terrible programmers get merely bad results, since we appear to demand more software than we have talent to supply.
This would involve admitting the (arguably ugly; but undeniable) truth that web pages have become a somewhat dysfunctional software development platform; but it'd be nice to see browser caching mechanisms that don't just treat giant JS libraries as a special case of cacheable assets generally and hope for the best; and instead offered something more in the vein of what Linux package managers do.
If you host your own; the user ends up downloading a copy even if it is identical to the one they pulled from somebody else for a different site that uses the same library. If you avail yourself of Google's...generous...hosted offer, the user is more likely to cache; but then every load of your page also involves a chat with Team Mountain View.
Ideally, you'd specify that you use JSLibXYZ, with cryptographic has and/or signature specified, and at least one source for a client who doesn't have it to get a copy; but the user's browser could make use of JSLibXYZ from any source, so long as the hash and signature match, since that provides assurance that it's the same thing. Caching mechanisms based on domain of origin are sensible enough for assets that are likely to be site specific(pictures, stylesheets, etc.); but, like it or not, giant javascript libraries, many shared across a large number of otherwise unrelated sites, have a lot more in common with dlls than with images; and it would be handy if they were treated as being a different case. With hashes and/or signatures, you could ensure integrity even in cross-site sharing situations; allow caching to work regardless of how the site operator has set up script hosting, and end the choice between 'serve yourself, lose out of caching/let google do it, get caching but add a 3rd party to everything you do'.
There may well be some missed opportunities that I'm in no way qualified to comment on; but at least part of the "browser performance goes to hell when you have a zillion tabs open"/"it takes ages to restore a zillion tabs on restart" trouble seems likely to be connected to the fact that web pages have, somewhat awkwardly, evolved from being pretty much pure markup with a small sprinkling of javascript(which had the advantage, both for inexpensive background storage and quick restoration, of being nearly stateless, aside from any form fields that had been filled in; and could be stored or re-rendered from cached assets at your convenience); to being pretty much full applications, with lots of state all over the place; and often a variety of assumptions on the server side about what the client side is doing and vice versa. You can put such a page on ice; or dump it and re-render it from cached assets; but if you do, don't be surprised if you get dumped to a login screen or the page ignores most of what you've saved on its behalf and starts xmlhttp-request-ing anything that might have changed since it has been away.
If you feed them retro websites, or sites designed by people with classic taste, contemporary browsers are faster than a bat out of hell with rocket boosters. That just doesn't help you against modern websites; which are both bloated(typically with slow-as-hell 3rd party ad code, just to add injury to insult); and still somewhat awkwardly trying to move from a caching model mostly designed to keep pictures from being unnecessarily retransmitted to something suitable for letting full applications pick up where they left off.
Somebody who steals and uses other people's phones isn't exactly a model citizen; but the notion that an Egyptian immigrant who doesn't...exactly...look to be living the high life would want cheap telecommunications, prefer an Arabic localization, call home periodically; and take 'his' phone in to the shop for a look when its weird behavior becomes too jarring to ignore doesn't seem terribly suspicious.
Yes, I suppose a particularly low-budget terrorist might also do all those things(though apparently the ISIS-preferred model for command-detonated IEDs is a nokia; unknown if this means that Mr. Elop needs to watch his back for what he did); but that is true in the same (largely useless) sense that "the guy at the shooting range plinking away with his AR-15 is doing what somebody practicing for a spree killing might do" is true. Yes, it isn't false; but the worrisome cases are drowned out be the number of similar looking and uninteresting cases.
If this were some random guy's Hackaday project; I'd be inclined to give it a friendly look, so long as he was willing to be good natured about admitting the rough edges; but we aren't exactly talking genius-level work; much less 'so genius it only happens in fictional settings where the title 'Dr.' implies cutting edge knowledge of at least a half-dozen disciplines...' level work.
If Zuck wants to be Tony Stark; I wouldn't necessarily mind him heading off to prove it by being seriously wounded and trapped in some hellhole with only a box of scrap; and escaping by quickly whipping together a suit of power armor; but a home automation system where the text parser works OK; but voice recognition is flaky as hell even for a relatively tiny set of possible commands and one user voice? That's more Walter Mitty than Tony Stark.
They bought QNX a while back, to use as a foundation for their modernization of the OS that runs on Blackberries('Blackberry 10' is QNX-based, 'Blackberry OS', v. 1-7.x are something much heavier on java).
Unless I'm missing something, they've announced an, um, bold and inspiring plan to attempt to continue selling QNX for basically the same applications that QNX was sold for before they bought it.
Beats letting it just rot in a back catalog somewhere; but "We plan to sell the product of a company we bought for the same sorts of things it was good for when we bought them, and that's pretty much it." isn't exactly the behavior of a company that has any idea what to do with itself.
Yeah, I was curious about what instruments it might have been carrying. If it's just stuff that any grad student at Wood's Hole wouldn't bat an eye at; the reverse-engineering value is likely close to zero; and the purpose most likely provocation/diplomatic posturing. If it's a fairly boring chassis; but has a classy Navy sonar array and some DSPs with proprietary code on them, that would be more likely to be worth a look even aside from the 'tweaking the Americans' value.
I'm on partial agreement with you on that: I agree that (given the sometimes fairly high complexity of media codecs; and the fact that the web is a malicious place) media rendering code needs to be given much, much more aggressive handling in terms of sandboxing/privilege restriction. If all the decoder needs to do is provide audio suitable to be fed to the soundcard; or provide a series of frames to be painted wherever the video is supposed to be playing, there is no reason for it to be running with all the privileges of the user account; much less some more-privileged account if the implementation is a real disaster.
That said, SPC audio is still seriously obscure, and used almost exclusively by people who know exactly what it is; so given that skepticism about security is the only safe stance when approaching a media codec/component; it still would have saved a lot of people some potential risk to have omitted it. Without the architectural reforms you suggest, people who do install libgme because they are doing chiptunes stuff would still be vulnerable; but the problem could have been avoided, even without any architectural changes, for most users just by omitting it.
At least officially, the Korean systems have a human in the loop: the robot is capable of using its sensors, and some sort of machine vision, to nominate targets; it's not just a dumb turret with a joystick; but somebody has to press the button. Obviously, unless their defense contractors make ours look like paragons of efficiency; that could be fixed in a firmware update before lunch.
Like many of the proclamations from the UN, such a ban will have little influence over the development and use of "killer robots".
Some arms control treaties have been relatively successful; but I wouldn't be optimistic here:
Somethings are just too convenient to ban; and those are usually a lost cause; but among stuff you can get support for; there seems to be a difference between hardware where you can say 'no legitimate use, period' and hardware where certain uses are forbidden; but there are enough legitimate use cases that the relevant hardware remains in stock, widely available to people relatively low on the food chain, and easily amenable to quiet 'off label' use.
Military small arms ammunition, say, tends to be pretty reliably jacketed, even disreputable outfits don't tend to produce their own dum-dums and hollowpoints; though irregular forces and police-derived paramilitaries are obviously more likely to be using weapons not concerned with Geneva convention compliance in the first place.
Stuff with both 'legitimate' and 'illegitimate' uses has been harder to keep a lid on. Phosphorus is a lovely illuminating agent; and produces great smoke; but it's considered poor taste to use it as an incendiary. Hard to make that stick when a large number of people, relatively low on the food chain, have access to it because of its legitimate applications, though.
In the case of 'killer robots'; the obvious problem is that all the hardware; and much of the software for a 'killer robot' will be identical to that of a 'human directed' robot with some automation of routine navigation stuff; machine-vision-assisted targeting and IFF, and so on. So long as you pinkie-swear that a human will have to press the 'make it so' button; you can develop all the elements, navigation, targeting, etc. that an autonomous killbot would need; but make sure that the firmware running on anything pesky journalists get to see has a human pressing the red button to approve what the autonomous killbot comes up with.
"Good faith" adherents to a 'no killbots' rule will likely find themselves easing their way toward autonomy with some (admittedly plausible) special cases: "We can't keep a human in the loop for our CIWS/RAM system; human reflexes aren't fast enough for contemporary missile intercept; but don't worry, the CIWS turrets are bolted onto the ship and aren't going to go wandering off." Not false; but an autonomous killbot. Then we'll need an 'emergency defensive protocol' for human-oversight robots that lose their link to HQ, whether to technical failure or hostile jamming; which will be OK; because it's strictly for the robots to engage in defensive actions in their existing location until communication is restored!
People who don't give a damn, of course, will just stub out the 'ask human for confirmation' part and carry on with their day.
Aside from this, some lucky logic-chopper is going to have the unenviable task of explaining why existing, more or less universally accepted, 'fire-and-forget' missiles and other similar hardware that gets its activation command from a human; but thereafter guides itself to target without external intervention, isn't a killbot; but the more drone-shaped hardware that gets its initial activation command from a human; but thereafter guides itself to target without external intervention, is a killbot.
People claiming that diplomatic pressure and arms control conventions are totally useless are seriously exaggerating their case(land mines, chemical, and biological weapons certainly are way down; people have been jumpy about blinding laser weapons, etc.); but there is a lot less room for optimism when you can't draw a bright line around whatever you are trying to ban and declare it and everything similar Off Limits.
With Killbots, I'm not optimistic: too much of the tech is shared with 100% legit 'human approved, machine assisted' systems; and the excuses to get a foot in the door(even if you care enough about perception of legality to not simply quietly switch off human approval) are too plausible.
(Edit: the one arguably major vice of code reuse is that it makes lazy over-inclusion easy and tempting. We had a story a few days back about some fairly common 'default' desktop linux setups that were vulnerable because of a bug in the implementation of the emulator of one of the chips in the SNES. Outside of chiptunes enthusiasts and some of the more serious console emulation wonks, almost nobody is likely to ever see SPC audio; and the few people who will are likely to know what it is and be minimally inconvenienced by having to open their package manager and install libgme. But, since it was available as a Gstreamer plugin; the more the merrier! and into the default config it went. Given that software not produced under very, very, unusual attention to detail and correctness, which is almost all software, can be reasonably expected to risk some bugs; you don't want to be throwing in libraries that you have little or no use for, just because it's easy, which is certainly less likely if everything you include you have to write yourself; but aside from that there just isn't a(realistic) better option to code reuse. If your practices are too shoddy to even keep your 3rd party dependencies up to date; your DIY attempt is unlikely to be pretty; while if you are good enough to DIY properly; you certainly aren't obligated to stop; but you can probably handle keeping an eye on 3rd party dependencies.)
Do we have any info on the purpose/sophistication of this UUV? They may not have intended to bring the spy plane down; but once that happened, they spent a fair while going through the hardware, though they sent the crew home pretty quickly.
Is this just some boring more or less off-the-shelf research widget that any university with an oceanography team has an equivalent of on the shelf(in which case messing with it is presumably pure posturing)? Or is there something onboard worth doing a bit of reverse engineering on?
Unless the hardware is vastly overqualified, just fixing it in software probably isn't an option. Doing encryption in software isn't too painful on a real computer; but cameras tend to have fairly feeble, power constrained, processors with any special-purpose hardware dedicated either to image processing or shovelling data from the sensor to the SD card as fast as possible. I'm sure you could fit an encryption implementation within the limits of a reasonably modern camera's hardware; but actually using it would do horrible things to the frame rate.
Reports mention that the failure to acquire an address is, at least sometimes, tied to the "Connected Devices Platform Service" crashing. Apparently this service is "used for Connected Devices and Universal Glass scenarios", which really clears things up.
Nobody seems to have much to say on what exactly the 'connected devices platform' is; but it sounds like the problem isn't with the DHCP client itself; but with some questionably sensible abstraction layer failing at automagic above it, in the service of some windows-everywhere-in-the-connected-home fever dream.
Sort of like the time they broke all those webcams, not by monkeying with UVC support; but by quietly inserting a poorly thought out frameserver without telling anyone because being able to log in with your face is obviously more important than Directshow working as expected.
In a sense, this is almost surprising: not because any sane person would expect Uber management to not be a bunch of shitbags; but because companies that take spying on their customers seriously tend to realize that the data they are gathering has value; and jealously guard it from people who aren't paying them for access.
It is...immature...of Uber to be wasting their time on stalker-bro antics when they could be using this sort of pervasive location data collection for all sorts of creepy ad-targeting and consumer profiling stuff, like respectable professionals.
I, for one, know that when I think "security" and "timely updates" and "product lifecycles long enough for things I'm going to embed in my building"; I think "Android".
And, when it comes to support and ecosystem consistency for IoT, I think "Google"; because they've earned my trust!
Seriously guys? I realize that 'IoT' is a garbage fire in a hazmat facility at this point; but adding Android? What are you thinking?
Slashdot Mirror
LCDs have refresh rates; but they don't 'flicker' the way CRTs do(unless the video source instructs them to).
Even when displaying a static image, CRTs show substantial variations in brightness(easily visible with video gear; really annoying to the naked eye with lousier hardware) as the electron guns scan about keeping the right phosphors pumped.
LCDs may flicker at the PWM frequency of the backlight LEDs, if LED backlit; but refresh rate reflects only how often a new image can be sent to the panel, not how often the electron gun redraws the image; so unless the input video is flickery, an LCD won't show appreciable flicker at any refresh rate. The only real issue is if the refresh rate is low enough that you can no longer generate a convincing illusion of continuous motion for things like mouse pointers(opinions vary; but 30Hz drove me nuts for that reason).
You joke; but games are actually one of the places where Flash(though not Adobe Flash) is arguably most tasteful and inoffensive(plus, since it isn't trying to render arbitrary stuff from wildly untrustworthy sources all the time, probably safest).
I haven't seen it as much as I used to; but 'Scaleform' is a reasonably popular middleware package that allows you to embed vector art assets authored with Flash tools into 3d engines; typically used for drawing UIs, 2D labels, etc. for 3D engines that had needs for which polygon-based stuff wasn't the best approach. Civ IV's UI, among a variety of others, was done that way.
I'm told that, as the supply of artists familiar with Flash has declined, along with Flash's popularity, the trend has been toward embedding a tame webkit derivative and using its text rendering and SVG support instead; but for all its sins on the web, Flash isn't a particularly illogical choice if you need to add some vector graphics to a 3d environment; and Scaleform was the implementation optimized for doing that.
This is basically never the reason why hideous giant webpages are bloated(or why lean, bandwidth friendly websites aren't); but complexity and bulk are actually pretty weakly related.
In the most extreme cases, you have the demoscene and procedural generation types using relatively compact, but mathematically hairy, techniques to avoid pre-canned art assets as much as possible; on the other side you have audio, video, and images uncompressed or with primitive codecs that offer really, really, trivial implementation but are absolutely enormous.
In the case of websites, most of the big ones are just bloated; and most of the small ones are just KISS-based; but with something like 3d engines; the complexity is substantially greater; but a lot of 'a different sprite for every possible combination of angle and action' art assets were eliminated in favor a polygon model with some textures. A great deal more math involved; but not necessarily bigger files(though this led to an unfortunate period where a number of franchises discarded really nice looking 2D engines, primitive; but with excellent production values and art direction, in favor of 3D engines that were just muddy, bland, low-poly messes on any hardware you could actually afford at the time. Mostly a solved problem now; but it was an ugly transition).
Even if the unpredictability ends up being a software issue that can be ironed out, so that repeated runs of the same workload at least produce the same results; it's hard to imagine the overall story on battery life is going to be a happy one. The 13in model was cut from 74.9WHr to 49.2; and the 15in from 99.5 to 76.
Apparently they've improved the efficiency of the screen; but more or less all of the efficiency improvement in the move from Broadwell to Skylake CPUs has been in the low power modes; and how quickly the CPUs can move in and out of them; but draw when under load is pretty much the same. In the models with a discrete GPU that might kick in, the difference between idling and load will be even more dramatic.
The new ones might well sleep more soundly than their predecessors; but Apple hacked off 25-30% of the battery capacity without being able to do much about consumption under load. That is going to make them more sensitive to what you are using them for than previously, even assuming perfect avoidance of unnecessary load, spurious wakeups, etc.
Even if the cause of the results were some really oddball bug like that; why would that matter?
If I'm a user of one of these devices and between 8% and 19% of page loads trigger atypical load on odd numbered days my battery life will also be unpredictable and short; which would make me an unhappy customer with a problematic device.
It's only a testing flaw if it's one of the nasty Heisenbugs that are actually caused by the fact that you are testing(eg. if safari's freaky rendering issue occurs only under certain circumstances where it is being script-driven in a particular way; but never otherwise). Otherwise, it may be a really cryptic issue that the tester doesn't know enough to actually diagnose; but if their tests are sufficiently representative of real-world loads; it's a cryptic issue that users risk running into as well, so the test is providing exactly the information it is supposed to. The point of this sort of testing is to attempt to simulate real world use and see how it goes; not to elucidate the deep mysteries of the product. That sort of testing does require avoiding test procedures that cause wildly unrealistic things to happen; but requires no particularly deep understanding of the system being tested, since you need only to do a slightly more automated and quantified version of what the end user is expected to do.
That does seem like a question at least worth throwing some mice at; but also one that may be aging itself out: I can't really remember the last time I actually used a CRT for any length of time; and the nasty iron ballast fluorescent drivers seem to be less common as well, though not as aggressively replaced if they aren't failing.
At this point, most of the flicker has moved well away from mains-induced frequencies and up into PWM brightness control; that could also have an effect; but it's a much, much, higher frequency flicker unless somebody did a really obnoxious job.
Just a chance to make friends with the Van Allen radiation belt. Don't worry.
No disagreement here on the quality of craftsmanship that goes into the average webpage. On the other hand; can you imagine how...glorious...the web would be if everyone who didn't have John Carmack on staff still needed to hammer out a bunch of clever tricks in C to get a site up and running?
It isn't at all elegant; but unless someone discovers a way to churn out good programmers with unprecedented efficiency, I can't say too many mean things about tools that let terrible programmers get merely bad results, since we appear to demand more software than we have talent to supply.
This would involve admitting the (arguably ugly; but undeniable) truth that web pages have become a somewhat dysfunctional software development platform; but it'd be nice to see browser caching mechanisms that don't just treat giant JS libraries as a special case of cacheable assets generally and hope for the best; and instead offered something more in the vein of what Linux package managers do.
If you host your own; the user ends up downloading a copy even if it is identical to the one they pulled from somebody else for a different site that uses the same library. If you avail yourself of Google's...generous...hosted offer, the user is more likely to cache; but then every load of your page also involves a chat with Team Mountain View.
Ideally, you'd specify that you use JSLibXYZ, with cryptographic has and/or signature specified, and at least one source for a client who doesn't have it to get a copy; but the user's browser could make use of JSLibXYZ from any source, so long as the hash and signature match, since that provides assurance that it's the same thing. Caching mechanisms based on domain of origin are sensible enough for assets that are likely to be site specific(pictures, stylesheets, etc.); but, like it or not, giant javascript libraries, many shared across a large number of otherwise unrelated sites, have a lot more in common with dlls than with images; and it would be handy if they were treated as being a different case. With hashes and/or signatures, you could ensure integrity even in cross-site sharing situations; allow caching to work regardless of how the site operator has set up script hosting, and end the choice between 'serve yourself, lose out of caching/let google do it, get caching but add a 3rd party to everything you do'.
There may well be some missed opportunities that I'm in no way qualified to comment on; but at least part of the "browser performance goes to hell when you have a zillion tabs open"/"it takes ages to restore a zillion tabs on restart" trouble seems likely to be connected to the fact that web pages have, somewhat awkwardly, evolved from being pretty much pure markup with a small sprinkling of javascript(which had the advantage, both for inexpensive background storage and quick restoration, of being nearly stateless, aside from any form fields that had been filled in; and could be stored or re-rendered from cached assets at your convenience); to being pretty much full applications, with lots of state all over the place; and often a variety of assumptions on the server side about what the client side is doing and vice versa. You can put such a page on ice; or dump it and re-render it from cached assets; but if you do, don't be surprised if you get dumped to a login screen or the page ignores most of what you've saved on its behalf and starts xmlhttp-request-ing anything that might have changed since it has been away.
If you feed them retro websites, or sites designed by people with classic taste, contemporary browsers are faster than a bat out of hell with rocket boosters. That just doesn't help you against modern websites; which are both bloated(typically with slow-as-hell 3rd party ad code, just to add injury to insult); and still somewhat awkwardly trying to move from a caching model mostly designed to keep pictures from being unnecessarily retransmitted to something suitable for letting full applications pick up where they left off.
At least you guys are better at keeping the water out than the Italians are, so it won't look too much like Venice.
Somebody who steals and uses other people's phones isn't exactly a model citizen; but the notion that an Egyptian immigrant who doesn't...exactly...look to be living the high life would want cheap telecommunications, prefer an Arabic localization, call home periodically; and take 'his' phone in to the shop for a look when its weird behavior becomes too jarring to ignore doesn't seem terribly suspicious.
Yes, I suppose a particularly low-budget terrorist might also do all those things(though apparently the ISIS-preferred model for command-detonated IEDs is a nokia; unknown if this means that Mr. Elop needs to watch his back for what he did); but that is true in the same (largely useless) sense that "the guy at the shooting range plinking away with his AR-15 is doing what somebody practicing for a spree killing might do" is true. Yes, it isn't false; but the worrisome cases are drowned out be the number of similar looking and uninteresting cases.
By 'Clapper' do you mean the as-seen-on-tv acoustically controlled switch; or the NSA perjurer?
In a 'smart home' scenario I could imagine either having control over the light switch.
If so, the money has really gone to his head.
If this were some random guy's Hackaday project; I'd be inclined to give it a friendly look, so long as he was willing to be good natured about admitting the rough edges; but we aren't exactly talking genius-level work; much less 'so genius it only happens in fictional settings where the title 'Dr.' implies cutting edge knowledge of at least a half-dozen disciplines...' level work.
If Zuck wants to be Tony Stark; I wouldn't necessarily mind him heading off to prove it by being seriously wounded and trapped in some hellhole with only a box of scrap; and escaping by quickly whipping together a suit of power armor; but a home automation system where the text parser works OK; but voice recognition is flaky as hell even for a relatively tiny set of possible commands and one user voice? That's more Walter Mitty than Tony Stark.
They bought QNX a while back, to use as a foundation for their modernization of the OS that runs on Blackberries('Blackberry 10' is QNX-based, 'Blackberry OS', v. 1-7.x are something much heavier on java).
Unless I'm missing something, they've announced an, um, bold and inspiring plan to attempt to continue selling QNX for basically the same applications that QNX was sold for before they bought it.
Beats letting it just rot in a back catalog somewhere; but "We plan to sell the product of a company we bought for the same sorts of things it was good for when we bought them, and that's pretty much it." isn't exactly the behavior of a company that has any idea what to do with itself.
Yeah, I was curious about what instruments it might have been carrying. If it's just stuff that any grad student at Wood's Hole wouldn't bat an eye at; the reverse-engineering value is likely close to zero; and the purpose most likely provocation/diplomatic posturing. If it's a fairly boring chassis; but has a classy Navy sonar array and some DSPs with proprietary code on them, that would be more likely to be worth a look even aside from the 'tweaking the Americans' value.
I'm on partial agreement with you on that: I agree that (given the sometimes fairly high complexity of media codecs; and the fact that the web is a malicious place) media rendering code needs to be given much, much more aggressive handling in terms of sandboxing/privilege restriction. If all the decoder needs to do is provide audio suitable to be fed to the soundcard; or provide a series of frames to be painted wherever the video is supposed to be playing, there is no reason for it to be running with all the privileges of the user account; much less some more-privileged account if the implementation is a real disaster.
That said, SPC audio is still seriously obscure, and used almost exclusively by people who know exactly what it is; so given that skepticism about security is the only safe stance when approaching a media codec/component; it still would have saved a lot of people some potential risk to have omitted it. Without the architectural reforms you suggest, people who do install libgme because they are doing chiptunes stuff would still be vulnerable; but the problem could have been avoided, even without any architectural changes, for most users just by omitting it.
At least officially, the Korean systems have a human in the loop: the robot is capable of using its sensors, and some sort of machine vision, to nominate targets; it's not just a dumb turret with a joystick; but somebody has to press the button. Obviously, unless their defense contractors make ours look like paragons of efficiency; that could be fixed in a firmware update before lunch.
Like many of the proclamations from the UN, such a ban will have little influence over the development and use of "killer robots".
Some arms control treaties have been relatively successful; but I wouldn't be optimistic here:
Somethings are just too convenient to ban; and those are usually a lost cause; but among stuff you can get support for; there seems to be a difference between hardware where you can say 'no legitimate use, period' and hardware where certain uses are forbidden; but there are enough legitimate use cases that the relevant hardware remains in stock, widely available to people relatively low on the food chain, and easily amenable to quiet 'off label' use.
Military small arms ammunition, say, tends to be pretty reliably jacketed, even disreputable outfits don't tend to produce their own dum-dums and hollowpoints; though irregular forces and police-derived paramilitaries are obviously more likely to be using weapons not concerned with Geneva convention compliance in the first place.
Stuff with both 'legitimate' and 'illegitimate' uses has been harder to keep a lid on. Phosphorus is a lovely illuminating agent; and produces great smoke; but it's considered poor taste to use it as an incendiary. Hard to make that stick when a large number of people, relatively low on the food chain, have access to it because of its legitimate applications, though.
In the case of 'killer robots'; the obvious problem is that all the hardware; and much of the software for a 'killer robot' will be identical to that of a 'human directed' robot with some automation of routine navigation stuff; machine-vision-assisted targeting and IFF, and so on. So long as you pinkie-swear that a human will have to press the 'make it so' button; you can develop all the elements, navigation, targeting, etc. that an autonomous killbot would need; but make sure that the firmware running on anything pesky journalists get to see has a human pressing the red button to approve what the autonomous killbot comes up with.
"Good faith" adherents to a 'no killbots' rule will likely find themselves easing their way toward autonomy with some (admittedly plausible) special cases: "We can't keep a human in the loop for our CIWS/RAM system; human reflexes aren't fast enough for contemporary missile intercept; but don't worry, the CIWS turrets are bolted onto the ship and aren't going to go wandering off." Not false; but an autonomous killbot. Then we'll need an 'emergency defensive protocol' for human-oversight robots that lose their link to HQ, whether to technical failure or hostile jamming; which will be OK; because it's strictly for the robots to engage in defensive actions in their existing location until communication is restored!
People who don't give a damn, of course, will just stub out the 'ask human for confirmation' part and carry on with their day.
Aside from this, some lucky logic-chopper is going to have the unenviable task of explaining why existing, more or less universally accepted, 'fire-and-forget' missiles and other similar hardware that gets its activation command from a human; but thereafter guides itself to target without external intervention, isn't a killbot; but the more drone-shaped hardware that gets its initial activation command from a human; but thereafter guides itself to target without external intervention, is a killbot.
People claiming that diplomatic pressure and arms control conventions are totally useless are seriously exaggerating their case(land mines, chemical, and biological weapons certainly are way down; people have been jumpy about blinding laser weapons, etc.); but there is a lot less room for optimism when you can't draw a bright line around whatever you are trying to ban and declare it and everything similar Off Limits.
With Killbots, I'm not optimistic: too much of the tech is shared with 100% legit 'human approved, machine assisted' systems; and the excuses to get a foot in the door(even if you care enough about perception of legality to not simply quietly switch off human approval) are too plausible.
(Edit: the one arguably major vice of code reuse is that it makes lazy over-inclusion easy and tempting. We had a story a few days back about some fairly common 'default' desktop linux setups that were vulnerable because of a bug in the implementation of the emulator of one of the chips in the SNES. Outside of chiptunes enthusiasts and some of the more serious console emulation wonks, almost nobody is likely to ever see SPC audio; and the few people who will are likely to know what it is and be minimally inconvenienced by having to open their package manager and install libgme. But, since it was available as a Gstreamer plugin; the more the merrier! and into the default config it went. Given that software not produced under very, very, unusual attention to detail and correctness, which is almost all software, can be reasonably expected to risk some bugs; you don't want to be throwing in libraries that you have little or no use for, just because it's easy, which is certainly less likely if everything you include you have to write yourself; but aside from that there just isn't a(realistic) better option to code reuse. If your practices are too shoddy to even keep your 3rd party dependencies up to date; your DIY attempt is unlikely to be pretty; while if you are good enough to DIY properly; you certainly aren't obligated to stop; but you can probably handle keeping an eye on 3rd party dependencies.)
Do we have any info on the purpose/sophistication of this UUV? They may not have intended to bring the spy plane down; but once that happened, they spent a fair while going through the hardware, though they sent the crew home pretty quickly.
Is this just some boring more or less off-the-shelf research widget that any university with an oceanography team has an equivalent of on the shelf(in which case messing with it is presumably pure posturing)? Or is there something onboard worth doing a bit of reverse engineering on?
Unless the hardware is vastly overqualified, just fixing it in software probably isn't an option. Doing encryption in software isn't too painful on a real computer; but cameras tend to have fairly feeble, power constrained, processors with any special-purpose hardware dedicated either to image processing or shovelling data from the sensor to the SD card as fast as possible. I'm sure you could fit an encryption implementation within the limits of a reasonably modern camera's hardware; but actually using it would do horrible things to the frame rate.
Reports mention that the failure to acquire an address is, at least sometimes, tied to the "Connected Devices Platform Service" crashing. Apparently this service is "used for Connected Devices and Universal Glass scenarios", which really clears things up.
Nobody seems to have much to say on what exactly the 'connected devices platform' is; but it sounds like the problem isn't with the DHCP client itself; but with some questionably sensible abstraction layer failing at automagic above it, in the service of some windows-everywhere-in-the-connected-home fever dream.
Sort of like the time they broke all those webcams, not by monkeying with UVC support; but by quietly inserting a poorly thought out frameserver without telling anyone because being able to log in with your face is obviously more important than Directshow working as expected.
In a sense, this is almost surprising: not because any sane person would expect Uber management to not be a bunch of shitbags; but because companies that take spying on their customers seriously tend to realize that the data they are gathering has value; and jealously guard it from people who aren't paying them for access.
It is...immature...of Uber to be wasting their time on stalker-bro antics when they could be using this sort of pervasive location data collection for all sorts of creepy ad-targeting and consumer profiling stuff, like respectable professionals.
I, for one, know that when I think "security" and "timely updates" and "product lifecycles long enough for things I'm going to embed in my building"; I think "Android".
And, when it comes to support and ecosystem consistency for IoT, I think "Google"; because they've earned my trust!
Seriously guys? I realize that 'IoT' is a garbage fire in a hazmat facility at this point; but adding Android? What are you thinking?