Thailand is actually a lovely country to visit - great beaches and diving, friendly people (just don't try to hire them to do work for you unless you understand their work ethic and speak their language), incredible culture, and some awesome things to see and do (visit the "tiger temple" where abandoned or orphaned tiger cubs are raised by humans; it's an incredible experience to go up and pet live tigers). There are also some... other... reasons to visit, ranging from "medical tourism" (dental, in particular, is high quality but orders of magnitude cheaper than in the US) to "sex tourism" (exactly what you think it is).
Their politics, on the other hand, are a complete flaming mess. Stay away from them (fortunately, this is easy; I was there for about five weeks and spent almost all of it out of the cities).
Good thing neither of the languages being discussed is in any way interpreted, or has been for a decade or so (actually, never in the official C#/.NET distribution).
But it's OK, I'm sure that somewhere under that mouth froth you actually know what you're talking about on some subject or other. Just keep searching, you'll find it eventually.
If you think Reflection usage is bad in ASP.NET MVC, you've obviously never seen Spring...
Also, the "whatever Java has" above is "nothing" because the idiot tested a bare JSP running on Tomcat vs. a ASPX running on top of the entire MVC framework on top of IIS. Yeah, no wonder the perf is going to suck; that's a huge amount of completely wasted overhead. IIS can serve a dynamic ASPX page without any of that MVC garbage just fine, thank you... and with that, get rid of all the Reflection and so forth that, while actually useful in seriously enterprise-y organizations where you want to be able to do things like drop-in replacements of one class for another by changing a single line in a configuration file, are utterly wasted on a trivial benchmark like this.
For simple ASP.NET, you can do fine on Mono (runs on Linux, *BSD, OS X, etc.) and there's an Apache module to use it. For pure C#, as long as you don't use the really fancy new features that haven't been implemented yet, the same is true. For Silverlight (which can be written using C# and other Common Language Runtime languages, and uses libraries from the.NET framework), there's an official OS X plugin, or a very incomplete and outdated Mono-based one (Moonlight). For the new and fancy stuff in.NET, yeah, you're limited to Windows (including, albeit with some restrictions, various flavors such as Windows Compact Embedded, Windows RT, and Windows Phone).
Oh, it's even better... Test 2: A function to generate a "full web site", (actually a simple web page with all the elements and trivial content). Java using a single JSP on bare Tomcat beats C# using the full MVC4 framework over IIS just to display an ASPX file hands down. Emphasis added, obviously. The guy had no idea what he was doing.
Frankly, the obvious problem (from somebody who has done a bit of both JSP and ASP.NET development) is the use of the MVC framework on IIS, and nothing even remotely equivalent on Java. If this were going to be as close to an apples-to-apples test as possible, you'd use bare ASP.NET (a single.ASPX page, possibly with a code-behind.cs file) and a single.JSP page.
I don't even think it's a matter of the author of the article having any agenda or something... I think he just honestly doesn't understand how to use the frameworks. For a very roughly analogous example from another programming domain, if I want to display a line of text on the terminal, I print a line of text. I don't go pull up the ncurses library and use it to create a one-line-tall TUI into which I create a label containing my text and then immediately exit. That would be... well, about as smart as using a heavyweight MVC framework to produce a web page containing the current time.
Unfortunately, electric car batteries are a lot bigger than most people realize. The Tesla Model S? It's the entire bottom ~4 inches of the car's body. Aside from a little but of room to account for very minor collisions and such, the battery bank is literally the size of the horizontal cross-section of a sedan. It also weighs well over a ton (the Model S is shockingly heavy, and over half of it is the battery bank).
Now, could you build a "battery station" designed to remove and replace such batteries, in a reasonably automated fashion, in a few minutes? Yeah, maybe, if the car were engineered for that... and the by "the car" I mean *all* cars you wanted to service at such a station. It would take a fairly large facility and a lot of engineering. You'd have to be able to store and simultaneously charge a substantial number of such batteries (admittedly, the space devoted to tankage in a convention fuel station would probably suffice).
So, the engineering would be hard, but it's probably possible. However, and perhaps most problematically, it would require standardizing on a specific battery. Dimensions, voltage, weight, and probably capacity. Want to build a smaller car? Oops, sorry, the battery won't fit. Want to offer different ranges of car (as the Model S itself has)? Sorry, all batteries are the same (you could argue "OK, just sell the car without the battery then, and pay at the 'pump'" except that the battery is major portion of the cost). Want to use a new battery chemistry that offers higher energy density but 15% lower voltage? Aside from the issues of introducing that into the supply chain (do people pay more to lease the new battery at each station? Do they get some of that back when they drop it off at a station that only has the old style?), those new batteries aren't going to be usable without inefficient voltage conversion, adding components and reducing the advantage of the new chemistry.
Don't get me wrong, I love the idea, and in time it's probably the way we'll go. But at this point, electric cars are too immature as a technology. We can't afford the weight and capacity penalties of using smaller, more modular batteries, and we can't offer the homogeneity needed to use one standard, massive battery, and we can't offer the future-proofing needed to make the battery exchange stations practical for the coming decade or so... look at what electric cars were just five years ago, compared to today!
C# is much more than a clone of Java (the list of things.NET code, including C#, can do but Java can't is very long), but more to the point:
C# was invented by MS, who had, by that time, many years of battling security issues and had apparently learned a few things along the way. The closest thing.NET has to Java applets is the Silverlight browser plugin, which, like Java applets, runs in a sandbox that restricts the operations possible by the applet code. However, there are two major differences: 1) In Java, a number of potentially very dangerous operations are permitted if the applet is "trusted", which mostly comes down to it being digitally signed. In Silverlight, those operations aren't permitted at all. 2) Both Java and.NET have "reflection" APIs which allow the code to examine and modify itself. However, while Java applets mostly just try to block specific dangerous operations from happening in reflection (it's a near-impossible task to get them all), Silverlight has made Reflection essentially read-only, allowing examination of the loaded classes and assemblies, but not allowing adding or modifying any code (which is how Java applets keep getting broken; the security manager is in Java itself, and gets overwritten or bypassed using reflection).
Well, as an example, this site you're reading wouldn't exist. The browser you're reading it in probably wouldn't either. If you're like a substantial portion of the readership of this site, the OS you're running that browser on most likely wouldn't exist either.
Free software (in either the gratis or libre sense) would be nigh-impossible without the "as-is" clause you so deride. At the very least, nobody would publicly publish it. In the "cathedral and the bazaar" sense, the bazaar becomes impossible (every single code submission becomes a new source of liability) and the cathedral approach becomes far too expensive to use for anything short of critical applications (actually critical, like medical and telecom systems, not such silly little things as web browsers). So, IBM would still exist, but they'd be serving a very niche environment. Microsoft would probably exist, but they'd either be writing software for those really expensive systems (and selling it for thousands of dollars, minimum) or they'd still only have one or two products: development tools that could be used by very wealthy hobbyists who had managed to acquire computers. Hardware would be vastly more expensive, as the demand would be much lower and thus there would never have been the money to fund massive R&D.
As-is solutions work pretty well. Did you know that in most of the world, you can't sue a doctor for malpractice? Liability insurance is one of the major reasons why medicine is so vastly more expensive in the US than almost anywhere else. Yes, it's also "safer"... assuming you can afford it at all.
IE10 is available for Win7. It's technically a "preview" release, but I use both Win7 and Win8, and IE10 behaves the same on both. It's the most release-candidate-level software I've ever seen go for more than a week without actually being released (it became available over a month ago).
Yeah. For the record, I'm aware that I can get all of these features, and then some, using enough Firefox extensions (although the implementation isn't always as polished). However, I appreciate the fact that they're built in, and that I don't have to worry if they're going to conflict, or leak RAM, or be broken by some update (less of an issue now). Still, I definitely keep Firefox installed. In fact, I keep all of the major browsers except Safari installed (I view Safari as offering basically nothing in exchange for its crap UI and since I don't have a Mac, I can't get the latest version anyhow). Chrome is "Safari (or more specifically, WebKit), but with a few more features and a slightly less-awful interface." Firefox is "Firebug and Gecko and don't open too many tabs or you'll have to restart it." Opera is "ALL THE FEATURES and Yet Another Rendering Engine but WHY are the keyboard shortcuts different from every other browser?"
Obviously, the above is over-simplified... Firefox loses points (and value) by being single-process, but despite being multi-process IE also starts to struggle if you open too many tabs at once (and it's not system resources, it's just the browser acting up). I actually use Opera as my secondary browser - I really do like the less-minimal interface; I think the thing that honestly pisses me off most about IE is the removal of the title bar - but no matter how often or how much I use it, its commands always feel just a little alien to me (I may use the keyboard more than most people do when browsing).
Personally, I actually find IE's interface one of the better ones. I don't like the approach that most browsers have been taking recently of minimalizing the browser UI; IE is no better off there than Firefox or Chrome (though its badness is slightly different) but things like the colored and automatically-combined tab groups, the ability to cycle through tabs in last-used order, the Favorites sidebar and feed reader, and the "Accelerators" feature for things like translating a text snippet instantly are all features which I appreciate, and feel are implemented pretty well.
Now, if it would just handle massive numbers of tabs more gracefully... there's a reason I use the "Ctrl+Tab cycles in last-used order" feature so much!
Similarly, jailbreaking RT can be argued to give it a new reason *for* existing. Before, it was a partially crippled device which had excellent battery life and portability, but you were so restricted in what you could do with it, no matter where you were or how long the battery lasted, that it wasn't as compelling a purchase. The Windows Store is ramping up quickly, but there will always be some classes of apps that just can't run in it, or at least not practically, and there will be more people who choose not to go through the effort of re-writing their UI for the new interface. It's a lot easier to take an existing Windows app's source code in VS 2012, open the Configuration Manager, select "ARM", and hit build again...
Not only do the tools exist for developing desktop apps for RT, they're actually the same (free, for the Express versions) Visual Studio tools used for developing Metro apps. You have to change one configuration file to stop it from bitching at you about not being able to create ARM desktop apps, and you'll find the list of.LIBs is sorely lacking, but the fix for the first was posted on StackOverflow weeks (months?) ago, and the second is easily fixed by "cutting" LIBs out of DLLs using scriptable programs which come with the build tools.
In fact, this hack would be mostly pointless if such tools didn't exist. Just because RT can now run desktop apps doesn't mean that it can run legacy (x86) software... at least without an emulator, which was one of the first things ported. Most programs recompile pretty smoothly, once you've gotten the tools set up. Just load the.SLN file in VS, select ARM as the target, and hit Build.
I've seen it before. Excluding the 10% or so that aren't on any smartphone (browser Silverlight plugin? Ha!), the 15% or so that were there when the list was first made and the people who made it were just being idiots, the 30%-ish that have been fixed in Mango or later versions of WP7 (seriously, that list is old; Mango came out a year and half ago, and I'm not counting WP8 changes in that 30% list), the additional 10% or so that were fixed by third-party apps, and the 25% or so that are fixed by homebrew apps, and you have the remaining 10 or so of features that some subset of the population wants but WP7 can't provide. Big whoop-de-doo, no smartphone OS is a strict superset of the others.
Downloaded non-game Marketplace apps that I use at least semi-regularly, from the top: Adobe Reader (sadly, the best PDF solution for WP7 right now). Amazon Kindle (constantly). Amazon Mobile (somewhat infrequently, but it has the cool features like barcode scanning to look up pricing). AuthenticatorG (Google Authenticator implementation). EveMon7 (EVE Online character tracking tool). Flashlight (uses the extremely bright camera flash LEDs). Forward Contact (not built in, sadly). GeekByte (feed reader for various tech sites, including/.). Headshot (cool app that uses facial recognition and spoken instructions to help you take self-portraits using the back camera). HTC YouTube (better than the default one, though these days I mostly use HTML5 in the browser). ICanHasCheezburger (my daily dose of silly cat pictures). IM+ (multi-network IM client). LinkedIn (the phone has some integration, but the app is much more complete). Look n Type (text messaging app that uses the camera to show what you're about to run into). Mango Transit (get bus routing, sadly the built-in maps app only supports car and foot navigation). MTG : Helper (Magic: The Gathering life tracker / card lookup / etc.). OneBusAway (shows real-time ETAs of buses). oPenGP (OpenPGP implementation, since we use encrypted mail at work). RemoteDesktop (Windows terminal services client, not built-in but the this third-party implementation is excellent). Shazam (music recognizer, works slightly better than the built-in feature). SkyDrive (the built-in one only supports document formats). Skype (sadly not integrated in WP7, unlike WP8). SnowMinder (ski conditions, snow day tracker, etc.). Speed Tester (Internet speed test). The SSH Client (exactly what is says on the tin, and works well). TouchDevelop (scripting IDE and runtime for the phone). Trailhead (hiking trail info, maps, etc.). User Agent Switcher (for sites that don't like the IE user agent). Vimeo (Internet video site, if you were somehow unaware of it). WarDice (polyhedral dice rolling app). Weather (The Weather Channel app). Xbox SmartGlass (access and control an Xbox 360 from the phone). XDA-Developers (read and respond to PMs and forum posts). Yelp. Ztitch (build panoramic photos).
Games: 7cave (good old fly-through-a-cave game). Chromatic Pro (bullet-storm game, shoot falling enemies with various weapons before they reach the bottom). Civilization Revolution (soooo much civ...). Fruit Ninja. geoDefense (great tower defense game) Hearts. Mars Runner (obstacle course racing, basically). Minehacker (free Minesweeper clone). Picross 7 (WP7 picross game). Plants vs. Zombies. Puzzle Quest 2. Rise of Glory (biplane combat flight sim). Sudoku. Wizard's Choice (fantasty-themed choose-your-own-adventure style of game). Wordament (incredibly addicting free word search game where everybody around the world plays on the same board at once). ZOMBIES (on the ph0ne) (twin-stick top-down shooter with fun flavor).
Note that I'm excluding a lot of apps that other people probably have, like Angry Birds, Facebook, Netflix, and such, as well as excluding apps that I don't use much (OpenTable, iHeartRadio since the phone has built-in radio and music streaming, etc.) but have installed anyhow. Most significantly for my phone in particular, I'm also not including sideloaded homebrew apps, like Advanced Config (customize all the device sounds, etc.), Bazaar (think Cydia), BlueManager (full Bluetooth file transfer), lockWidgets (dynamic lockscreen info), Marketplace Config (bypass marketplace regional or device restrictions), Metro Theme (advanced custom theming), Orientation Lock (not built in, sadly), phonemander (Midnight Commander-like file browser), SMSBackup (also not built in...), TouchXperience (alternate shell + connection to a PC app for remote administration), USBModeSwitch (wired tethering; wifi is bui
You came *so close* to understanding, and then you lost it.
This hack involves the following steps: 1. Probe the address of a kernel flag. 2. Attach a debugger to the user-mode CSRSS.exe and modify a function call it makes into the kernel using info from step 1. 3. Execute the function call to change kernel-mode memory.
Step 1 is fairly legit, even though it's not really supposed to be possible from a WinRT app. Step 2 is completely legit, assuming step 1 succeeds. Step 3 is the tricky one. This is not a kernel debugger, those are *NOT* allowed on Windows RT devices. But, it's changing *kernel* memory (because that's where the relevant flag resides). HOW'D THEY DO THAT?!?
Turns out that the kernel trusts CSRSS a lot, and doesn't validate the parameters of some calls it makes. Some of those parameters can be used to modify kernel memory. It's a write-only process, but we know the target address (from step 1) and we know (approximately) what the desired value is - more accurately, we know the difference between the initial value and the desired value, which is good because the exploit works by decrementing the value - so that's usually not a problem.
Anyhow, this fully meets your definition of a jailbreak. "some sort of privilege escalation": Yes, from Admin (required to attach the debugger) to kernel. Not normally a boundary that matters, which is why a multi-year-old exploit was left unpatched and we were able to use it, but on Windows RT there is in fact a boundary between Admin and kernel. "from inside a locked-down system": Pretty much obvious, although it's worth noting that this hack requires already being able to sideload a sandboxed app and attach a debugger to a user-mode system process, which is a lot less locked down than some other systems. "using bugs in the system": Yep. The kernel could, and arguably should, prevent CSRSS from sending it invalid parameters like that; the API in question isn't actually supposed to allow decrementing an *arbitrary* memory address.
That said, it's earned MS a lot of press coverage in the tech community, and there's been a lot of excitement over the hack amongst RT users, so hopefully they don't patch this out without providing an alternative method (or until we find one ourselves...)
Note that this hack does actually make use of a genuine security vulnerability. Specifically, the user-mode system process CSRSS.EXE (Client/Server Runtime SubSystem) makes a bunch of calls into the kernel. The kernel checks that CSRSS is the process making these calls, but beyond that, it doesn't bother validating the parameters much, if at all. Some of the calls have parameters that, if deliberately modified, can be used for write-only access to kernel memory. That's what this hack is doing: changing a kernel-mode flag that controls what signature level is required on EXEs (RT defaults to "Microsoft", or 0x80000 x86 Windows defaults to "None" or 0x00000; this hack simply decrements that memory address by approximately 0x80000 depending on the state of the other flags).
This vulnerability has existed for years, and previously has not been worth patching. In order to exploit it, you need to attach a debugger to csrss. In order to attach a debugger to a system process, you must be Admin. If you're Admin, you *used* to be able to just attach a debugger to the kernel directly. However, doing so requires a bootloader option change, and Secure Boot on Windows RT device prohibits adding the debug flag to the bootloader configuration. Therefore, while this bug was never before a priority for MS to patch (why bother, when they can squeeze a bit of performance out of skipping the parameter checks and the security is functionally identical?), the fact that Admin on RT does *not* automatically also imply kernel access means they may re-evaluate the priority of the bug.
The "why" is twofold. First of all, it's there, and we could. People have been working on this since literally launch day. Hackers gonna hack. Second, the Surface RT (and presumably other Windows RT devices) actually make very nice highly portable computers. With the familiar Windows interface and standard system tools, plus the keyboard and mouse provided by the cover, and excellent battery life... the only thing they are missing is software. The restrictions on third party apps (the AppContainer sandbox) makes it difficult to do things like create a decent IM client that is permanently connected without any lag, or an x86 PC emulator. Furthermore, all of the UI and much of the program code will need to be re-written (in most cases, at least) even if you want to target a Windows Store app.
This jailbreak largely solves the second problem. While closed-source software is still not going to be available, it turns out to be very easy to persuade Visual Studio to build desktop apps for Windows RT (something it's not *supposed* to do, but is fully capable of) and people have been working on re-building open-source software pretty much all day. The list is growing slowly at the moment, but it is growing.
As for complicated... not really. The most complex part is installing the sideloaded Metro application, and there's a script that almost completely automates that part. The rest is easy; run the tool, press Volume Down when instructed to do so, hit Enter and you're done.
Gwala is correct, and the purpose of this hack is to remove that restriction. There are a handful of apps which have already been ported. PuTTY, TightVNC, Bochs, and 7-Zip were the first. There are ongoing efforts to port more (including some mildly ambitious projects, like Firefox, Chromium, Thunderbird, Java, and Python).
Additionally, any pure.NET 4.5 app will run, unmodified, on the Surface RT after "jailbreaking". It has to be entirely 4.5 though; Windows RT doesn't include the legacy versions.
You could always deliver sideloadable APPX packages. They would require your users to install a developer license (free, supported, less complicated than this jailbreak tool, and doesn't rely on a patchable OS security hole) but it works fine. In fact, this tool requires sideloading such a package already.
The difference is that APPX packages (bundled "Metro" apps) only work for apps that run within an "AppContainer" sandbox. That means very restricted access to the whole system, no ability to run as Admin, no ability to run as a service, and almost no ability to run on the desktop (the final item is, unofficially, partially possible but it's a total hack). This "jailbreak" (I don't care for the term but can't come up with a better one) allows you to simply compile normal Windows binaries for ARM and run them like any other.EXE.
Exploit kits are not illegal. They have legit uses for testing your own security. For example, see Metasploit, which includes a large suite of exploits.
For fun? Minecraft. For work? Burp suite (there are other HTTP proxies, but none that do as well what I need them to do). There's also things like Eclipse and NetBeans (developers are people too... even if they are Java developers), of course... Java begets Java, to a certain degree, and there's already so much Java out there that it's pretty much impossible to stop creating more of it anytime in the reasonable future.
Charles Dickens is out of copyright. Still making money out of it.
Citation and/or clarification needed. Sure, *somebody* is making money... but unless it's Dickens' estate, then it doesn't benefit the creator of the work (at least, not monetarily) and therefore "no possible way to make money" is, hyperbole aside, correct. I suspect you'll find that the only people making money are those who take the works of long-dead authors and re-publish them, pricing the result below new publications because they don't have to pay royalties to anybody or secure the rights, they only need to avoid making the books so expensive that another publisher doesn't undercut them.
Now, that doesn't mean that it isn't, in fact, perfectly reasonable for there to be companies doing this (re-publishing public domain works and profiting off of them). However, the central tenet of your argument is "authors still make money without copyright" and yet you've presented absolutely no evidence in support of this. If copyright expired quickly, slightly-older works would be substantially less expensive, and the bulk of the money being made would go to the publishers (or public domain content) rather than the authors (who only receive payment when they sell something that's more expensive than the older stuff).
There's probably a reasonable middle ground - could be anything from a hard limit (anywhere from the US's original 14 years to something like a century is justifiable to one degree or another) to a wildly sliding scale based on something like the number of copies being published annually by the creator (note: not by re-sellers), or the value of those sold copies (but that gets tricky with open source... which, you should note, is usually not successfully sold for money because it's just so easy to undercut the price).
Eh? Not at all. Negative votes impact a candidate's total, and the candidate with the highest total still wins. Of course, that could be the only candidate left positive, or even the candidate who is least negative... but it's all still a valid approach.
Slashdot Mirror
Thailand is actually a lovely country to visit - great beaches and diving, friendly people (just don't try to hire them to do work for you unless you understand their work ethic and speak their language), incredible culture, and some awesome things to see and do (visit the "tiger temple" where abandoned or orphaned tiger cubs are raised by humans; it's an incredible experience to go up and pet live tigers). There are also some... other... reasons to visit, ranging from "medical tourism" (dental, in particular, is high quality but orders of magnitude cheaper than in the US) to "sex tourism" (exactly what you think it is).
Their politics, on the other hand, are a complete flaming mess. Stay away from them (fortunately, this is easy; I was there for about five weeks and spent almost all of it out of the cities).
Good thing neither of the languages being discussed is in any way interpreted, or has been for a decade or so (actually, never in the official C#/.NET distribution).
But it's OK, I'm sure that somewhere under that mouth froth you actually know what you're talking about on some subject or other. Just keep searching, you'll find it eventually.
If you think Reflection usage is bad in ASP.NET MVC, you've obviously never seen Spring...
Also, the "whatever Java has" above is "nothing" because the idiot tested a bare JSP running on Tomcat vs. a ASPX running on top of the entire MVC framework on top of IIS. Yeah, no wonder the perf is going to suck; that's a huge amount of completely wasted overhead. IIS can serve a dynamic ASPX page without any of that MVC garbage just fine, thank you... and with that, get rid of all the Reflection and so forth that, while actually useful in seriously enterprise-y organizations where you want to be able to do things like drop-in replacements of one class for another by changing a single line in a configuration file, are utterly wasted on a trivial benchmark like this.
For simple ASP.NET, you can do fine on Mono (runs on Linux, *BSD, OS X, etc.) and there's an Apache module to use it. .NET framework), there's an official OS X plugin, or a very incomplete and outdated Mono-based one (Moonlight). .NET, yeah, you're limited to Windows (including, albeit with some restrictions, various flavors such as Windows Compact Embedded, Windows RT, and Windows Phone).
For pure C#, as long as you don't use the really fancy new features that haven't been implemented yet, the same is true.
For Silverlight (which can be written using C# and other Common Language Runtime languages, and uses libraries from the
For the new and fancy stuff in
Oh, it's even better...
Test 2: A function to generate a "full web site", (actually a simple web page with all the elements and trivial content). Java using a single JSP on bare Tomcat beats C# using the full MVC4 framework over IIS just to display an ASPX file hands down.
Emphasis added, obviously. The guy had no idea what he was doing.
Frankly, the obvious problem (from somebody who has done a bit of both JSP and ASP.NET development) is the use of the MVC framework on IIS, and nothing even remotely equivalent on Java. If this were going to be as close to an apples-to-apples test as possible, you'd use bare ASP.NET (a single .ASPX page, possibly with a code-behind .cs file) and a single .JSP page.
I don't even think it's a matter of the author of the article having any agenda or something... I think he just honestly doesn't understand how to use the frameworks. For a very roughly analogous example from another programming domain, if I want to display a line of text on the terminal, I print a line of text. I don't go pull up the ncurses library and use it to create a one-line-tall TUI into which I create a label containing my text and then immediately exit. That would be... well, about as smart as using a heavyweight MVC framework to produce a web page containing the current time.
Unfortunately, electric car batteries are a lot bigger than most people realize. The Tesla Model S? It's the entire bottom ~4 inches of the car's body. Aside from a little but of room to account for very minor collisions and such, the battery bank is literally the size of the horizontal cross-section of a sedan. It also weighs well over a ton (the Model S is shockingly heavy, and over half of it is the battery bank).
Now, could you build a "battery station" designed to remove and replace such batteries, in a reasonably automated fashion, in a few minutes? Yeah, maybe, if the car were engineered for that... and the by "the car" I mean *all* cars you wanted to service at such a station. It would take a fairly large facility and a lot of engineering. You'd have to be able to store and simultaneously charge a substantial number of such batteries (admittedly, the space devoted to tankage in a convention fuel station would probably suffice).
So, the engineering would be hard, but it's probably possible. However, and perhaps most problematically, it would require standardizing on a specific battery. Dimensions, voltage, weight, and probably capacity. Want to build a smaller car? Oops, sorry, the battery won't fit. Want to offer different ranges of car (as the Model S itself has)? Sorry, all batteries are the same (you could argue "OK, just sell the car without the battery then, and pay at the 'pump'" except that the battery is major portion of the cost). Want to use a new battery chemistry that offers higher energy density but 15% lower voltage? Aside from the issues of introducing that into the supply chain (do people pay more to lease the new battery at each station? Do they get some of that back when they drop it off at a station that only has the old style?), those new batteries aren't going to be usable without inefficient voltage conversion, adding components and reducing the advantage of the new chemistry.
Don't get me wrong, I love the idea, and in time it's probably the way we'll go. But at this point, electric cars are too immature as a technology. We can't afford the weight and capacity penalties of using smaller, more modular batteries, and we can't offer the homogeneity needed to use one standard, massive battery, and we can't offer the future-proofing needed to make the battery exchange stations practical for the coming decade or so... look at what electric cars were just five years ago, compared to today!
C# is much more than a clone of Java (the list of things .NET code, including C#, can do but Java can't is very long), but more to the point:
C# was invented by MS, who had, by that time, many years of battling security issues and had apparently learned a few things along the way. The closest thing .NET has to Java applets is the Silverlight browser plugin, which, like Java applets, runs in a sandbox that restricts the operations possible by the applet code. However, there are two major differences: .NET have "reflection" APIs which allow the code to examine and modify itself. However, while Java applets mostly just try to block specific dangerous operations from happening in reflection (it's a near-impossible task to get them all), Silverlight has made Reflection essentially read-only, allowing examination of the loaded classes and assemblies, but not allowing adding or modifying any code (which is how Java applets keep getting broken; the security manager is in Java itself, and gets overwritten or bypassed using reflection).
1) In Java, a number of potentially very dangerous operations are permitted if the applet is "trusted", which mostly comes down to it being digitally signed. In Silverlight, those operations aren't permitted at all.
2) Both Java and
Well, as an example, this site you're reading wouldn't exist. The browser you're reading it in probably wouldn't either. If you're like a substantial portion of the readership of this site, the OS you're running that browser on most likely wouldn't exist either.
Free software (in either the gratis or libre sense) would be nigh-impossible without the "as-is" clause you so deride. At the very least, nobody would publicly publish it. In the "cathedral and the bazaar" sense, the bazaar becomes impossible (every single code submission becomes a new source of liability) and the cathedral approach becomes far too expensive to use for anything short of critical applications (actually critical, like medical and telecom systems, not such silly little things as web browsers). So, IBM would still exist, but they'd be serving a very niche environment. Microsoft would probably exist, but they'd either be writing software for those really expensive systems (and selling it for thousands of dollars, minimum) or they'd still only have one or two products: development tools that could be used by very wealthy hobbyists who had managed to acquire computers. Hardware would be vastly more expensive, as the demand would be much lower and thus there would never have been the money to fund massive R&D.
As-is solutions work pretty well. Did you know that in most of the world, you can't sue a doctor for malpractice? Liability insurance is one of the major reasons why medicine is so vastly more expensive in the US than almost anywhere else. Yes, it's also "safer"... assuming you can afford it at all.
IE10 is available for Win7. It's technically a "preview" release, but I use both Win7 and Win8, and IE10 behaves the same on both. It's the most release-candidate-level software I've ever seen go for more than a week without actually being released (it became available over a month ago).
Yeah. For the record, I'm aware that I can get all of these features, and then some, using enough Firefox extensions (although the implementation isn't always as polished). However, I appreciate the fact that they're built in, and that I don't have to worry if they're going to conflict, or leak RAM, or be broken by some update (less of an issue now). Still, I definitely keep Firefox installed. In fact, I keep all of the major browsers except Safari installed (I view Safari as offering basically nothing in exchange for its crap UI and since I don't have a Mac, I can't get the latest version anyhow). Chrome is "Safari (or more specifically, WebKit), but with a few more features and a slightly less-awful interface." Firefox is "Firebug and Gecko and don't open too many tabs or you'll have to restart it." Opera is "ALL THE FEATURES and Yet Another Rendering Engine but WHY are the keyboard shortcuts different from every other browser?"
Obviously, the above is over-simplified... Firefox loses points (and value) by being single-process, but despite being multi-process IE also starts to struggle if you open too many tabs at once (and it's not system resources, it's just the browser acting up). I actually use Opera as my secondary browser - I really do like the less-minimal interface; I think the thing that honestly pisses me off most about IE is the removal of the title bar - but no matter how often or how much I use it, its commands always feel just a little alien to me (I may use the keyboard more than most people do when browsing).
Personally, I actually find IE's interface one of the better ones. I don't like the approach that most browsers have been taking recently of minimalizing the browser UI; IE is no better off there than Firefox or Chrome (though its badness is slightly different) but things like the colored and automatically-combined tab groups, the ability to cycle through tabs in last-used order, the Favorites sidebar and feed reader, and the "Accelerators" feature for things like translating a text snippet instantly are all features which I appreciate, and feel are implemented pretty well.
Now, if it would just handle massive numbers of tabs more gracefully... there's a reason I use the "Ctrl+Tab cycles in last-used order" feature so much!
Similarly, jailbreaking RT can be argued to give it a new reason *for* existing. Before, it was a partially crippled device which had excellent battery life and portability, but you were so restricted in what you could do with it, no matter where you were or how long the battery lasted, that it wasn't as compelling a purchase. The Windows Store is ramping up quickly, but there will always be some classes of apps that just can't run in it, or at least not practically, and there will be more people who choose not to go through the effort of re-writing their UI for the new interface. It's a lot easier to take an existing Windows app's source code in VS 2012, open the Configuration Manager, select "ARM", and hit build again...
Not only do the tools exist for developing desktop apps for RT, they're actually the same (free, for the Express versions) Visual Studio tools used for developing Metro apps. You have to change one configuration file to stop it from bitching at you about not being able to create ARM desktop apps, and you'll find the list of .LIBs is sorely lacking, but the fix for the first was posted on StackOverflow weeks (months?) ago, and the second is easily fixed by "cutting" LIBs out of DLLs using scriptable programs which come with the build tools.
In fact, this hack would be mostly pointless if such tools didn't exist. Just because RT can now run desktop apps doesn't mean that it can run legacy (x86) software... at least without an emulator, which was one of the first things ported. Most programs recompile pretty smoothly, once you've gotten the tools set up. Just load the .SLN file in VS, select ARM as the target, and hit Build.
I've seen it before. Excluding the 10% or so that aren't on any smartphone (browser Silverlight plugin? Ha!), the 15% or so that were there when the list was first made and the people who made it were just being idiots, the 30%-ish that have been fixed in Mango or later versions of WP7 (seriously, that list is old; Mango came out a year and half ago, and I'm not counting WP8 changes in that 30% list), the additional 10% or so that were fixed by third-party apps, and the 25% or so that are fixed by homebrew apps, and you have the remaining 10 or so of features that some subset of the population wants but WP7 can't provide. Big whoop-de-doo, no smartphone OS is a strict superset of the others.
Different phone, same OS...
Downloaded non-game Marketplace apps that I use at least semi-regularly, from the top: /.).
Adobe Reader (sadly, the best PDF solution for WP7 right now).
Amazon Kindle (constantly).
Amazon Mobile (somewhat infrequently, but it has the cool features like barcode scanning to look up pricing).
AuthenticatorG (Google Authenticator implementation).
EveMon7 (EVE Online character tracking tool).
Flashlight (uses the extremely bright camera flash LEDs).
Forward Contact (not built in, sadly).
GeekByte (feed reader for various tech sites, including
Headshot (cool app that uses facial recognition and spoken instructions to help you take self-portraits using the back camera).
HTC YouTube (better than the default one, though these days I mostly use HTML5 in the browser).
ICanHasCheezburger (my daily dose of silly cat pictures).
IM+ (multi-network IM client).
LinkedIn (the phone has some integration, but the app is much more complete).
Look n Type (text messaging app that uses the camera to show what you're about to run into).
Mango Transit (get bus routing, sadly the built-in maps app only supports car and foot navigation).
MTG : Helper (Magic: The Gathering life tracker / card lookup / etc.).
OneBusAway (shows real-time ETAs of buses).
oPenGP (OpenPGP implementation, since we use encrypted mail at work).
RemoteDesktop (Windows terminal services client, not built-in but the this third-party implementation is excellent).
Shazam (music recognizer, works slightly better than the built-in feature).
SkyDrive (the built-in one only supports document formats).
Skype (sadly not integrated in WP7, unlike WP8).
SnowMinder (ski conditions, snow day tracker, etc.).
Speed Tester (Internet speed test).
The SSH Client (exactly what is says on the tin, and works well).
TouchDevelop (scripting IDE and runtime for the phone).
Trailhead (hiking trail info, maps, etc.).
User Agent Switcher (for sites that don't like the IE user agent).
Vimeo (Internet video site, if you were somehow unaware of it).
WarDice (polyhedral dice rolling app).
Weather (The Weather Channel app).
Xbox SmartGlass (access and control an Xbox 360 from the phone).
XDA-Developers (read and respond to PMs and forum posts).
Yelp.
Ztitch (build panoramic photos).
Games:
7cave (good old fly-through-a-cave game).
Chromatic Pro (bullet-storm game, shoot falling enemies with various weapons before they reach the bottom).
Civilization Revolution (soooo much civ...).
Fruit Ninja.
geoDefense (great tower defense game)
Hearts.
Mars Runner (obstacle course racing, basically).
Minehacker (free Minesweeper clone).
Picross 7 (WP7 picross game).
Plants vs. Zombies.
Puzzle Quest 2.
Rise of Glory (biplane combat flight sim).
Sudoku.
Wizard's Choice (fantasty-themed choose-your-own-adventure style of game).
Wordament (incredibly addicting free word search game where everybody around the world plays on the same board at once).
ZOMBIES (on the ph0ne) (twin-stick top-down shooter with fun flavor).
Note that I'm excluding a lot of apps that other people probably have, like Angry Birds, Facebook, Netflix, and such, as well as excluding apps that I don't use much (OpenTable, iHeartRadio since the phone has built-in radio and music streaming, etc.) but have installed anyhow. Most significantly for my phone in particular, I'm also not including sideloaded homebrew apps, like Advanced Config (customize all the device sounds, etc.), Bazaar (think Cydia), BlueManager (full Bluetooth file transfer), lockWidgets (dynamic lockscreen info), Marketplace Config (bypass marketplace regional or device restrictions), Metro Theme (advanced custom theming), Orientation Lock (not built in, sadly), phonemander (Midnight Commander-like file browser), SMSBackup (also not built in...), TouchXperience (alternate shell + connection to a PC app for remote administration), USBModeSwitch (wired tethering; wifi is bui
You came *so close* to understanding, and then you lost it.
This hack involves the following steps:
1. Probe the address of a kernel flag.
2. Attach a debugger to the user-mode CSRSS.exe and modify a function call it makes into the kernel using info from step 1.
3. Execute the function call to change kernel-mode memory.
Step 1 is fairly legit, even though it's not really supposed to be possible from a WinRT app.
Step 2 is completely legit, assuming step 1 succeeds.
Step 3 is the tricky one. This is not a kernel debugger, those are *NOT* allowed on Windows RT devices. But, it's changing *kernel* memory (because that's where the relevant flag resides). HOW'D THEY DO THAT?!?
Turns out that the kernel trusts CSRSS a lot, and doesn't validate the parameters of some calls it makes. Some of those parameters can be used to modify kernel memory. It's a write-only process, but we know the target address (from step 1) and we know (approximately) what the desired value is - more accurately, we know the difference between the initial value and the desired value, which is good because the exploit works by decrementing the value - so that's usually not a problem.
Anyhow, this fully meets your definition of a jailbreak.
"some sort of privilege escalation": Yes, from Admin (required to attach the debugger) to kernel. Not normally a boundary that matters, which is why a multi-year-old exploit was left unpatched and we were able to use it, but on Windows RT there is in fact a boundary between Admin and kernel.
"from inside a locked-down system": Pretty much obvious, although it's worth noting that this hack requires already being able to sideload a sandboxed app and attach a debugger to a user-mode system process, which is a lot less locked down than some other systems.
"using bugs in the system": Yep. The kernel could, and arguably should, prevent CSRSS from sending it invalid parameters like that; the API in question isn't actually supposed to allow decrementing an *arbitrary* memory address.
That said, it's earned MS a lot of press coverage in the tech community, and there's been a lot of excitement over the hack amongst RT users, so hopefully they don't patch this out without providing an alternative method (or until we find one ourselves...)
Note that this hack does actually make use of a genuine security vulnerability. Specifically, the user-mode system process CSRSS.EXE (Client/Server Runtime SubSystem) makes a bunch of calls into the kernel. The kernel checks that CSRSS is the process making these calls, but beyond that, it doesn't bother validating the parameters much, if at all. Some of the calls have parameters that, if deliberately modified, can be used for write-only access to kernel memory. That's what this hack is doing: changing a kernel-mode flag that controls what signature level is required on EXEs (RT defaults to "Microsoft", or 0x80000 x86 Windows defaults to "None" or 0x00000; this hack simply decrements that memory address by approximately 0x80000 depending on the state of the other flags).
This vulnerability has existed for years, and previously has not been worth patching. In order to exploit it, you need to attach a debugger to csrss. In order to attach a debugger to a system process, you must be Admin. If you're Admin, you *used* to be able to just attach a debugger to the kernel directly. However, doing so requires a bootloader option change, and Secure Boot on Windows RT device prohibits adding the debug flag to the bootloader configuration. Therefore, while this bug was never before a priority for MS to patch (why bother, when they can squeeze a bit of performance out of skipping the parameter checks and the security is functionally identical?), the fact that Admin on RT does *not* automatically also imply kernel access means they may re-evaluate the priority of the bug.
The "why" is twofold. First of all, it's there, and we could. People have been working on this since literally launch day. Hackers gonna hack. Second, the Surface RT (and presumably other Windows RT devices) actually make very nice highly portable computers. With the familiar Windows interface and standard system tools, plus the keyboard and mouse provided by the cover, and excellent battery life... the only thing they are missing is software. The restrictions on third party apps (the AppContainer sandbox) makes it difficult to do things like create a decent IM client that is permanently connected without any lag, or an x86 PC emulator. Furthermore, all of the UI and much of the program code will need to be re-written (in most cases, at least) even if you want to target a Windows Store app.
This jailbreak largely solves the second problem. While closed-source software is still not going to be available, it turns out to be very easy to persuade Visual Studio to build desktop apps for Windows RT (something it's not *supposed* to do, but is fully capable of) and people have been working on re-building open-source software pretty much all day. The list is growing slowly at the moment, but it is growing.
As for complicated... not really. The most complex part is installing the sideloaded Metro application, and there's a script that almost completely automates that part. The rest is easy; run the tool, press Volume Down when instructed to do so, hit Enter and you're done.
Gwala is correct, and the purpose of this hack is to remove that restriction. There are a handful of apps which have already been ported. PuTTY, TightVNC, Bochs, and 7-Zip were the first. There are ongoing efforts to port more (including some mildly ambitious projects, like Firefox, Chromium, Thunderbird, Java, and Python).
Additionally, any pure .NET 4.5 app will run, unmodified, on the Surface RT after "jailbreaking". It has to be entirely 4.5 though; Windows RT doesn't include the legacy versions.
There's a thread on the XDA-Developer forums with a list of ported software: http://forum.xda-developers.com/showthread.php?t=2092348
You could always deliver sideloadable APPX packages. They would require your users to install a developer license (free, supported, less complicated than this jailbreak tool, and doesn't rely on a patchable OS security hole) but it works fine. In fact, this tool requires sideloading such a package already.
The difference is that APPX packages (bundled "Metro" apps) only work for apps that run within an "AppContainer" sandbox. That means very restricted access to the whole system, no ability to run as Admin, no ability to run as a service, and almost no ability to run on the desktop (the final item is, unofficially, partially possible but it's a total hack). This "jailbreak" (I don't care for the term but can't come up with a better one) allows you to simply compile normal Windows binaries for ARM and run them like any other .EXE.
Exploit kits are not illegal. They have legit uses for testing your own security. For example, see Metasploit, which includes a large suite of exploits.
For fun? Minecraft.
For work? Burp suite (there are other HTTP proxies, but none that do as well what I need them to do).
There's also things like Eclipse and NetBeans (developers are people too... even if they are Java developers), of course... Java begets Java, to a certain degree, and there's already so much Java out there that it's pretty much impossible to stop creating more of it anytime in the reasonable future.
Citation and/or clarification needed. Sure, *somebody* is making money... but unless it's Dickens' estate, then it doesn't benefit the creator of the work (at least, not monetarily) and therefore "no possible way to make money" is, hyperbole aside, correct. I suspect you'll find that the only people making money are those who take the works of long-dead authors and re-publish them, pricing the result below new publications because they don't have to pay royalties to anybody or secure the rights, they only need to avoid making the books so expensive that another publisher doesn't undercut them.
Now, that doesn't mean that it isn't, in fact, perfectly reasonable for there to be companies doing this (re-publishing public domain works and profiting off of them). However, the central tenet of your argument is "authors still make money without copyright" and yet you've presented absolutely no evidence in support of this. If copyright expired quickly, slightly-older works would be substantially less expensive, and the bulk of the money being made would go to the publishers (or public domain content) rather than the authors (who only receive payment when they sell something that's more expensive than the older stuff).
There's probably a reasonable middle ground - could be anything from a hard limit (anywhere from the US's original 14 years to something like a century is justifiable to one degree or another) to a wildly sliding scale based on something like the number of copies being published annually by the creator (note: not by re-sellers), or the value of those sold copies (but that gets tricky with open source... which, you should note, is usually not successfully sold for money because it's just so easy to undercut the price).
Eh? Not at all. Negative votes impact a candidate's total, and the candidate with the highest total still wins. Of course, that could be the only candidate left positive, or even the candidate who is least negative... but it's all still a valid approach.