Microsoft's embrace and extend isn't what stopped Java GUI apps from becoming popular. I'm no big fan of Microsoft, but Java's failure on the desktop really has nothing to do with Microsoft and everything to do with Java.
I don't have a problem with Mono. Nobody is shutting down OpenOffice or Google Docs for interoperability with Microsoft Office proprietary file formats. Nobody is shutting down MingW for compiling code that runs on Windows. Nobody is shutting down Wine for building a Windows API layer. Nobody is shutting down Zimbra and Open Xchange for providing compatible features from Microsoft Exchange. The Samba is even working (finished??) on full interoperability with Microsoft Active Directory.
I ignore Mono because I see no reason to tackle C#'s learning curve when I'm comfortably employed as a Java developer. If I want some of the C# and F# features Java doesn't have, I'll use Scala. But I don't see any problems with using Mono.
But Java has been around for years, most PC vendors have shipped their products with the Java Runtime Environment (JRE) pre-installed, and many Linux distributions install the JRE by default or make it an easy option. It all predated.NET by a long period. Java Web Start, Sun's idea for easy web distribution of digitally signed Java applications with fine-grained security, also predates.NET.
Java desktop applications had plenty of time to gain marketplace momentum, the infrastructure and development tools have been free, and the PC vendors sold desktops and laptops with the JVM pre-installed. It still never took off. As PCs get more powerful, Java GUI themes get much more pretty, the JVM continues to get more efficient and lean, Java is moving into a position where it is the technical equal (and source code license superior) of the.NET framework for desktop apps. But the damage is done, the window of opportunity is closed.
Also, I think the term 'folder' in meatspace generally implies no nesting. People don't usually take a blue folder and stuff four red folders into it, and three green folders into one of the red folders, and so forth.
I suspect Google is making the device 'web-only' on purpose, so that users don't link problems they have with a particular GNOME, OpenOffice, media encoder, or application installed on Wine with Google. By using a custom windowing engine instead of X, even if they open source it, they have far more control over applications.
In a few years, if Google OS takes off, then third party applications to run on their windowing engine will start appearing. But they can cross that bridge when they reach it.
The Google press release pretty explicitly states that Google Chrome OS will start at netbooks and expand from there. I can easily see success at netbooks, for the reason you describe.
But if someone is willing to pay $800 for a mid level desktop PC or $1200 for a mid level laptop, the computer will be able to do photo editing, video editing, and gaming on a level that no browser-based application will supply. I just don't see Google OS making much inroads into that market.
Going from a procedural language to a procedural language with functional options is relatively easy. That's cases like C++ to C#, or even older versions of C# to LINQ. It's also true with Java and Scala. Going from a procedural language to a purely functional language like Haskell is far more difficult. I'm a mediocre C and C++ developer and a passable Java developer, and it's taking me a lot of work to learn Haskell. It seems worthwhile, but I can understand why Haskell hasn't taken the software industry by storm.
The London Stock Exchange example is useless. Yes, it ran Windows Server and an application coded in.NET. Yes, it crashed. But no one can prove whether the problem was the operating system, the database, the.NET platform, or buggy code.
It's my understanding that C# is more popular than Java for desktop applications because of faster startup and lower memory use. I can't imagine many companies would decide to move to C# from Java for server applications for anything more than political reasons.
Frankly, I still expect Google OS to become at best a tiny portion of the PC market. But that said, they have enormous advantages over other Linux desktop distributions: 1. Name recognition - favorable name recognition - from the average computer user. 2. Massive funding available for QA, pretty graphics, detailed documentation, and so forth. These days Ubuntu and OpenSuse, among others, are damn good, but Google has the resources to do even better. 3. Massive funding available for advertising. 4. The ability to sell machines to end-users with their distribution pre-installed. This has happened before with Linux in small numbers, but even at its peak it was tiny numbers and little attention. This will be available and widely known.
But even with all those advantages, I expect the three way combination of Microsoft FUD, Microsoft genuine attempts to compete by improving their products, and consumer comfort with Microsoft will still leave Redmond controlling more than 90% of the PC market.
All Linux distributions have a Linux kernel, by definition. Most have X. But there's a decent number that skip without KDE and GNOME. There are at least half a dozen competent window managers that are not nearly as feature-rich as KDE or GNOME but great for running on hardware that would choke on the more resource-intensive pair.
I don't mean to denigrate the hard work done by the KDE and GNOME teams. They were decent a decade ago and are excellent today. But one of the territories where Microsoft's grip is weak is cheaper hardware. I think it's intelligent for Google's OS to tackle this first. I also think it's a place where KDE and GNOME have the least to offer.
Most of the calories burned by muscle are burned because of your workouts. There's a myth floating around that each pound of lean muscle mass burns 50 or more calories per day at rest. The real number is closer to 6: http://www.thefactsaboutfitness.com/news/cals.htm
Speaking as a guy with a herniated disk in his lower back, unless you're in your mid 20s or younger, you should always include abdominal and back exercises in your workout routine.
Obviously, if your stomach is fat, you won't see any visible results. But if your stomach is fat, that's when you need strength in your lower back and abdominal muscles the most. I ignored abs and lower back in favor of leg and arm exercises, and what I thought was leg cramps from enthusiastic workouts was actually nerve problems from a slipped disk.
10 years ago: Kid: "Hi, I want a job writing software!" Manager: "Tell me what you know about writing software." Kid: "I saw some C++ code in a textbook once!" Manager: "Will you accept $80,000 and start tomorrow?"
Today: Applicant: "Hi, I want a job writing software!" Manager: "Tell me what you know about writing software." Applicant: "I have a bachelor of science degree in math with a minor in computer science. I've written 10,000 lines of code in widespread use in an open source project. I've written my own cell phone operating system. I've written 4 applications in the iPhone store. I'm a contributor on the specifications for C++0x." Manager: "We're sorry, you are woefully underqualified for this junior position. We're looking for someone with ten times as much experience and a master's degree, and we will offer them $35,000 per year."
I'm genuinely happy for you and your success. But I'm guessing you got your start during the dot com boom or something similar. I love developing software, I can't believe I get paid money to do something this interesting. But the opportunities for a self taught person to break in to the industry, as far as I can tell, are tremendously fewer now than in the past.
So unless gbarules2999 has a computer that can barely run Fedora 10 or (for example) OpenSUSE 11 at all, ESXi might let him run a new version in a VM with acceptable performance.
You're making an extremely solid argument for good virtualization, backups, and failover with redeployment.
You're making a far weaker argument for a proprietary solution that does those things. If some or all of your environments require Windows, then obviously you need a proprietary solution. But properly configured, backups, VMs, and fast switching between different setups in BSD jails, Xen, KVM (Linux Kernel-based Virtual Machine, not Keyboard-Video-Mouse switching), and other options give you the same flexibility. And a competent developer/admin can set them up for less than $15-$20k.
It's perfectly possible to have a system with a thin, locally hosted GUI and a much larger server backend.
But your thin, locally hosted GUI must be installed, and therein lies the headache. And that's what I meant by fat client - some portion of the software must be installed outside of a web browser.
Again, I'm not arguing that websites are mostly better than installed local applications. I'm just arguing that there's a broad class of applications where the advantages of websites outweigh the weaknesses.
All through college, I was taught that CPU cycles are cheaper than developer man-hours. And clearly, computers are far cheaper today relative to the cost of a good developer than 30 or 40 years ago.
But look at the world today. We have software running in VMs, software on cell phones, all sorts of embedded devices, and netbook PCs with relatively anemic resources. Our workstations have dozens of services and background processes running. And in terms of server applications, you also have to consider that one fast application running on one server saves you a lot of configuration, concurrency, and backup headaches compared to clustered applications on multiple servers.
Efficient code still matters quite a bit. It's not the end-all-be-all like it was in the infancy of computing. But it's not something you can ignore either.
Perl became popular because all of its syntactic shortcuts and builtin language features permitted extremely rapid development. It's the anti-C: often 10 times faster to write, almost always 100 times slower to execute. When that tradeoff makes sense, it was very suitable. Since then, you can argue that Python and Ruby have taken all of the best ideas of Perl and left behind the ones that made it too easy to write unreadable code. But Perl is still a very useful, usable language - especially when you follow recommended convention.
And "Java was" nothing. Love it or hate it, Java is the biggest programming language in the job market today or very close to it. It might be growing at a reduced rate or maybe even shrinking slowly, but we're easily a decade away from seeing it become uncommon. It's not touted much for the desktop, but the language is good enough for server application purposes.
The problem with fat client software is not that it's equal or inferior to a well-built website. It's definitely superior.
The problem is deployment and support. As much as Javascript is a pain, non-standard HTML support in IE is a pain, and a million other headaches come with a website, in many ways it's far less headache than supporting a.msi/tar.gz/.deb/.rpm installer and getting tech support calls that have nothing to do with your application.
There's certainly a wide range of applications that will always remain fat client only. But the terminal-server model makes a lot of sense from the support perspective for many applications.
I don't know. I'm involved in two expensive legal battles to get insurance coverage for things that should have been covered, and there's one other legal battle I dropped just because the cost of the legal fees didn't equal out to covering the fucking expense out of pocket.
I understand intellectually that insurance companies exist to make a profit, and I'm still extremely civil with correspondence and phone conversations. But at a gut level, I hate the motherfuckers with a passion.
Thanks for the correction. We use ye olde Struts 1.x (an older Java web application framework) and I hadn't realized Spring MVC/WebFlow is not often used with the rest of Spring.
I wouldn't say all of the MVC frameworks are identical. The fundamental concept of MVC doesn't change, but trying building a site from start to finish with Struts 1.x (which REALLY shows its age these days) and many of the newer alternatives, and the differences pop up early and often.
Slashdot Mirror
Microsoft's embrace and extend isn't what stopped Java GUI apps from becoming popular. I'm no big fan of Microsoft, but Java's failure on the desktop really has nothing to do with Microsoft and everything to do with Java.
I don't have a problem with Mono. Nobody is shutting down OpenOffice or Google Docs for interoperability with Microsoft Office proprietary file formats. Nobody is shutting down MingW for compiling code that runs on Windows. Nobody is shutting down Wine for building a Windows API layer. Nobody is shutting down Zimbra and Open Xchange for providing compatible features from Microsoft Exchange. The Samba is even working (finished??) on full interoperability with Microsoft Active Directory.
I ignore Mono because I see no reason to tackle C#'s learning curve when I'm comfortably employed as a Java developer. If I want some of the C# and F# features Java doesn't have, I'll use Scala. But I don't see any problems with using Mono.
I think those are accurate points.
.NET by a long period. Java Web Start, Sun's idea for easy web distribution of digitally signed Java applications with fine-grained security, also predates .NET.
.NET framework for desktop apps. But the damage is done, the window of opportunity is closed.
But Java has been around for years, most PC vendors have shipped their products with the Java Runtime Environment (JRE) pre-installed, and many Linux distributions install the JRE by default or make it an easy option. It all predated
Java desktop applications had plenty of time to gain marketplace momentum, the infrastructure and development tools have been free, and the PC vendors sold desktops and laptops with the JVM pre-installed. It still never took off. As PCs get more powerful, Java GUI themes get much more pretty, the JVM continues to get more efficient and lean, Java is moving into a position where it is the technical equal (and source code license superior) of the
Also, I think the term 'folder' in meatspace generally implies no nesting. People don't usually take a blue folder and stuff four red folders into it, and three green folders into one of the red folders, and so forth.
Is C typed? I thought C was "cast it however you want and go".
I suspect Google is making the device 'web-only' on purpose, so that users don't link problems they have with a particular GNOME, OpenOffice, media encoder, or application installed on Wine with Google. By using a custom windowing engine instead of X, even if they open source it, they have far more control over applications.
In a few years, if Google OS takes off, then third party applications to run on their windowing engine will start appearing. But they can cross that bridge when they reach it.
The Google press release pretty explicitly states that Google Chrome OS will start at netbooks and expand from there. I can easily see success at netbooks, for the reason you describe.
But if someone is willing to pay $800 for a mid level desktop PC or $1200 for a mid level laptop, the computer will be able to do photo editing, video editing, and gaming on a level that no browser-based application will supply. I just don't see Google OS making much inroads into that market.
Scala is available for .NET too (http://www.scala-lang.org/node/25 - bottom of page).
Going from a procedural language to a procedural language with functional options is relatively easy. That's cases like C++ to C#, or even older versions of C# to LINQ. It's also true with Java and Scala. Going from a procedural language to a purely functional language like Haskell is far more difficult. I'm a mediocre C and C++ developer and a passable Java developer, and it's taking me a lot of work to learn Haskell. It seems worthwhile, but I can understand why Haskell hasn't taken the software industry by storm.
The London Stock Exchange example is useless. Yes, it ran Windows Server and an application coded in .NET. Yes, it crashed. But no one can prove whether the problem was the operating system, the database, the .NET platform, or buggy code.
It's my understanding that C# is more popular than Java for desktop applications because of faster startup and lower memory use. I can't imagine many companies would decide to move to C# from Java for server applications for anything more than political reasons.
Most of the laptops people buy come from Compal (Dell, Toshiba, HP) http://en.wikipedia.org/wiki/Compal_Electronics and Quanta (Acer, Apple, Compaq, Dell again, Toshiba again, HP again, Lenovo, Sony) http://en.wikipedia.org/wiki/Quanta_Computers.
So don't get too caught up in which manufacturer is better. Pay attention to value for dollar and service (ha!), the hardware is shared.
Frankly, I still expect Google OS to become at best a tiny portion of the PC market. But that said, they have enormous advantages over other Linux desktop distributions: 1. Name recognition - favorable name recognition - from the average computer user. 2. Massive funding available for QA, pretty graphics, detailed documentation, and so forth. These days Ubuntu and OpenSuse, among others, are damn good, but Google has the resources to do even better. 3. Massive funding available for advertising. 4. The ability to sell machines to end-users with their distribution pre-installed. This has happened before with Linux in small numbers, but even at its peak it was tiny numbers and little attention. This will be available and widely known.
But even with all those advantages, I expect the three way combination of Microsoft FUD, Microsoft genuine attempts to compete by improving their products, and consumer comfort with Microsoft will still leave Redmond controlling more than 90% of the PC market.
Sounds great. Get to work.
All Linux distributions have a Linux kernel, by definition. Most have X. But there's a decent number that skip without KDE and GNOME. There are at least half a dozen competent window managers that are not nearly as feature-rich as KDE or GNOME but great for running on hardware that would choke on the more resource-intensive pair.
I don't mean to denigrate the hard work done by the KDE and GNOME teams. They were decent a decade ago and are excellent today. But one of the territories where Microsoft's grip is weak is cheaper hardware. I think it's intelligent for Google's OS to tackle this first. I also think it's a place where KDE and GNOME have the least to offer.
Most of the calories burned by muscle are burned because of your workouts. There's a myth floating around that each pound of lean muscle mass burns 50 or more calories per day at rest. The real number is closer to 6: http://www.thefactsaboutfitness.com/news/cals.htm
Speaking as a guy with a herniated disk in his lower back, unless you're in your mid 20s or younger, you should always include abdominal and back exercises in your workout routine.
Obviously, if your stomach is fat, you won't see any visible results. But if your stomach is fat, that's when you need strength in your lower back and abdominal muscles the most. I ignored abs and lower back in favor of leg and arm exercises, and what I thought was leg cramps from enthusiastic workouts was actually nerve problems from a slipped disk.
10 years ago:
Kid: "Hi, I want a job writing software!"
Manager: "Tell me what you know about writing software."
Kid: "I saw some C++ code in a textbook once!"
Manager: "Will you accept $80,000 and start tomorrow?"
Today:
Applicant: "Hi, I want a job writing software!"
Manager: "Tell me what you know about writing software."
Applicant: "I have a bachelor of science degree in math with a minor in computer science. I've written 10,000 lines of code in widespread use in an open source project. I've written my own cell phone operating system. I've written 4 applications in the iPhone store. I'm a contributor on the specifications for C++0x."
Manager: "We're sorry, you are woefully underqualified for this junior position. We're looking for someone with ten times as much experience and a master's degree, and we will offer them $35,000 per year."
I'm genuinely happy for you and your success. But I'm guessing you got your start during the dot com boom or something similar. I love developing software, I can't believe I get paid money to do something this interesting. But the opportunities for a self taught person to break in to the industry, as far as I can tell, are tremendously fewer now than in the past.
According to many comments in this Slashdot discussion: http://bsd.slashdot.org/story/09/06/02/0043258/When-VMware-Performance-Fails-Try-BSD-Jails the VMWare ESXi product has very low computer resource requirements.
So unless gbarules2999 has a computer that can barely run Fedora 10 or (for example) OpenSUSE 11 at all, ESXi might let him run a new version in a VM with acceptable performance.
You're making an extremely solid argument for good virtualization, backups, and failover with redeployment.
You're making a far weaker argument for a proprietary solution that does those things. If some or all of your environments require Windows, then obviously you need a proprietary solution. But properly configured, backups, VMs, and fast switching between different setups in BSD jails, Xen, KVM (Linux Kernel-based Virtual Machine, not Keyboard-Video-Mouse switching), and other options give you the same flexibility. And a competent developer/admin can set them up for less than $15-$20k.
It's perfectly possible to have a system with a thin, locally hosted GUI and a much larger server backend.
But your thin, locally hosted GUI must be installed, and therein lies the headache. And that's what I meant by fat client - some portion of the software must be installed outside of a web browser.
Again, I'm not arguing that websites are mostly better than installed local applications. I'm just arguing that there's a broad class of applications where the advantages of websites outweigh the weaknesses.
All through college, I was taught that CPU cycles are cheaper than developer man-hours. And clearly, computers are far cheaper today relative to the cost of a good developer than 30 or 40 years ago.
But look at the world today. We have software running in VMs, software on cell phones, all sorts of embedded devices, and netbook PCs with relatively anemic resources. Our workstations have dozens of services and background processes running. And in terms of server applications, you also have to consider that one fast application running on one server saves you a lot of configuration, concurrency, and backup headaches compared to clustered applications on multiple servers.
Efficient code still matters quite a bit. It's not the end-all-be-all like it was in the infancy of computing. But it's not something you can ignore either.
Perl became popular because all of its syntactic shortcuts and builtin language features permitted extremely rapid development. It's the anti-C: often 10 times faster to write, almost always 100 times slower to execute. When that tradeoff makes sense, it was very suitable. Since then, you can argue that Python and Ruby have taken all of the best ideas of Perl and left behind the ones that made it too easy to write unreadable code. But Perl is still a very useful, usable language - especially when you follow recommended convention.
And "Java was" nothing. Love it or hate it, Java is the biggest programming language in the job market today or very close to it. It might be growing at a reduced rate or maybe even shrinking slowly, but we're easily a decade away from seeing it become uncommon. It's not touted much for the desktop, but the language is good enough for server application purposes.
That's the point, though. There are some preliminary studies demonstrating that artificial sweeteners interfere with appetite regulation.
So maybe if that person was drinking water instead of diet soda, they wouldn't even want a quarter pounder.
I'm assuming that the Anonymous Coward was trying to make that joke and was just a little too subtle with it.
The problem with fat client software is not that it's equal or inferior to a well-built website. It's definitely superior.
.msi/tar.gz/.deb/.rpm installer and getting tech support calls that have nothing to do with your application.
The problem is deployment and support. As much as Javascript is a pain, non-standard HTML support in IE is a pain, and a million other headaches come with a website, in many ways it's far less headache than supporting a
There's certainly a wide range of applications that will always remain fat client only. But the terminal-server model makes a lot of sense from the support perspective for many applications.
I don't know. I'm involved in two expensive legal battles to get insurance coverage for things that should have been covered, and there's one other legal battle I dropped just because the cost of the legal fees didn't equal out to covering the fucking expense out of pocket.
I understand intellectually that insurance companies exist to make a profit, and I'm still extremely civil with correspondence and phone conversations. But at a gut level, I hate the motherfuckers with a passion.
Thanks for the correction. We use ye olde Struts 1.x (an older Java web application framework) and I hadn't realized Spring MVC/WebFlow is not often used with the rest of Spring.
I wouldn't say all of the MVC frameworks are identical. The fundamental concept of MVC doesn't change, but trying building a site from start to finish with Struts 1.x (which REALLY shows its age these days) and many of the newer alternatives, and the differences pop up early and often.