IMHO, SiliconDust was INSANE for not just asking Microsoft to sell them the sourcecode and IP rights to Windows Media Center in exchange for equity in SD and an agreement to license PlayReady from Microsoft going forward. Microsoft would have had nothing to lose, since they've basically abandoned WMC anyway, and it would have enabled SiliconDust to have a version working under Windows 10 (with full DRM support) in a matter of months. And it would be an epic win for Microsoft, because you'd still have to buy a copy of Windows to use it.
Alternatively... they should have written the core DVR first as a collection of scriptable commandline apps with full DRM support for COPY_ONCE-flagged channels. The idea isn't that end users would record and play shows via commandline, but rather that someone ELSE could then write a front end using Java (or C, or Python, or whatever) that launches SD's Recorder or Player app & opens a network socket to it to query for things like "current position" and send commands like "pause", "skip 30 seconds", "new position: 00:24:13", etc.
As it stands, SiliconDust has basically spent a year writing a mediocre DVR app that does nothing the free Linux DVR apps can't ALREADY do better. They just don't seem to get it... without DRM support and the ability to record & play COPY_ONCE channels, their DVR app is POINTLESS and has no reason to even exist.
I hope Samsung takes one HELL of a financial beating over this, because most of the cost will be well-deserved punishment for taking away removable batteries. Had the N7 allowed batteries to be swapped, they could have given anyone who agreed to surrender their defective battery two or three free replacements (total cost to Samsung: about $5-10 at eBay Chinese battery prices) and used customers as a vast, unpaid labor force to do the battery swaps. Instead, Samsung is going to have to eat the cost of a recall (including shipping) AND pay employees to swap the batteries & re-package the phones.
Apple is claiming they did it to make the phone waterproof. Apparently, they didn't bother to spend about 12 seconds with Google searching for "ip67 headphone jack", because if they DID, they'd have found countless IP67-rated headphone jacks like this one:
For those who don't know, the "7" in "IP67" means "waterproof to a depth of 1 meter for 30 minutes". I didn't have time to search further, but I'd be shocked if there wasn't at least one company that makes IP68 ("waterproof to a depth guaranteed by manufacturer, generally 1-3 meters, for some period of time also guaranteed by the manufacturer"). Note that IP ratings for things like headphone jacks don't guarantee that the jack itself won't end up with gunk in it if you drop it into mud, only that the jack ITSELF won't allow water to pass through to the interior of the phone case.
No, it's NOT "single-purpose". It might be MARKETED as "a headphone jack", but it's REALLY 3 raw GPIO lines plus a ground (or at least, two waveform outputs and one waveform input) constrained to specific sample rates).
Headphone jacks are a great way to hack up cheap circuits to do simple, analog(-ish) things, like sense the state of a switch or sample a resistive analog value (generate power from the mic port, then use the resistive sensor with a simple oscillation circuit to generate something you can analyze via FFT). Yeah, you can ultimately achieve most of this using the USB port (Android ADK, IOIO, etc)... but a bare headphone plug and a soldering iron is a hell of a lot cheaper AND smaller than the electronics you'd otherwise need to do even the most trivial i/o over USB. The ADK in particular is HUGE (quite possibly bigger than the phone itself), and even IOIO is the size of a USB flash drive.
Want to power something using the phone? Output a high-frequency sine wave at max volume. Feed it into a transformer, then regulate its output if necessary. Assuming you can't just drive it with a looping waveform of 0x7FFF at max volume to generate enough DC.
Want a serial port? OK... DB9 port, level-shifter IC, and a headphone plug. Some Samsung (and possibly HTC) Android phones actually shipped with kernel-level support for such hardware (I know the Galaxy S family did, and I'm pretty sure the Galaxy S2 family did, but I think Samsung quit building it into the stock kernel starting with the S3).
And let's not forget cool, useful things like thirdparty IR blasters and credit card readers that plug into the headphone jack.
An Android phone might begin its life as a phone and only get used as such for a year or two, but having useful i/o greatly increases the opportunities to repurpose old Android devices and give them a second life as security webcams, pet door monitors, touchscreen remote controls, etc. So yeah, the current villain might be Apple, but it's imperative that Android owners fight Apple's abandonment as hard as the iPhone community, and to come down HARD condemning any Android phone that does the same thing to keep other companies from blindly following Apple and eliminating headphone jacks on their top-shelf ANDROID devices, too.
You can definitely make a tiny sensor array with higher technical resolution than traditional ISO 400 print film grain... maybe even ISO 100. The catch is, you'll have to light up the scene to retina-searing brightness levels like a color movie set from the 1930s, because your effective f-stop will be insanely high and/or your dynamic range will be unacceptably low & have too much random noise.
Big lenses and/or large-format film/sensors allow you to capture more photons and take pictures with less light.
Except the fact that JavaScript absolutely SUCKS ASS on mobile platforms. Go ahead, just TRY going to walmart.com using Chrome under Android to see whether a store near you has something in stock. It'll choke, stall, and metaphorically flop around on the ground like a soon-to-be-deceased fish.
Anybody who makes a web site that's entirely generated via JavaScript and ajax & consists of pages with nothing besides a single placeholder html tag deserves to get beaten to a pulp.
At the VERY least, Google ought to commit to releasing unsupported "best-effort" automated builds of binary kernel modules for proprietary hardware for at least 5 years. It's something that would take only a tiny bit of effort (or arm twisting) by Google, and would go a LONG way towards neutralizing the misery caused by Linux's lack of a stable kernel ABI by doing the ONE THING for us that we genuinely can't do ourselves -- build proprietary drivers from source so they'll work with a new kernel.
Alternatively, Google should come up with a slightly better alternative to loadable kernel modules that enables some reasonable degree of compatibility between kernel builds. Or just fork Android's kernel outright, and commit to keeping the kernel ABI stable (absent some really, REALLY good, compelling, and urgent reason) from release to release.
The really fucked up thing is, ten years ago you could do a guerrilla upgrade of a Windows Mobile 5 phone to Windows Mobile 6 by doing little more than copying.exe and.dll files from a newer phone. Thanks to Linux's total lack of kernel ABI stability, we can't even do THAT anymore (at least, not unless the kernel from that newer phone can ALSO run verbatim on the older one)
IMHO, GPU development over the past 10 years has been pretty uninspiring, and has done little more than tread water to maintain the status quo as resolutions slowly lurched forwards. 480p60, then 720p60, then 1080p30, now 1080p60.
When NVidia or AMD adds hardware-accelerated raytracing and spline-rendering, I might start to be more impressed. Compared to 1995-2005, we really ARE in a mini dark age of computers, with phones being the sole exception. Even tablets rarely meet, let alone exceed, the specs of top-shelf phones from two generations ago. Every few months, I go out looking at new tablets, and end up going home frustrated & disgusted because nothing can even match the capabilities of my current phone (Nexus 6P), let alone stomp all over them and blow me away in awe. And computer hardware has barely advanced since 2010. Oh, yeah, we get longer battery life with smaller batteries. Wheee. Exciting. I can't even REMEMBER the last time I saw a new computer that decisively blew away and annihilated my current one.
Call me when Android & Apple phones or tablets become capable of rendering a pdf file from flash storage in realtime at 60 pages per second in 2560x1600 with subpixel rendering, and without glitches, tearing, or stalls (pdf-rendering might not be cool and sexy like 2160p60 3D, but it's a fundamental & basic task that current phones and tablets SUCK MISERABLY at doing.
Actually, no they won't. Unlike most consumer protection laws, Magnuson-Moss actually has teeth. You don't HAVE to sue them in court and prevail. All you have to do is file a claim with the Federal Trade Commission, and THEY'LL do the grunt work for you. After reviewing your claim, they'll forward it to the manufacturer, who has a limited amount of time to respond and either 1) agree to cover the repair, or 2) file a rebuttal that explains the legal basis for their refusal.
As a practical matter, manufacturers almost NEVER do anything besides meekly grunt an apology at the FTC & agree to cover the repair, because challenging the FTC and losing is WAY more expensive than grudgingly eating the cost of a warranty repair they would have otherwise refused.
With Magnuson-Moss, the deck is stacked VERY heavily against manufacturers in favor of consumers. It's probably one of the best consumer protection laws ever passed, because the members of Congress who wrote the law weren't just going through the motions to appease voters... they were as personally pissed off at the automakers as the general public was, and they wanted the automakers' blood to metaphorically flood the streets of Detroit.
Actually, no. The warranty in this specific case is the warranty on KNOX, not the warranty on the phone itself. In effect, Samsung is saying that if you root your phone, the bootloader notices, and the bootloader renders the phone permanently incapable of running Knox, you can't turn around and claim the phone is defective if you later need to use Knox after all.
That said... the "fuse" isn't actually a fuse. It's just software running in ARM TrustZone. Samsung itself is absolutely capable of restoring any phone back to its virgin state, Knox and all. They just refuse to do it as a matter of business policy, and don't like to admit that they do it all the time with phones that were returned for insurance repairs (like a broken screen) & sent to them for refurbishment.
It depends what you're connecting to. Their network is very heavily optimized to make http requests to popular American websites, plus services like Youtube, work well.
HOWEVER... their connectivity to arbitrary hosts in foreign countries isn't nearly as impressive.
Four years ago, I switched from Comcast (50mbps down) to U-verse (24mbps down, 3mbps up) and ran a bunch of connectivity benchmarks the day before I cancelled Comcast. I was in Miami, and the servers I connected to were in cities like Taipei, Darwin (Australia), Volograd, Caracas, London, Yellowknife (Canada), and Helsinki.
The long and short answer: Comcast was decisively faster to London and Caracas, and comparable for Helsinki... but U-verse was about FOUR TIMES faster to the other cities. From what I recall, the Yellowknife test actually timed out with Comcast (but worked fine, albeit a little slowly, with U-verse).
More importantly, U-verse seems to do a better job of SUSTAINING fast, long transfers. Comcast will show insane speeds for a few seconds, but the moment their network realizes you're downloading something HUGE, their traffic-shaping kicks in & starts to limit your transfer rate. U-verse just keeps going... and going... and going... and going. 24mbps now, 10 minutes from now, and an hour from now.
Strictly speaking, 320x200 and 320x256 weren't interlaced. They just refreshed half the scanlines twice as often, while totally ignoring the other half. In modern parlance, they were "200p60" and "256p50".
That's also why a lot of first-generation LCD TVs had problems displaying 320x200 or 320x256 from old computers and videogames. It was technically never an official video mode, and the fact that it worked was just a lucky side-effect of the way CRTs operated.
Nifty trivia: through clever CPU timing, someone semi-recently discovered that you can coax a c64, Vic-20, or 8-bit Atari into displaying interlaced graphics at double the vertical resolution by manually changing a register (and the video ram pointers) at the right moment to make the display THINK you're about to send it the even scanlines (instead of sending the odd lines again).
If you want to appeal to anyone besides ultra-elderly passengers whose adult children are treating the cruise like an ad-hoc assisted living facility to get rid of their parents for a few weeks, you have to get the travel time back down to 4 or 5 days, max... Long enough for customers to do a transatlantic cruise, spend a couple of days in Europe, then fly home in the span of a week.
Anything that demands more than 8 days is going to PROFOUNDLY limit the number of potential passengers, because most Americans just don't have enough days off per year to do it.
Typical transatlantic repositioning cruises with normal modem cruise ships are 10 days MINIMUM (New York to Southampton), and are more likely to be 14-20 days. And the internet access is pretty awful. The Caribbean is starting to get onboard broadband thanks to satellite spot beams and terrestrial Wimax/LTE (courtesy of nearby undersea fiber between Miami and South America, and few areas where there isn't at least a sandbar suitable for a radio tower), but the mid-Atlantic is another matter entirely. For most of a NY to Southampton cruise, you'd be lucky to get 128kbps shared by everyone on the ship... At about a dollar per minute of usage.
Wait... CAN you even REFUSE the anniversary update if you have non-Enterprise-licensed Windows?
I was under the impression that 10 Home & 10 Pro users could -- at best -- defer it for ever-decreasing amounts of time, until it eventually loses patience, installs it anyway, then informs you after the fact that a reboot has been scheduled for tomorrow whether you like it or not. Or the "install and reboot in 10 minutes" countdown appears while you're getting lunch, or you accidentally click the wrong square millimeter of the screen while distracted by something else, like whatever you're working on instead of satisfying Windows' demands.
Is there some hardware constraint that prevents Microsoft from enabling "4k UHD" on the original Xbox One at some framerate supported by its HDMI 1.4 port, or are they just using it as a selling point to try and get people who already own one to buy another one?
As far as I can tell, there's no reason why it would take anything besides a software update to enable 2160p30 on the existing Xbox One.
Then again, what I'd really LOVE to see is support for 720p100, 720p120, 1080p100, 1080p120. The difference between 60fps and 90-100fps is still pretty easy to spot, especially in a side-by-side comparison (above 100fps, you really need to hit 300-600fps for the difference to really stand out and be obvious... and even then, it's something you'd notice mainly with peripheral vision & only in high-contrast with fast motion).
That said, there's another mode nobody talks about that could EASILY be supported by even previous-generation hardware (360 & PS3) -- side-by-side 3D. Basically, some new 3D shutter-glass TVs can take a 1920x1080@60fps frame, split it into two 960x1080 frames, stretch them back to 1920x1080, and display them alternating between left and right at 120fps. Right now, just about the only people who use it are people who rip a Blu-Ray 3D disc, re-encode it as SBS, put the TV into SBS mode, and play it with a generic media player... but there's no reason why it couldn't be used for kick-ass games, too.
Microsoft has done plenty of things to deserve hate and wrath, but Xbox Live isn't one of them. Xbox Live is probably the least-restrictive commercial app market out there... probably less-restrictive than Sony, and several orders of MAGNITUDE less restrictive than Nintendo.
Remember, ARM is optimized for using low power in use cases where the user is running fairly undemanding software. In real-world terms, a 1.5GHz dualcore ARM9 is roughly equivalent to a 500-900MHz Pentium 3 from 15 years ago.
ARM was optimized to be low-power, simple, and economical. The i7 was designed to win every race at any cost through sheer brute force... and for the most part, it succeeds 100%.
Yes, it's totally possible to build an ARM9-based system that can beat the best i7-based system in every measurable way... except that by the time you got to that point, you'd need a 10U+ rack and a few hundred thousand dollars to pay for the hardware. You can certainly stick an ARM into a tablet, then stick the tablet into a keyboard with a USB port for a mouse, but you're NOT going to end up with the equivalent of a high-end i7 mobile workstation. Not even if it's an 8-core ARM9 running at 2.5GHz.
Wait... is this article saying that the trick for loading Microsoft-unsigned drivers under 64-bit Windows since Vista no longer works?
Microsoft's official documentation has definitely given the impression that drivers had to be signed by them in order for 64-bit Windows to allow their installation... but the REALITY (up until now, at least) has been that 64-bit versions of Windows would treat drivers that were signed by SOMEBODY... but not signed by MICROSOFT specifically... the same way 32-bit versions of Windows treated drivers that weren't signed at all -- a sternly-worded dialog warning against proceeding with the installation that could be swatted away and wouldn't bother you again.
2. drivers that were signed, but not by Microsoft: both 32-bit and 64-bit allowed after one-time warning.
3. drivers that were signed by Microsoft: both 32-bit and 64-bit installed without complaint.
Case "2" is the one of interest here. If Microsoft eliminated it with the new release of Windows 10, I'm going right back to Windows 7 if I find so much as a single driver that can't be coaxed into running. It would suck, because I've already spent the past 5 days tweaking Windows 10 to look kind of like Windows 7 (via ClassicShell and Glass8), but I'd definitely put the elimination of case 2 as grounds for abandoning it (and would probably be so disgusted, I'd make another stab at switching to Linux as my primary operating system).
I can't speak for the original Xbox, but the Xbox 360 has a pretty respectable library of indie third-party games that can be installed through Xbox Live. In fact, the third-party indie games on my 360 outnumber the retail-boxed games about 3 to 1.
Except Windows-running computers HAVE to be rebooted occasionally, or they'll get slower and slower. I think it's because Microsoft creates a VSS restore point prior to installing the disruptive update, then treats the system like a virtual hard drive mounted from that restore point until you finally reboot. It's been that way ever since Windows XP.
The last (and probably ONLY) version of Windows that you could truly get away with going for weeks without rebooting was Windows 2000 (prior to one of the later service packs... somewhere between SP3 and SP5, I think, which made Win2k require frequent reboots just like XP did). I still fondly remember installing Windows 2000, installing a bunch of other stuff, rebooting, then proceeding to go for almost a month without rebooting after installing Norton Antivirus and updating the AGP GART miniport drivers. Now, Windows wants you to reboot if you so much as raise your voice at it (though I think the never-ending reboots reached their worst point under Vista, before mellowing out slightly with Windows 7)
Linux WAS actually well on its way to becoming a meaningful alternative, until Ubuntu (who was responsible for most of that popularity) succumbed to Tablet Fever and, like Microsoft, proceeded to slaughter its golden egg-laying goose.
Remember 2008? Just slightly over 8 years ago? Back when "Ubuntu" had almost become SYNONYMOUS with "Linux" as far as books, magazines, and mainstream users were concerned? Now look at them... the only reason they're even still RELEVANT is because of all the popular distros that take Ubuntu's Unity trainwreck and undo most of the damage.
Classic Shell with Aero Glass Windows 7 theme is awesome, but be warned: getting glass8 (http://glass8.eu) to work is a BITCH. I got the translucent drag bars to work pretty easily, but window outlines are still just one pixel, and the translucency effect itself looks more like Metro's cheesy alpha-blending than Aero Glass' Gaussian-blurred splendor). And installing the debugging symbols it depends upon was a NIGHTMARE. Full props to its author for making it work at all, but Microsoft deserves endless hate for subjecting us to this kind of misery in the first place by taking away Aero Glass just so Windows wouldn't suck as badly on underpowered ARM hardware.
Slashdot Mirror
IMHO, SiliconDust was INSANE for not just asking Microsoft to sell them the sourcecode and IP rights to Windows Media Center in exchange for equity in SD and an agreement to license PlayReady from Microsoft going forward. Microsoft would have had nothing to lose, since they've basically abandoned WMC anyway, and it would have enabled SiliconDust to have a version working under Windows 10 (with full DRM support) in a matter of months. And it would be an epic win for Microsoft, because you'd still have to buy a copy of Windows to use it.
Alternatively... they should have written the core DVR first as a collection of scriptable commandline apps with full DRM support for COPY_ONCE-flagged channels. The idea isn't that end users would record and play shows via commandline, but rather that someone ELSE could then write a front end using Java (or C, or Python, or whatever) that launches SD's Recorder or Player app & opens a network socket to it to query for things like "current position" and send commands like "pause", "skip 30 seconds", "new position: 00:24:13", etc.
As it stands, SiliconDust has basically spent a year writing a mediocre DVR app that does nothing the free Linux DVR apps can't ALREADY do better. They just don't seem to get it... without DRM support and the ability to record & play COPY_ONCE channels, their DVR app is POINTLESS and has no reason to even exist.
I hope Samsung takes one HELL of a financial beating over this, because most of the cost will be well-deserved punishment for taking away removable batteries. Had the N7 allowed batteries to be swapped, they could have given anyone who agreed to surrender their defective battery two or three free replacements (total cost to Samsung: about $5-10 at eBay Chinese battery prices) and used customers as a vast, unpaid labor force to do the battery swaps. Instead, Samsung is going to have to eat the cost of a recall (including shipping) AND pay employees to swap the batteries & re-package the phones.
Apple is claiming they did it to make the phone waterproof. Apparently, they didn't bother to spend about 12 seconds with Google searching for "ip67 headphone jack", because if they DID, they'd have found countless IP67-rated headphone jacks like this one:
http://koumay.en.alibaba.com/p...
For those who don't know, the "7" in "IP67" means "waterproof to a depth of 1 meter for 30 minutes". I didn't have time to search further, but I'd be shocked if there wasn't at least one company that makes IP68 ("waterproof to a depth guaranteed by manufacturer, generally 1-3 meters, for some period of time also guaranteed by the manufacturer"). Note that IP ratings for things like headphone jacks don't guarantee that the jack itself won't end up with gunk in it if you drop it into mud, only that the jack ITSELF won't allow water to pass through to the interior of the phone case.
No, it's NOT "single-purpose". It might be MARKETED as "a headphone jack", but it's REALLY 3 raw GPIO lines plus a ground (or at least, two waveform outputs and one waveform input) constrained to specific sample rates).
Headphone jacks are a great way to hack up cheap circuits to do simple, analog(-ish) things, like sense the state of a switch or sample a resistive analog value (generate power from the mic port, then use the resistive sensor with a simple oscillation circuit to generate something you can analyze via FFT). Yeah, you can ultimately achieve most of this using the USB port (Android ADK, IOIO, etc)... but a bare headphone plug and a soldering iron is a hell of a lot cheaper AND smaller than the electronics you'd otherwise need to do even the most trivial i/o over USB. The ADK in particular is HUGE (quite possibly bigger than the phone itself), and even IOIO is the size of a USB flash drive.
Want to power something using the phone? Output a high-frequency sine wave at max volume. Feed it into a transformer, then regulate its output if necessary. Assuming you can't just drive it with a looping waveform of 0x7FFF at max volume to generate enough DC.
Want a serial port? OK... DB9 port, level-shifter IC, and a headphone plug. Some Samsung (and possibly HTC) Android phones actually shipped with kernel-level support for such hardware (I know the Galaxy S family did, and I'm pretty sure the Galaxy S2 family did, but I think Samsung quit building it into the stock kernel starting with the S3).
And let's not forget cool, useful things like thirdparty IR blasters and credit card readers that plug into the headphone jack.
An Android phone might begin its life as a phone and only get used as such for a year or two, but having useful i/o greatly increases the opportunities to repurpose old Android devices and give them a second life as security webcams, pet door monitors, touchscreen remote controls, etc. So yeah, the current villain might be Apple, but it's imperative that Android owners fight Apple's abandonment as hard as the iPhone community, and to come down HARD condemning any Android phone that does the same thing to keep other companies from blindly following Apple and eliminating headphone jacks on their top-shelf ANDROID devices, too.
You can definitely make a tiny sensor array with higher technical resolution than traditional ISO 400 print film grain... maybe even ISO 100. The catch is, you'll have to light up the scene to retina-searing brightness levels like a color movie set from the 1930s, because your effective f-stop will be insanely high and/or your dynamic range will be unacceptably low & have too much random noise.
Big lenses and/or large-format film/sensors allow you to capture more photons and take pictures with less light.
Except the fact that JavaScript absolutely SUCKS ASS on mobile platforms. Go ahead, just TRY going to walmart.com using Chrome under Android to see whether a store near you has something in stock. It'll choke, stall, and metaphorically flop around on the ground like a soon-to-be-deceased fish.
Anybody who makes a web site that's entirely generated via JavaScript and ajax & consists of pages with nothing besides a single placeholder html tag deserves to get beaten to a pulp.
At the VERY least, Google ought to commit to releasing unsupported "best-effort" automated builds of binary kernel modules for proprietary hardware for at least 5 years. It's something that would take only a tiny bit of effort (or arm twisting) by Google, and would go a LONG way towards neutralizing the misery caused by Linux's lack of a stable kernel ABI by doing the ONE THING for us that we genuinely can't do ourselves -- build proprietary drivers from source so they'll work with a new kernel.
Alternatively, Google should come up with a slightly better alternative to loadable kernel modules that enables some reasonable degree of compatibility between kernel builds. Or just fork Android's kernel outright, and commit to keeping the kernel ABI stable (absent some really, REALLY good, compelling, and urgent reason) from release to release.
The really fucked up thing is, ten years ago you could do a guerrilla upgrade of a Windows Mobile 5 phone to Windows Mobile 6 by doing little more than copying .exe and .dll files from a newer phone. Thanks to Linux's total lack of kernel ABI stability, we can't even do THAT anymore (at least, not unless the kernel from that newer phone can ALSO run verbatim on the older one)
IMHO, GPU development over the past 10 years has been pretty uninspiring, and has done little more than tread water to maintain the status quo as resolutions slowly lurched forwards. 480p60, then 720p60, then 1080p30, now 1080p60.
When NVidia or AMD adds hardware-accelerated raytracing and spline-rendering, I might start to be more impressed. Compared to 1995-2005, we really ARE in a mini dark age of computers, with phones being the sole exception. Even tablets rarely meet, let alone exceed, the specs of top-shelf phones from two generations ago. Every few months, I go out looking at new tablets, and end up going home frustrated & disgusted because nothing can even match the capabilities of my current phone (Nexus 6P), let alone stomp all over them and blow me away in awe. And computer hardware has barely advanced since 2010. Oh, yeah, we get longer battery life with smaller batteries. Wheee. Exciting. I can't even REMEMBER the last time I saw a new computer that decisively blew away and annihilated my current one.
Call me when Android & Apple phones or tablets become capable of rendering a pdf file from flash storage in realtime at 60 pages per second in 2560x1600 with subpixel rendering, and without glitches, tearing, or stalls (pdf-rendering might not be cool and sexy like 2160p60 3D, but it's a fundamental & basic task that current phones and tablets SUCK MISERABLY at doing.
Actually, no they won't. Unlike most consumer protection laws, Magnuson-Moss actually has teeth. You don't HAVE to sue them in court and prevail. All you have to do is file a claim with the Federal Trade Commission, and THEY'LL do the grunt work for you. After reviewing your claim, they'll forward it to the manufacturer, who has a limited amount of time to respond and either 1) agree to cover the repair, or 2) file a rebuttal that explains the legal basis for their refusal.
As a practical matter, manufacturers almost NEVER do anything besides meekly grunt an apology at the FTC & agree to cover the repair, because challenging the FTC and losing is WAY more expensive than grudgingly eating the cost of a warranty repair they would have otherwise refused.
With Magnuson-Moss, the deck is stacked VERY heavily against manufacturers in favor of consumers. It's probably one of the best consumer protection laws ever passed, because the members of Congress who wrote the law weren't just going through the motions to appease voters... they were as personally pissed off at the automakers as the general public was, and they wanted the automakers' blood to metaphorically flood the streets of Detroit.
> Blown fuse==out of warranty.
Actually, no. The warranty in this specific case is the warranty on KNOX, not the warranty on the phone itself. In effect, Samsung is saying that if you root your phone, the bootloader notices, and the bootloader renders the phone permanently incapable of running Knox, you can't turn around and claim the phone is defective if you later need to use Knox after all.
That said... the "fuse" isn't actually a fuse. It's just software running in ARM TrustZone. Samsung itself is absolutely capable of restoring any phone back to its virgin state, Knox and all. They just refuse to do it as a matter of business policy, and don't like to admit that they do it all the time with phones that were returned for insurance repairs (like a broken screen) & sent to them for refurbishment.
Everybody else is most certainly NOT limited to IPv4.
I have U-verse (45mbps down, 55/6 bonded profile), and have IPv6 with a /60 prefix.
I have Uverse, with 45mbps down on a 55/6 pair-bonded profile. According to Speedtest, I just got 50.74 down, and 5.47up.
As of my next bill, my data cap is 1TB/month. Right now, it's either 600gb or 750gb.
U-verse seems to be fairly lenient with both the max speed and usage byte-counting.
It depends what you're connecting to. Their network is very heavily optimized to make http requests to popular American websites, plus services like Youtube, work well.
HOWEVER... their connectivity to arbitrary hosts in foreign countries isn't nearly as impressive.
Four years ago, I switched from Comcast (50mbps down) to U-verse (24mbps down, 3mbps up) and ran a bunch of connectivity benchmarks the day before I cancelled Comcast. I was in Miami, and the servers I connected to were in cities like Taipei, Darwin (Australia), Volograd, Caracas, London, Yellowknife (Canada), and Helsinki.
The long and short answer: Comcast was decisively faster to London and Caracas, and comparable for Helsinki... but U-verse was about FOUR TIMES faster to the other cities. From what I recall, the Yellowknife test actually timed out with Comcast (but worked fine, albeit a little slowly, with U-verse).
More importantly, U-verse seems to do a better job of SUSTAINING fast, long transfers. Comcast will show insane speeds for a few seconds, but the moment their network realizes you're downloading something HUGE, their traffic-shaping kicks in & starts to limit your transfer rate. U-verse just keeps going... and going... and going... and going. 24mbps now, 10 minutes from now, and an hour from now.
Strictly speaking, 320x200 and 320x256 weren't interlaced. They just refreshed half the scanlines twice as often, while totally ignoring the other half. In modern parlance, they were "200p60" and "256p50".
That's also why a lot of first-generation LCD TVs had problems displaying 320x200 or 320x256 from old computers and videogames. It was technically never an official video mode, and the fact that it worked was just a lucky side-effect of the way CRTs operated.
Nifty trivia: through clever CPU timing, someone semi-recently discovered that you can coax a c64, Vic-20, or 8-bit Atari into displaying interlaced graphics at double the vertical resolution by manually changing a register (and the video ram pointers) at the right moment to make the display THINK you're about to send it the even scanlines (instead of sending the odd lines again).
If you want to appeal to anyone besides ultra-elderly passengers whose adult children are treating the cruise like an ad-hoc assisted living facility to get rid of their parents for a few weeks, you have to get the travel time back down to 4 or 5 days, max... Long enough for customers to do a transatlantic cruise, spend a couple of days in Europe, then fly home in the span of a week.
Anything that demands more than 8 days is going to PROFOUNDLY limit the number of potential passengers, because most Americans just don't have enough days off per year to do it.
Typical transatlantic repositioning cruises with normal modem cruise ships are 10 days MINIMUM (New York to Southampton), and are more likely to be 14-20 days. And the internet access is pretty awful. The Caribbean is starting to get onboard broadband thanks to satellite spot beams and terrestrial Wimax/LTE (courtesy of nearby undersea fiber between Miami and South America, and few areas where there isn't at least a sandbar suitable for a radio tower), but the mid-Atlantic is another matter entirely. For most of a NY to Southampton cruise, you'd be lucky to get 128kbps shared by everyone on the ship... At about a dollar per minute of usage.
Wait... CAN you even REFUSE the anniversary update if you have non-Enterprise-licensed Windows?
I was under the impression that 10 Home & 10 Pro users could -- at best -- defer it for ever-decreasing amounts of time, until it eventually loses patience, installs it anyway, then informs you after the fact that a reboot has been scheduled for tomorrow whether you like it or not. Or the "install and reboot in 10 minutes" countdown appears while you're getting lunch, or you accidentally click the wrong square millimeter of the screen while distracted by something else, like whatever you're working on instead of satisfying Windows' demands.
Is there some hardware constraint that prevents Microsoft from enabling "4k UHD" on the original Xbox One at some framerate supported by its HDMI 1.4 port, or are they just using it as a selling point to try and get people who already own one to buy another one?
As far as I can tell, there's no reason why it would take anything besides a software update to enable 2160p30 on the existing Xbox One.
Then again, what I'd really LOVE to see is support for 720p100, 720p120, 1080p100, 1080p120. The difference between 60fps and 90-100fps is still pretty easy to spot, especially in a side-by-side comparison (above 100fps, you really need to hit 300-600fps for the difference to really stand out and be obvious... and even then, it's something you'd notice mainly with peripheral vision & only in high-contrast with fast motion).
That said, there's another mode nobody talks about that could EASILY be supported by even previous-generation hardware (360 & PS3) -- side-by-side 3D. Basically, some new 3D shutter-glass TVs can take a 1920x1080@60fps frame, split it into two 960x1080 frames, stretch them back to 1920x1080, and display them alternating between left and right at 120fps. Right now, just about the only people who use it are people who rip a Blu-Ray 3D disc, re-encode it as SBS, put the TV into SBS mode, and play it with a generic media player... but there's no reason why it couldn't be used for kick-ass games, too.
Microsoft has done plenty of things to deserve hate and wrath, but Xbox Live isn't one of them. Xbox Live is probably the least-restrictive commercial app market out there... probably less-restrictive than Sony, and several orders of MAGNITUDE less restrictive than Nintendo.
Remember, ARM is optimized for using low power in use cases where the user is running fairly undemanding software. In real-world terms, a 1.5GHz dualcore ARM9 is roughly equivalent to a 500-900MHz Pentium 3 from 15 years ago.
ARM was optimized to be low-power, simple, and economical. The i7 was designed to win every race at any cost through sheer brute force... and for the most part, it succeeds 100%.
Yes, it's totally possible to build an ARM9-based system that can beat the best i7-based system in every measurable way... except that by the time you got to that point, you'd need a 10U+ rack and a few hundred thousand dollars to pay for the hardware. You can certainly stick an ARM into a tablet, then stick the tablet into a keyboard with a USB port for a mouse, but you're NOT going to end up with the equivalent of a high-end i7 mobile workstation. Not even if it's an 8-core ARM9 running at 2.5GHz.
Wait... is this article saying that the trick for loading Microsoft-unsigned drivers under 64-bit Windows since Vista no longer works?
Microsoft's official documentation has definitely given the impression that drivers had to be signed by them in order for 64-bit Windows to allow their installation... but the REALITY (up until now, at least) has been that 64-bit versions of Windows would treat drivers that were signed by SOMEBODY... but not signed by MICROSOFT specifically... the same way 32-bit versions of Windows treated drivers that weren't signed at all -- a sternly-worded dialog warning against proceeding with the installation that could be swatted away and wouldn't bother you again.
In summary form:
1. unsigned drivers: 32-bit allowed after one-time warning, 64-bit refused outright.
2. drivers that were signed, but not by Microsoft: both 32-bit and 64-bit allowed after one-time warning.
3. drivers that were signed by Microsoft: both 32-bit and 64-bit installed without complaint.
Case "2" is the one of interest here. If Microsoft eliminated it with the new release of Windows 10, I'm going right back to Windows 7 if I find so much as a single driver that can't be coaxed into running. It would suck, because I've already spent the past 5 days tweaking Windows 10 to look kind of like Windows 7 (via ClassicShell and Glass8), but I'd definitely put the elimination of case 2 as grounds for abandoning it (and would probably be so disgusted, I'd make another stab at switching to Linux as my primary operating system).
I can't speak for the original Xbox, but the Xbox 360 has a pretty respectable library of indie third-party games that can be installed through Xbox Live. In fact, the third-party indie games on my 360 outnumber the retail-boxed games about 3 to 1.
Unholy Heights is a riot.
http://xbox.com/indiegames
No, it would mean that nobody who owns a top of the line i7 computer would voluntarily use Windows on a wimpy ARM device.
i7winUsers / i7winUsersWithARM ==> DIVISION BY ZERO
Except Windows-running computers HAVE to be rebooted occasionally, or they'll get slower and slower. I think it's because Microsoft creates a VSS restore point prior to installing the disruptive update, then treats the system like a virtual hard drive mounted from that restore point until you finally reboot. It's been that way ever since Windows XP.
The last (and probably ONLY) version of Windows that you could truly get away with going for weeks without rebooting was Windows 2000 (prior to one of the later service packs... somewhere between SP3 and SP5, I think, which made Win2k require frequent reboots just like XP did). I still fondly remember installing Windows 2000, installing a bunch of other stuff, rebooting, then proceeding to go for almost a month without rebooting after installing Norton Antivirus and updating the AGP GART miniport drivers. Now, Windows wants you to reboot if you so much as raise your voice at it (though I think the never-ending reboots reached their worst point under Vista, before mellowing out slightly with Windows 7)
Linux WAS actually well on its way to becoming a meaningful alternative, until Ubuntu (who was responsible for most of that popularity) succumbed to Tablet Fever and, like Microsoft, proceeded to slaughter its golden egg-laying goose.
Remember 2008? Just slightly over 8 years ago? Back when "Ubuntu" had almost become SYNONYMOUS with "Linux" as far as books, magazines, and mainstream users were concerned? Now look at them... the only reason they're even still RELEVANT is because of all the popular distros that take Ubuntu's Unity trainwreck and undo most of the damage.
The UI, hands down.
Classic Shell with Aero Glass Windows 7 theme is awesome, but be warned: getting glass8 (http://glass8.eu) to work is a BITCH. I got the translucent drag bars to work pretty easily, but window outlines are still just one pixel, and the translucency effect itself looks more like Metro's cheesy alpha-blending than Aero Glass' Gaussian-blurred splendor). And installing the debugging symbols it depends upon was a NIGHTMARE. Full props to its author for making it work at all, but Microsoft deserves endless hate for subjecting us to this kind of misery in the first place by taking away Aero Glass just so Windows wouldn't suck as badly on underpowered ARM hardware.