I'd rather they fixed Windows guest support. I've tried it (in Ubuntu Karmic), and it's horrible if you want to run Windows in it (both XP and Win7). Very slow, timer lags behind, network and disk throughput are super slow even with virtio guest drivers. Linux runs fine as a guest on the same box.
I guess it's unfair to _demand_ anything if something cost you zero dollars (gifted horse thing and all), but VMWare ESX and HyperV Server also cost zero dollars these days, and they both run Windows just fine.
Well, for all practical purposes in most (99%) of Java dev teams, it is impossible to rebuild a version from 2 years ago an be sure it's exactly the same (modulo the fixes). No one uses versioning for tools, jre and and jars. Everyone uses Maven and pulls the deps either directly from maven repos on the web, or set up Nexus, which is not versioned either. In addition, folks see nothing wrong in deploying their code on a newer (or just plain different) version of a JRE. They just cross their fingers and hope it will work somehow. I know it for a fact that OpenJDK, for instance, doesn't even run Netbeans properly.
You may be doing things differently, but you're the exception rather than the rule.
>> Java jars are designed for backward compatibility >> so grabbing the latest one is safe
Heard that tune MANY times. The simple fact is, YOU DON'T KNOW THIS. That's precisely my point. Some Joe Sixpack changes calling semantics of a function on a whim and you end up with hairy issues in production, because a function, for instance, throws the kind of exception you don't catch further up the stack.
It will be another three or four years until OSGI becomes mainstream. By then.NET will have had cryptographically verified side-by-side deployment of code for well over a decade.
Apparently you don't understand what "jar hell" means. Let me really break it down for you.
Let's say you use foo.jar, which relies on a concrete version of log4j.jar. Let's also say foo.jar requires bar.jar, which in turn requires a different version of log4j.jar.
In.NET you deploy two different assemblies side by side and they coexist peacefully.
In Java you're fucked. Now, there are OSGI bundles now, but their use is far from widespread. This means that Java developers have no fucking clue whether jars in their their extensive dependency hierarchies are even fully compatible.:-)
Those local Maven repos are not versioned within the source control system, and therefore are unreliable. And checking in only jars is insufficient - in order for things to be 100% repeatable and isolated, you need to check in all your tooling, jdk and compilers as well, and make sure the developers launch a separate bash session which makes sure you're using only the tools in the enlistment, and not the ones installed locally on the box. No one does this.
I like how you avoided the jar hell issue and the issue where people grab cryptographically unverified jars off the web and stuff them into production code with very little testing (you aren't going to tell me you thoroughly tested each of the jars that your latest dependency pulled in through Maven). That's zealotry at its best. Perhaps if the java community (or should I call it a committee?) was willing to admit that Java has severe deficiencies, it would improve faster? I know it's far easier to just rip on Microsoft while writing yet another web or IoC framework that no one will ever use.
You can (and should) check in the C++ compiler separately from Visual Studio. It's a free download from Microsoft -- no reason not to check it in. You should also check in any other compilers and interpreters you use. If you use MSBuild or make on Windows platform to build your code, you should check it in as well. The beauty of MSBuild is that it can take VS project files and build stuff without needing Visual Studio.
You're missing out on guaranteed versions of binaries in your build, side by side deployment of different versions if your dependencies need them.
I was shocked when I found out that in Java world if library A requires version x of library B, and library C, which in turn requires version y of library B, a Java developer will pick some version of library B at random and pray it works with both A and C.
For most folks, compiler and tools are not checked in and versioned (even though they can be, in most cases), so there's no guarantee that your crap will even build two years down the road when you roll back to an earlier revision to fix an issue your customer is having with an older version.
Furthermore, folks who use Maven rely on unsigned components pulled from random places on the web, and components can be silently updated, compromised or removed.
I could go on and on. Java devs are sloppy with their dependencies and tooling, and it's no fault of their own -- it's just that their platform is brain dead and outdated..NET had side-by-side deployments and signed assemblies in _2001_.
Also, looking down the thread, you seem to imply that I work on Microsoft products. I don't. I left Microsoft quite a while ago. These days it's mostly C++ and Python. Couldn't bring myself to code Java, sorry.
The real reason why they don't use Visual Studio is far more prosaic -- the build environment of most of Microsoft products does not support the Visual Studio project files. Their products are built using a system called CoreXT -- basically a set of binary tools and scripts cobbled together by build engineers and developers over the past decade or so. CoreXT uses a lot of different crap, make, perl, compilers, etc, etc., and all tools and SDKs are checked in and versioned. The upside is that you can roll back your Source Depot (Microsoft's own flavor of Perforce) enlistment to an earlier date and be sure things will build exactly the same way, and once you enlist, you get repeatable, isolated build environment where you can guarantee the correctness of versions for all tools, compilers and libraries (Java developer's wet dream, even though they don't know it). The downside is that you have to maintain the makefiles by hand, and you can't use Visual Studio, because there are no project files checked in, and even if there are, most people don't use them and they are not updated, so you can count on them being broken.
I did a lot of my coding in either Notepad2, or in a separate project in Visual Studio against a test harness emulating the rest of the project (what Enterprise Java types call a "mock"). Some folks used Ultra Edit or vi, or EMACS. For some just a bare Notepad did the trick. Some stuck with Visual Studio, which in their case was just a glorified Notepad with autoindent since it doesn't support build or Intellisense if you don't have a project file.
Yes, it's an enormous waste of time, and yes, it was painful. But CoreXT is so integrated into the rest of the dev pipeline that replacing it with something else in a large product is a major, destabilizing endeavor that is bound to undo at least some of the work around gated check-in infrastructure, test infrastructure, automated deployment infrastructure and god knows what else, so few teams ever attempt it. Now naturally, DevDiv eats their own dogfood, so they were one of the first teams to switch completely to MSBuild. It took something like a year in their case, they did it gradually, from the leaves down the tree. I'm sure if they had a choice, they would be using CoreXT to this day though, and fighting with incremental build issues.:-)
Recently, a few more teams have adopted MSBuild. They can actually open their entire projects in Visual Studio and rebuild them. If they have test infrastructure deployed on the side, some of them can even test the product without waiting for it to deploy. So I predict that as more and more teams adopt MSBuild (this in itself could take another decade easily), these "senior" folks will come around to appreciate its benefits. It's awfully handy when you can set a conditional breakpoint on your local box and step through things.
>> Why won't Microsoft invest time and energy making IE html5 compliant
Looks like they will bring it closer to compliance in IE9.
Silverlight exists because HTML5 and Flash suck ass as a development platform if you want to develop desktop-class applications and deploy them over the web. I'm sorry, that's just a fact of life. Just look at Google Docs. It will never be full fidelity until it is rebuilt on top of the platform actually designed to run applications, not just display content.
Sun had a tremendous lead with Java, but somehow they managed to fuck up every single thing they needed to do to succeed. Microsoft fucked up the first three versions already, as they typically do, now with version 4 coming out I expect a good product, and good tooling around the SDK to go with it.
The only shitty bit about Silverlight from technological standpoint is that it relies on XAML. If there ever was an idea that deserved to be strangled in its infancy, that would be XAML. Other than that, SL provides a high performance (faster than Java, not to mention Javascript, and with lower memory footprint), garbage collected runtime, a contemporary object-oriented language (with functional bits tastily thrown in over the past couple of years), GPU accelerated media decoding and drawing, etc, etc.
If Google released something like this, everyone would be shitting their pants in ecstasy. Think about it, in SL there's NOTHING preventing you from building a full-fidelity equivalent of Word or Excel, for example. Anything you can do in managed code on the desktop (and that's a heck of a lot), you can do in Silverlight just as well. And it will run on both PC and Mac.
Instead, everyone will continue hacking browsers into submission ad nauseam. I've spent years of my life doing just that, and I want those years back.
This is my message to F-Spot developers: do some fucking usability tests, and then get an actual UI designer and have him address the issues. Or if you can't, just rip off the iPhoto UI wholesale. "Real" users get lost in the current F-Spot within 15 seconds. Its UI for _browsing_ the pictures sucks, it's import functionality is confusing, and its editing is both confusing and inadequate. Yes, I know the proverb about the teeth of the gift horse, but if we're picking based on merit here, let's recognize that currently there's no good choice.
How much you get paid depends on your reputation. And a good school (+a good GPA) gives you a head start on that, since the assumption is that if you showed good academic performance you, at the very least, won't be as dumb as a door knob.
The degree ceases to matter about 2-3 years into your career if you do a good job. Thing is, those with a degree get further ahead and build stronger reputation. 10 years in you look at your code and scratch your forehead wondering: "It looks about as good as 10 years ago, why the heck am I paid 3-4 times as much?" And the answer is, experience and reputation. Businesses will pay dearly for a good track record.
This is not to say that reputation is the only benefit that you get from school. In anything but the most mundane of work you will need to know quite a bit from those CS classes you've taken. If you're finding yourself not needing anything at all from your educational background, then perhaps you should try to advance in your career and do things a brain damaged monkey in Elbonia can't do.
One thing to mention here is if you join Microsoft itself (as opposed to its research arm - Microsoft Research), you won't ever get to work on any of the cool stuff. And if you join MSR, the shit you work on will never ship. So it's a lose-lose, no matter where you go, unless you're a researcher and publishing papers gives you a boner.
Both on the server and on the desktop. Actually, I threw away VMWare ESXi 4.0.0 I was testing on one of my non-production machines. At this point KVM is more stable with my set of guests, and easier to manage too (doesn't need Windows to run management tools). VMWare would hang the host when running FreeBSD 8 sometimes. Not acceptable.
As a matter of fact, I'm posting this from Karmic. If you can't tolerate a little roughness around the edges, wait for a month or two. Heck, even with Windows you have to wait for an SP1.
Virtualize. If you're anything like me, you have a public web server, a NAS, and a development Linux box. Now obviously you don't want your public web server having any access to your NAS, and you don't want your dev box to be able to screw up either. At the same time, you don't want to have three separate boxes, either. So what do you do? You get a fairly low-end dual core AMD box with lots of RAM (do yourself a favor - get ECC ram, on AMD it doesn't cost that much extra), download and install VMWare ESXi, and run all three machines on one set of hardware. Your idle power draw will be at around 40 watts or so, more than that if you stuff half a dozen hard drives in it (for the thick, juicy, FreeBSD based ZFS NAS), but still WAY less than the power draw of three separate machines. And you don't have to recompile and install everything by hand. And if you need another box, spontaneously, you can just provision yet another VM.
>> Microsoft can really change things around if they decided to port Win7 to ARM
Heard it through the grapevine that this is EXACTLY what they're doing, albeit not in a context you mentioned. A subset of full blown Windows kernel is being ported to ARM (a-la iPhone Mach) as a foundation for their "next" next gen mobile OS.
I guess they just don't want shitty homemade LPs to screw up the LP "brand". At least not initially. And $10K is really not that much for world class design work. I'd be surprised if a "real" LP (with artwork, etc) costs any less than that for a reasonable number of copies.
>> In a nuclear war, America is the only state >> capable of defeating China or Russia.
In a nuclear war the US can't defeat any other nation which has ICBMs of sufficient range, or has a neighbor which has ICBMs of sufficient range. Once US ICBMs are anywhere close to Russian airspace (which means they could be striking China, for all they know), Russia will fire back with all its might, including mobile launch platforms roaming the tundra and nuclear subs patrolling the East Coast of the US.
Under this scenario, both the East and West coast will be completely destroyed. I wouldn't call that a "victory".
I would suggest that the "world leaders" "band together" against Israel, which:
a. Has nuclear weapons b. Is not a party to the non-proliferation treaty c. Has the means of delivery of said nuclear weapons d. Does not allow IAEA inspectors e. Is extremely aggressive
Compared to Israel, Iran is in kindergarten. If you're going to apply sanctions to Iran, get rid of the double standard and apply them uniformly to Israel as well.
And their entire office was upgraded to Office 2007 in a couple of months after it came out. They were ecstatic about it, too, since features that were previously hidden in the menus were now right there, intuitively laid out and ready to be used.
Me? I couldn't care less about 2007, but I think whoever came up with the idea and pushed it through has an enormous pair of balls. This is the best innovation that's come out of Microsoft in a LONG while.
This was a new product, in a new (for Microsoft) market. We were starting from zero marketshare against firmly entrenched competitors. It took that product about five years to even start breaking even and now it brings in a healthy profit.
People at MSFT by and large try really hard to put out the best product they can. Unfortunately, in a company the size of Microsoft it's not as straightforward as it perhaps should be. If you work on a product that's already shipped a few versions, you end up having to convince too many people to get anything changed, so unless something is truly horribly broken people tend to pick their fights and argue for the cases where have a greater probability of success.
Fortunately, this is not an issue with new, v1 products, since you're building from the ground up. Hence, in our case, we've made fairly dramatic changes as we went along.
They basically have labs with one-way mirror. User is left alone in a sound-proof room and given a set of tasks to perform. Everything is recorded (including facial expressions and sound), and any developer can take a look at the test either from the adjacent room or from his/her workstation (using Windows Media Player). The only input the user gets is when he gets so confused he can't accomplish the task from the list. In which case the person conducting the test just says "next task" and that's it.
The experience is really humbling. You just realize that people out there are FAR, FAR less experienced with computers than you thought, and even working their email client is a challenge for most.
You make your assumptions on the basis of what's convenient for you. Guess what, people out there are not you, and what's good for you is torture for them (the inverse is often true, too).
We ended up redesigning the entire chunks of the UI sometimes, some features got cut, some scenarios overhauled. And in the end we still didn't do enough of usability testing (IMO), but such is life in commercial software development - you work against an arbitrary schedule.
HP is releasing a Core i7 based laptop in mid-October. Apple is known for getting new Intel processors sooner than anybody else, so I do expect an announcement in the next three weeks, and it will include the phrase "shipping NOW".
Water heater consumes the most energy in most households. I'm pretty sure it's possible to make it more efficient than it currently is. Same goes for electric heating and air conditioning.
Slashdot Mirror
I'd rather they fixed Windows guest support. I've tried it (in Ubuntu Karmic), and it's horrible if you want to run Windows in it (both XP and Win7). Very slow, timer lags behind, network and disk throughput are super slow even with virtio guest drivers. Linux runs fine as a guest on the same box.
I guess it's unfair to _demand_ anything if something cost you zero dollars (gifted horse thing and all), but VMWare ESX and HyperV Server also cost zero dollars these days, and they both run Windows just fine.
Well, for all practical purposes in most (99%) of Java dev teams, it is impossible to rebuild a version from 2 years ago an be sure it's exactly the same (modulo the fixes). No one uses versioning for tools, jre and and jars. Everyone uses Maven and pulls the deps either directly from maven repos on the web, or set up Nexus, which is not versioned either. In addition, folks see nothing wrong in deploying their code on a newer (or just plain different) version of a JRE. They just cross their fingers and hope it will work somehow. I know it for a fact that OpenJDK, for instance, doesn't even run Netbeans properly.
You may be doing things differently, but you're the exception rather than the rule.
>> Java jars are designed for backward compatibility
>> so grabbing the latest one is safe
Heard that tune MANY times. The simple fact is, YOU DON'T KNOW THIS. That's precisely my point. Some Joe Sixpack changes calling semantics of a function on a whim and you end up with hairy issues in production, because a function, for instance, throws the kind of exception you don't catch further up the stack.
It will be another three or four years until OSGI becomes mainstream. By then .NET will have had cryptographically verified side-by-side deployment of code for well over a decade.
Apparently you don't understand what "jar hell" means. Let me really break it down for you.
Let's say you use foo.jar, which relies on a concrete version of log4j.jar. Let's also say foo.jar requires bar.jar, which in turn requires a different version of log4j.jar.
In .NET you deploy two different assemblies side by side and they coexist peacefully.
In Java you're fucked. Now, there are OSGI bundles now, but their use is far from widespread. This means that Java developers have no fucking clue whether jars in their their extensive dependency hierarchies are even fully compatible. :-)
And you need to build and deploy crap by hand, and then attach the debugger, tell it where the sources are, etc.
Sure, WinDbg is a viable option, but far from a convenient one. Some folks at MSFT use Rascal as well - an xcopy-able custom build of VS2005 debugger.
Those local Maven repos are not versioned within the source control system, and therefore are unreliable. And checking in only jars is insufficient - in order for things to be 100% repeatable and isolated, you need to check in all your tooling, jdk and compilers as well, and make sure the developers launch a separate bash session which makes sure you're using only the tools in the enlistment, and not the ones installed locally on the box. No one does this.
I like how you avoided the jar hell issue and the issue where people grab cryptographically unverified jars off the web and stuff them into production code with very little testing (you aren't going to tell me you thoroughly tested each of the jars that your latest dependency pulled in through Maven). That's zealotry at its best. Perhaps if the java community (or should I call it a committee?) was willing to admit that Java has severe deficiencies, it would improve faster? I know it's far easier to just rip on Microsoft while writing yet another web or IoC framework that no one will ever use.
You can (and should) check in the C++ compiler separately from Visual Studio. It's a free download from Microsoft -- no reason not to check it in. You should also check in any other compilers and interpreters you use. If you use MSBuild or make on Windows platform to build your code, you should check it in as well. The beauty of MSBuild is that it can take VS project files and build stuff without needing Visual Studio.
You're missing out on guaranteed versions of binaries in your build, side by side deployment of different versions if your dependencies need them.
I was shocked when I found out that in Java world if library A requires version x of library B, and library C, which in turn requires version y of library B, a Java developer will pick some version of library B at random and pray it works with both A and C.
For most folks, compiler and tools are not checked in and versioned (even though they can be, in most cases), so there's no guarantee that your crap will even build two years down the road when you roll back to an earlier revision to fix an issue your customer is having with an older version.
Furthermore, folks who use Maven rely on unsigned components pulled from random places on the web, and components can be silently updated, compromised or removed.
I could go on and on. Java devs are sloppy with their dependencies and tooling, and it's no fault of their own -- it's just that their platform is brain dead and outdated. .NET had side-by-side deployments and signed assemblies in _2001_.
Also, looking down the thread, you seem to imply that I work on Microsoft products. I don't. I left Microsoft quite a while ago. These days it's mostly C++ and Python. Couldn't bring myself to code Java, sorry.
The real reason why they don't use Visual Studio is far more prosaic -- the build environment of most of Microsoft products does not support the Visual Studio project files. Their products are built using a system called CoreXT -- basically a set of binary tools and scripts cobbled together by build engineers and developers over the past decade or so. CoreXT uses a lot of different crap, make, perl, compilers, etc, etc., and all tools and SDKs are checked in and versioned. The upside is that you can roll back your Source Depot (Microsoft's own flavor of Perforce) enlistment to an earlier date and be sure things will build exactly the same way, and once you enlist, you get repeatable, isolated build environment where you can guarantee the correctness of versions for all tools, compilers and libraries (Java developer's wet dream, even though they don't know it). The downside is that you have to maintain the makefiles by hand, and you can't use Visual Studio, because there are no project files checked in, and even if there are, most people don't use them and they are not updated, so you can count on them being broken.
I did a lot of my coding in either Notepad2, or in a separate project in Visual Studio against a test harness emulating the rest of the project (what Enterprise Java types call a "mock"). Some folks used Ultra Edit or vi, or EMACS. For some just a bare Notepad did the trick. Some stuck with Visual Studio, which in their case was just a glorified Notepad with autoindent since it doesn't support build or Intellisense if you don't have a project file.
Yes, it's an enormous waste of time, and yes, it was painful. But CoreXT is so integrated into the rest of the dev pipeline that replacing it with something else in a large product is a major, destabilizing endeavor that is bound to undo at least some of the work around gated check-in infrastructure, test infrastructure, automated deployment infrastructure and god knows what else, so few teams ever attempt it. Now naturally, DevDiv eats their own dogfood, so they were one of the first teams to switch completely to MSBuild. It took something like a year in their case, they did it gradually, from the leaves down the tree. I'm sure if they had a choice, they would be using CoreXT to this day though, and fighting with incremental build issues. :-)
Recently, a few more teams have adopted MSBuild. They can actually open their entire projects in Visual Studio and rebuild them. If they have test infrastructure deployed on the side, some of them can even test the product without waiting for it to deploy. So I predict that as more and more teams adopt MSBuild (this in itself could take another decade easily), these "senior" folks will come around to appreciate its benefits. It's awfully handy when you can set a conditional breakpoint on your local box and step through things.
>> Why won't Microsoft invest time and energy making IE html5 compliant
Looks like they will bring it closer to compliance in IE9.
Silverlight exists because HTML5 and Flash suck ass as a development platform if you want to develop desktop-class applications and deploy them over the web. I'm sorry, that's just a fact of life. Just look at Google Docs. It will never be full fidelity until it is rebuilt on top of the platform actually designed to run applications, not just display content.
Sun had a tremendous lead with Java, but somehow they managed to fuck up every single thing they needed to do to succeed. Microsoft fucked up the first three versions already, as they typically do, now with version 4 coming out I expect a good product, and good tooling around the SDK to go with it.
The only shitty bit about Silverlight from technological standpoint is that it relies on XAML. If there ever was an idea that deserved to be strangled in its infancy, that would be XAML. Other than that, SL provides a high performance (faster than Java, not to mention Javascript, and with lower memory footprint), garbage collected runtime, a contemporary object-oriented language (with functional bits tastily thrown in over the past couple of years), GPU accelerated media decoding and drawing, etc, etc.
If Google released something like this, everyone would be shitting their pants in ecstasy. Think about it, in SL there's NOTHING preventing you from building a full-fidelity equivalent of Word or Excel, for example. Anything you can do in managed code on the desktop (and that's a heck of a lot), you can do in Silverlight just as well. And it will run on both PC and Mac.
Instead, everyone will continue hacking browsers into submission ad nauseam. I've spent years of my life doing just that, and I want those years back.
This is my message to F-Spot developers: do some fucking usability tests, and then get an actual UI designer and have him address the issues. Or if you can't, just rip off the iPhoto UI wholesale. "Real" users get lost in the current F-Spot within 15 seconds. Its UI for _browsing_ the pictures sucks, it's import functionality is confusing, and its editing is both confusing and inadequate. Yes, I know the proverb about the teeth of the gift horse, but if we're picking based on merit here, let's recognize that currently there's no good choice.
How much you get paid depends on your reputation. And a good school (+a good GPA) gives you a head start on that, since the assumption is that if you showed good academic performance you, at the very least, won't be as dumb as a door knob.
The degree ceases to matter about 2-3 years into your career if you do a good job. Thing is, those with a degree get further ahead and build stronger reputation. 10 years in you look at your code and scratch your forehead wondering: "It looks about as good as 10 years ago, why the heck am I paid 3-4 times as much?" And the answer is, experience and reputation. Businesses will pay dearly for a good track record.
This is not to say that reputation is the only benefit that you get from school. In anything but the most mundane of work you will need to know quite a bit from those CS classes you've taken. If you're finding yourself not needing anything at all from your educational background, then perhaps you should try to advance in your career and do things a brain damaged monkey in Elbonia can't do.
I'm pretty sure that if I just yank the cable, not everything will be replicated. :-)
One thing to mention here is if you join Microsoft itself (as opposed to its research arm - Microsoft Research), you won't ever get to work on any of the cool stuff. And if you join MSR, the shit you work on will never ship. So it's a lose-lose, no matter where you go, unless you're a researcher and publishing papers gives you a boner.
And Ruby, PHP and Perl. Check it out for yourselves: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=python&box=1
Both on the server and on the desktop. Actually, I threw away VMWare ESXi 4.0.0 I was testing on one of my non-production machines. At this point KVM is more stable with my set of guests, and easier to manage too (doesn't need Windows to run management tools). VMWare would hang the host when running FreeBSD 8 sometimes. Not acceptable.
As a matter of fact, I'm posting this from Karmic. If you can't tolerate a little roughness around the edges, wait for a month or two. Heck, even with Windows you have to wait for an SP1.
Virtualize. If you're anything like me, you have a public web server, a NAS, and a development Linux box. Now obviously you don't want your public web server having any access to your NAS, and you don't want your dev box to be able to screw up either. At the same time, you don't want to have three separate boxes, either. So what do you do? You get a fairly low-end dual core AMD box with lots of RAM (do yourself a favor - get ECC ram, on AMD it doesn't cost that much extra), download and install VMWare ESXi, and run all three machines on one set of hardware. Your idle power draw will be at around 40 watts or so, more than that if you stuff half a dozen hard drives in it (for the thick, juicy, FreeBSD based ZFS NAS), but still WAY less than the power draw of three separate machines. And you don't have to recompile and install everything by hand. And if you need another box, spontaneously, you can just provision yet another VM.
>> Microsoft can really change things around if they decided to port Win7 to ARM
Heard it through the grapevine that this is EXACTLY what they're doing, albeit not in a context you mentioned. A subset of full blown Windows kernel is being ported to ARM (a-la iPhone Mach) as a foundation for their "next" next gen mobile OS.
I guess they just don't want shitty homemade LPs to screw up the LP "brand". At least not initially. And $10K is really not that much for world class design work. I'd be surprised if a "real" LP (with artwork, etc) costs any less than that for a reasonable number of copies.
>> In a nuclear war, America is the only state
>> capable of defeating China or Russia.
In a nuclear war the US can't defeat any other nation which has ICBMs of sufficient range, or has a neighbor which has ICBMs of sufficient range. Once US ICBMs are anywhere close to Russian airspace (which means they could be striking China, for all they know), Russia will fire back with all its might, including mobile launch platforms roaming the tundra and nuclear subs patrolling the East Coast of the US.
Under this scenario, both the East and West coast will be completely destroyed. I wouldn't call that a "victory".
I would suggest that the "world leaders" "band together" against Israel, which:
a. Has nuclear weapons
b. Is not a party to the non-proliferation treaty
c. Has the means of delivery of said nuclear weapons
d. Does not allow IAEA inspectors
e. Is extremely aggressive
Compared to Israel, Iran is in kindergarten. If you're going to apply sanctions to Iran, get rid of the double standard and apply them uniformly to Israel as well.
And their entire office was upgraded to Office 2007 in a couple of months after it came out. They were ecstatic about it, too, since features that were previously hidden in the menus were now right there, intuitively laid out and ready to be used.
Me? I couldn't care less about 2007, but I think whoever came up with the idea and pushed it through has an enormous pair of balls. This is the best innovation that's come out of Microsoft in a LONG while.
This was a new product, in a new (for Microsoft) market. We were starting from zero marketshare against firmly entrenched competitors. It took that product about five years to even start breaking even and now it brings in a healthy profit.
People at MSFT by and large try really hard to put out the best product they can. Unfortunately, in a company the size of Microsoft it's not as straightforward as it perhaps should be. If you work on a product that's already shipped a few versions, you end up having to convince too many people to get anything changed, so unless something is truly horribly broken people tend to pick their fights and argue for the cases where have a greater probability of success.
Fortunately, this is not an issue with new, v1 products, since you're building from the ground up. Hence, in our case, we've made fairly dramatic changes as we went along.
... as a developer.
They basically have labs with one-way mirror. User is left alone in a sound-proof room and given a set of tasks to perform. Everything is recorded (including facial expressions and sound), and any developer can take a look at the test either from the adjacent room or from his/her workstation (using Windows Media Player). The only input the user gets is when he gets so confused he can't accomplish the task from the list. In which case the person conducting the test just says "next task" and that's it.
The experience is really humbling. You just realize that people out there are FAR, FAR less experienced with computers than you thought, and even working their email client is a challenge for most.
You make your assumptions on the basis of what's convenient for you. Guess what, people out there are not you, and what's good for you is torture for them (the inverse is often true, too).
We ended up redesigning the entire chunks of the UI sometimes, some features got cut, some scenarios overhauled. And in the end we still didn't do enough of usability testing (IMO), but such is life in commercial software development - you work against an arbitrary schedule.
HP is releasing a Core i7 based laptop in mid-October. Apple is known for getting new Intel processors sooner than anybody else, so I do expect an announcement in the next three weeks, and it will include the phrase "shipping NOW".
Water heater consumes the most energy in most households. I'm pretty sure it's possible to make it more efficient than it currently is. Same goes for electric heating and air conditioning.