It's actually explicitly forbidden for the CIA to do so; not because it's Congress in particular but because Congressthings are Americans. Saying "spooks regardless" ignores the fact that they're supposed to be balanced against each other. Of course, they all end up collaborating instead, but in theory that's punishable.
Probably the Touch Pro or Touch Pro 2. Yeah, those were great. I saw people using them well after they were obsolete, just for the good keyboard and decent (for the time) display.
The HTC 7 Pro was supposed to be the successor to that line, running WP7 instead of WinMo, but it had relatively limited availability and the smallest screen of all WP7 devices. None of the slider WP7 phones did well, although there were at least three model lines of them (LG had one, HTC had the 7 Pro, and Dell had the Venue Pro). As far as I know, not a single WP8 handset has a slideout keyboard, and there are few-if-any Android phones that have come out in the last year-or-so (same time frame since WP8 launched) with slider keyboards either.
My Samsung ATIV S (same hardware as the Galaxy S3) does this, except it will work for a little more than two days and it doesn't switch off *all* smartphone features, just the ones that run automatically in the background. You can still do things like play games on it, or *manually* trigger an email sync, if you're willing to accept the battery hit.
Of source, every single Windows Phone 8 device has this feature... The percentage of battery where it does this automatically is not settable (it's always 20% if automatic mode is enabled) and the duration that it can last when in Battery Saver mode will very depending on how much actual capacity "20%" is (the ATIV S had the largest battery of the first-wave WP8 handsets). However, you can manually enable Battery Saver any time you want to, and you can (as of the latest update) also exclude specific apps from the Battery Saver rules (so you could keep synching one vital email account but stop synching the others, for example).
I really don't understand why something like this isn't standard in all smartphone operating systems. It's an obvious, useful feature. Smartphone batteries actually last very long if the phone isn't doing anything except listening for phone calls or messages - my phone reports 21 days of battery life if I put it into Battery Saver right after charging - but the things that make a smartphone really useful eat a lot of that. My HTC One M8 is a much newer phone than the ATIV S, and can survive in "full smartphone" mode longer now than the ATIV can... but without third-party tools or a bunch of manual tweaking, it will die while the Windows phone still has about 28 hours left.
In fairness, the SLS is supposed to be more powerful than the Falcon 9. On the other hand, an extra $400M would probably be plenty for SpaceX to get the Falcon Heavy flying, which will be capable of most of the things that the SLS is supposed to handle and at a vastly lower per-launch price even if they *don't* manage to make the launcher reusable. Hell, an extra $400M would probably go much further toward SpaceX managing to build their interplanetary craft (the one that's supposed to ferry people to Mars) than it will actually produce toward the SLS, and you'd get a more powerful (and probably *still* cheaper per-use) spaceship out of it, too!
I wasn't under the impression that the government making things that help (in the case of the TSA, that last word is highly sarcastic) a private industry render that industry public. If that were the case, any industry that relied on the interstate highways (or even just public roads) would seem to apply. Or anything involving oceanic operations (Coast Guard, NOAA weather stations, survey charts, hell even GPS). In many parts of the country, municipal water is government-run; does that mean that the government "funds" restaurants by making sure that they don't need to perform their own water quality testing before they can serve it to their guests?
Mind you, I'm ignorant of (and therefore not considering) any legal history which may exist around this issue. So far as I know, the gov does not actually directly fund airlines in any way and instead just has agencies who are responsible for making sure that planes don't fall out of the sky, crash into each other, or get hijacked for use as missiles... at least, not very often. I'm not sure how this is different from the government agencies which make sure that road signs are accurate, bridges can support the weight of a truck driving over them, and people aren't allowed to tear through residential neighborhoods at whatever speed they feel like. Well, aside from the fact that many (though not all) of the relevant agencies are operated by lesser governments than the feds.
Anyhow, if there's actually something that makes the difference, then I'm curious but accept that my understanding was incorrect. To the best of my knowledge, an airline agent is a public servant in much the same way that a cruise ship agent is - that is, not at all. They have authority within the scope of their employer (including the authority to evict you from the plane, assuming that in doing so they are not putting anybody's life in undue danger) but then, so does any restaurant proprietor if they have reason to believe that you are harmful to their business. They have the authority to call the police, but so does any private citizen for any scenario in which they think a crime has been or is being (or imminently will be) committed. They do not, to my understanding, have the authority to force the police to arrest anybody or indeed to show up at all, although given the nature of their job I'm sure they can convince the police to show up any time they want them to (at risk of crying wolf too many times). Again, correct me if I'm wrong about any of this.
What first amendment rights were violated? I'm absolutely serious about this; please point to any violation of first amendment rights anywhere in here.
While you do so, remember that the first amendment restricts the actions of the *government* - that is, it prohibits the making of laws that do certain things - and has absolutely nothing to do with the private sector. Here, let me quote it for you (emphasis mine):
Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
So, which law did SWAirlines cause Congress to pass that violated these people's first amendment rights? Go on, point it out please.
Or were you just mouthing off about stuff you don't understand, trying to get people riled up about an issue that doesn't even exist? Because that... well, let's just say it speaks volumes about your intelligence (and that of the person who modded you up). Volumes that I doubt you would ever read, since apparently you can't be bothered to read (or at least, understand) one of the most important *sentences* ever committed to text in the history of this nation...
No offense, but that's a kind of dumb assumption. They explicitly state that they make the games compatible with modern systems. With a large portion of their catalog being 16-bit, and 64-bit OSes not able to load 16-bit apps, they *need* to be wrapping the games in emulators or the like.
Yes, the original game files - or very close, minimally-patched versions - are in there. However, the vast majority of their customer base wouldn't be able to do anything with those game files. Even if they were, it wouldn't be the simple and user-friendly experience that it is today.
Now, as a Linux user trying to run Windows software, you're pretty much writing off "simple and user-friendly" from the get-go (I've been gaming in Wine since 2006; it's better than it was but it's got a long way to go and the goalposts keep moving). Given that, maybe it would have been nice for the small portion of users who care if they'd provided a "here's the files and instructions you need for setting this up in ScummVM on the platform of your choice" option... but that's not their target market, and frankly it might actually be harmful to their goals (never underestimate the cost of support calls from idiots who think they know what they're doing).
Hence, while many of their games have been *able* to run on Linux since GOG released them, the really core portion of the service - the dead-simple installers and updates - didn't. That is what they're now changing.
Yes, please! Hell, just dumping the lockdown (or rather, making it optional) should boost sales a good bit; there's a fair bit of recompiled code already available (jailbroken) RT. Something with RT's battery life and hardware support, but able to run "real" Windows software, is a desirable machine for many people... and as you say, there's also many who would like to put Linux on it, and get an ultra-portable Linux machine that can also run Windows stuff at need.
There's already a semi-functional x86 emulation (dynamic recompilation, more accurately) layer for RT. Considering it's the work of one hobbyist in his spare time over a few months, without access to MS source, I'm sure MS could do a lot better themselves if they wanted to. With that said, I can see the argument for not doing so after all..NET binaries run as-is, anything MS owns can be ported, and perf impact of recompilation onto a less-powerful architecture, especially for something as complex as x86, is pretty heavy. (The current tool will happily run 2D games... from the late 90s.)
What the [redacted] do you mean "go back to" promoting.NET? Honestly curious. I mean, you obviously know [redacted]-all about it (among other things, while it compiles to bytecode in the typical use cases, it's executed as native code thanks to a JIT compiler that takes it the rest of the way for whatever platform it's on) but I'm not sure how you've missed the fact that it's the primary platform for Windows Phone apps (WP7 only supported Silverlight or XNA - both of which are.NET - for third-party apps; WP8 allows native code but most apps are still mostly or entirely.NET), Windows Store apps (JS and native are both available, but.NET is very heavily used), client apps (it's rarely used in big apps, but widely used for small utilities), server apps (hell, the Server Core SKU doesn't have a GUI, just PowerShell... which is a.NET-based command line interface), and games (all Xbox360 indie games - there are many thousands of them - are XNA which is.NET).
They added native code options for Phone and WinRT because people wanted them for performance-sensitive stuff, but the vast majority of the software for those platforms is architecture-independent. Windows RT will run the same.NET binaries that Windows 8 will.
Microsoft actually sold a highly-successful cross-platform Unix system for many years, back in the pre-NT days. You didn't think they ran the company on DOS, did you? They used Xenix machines extensively into the 90s, until NT was in a position to take over.
For that matter, back then NT had a POSIX subsystem and could run most Unix software with little more than a recompile. In case you're curious, by "back then" I mean "until Windows 8.1"; the POSIX subsystem is still available in Win7 and Win8. It's not a great Unix, but it's better integrated into Windows than a VM or CoLinux, or even Cygwin, and it does the job... or did. When MS discontinued it, they also cut support for the most-used software repo, and staying up to date currently means manually updating or moving to a different package manager.
Win8 (especially 8.1) already does this, to a small degree. Buttons and menu items are bigger on touchscreen systems, and I think the default state of boot-to-desktop-vs.-Start-screen is already input-hardware-determined. It certainly doesn't require any new APIs, much less new drivers!
With that said, yes, Win9/Threshold/whatever will be a more dramatic example. It's not new, though.
Nokia was struggling quite badly before Elop. I'm not dismissing your claim that Microsoft devoured it, or that Elop was a major part of that, but if you take off your rose-tinted glasses of Nokia past (which was excellent, undeniably) and look at the Nokia of just a few years ago, that company was in major trouble.
Now, they *could* have made a run at being the next Samsung, and gone with Android. Or they *could* have put real resources into Maemo/Meego/whatever-they-were-calling-it-then, brought out a really modern successor to the N900, and tried to compete solo. Or they *could* have canned everything else and pushed Symbian as far as it would go.
But they had to do something. They were hurting, badly, and showing no sign of an actual path out.
It's a $300 phone. That's "cheap" only by comparison to the high-end models; it's actually more accurately called mid-range. You can get vastly cheaper (less than half the price) smartphones that have better software/firmware. Their specs will be worse, but - and this is the whole point of the article - nobody will notice the shitty software and firmware before they buy, whereas a bad spec list makes a phone look bad (and cheap) even if the actual experience of using it is pretty good (most people don't come close to really using the full power of their phones).
No. The solution isn't that somebody needs to rate phones. It's that the rating needs to be obvious and visible. If I go into a store and look at a line of phones, they'll all tell me their screen size and their CPU speed and usually what OS version they have, plus usually one distinguishing feature, but that's about it.
Compare that with, say, buying a game or other piece of software. There will be review scores (and actual reviews, if I go looking, but the scores are prominently displayed), there will be awards given, there will be indications of the actual *quality* of the item. Not flawless ones, of course, but a hell of a lot better than getting nothing but a short list that tells me this is a RTS game, supports up to 8-way multi-player, runs on Windows XP or newer, requires 20GB of storage, and features a campaign with multiple endings depending on the decisions you make in game (or similar "cool but you have no idea how well that works" feature).
Of course, nobody *wants* to display a bad score on something they're trying to sell you... but they'd happily display a good one. The idea is to make such review scores sufficiently widespread and usable (which requires decent accuracy) that people will actually A) pay attention to them, and B) notice when they are missing.
I actually found it interesting, exactly *because* of the comparison to things like the Lumia 520 (the only really-low-end smartphone I have any experience with - I've done a lot of security review on them - in the last five years). The 520 is an unabashedly low-end phone. Rear camera only, no flash, 5MPx (for Nokia, this is low-end indeed). 480x800 used to be pretty good for a 3.5" screen, but these days it's pretty meh. 1GHz CPU, even though it's dual-core, is about as low as it's possible to find in a brand new smartphone, at least in the USA. No 4G, no NFC, etc... but the radios it does have had good firmware. The software runs well within the confines of that hardware, and doesn't have any bugs that I found which its higher-end brethren fixed.
My roommate still uses DDR (OK, technically Stepmania) as his workout routine. I tend to go with Dance Central on the Kinect instead, but... yeah, they're both amazing workouts.
MS brought in about 25,000 Nokians, so it's about half of that. 50% cuts is huge, but part of the problem Nokia was having before (Pre-Elop, even) was a massively overinflated headcount of redundant positions. Add to that the fact that Nokia really does have a lot of redundant people now (MS already has marketing folks, sales folks, legal folks, etc.) and I can believe that they're getting cut by a large measure without it being crippling to the phone division.
Whether or not it survives a few more years, though... can't say. The 8.1 update finally brought a ton of stuff that people have been asking for since basically day one (unified notification center, one-touch control of settings, ringer volume separate from the app volume, etc.) and while some would say it's too late, there are parts of the world where 8.1 is actually fairly common (over 10% market share). That's enough of a foothold to carry on if they don't wreck the things they have going for them.
ArchieBunker either has no fucking clue what he's talking about, or is just trolling. Not sure which. To set the record straight, though: 1) You can't move the pointer (one assumes that's what he meant by "CURSOR") with your finger. Anybody who has used Windows on a touchscreen knows this. You can move it with the stylus, and you can do gestures with fingers, but you can't move the pointer. 2) Moving the mouse to the upper right corner brings up the Charms bar, just like the little animation shows. You can disable that behavior if you want to, but it's enabled by default whether you have a touchscreen or not. It is a ridiculously blatant lie to claim otherwise. 3) Anything you can do with the mouse in Win7 or below, you can do with the mouse in Win8. Sometimes the exact form it takes is different - for example, right-clicking in Metro-style apps brings up a context-sensitive app bar instead of a context menu - but it's there. You can operate menus, launch/minimize/restore/maximize/snap/close apps, scroll documents, and so on.
Sadly, at least one moderator fell for it. Or maybe they have an agenda and don't mind spreading... is it even FUD when it is blatantly , easily provably false? Spreading lies, because spreading FUD wasn't quite good enough, I guess...
The Start button was always there. It was hidden, in the same sense as the "Hide Taskbar" feature that's been there since what, Windows 95 or maybe 98? Mouse to the corner of the screen, button appears. Left click it, get Start screen; right click it, get admin menu. In the meantime, you get a bit more space on the taskbar.
Mind you, it'd have been nice if they'd made that *optional* (the way that Hide Taskbar is optional), but considering the Windows setup process - either on a new machine or on a clean install - spends like 5 minutes explaining this to you with really repetitive animations, it's pretty sad that people were *that* up in arms over it.
What MS could have done to make it a bit better is to allow the standard vertical scrollwheel most mice come with nowadays to scroll the start screen; down = right, up = left (because you always started at the TOP of the start menu, naturally you'd scroll DOWN for more, while the start screen starts at the LEFT, requiring you to scroll RIGHT for more).
What the hell's wrong with your system? That's exactly what it does, at least on 8.0 (haven't "upgraded" to 8.1 because they cut a feature that I regularly use). My mouse wheel is not capable of side-scroll, but I just tested with vertical scrolling and it works exactly like you describe.
Of course, the reason I had to test that is because it's not something a sane person should ever need to do. You have a keyboard, right? Type the first few letters of the program name (or type the file name), hit Enter, and behold the launching of your program. Just like you've been able to do for the last 7+ years, since fucking Vista (to say nothing of Win7).
The sad thing is, NT itself has (or rather, had) a POSIX API. Up through Win8 (but not 8.1) you can actually get a basic but functional *nix environment running on NT natively (or as natively as NT runs Win32 at least, which is to say it works pretty much seamlessly and nobody back a handful of hacker-types care about the underlying guts). Shells, libraries, utilities, GCC-based build toolchain... pretty nifty, and it integrates better with Windows than Cygwin ever has, while also being faster and supporting things that Cygwin doesn't (setuid, etc.)
However, Microsoft has seen fit to stop funding the maintainers of the package repo for it (there are third-party repos - NetBSD has one, last I checked - but SUACommunity/InteropSystems was where you went for most of this stuff) and to discontinue the POSIX subsystem entirely as of NT6.3 (Win8.1). Very irritating. They say to use Cygwin instead, which is technically a viable option for most of what I use SUA/Interix for, but it's not one I'm happy about needing to take (and move everything over to).
Better yet, "valid" ASCII-armored PGP blobs (or PGP attachments) that don't actually contain any decryptable data, but are otherwise indistinguishable from a real blob. Put a random key ID in there, cycle it every time, claim they are one-time use if anybody ever reaaaaally gets on your case about it.
I have well over 100 passwords for various accounts (I have no real idea how many I'm up to by now). I can probably remember about 50 of them off the top of my head, and can make educated guesses at many of the rest... but unless it's a password I use regularly, I'd need to check my password keeper (which I do not keep on my phone or in physical form anywhere) to be sure. Some of the more obscure ones I wouldn't have a chance at, and it would probably take me at least a few tries to remember which one was for something I hadn't used in over two years.
Sorry to self-reply, but I figured I should add some mitigations (for those who don't RTFA...)
First of all, as a user, one can of course disallow Flash by default (or remove it entirely). Mechanisms for doing this vary by browser, but all major browsers have at least one. You can also update Flash. The latest version, released today (Tuesday the 8th), tightens up the validation of "compressed" applets in such a way that it should catch the output of this "Rosetta Flash" program.
For sitemasters / developers, there are a few options.
You can host your JSONP service on a different (sub)domain from your sensitive data. This is most effective if the JSONP responses are either static or if there's a CSRF token for accessing the user data.
You can add the string/**/ to the beginning of the JSONP response body, right before the callback identifier (this is what Google and GitHub are doing, for example). This will be ignored by the browser when it's treating JSONP as JavaScript (a 0-character comment) but will break the reflected-Flash-applet attack because the start of the response body no longer contains the magic number for any kind of Flash applet.
You can add a HTTP response header like Content-Disposition: attachment; filename=f.txt to the JSONP responses, which will prevent all reasonably recent versions of Flashplayer from executing it the applet.
You can add the HTTP response header X-Content-Type-Options: nosniff to all vulnerable responses (or just all of them), and then make sure that you specify the correct Content-Type header (it should be Content-Type: application/javascript although application/json, while technically incorrect, will probably work too). This header forces most browsers to pay attention to the server-provided content type, rather than letting the web page specify or guessing from the content itself.
I don't know about English, but I can produce an explanation that is understandable by most people with at least some knowledge of how the web works, hopefully... It's not going to be short or simple, but I'll at least try for clear.
JSONP is a web service communication method. The idea is that a client (a web browser) sends a request to a given URL, and in that URL they include a "callback" parameter. The response from the server is a blob of JavaScript starting with the callback parameter (as a function name), and then containing additional data (as a JSON-defined object, usually). Examples: A target URL that looks like this: https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint Produces a request like this (no body, and some headers omitted for brevity): GET/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint HTTP/1.1 Host: vulnerablesite.com Cookie: VulnerableSiteSessionCookie=JoeBlowIdentificationValue... That produces a response like this (again, header details omitted): HTTP/1.1 200 OK Content-Type: application/javascript Content-Length: 41 ...
jsonp.handle_some_endpoint({"foo":"bar"}) The browser would then interpret that response as JavaScript, calling the named function.
Now, this looks risky but normally it's safe enough, because while an attacker could embed a <script src="https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint"/> script source tag that specifies an arbitrary callback name (which then gets executed as JS), there's nothing really dangerous they can do with that because the server will disallow most sensitive characters in JS (things like ( ) = ' " < >) from the callback name, so you can't actually embed arbitrary javascript in the response. Usually the attacker doesn't control the content of the parameter (the JSON blob) either, or at least can't make it be anything except JSON (which is normally pretty harmless). For example, the attacker could pass "alert" as the callback, in which case the victim gets a message box saying "[object Object]" or similar. Whoop-de-do.
OK, so the attacker can't do much just by invoking a script with an arbitrary callback name. However, Flashplayer can execute applets in a number of formats, including formats that are theoretically compressed. I say "theoretically" because there's actually nothing requiring the data to be "compressed" in any even vaguely efficient manner (which tends to produce dense blobs of seemingly-random binary values). Instead, it's possible to create a "compressed" file that only contains alphanumeric characters (and is therefore valid as a callback name), but when it is "expanded" it produces an arbitrary binary blob (such as a compiled Flash applet).
So, here's what the attacker does. They create a malicious Flash applet. They run it through the special compiler this guy came up with, which converts it into a "compressed" applet format containing only characters that are valid for a callback name. They place an HTML object tag on their own, attacker-controlled website. The object specifies the jsonp service on the vulnerable site as its data source (the way one might specify youtube's flash applet as a data source), and specifies the callback name to be the alphanumeric-format applet. The attacker also specifies that the type of the data is application/x-shockwave-flash.
When a user visits the attacker's site, their browser sees the object tag and tries to retrieve the specified data. The response they get back is *actually* a JSONP script, but the first part of it - the callback function name - is *also* a valid Flash applet. Because the object tag specifies that the data type is Flash, the browser obligingly loads Flashplayer and runs the malicious applet (it ignores the ({"foo":"bar"}) blob at the end).
Slashdot Mirror
It's actually explicitly forbidden for the CIA to do so; not because it's Congress in particular but because Congressthings are Americans. Saying "spooks regardless" ignores the fact that they're supposed to be balanced against each other. Of course, they all end up collaborating instead, but in theory that's punishable.
Probably the Touch Pro or Touch Pro 2. Yeah, those were great. I saw people using them well after they were obsolete, just for the good keyboard and decent (for the time) display.
The HTC 7 Pro was supposed to be the successor to that line, running WP7 instead of WinMo, but it had relatively limited availability and the smallest screen of all WP7 devices. None of the slider WP7 phones did well, although there were at least three model lines of them (LG had one, HTC had the 7 Pro, and Dell had the Venue Pro). As far as I know, not a single WP8 handset has a slideout keyboard, and there are few-if-any Android phones that have come out in the last year-or-so (same time frame since WP8 launched) with slider keyboards either.
My Samsung ATIV S (same hardware as the Galaxy S3) does this, except it will work for a little more than two days and it doesn't switch off *all* smartphone features, just the ones that run automatically in the background. You can still do things like play games on it, or *manually* trigger an email sync, if you're willing to accept the battery hit.
Of source, every single Windows Phone 8 device has this feature... The percentage of battery where it does this automatically is not settable (it's always 20% if automatic mode is enabled) and the duration that it can last when in Battery Saver mode will very depending on how much actual capacity "20%" is (the ATIV S had the largest battery of the first-wave WP8 handsets). However, you can manually enable Battery Saver any time you want to, and you can (as of the latest update) also exclude specific apps from the Battery Saver rules (so you could keep synching one vital email account but stop synching the others, for example).
I really don't understand why something like this isn't standard in all smartphone operating systems. It's an obvious, useful feature. Smartphone batteries actually last very long if the phone isn't doing anything except listening for phone calls or messages - my phone reports 21 days of battery life if I put it into Battery Saver right after charging - but the things that make a smartphone really useful eat a lot of that. My HTC One M8 is a much newer phone than the ATIV S, and can survive in "full smartphone" mode longer now than the ATIV can... but without third-party tools or a bunch of manual tweaking, it will die while the Windows phone still has about 28 hours left.
In fairness, the SLS is supposed to be more powerful than the Falcon 9. On the other hand, an extra $400M would probably be plenty for SpaceX to get the Falcon Heavy flying, which will be capable of most of the things that the SLS is supposed to handle and at a vastly lower per-launch price even if they *don't* manage to make the launcher reusable. Hell, an extra $400M would probably go much further toward SpaceX managing to build their interplanetary craft (the one that's supposed to ferry people to Mars) than it will actually produce toward the SLS, and you'd get a more powerful (and probably *still* cheaper per-use) spaceship out of it, too!
I wasn't under the impression that the government making things that help (in the case of the TSA, that last word is highly sarcastic) a private industry render that industry public. If that were the case, any industry that relied on the interstate highways (or even just public roads) would seem to apply. Or anything involving oceanic operations (Coast Guard, NOAA weather stations, survey charts, hell even GPS). In many parts of the country, municipal water is government-run; does that mean that the government "funds" restaurants by making sure that they don't need to perform their own water quality testing before they can serve it to their guests?
Mind you, I'm ignorant of (and therefore not considering) any legal history which may exist around this issue. So far as I know, the gov does not actually directly fund airlines in any way and instead just has agencies who are responsible for making sure that planes don't fall out of the sky, crash into each other, or get hijacked for use as missiles... at least, not very often. I'm not sure how this is different from the government agencies which make sure that road signs are accurate, bridges can support the weight of a truck driving over them, and people aren't allowed to tear through residential neighborhoods at whatever speed they feel like. Well, aside from the fact that many (though not all) of the relevant agencies are operated by lesser governments than the feds.
Anyhow, if there's actually something that makes the difference, then I'm curious but accept that my understanding was incorrect. To the best of my knowledge, an airline agent is a public servant in much the same way that a cruise ship agent is - that is, not at all. They have authority within the scope of their employer (including the authority to evict you from the plane, assuming that in doing so they are not putting anybody's life in undue danger) but then, so does any restaurant proprietor if they have reason to believe that you are harmful to their business. They have the authority to call the police, but so does any private citizen for any scenario in which they think a crime has been or is being (or imminently will be) committed. They do not, to my understanding, have the authority to force the police to arrest anybody or indeed to show up at all, although given the nature of their job I'm sure they can convince the police to show up any time they want them to (at risk of crying wolf too many times). Again, correct me if I'm wrong about any of this.
What first amendment rights were violated? I'm absolutely serious about this; please point to any violation of first amendment rights anywhere in here.
While you do so, remember that the first amendment restricts the actions of the *government* - that is, it prohibits the making of laws that do certain things - and has absolutely nothing to do with the private sector. Here, let me quote it for you (emphasis mine):
So, which law did SWAirlines cause Congress to pass that violated these people's first amendment rights? Go on, point it out please.
Or were you just mouthing off about stuff you don't understand, trying to get people riled up about an issue that doesn't even exist? Because that... well, let's just say it speaks volumes about your intelligence (and that of the person who modded you up). Volumes that I doubt you would ever read, since apparently you can't be bothered to read (or at least, understand) one of the most important *sentences* ever committed to text in the history of this nation...
No offense, but that's a kind of dumb assumption. They explicitly state that they make the games compatible with modern systems. With a large portion of their catalog being 16-bit, and 64-bit OSes not able to load 16-bit apps, they *need* to be wrapping the games in emulators or the like.
Yes, the original game files - or very close, minimally-patched versions - are in there. However, the vast majority of their customer base wouldn't be able to do anything with those game files. Even if they were, it wouldn't be the simple and user-friendly experience that it is today.
Now, as a Linux user trying to run Windows software, you're pretty much writing off "simple and user-friendly" from the get-go (I've been gaming in Wine since 2006; it's better than it was but it's got a long way to go and the goalposts keep moving). Given that, maybe it would have been nice for the small portion of users who care if they'd provided a "here's the files and instructions you need for setting this up in ScummVM on the platform of your choice" option... but that's not their target market, and frankly it might actually be harmful to their goals (never underestimate the cost of support calls from idiots who think they know what they're doing).
Hence, while many of their games have been *able* to run on Linux since GOG released them, the really core portion of the service - the dead-simple installers and updates - didn't. That is what they're now changing.
Yes, please! Hell, just dumping the lockdown (or rather, making it optional) should boost sales a good bit; there's a fair bit of recompiled code already available (jailbroken) RT. Something with RT's battery life and hardware support, but able to run "real" Windows software, is a desirable machine for many people... and as you say, there's also many who would like to put Linux on it, and get an ultra-portable Linux machine that can also run Windows stuff at need.
There's already a semi-functional x86 emulation (dynamic recompilation, more accurately) layer for RT. Considering it's the work of one hobbyist in his spare time over a few months, without access to MS source, I'm sure MS could do a lot better themselves if they wanted to. With that said, I can see the argument for not doing so after all. .NET binaries run as-is, anything MS owns can be ported, and perf impact of recompilation onto a less-powerful architecture, especially for something as complex as x86, is pretty heavy. (The current tool will happily run 2D games... from the late 90s.)
What the [redacted] do you mean "go back to" promoting .NET? Honestly curious. I mean, you obviously know [redacted]-all about it (among other things, while it compiles to bytecode in the typical use cases, it's executed as native code thanks to a JIT compiler that takes it the rest of the way for whatever platform it's on) but I'm not sure how you've missed the fact that it's the primary platform for Windows Phone apps (WP7 only supported Silverlight or XNA - both of which are .NET - for third-party apps; WP8 allows native code but most apps are still mostly or entirely .NET), Windows Store apps (JS and native are both available, but .NET is very heavily used), client apps (it's rarely used in big apps, but widely used for small utilities), server apps (hell, the Server Core SKU doesn't have a GUI, just PowerShell... which is a .NET-based command line interface), and games (all Xbox360 indie games - there are many thousands of them - are XNA which is .NET).
They added native code options for Phone and WinRT because people wanted them for performance-sensitive stuff, but the vast majority of the software for those platforms is architecture-independent. Windows RT will run the same .NET binaries that Windows 8 will.
Microsoft actually sold a highly-successful cross-platform Unix system for many years, back in the pre-NT days. You didn't think they ran the company on DOS, did you? They used Xenix machines extensively into the 90s, until NT was in a position to take over.
For that matter, back then NT had a POSIX subsystem and could run most Unix software with little more than a recompile. In case you're curious, by "back then" I mean "until Windows 8.1"; the POSIX subsystem is still available in Win7 and Win8. It's not a great Unix, but it's better integrated into Windows than a VM or CoLinux, or even Cygwin, and it does the job... or did. When MS discontinued it, they also cut support for the most-used software repo, and staying up to date currently means manually updating or moving to a different package manager.
Win8 (especially 8.1) already does this, to a small degree. Buttons and menu items are bigger on touchscreen systems, and I think the default state of boot-to-desktop-vs.-Start-screen is already input-hardware-determined. It certainly doesn't require any new APIs, much less new drivers!
With that said, yes, Win9/Threshold/whatever will be a more dramatic example. It's not new, though.
Nokia was struggling quite badly before Elop. I'm not dismissing your claim that Microsoft devoured it, or that Elop was a major part of that, but if you take off your rose-tinted glasses of Nokia past (which was excellent, undeniably) and look at the Nokia of just a few years ago, that company was in major trouble.
Now, they *could* have made a run at being the next Samsung, and gone with Android. Or they *could* have put real resources into Maemo/Meego/whatever-they-were-calling-it-then, brought out a really modern successor to the N900, and tried to compete solo. Or they *could* have canned everything else and pushed Symbian as far as it would go.
But they had to do something. They were hurting, badly, and showing no sign of an actual path out.
It's a $300 phone. That's "cheap" only by comparison to the high-end models; it's actually more accurately called mid-range. You can get vastly cheaper (less than half the price) smartphones that have better software/firmware. Their specs will be worse, but - and this is the whole point of the article - nobody will notice the shitty software and firmware before they buy, whereas a bad spec list makes a phone look bad (and cheap) even if the actual experience of using it is pretty good (most people don't come close to really using the full power of their phones).
No. The solution isn't that somebody needs to rate phones. It's that the rating needs to be obvious and visible. If I go into a store and look at a line of phones, they'll all tell me their screen size and their CPU speed and usually what OS version they have, plus usually one distinguishing feature, but that's about it.
Compare that with, say, buying a game or other piece of software. There will be review scores (and actual reviews, if I go looking, but the scores are prominently displayed), there will be awards given, there will be indications of the actual *quality* of the item. Not flawless ones, of course, but a hell of a lot better than getting nothing but a short list that tells me this is a RTS game, supports up to 8-way multi-player, runs on Windows XP or newer, requires 20GB of storage, and features a campaign with multiple endings depending on the decisions you make in game (or similar "cool but you have no idea how well that works" feature).
Of course, nobody *wants* to display a bad score on something they're trying to sell you... but they'd happily display a good one. The idea is to make such review scores sufficiently widespread and usable (which requires decent accuracy) that people will actually A) pay attention to them, and B) notice when they are missing.
I actually found it interesting, exactly *because* of the comparison to things like the Lumia 520 (the only really-low-end smartphone I have any experience with - I've done a lot of security review on them - in the last five years). The 520 is an unabashedly low-end phone. Rear camera only, no flash, 5MPx (for Nokia, this is low-end indeed). 480x800 used to be pretty good for a 3.5" screen, but these days it's pretty meh. 1GHz CPU, even though it's dual-core, is about as low as it's possible to find in a brand new smartphone, at least in the USA. No 4G, no NFC, etc... but the radios it does have had good firmware. The software runs well within the confines of that hardware, and doesn't have any bugs that I found which its higher-end brethren fixed.
My roommate still uses DDR (OK, technically Stepmania) as his workout routine. I tend to go with Dance Central on the Kinect instead, but... yeah, they're both amazing workouts.
MS brought in about 25,000 Nokians, so it's about half of that. 50% cuts is huge, but part of the problem Nokia was having before (Pre-Elop, even) was a massively overinflated headcount of redundant positions. Add to that the fact that Nokia really does have a lot of redundant people now (MS already has marketing folks, sales folks, legal folks, etc.) and I can believe that they're getting cut by a large measure without it being crippling to the phone division.
Whether or not it survives a few more years, though... can't say. The 8.1 update finally brought a ton of stuff that people have been asking for since basically day one (unified notification center, one-touch control of settings, ringer volume separate from the app volume, etc.) and while some would say it's too late, there are parts of the world where 8.1 is actually fairly common (over 10% market share). That's enough of a foothold to carry on if they don't wreck the things they have going for them.
ArchieBunker either has no fucking clue what he's talking about, or is just trolling. Not sure which. To set the record straight, though:
1) You can't move the pointer (one assumes that's what he meant by "CURSOR") with your finger. Anybody who has used Windows on a touchscreen knows this. You can move it with the stylus, and you can do gestures with fingers, but you can't move the pointer.
2) Moving the mouse to the upper right corner brings up the Charms bar, just like the little animation shows. You can disable that behavior if you want to, but it's enabled by default whether you have a touchscreen or not. It is a ridiculously blatant lie to claim otherwise.
3) Anything you can do with the mouse in Win7 or below, you can do with the mouse in Win8. Sometimes the exact form it takes is different - for example, right-clicking in Metro-style apps brings up a context-sensitive app bar instead of a context menu - but it's there. You can operate menus, launch/minimize/restore/maximize/snap/close apps, scroll documents, and so on.
Sadly, at least one moderator fell for it. Or maybe they have an agenda and don't mind spreading... is it even FUD when it is blatantly , easily provably false? Spreading lies, because spreading FUD wasn't quite good enough, I guess...
WRONG!
The Start button was always there. It was hidden, in the same sense as the "Hide Taskbar" feature that's been there since what, Windows 95 or maybe 98? Mouse to the corner of the screen, button appears. Left click it, get Start screen; right click it, get admin menu. In the meantime, you get a bit more space on the taskbar.
Mind you, it'd have been nice if they'd made that *optional* (the way that Hide Taskbar is optional), but considering the Windows setup process - either on a new machine or on a clean install - spends like 5 minutes explaining this to you with really repetitive animations, it's pretty sad that people were *that* up in arms over it.
What the hell's wrong with your system? That's exactly what it does, at least on 8.0 (haven't "upgraded" to 8.1 because they cut a feature that I regularly use). My mouse wheel is not capable of side-scroll, but I just tested with vertical scrolling and it works exactly like you describe.
Of course, the reason I had to test that is because it's not something a sane person should ever need to do. You have a keyboard, right? Type the first few letters of the program name (or type the file name), hit Enter, and behold the launching of your program. Just like you've been able to do for the last 7+ years, since fucking Vista (to say nothing of Win7).
The sad thing is, NT itself has (or rather, had) a POSIX API. Up through Win8 (but not 8.1) you can actually get a basic but functional *nix environment running on NT natively (or as natively as NT runs Win32 at least, which is to say it works pretty much seamlessly and nobody back a handful of hacker-types care about the underlying guts). Shells, libraries, utilities, GCC-based build toolchain... pretty nifty, and it integrates better with Windows than Cygwin ever has, while also being faster and supporting things that Cygwin doesn't (setuid, etc.)
However, Microsoft has seen fit to stop funding the maintainers of the package repo for it (there are third-party repos - NetBSD has one, last I checked - but SUACommunity/InteropSystems was where you went for most of this stuff) and to discontinue the POSIX subsystem entirely as of NT6.3 (Win8.1). Very irritating. They say to use Cygwin instead, which is technically a viable option for most of what I use SUA/Interix for, but it's not one I'm happy about needing to take (and move everything over to).
Better yet, "valid" ASCII-armored PGP blobs (or PGP attachments) that don't actually contain any decryptable data, but are otherwise indistinguishable from a real blob. Put a random key ID in there, cycle it every time, claim they are one-time use if anybody ever reaaaaally gets on your case about it.
I have well over 100 passwords for various accounts (I have no real idea how many I'm up to by now). I can probably remember about 50 of them off the top of my head, and can make educated guesses at many of the rest... but unless it's a password I use regularly, I'd need to check my password keeper (which I do not keep on my phone or in physical form anywhere) to be sure. Some of the more obscure ones I wouldn't have a chance at, and it would probably take me at least a few tries to remember which one was for something I hadn't used in over two years.
Sorry to self-reply, but I figured I should add some mitigations (for those who don't RTFA...)
First of all, as a user, one can of course disallow Flash by default (or remove it entirely). Mechanisms for doing this vary by browser, but all major browsers have at least one.
You can also update Flash. The latest version, released today (Tuesday the 8th), tightens up the validation of "compressed" applets in such a way that it should catch the output of this "Rosetta Flash" program.
For sitemasters / developers, there are a few options.
Hope that helps!
I don't know about English, but I can produce an explanation that is understandable by most people with at least some knowledge of how the web works, hopefully... It's not going to be short or simple, but I'll at least try for clear.
JSONP is a web service communication method. The idea is that a client (a web browser) sends a request to a given URL, and in that URL they include a "callback" parameter. The response from the server is a blob of JavaScript starting with the callback parameter (as a function name), and then containing additional data (as a JSON-defined object, usually). Examples: /jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint HTTP/1.1 ...
...
A target URL that looks like this:
https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint
Produces a request like this (no body, and some headers omitted for brevity):
GET
Host: vulnerablesite.com
Cookie: VulnerableSiteSessionCookie=JoeBlowIdentificationValue
That produces a response like this (again, header details omitted):
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Length: 41
jsonp.handle_some_endpoint({"foo":"bar"})
The browser would then interpret that response as JavaScript, calling the named function.
Now, this looks risky but normally it's safe enough, because while an attacker could embed a <script src="https://vulnerablesite.com/jsonp_service/some_endpoint?callback=jsonp.handle_some_endpoint" /> script source tag that specifies an arbitrary callback name (which then gets executed as JS), there's nothing really dangerous they can do with that because the server will disallow most sensitive characters in JS (things like ( ) = ' " < >) from the callback name, so you can't actually embed arbitrary javascript in the response. Usually the attacker doesn't control the content of the parameter (the JSON blob) either, or at least can't make it be anything except JSON (which is normally pretty harmless). For example, the attacker could pass "alert" as the callback, in which case the victim gets a message box saying "[object Object]" or similar. Whoop-de-do.
OK, so the attacker can't do much just by invoking a script with an arbitrary callback name. However, Flashplayer can execute applets in a number of formats, including formats that are theoretically compressed. I say "theoretically" because there's actually nothing requiring the data to be "compressed" in any even vaguely efficient manner (which tends to produce dense blobs of seemingly-random binary values). Instead, it's possible to create a "compressed" file that only contains alphanumeric characters (and is therefore valid as a callback name), but when it is "expanded" it produces an arbitrary binary blob (such as a compiled Flash applet).
So, here's what the attacker does. They create a malicious Flash applet. They run it through the special compiler this guy came up with, which converts it into a "compressed" applet format containing only characters that are valid for a callback name. They place an HTML object tag on their own, attacker-controlled website. The object specifies the jsonp service on the vulnerable site as its data source (the way one might specify youtube's flash applet as a data source), and specifies the callback name to be the alphanumeric-format applet. The attacker also specifies that the type of the data is application/x-shockwave-flash.
When a user visits the attacker's site, their browser sees the object tag and tries to retrieve the specified data. The response they get back is *actually* a JSONP script, but the first part of it - the callback function name - is *also* a valid Flash applet. Because the object tag specifies that the data type is Flash, the browser obligingly loads Flashplayer and runs the malicious applet (it ignores the ({"foo":"bar"}) blob at the end).
Now, here's the really mean pa