That hasn't been true for a while. It's up to the customer each time whether to have the payload stacked or not, but for the last largish number of vehicles - since F9-14 I think? - they've mostly been doing it this way. It saves time (don't need to return the rocket to the assembly building, add the payload, then roll it out and erect it again) and should also reduce risk of a launch failure (less messing around with the rocket between the static fire - which is basically a dress rehearsal - and the actual launch).
There wasn't *any* part that was firing. They were still only fuelling it up; the static fire hadn't started yet. The engines were cold (literally; they chill the engines before start). But yes, the problem started in (or near) the second stage, which wouldn't even have started its engine chill, I think (normally that starts a couple minutes after launch, though maybe they do a MVac chill cycle for static fires too; not sure).
Also, problems like this are the reason why human-rated spacecraft have launch escape systems. Well, human-rated craft other than the Space Shuttle, at least. Did you watch the Dragon 2 Launch Pad Abort video from last year? If anything goes wrong. the capsule blasts all eight of its thrusters to full and takes off like a bat out of hell. It's completely automated, as well; it'll happen faster than a human could ever react.
This is correct. They *can* do the static fire without the payload attached - and for many early launches, that's what they did - but it takes longer between static fire and launch. With the launch window coming only three days away, and no incident like this having occurred in approximately forever (they didn't even have the engines lit yet!) saving some time and (presumably) risk by having the payload stacked on the rocket probably made sense... to the satellite owner.
It wasn't even SpaceX's decision; the payload owner makes the choices like that.
It's covered by insurance, just not *launch* insurance. You thought they wouldn't have a $200M machine covered by insurance for every step of its trip into space?
But yeah, Facebook was just going to pay for part of the satellite's capacity, they were definitely not the owner in any way.
You are comparing apples to oranges. Progress is a spacecraft, not a rocket. Falcon 9 is a rocket, not a spacecraft. They cannot be directly compared, because they aren't even the same class of thing! SpaceX's equivalent of Progress is the Dragon capsule.
The Soyuz ROCKET, specifically the newest version (called Soyuz-2, has a payload of 8200 kg to LEO and 3250 kg to GTO. It's still not nearly so powerful as Falcon 9, even the reusable configuration (I believe the numbers you quoted omit the F9's grid fins, landing legs, and reserved fuel for recovery), but it's far more than one ninth as powerful.
OK, 7-digit ID or not, are you really so new here you think that Slashdot summaries (or even articles) are an always-accurate representation of the world? Out here in the real world, where I've been working in information security longer than you've been on this site (and nearly as long as I have, actually), we understand the difference between "the attacker needs to physically or remotely accessing the machine" and "the attacker needs to have code executing on the machine". It's a very important difference. The fact that the summary implies direct access is required is stupid, but the fact that you (and, apparently, a significant number of other people) took that implication as fact says much more about you all than it does about the exploit.
Try reading the actual exploit writeup rather than dumbed-down ThreatPost article, and you'll see that no such claim is made. There's not a single step of the process that requires the level of access you'd need to approve a UAC prompt. Hell, even in the ThreatPost article, it doesn't say (or even imply) anything about physical access.
“This is a post-exploitation technique, so an attacker would need to already be on the system.”
You can do this exploit if you get non-elevated arbitrary code execution (via remote compromise, or Trojan download, or anything else of that sort) in the account of a member of the Administrators group. You cannot click "Allow" via non-elevated code execution; UAC is very carefully designed to not allow non-elevated code to approve its prompts.
Please don't run your mouth when you don't know what you're talking about. This exploit, and the UAC default in Win7+, are both stupid enough already; you don't have to turn it into a three-way race. Think first, then post!
Elevation from limited-user access to "root" (Administrators-level access) is definitely a threat. Of course, in this case, it's just enabled by a really moronic default that Microsoft added to UAC in Win7 (and has persisted since), which auto-elevates some "trusted" Windows binaries (like eventvwr.exe). If you remove that particular stupidity (in the UAC control panel, move the slider all the way up to "Always Notify"), this attack (and the long, long list of similar things, many known for years, like it) won't work.
There's only one known UAC bypass if you switch to "Always Notify" from the brain-dead default setting that auto-elevates many Windows binaries, and there's a work-around for that one (the exploit itself is far more complicated than this one, too). Not arguing that running as not-a-member-of-Administrators isn't a good idea anyhow, because (from a security standpoint) it definitely is, but it's also a *mostly*-needless hassle.
No physical access required. Arbitrary code execution in a non-elevated context required, and then it can use that to elevate... if you're a member of the Administrators group, and still have the brain-dead UAC default "don't notify when I make changes to Windows settings" setting selected.
It's actually even stupider than that. If you don't have UAC set to automatically elevate system binaries (like eventvwr.exe), this doesn't provide the attacker with anything either. UAC in Win7 introduced the idiotic notion that "trusted" programs would auto-elevate, rather than prompting, by default. There have been UAC bypasses based on this stupidity known for many years, this is just the latest in a long, long list.
To avert this, on Win7+, set UAC to "Always notify", rather than the default "Notify me when apps try to make changes to my computer (Don't notify me when I make changes to Windows settings)". In the UAC control panel, just move the slider to the top. (On Vista, the latter option doesn't exist; anything launching from a non-elevated context is required to prompt.) That will protect you against stupidities like an auto-elevated process reading a command to execute out of the non-elevated-writable HKCU registry hive (which is how this bypass works). Microsoft's idea in changing that default may have been good (reduce the number of prompts), but their execution was shit because none of their code (including the self-elevating stuff) is actually designed to treat non-elevated-same-user-writable locations as untrusted.
Note that there is *one* known UAC bypass that works even in "Always Notify" mode, because Microsoft is really bad at this stuff. It's far more complicated than this one, though. It also still doesn't work if you aren't a member of the Administrators group, though removing yourself from that group does introduce a lot of hassle.
No, just shitting on users who insist on running obsolete software without upgrading. Windows Phone and Windows 10 Mobile are different operating systems. W10M is backward-compatible with WP apps, of course, but the reverse is not true; WP8.1 cannot run W10M apps such as the current version of Skype. They're keeping the old version around on life support to give people time to upgrade, that's all.
Unfortunately, Microsoft branding sucks balls, and people like you with no incentive to get your facts straight will probably go on twisting these announcements and misleading others.
The post submitter is confused / has no idea what e's talking about. They aren't "killing a popular app", they're end-of-life-ing the old version that runs on the outdated operating system. Skype for Windows 10 Mobile (to which one can upgrade from Windows Phone 8.1, unless your handset is quite old) is not the same thing as Skype for Windows Phone. Windows Phone is going the way of the Win9x family, and Microsoft is no longer going to support apps for it. This is not unreasonable, especially since the population of people who will still be using the old OS by 2017 is quite small. Not zero - some people will hold on to old hardware and not upgrade - but not much.
It'd be nice if Microsoft committed to mobile product support lifetimes anywhere near so long as their PC/server product support lifetimes, but considering their overall marketshare, it's not surprising they don't consider it worthwhile. Of course, this will probably lose them some more of that thin slice of marketshare they still have, but at this point, nobody should be surprised by that.
Yeah, part of the problem here is that Microsoft's idiotic, asinine branding is (once again) biting them on the ass. "Skype for Windows Phone" has nothing to do with "Skype for Windows 10 Mobile", because the last version of "Windows Phone" is 8.1, and "Windows 10 Mobile" (no relation to the long-dead "Windows Mobile" family, whose last version was 6.5) is a new OS.
If you upgrade to Windows 10 Mobile, your Skype app will continue working just fine. Of course, initially every WP8.1 phone could upgrade (through the Windows Insider program) but now they're limiting it to only the relatively-new handset models. If your handset is more than about three years old, or more than about two years old and mid-grade or lower, you'll probably need a new phone. This is bullshit - I've got an old Lumia 520, the lowest-end WP8.0 release device from way back in 2012, (I use it for testing, not daily phone needs), and it runs W10M just fine - but nobody has ever accused Microsoft business practices of being bullshit-free.
While what you say is true on some level - a compromised process can dick with your system, including other processes, just fine - you're missing the point of having a multi-process browser for security. The vast majority of what a browser does requires almost no access to the rest of the computer. You can have one container process that runs with user privileges and implements the few things the browser needs to be able to do to the system at large (save downloaded files, etc.) in a very secure manner, and is also responsible for launching sandboxed, low-privilege sub-processes that do the dangerous work of a browser (parsing web server responses, running plugins, executing javascript, etc.). If these sandboxed processes are compromised, the attacker can still fuck with your browser... but they can't get out into the rest of your system.
This is how Chrome and IE have worked for years (though Chrome's sandbox is a lot tighter than IE's). It's not just about stability/reliability, there's also a very real element of security here. Chrome's sandboxed render processes are so underprivileged that there's practically nothing a compromised one can do (to the rest of the computer) except try to attack its full-user-privilege container / broker process (through the IPC channels that let it do things like say "Please ask the user where they want to save this downloaded file"), but that is a very small attack surface compared to most of what a browser does, and the trusted process can have that attack surface very well-hardened.
Yeah, this looks like a classic example of the motte and bailey doctrine. They support, but cannot defend, the claim that all porn is bad and needs to be banned. When people assail this position, they retreat to their metaphorical motte (a well-defended tower where you could hole up and resist attackers) claim of "but we're trying to stop child porn! Child porn is terrible and you're evil if you don't want to stop it!" Of course, as soon as people agree that stopping child porn is good and righteous, they head back out to their metaphorical bailey (the valuable but indefensible land around a motte) and start campaigning against porn in general again.
Glad to know I'm not the only who noticed that, hey, Steam-on-Win10 actually still runs just fine. If you read TFA, you'll see it looks about as credible as somebody in ragged clothes standing on a street corner and shouting that the Martians have mind-controlled the government. There's no evidence claimed, much less presented, whatsoever. The only actual concrete claim made (about how some new features are UWP-specific) has nothing to do win Steam; Steam has never cared what features Windows Store apps do or don't have, any more than it has cared what features Java ME does or doesn't have. Nothing that Steam actually uses has been impacted, so far as I can tell or so far as TFA claims.
So... did anybody actually RTFA? (Yeah, yeah, not new here, whatever.) You need some kind of grounds to sue. I checked TFA; it contains exactly one more concrete claim, and exactly as much evidence to support the allegations, as TFS.
Concrete claim:
Microsoft has launched new PC Windows features exclusively in UWP
Leaving aside the fact that you can (fully supported) sideload UWP apps, I don't even see what this has to do with Steam. Adding new features to a platform that Steam doesn't use will not impact Steam at all! The author doesn't ever even imply, much less actually claim, that Microsoft is specifically removing or modifying anything that will impact Steam.
Evidence to support the allegation: Nothing at all. I mean, maybe the author has some (in which case it would presumably come out at trial), but TFA doesn't even claim to have evidence, much less present any. Not one single point. This entire article is no more credible than idle speculation!
As far as I can tell, Steam runs about as well as it ever has (which is to say, much better than it used to in the Win7 days) on Win10, Look at that: I just made a more-concrete claim about Steam on Win10 than anything in the entire article.
Retirement accounts are very much a special case of capital gains, with restrictions on accessing them and subject to different tax laws. Equating retirement accounts with the type of investments under discussion here is completely disingenuous.
What's not free-market about it, aside from the fact that if they'd printed outright lies they could have been sued? I really doubt that that's the kind of government intervention in free markets you were referring to. One of the colossal problems with free-market ideals is that the consumer will *never* have all the information, nor will the very partial info the have be representative or properly weighted by importance, nor will the (partial, sensationalized, and unrepresentational) information be unencumbered by bias.
The vast majority of people do not, on an everyday basis, make rational decisions. This is true when deciding what to have for breakfast (see the absurdly sugar-rich and/or fatty things that pass for "breakfast" in most of America, at least), it is true when deciding on political candidates (I'm not even going to mention major candidates; in states where primaries select delegates instead of directly voting on candidates, Trump lost some delegates from regions that otherwise favored him because some of his potential delegates in those regions had foreign-sounding names), and when deciding what car to buy. Instead, we mostly rely on heuristics: I should eat this because it tastes good, I shouldn't vote for this delegate because their name doesn't sound like the names of people who think like me, I shouldn't buy a Tesla because somebody on Slashdot said they'll go out of business soon, etc. Often, it is rational to use heuristics; they're less mentally expensive than rational cost-benefit analyses. For major decisions (or ongoing behavior), though, it's really not... and yet we do anyhow.
What's more, people (most commonly salespeople, marketers, lobbyists, politicians, con artists, evangelists, and the rest of that ilk) are skilled at exploiting weaknesses in those heuristics. They appeal to emotion, exploit widespread ignorance, craft popular narratives that spread virally, present easy answers, use ad hominem attacks, try to get people to confuse them with trustworthy sources, and (when they can get away with it, which is pretty often) outright lie. You might think that all the bullshit would cancel out and the truth would win in the end, but not all positions are equally privileged in peoples' minds. Just as a comforting lie is much more believable than a painful truth for most people, it is much easier to tear down somebody else's reputation on distortions than to build up your own on truth.
We see that today, all the time. A lot of it's medical (anti-vaccine, homeopathy, "miracle" diets, etc.) but it happens in every other field too. One I see all the time, professionally, is products advertised as "secure" or "private" when they are the polar opposite of that. Even in pure science, it happens as people compete to be credited on publications and to horde the limelight for accomplishments they don't want to share, thus raising their status higher than it should be, to the detriment of us all.
Usually, because of the new features. Often, they are A) cool / fun - letting you do neat stuff the device couldn't do (or at least not easily) before B) useful / productive - even if you spend some time debugging, you can sometimes make back that time by using those new features to get stuff done faster C) more secure - while pre-release software can have (new) security bugs as well as other kinds of bugs, defense-in-depth type features often aren't rolled out in minor updates, and OS security features can help protect you even against security vulnerabilities in third-party software (sandboxing features, ASLR improvements, etc.)
Alternatively, because you support internal or niche software for that platform. The company isn't going to test your specific environment; there are far too many to try, even if you ignore the combinatorial explosion when you consider interactions between components. They'll do their best to ensure backward compatibility, but it's never exactly perfect (if only because sometimes they have to fix buggy behavior that old software was relying on). It is your responsibility, not that of the OS developer, to ensure that your specific code works on the new version before your customers (internal or external) start coming to you saying they updated their machine and now your code breaks. If you test before the thing gets released, and find a compatibility bug that affects your code in particular, you can tell the OS vendor about the bug and maybe they'll fix it before any of your users see the problem.
Yep. The video doesn't make it clear, because the cameras are all either tracking the rocket or are mounted *on* the rocket, but the first stage is going really fast at separation, and a lot of that velocity is lateral. Going to *space* only requires going up a relatively short distance, but going to *orbit* requires going extremely fast around the planet. After the first few seconds post-liftoff, the rocket is angled mostly downrange, not just up. To come back to the launch site, the rocket not only needs to kill all that down-range velocity, it needs to boost *back* to the launch site.
The rocket does actually need to do a braking burn when landing on a downrange barge anyhow, but the purpose is different. Rather than being focused on reversing the rocket's forward trajectory, it's focused on slowing the rocket down so it can re-enter the atmosphere safely. By the time of separation, the stages are quite high - well out of the thick part of the atmosphere - and sheer momentum will take them quite a bit higher. Eventually gravity takes over, though, and between gravity pulling the rocket downward and that downrange momentum still making it go forward so fast, the rocket wouldn't survive re-entry if it didn't use its motors to slow down. This re-entry braking burn is done both for land and sea landings.
Well, in theory it *could* if it had the fuel, and I bet that for a really light GTO payload they could manage to save enough fuel for the boostback burn, but in practice satellites intended for GSO aren't that light. It would be a longer boostback burn (than for LEO) anyhow, because the first stage is usually going faster at separation when it's targeting GTO, but for a really light payload the second stage wouldn't need to burn for as long either so maybe the first stage could separate a little earlier.
No matter what the target orbit, the first stage will always be well down-range, and have a lot of velocity in that down-range direction, at separation. For ground landings, it needs to reverse that velocity to come back to the launch site, then do another burn to slow down enough to not burn up in the atmosphere, and then the landing burn. For GTO launches, it usually skips the first burn (boostback) and just continues along that down-range trajectory, doing just the re-entry and then landing burns. This obviously needs less fuel, but also means that the rocket is hundreds of miles downrange by the time it lands.
It's not theoretically impossible to do a full boostback burn after a GTO launch, though... just impractical given how much fuel the first stage uses on the ascent of a GTO launch.
Hmm... diabolical, if true. I suspect it'd get them sued *hard* if it came out that they were doing this, though. Requesting more access than you need is a security risk and a reason to distrust the app. Abusing that unreasonable level of access is an existential risk for a company, and a financial (and possibly even criminal; you could arguably make something stick via CFAA) risk to the people responsible for that decision.
What do you mean, when "it" can't find your information? If you don't have a Google account, you can't sign into the app using a Google account. Since the only other way to sign into the app is using a service that no longer allows new account creation, you won't be able to use the app at all until you create a Google account.
This isn't about app capabilities on your phone. This is about third-party API access to your Google account. It's all online, viewed and managed through a browser and used (or abused) via web services. It has nothing to do with your phone (except that apparently the iOS and Android versions of the app request different permissions to your Google account, and apparently the iOS version is unreasonably greedy).
Slashdot Mirror
That hasn't been true for a while. It's up to the customer each time whether to have the payload stacked or not, but for the last largish number of vehicles - since F9-14 I think? - they've mostly been doing it this way. It saves time (don't need to return the rocket to the assembly building, add the payload, then roll it out and erect it again) and should also reduce risk of a launch failure (less messing around with the rocket between the static fire - which is basically a dress rehearsal - and the actual launch).
There wasn't *any* part that was firing. They were still only fuelling it up; the static fire hadn't started yet. The engines were cold (literally; they chill the engines before start). But yes, the problem started in (or near) the second stage, which wouldn't even have started its engine chill, I think (normally that starts a couple minutes after launch, though maybe they do a MVac chill cycle for static fires too; not sure).
Also, problems like this are the reason why human-rated spacecraft have launch escape systems. Well, human-rated craft other than the Space Shuttle, at least. Did you watch the Dragon 2 Launch Pad Abort video from last year? If anything goes wrong. the capsule blasts all eight of its thrusters to full and takes off like a bat out of hell. It's completely automated, as well; it'll happen faster than a human could ever react.
This is correct. They *can* do the static fire without the payload attached - and for many early launches, that's what they did - but it takes longer between static fire and launch. With the launch window coming only three days away, and no incident like this having occurred in approximately forever (they didn't even have the engines lit yet!) saving some time and (presumably) risk by having the payload stacked on the rocket probably made sense... to the satellite owner.
It wasn't even SpaceX's decision; the payload owner makes the choices like that.
It's covered by insurance, just not *launch* insurance. You thought they wouldn't have a $200M machine covered by insurance for every step of its trip into space?
But yeah, Facebook was just going to pay for part of the satellite's capacity, they were definitely not the owner in any way.
You are comparing apples to oranges. Progress is a spacecraft, not a rocket. Falcon 9 is a rocket, not a spacecraft. They cannot be directly compared, because they aren't even the same class of thing! SpaceX's equivalent of Progress is the Dragon capsule.
The Soyuz ROCKET , specifically the newest version (called Soyuz-2, has a payload of 8200 kg to LEO and 3250 kg to GTO. It's still not nearly so powerful as Falcon 9, even the reusable configuration (I believe the numbers you quoted omit the F9's grid fins, landing legs, and reserved fuel for recovery), but it's far more than one ninth as powerful.
Sigh...
OK, 7-digit ID or not, are you really so new here you think that Slashdot summaries (or even articles) are an always-accurate representation of the world? Out here in the real world, where I've been working in information security longer than you've been on this site (and nearly as long as I have, actually), we understand the difference between "the attacker needs to physically or remotely accessing the machine" and "the attacker needs to have code executing on the machine". It's a very important difference. The fact that the summary implies direct access is required is stupid, but the fact that you (and, apparently, a significant number of other people) took that implication as fact says much more about you all than it does about the exploit.
Try reading the actual exploit writeup rather than dumbed-down ThreatPost article, and you'll see that no such claim is made. There's not a single step of the process that requires the level of access you'd need to approve a UAC prompt. Hell, even in the ThreatPost article, it doesn't say (or even imply) anything about physical access.
You can do this exploit if you get non-elevated arbitrary code execution (via remote compromise, or Trojan download, or anything else of that sort) in the account of a member of the Administrators group. You cannot click "Allow" via non-elevated code execution; UAC is very carefully designed to not allow non-elevated code to approve its prompts.
Please don't run your mouth when you don't know what you're talking about. This exploit, and the UAC default in Win7+, are both stupid enough already; you don't have to turn it into a three-way race. Think first, then post!
Elevation from limited-user access to "root" (Administrators-level access) is definitely a threat. Of course, in this case, it's just enabled by a really moronic default that Microsoft added to UAC in Win7 (and has persisted since), which auto-elevates some "trusted" Windows binaries (like eventvwr.exe). If you remove that particular stupidity (in the UAC control panel, move the slider all the way up to "Always Notify"), this attack (and the long, long list of similar things, many known for years, like it) won't work.
There's only one known UAC bypass if you switch to "Always Notify" from the brain-dead default setting that auto-elevates many Windows binaries , and there's a work-around for that one (the exploit itself is far more complicated than this one, too). Not arguing that running as not-a-member-of-Administrators isn't a good idea anyhow, because (from a security standpoint) it definitely is, but it's also a *mostly*-needless hassle.
No physical access required. Arbitrary code execution in a non-elevated context required, and then it can use that to elevate... if you're a member of the Administrators group, and still have the brain-dead UAC default "don't notify when I make changes to Windows settings" setting selected.
It's actually even stupider than that. If you don't have UAC set to automatically elevate system binaries (like eventvwr.exe), this doesn't provide the attacker with anything either. UAC in Win7 introduced the idiotic notion that "trusted" programs would auto-elevate, rather than prompting, by default. There have been UAC bypasses based on this stupidity known for many years, this is just the latest in a long, long list.
To avert this, on Win7+, set UAC to "Always notify", rather than the default "Notify me when apps try to make changes to my computer (Don't notify me when I make changes to Windows settings)". In the UAC control panel, just move the slider to the top. (On Vista, the latter option doesn't exist; anything launching from a non-elevated context is required to prompt.) That will protect you against stupidities like an auto-elevated process reading a command to execute out of the non-elevated-writable HKCU registry hive (which is how this bypass works). Microsoft's idea in changing that default may have been good (reduce the number of prompts), but their execution was shit because none of their code (including the self-elevating stuff) is actually designed to treat non-elevated-same-user-writable locations as untrusted.
Note that there is *one* known UAC bypass that works even in "Always Notify" mode, because Microsoft is really bad at this stuff. It's far more complicated than this one, though. It also still doesn't work if you aren't a member of the Administrators group, though removing yourself from that group does introduce a lot of hassle.
No, just shitting on users who insist on running obsolete software without upgrading. Windows Phone and Windows 10 Mobile are different operating systems. W10M is backward-compatible with WP apps, of course, but the reverse is not true; WP8.1 cannot run W10M apps such as the current version of Skype. They're keeping the old version around on life support to give people time to upgrade, that's all.
Unfortunately, Microsoft branding sucks balls, and people like you with no incentive to get your facts straight will probably go on twisting these announcements and misleading others.
The post submitter is confused / has no idea what e's talking about. They aren't "killing a popular app", they're end-of-life-ing the old version that runs on the outdated operating system. Skype for Windows 10 Mobile (to which one can upgrade from Windows Phone 8.1, unless your handset is quite old) is not the same thing as Skype for Windows Phone. Windows Phone is going the way of the Win9x family, and Microsoft is no longer going to support apps for it. This is not unreasonable, especially since the population of people who will still be using the old OS by 2017 is quite small. Not zero - some people will hold on to old hardware and not upgrade - but not much.
It'd be nice if Microsoft committed to mobile product support lifetimes anywhere near so long as their PC/server product support lifetimes, but considering their overall marketshare, it's not surprising they don't consider it worthwhile. Of course, this will probably lose them some more of that thin slice of marketshare they still have, but at this point, nobody should be surprised by that.
Yeah, part of the problem here is that Microsoft's idiotic, asinine branding is (once again) biting them on the ass. "Skype for Windows Phone" has nothing to do with "Skype for Windows 10 Mobile", because the last version of "Windows Phone" is 8.1, and "Windows 10 Mobile" (no relation to the long-dead "Windows Mobile" family, whose last version was 6.5) is a new OS.
If you upgrade to Windows 10 Mobile, your Skype app will continue working just fine. Of course, initially every WP8.1 phone could upgrade (through the Windows Insider program) but now they're limiting it to only the relatively-new handset models. If your handset is more than about three years old, or more than about two years old and mid-grade or lower, you'll probably need a new phone. This is bullshit - I've got an old Lumia 520, the lowest-end WP8.0 release device from way back in 2012, (I use it for testing, not daily phone needs), and it runs W10M just fine - but nobody has ever accused Microsoft business practices of being bullshit-free.
While what you say is true on some level - a compromised process can dick with your system, including other processes, just fine - you're missing the point of having a multi-process browser for security. The vast majority of what a browser does requires almost no access to the rest of the computer. You can have one container process that runs with user privileges and implements the few things the browser needs to be able to do to the system at large (save downloaded files, etc.) in a very secure manner, and is also responsible for launching sandboxed, low-privilege sub-processes that do the dangerous work of a browser (parsing web server responses, running plugins, executing javascript, etc.). If these sandboxed processes are compromised, the attacker can still fuck with your browser... but they can't get out into the rest of your system.
This is how Chrome and IE have worked for years (though Chrome's sandbox is a lot tighter than IE's). It's not just about stability/reliability, there's also a very real element of security here. Chrome's sandboxed render processes are so underprivileged that there's practically nothing a compromised one can do (to the rest of the computer) except try to attack its full-user-privilege container / broker process (through the IPC channels that let it do things like say "Please ask the user where they want to save this downloaded file"), but that is a very small attack surface compared to most of what a browser does, and the trusted process can have that attack surface very well-hardened.
Yeah, this looks like a classic example of the motte and bailey doctrine. They support, but cannot defend, the claim that all porn is bad and needs to be banned. When people assail this position, they retreat to their metaphorical motte (a well-defended tower where you could hole up and resist attackers) claim of "but we're trying to stop child porn! Child porn is terrible and you're evil if you don't want to stop it!" Of course, as soon as people agree that stopping child porn is good and righteous, they head back out to their metaphorical bailey (the valuable but indefensible land around a motte) and start campaigning against porn in general again.
Glad to know I'm not the only who noticed that, hey, Steam-on-Win10 actually still runs just fine. If you read TFA, you'll see it looks about as credible as somebody in ragged clothes standing on a street corner and shouting that the Martians have mind-controlled the government. There's no evidence claimed, much less presented, whatsoever. The only actual concrete claim made (about how some new features are UWP-specific) has nothing to do win Steam; Steam has never cared what features Windows Store apps do or don't have, any more than it has cared what features Java ME does or doesn't have. Nothing that Steam actually uses has been impacted, so far as I can tell or so far as TFA claims.
So... did anybody actually RTFA? (Yeah, yeah, not new here, whatever.) You need some kind of grounds to sue. I checked TFA; it contains exactly one more concrete claim, and exactly as much evidence to support the allegations, as TFS.
Concrete claim:
Leaving aside the fact that you can (fully supported) sideload UWP apps, I don't even see what this has to do with Steam. Adding new features to a platform that Steam doesn't use will not impact Steam at all! The author doesn't ever even imply, much less actually claim, that Microsoft is specifically removing or modifying anything that will impact Steam.
Evidence to support the allegation: Nothing at all. I mean, maybe the author has some (in which case it would presumably come out at trial), but TFA doesn't even claim to have evidence, much less present any. Not one single point. This entire article is no more credible than idle speculation!
As far as I can tell, Steam runs about as well as it ever has (which is to say, much better than it used to in the Win7 days) on Win10, Look at that: I just made a more-concrete claim about Steam on Win10 than anything in the entire article.
Retirement accounts are very much a special case of capital gains, with restrictions on accessing them and subject to different tax laws. Equating retirement accounts with the type of investments under discussion here is completely disingenuous.
What's not free-market about it, aside from the fact that if they'd printed outright lies they could have been sued? I really doubt that that's the kind of government intervention in free markets you were referring to. One of the colossal problems with free-market ideals is that the consumer will *never* have all the information, nor will the very partial info the have be representative or properly weighted by importance, nor will the (partial, sensationalized, and unrepresentational) information be unencumbered by bias.
The vast majority of people do not, on an everyday basis, make rational decisions. This is true when deciding what to have for breakfast (see the absurdly sugar-rich and/or fatty things that pass for "breakfast" in most of America, at least), it is true when deciding on political candidates (I'm not even going to mention major candidates; in states where primaries select delegates instead of directly voting on candidates, Trump lost some delegates from regions that otherwise favored him because some of his potential delegates in those regions had foreign-sounding names), and when deciding what car to buy. Instead, we mostly rely on heuristics: I should eat this because it tastes good, I shouldn't vote for this delegate because their name doesn't sound like the names of people who think like me, I shouldn't buy a Tesla because somebody on Slashdot said they'll go out of business soon, etc. Often, it is rational to use heuristics; they're less mentally expensive than rational cost-benefit analyses. For major decisions (or ongoing behavior), though, it's really not... and yet we do anyhow.
What's more, people (most commonly salespeople, marketers, lobbyists, politicians, con artists, evangelists, and the rest of that ilk) are skilled at exploiting weaknesses in those heuristics. They appeal to emotion, exploit widespread ignorance, craft popular narratives that spread virally, present easy answers, use ad hominem attacks, try to get people to confuse them with trustworthy sources, and (when they can get away with it, which is pretty often) outright lie. You might think that all the bullshit would cancel out and the truth would win in the end, but not all positions are equally privileged in peoples' minds. Just as a comforting lie is much more believable than a painful truth for most people, it is much easier to tear down somebody else's reputation on distortions than to build up your own on truth.
We see that today, all the time. A lot of it's medical (anti-vaccine, homeopathy, "miracle" diets, etc.) but it happens in every other field too. One I see all the time, professionally, is products advertised as "secure" or "private" when they are the polar opposite of that. Even in pure science, it happens as people compete to be credited on publications and to horde the limelight for accomplishments they don't want to share, thus raising their status higher than it should be, to the detriment of us all.
Usually, because of the new features. Often, they are
A) cool / fun - letting you do neat stuff the device couldn't do (or at least not easily) before
B) useful / productive - even if you spend some time debugging, you can sometimes make back that time by using those new features to get stuff done faster
C) more secure - while pre-release software can have (new) security bugs as well as other kinds of bugs, defense-in-depth type features often aren't rolled out in minor updates, and OS security features can help protect you even against security vulnerabilities in third-party software (sandboxing features, ASLR improvements, etc.)
Alternatively, because you support internal or niche software for that platform. The company isn't going to test your specific environment; there are far too many to try, even if you ignore the combinatorial explosion when you consider interactions between components. They'll do their best to ensure backward compatibility, but it's never exactly perfect (if only because sometimes they have to fix buggy behavior that old software was relying on). It is your responsibility, not that of the OS developer, to ensure that your specific code works on the new version before your customers (internal or external) start coming to you saying they updated their machine and now your code breaks. If you test before the thing gets released, and find a compatibility bug that affects your code in particular, you can tell the OS vendor about the bug and maybe they'll fix it before any of your users see the problem.
Yep. The video doesn't make it clear, because the cameras are all either tracking the rocket or are mounted *on* the rocket, but the first stage is going really fast at separation, and a lot of that velocity is lateral. Going to *space* only requires going up a relatively short distance, but going to *orbit* requires going extremely fast around the planet. After the first few seconds post-liftoff, the rocket is angled mostly downrange, not just up. To come back to the launch site, the rocket not only needs to kill all that down-range velocity, it needs to boost *back* to the launch site.
The rocket does actually need to do a braking burn when landing on a downrange barge anyhow, but the purpose is different. Rather than being focused on reversing the rocket's forward trajectory, it's focused on slowing the rocket down so it can re-enter the atmosphere safely. By the time of separation, the stages are quite high - well out of the thick part of the atmosphere - and sheer momentum will take them quite a bit higher. Eventually gravity takes over, though, and between gravity pulling the rocket downward and that downrange momentum still making it go forward so fast, the rocket wouldn't survive re-entry if it didn't use its motors to slow down. This re-entry braking burn is done both for land and sea landings.
Well, in theory it *could* if it had the fuel, and I bet that for a really light GTO payload they could manage to save enough fuel for the boostback burn, but in practice satellites intended for GSO aren't that light. It would be a longer boostback burn (than for LEO) anyhow, because the first stage is usually going faster at separation when it's targeting GTO, but for a really light payload the second stage wouldn't need to burn for as long either so maybe the first stage could separate a little earlier.
No matter what the target orbit, the first stage will always be well down-range, and have a lot of velocity in that down-range direction, at separation. For ground landings, it needs to reverse that velocity to come back to the launch site, then do another burn to slow down enough to not burn up in the atmosphere, and then the landing burn. For GTO launches, it usually skips the first burn (boostback) and just continues along that down-range trajectory, doing just the re-entry and then landing burns. This obviously needs less fuel, but also means that the rocket is hundreds of miles downrange by the time it lands.
It's not theoretically impossible to do a full boostback burn after a GTO launch, though... just impractical given how much fuel the first stage uses on the ascent of a GTO launch.
Hmm... diabolical, if true. I suspect it'd get them sued *hard* if it came out that they were doing this, though. Requesting more access than you need is a security risk and a reason to distrust the app. Abusing that unreasonable level of access is an existential risk for a company, and a financial (and possibly even criminal; you could arguably make something stick via CFAA) risk to the people responsible for that decision.
What do you mean, when "it" can't find your information? If you don't have a Google account, you can't sign into the app using a Google account. Since the only other way to sign into the app is using a service that no longer allows new account creation, you won't be able to use the app at all until you create a Google account.
This isn't about app capabilities on your phone. This is about third-party API access to your Google account. It's all online, viewed and managed through a browser and used (or abused) via web services. It has nothing to do with your phone (except that apparently the iOS and Android versions of the app request different permissions to your Google account, and apparently the iOS version is unreasonably greedy).