It's not just the UK and France, though. The ocean is a big place, there are lots of countries with navies, and some of them aren't neccessarily people we want being able to track our mobile nuclear arsenals. Active sonar can be heard a LONG way (further than the originating sub can get any meaningful echo from it, in fact, meaning that you can releave your position to somebody without ever knowing that said somebody is there). There's also no way to be absolutely sure that another sub belongs to an ally - usually its safer to assume not.
I'm reminded of a story I heard about two US Navy battle groups playing war games. The commanding officer of one of the groups was frustrated because the other always seemed to know *exactly* where he was - it's a big ocean, and carriers routinely launch from well out of radar range from their targets, and yet the other CO always knew where to send his planes.
The CO then got an idea, and asked the sonar operator what the current depth was. The sonarman responded that the depth sounder was broken; ever since leaving port it had read 300 feet. The CO called another ship in his group and asked them to fire a sonar pulse beneath his ship, and discovered that an opposing submarine had been shadowing his group throughout the entire exercise. Nobody - not even the destroyers who were supposed to hunt subs - had caught on.
Just wondering, is it still only NTFS-3g? That will only work correctly up to NTFS found on NT5.x (2000, XP, Server 2003) - 6.x has a new version which is mostly but not entirely backward compatible - writing using a driver that doesn't understand the new version can result in loss of "Previous Versions" shadow copies of files. For this reason I've found it beneficial to mount Vista/Win7 partitions RO, but then I'm still using a distro from last year.
just like the random anecdotes and wild conclusions in TFA
Wait, there's an article? All I saw were random anecdotes and wild conclusions in the summary.
Just for extra fun, said random anecdotes are perfectly explainable, for example the "Local Settings" folder doesn't even exist - it's a severely limited form of symbolic link to AppData\Local. You can't access "Local Settings" in Explorer on *any* version of NT 6 or up (Vista, Server 2008, Win7).
Kind of - they're actually more similar to symbolic links (symlinks) in that they don't actually point to the exact same physical location on the disk, but merely tell the filesystem to go to another file/folder. Unfortunately, NTFS junctions (as these particular flavor of reparse points are called) are substantially more restricted than symlinks, as the examples given above illustrate. That said, you actually can use junctions in Explorer; type into the navigation bar (in Vista) C:\Documents and Settings\<YourUserName> and press Enter. Even though DOCUME~1 is a junction, you'll still be where you expect to be. Try clicking on the breadcrumb for the junction, though, and you'll find you still can't view it directly.
The weird thing? In Vista, NTFS actually supports symlinks. I can only assume they weren't used in the default install because XP wouldn't know what to do with them... it does seem that they would make things easier, though.
The weird thing is, Vista and above actually correctly implement symbolic links (not junctions, which are broken as you describe, or shortcuts, which can't be used as part of a path, or hardlinks, which are also available but can't point to folders or across volumes - real, honest symlinks). I'm not at all sure why "Documents and Settings" -> "Users", or "My Documents" -> "Documents", or any of the other places where overly complex or unclear folder names were replaced use junctions and not symlinks for their legacy names. Maybe they wanted to presever backward-compatibility with previous versions of NTFS (which didn't support symlinks) in the basic install, but it still looks ugly.
I agreed with you perfectly right up to the word "flaw" because this really is a case of something being a feature, not a bug. It's a freaking API for firewall control, not some sinister plot. It requires an Administrator-level process, which most installers insist upon. It allows things like Skype and torrent applications to work correctly out-of-the-box.
It's also the functional equivalent of system("iptables..."); in a Linux binary installer (or similar in an install script, etc.) - in other words, anything that you could do, on any system, as a given user... a program run with that user's permissions can also do.
Heh... just for the hell of it, I created an Amarrian alt on a trial account (back then, trials were 14 days only) some time ago.
I flew a few missions to make a little cash to buy skillbooks. It wasn't hard at all. Ships are cheap that early, and you can just use the loot the pirates drop to build your own fit for the first few days.
By the end of two weeks, I had a tier-3 frigate (could have gone for a destroyer, but Amarrian destroyers are crap) with a full set of tech-2 guns, a micro-warp drive to catch people, a warp scrambler to keep them from running, and enough durability to survive combat long enough to attack somebody, then run if the battle went poorly (unless they were both stronger and faster than me - but hey, then you picked a bad target). In the last few hours of the trial, I went on a small piracy spree - one small ship, a mere 14 days of skill training. Yes, I got killed, but not immediately. Anyhow it was fun, and I had enough ISK left over to rebuild the entire ship had I wanted to.
I could easily have gotten that character into a corporation (guild, for non-EVE-players). If I'd focused on ship skills, I could have been in a cruiser, nearly a battlecruiser, big enough to for 0.0 (lawless space, where players take over systems and run their own empires). Already, the solo frigate I had was a useful ship in a gng fight - I could scout, tackle enemy ships while my gangmates killed them, shoot down enemy drones or pods, or engage other tacklers and force them to run (allowing our gang freedom of movement) or fight me.
In short, a two-week character on a trial account was already a useful - not powerful, but useful - force in PvP, could be self-sufficient with minimal PvE, and was just a few weeks from being skilled enough to help carve out a piece of space and claim it for corp and alliance.
"Invest" the time to play it? What bullshit is this? Generally, people play games because they enjoy them. When I fire up EVE, I'm not doing it against some future return, I'm doing it because I want to blow somebody up and loot their ship, because it's fun. Not everybody finds EVE fun, just like I have no interest in WoW, but I don't *not* play WoW just because there's no Linux version - if I wanted to play it, I would.
Investing is something you do when you expect a return on investment. In this case, CCP invested some time and money in creating a pre-wrapped, playable out-of-the-box (at least, more so than real wine, though it's not hard in wine either), and supported (the big one) version. They expected a return in the form of more subscribers... but they didn't actually get many, so they didn't see a need to continue investing. This makes perfect sense to me; those who want to play EVE on Linux mostly just use wine anyhow; it works well, costs the user almost nothing, and costs CCP nothing at all. Win-win situation.
In other words, if you didn't want to play EVE anyhow, CCP has lost nothing. If you did, you're cutting off your nose to spite your face; lose-lose situation. Saying that you won't play a game, even though it works on your system, just because they use the wrong binary executable format... well, frankly that's stupid.
It was big news on Slashdot when they first released the Linux and OS X clients. It was also mentioned at least twice, in positively-modded comments, in every story even tangentially related to EVE since then.
Their big advertising push is relatively recent, but I think at least one of the ads mentioned "Windows, Mac, and Linux." Of course, the game still runs just fine on Linux - you just need to install the Windows version into Wine yourself, rather than getting CCP to wrap it for you. You can have the Premium graphics, though, so I'd say it's a fair trade. I tried the official, Cedega-wrapped client once, just to try it. I then went back to just using wine - there was no substantial reason to waste the disk space on Cedega.
It's called Hibernate (or Suspend-to-Disk, depending on your distro/environment). Fater than rebooting, ad everything is just like you left it. Of course, over half the Linux configurations I've tried in the last 3 years either don't enter or don't leave hibernate correctly - I think it's the nVidia driver, though I'm not sure - but there are alternatives to a full reboot.
Hell, if you don't need full hardware acceleration in Linux, just run your Linux install in a full-screen virtualized system. To play a game, you don't even need to suspend Linux directly - just pause the virtualizer, let Windows swap out its RAM, and fire up your game in its native environment.
Stackless Python isn't actually quite the same as your garden variety runtime for.py scripts. Stackless can be compiled on Linux, so it's not a deal-breaker, but it would still increase costs and test effort.
On the other hand, that "crummy DirectX wrapper" you deride so much (in the case of Cedega, I happen to agree, although wine itself is free and rapidly improving) is the reason itself. The game was released over 4 years ago. That's a LOT of work invested with a widely-deployed, well-supported API well-designed for gaming needs (not just 3D, though that's certainly a part of it).
Are you really suggesting they should throw away all that work, re-writing large portions of their game engine, putting actual improvements on hold, rather than use an already-written runtime layer that allows them to use their existing code?
The way I see it, their main mistake was going with Cedega/Transgaming rather than wine itself, or perhaps Crossover/Codeweavers (if they want commercial support). My guess is that in the near future, there will be an unofficially or even officially supported wine build that runs EVE happily, probably linked directly from CCP's site.
First, that's NOT bait-and-switch; they never said it was a native port of the client, they said they were releasing a client that ran on Linux. They did, and it does (lack of Premium graphics aside). They never pretended it was anything that it wasn't, in either the announcements I saw or the download page. It's not like you pay for the client, anyhow, although the install footprint seemed more than a little excessive to me.
Second, suppose they had taken winelib and compiled the client, from source, against it.* This would have produced a native ELF binary, linked against a native.so library using POSIX syscalls. On the other hand, it still would have been EXACTLY THE SAME CODE, would still have been proprietary (wine is LGPL, so CCP wouldn't have needed to release their source), would run about the same (Direct3D calls translated or OpenGL, etc.) and would have increased the complexity of CCP's development and patching system (no longer even pretending to be in Windows). It would technically have been native, though... would THAT have been enough to get you as a customer? Is the trivial difference from your perspective enough to justify the major cost and effort from theirs?
* Of course, this wouldn't have worked anyhow; a good chunk of EVE is written in a Python derivative which almost certainly wouldn't have compiled against winelib a year ago, since Python itself didn't until about a week ago.
I'm actually mildly surprised that Parallels allows enough hardware acceleration for that... I'd heard they were doing video acceleration, but not that it worked so well.
Does it support Direct3D 9 (required for Premium)? Cedega seems to have major issues with DirectX 9, and Wine is still somewhat buggy in that regard.
There probably will be an actual reset mechanism. However, this really shouldn't be needed. Since the OS manages all the software (no user-space un-managed code allowed), the OS knows what resources a program is using, and if a program is ended, the OS knows exactly what it *was* using and can free it all. To prevent a greedy program from taking everything then dying, reserve enough resources to terminate any given application easily.
Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.
This doesn't make any sense to me. Sure, while you're editing the document you would need to be able to undo fully. If the editor unexpectedly crashed, it would be nice to be able to restore not only its most recent state, but those immediately preceding it, too.
However, there's no remotely logical reason that you would *need* to copy all this history when you serialize your document to a file on a flashdrive or a bunch of encoded ASCII in an email. Sure, maybe you could send it along if you want - that's the purpose of Word's "Track Changes" feature - but you don't have to. When you "send" the document, even if it's just to a removable storage device, it's reasonable to assume that it is in the state you want it to be in, and therefore you no longer care about its prior state(s).
Regardless of how cool the OS' underpinings are, you could write C for it with an OS-specific compiler.
If you don't mind never using a pointer, sure. Of course, writing literally anymore much more complex than "Hello, World!" using C without one variable of a pointer type or one instance of &varName is effectively impossible; the language just isn't designed that way.
This OS is exclusively for managed code. Memory pointers are anathema to managed code, and also make serious security vulnerabilities for more likely. As was mentioned in another post, Phantom doesn't even run programs in different memory spaces - why should it, when the software can only access memory that it explicitly requested from the system? Without the ability to access arbitrary memory addresses, and with modern memory managers, separating process memory spaces is wasted effort. Thread switching is faster than process switching for a reason...
The old/. would figure out how to get the premium client running on a toaster.
Welllll... NetBSD has been run on a toaster, and Wine can run on NetBSD, and the Premium client can run (for the most part) on Wine... so all you need is a toaster running a x86 processor with enough clock speed and RAM, plus a video card capable of Premium graphics (Direct3D 9c equivalent).
I, for one, welcome our new open-source-powered gaming toasters!
Actually, while it's not Windows, Microsoft Research does have a working OS kernel written almost entirely (for obvious reasons, some assembly required) in a managed language descended from C#. It's called Singularity, and is an open-source project - not much can be done with it, but it's fun to play with. Midori, a internal project aiming to take what was learned from Singularity but do better and potentially accomplish much more, is under development within MS.
Additionally, I believe Media Center, at least in Vista, is almost entirely.NET code - a rather impressive example of it, too. Future versions of Microsoft's development tools, Visual Studio and the Expression Suite, also use WPF (a.NET component) for their UIs, at least.
In other words, while the NT kernel is most definitely still all C (with small bits of assembly - it is actually intended to be highly portable), it's not impossible for managed code to find its way even in there - and.NET is far from dead.
Sorry to burst your bubble, but in some cases.NET code is actually faster than native C++. The reason is that it actually *does* get compiled to native code just before execution - the bytecode is only to provide a machine-independent intermediate language, which nearly all compilers have even if the developer never sees the output at this step - and that JIT compiler optimizes for the specific hardware it is running on. Typically, developers compile for general i386 or possibly i586, but don't come close to taking advantage of the specific advantages of modern processors - that would make the code run slowly or completely fail to run on older (or just *other*) CPUs.
This JIT compilation does have a cost, of course - a brief startup delay on the first execution (the native code is cached thereafter) and an increased runtime size to include the JIT - but execution speed of.NET code is actually quite good. Mono also includes such a JIT compiler on the most common platforms, including the x86 derivatives.
JavaScript? JS can be used outside of web applications, and it can be very useful indeed within web applications, but even there you certainly don't need *every* developer to know it! There are plenty of web app frameworks out there (including ASP.NET, which can be run through Mono, incidentally) which will generate JS automatically for most things. As somebody who used to code the back-end portion of web apps, I would argue that SQL is far more important than JS.
Also, seriously, why Java? It's a popular language, but then, so is Visual Basic. I hardly see Java as being a "must-know" languge any more than almost any other modern managed-code language (of which there are plenty, many providing language features which Java could really stand to have but doesn't).
But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it. I don't even really understand why they bother.
Well... since one of the very best things about F/OSS is how fast it moves and evolves, I'd say anything after a line such as "Unless things have changed..." can quite safely be ignored. Things have changed IMMENSELY in the last 2 years. Three years ago, Mono couldn't do WinForms, couldn't really do VB, and had major compatibility issues. Two years ago, it had full.NET 1.1 compatibility including WinForms and VB.NET, and a good chunk of 2.0. Today, it has effectively all of 2.0 and some 3.x, supports an incredible number of languages and many platforms, is widely used on Linux desktops (know it or not), and is quite easy to target as a development platform, even from.NET; just avoid using any native DLLs, and there's a good chance you can take your Visual Studio-compiled EXE and DLL files, copy them to Linux, run Mono on the main EXE, and it will Just Work. Heck, FreeBSD has a optional application loader module which will automatically run Mono on a CLR binary, so all you need to do is type MyMonoApp (assuming it's somewhere in your PATH and marked executable) and it runs.
There are a few other Mono apps out there, though I certainly don't have anything like a comprehensive list. The source control software I used at a summer internship some 2.5 years ago had a nice graphical interface that was easy to use and looked good (I use Subversion these days and am contemplating moving to Git, but at the time I'd never used version control before and found this one quite easy to get the hang of). It ran on.NET 1.1, but the company officially supported the product on Mono as well. At the time, Linux was still not widely known, never mind used - I see it even on non-CS students' laptop now, but certainly didn't then - but this company was willing to put resources into ensuring that their software ran on Linux, simply because Mono was so easy to target.
C# supports a lot of stuff that the JVM doesn't (currently), like actual pointers, function delegates, anonymous functions (unless Java got these while I wasn't watching), stack-allocated non-primitive structs (which are objects like any other), and other handy language tricks. Also, Java's one-public-class-per-file thing, combined with things like significant filesystem hierarchy for packages, just makes handling Java more of a pain. JARs hide the worst of it from the end user, but it's still uglier to run a Java app, even on Linux, than a.NET/Mono one.
Slashdot Mirror
It's a single registry key, easy to change. I've seen it used by everything from OEMs to non-malicious viruses.
It's not just the UK and France, though. The ocean is a big place, there are lots of countries with navies, and some of them aren't neccessarily people we want being able to track our mobile nuclear arsenals. Active sonar can be heard a LONG way (further than the originating sub can get any meaningful echo from it, in fact, meaning that you can releave your position to somebody without ever knowing that said somebody is there). There's also no way to be absolutely sure that another sub belongs to an ally - usually its safer to assume not.
I'm reminded of a story I heard about two US Navy battle groups playing war games. The commanding officer of one of the groups was frustrated because the other always seemed to know *exactly* where he was - it's a big ocean, and carriers routinely launch from well out of radar range from their targets, and yet the other CO always knew where to send his planes.
The CO then got an idea, and asked the sonar operator what the current depth was. The sonarman responded that the depth sounder was broken; ever since leaving port it had read 300 feet. The CO called another ship in his group and asked them to fire a sonar pulse beneath his ship, and discovered that an opposing submarine had been shadowing his group throughout the entire exercise. Nobody - not even the destroyers who were supposed to hunt subs - had caught on.
Just wondering, is it still only NTFS-3g? That will only work correctly up to NTFS found on NT5.x (2000, XP, Server 2003) - 6.x has a new version which is mostly but not entirely backward compatible - writing using a driver that doesn't understand the new version can result in loss of "Previous Versions" shadow copies of files. For this reason I've found it beneficial to mount Vista/Win7 partitions RO, but then I'm still using a distro from last year.
just like the random anecdotes and wild conclusions in TFA
Wait, there's an article? All I saw were random anecdotes and wild conclusions in the summary.
Just for extra fun, said random anecdotes are perfectly explainable, for example the "Local Settings" folder doesn't even exist - it's a severely limited form of symbolic link to AppData\Local. You can't access "Local Settings" in Explorer on *any* version of NT 6 or up (Vista, Server 2008, Win7).
(They're similar to *nix hard links.)
Kind of - they're actually more similar to symbolic links (symlinks) in that they don't actually point to the exact same physical location on the disk, but merely tell the filesystem to go to another file/folder. Unfortunately, NTFS junctions (as these particular flavor of reparse points are called) are substantially more restricted than symlinks, as the examples given above illustrate. That said, you actually can use junctions in Explorer; type into the navigation bar (in Vista)
C:\Documents and Settings\<YourUserName>
and press Enter. Even though DOCUME~1 is a junction, you'll still be where you expect to be. Try clicking on the breadcrumb for the junction, though, and you'll find you still can't view it directly.
The weird thing? In Vista, NTFS actually supports symlinks. I can only assume they weren't used in the default install because XP wouldn't know what to do with them... it does seem that they would make things easier, though.
The weird thing is, Vista and above actually correctly implement symbolic links (not junctions, which are broken as you describe, or shortcuts, which can't be used as part of a path, or hardlinks, which are also available but can't point to folders or across volumes - real, honest symlinks). I'm not at all sure why "Documents and Settings" -> "Users", or "My Documents" -> "Documents", or any of the other places where overly complex or unclear folder names were replaced use junctions and not symlinks for their legacy names. Maybe they wanted to presever backward-compatibility with previous versions of NTFS (which didn't support symlinks) in the basic install, but it still looks ugly.
I agreed with you perfectly right up to the word "flaw" because this really is a case of something being a feature, not a bug. It's a freaking API for firewall control, not some sinister plot. It requires an Administrator-level process, which most installers insist upon. It allows things like Skype and torrent applications to work correctly out-of-the-box.
It's also the functional equivalent of
system("iptables..."); in a Linux binary installer (or similar in an install script, etc.) - in other words, anything that you could do, on any system, as a given user... a program run with that user's permissions can also do.
Heh... just for the hell of it, I created an Amarrian alt on a trial account (back then, trials were 14 days only) some time ago.
I flew a few missions to make a little cash to buy skillbooks. It wasn't hard at all. Ships are cheap that early, and you can just use the loot the pirates drop to build your own fit for the first few days.
By the end of two weeks, I had a tier-3 frigate (could have gone for a destroyer, but Amarrian destroyers are crap) with a full set of tech-2 guns, a micro-warp drive to catch people, a warp scrambler to keep them from running, and enough durability to survive combat long enough to attack somebody, then run if the battle went poorly (unless they were both stronger and faster than me - but hey, then you picked a bad target). In the last few hours of the trial, I went on a small piracy spree - one small ship, a mere 14 days of skill training. Yes, I got killed, but not immediately. Anyhow it was fun, and I had enough ISK left over to rebuild the entire ship had I wanted to.
I could easily have gotten that character into a corporation (guild, for non-EVE-players). If I'd focused on ship skills, I could have been in a cruiser, nearly a battlecruiser, big enough to for 0.0 (lawless space, where players take over systems and run their own empires). Already, the solo frigate I had was a useful ship in a gng fight - I could scout, tackle enemy ships while my gangmates killed them, shoot down enemy drones or pods, or engage other tacklers and force them to run (allowing our gang freedom of movement) or fight me.
In short, a two-week character on a trial account was already a useful - not powerful, but useful - force in PvP, could be self-sufficient with minimal PvE, and was just a few weeks from being skilled enough to help carve out a piece of space and claim it for corp and alliance.
"Invest" the time to play it? What bullshit is this? Generally, people play games because they enjoy them. When I fire up EVE, I'm not doing it against some future return, I'm doing it because I want to blow somebody up and loot their ship, because it's fun. Not everybody finds EVE fun, just like I have no interest in WoW, but I don't *not* play WoW just because there's no Linux version - if I wanted to play it, I would.
Investing is something you do when you expect a return on investment. In this case, CCP invested some time and money in creating a pre-wrapped, playable out-of-the-box (at least, more so than real wine, though it's not hard in wine either), and supported (the big one) version. They expected a return in the form of more subscribers... but they didn't actually get many, so they didn't see a need to continue investing. This makes perfect sense to me; those who want to play EVE on Linux mostly just use wine anyhow; it works well, costs the user almost nothing, and costs CCP nothing at all. Win-win situation.
In other words, if you didn't want to play EVE anyhow, CCP has lost nothing. If you did, you're cutting off your nose to spite your face; lose-lose situation. Saying that you won't play a game, even though it works on your system, just because they use the wrong binary executable format... well, frankly that's stupid.
It was big news on Slashdot when they first released the Linux and OS X clients. It was also mentioned at least twice, in positively-modded comments, in every story even tangentially related to EVE since then.
Their big advertising push is relatively recent, but I think at least one of the ads mentioned "Windows, Mac, and Linux." Of course, the game still runs just fine on Linux - you just need to install the Windows version into Wine yourself, rather than getting CCP to wrap it for you. You can have the Premium graphics, though, so I'd say it's a fair trade. I tried the official, Cedega-wrapped client once, just to try it. I then went back to just using wine - there was no substantial reason to waste the disk space on Cedega.
It's called Hibernate (or Suspend-to-Disk, depending on your distro/environment). Fater than rebooting, ad everything is just like you left it. Of course, over half the Linux configurations I've tried in the last 3 years either don't enter or don't leave hibernate correctly - I think it's the nVidia driver, though I'm not sure - but there are alternatives to a full reboot.
Hell, if you don't need full hardware acceleration in Linux, just run your Linux install in a full-screen virtualized system. To play a game, you don't even need to suspend Linux directly - just pause the virtualizer, let Windows swap out its RAM, and fire up your game in its native environment.
Stackless Python isn't actually quite the same as your garden variety runtime for .py scripts. Stackless can be compiled on Linux, so it's not a deal-breaker, but it would still increase costs and test effort.
On the other hand, that "crummy DirectX wrapper" you deride so much (in the case of Cedega, I happen to agree, although wine itself is free and rapidly improving) is the reason itself. The game was released over 4 years ago. That's a LOT of work invested with a widely-deployed, well-supported API well-designed for gaming needs (not just 3D, though that's certainly a part of it).
Are you really suggesting they should throw away all that work, re-writing large portions of their game engine, putting actual improvements on hold, rather than use an already-written runtime layer that allows them to use their existing code?
The way I see it, their main mistake was going with Cedega/Transgaming rather than wine itself, or perhaps Crossover/Codeweavers (if they want commercial support). My guess is that in the near future, there will be an unofficially or even officially supported wine build that runs EVE happily, probably linked directly from CCP's site.
First, that's NOT bait-and-switch; they never said it was a native port of the client, they said they were releasing a client that ran on Linux. They did, and it does (lack of Premium graphics aside). They never pretended it was anything that it wasn't, in either the announcements I saw or the download page. It's not like you pay for the client, anyhow, although the install footprint seemed more than a little excessive to me.
Second, suppose they had taken winelib and compiled the client, from source, against it.* This would have produced a native ELF binary, linked against a native .so library using POSIX syscalls. On the other hand, it still would have been EXACTLY THE SAME CODE, would still have been proprietary (wine is LGPL, so CCP wouldn't have needed to release their source), would run about the same (Direct3D calls translated or OpenGL, etc.) and would have increased the complexity of CCP's development and patching system (no longer even pretending to be in Windows). It would technically have been native, though... would THAT have been enough to get you as a customer? Is the trivial difference from your perspective enough to justify the major cost and effort from theirs?
* Of course, this wouldn't have worked anyhow; a good chunk of EVE is written in a Python derivative which almost certainly wouldn't have compiled against winelib a year ago, since Python itself didn't until about a week ago.
I'm actually mildly surprised that Parallels allows enough hardware acceleration for that... I'd heard they were doing video acceleration, but not that it worked so well.
Does it support Direct3D 9 (required for Premium)? Cedega seems to have major issues with DirectX 9, and Wine is still somewhat buggy in that regard.
There probably will be an actual reset mechanism. However, this really shouldn't be needed. Since the OS manages all the software (no user-space un-managed code allowed), the OS knows what resources a program is using, and if a program is ended, the OS knows exactly what it *was* using and can free it all. To prevent a greedy program from taking everything then dying, reserve enough resources to terminate any given application easily.
Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.
This doesn't make any sense to me. Sure, while you're editing the document you would need to be able to undo fully. If the editor unexpectedly crashed, it would be nice to be able to restore not only its most recent state, but those immediately preceding it, too.
However, there's no remotely logical reason that you would *need* to copy all this history when you serialize your document to a file on a flashdrive or a bunch of encoded ASCII in an email. Sure, maybe you could send it along if you want - that's the purpose of Word's "Track Changes" feature - but you don't have to. When you "send" the document, even if it's just to a removable storage device, it's reasonable to assume that it is in the state you want it to be in, and therefore you no longer care about its prior state(s).
Regardless of how cool the OS' underpinings are, you could write C for it with an OS-specific compiler.
If you don't mind never using a pointer, sure. Of course, writing literally anymore much more complex than "Hello, World!" using C without one variable of a pointer type or one instance of &varName is effectively impossible; the language just isn't designed that way.
This OS is exclusively for managed code. Memory pointers are anathema to managed code, and also make serious security vulnerabilities for more likely. As was mentioned in another post, Phantom doesn't even run programs in different memory spaces - why should it, when the software can only access memory that it explicitly requested from the system? Without the ability to access arbitrary memory addresses, and with modern memory managers, separating process memory spaces is wasted effort. Thread switching is faster than process switching for a reason...
The old /. would figure out how to get the premium client running on a toaster.
Welllll... NetBSD has been run on a toaster, and Wine can run on NetBSD, and the Premium client can run (for the most part) on Wine... so all you need is a toaster running a x86 processor with enough clock speed and RAM, plus a video card capable of Premium graphics (Direct3D 9c equivalent).
I, for one, welcome our new open-source-powered gaming toasters!
Actually, while it's not Windows, Microsoft Research does have a working OS kernel written almost entirely (for obvious reasons, some assembly required) in a managed language descended from C#. It's called Singularity, and is an open-source project - not much can be done with it, but it's fun to play with. Midori, a internal project aiming to take what was learned from Singularity but do better and potentially accomplish much more, is under development within MS.
Additionally, I believe Media Center, at least in Vista, is almost entirely .NET code - a rather impressive example of it, too. Future versions of Microsoft's development tools, Visual Studio and the Expression Suite, also use WPF (a .NET component) for their UIs, at least.
In other words, while the NT kernel is most definitely still all C (with small bits of assembly - it is actually intended to be highly portable), it's not impossible for managed code to find its way even in there - and .NET is far from dead.
Sorry to burst your bubble, but in some cases .NET code is actually faster than native C++. The reason is that it actually *does* get compiled to native code just before execution - the bytecode is only to provide a machine-independent intermediate language, which nearly all compilers have even if the developer never sees the output at this step - and that JIT compiler optimizes for the specific hardware it is running on. Typically, developers compile for general i386 or possibly i586, but don't come close to taking advantage of the specific advantages of modern processors - that would make the code run slowly or completely fail to run on older (or just *other*) CPUs.
This JIT compilation does have a cost, of course - a brief startup delay on the first execution (the native code is cached thereafter) and an increased runtime size to include the JIT - but execution speed of .NET code is actually quite good. Mono also includes such a JIT compiler on the most common platforms, including the x86 derivatives.
JavaScript? JS can be used outside of web applications, and it can be very useful indeed within web applications, but even there you certainly don't need *every* developer to know it! There are plenty of web app frameworks out there (including ASP.NET, which can be run through Mono, incidentally) which will generate JS automatically for most things. As somebody who used to code the back-end portion of web apps, I would argue that SQL is far more important than JS.
Also, seriously, why Java? It's a popular language, but then, so is Visual Basic. I hardly see Java as being a "must-know" languge any more than almost any other modern managed-code language (of which there are plenty, many providing language features which Java could really stand to have but doesn't).
But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it. I don't even really understand why they bother.
Well... since one of the very best things about F/OSS is how fast it moves and evolves, I'd say anything after a line such as "Unless things have changed..." can quite safely be ignored. Things have changed IMMENSELY in the last 2 years. Three years ago, Mono couldn't do WinForms, couldn't really do VB, and had major compatibility issues. Two years ago, it had full .NET 1.1 compatibility including WinForms and VB.NET, and a good chunk of 2.0. Today, it has effectively all of 2.0 and some 3.x, supports an incredible number of languages and many platforms, is widely used on Linux desktops (know it or not), and is quite easy to target as a development platform, even from .NET; just avoid using any native DLLs, and there's a good chance you can take your Visual Studio-compiled EXE and DLL files, copy them to Linux, run Mono on the main EXE, and it will Just Work. Heck, FreeBSD has a optional application loader module which will automatically run Mono on a CLR binary, so all you need to do is type MyMonoApp (assuming it's somewhere in your PATH and marked executable) and it runs.
There are a few other Mono apps out there, though I certainly don't have anything like a comprehensive list. The source control software I used at a summer internship some 2.5 years ago had a nice graphical interface that was easy to use and looked good (I use Subversion these days and am contemplating moving to Git, but at the time I'd never used version control before and found this one quite easy to get the hang of). It ran on .NET 1.1, but the company officially supported the product on Mono as well. At the time, Linux was still not widely known, never mind used - I see it even on non-CS students' laptop now, but certainly didn't then - but this company was willing to put resources into ensuring that their software ran on Linux, simply because Mono was so easy to target.
C# supports a lot of stuff that the JVM doesn't (currently), like actual pointers, function delegates, anonymous functions (unless Java got these while I wasn't watching), stack-allocated non-primitive structs (which are objects like any other), and other handy language tricks. Also, Java's one-public-class-per-file thing, combined with things like significant filesystem hierarchy for packages, just makes handling Java more of a pain. JARs hide the worst of it from the end user, but it's still uglier to run a Java app, even on Linux, than a .NET/Mono one.