layer-8
Wednesday, April 12, 2006
Sun, Apple, and the Fortune 500
Ben Rockwood mentioned that the Fortune 500 list for 2006 is now online, and commented that Sun's position, at #211, is still impressive.
Sun's position is indeed relevant, even slipping from #194 last year, #211 still makes you a very large and very relevant company. Still, it means that Sun is below Apple (which it wasn't in 2005), and profit figures aren't impressive, either, with Sun reporting a 107 M$ loss that places it at #36 in the "Losers" category.
Blame Nick Carr or not, IT, especially hardware and operating systems, is indeed seen by many managers as a commodity of sorts. It's up to the challengers to change that perception - not the incumbents. So HP and Dell can play along with the "commodity" approach and still profit from it, while Sun and Apple can not.
Apple has done a pretty good job at it; it's very easy for the consumer to distinguish from an Apple product and a non-Apple product, they have a different perceived-value, thanks to marketing but also to some true innovation and design.
When it comes to Sun, I talk to a lot of people that really find little subjective difference between Unix boxes, they are ready to choose Sun or IBM or HP based on reasons other that the platform's merit. They are often wrong, but it's not a trivial task to prove them wrong before they make their decision. IBM and HP have a lot of success stories they can come in and tell you. In the end, the decision is based on price, on "synergies" (whatever they may be, real or not) and on "ability to deliver on time".
What is Sun going to do about it? What makes a Sun product better than its competition? And does the average CIO know about that?
Those are the questions that will define Sun's rank in the Fortune 500 2006 list. ¶ 12:30 2 comments
Sun's position is indeed relevant, even slipping from #194 last year, #211 still makes you a very large and very relevant company. Still, it means that Sun is below Apple (which it wasn't in 2005), and profit figures aren't impressive, either, with Sun reporting a 107 M$ loss that places it at #36 in the "Losers" category.
Blame Nick Carr or not, IT, especially hardware and operating systems, is indeed seen by many managers as a commodity of sorts. It's up to the challengers to change that perception - not the incumbents. So HP and Dell can play along with the "commodity" approach and still profit from it, while Sun and Apple can not.
Apple has done a pretty good job at it; it's very easy for the consumer to distinguish from an Apple product and a non-Apple product, they have a different perceived-value, thanks to marketing but also to some true innovation and design.
When it comes to Sun, I talk to a lot of people that really find little subjective difference between Unix boxes, they are ready to choose Sun or IBM or HP based on reasons other that the platform's merit. They are often wrong, but it's not a trivial task to prove them wrong before they make their decision. IBM and HP have a lot of success stories they can come in and tell you. In the end, the decision is based on price, on "synergies" (whatever they may be, real or not) and on "ability to deliver on time".
What is Sun going to do about it? What makes a Sun product better than its competition? And does the average CIO know about that?
Those are the questions that will define Sun's rank in the Fortune 500 2006 list. ¶ 12:30 2 comments
windows and unix, oil and water
Some days go by without even remembering that there are different software platforms and different system philosophies. In this ever-more-so service oriented world, everything quickly becomes a service, and platforms are readily available to do whatever they are best at doing.
It is know that when all you have is a hammer, pretty much everything starts looking like a nail in some way. So the weltanschauung of a distributed systems architect is, often, that everything is a distributed system, even your desktop.
For years, I've had two or three machines as my "desktop". Usually, one of them is a headless linux box under the desk (does that still count as "desktop"?). The other is usually a Windows box that I run Microsoft Project, Visio and sometines Outlook on. The third is a small Solaris box in the development datacenter with a big sticker with my name on it.
Why would an architect need - or want - three boxes for daily usage?
First, you must answer the question of "what does an architect do".
Architects don't spend all their time "architecting" things away. Beneath the architect's skin, there's someone that needs to hack, to explore, to experiment.
Software and systems architecture is a relatively young field, in a fast changing environment. Designing software and systems is not a close parallel to designing houses. In housing, materials and building techniques have developed in the last 20 years, and so have people's requirements,
but those changes pale in comparison with the yearly changes in the software world.
That makes software architecture a partly experimental discipline. The only architects that can do without the hands-on component are the ones that have large teams to do the hands-on bit for them. Still, it's like being a painter without ever touching a brush - and most architects do have the hacker bug in them, so we tend to enjoy the tinkering bit.
Living daily with all the different platforms gives you the true notion of how they can be best combined, so eventually you start looking at them as complements rather than alternatives. Even at home, where we run a Windows box, a couple of Macs (one OS X, one System 9), a FreeBSD and a Debian box, platforms tend to get used for what they do best (we run graphics and audio stuff on the Mac, the Linux box is for development and pen-testing, the Windows box runs OpenOffice, Firefox and a few more things).
But sometimes you have to step outside this confort zone.
Today, I had to setup a way to run remote programs on three dozen windows servers. I tried a number of things, from sysinternals psexec to Windows Scripting. The solution that seemed to be more stable and work best, in the end, was an old friend - ssh.
So I went and installed and configured OpenSSH on 36 Windows boxes in less than an afternoon, complete with public key authentication, and was quite happy with the result.
And then I remembered why I dislike the Windows platform so much.
It has to do with expectations.
An API is an API. A system API, even more so.
The behaviour of a system call is a ponderous thing - it cannot be changed because of a whim, there are whole layers of software that depend on it.
Unix-heritage systems understand this, so they implement system functions with the upmost care, sometimes taking endless time to discuss, to review, to approve a small change. This upsets a lot of people, but changing the API would upset a lot more.
Linux takes a somewhat different approach. The kernel and libraries evolve faster, but there is a serious peer-review process going on in the kernel mailing-lists, and you have well-chosen and responsible people looking over the whole process. So change happens, while disruption is kept at a minimum.
On Windows, they must have a process. Some process. And it's probably good, as processes go. But the outcome sometimes sucks.
Somewhere between Windows 2000 and Windows XP, someone decided to change the behaviour of the RunAs call regarding system-wide resources, such as mapped drives.
In Windows 2000, if a user maps a drive, processes that run under that same account will find the drive mapped and will be able to use it. That allows you to have a session owning the desktop, under user fred, mapping a drive as z:, and then ssh into the box as fred to check on the status of the drive (whether it is still connected or not, if you can write on it, what the free space is).
In Windows XP, you can no longer do that. The RunAs call doesn't export user fred's environment or mapped resources. If you want to check on the drive, you have to map it again - which is not what you need nor what you wanted in the first place.
I'm not even arguing if the decision is good or bad. It doesn't look like it can add much security; if the original user has the power to access a resource, then any other program running as the same user will be able to access it using the exact same credentials. But it does prevent you from inspecting the logged-on user's environment, or to have helper programs be spawned in the background to reconnect the drive (since they are launched by system, and use the RunAs function to change into the user's identity).
The outcome of it all is that I'll have to go find yet another solution for my problem. I'm sure I will find a good one, that's not the part that I'm upset about.
But this close encounter with the things that are wrong in Windows, in the Microsoft change-management process over the operating system, and with the pains of enduring support of a complex software system on top of an operating system that keeps changing for no apparent reason reminded me of why I've chosen Unix over Windows for the last 20 years. ¶ 02:14 0 comments
It is know that when all you have is a hammer, pretty much everything starts looking like a nail in some way. So the weltanschauung of a distributed systems architect is, often, that everything is a distributed system, even your desktop.
For years, I've had two or three machines as my "desktop". Usually, one of them is a headless linux box under the desk (does that still count as "desktop"?). The other is usually a Windows box that I run Microsoft Project, Visio and sometines Outlook on. The third is a small Solaris box in the development datacenter with a big sticker with my name on it.
Why would an architect need - or want - three boxes for daily usage?
First, you must answer the question of "what does an architect do".
Architects don't spend all their time "architecting" things away. Beneath the architect's skin, there's someone that needs to hack, to explore, to experiment.
Software and systems architecture is a relatively young field, in a fast changing environment. Designing software and systems is not a close parallel to designing houses. In housing, materials and building techniques have developed in the last 20 years, and so have people's requirements,
but those changes pale in comparison with the yearly changes in the software world.
That makes software architecture a partly experimental discipline. The only architects that can do without the hands-on component are the ones that have large teams to do the hands-on bit for them. Still, it's like being a painter without ever touching a brush - and most architects do have the hacker bug in them, so we tend to enjoy the tinkering bit.
Living daily with all the different platforms gives you the true notion of how they can be best combined, so eventually you start looking at them as complements rather than alternatives. Even at home, where we run a Windows box, a couple of Macs (one OS X, one System 9), a FreeBSD and a Debian box, platforms tend to get used for what they do best (we run graphics and audio stuff on the Mac, the Linux box is for development and pen-testing, the Windows box runs OpenOffice, Firefox and a few more things).
But sometimes you have to step outside this confort zone.
Today, I had to setup a way to run remote programs on three dozen windows servers. I tried a number of things, from sysinternals psexec to Windows Scripting. The solution that seemed to be more stable and work best, in the end, was an old friend - ssh.
So I went and installed and configured OpenSSH on 36 Windows boxes in less than an afternoon, complete with public key authentication, and was quite happy with the result.
And then I remembered why I dislike the Windows platform so much.
It has to do with expectations.
An API is an API. A system API, even more so.
The behaviour of a system call is a ponderous thing - it cannot be changed because of a whim, there are whole layers of software that depend on it.
Unix-heritage systems understand this, so they implement system functions with the upmost care, sometimes taking endless time to discuss, to review, to approve a small change. This upsets a lot of people, but changing the API would upset a lot more.
Linux takes a somewhat different approach. The kernel and libraries evolve faster, but there is a serious peer-review process going on in the kernel mailing-lists, and you have well-chosen and responsible people looking over the whole process. So change happens, while disruption is kept at a minimum.
On Windows, they must have a process. Some process. And it's probably good, as processes go. But the outcome sometimes sucks.
Somewhere between Windows 2000 and Windows XP, someone decided to change the behaviour of the RunAs call regarding system-wide resources, such as mapped drives.
In Windows 2000, if a user maps a drive, processes that run under that same account will find the drive mapped and will be able to use it. That allows you to have a session owning the desktop, under user fred, mapping a drive as z:, and then ssh into the box as fred to check on the status of the drive (whether it is still connected or not, if you can write on it, what the free space is).
In Windows XP, you can no longer do that. The RunAs call doesn't export user fred's environment or mapped resources. If you want to check on the drive, you have to map it again - which is not what you need nor what you wanted in the first place.
I'm not even arguing if the decision is good or bad. It doesn't look like it can add much security; if the original user has the power to access a resource, then any other program running as the same user will be able to access it using the exact same credentials. But it does prevent you from inspecting the logged-on user's environment, or to have helper programs be spawned in the background to reconnect the drive (since they are launched by system, and use the RunAs function to change into the user's identity).
The outcome of it all is that I'll have to go find yet another solution for my problem. I'm sure I will find a good one, that's not the part that I'm upset about.
But this close encounter with the things that are wrong in Windows, in the Microsoft change-management process over the operating system, and with the pains of enduring support of a complex software system on top of an operating system that keeps changing for no apparent reason reminded me of why I've chosen Unix over Windows for the last 20 years. ¶ 02:14 0 comments
Tuesday, April 04, 2006
Saturday, April 01, 2006
Game over, time to turn the page (April's fools post)
This is my 2006 April fools post. None of what is said is actually true, as befits the tradition.
I've had it.
If you read a comment I made yesterday on some blog, you'll know how upset I am at corporate "wisdom", that keeps taking the wrong decisions, over and over and over again.
Today didn't do much to clear my head, on the contrary.
So I've decided it's time to quit.
I am leaving my current position, am no longer going to work in IT, and I've accepted a long-standing proposition to work as a consultant for a major portuguese player in the fishing industry.
And what do I know about fishing, may you ask? Well, a lot more than I do about computers. You throw stuff into the water and you lure fishes to come out of it. With computers, with all the stuff I've thrown into them, I could never get a fish to come out of the drive or anything; a couple of bugs, maybe, but never something as complex and wholesome as a fish.
This decision has been long in the making, and I am aware of all the consequences. I do know I'll suddenly start having a lot more problems with computers, because I will no longer be a computer engineer. The dress code will be an advantage, since I won't have to change much - I can go on wearing high-collar sweaters and sturdy boots, and that's ok by me.
One of the main advantages will be that in the fishing industry it's a lot harder to bring your work home with you, unless you happen to live by the shore (which I don't). Well, you can bring the fishes, but by then they no longer count as "work", the right word would be "dinner".
Lastly, I would like to extend a word of appreciation and thanks to all the people I've worked with in IT during the last 20 years. Your example and inspiration has always been a source of continued strength and motivation for me. It's a pleasure and a privilege to work in an industry with such dedicated and inspired minds as I've had the chance of knowing and working with, on countless occasions.
And if you ever happen to drop by the docks some day, pay me a visit. I'll be the one in the yellow overall, smoking a pipe and making witty comments about the weather. ¶ 23:59 0 comments
I've had it.
If you read a comment I made yesterday on some blog, you'll know how upset I am at corporate "wisdom", that keeps taking the wrong decisions, over and over and over again.
Today didn't do much to clear my head, on the contrary.
So I've decided it's time to quit.
I am leaving my current position, am no longer going to work in IT, and I've accepted a long-standing proposition to work as a consultant for a major portuguese player in the fishing industry.
And what do I know about fishing, may you ask? Well, a lot more than I do about computers. You throw stuff into the water and you lure fishes to come out of it. With computers, with all the stuff I've thrown into them, I could never get a fish to come out of the drive or anything; a couple of bugs, maybe, but never something as complex and wholesome as a fish.
This decision has been long in the making, and I am aware of all the consequences. I do know I'll suddenly start having a lot more problems with computers, because I will no longer be a computer engineer. The dress code will be an advantage, since I won't have to change much - I can go on wearing high-collar sweaters and sturdy boots, and that's ok by me.
One of the main advantages will be that in the fishing industry it's a lot harder to bring your work home with you, unless you happen to live by the shore (which I don't). Well, you can bring the fishes, but by then they no longer count as "work", the right word would be "dinner".
Lastly, I would like to extend a word of appreciation and thanks to all the people I've worked with in IT during the last 20 years. Your example and inspiration has always been a source of continued strength and motivation for me. It's a pleasure and a privilege to work in an industry with such dedicated and inspired minds as I've had the chance of knowing and working with, on countless occasions.
And if you ever happen to drop by the docks some day, pay me a visit. I'll be the one in the yellow overall, smoking a pipe and making witty comments about the weather. ¶ 23:59 0 comments
The thing about Ruby
It seems that one of the "hot topics" of late in my corner of blogsphere is Ruby.
I first heard of Ruby in 1997. It was being described as a great language for a number of things, especially web apps. Well, everything was supposed to be good for web apps in those days. I remember I was toying around with languages, trying out REBOL, Ruby, Python and others.
REBOL was (and is) almost a DSL, a nice one, too, but still a DSL.
Python, i never did like, (and still don't). You can only trust this much on a language that uses whitespace as a significant token, and not just as a separator.
Ruby, on the other hand, seemed promising. Smalltalk meets Perl.
Perl was always my baby (and still is).
I've done more different things with Perl than many people have done with all the languages they know, combined. And it never let me down; not in reliability, not in elegance, not in power. I've heard complains about the terse syntax more times than I care to remember. But then I realize that the people that complain about Perl are the same ones that complain about algebra, and I understand.
What I don't understand is why we're starting a language war - on a small scale, still a regional conflict - abut Ruby. James McGovern on one side, a lot of people on the other, from Blaine and James Robertson to David Hansson of 37signals (to be expected, of course ;) )
Robert McIlree sums it up pretty well, and there's not much I'd rather say that he didn't already cover.
I've lived by IETF practices for too long to consider doing otherwise. "Rough consensus, running code" has served me well for the last 20 years, and I expect it will continue being a sane mantra.
Morten comments on a LoudThinking article that
Most enterprises have to maintain something called production systems (look it up on google, if you need); also, most enterprises focus on something called "their business", where IT is just a tool, not a goal in itself. It's so easy to talk about radical change when we have little to lose, isn't it? Now start carrying the weight of supporting production systems, and all-of-a-sudden you're not feeling so light and nimble anymore, and your butterfly-ish tendency to embrace whatever is bright and new and shiny starts to fade away.
And then you start to realize than you do have to keep those 200.000 lines of COBOL on the mainframe, because you just can't take the time, the money and the risk of redesigning your entire core systems because somebody thinks that Ruby or Python are much better and modern languages.
If you come to think of it, the only languages found on those Fortune 200 companies James McGovernor talks about are the ones that have been around long enough to evolve into core systems - COBOL, C, and a few others. Java has made a few incursions into that field - heck, but so has Visual Basic.
So let's all stop judging languages by whether they have been around long enough to have creeped into the core systems, and start looking at what they can do today, and wether or not they can help us solve our problems, today, and help us have less problems tomorrow.
Me, I'm just an old dog; i'll stick to Perl. ¶ 04:51 2 comments
I first heard of Ruby in 1997. It was being described as a great language for a number of things, especially web apps. Well, everything was supposed to be good for web apps in those days. I remember I was toying around with languages, trying out REBOL, Ruby, Python and others.
REBOL was (and is) almost a DSL, a nice one, too, but still a DSL.
Python, i never did like, (and still don't). You can only trust this much on a language that uses whitespace as a significant token, and not just as a separator.
Ruby, on the other hand, seemed promising. Smalltalk meets Perl.
Perl was always my baby (and still is).
I've done more different things with Perl than many people have done with all the languages they know, combined. And it never let me down; not in reliability, not in elegance, not in power. I've heard complains about the terse syntax more times than I care to remember. But then I realize that the people that complain about Perl are the same ones that complain about algebra, and I understand.
What I don't understand is why we're starting a language war - on a small scale, still a regional conflict - abut Ruby. James McGovern on one side, a lot of people on the other, from Blaine and James Robertson to David Hansson of 37signals (to be expected, of course ;) )
Robert McIlree sums it up pretty well, and there's not much I'd rather say that he didn't already cover.
I've lived by IETF practices for too long to consider doing otherwise. "Rough consensus, running code" has served me well for the last 20 years, and I expect it will continue being a sane mantra.
Morten comments on a LoudThinking article that
The enterprise (...) customers (...) are severely encumbered by legacy because they maintain home grown frameworks from yesteryear rather than having a strategy for moving on. For some reason, they find that they must "defend" their investment rather than leverage common open source frameworks (which are far superior to their home grown stack).Yes, and the exact same words can be said about Microsoft. Our past stays with us at all times,; still our past is also the ground we stand to take the next step and reach higher, further.
Most enterprises have to maintain something called production systems (look it up on google, if you need); also, most enterprises focus on something called "their business", where IT is just a tool, not a goal in itself. It's so easy to talk about radical change when we have little to lose, isn't it? Now start carrying the weight of supporting production systems, and all-of-a-sudden you're not feeling so light and nimble anymore, and your butterfly-ish tendency to embrace whatever is bright and new and shiny starts to fade away.
And then you start to realize than you do have to keep those 200.000 lines of COBOL on the mainframe, because you just can't take the time, the money and the risk of redesigning your entire core systems because somebody thinks that Ruby or Python are much better and modern languages.
If you come to think of it, the only languages found on those Fortune 200 companies James McGovernor talks about are the ones that have been around long enough to evolve into core systems - COBOL, C, and a few others. Java has made a few incursions into that field - heck, but so has Visual Basic.
So let's all stop judging languages by whether they have been around long enough to have creeped into the core systems, and start looking at what they can do today, and wether or not they can help us solve our problems, today, and help us have less problems tomorrow.
Me, I'm just an old dog; i'll stick to Perl. ¶ 04:51 2 comments
