Falcon 9 can take off on 89% thrust (one engine down). If it loses a second engine *immediately* on takeoff, it might crash. However, remember that those engines are burning through the rocket's fuel, lightening the load considerably. Typically, the fuel is exhausted after 3 minutes of flight; call it 27 engine-minutes. At that point, (or rather, right before that point, when there's still a tiny bit of fuel) the first stage is so light that even throttled all the way down, a single Merlin 1D engine produces a thrust/weight ratio greater than one (this makes landing tricky; they are constantly decelerating by "accelerating upwards", and need to pass the 0-velocity mark right when they hit the ground).
If the rocket has more fuel in it (or otherwise has more weight), then the stage can hover; Grasshopper demonstrated this. If you can hover, or even avoid crashing *immediately*, the remaining engines can run to burn off the fuel. As the fuel burns off, the rocket gets lighter. Now, counting the weight of the (fully fuelled) second stage and the payload, 1 rocket motor probably isn't enough to land safely even if the first stage manages to burn (or dump) its fuel... although it might be; after all, the second stage is able to accelerate handily under a single engine (though the vacuum thrust is higher, and of course it doesn't have the weight of the near-empty first stage too).
If they have even a few working engines - ideally in some reasonably-stable arrangement, such as any two opposing ones and the middle one - and enough time to burn (or dump, assuming there's a mechanism for that) fuel, they should be able to land the whole stack again. Dragon would probably detach and land itself - Dragon 2 definitely would, what with its SuperDracos and landing legs - but a launch using a payload fairing would just have to try and survive on the top of the rocket while the booster's RCS, grid fins, and gimbaling attempt to get the orientation right. I wouldn't put it past SpaceX to manage this, though.
The Declaration of Independence and the Constitution are very different documents. "We hold these truths to be self evident: that all men are created equal..." comes from the Declaration, which was basically a big political "fuck you" to the British government and especially the monarchy. It's not a law and has no legal weight, and unlike the Constitution it is not subject to updates (amendments). Its language might serve as a guide for the country at times - apparently, to such an extent that some people can't tell the difference between document that is merely of historical interest and the highest law of the USA - but the Declaration is merely a historical document, today.
The "primary direction" is most certainly *NOT* up; the first stage gets many times as far downrange as it gets in altitude. However, the boost-back burn is indeed pretty much entirely horizontal; the rocket is high enough that there's very little air, and what little there is, the mostly-empty stage attempts to ride by angling itself as a (really bad) lifting surface.
So yes, the rocket is forced to largely reverse its forward velocity. However, with its tanks empty and no second stage or payload, it weighs very little. Three of it's nine engines are quite sufficient to turn it around and put it on course for home.
It's been available as a "Preview" for months (since before Win10 on PC went RTM), though the early preview builds of it were far from usable. That 8.8% is a mixture of "Windows Insider" preview users (people with legacy phones) and the new Lumia 950 and 950XL flagships, which come with "Windows 10 Mobile (Preview)" and yes, the "Preview" part of that is not my own addition but is actually what Microsoft says the phone's come with. They are shipping hardware with a pre-release operating system installed. It's bizarre (and is leading to a lot of bad reviews for the 950s, saying things like "great hardware, pity about the software"), but this is MSFT, after all.
On the other hand, pre-release OS or not, the 950 and especially 950XL are apparently flying off the shelves; I live in Seattle so there's no lack of Microsoft stores/kiosks nearby, and none of them have the things in stock. They sell out each shipment within a few hours.
Just for the sake of curiosity, what "app access to SMS and call logs" are you looking for? Apps *can* access those; it just requires capabilities that third-party devs aren't allowed to declare by default. We've had the ability to unlock those capabilities for years now - the first "capability unlock" was only for Samsung phones, but was published in 2013 - but relatively few people have bothered writing apps that take advantage of this. I'm curious what your use case for this kind of access would be.
Also, W10M allows sideloaded apps to have the same capabilities that OEMs get to use. This is actually a really big deal - it undoes a change Microsoft introduced way back in WP7.5 that has set a lot of people who would otherwise be productive devs simply looking for ways to get meaningful apps to run at all - and it means that "second-party" capabilities like SMS are now available to everybody's phones again, without needing to perform any hacks.
I'm honestly rather shocked they released the 950/950XL with W10M in its current state. First of all, let's make something clear: Anybody who wants W10M on a WP8.1 phone can get it, today, no big deal. It's called the Windows Insider program and has been available for many months. You'll get the same version of "Windows 10 Mobile (Preview)" that is on the new flagship devices, and you'll get updates just like they do.
The problem is, what Microsoft calls a "preview" is what other people call a "beta". Not release-quality software, not even a release candidate where they're chasing down the last few ship-blocking bugs, but a beta. It's nominally feature-complete, but there's a lot of stuff that just doesn't work right yet, and the OS itself is prone to weird but serious glitches, hangs, even boot-crash-loops. MS is fixing these issues pretty quickly - there have been several updates already since the build that the 950s launched with - but the users and review sites all seem to agree: W10M in its current state is *not* ready for day-to-day usage. This is why Microsoft is not pushing it as an update to all WP8.1 users yet; most of them would be unhappy to go from a stable OS to a buggy one, even though the buggy one has a ton of new and excellent features.
Meh, RT was a shit-show well above and beyond not being "something Microsoft wanted to do". I've never seen a company shoot their own product in the foot (or the face, more like) so hard before. There is absolutely no technical reason that RT couldn't run.NET desktop apps; if you jailbreak it,.NET apps written years before RT existed run just fine. Native code required a recompile (but often nothing else); a native Java runtime would have added a bunch more apps immediately (there's a Java-on-.NET runtime, IKVM, which does work on RT... but it's slow and kind of buggy). There's even a homebrewed (as in, one guy's hobby project) compatibility layer for legacy apps that uses dynamic retranslation and API shims to run legacy x86 Windows apps, unmodified, on RT (not emulating a full x86 Windows, but actually running in RT; they use the same file system, registry, network interfaces, etc.). It's slow, but it's also an example of what Microsoft could have made RT be, if they'd really wanted to.
Instead, of course, after launching a crippled product and watching the community help it start to struggle to its feet usefulness-wise, they came back and crippled it *much harder* this time. RT 8.1 was eventually jailbroken as well, but it took far more effort than it should have, and by the time the new jailbreak was released, most of the community just didn't care anymore. It's really weird how much money and effort Microsoft put into making their own product less useful.
"Universal Windows [10] Apps", or whatever the hell MS calls them this morning, will run at most aspect ratios and display sizes. However, Windows 10 Mobile* still supports apps clear back to WP7.0, four API versions and one major infrastructure change old. WP 7.x and 8.x apps were never intended to run on anything that could be called "desktop mode". WP8.1 supported its own version of "universal" apps, where you could use the same code for PC/tablet and phone apps, but I'm not sure if that means universal WP8.1 apps installed on the phone will have the ability to handle Continuum. We shall see.
The primary targets for Continuum (For Phones, as opposed to the whole "auto-switch to tablet mode" thing on convertible laplets) are, at least initially, Microsoft's built-in apps. Edge and "Outlook" (it's a very nicely souped-up mobile email client, but Outlook it is not) and OneNote and Word and so on. The Office apps built into W10M are way more powerful than they were in any previous Windows Phone version, even in phone mode; in PC (Continuum) mode they'll be weaker than actual PC versions but much closer than you might expect.
Also, while new hardware is required to use the dock that allows plugging in a display and USB devices, you can connect Bluetooth keyboards and mice to a legacy phone running W10M just fine, and there's been ways to mirror the phone's screen on a PC for years. That's not as good as Continuum, but maybe there's also a way to directly, wirelessly connect the phone to a PC or TV screen - I haven't checked - and that mostly solves that issue.
* which, unlike what some people have claimed, is no more a "reboot" of the OS than Windows Phone 8 -> Windows Phone 8.1 was; they just changed the name again
Removing or renaming the Flash binary, making it non-executable (yes, Windows has Execute permissions, just like *nix), or de-registering it from HKCR (ActiveX is just COM, and registers by GUIDs under HKCR\Classes, or using regsvr) are all valid options here, too.
But yes, it's pretty goddamn stupid that Outlook should execute Flash. It doesn't allow scripts in HTML email, but it allows something that is a superset of what JavaScript can do? Moronic.
Nope, @ragefan didn't say that. However, your beliefs appear to be interfering with your reading comprehension, so I can see how you would have read their question in a way consistent with your ideology.
The possibility that someone, somewhere might drive with really bad judgment or without sufficient knowledge of how to do so safely is why we have driver's licenses, and ban driving without one. Being drunk impairs your judgment and ability, so if you drive while in that state you have demonstrated that you are not safe to have behind the wheel, and you lose your license. Even though modern society in many parts of the country is heavily dependent on having a car, operating a car without a currently-valid license is deemed a sufficient risk to society that you can be imprisoned for it.
So, which of the following logically consistent arguments would you like to make: A) "I was wrong, and yes, guns should probably be licensed at least as strictly as cars." B) "Guns are less dangerous to operate than cars, so they don't need to be licensed even though drivers do." C) "Private guns are more vital to society than private cars are, so they need to be less restricted." D) "You don't need a license to own a car, so you shouldn't need one for a gun unless you want to ever do anything with it." E) "Operating a car shouldn't require a license either, and should never be a crime unless you cause actual harm with it." F) Something not included above, but that is logically consistent and has supporting evidence.
For the record, you *might* have an argument with C and/or D, though a hardcore libertarian would presumably argue E.
Yep. First thing I thought when I saw that line. I'm not generally a fan of the degree of influence businesses can impose on the government, but if it takes the united front of everything from Apple down to (relatively tiny) Mozilla to stop this bullshit, I'll take it. The NSA has already cost American corporations significantly, both in lost sales and in needing to defend themselves against their own government (which, in fairness, isn't that different from the defending against foreign governments that they probably should have been doing anyhow). Throw the FBI in the ring too, and "Made in USA" software is going to become untouchable, anathema to all the rest of the world's businesses.
Except... those companies already pay six-digit salaries. It's not the tech giants who would be hurt by this, it's the companies where typical wages are in the mid-to-upper 5 digits and cost of living is half (or less) what it is on the coast. The giants would actually benefit, here; there'd be less competition for the visa workers.
Heartbleed wasn't exposing memory from other processes, it was exposing memory from the address space of the vulnerable process. The data leaked in Heartbleed attacks was all data that the program had put into memory itself. For example, if you create a HTTP request to a login page, and populate it with credentials, and then try to send it over an HTTPS connection using OpenSSL for the TLS, that request (with its plain-text credentials) could be leaked out of memory by Heartbleed. Similarly, OpenSSL on the server needed to know the private key of the server in order to decrypt and sign messages, so that private key was stored in memory by OpenSSL itself and could be leaked in a Heartbleed attack.
Using calloc() wouldn't have made it harder to exploit the basic flaw (leaking memory from the process due to buffer overread) at all; at best, the 64k of leaked memory would have had more zeroed bytes in it. That might have been a *small* help, if those bytes had previously stored sensitive data that was then freed and re-allocated for a different use but hadn't yet had new data written into them. That's an extremely unlikely scenario, though. More likely, either the sensitive data would never have been freed, or the re-allocated data would have been overwritten, or the sensitive data would have been freed but kept in memory (remember, calloc() doesn't wipe until you call it to allocate the memory; if you want to zero bytes before freeing them you have to use a function to do that).
Now, part of the problem *was* due to the way OpenSSL (through absolutely no fault of the operating system) handles memory; rather than having the OS and runtime library do memory management, OpenSSL grabs (grabbed? Maybe they fixed this) a pile of memory from the OS, and then "allocates" and "frees" it using an internal memory manager. This meant that Heartbleed was virtually guaranteed to find 64k of contiguous memory, without the holes where the OS hadn't mapped any page into the program's address space. Such holes would have caused an access violation / segmentation fault when Heartbleed tried to read them, and crashed the program; bad for server uptime, but better than exposing a bunch of data that is sensitive enough you wanted to transmit it through an encrypted channel (or leaking the encryption key for the channel itself, etc.)
My bad, you are correct. The OS does actually clear memory when it is newly allocated to a program (or possibly when it is released; I'm not sure). That would, otherwise, be a huge security risk.
There's no need to clear memory each time memory is re-allocated *within* a program, though, except as a debugging technique (detecting the use of uninitialized memory), for which a distinctive pattern is usually used instead of simply zeroing the data. Memory managers usually handle many allocations smaller than full pages, so calling free() (or delete) doesn't always immediately return memory to the OS. That memory is usually re-allocated to a different buffer or object in short order, and zeroing it between those times (while still owned by the process) is wasteful.
There actually is an x86 emulation (well, dynamic recompilation, which is faster) layer for Windows RT. It's unofficial and only runs on jailbroken devices, but it's there. App compat isn't that great yet, because it has to shim all Win32 calls from the x86 version to the ARM version (this is much faster and has a smaller install footprint than emulating a full x86 Windows, and makes it possible to optimize the translation a bit, but means each Win32 API needs to be shimmed and there are a huge number of them).
It's largely the work of one developer, aside from the form from existing open-source code. Microsoft could easily have produced something much more complete than this, especially since they have access to the original implementations of the functions in question (the dev of the compat layer had to work off public headers, MSDN docs, and stuff from Wine and ReactOS). Done right, this software could have hugely improved interest in RT.
Instead, Microsoft doubled down on the lockdown in RT8.1, blocking the 8.0 jailbreak in multiple different ways and setting back progress on the OS until people basically lost interest. Work has resumed now that there's a new public jailbreak, but the original dev has moved on (though the compat layer is open source) and most people just don't care anymore. I have never seen a company so deliberately destroy one of their own products before...
Linker flag, technically, but yes. The compiler produces machine modules which are always at known addresses relative to other parts of the module (but not relative to the address space as a whole), or relative jumps and branches wouldn't work and that would break everything. The linker controls how each module finds the base addresses of other modules. When the OS loads the binary produced by the linker, it can place the modules into memory at addresses controlled by a random mask, and the modules query these (masked) addresses when they are trying to find the addresses of code or data in other modules. However, old OSes always loaded the modules at the same addresses relative to each other (allowing one module to call directly into another, without needing to look up the address of the other module) and therefore the OS doesn't randomize module locations unless the program supports doing so.
On Windows, in Microsoft's SDK, the linker flag to produce a binary that supports random memory layout is/DYNAMICBASE. It's been enabled by default in the last 5 or so versions of Visual Studio.
I get the feeling that you really don't understand how memory exploits work. You seem to be under a very large number of misconceptions, and to have come to all sorts of wrong conclusions based on them. I hope you haven't misled too many other people with your incorrect views on some of the very basics of how operating systems work. Hopefully the following constitutes a "satisfactory explanation" for you:
process X is allowed to overwrite memory belonging to process Y, thus causing Y to do BADSHIT when it jumps to that location
No, it's not. That hasn't been possible on any mainstream OS for many years (DOS/16-bit Windows, maybe old versions of Mac OS?). I mean, you can do it using debug APIs (on Windows, see things like WriteProcessMemory), but if your code has privileges to debug a high-privilege process it could also just do "BADSHIT" directly. A low-privileged process (which you already have code execution in, if you're talking about calling WriteProcessMemory) can't debug a high-privileged one.
why stack overflow is still a problem
What do you think the silver bullet is for stack overflows, then? Using counted functions is vulnerable to off-by-one errors (or other things that specify the wrong count), integer overflows when creating the buffer (malloc(itemcount * sizeof(Item)) will, for sufficiently large itemcount, produce a tiny buffer that will immediately overflow when written to), and many other risks. The closest thing we have is languages that manage their own buffer lengths and such, like Java, Python, JavaScript, and the (other).NET languages... and those still have implementation errors that lead to memory corruption sometimes (I'm sure you've noticed that JavaScript engines, in particular, are not fully safe even though JS as a language is supposed to be safe). Managed languages are also still significantly slower than optimized C/C++ code, though the difference isn't nearly as bad as it used to be.
Or do you mean mitigating the overflows with DEP and ASLR? First of all, that's not a guaranteed fix; if the attacker can leak an address from the program to use as an offset baseline, or otherwise determine the ASLR mask, then that protection can be bypassed. Second, that assumes that there aren't any executables which insist on being loaded at known addresses... and as this story shows, we still have a ways to go to achieve that.
why process X can heap spray the fuck out of memory and have that shit affect process Y
It can't, unless process Y is consuming output from process X and writing it into its own memory (for example, an antivirus filter scanning a file that a web browser downloaded and wrote to disk). See first point.
OS should be managing memory
It is, as far as assigning memory to processes goes. Within a process' own address space, "managing memory" is literally 100% of what a computer program does (reading values, changing values, setting values, copying values, testing values, etc.). Well-behaved programs don't care what addresses the OS hands it, but not all programs as well-behaved in this way.
Address locations should be randomized
They are, for modern software... unless that software says it's incompatible with this behavior. Since a lot of old software *is* incompatible with this behavior - see above point - the OS defaults to trusting the software. In the case of the AV vendors mentioned in TFA, that's apparently a mistake, but it's not the fault of the OS for trusting the software you told it to install, it's the developer's fault for not making their software as safe as possible, and your fault for installing software that you can't trust to be safe.
Memory should be zeroed out upon allocation (or deallocation, or both)
Unless your code assumes that a given function is always loaded at address 0x004006AE, or something stupid like that. Which older software sometimes does, so Microsoft had to make ASLR opt-in by default. Except some *new* software is still not opting in, despite it being the default on Microsoft's linker for the last 5 versions or so.
You can use Microsoft's free tool EMET to force a program to use ASLR, and some Windows programs are now always forced to act this way by default. ASLR applies to DLLs and other executable files, not just to the base EXE, so sometimes a third-party library can make your otherwise-safe process vulnerable. I'd like to say that we can apply such "force everything to be relocated randomly" rules to all software now, but if three major AV vendors hadn't turned on the option until now, maybe we aren't there yet.
Not *another* process. AV software consumes a ton of untrusted input - that's literally its entire purpose - and sometimes it has security flaws itself. If there's a security bug in AV filters (which isn't actually that uncommon) and ASLR is on, the malicious input can crash your AV software (which may, or may not, bring down your system and require a reboot). If ASLR is off, even for a single binary in the process' address space, though, the malicious input can completely take over your machine.
I'm sorry, I wasn't going to post in this thread, but people keep posting this utter idiocy like it means anything.
I drove into California a couple weeks ago. I came across the Oregon border, from Washington. Both of those states are, as far as I can tell, much more lenient on guns than California. The border person didn't ask about guns ("you have any fruit?" / "no" / "all right" and waves us through) and didn't even try to look in the car, which was half-full of baggage that could have carried enough guns and ammo to have defended the Alamo.
STATE gun control is meaningless. California's border probably sees many thousands of guns (that the CA government never learns about) cross it every day in civilian vehicles, and they're one of the only states that bother to mark their border with anything more than a signpost! If you don't have an actual perimeter within and across which guns are controlled - and we don't, not for anything close to the regulations that California has - then you don't have gun control. It doesn't matter where in the USA this happened; all we needed to know was that it happened in the USA.
California's laws are feel-good wastes of paper. Go nationwide with similar laws (or enforce the check at the CA border). Implement tested systems for reducing guns, like buyback plans and so on, instead of just passing laws that criminals have no reason to care about. Do that for a few years, and then check the statistics and we will see if gun control actually does anything. Right now, without looking at non-USA sources, we have no way to know... because nowhere in the USA, California included, has meaningful gun control.
Only if your definition of "conflict" inherently requires violence, in which case your sentence uses circular logic and it meaningless. British occupation of India and South African apartheid are two relatively recent examples of major conflicts between large numbers of people that were resolved without the victorious side resorting to violence.
Win32 != WinNT. Win9x (Windows 95, 98, ME) implemented Win32, but did not use the NT kernel. Hell, Windows 3.11 (which was 16-bit, while all NT versions have been at least 32-bit) had a partial Win32 implementation called "Win32s" that could be used to run some Win32 programs even though the kernel was still 16-bit. Windows CE (including Windows Mobile, aside from the confusingly-named "Windows 10 Mobile") implements Win32, but is completely unlike the NT kernel. A modified version of the CE kernel was used on Windows Phone 7 (I know, because I wrote code that parsed WP7 kernel data structures, which scarcely resemble NT ones), but CE was scrapped in favor of NT for WP8 and later.
CE has been ported to more platforms than NT and has much lower minimum requirements, but uses a far simpler memory manager, does not support SMP (multiple hardware cores), does not support NTFS (it uses a weird variant of FAT that allows files to be "modules" loadable as executable images but not openable as files; NT has no such concept), does not support any kind of access control (a rudimentary access control system was grafted onto the CE kernel for WP7, but it bore no resemblance to the NT access control system that WP8-and-later use), does not support NT drivers, does not use the NT bootloader, is missing many security features (of which user accounts and access controls are only the most visible) that NT has, and is generally unsuited for anything except embedded systems (but has some features targeting those, such as some real-time support, that NT lacks).
A) Anybody who wants to study the science behind those things can do so, and there is quite sufficient evidence (replicated continuously in labs all over the world) for the latter two (assuming you mean Darwin's theory of evolution by natural selection, and yes, speciation through evolutionary response to environmental pressure has been demonstrated in the lab). The effect of the first is still hotly (haha) debated, but the basic science behind it - humans emit literal tons of CO2, CO2 causes greenhouse effect, greenhouse effect warms the planet - are quite thoroughly understood.
B) Can you find me anybody, anywhere, who was killed for not believing in any of the above three things? I'd call you a blithering idiot to your face, but I wouldn't have you killed even if I was dictator of the world and could get away with it. It bears no resemblance to the kind of fanaticism that leads to mass murder.
The evidence is present and sufficient, and nobody is demanding you accept it. You might find yourself lacking opportunities to breed with anybody that has an IQ above room temperature, but such it the price of being vocally moronic.
It would work with a preloaded pin list similar to the HSTS preload list, for sites that should use HTTPS even on the first visit. It would also work for sites like Google properties (in Chrome) or Mozilla properties (in Firefox) where the expected cert is baked into the browser even in advance of HPKP deployment.
It would also work if nobody was intercepting your traffic the first time you visited the site. You would only be in danger if you were being intercepted every single time, including the first time, with this rogue certificate. That's a relatively low-risk threat, though the possibility of such interception does exist and this is why HSTS has a preload list.
But yes, this kind of pwned-before-you-even-start thing is Really Bad.
Slashdot Mirror
Falcon 9 can take off on 89% thrust (one engine down). If it loses a second engine *immediately* on takeoff, it might crash. However, remember that those engines are burning through the rocket's fuel, lightening the load considerably. Typically, the fuel is exhausted after 3 minutes of flight; call it 27 engine-minutes. At that point, (or rather, right before that point, when there's still a tiny bit of fuel) the first stage is so light that even throttled all the way down, a single Merlin 1D engine produces a thrust/weight ratio greater than one (this makes landing tricky; they are constantly decelerating by "accelerating upwards", and need to pass the 0-velocity mark right when they hit the ground).
If the rocket has more fuel in it (or otherwise has more weight), then the stage can hover; Grasshopper demonstrated this. If you can hover, or even avoid crashing *immediately*, the remaining engines can run to burn off the fuel. As the fuel burns off, the rocket gets lighter. Now, counting the weight of the (fully fuelled) second stage and the payload, 1 rocket motor probably isn't enough to land safely even if the first stage manages to burn (or dump) its fuel... although it might be; after all, the second stage is able to accelerate handily under a single engine (though the vacuum thrust is higher, and of course it doesn't have the weight of the near-empty first stage too).
If they have even a few working engines - ideally in some reasonably-stable arrangement, such as any two opposing ones and the middle one - and enough time to burn (or dump, assuming there's a mechanism for that) fuel, they should be able to land the whole stack again. Dragon would probably detach and land itself - Dragon 2 definitely would, what with its SuperDracos and landing legs - but a launch using a payload fairing would just have to try and survive on the top of the rocket while the booster's RCS, grid fins, and gimbaling attempt to get the orientation right. I wouldn't put it past SpaceX to manage this, though.
The Declaration of Independence and the Constitution are very different documents. "We hold these truths to be self evident: that all men are created equal..." comes from the Declaration, which was basically a big political "fuck you" to the British government and especially the monarchy. It's not a law and has no legal weight, and unlike the Constitution it is not subject to updates (amendments). Its language might serve as a guide for the country at times - apparently, to such an extent that some people can't tell the difference between document that is merely of historical interest and the highest law of the USA - but the Declaration is merely a historical document, today.
Whoops, yeah, there should have been a "nearly" in there, my bad. What I get for Slashdotting at terrible hours of the morning.
The "primary direction" is most certainly *NOT* up; the first stage gets many times as far downrange as it gets in altitude. However, the boost-back burn is indeed pretty much entirely horizontal; the rocket is high enough that there's very little air, and what little there is, the mostly-empty stage attempts to ride by angling itself as a (really bad) lifting surface.
So yes, the rocket is forced to largely reverse its forward velocity. However, with its tanks empty and no second stage or payload, it weighs very little. Three of it's nine engines are quite sufficient to turn it around and put it on course for home.
It's been available as a "Preview" for months (since before Win10 on PC went RTM), though the early preview builds of it were far from usable. That 8.8% is a mixture of "Windows Insider" preview users (people with legacy phones) and the new Lumia 950 and 950XL flagships, which come with "Windows 10 Mobile (Preview)" and yes, the "Preview" part of that is not my own addition but is actually what Microsoft says the phone's come with. They are shipping hardware with a pre-release operating system installed. It's bizarre (and is leading to a lot of bad reviews for the 950s, saying things like "great hardware, pity about the software"), but this is MSFT, after all.
On the other hand, pre-release OS or not, the 950 and especially 950XL are apparently flying off the shelves; I live in Seattle so there's no lack of Microsoft stores/kiosks nearby, and none of them have the things in stock. They sell out each shipment within a few hours.
Just for the sake of curiosity, what "app access to SMS and call logs" are you looking for? Apps *can* access those; it just requires capabilities that third-party devs aren't allowed to declare by default. We've had the ability to unlock those capabilities for years now - the first "capability unlock" was only for Samsung phones, but was published in 2013 - but relatively few people have bothered writing apps that take advantage of this. I'm curious what your use case for this kind of access would be.
Also, W10M allows sideloaded apps to have the same capabilities that OEMs get to use. This is actually a really big deal - it undoes a change Microsoft introduced way back in WP7.5 that has set a lot of people who would otherwise be productive devs simply looking for ways to get meaningful apps to run at all - and it means that "second-party" capabilities like SMS are now available to everybody's phones again, without needing to perform any hacks.
I'm honestly rather shocked they released the 950/950XL with W10M in its current state. First of all, let's make something clear: Anybody who wants W10M on a WP8.1 phone can get it, today, no big deal. It's called the Windows Insider program and has been available for many months. You'll get the same version of "Windows 10 Mobile (Preview)" that is on the new flagship devices, and you'll get updates just like they do.
The problem is, what Microsoft calls a "preview" is what other people call a "beta". Not release-quality software, not even a release candidate where they're chasing down the last few ship-blocking bugs, but a beta. It's nominally feature-complete, but there's a lot of stuff that just doesn't work right yet, and the OS itself is prone to weird but serious glitches, hangs, even boot-crash-loops. MS is fixing these issues pretty quickly - there have been several updates already since the build that the 950s launched with - but the users and review sites all seem to agree: W10M in its current state is *not* ready for day-to-day usage. This is why Microsoft is not pushing it as an update to all WP8.1 users yet; most of them would be unhappy to go from a stable OS to a buggy one, even though the buggy one has a ton of new and excellent features.
Meh, RT was a shit-show well above and beyond not being "something Microsoft wanted to do". I've never seen a company shoot their own product in the foot (or the face, more like) so hard before. There is absolutely no technical reason that RT couldn't run .NET desktop apps; if you jailbreak it, .NET apps written years before RT existed run just fine. Native code required a recompile (but often nothing else); a native Java runtime would have added a bunch more apps immediately (there's a Java-on-.NET runtime, IKVM, which does work on RT... but it's slow and kind of buggy). There's even a homebrewed (as in, one guy's hobby project) compatibility layer for legacy apps that uses dynamic retranslation and API shims to run legacy x86 Windows apps, unmodified, on RT (not emulating a full x86 Windows, but actually running in RT; they use the same file system, registry, network interfaces, etc.). It's slow, but it's also an example of what Microsoft could have made RT be, if they'd really wanted to.
Instead, of course, after launching a crippled product and watching the community help it start to struggle to its feet usefulness-wise, they came back and crippled it *much harder* this time. RT 8.1 was eventually jailbroken as well, but it took far more effort than it should have, and by the time the new jailbreak was released, most of the community just didn't care anymore. It's really weird how much money and effort Microsoft put into making their own product less useful.
"Universal Windows [10] Apps", or whatever the hell MS calls them this morning, will run at most aspect ratios and display sizes. However, Windows 10 Mobile* still supports apps clear back to WP7.0, four API versions and one major infrastructure change old. WP 7.x and 8.x apps were never intended to run on anything that could be called "desktop mode". WP8.1 supported its own version of "universal" apps, where you could use the same code for PC/tablet and phone apps, but I'm not sure if that means universal WP8.1 apps installed on the phone will have the ability to handle Continuum. We shall see.
The primary targets for Continuum (For Phones, as opposed to the whole "auto-switch to tablet mode" thing on convertible laplets) are, at least initially, Microsoft's built-in apps. Edge and "Outlook" (it's a very nicely souped-up mobile email client, but Outlook it is not) and OneNote and Word and so on. The Office apps built into W10M are way more powerful than they were in any previous Windows Phone version, even in phone mode; in PC (Continuum) mode they'll be weaker than actual PC versions but much closer than you might expect.
Also, while new hardware is required to use the dock that allows plugging in a display and USB devices, you can connect Bluetooth keyboards and mice to a legacy phone running W10M just fine, and there's been ways to mirror the phone's screen on a PC for years. That's not as good as Continuum, but maybe there's also a way to directly, wirelessly connect the phone to a PC or TV screen - I haven't checked - and that mostly solves that issue.
* which, unlike what some people have claimed, is no more a "reboot" of the OS than Windows Phone 8 -> Windows Phone 8.1 was; they just changed the name again
Removing or renaming the Flash binary, making it non-executable (yes, Windows has Execute permissions, just like *nix), or de-registering it from HKCR (ActiveX is just COM, and registers by GUIDs under HKCR\Classes, or using regsvr) are all valid options here, too.
But yes, it's pretty goddamn stupid that Outlook should execute Flash. It doesn't allow scripts in HTML email, but it allows something that is a superset of what JavaScript can do? Moronic.
Nope, @ragefan didn't say that. However, your beliefs appear to be interfering with your reading comprehension, so I can see how you would have read their question in a way consistent with your ideology.
The possibility that someone, somewhere might drive with really bad judgment or without sufficient knowledge of how to do so safely is why we have driver's licenses, and ban driving without one. Being drunk impairs your judgment and ability, so if you drive while in that state you have demonstrated that you are not safe to have behind the wheel, and you lose your license. Even though modern society in many parts of the country is heavily dependent on having a car, operating a car without a currently-valid license is deemed a sufficient risk to society that you can be imprisoned for it.
So, which of the following logically consistent arguments would you like to make:
A) "I was wrong, and yes, guns should probably be licensed at least as strictly as cars."
B) "Guns are less dangerous to operate than cars, so they don't need to be licensed even though drivers do."
C) "Private guns are more vital to society than private cars are, so they need to be less restricted."
D) "You don't need a license to own a car, so you shouldn't need one for a gun unless you want to ever do anything with it."
E) "Operating a car shouldn't require a license either, and should never be a crime unless you cause actual harm with it."
F) Something not included above, but that is logically consistent and has supporting evidence.
For the record, you *might* have an argument with C and/or D, though a hardcore libertarian would presumably argue E.
Yep. First thing I thought when I saw that line. I'm not generally a fan of the degree of influence businesses can impose on the government, but if it takes the united front of everything from Apple down to (relatively tiny) Mozilla to stop this bullshit, I'll take it. The NSA has already cost American corporations significantly, both in lost sales and in needing to defend themselves against their own government (which, in fairness, isn't that different from the defending against foreign governments that they probably should have been doing anyhow). Throw the FBI in the ring too, and "Made in USA" software is going to become untouchable, anathema to all the rest of the world's businesses.
Except... those companies already pay six-digit salaries. It's not the tech giants who would be hurt by this, it's the companies where typical wages are in the mid-to-upper 5 digits and cost of living is half (or less) what it is on the coast. The giants would actually benefit, here; there'd be less competition for the visa workers.
Incorrect.
Heartbleed wasn't exposing memory from other processes, it was exposing memory from the address space of the vulnerable process. The data leaked in Heartbleed attacks was all data that the program had put into memory itself. For example, if you create a HTTP request to a login page, and populate it with credentials, and then try to send it over an HTTPS connection using OpenSSL for the TLS, that request (with its plain-text credentials) could be leaked out of memory by Heartbleed. Similarly, OpenSSL on the server needed to know the private key of the server in order to decrypt and sign messages, so that private key was stored in memory by OpenSSL itself and could be leaked in a Heartbleed attack.
Using calloc() wouldn't have made it harder to exploit the basic flaw (leaking memory from the process due to buffer overread) at all; at best, the 64k of leaked memory would have had more zeroed bytes in it. That might have been a *small* help, if those bytes had previously stored sensitive data that was then freed and re-allocated for a different use but hadn't yet had new data written into them. That's an extremely unlikely scenario, though. More likely, either the sensitive data would never have been freed, or the re-allocated data would have been overwritten, or the sensitive data would have been freed but kept in memory (remember, calloc() doesn't wipe until you call it to allocate the memory; if you want to zero bytes before freeing them you have to use a function to do that).
Now, part of the problem *was* due to the way OpenSSL (through absolutely no fault of the operating system) handles memory; rather than having the OS and runtime library do memory management, OpenSSL grabs (grabbed? Maybe they fixed this) a pile of memory from the OS, and then "allocates" and "frees" it using an internal memory manager. This meant that Heartbleed was virtually guaranteed to find 64k of contiguous memory, without the holes where the OS hadn't mapped any page into the program's address space. Such holes would have caused an access violation / segmentation fault when Heartbleed tried to read them, and crashed the program; bad for server uptime, but better than exposing a bunch of data that is sensitive enough you wanted to transmit it through an encrypted channel (or leaking the encryption key for the channel itself, etc.)
My bad, you are correct. The OS does actually clear memory when it is newly allocated to a program (or possibly when it is released; I'm not sure). That would, otherwise, be a huge security risk.
There's no need to clear memory each time memory is re-allocated *within* a program, though, except as a debugging technique (detecting the use of uninitialized memory), for which a distinctive pattern is usually used instead of simply zeroing the data. Memory managers usually handle many allocations smaller than full pages, so calling free() (or delete) doesn't always immediately return memory to the OS. That memory is usually re-allocated to a different buffer or object in short order, and zeroing it between those times (while still owned by the process) is wasteful.
There actually is an x86 emulation (well, dynamic recompilation, which is faster) layer for Windows RT. It's unofficial and only runs on jailbroken devices, but it's there. App compat isn't that great yet, because it has to shim all Win32 calls from the x86 version to the ARM version (this is much faster and has a smaller install footprint than emulating a full x86 Windows, and makes it possible to optimize the translation a bit, but means each Win32 API needs to be shimmed and there are a huge number of them).
It's largely the work of one developer, aside from the form from existing open-source code. Microsoft could easily have produced something much more complete than this, especially since they have access to the original implementations of the functions in question (the dev of the compat layer had to work off public headers, MSDN docs, and stuff from Wine and ReactOS). Done right, this software could have hugely improved interest in RT.
Instead, Microsoft doubled down on the lockdown in RT8.1, blocking the 8.0 jailbreak in multiple different ways and setting back progress on the OS until people basically lost interest. Work has resumed now that there's a new public jailbreak, but the original dev has moved on (though the compat layer is open source) and most people just don't care anymore. I have never seen a company so deliberately destroy one of their own products before...
Linker flag, technically, but yes. The compiler produces machine modules which are always at known addresses relative to other parts of the module (but not relative to the address space as a whole), or relative jumps and branches wouldn't work and that would break everything. The linker controls how each module finds the base addresses of other modules. When the OS loads the binary produced by the linker, it can place the modules into memory at addresses controlled by a random mask, and the modules query these (masked) addresses when they are trying to find the addresses of code or data in other modules. However, old OSes always loaded the modules at the same addresses relative to each other (allowing one module to call directly into another, without needing to look up the address of the other module) and therefore the OS doesn't randomize module locations unless the program supports doing so.
On Windows, in Microsoft's SDK, the linker flag to produce a binary that supports random memory layout is /DYNAMICBASE. It's been enabled by default in the last 5 or so versions of Visual Studio.
I get the feeling that you really don't understand how memory exploits work. You seem to be under a very large number of misconceptions, and to have come to all sorts of wrong conclusions based on them. I hope you haven't misled too many other people with your incorrect views on some of the very basics of how operating systems work. Hopefully the following constitutes a "satisfactory explanation" for you:
No, it's not. That hasn't been possible on any mainstream OS for many years (DOS/16-bit Windows, maybe old versions of Mac OS?). I mean, you can do it using debug APIs (on Windows, see things like WriteProcessMemory), but if your code has privileges to debug a high-privilege process it could also just do "BADSHIT" directly. A low-privileged process (which you already have code execution in, if you're talking about calling WriteProcessMemory) can't debug a high-privileged one.
What do you think the silver bullet is for stack overflows, then? Using counted functions is vulnerable to off-by-one errors (or other things that specify the wrong count), integer overflows when creating the buffer (malloc(itemcount * sizeof(Item)) will, for sufficiently large itemcount, produce a tiny buffer that will immediately overflow when written to), and many other risks. The closest thing we have is languages that manage their own buffer lengths and such, like Java, Python, JavaScript, and the (other) .NET languages... and those still have implementation errors that lead to memory corruption sometimes (I'm sure you've noticed that JavaScript engines, in particular, are not fully safe even though JS as a language is supposed to be safe). Managed languages are also still significantly slower than optimized C/C++ code, though the difference isn't nearly as bad as it used to be.
Or do you mean mitigating the overflows with DEP and ASLR? First of all, that's not a guaranteed fix; if the attacker can leak an address from the program to use as an offset baseline, or otherwise determine the ASLR mask, then that protection can be bypassed. Second, that assumes that there aren't any executables which insist on being loaded at known addresses... and as this story shows, we still have a ways to go to achieve that.
It can't, unless process Y is consuming output from process X and writing it into its own memory (for example, an antivirus filter scanning a file that a web browser downloaded and wrote to disk). See first point.
It is, as far as assigning memory to processes goes. Within a process' own address space, "managing memory" is literally 100% of what a computer program does (reading values, changing values, setting values, copying values, testing values, etc.). Well-behaved programs don't care what addresses the OS hands it, but not all programs as well-behaved in this way.
They are, for modern software... unless that software says it's incompatible with this behavior. Since a lot of old software *is* incompatible with this behavior - see above point - the OS defaults to trusting the software. In the case of the AV vendors mentioned in TFA, that's apparently a mistake, but it's not the fault of the OS for trusting the software you told it to install, it's the developer's fault for not making their software as safe as possible, and your fault for installing software that you can't trust to be safe.
Not *really* relevant here, but I'll add
Unless your code assumes that a given function is always loaded at address 0x004006AE, or something stupid like that. Which older software sometimes does, so Microsoft had to make ASLR opt-in by default. Except some *new* software is still not opting in, despite it being the default on Microsoft's linker for the last 5 versions or so.
You can use Microsoft's free tool EMET to force a program to use ASLR, and some Windows programs are now always forced to act this way by default. ASLR applies to DLLs and other executable files, not just to the base EXE, so sometimes a third-party library can make your otherwise-safe process vulnerable. I'd like to say that we can apply such "force everything to be relocated randomly" rules to all software now, but if three major AV vendors hadn't turned on the option until now, maybe we aren't there yet.
Sigh...
Not *another* process. AV software consumes a ton of untrusted input - that's literally its entire purpose - and sometimes it has security flaws itself. If there's a security bug in AV filters (which isn't actually that uncommon) and ASLR is on, the malicious input can crash your AV software (which may, or may not, bring down your system and require a reboot). If ASLR is off, even for a single binary in the process' address space, though, the malicious input can completely take over your machine.
I'm sorry, I wasn't going to post in this thread, but people keep posting this utter idiocy like it means anything.
I drove into California a couple weeks ago. I came across the Oregon border, from Washington. Both of those states are, as far as I can tell, much more lenient on guns than California. The border person didn't ask about guns ("you have any fruit?" / "no" / "all right" and waves us through) and didn't even try to look in the car, which was half-full of baggage that could have carried enough guns and ammo to have defended the Alamo.
STATE gun control is meaningless. California's border probably sees many thousands of guns (that the CA government never learns about) cross it every day in civilian vehicles, and they're one of the only states that bother to mark their border with anything more than a signpost! If you don't have an actual perimeter within and across which guns are controlled - and we don't, not for anything close to the regulations that California has - then you don't have gun control. It doesn't matter where in the USA this happened; all we needed to know was that it happened in the USA.
California's laws are feel-good wastes of paper. Go nationwide with similar laws (or enforce the check at the CA border). Implement tested systems for reducing guns, like buyback plans and so on, instead of just passing laws that criminals have no reason to care about. Do that for a few years, and then check the statistics and we will see if gun control actually does anything. Right now, without looking at non-USA sources, we have no way to know... because nowhere in the USA, California included, has meaningful gun control.
It isn't that
Only if your definition of "conflict" inherently requires violence, in which case your sentence uses circular logic and it meaningless. British occupation of India and South African apartheid are two relatively recent examples of major conflicts between large numbers of people that were resolved without the victorious side resorting to violence.
Win32 != WinNT. Win9x (Windows 95, 98, ME) implemented Win32, but did not use the NT kernel. Hell, Windows 3.11 (which was 16-bit, while all NT versions have been at least 32-bit) had a partial Win32 implementation called "Win32s" that could be used to run some Win32 programs even though the kernel was still 16-bit. Windows CE (including Windows Mobile, aside from the confusingly-named "Windows 10 Mobile") implements Win32, but is completely unlike the NT kernel. A modified version of the CE kernel was used on Windows Phone 7 (I know, because I wrote code that parsed WP7 kernel data structures, which scarcely resemble NT ones), but CE was scrapped in favor of NT for WP8 and later.
CE has been ported to more platforms than NT and has much lower minimum requirements, but uses a far simpler memory manager, does not support SMP (multiple hardware cores), does not support NTFS (it uses a weird variant of FAT that allows files to be "modules" loadable as executable images but not openable as files; NT has no such concept), does not support any kind of access control (a rudimentary access control system was grafted onto the CE kernel for WP7, but it bore no resemblance to the NT access control system that WP8-and-later use), does not support NT drivers, does not use the NT bootloader, is missing many security features (of which user accounts and access controls are only the most visible) that NT has, and is generally unsuited for anything except embedded systems (but has some features targeting those, such as some real-time support, that NT lacks).
How is the parent not yet modded Troll?
A) Anybody who wants to study the science behind those things can do so, and there is quite sufficient evidence (replicated continuously in labs all over the world) for the latter two (assuming you mean Darwin's theory of evolution by natural selection, and yes, speciation through evolutionary response to environmental pressure has been demonstrated in the lab). The effect of the first is still hotly (haha) debated, but the basic science behind it - humans emit literal tons of CO2, CO2 causes greenhouse effect, greenhouse effect warms the planet - are quite thoroughly understood.
B) Can you find me anybody, anywhere, who was killed for not believing in any of the above three things? I'd call you a blithering idiot to your face, but I wouldn't have you killed even if I was dictator of the world and could get away with it. It bears no resemblance to the kind of fanaticism that leads to mass murder.
The evidence is present and sufficient, and nobody is demanding you accept it. You might find yourself lacking opportunities to breed with anybody that has an IQ above room temperature, but such it the price of being vocally moronic.
It would work with a preloaded pin list similar to the HSTS preload list, for sites that should use HTTPS even on the first visit. It would also work for sites like Google properties (in Chrome) or Mozilla properties (in Firefox) where the expected cert is baked into the browser even in advance of HPKP deployment.
It would also work if nobody was intercepting your traffic the first time you visited the site. You would only be in danger if you were being intercepted every single time, including the first time, with this rogue certificate. That's a relatively low-risk threat, though the possibility of such interception does exist and this is why HSTS has a preload list.
But yes, this kind of pwned-before-you-even-start thing is Really Bad.