Archive for the 'Technology' Category
02nd Apr 2008
Why Linux will never be the world’s primary desktop
Every year for the past N years has been proclaimed as “The Year of Linux on the Desktop!” It hasn’t happened. It will never happen.
Why?
GNOME vs. KDE? Which distro?
I understand that Linux is the kernel and that GNOME/KDE is the desktop. I am well aware of this distinction. Joe Average User is not. Joe Average User runs Windows because that’s what came installed with his machine from BestBuy. Jane Schmancy User might be using a Mac, but OS X came pre-installed when she bought her machine. In both scenarios, the computers Just Work⢠when they brought them home and booted them up. It’s a packaged experience where the value-add of the OEM vendor is the preconfigured-everything-work-out-of-the-box.
Enter Linux.
First, you have to download a distribution. Which one? With this single step, you’ve lost 95% of the people.
Second, you have to install the OS. It’s a well-known fact that 98.87823423% of the people don’t know what an operating system is nor do they care. They want to vote for their favorite American Idol, not worry about what it means to walk through Anaconda’s install process.
The Free Open Source Software community (of which I am a fervent supporter) believes that choice is a good thing. They are wrong. Less is more, particularly when it comes to making choices. This is the paradox of choice.
The group of people in the world who likes more choice when it comes to operating systems is vanishingly small.
I’ve got CentOS on a desktop at home. I’ve installed Ubuntu on a work machine. Damn Small Linux is our OS of choice for our message bus. I’m in the minority of users. It takes one to know one.
The real reason people won’t switch desktops
It’s different.
That’s it. In a nutshell, “it’s different” will keep the vast majority of users from switching desktops. Joe and Jane Average User barely know Windows, I don’t expect them to voluntarily want to be a newbie on another system. No one likes being a newbie, especially when they’ve achieved some level of mastery of something.
One of my teammates (we’ll call him “Dan”) just got a MacBook Pro to replace his aging Windows laptop. Dan is among the technical elite. He chose Damn Small Linux for our server OS. One week later, he’s lamenting the fact that he’s not as productive on his new machine because he has to learn all new ways of doing things. He briefly considering remapping all the Mac hot keys to match the Windows hot keys he was used to.
When a tech master is considering remapping hot keys, Joe Average User is lost!
The average user doesn’t use hot keys, doesn’t know what they are, and certainly doesn’t know how to remap them. If they even manage to install a new OS, they’ll be lost when looking to run their programs; they won’t get the dumb joke in KDE where every app has to start with a K (Kommander? Konquerer? Kalculator? Please.)
The rise of Mac OSX?
If there will be another desktop to challenge Windows — and that’s a pretty big IF — it will be Apple’s wares. They’ve got the iPod and the iPhone leading the way. They’ve got a much cooler brand than Microsoft. They are trickling into the enterprise market (our CEO uses a Mac, for example, as does our creative staff, media department, and several developers).
Still, “Think Different” becomes “it’s different” for the average user. The person switching from Windows to Mac will be on the right side of the bell curve. The billion PCs out there in the world (and growing) will be running Windows for a long time.
I’m writing this from a Windows laptop. Of the 12 people I can see in my immediate field of vision, only Dan has a Mac. One runs Ubuntu in a VM on his Windows laptop. The rest are running straight Windows.
This article isn’t meant to be a comparison of desktops, features, security, reliability or anything else. I’m just calling it like it see it in terms of usage. The word “never” in the title makes my position an absolute. Perhaps I should modify it to say “Why Linux won’t be the world’s primary desktop for a looooooooooong time, if ever.”
I’m sure some will disagree.
Every year for the past N years has been proclaimed as “The Year of Linux on the Desktop!” It hasn’t happened. It will never happen.
Why?
GNOME vs. KDE? Which distro?
I understand that Linux is the kernel and that GNOME/KDE is the desktop. I am well aware of this distinction. Joe Average User is not. Joe Average User runs Windows because that’s what came installed with his machine from BestBuy. Jane Schmancy User might be using a Mac, but OS X came pre-installed when she bought her machine. In both scenarios, the computers Just Work⢠when they brought them home and booted them up. It’s a packaged experience where the value-add of the OEM vendor is the preconfigured-everything-work-out-of-the-box.
Enter Linux.
First, you have to download a distribution. Which one? With this single step, you’ve lost 95% of the people.
Second, you have to install the OS. It’s a well-known fact that 98.87823423% of the people don’t know what an operating system is nor do they care. They want to vote for their favorite American Idol, not worry about what it means to walk through Anaconda’s install process.
The Free Open Source Software community (of which I am a fervent supporter) believes that choice is a good thing. They are wrong. Less is more, particularly when it comes to making choices. This is the paradox of choice.
The group of people in the world who likes more choice when it comes to operating systems is vanishingly small.
I’ve got CentOS on a desktop at home. I’ve installed Ubuntu on a work machine. Damn Small Linux is our OS of choice for our message bus. I’m in the minority of users. It takes one to know one.
The real reason people won’t switch desktops
It’s different.
That’s it. In a nutshell, “it’s different” will keep the vast majority of users from switching desktops. Joe and Jane Average User barely know Windows, I don’t expect them to voluntarily want to be a newbie on another system. No one likes being a newbie, especially when they’ve achieved some level of mastery of something.
One of my teammates (we’ll call him “Dan”) just got a MacBook Pro to replace his aging Windows laptop. Dan is among the technical elite. He chose Damn Small Linux for our server OS. One week later, he’s lamenting the fact that he’s not as productive on his new machine because he has to learn all new ways of doing things. He briefly considering remapping all the Mac hot keys to match the Windows hot keys he was used to.
When a tech master is considering remapping hot keys, Joe Average User is lost!
The average user doesn’t use hot keys, doesn’t know what they are, and certainly doesn’t know how to remap them. If they even manage to install a new OS, they’ll be lost when looking to run their programs; they won’t get the dumb joke in KDE where every app has to start with a K (Kommander? Konquerer? Kalculator? Please.)
The rise of Mac OSX?
If there will be another desktop to challenge Windows — and that’s a pretty big IF — it will be Apple’s wares. They’ve got the iPod and the iPhone leading the way. They’ve got a much cooler brand than Microsoft. They are trickling into the enterprise market (our CEO uses a Mac, for example, as does our creative staff, media department, and several developers).
Still, “Think Different” becomes “it’s different” for the average user. The person switching from Windows to Mac will be on the right side of the bell curve. The billion PCs out there in the world (and growing) will be running Windows for a long time.
I’m writing this from a Windows laptop. Of the 12 people I can see in my immediate field of vision, only Dan has a Mac. One runs Ubuntu in a VM on his Windows laptop. The rest are running straight Windows.
This article isn’t meant to be a comparison of desktops, features, security, reliability or anything else. I’m just calling it like it see it in terms of usage. The word “never” in the title makes my position an absolute. Perhaps I should modify it to say “Why Linux won’t be the world’s primary desktop for a looooooooooong time, if ever.”
I’m sure some will disagree.
Posted by Mark Turansky under 
Engineering, Technology 
15 Comments »
07th Mar 2008
Scalability & High Availability with Terracotta Server
Our message bus will be deployed to production this month. We’re currently sailing through QA. Whatever bugs we’ve found have been in the business logic of the messages themselves (and assorted processing classes). Our infrastructure — the message bus backed by Terracotta — is strong.
SCALABILITY
People are asking questions about scalability. Quite frankly, I’m not worried about it.
Scalability is a function of architecture. If you get it right, you can scale easily with new hardware. We got it right. I can say that with confidence because we’ve load tested the hell out of it. We put 1.3 million real world messages through our bus in a weekend. That may or may not be high throughput for you and your business, but I guarantee you it is for our’s.
The messages we put through our bus take a fair amount of processing power. That means they take more time to produce their result than they do to route through our bus. How does that affect our server load? Terracotta sat idle most of the time. The box hosting TC is the beefiest one in our cluster. Two dual-core hyperthreaded procs, which look like 8 CPUs in htop. We figured we would need the most powerful server to host the brains of the bus. Turns out we were wrong, so we put some message consumers on the TC box, widening our cluster for greater throughput. Now the box is hard at work, but only because we put four message consumers on it.
When we slam our bus with simple messages (e.g, messages that add 1+1), we see TC hard at work. The CPUs light up and the bus is running as fast as it can. 1+1 doesn’t carry much overhead. It’s the perfect test to stress the interlocking components of our bus. You can’t get any faster than 1+1 messages. But when we switched to real world messages, our consumers took all the time, their CPUs hit the ceiling, and our bus was largely idle. The whole bus, not just TC. We’ve got consumers that perform logging and callbacks and other sundry functions. All of these are mostly idle when our message consumers process real world workloads.
We’ve got our test farm on 4 physical nodes, each running between 4 and 8 Java processes (our various consumers) for a total of 24 separate JVMs. All of these JVMs are consumers of queues, half of them are consumers of our main request queue that performs all the real work. The other half are web service endpoints, batch processors, loggers, callback consumers, etc. and each are redundant on different phsyical nodes. Because our message processing carries greater overhead than bussing, I know we can add dozens more consumers for greater throughput without unduly taxing Terracotta. If we hit a ceiling, we can very easily create another cluster and load balance between them. That’s how Google scales. They’ve got thousands of clusters in a data center. This is perfectly acceptable for our requirements. It may or may not be suitable for your’s.
You might be thinking that dozens of nodes isn’t a massive cluster, but our database would beg to differ. Once we launch our messaging system and start processing with it, we’ll begin to adversely impact our database. Scaling out that tier (more cheaply than buying new RAC nodes) is coming next. I hope we can scale our database as cheaply and easily as our message bus. That’ll enable us to grow our bus to hundreds of processors.
Like I said, I’m not worried about scaling our bus.
HIGH AVAILABILITY
I might not be worried about scalability, but I am worried about high availability. My company is currently migrating to two new data centers. One will be used for our production servers while the other is slated for User Acceptance Test and Disaster Recovery. That’s right, an entire data center for failover. High availability is very important for our business and any business bound by Service Level Agreements.
Terracotta Server has an Active-Passive over Network solution for high availability. There is also a shared disk solution, but the network option fits our needs well. Our two data centers are connected by a big fat pipe, and Terracotta Server can have N number of passive servers. That means we can have a redundant server in our production data center and another one across the wire in our DR data center. We’ve also got a SAN that replicates disks between data centers. We might go with the shared disk solution if we find it performs better.
Overall, though, it is more important for our business to get back online quickly than it is to perform at the nth degree of efficiency. Messaging, after all, doesn’t guarantee when your stuff gets run, just that it eventually runs. And if everything is asynchronous, then performance, too, is a secondary consideration to high availability.
CONCLUSION
If there’s one lesson to be learned through this blog article, it’s that one size does not fit all. Not all requirements are created equal. Our message bus is the right solution for our needs. Your mileage may vary. Some factors may outweigh others. For example, having a tight and tiny message bus that any developer can run in their IDE without a server (even without TC) is a great feature. No APIs lets us do that with Terracotta. You might have very different requirements than we do and find yourself with a very different solution.
Our message bus will be deployed to production this month. We’re currently sailing through QA. Whatever bugs we’ve found have been in the business logic of the messages themselves (and assorted processing classes). Our infrastructure — the message bus backed by Terracotta — is strong.
SCALABILITY
People are asking questions about scalability. Quite frankly, I’m not worried about it.
Scalability is a function of architecture. If you get it right, you can scale easily with new hardware. We got it right. I can say that with confidence because we’ve load tested the hell out of it. We put 1.3 million real world messages through our bus in a weekend. That may or may not be high throughput for you and your business, but I guarantee you it is for our’s.
The messages we put through our bus take a fair amount of processing power. That means they take more time to produce their result than they do to route through our bus. How does that affect our server load? Terracotta sat idle most of the time. The box hosting TC is the beefiest one in our cluster. Two dual-core hyperthreaded procs, which look like 8 CPUs in htop. We figured we would need the most powerful server to host the brains of the bus. Turns out we were wrong, so we put some message consumers on the TC box, widening our cluster for greater throughput. Now the box is hard at work, but only because we put four message consumers on it.
When we slam our bus with simple messages (e.g, messages that add 1+1), we see TC hard at work. The CPUs light up and the bus is running as fast as it can. 1+1 doesn’t carry much overhead. It’s the perfect test to stress the interlocking components of our bus. You can’t get any faster than 1+1 messages. But when we switched to real world messages, our consumers took all the time, their CPUs hit the ceiling, and our bus was largely idle. The whole bus, not just TC. We’ve got consumers that perform logging and callbacks and other sundry functions. All of these are mostly idle when our message consumers process real world workloads.
We’ve got our test farm on 4 physical nodes, each running between 4 and 8 Java processes (our various consumers) for a total of 24 separate JVMs. All of these JVMs are consumers of queues, half of them are consumers of our main request queue that performs all the real work. The other half are web service endpoints, batch processors, loggers, callback consumers, etc. and each are redundant on different phsyical nodes. Because our message processing carries greater overhead than bussing, I know we can add dozens more consumers for greater throughput without unduly taxing Terracotta. If we hit a ceiling, we can very easily create another cluster and load balance between them. That’s how Google scales. They’ve got thousands of clusters in a data center. This is perfectly acceptable for our requirements. It may or may not be suitable for your’s.
You might be thinking that dozens of nodes isn’t a massive cluster, but our database would beg to differ. Once we launch our messaging system and start processing with it, we’ll begin to adversely impact our database. Scaling out that tier (more cheaply than buying new RAC nodes) is coming next. I hope we can scale our database as cheaply and easily as our message bus. That’ll enable us to grow our bus to hundreds of processors.
Like I said, I’m not worried about scaling our bus.
HIGH AVAILABILITY
I might not be worried about scalability, but I am worried about high availability. My company is currently migrating to two new data centers. One will be used for our production servers while the other is slated for User Acceptance Test and Disaster Recovery. That’s right, an entire data center for failover. High availability is very important for our business and any business bound by Service Level Agreements.
Terracotta Server has an Active-Passive over Network solution for high availability. There is also a shared disk solution, but the network option fits our needs well. Our two data centers are connected by a big fat pipe, and Terracotta Server can have N number of passive servers. That means we can have a redundant server in our production data center and another one across the wire in our DR data center. We’ve also got a SAN that replicates disks between data centers. We might go with the shared disk solution if we find it performs better.
Overall, though, it is more important for our business to get back online quickly than it is to perform at the nth degree of efficiency. Messaging, after all, doesn’t guarantee when your stuff gets run, just that it eventually runs. And if everything is asynchronous, then performance, too, is a secondary consideration to high availability.
CONCLUSION
If there’s one lesson to be learned through this blog article, it’s that one size does not fit all. Not all requirements are created equal. Our message bus is the right solution for our needs. Your mileage may vary. Some factors may outweigh others. For example, having a tight and tiny message bus that any developer can run in their IDE without a server (even without TC) is a great feature. No APIs lets us do that with Terracotta. You might have very different requirements than we do and find yourself with a very different solution.
Posted by Mark Turansky under Architecture, Engineering, Technology, Terracotta 3 Comments »
05th Mar 2008
HOW TO: Better JavaScript Templates
JavaScript Templates (Jst) is a pure Javascript templating engine that runs in your browser using JSP-like syntax. If that doesn’t sound familiar, check out the live working example on this site and download the code. It’s Free Open Source Software.
JavaScript Templates (Jst) is a pure Javascript templating engine that runs in your browser using JSP-like syntax. If that doesn’t sound familiar, check out the live working example on this site and download the code. It’s Free Open Source Software.
Posted by Mark Turansky under Code Hints, Engineering, HOW TO, Technology 3 Comments »
