Sometimes, when I rebuild my Sun machines, I update the OBP (OpenBoot PROM).
Not always, and not necessarily to a systematic pattern. Part of the reason for this is that I don't always have a convenient window to do so, but also I'm not entirely sure whether it's really a good idea - it's not broken, so why fix it?
I have had SunService complain about non-current OBP versions, but without any particularly good justification. And I have had one case where an OBP update actually stopped a system working.
It's easier to update systems now - US-III machines (most of them, anyway) can be updated from Solaris with a script, which is good. I just have to put the keyswitch into normal (which involves physically going to the machine) on servers. Older machines are slightly more tricky.
I know there are some cases where I have to upgrade OBP. For example, before a CPU upgrade so it will recognize the new processors.
I wonder what other people do as a strategy. Do you religiously upgrade OBP, or avoid doing so like the plague?
Thursday, March 24, 2005
Wednesday, March 23, 2005
I love the sound of breaking glass
(Not!)
Not how you want to find your computer room!
Yup, that's a glass door spontaneously shattered overnight. Certainly the first time I've seen anything like this.
(And it's obviously shattered rather than fell out - the distribution of glass indicates that it's dropped vertically. That was a mess to clear up, let me tell you! Fortunately safety glass tends not to generate large sharp pieces, although there were a lot of nasty dust-like shards.)
Not how you want to find your computer room!
Yup, that's a glass door spontaneously shattered overnight. Certainly the first time I've seen anything like this.
(And it's obviously shattered rather than fell out - the distribution of glass indicates that it's dropped vertically. That was a mess to clear up, let me tell you! Fortunately safety glass tends not to generate large sharp pieces, although there were a lot of nasty dust-like shards.)
Monday, March 21, 2005
FantasyLand
As Jim says, Conspiracy theories are fun.
Specifically, the idea that Sun might buy SCO.
Does SCO have anything of value left that Sun might want? I doubt it. Last year, Sun bought out whatever IP from SCO it needed, to help Open Source Solaris. Sun's got all the IP it needs from SCO, has a much better OS in Solaris than SCO will ever have, and it's not as if SCO has any other assets that would be interesting to Sun.
I was entertained by the considerable advances listed in the article:
OpenServer can now support 16 processors, use 16GB of general-purpose memory, let databases access 64GB of memory, support files bigger than 2GB and multithreaded application via the native SVR5 kernel.
Oh my. We were doing that with Solaris 7. In what, 1998?
Specifically, the idea that Sun might buy SCO.
Does SCO have anything of value left that Sun might want? I doubt it. Last year, Sun bought out whatever IP from SCO it needed, to help Open Source Solaris. Sun's got all the IP it needs from SCO, has a much better OS in Solaris than SCO will ever have, and it's not as if SCO has any other assets that would be interesting to Sun.
I was entertained by the considerable advances listed in the article:
OpenServer can now support 16 processors, use 16GB of general-purpose memory, let databases access 64GB of memory, support files bigger than 2GB and multithreaded application via the native SVR5 kernel.
Oh my. We were doing that with Solaris 7. In what, 1998?
Sunday, March 20, 2005
Improving Operational Efficiency
Most computers sit pretty idle most of the time. (In fact, one could well ask if they ever do anything useful!) This is true both for desktops and servers.
Normally, this is because you have to overspecify the kit - based on the average load - in order to be able to handle the peaks. Either to give good response on a desktop machine once the user actually does something, or to handle sudden unpredictable surges in demand, or simply because load is cyclical.
(In our case, one case we have to cater for is the case of an instructor standing in front of a class of 20 students and inviting them all to run some interesting application on our servers - at the same time.)
The well-known downside to this is that you end up with a system that's horribly inefficient. Not only do you have to spend much more up front than you really need, you end up burning electricity and running your air conditioning plant round the clock, so the cost is based on the peak load which is usually highly atypical.
There are a range of solutions that can drive up efficiency and equipment utilization - or, more to the point, how to achieve the same (or better) service for customers and users for lower cost.
On the desktop front, thin-client solutions can lead to considerable savings. Not so much in up-front costs any more, but in terms of power and cost of ownership the thin-client starts to make much more sense. In many ways, though, it's more subtle issues like the lower noise and desktop footprint that ought to make this a no-brainer. We've used SunRays (and the hot desking is really useful) with some success, although we've avoided them for developer desktops in the past because developers tend to want to do things like run netbeans, tomcat, apache, mysql and the like, and you can't really have more than one on a machine. But with zones in Solaris 10 we could consolidate developers onto a SunRay server as well.
Many servers sit pretty idle simply because it's been traditional to allocate one server per service. I know we've done this in the past - simply to keep services separate and manageable. Then server sprawl can become a serious problem. Enter Solaris zones again - it looks like you're running one service per machine, but they're all consolidated. Providing you have some means of handling resource management issues so that you can stop one service monopolizing all the resources on the box, you can consolidate a lot of services onto a single piece of hardware. Not only that, you can afford a better system - more RAS, more power, more memory - so that the services can run faster and more reliably.
Handling cyclical load is another matter. If you have to do something once a month, or once a night, then you normally have a given window in which to do it, and almost by definition the systems used will sit idle the rest of the time. Sure, there's some opportunity to steal CPU and other resource from other machines on your network, but if you want to consolidate then the only opportunity is to find someone else with the same needs but at different times (it's no use if you both want to do the same analysis at the same time!) and share systems with them. (Or, for certain workloads, you have datacenters in different timezones and move the load around the planet as the earth rotates.)
I'm guessing that this is the sort of workload that Sun's recent grid offerings (and grid is one of those words I'll return to in a future blog, no doubt) are designed to address. The business model has to be that if Sun can keep the machines busy then they can make money, and that it's cheaper to buy CPU power when you need it than pay for it and have it sitting idle.
So the grid provision model isn't going to be of any use to customers who have already got high utilization - or, same thing, to customers who have constant workloads. I worked this out for our compute systems and once you get better than 50% (or so - it's only approximate) utilization then it's cheaper to do it yourself. But with utilization much lower than that, it's cheaper to buy the stuff off someone else as you need it.
I wonder who the likely customers are - or what market segment they might be in. In particular, is it going to be large companies or small? If small, there's an opportunity for resellers - brokers, if you like - to act as middlemen, buying large chunks and doing the tasks on behalf of the smaller customers. And while, as I've understood it, Sun are offering capacity in a fairly raw form, smaller end users might be interested in more focused services rather than counting individual cycles.
This could go down to individual consumers once you get into storage. Now, I don't suppose Sun are going to deal with individual consumers, but I know that I would be interested in a gigabyte at a dollar a month for my own critical data. After all, I have a PC and it isn't backed up - and never will be. So I need somewhere to keep this stuff that isn't vulnerable to hardware failure, theft, or user stupidity.
None of this is new, of course. The problem of systems operating inefficiently - at very low utilization levels - has been around for years. It remains to be seen if current initiatives are any more successful than past approaches in getting rid of the horrible inefficiencies we currently put up with.
Normally, this is because you have to overspecify the kit - based on the average load - in order to be able to handle the peaks. Either to give good response on a desktop machine once the user actually does something, or to handle sudden unpredictable surges in demand, or simply because load is cyclical.
(In our case, one case we have to cater for is the case of an instructor standing in front of a class of 20 students and inviting them all to run some interesting application on our servers - at the same time.)
The well-known downside to this is that you end up with a system that's horribly inefficient. Not only do you have to spend much more up front than you really need, you end up burning electricity and running your air conditioning plant round the clock, so the cost is based on the peak load which is usually highly atypical.
There are a range of solutions that can drive up efficiency and equipment utilization - or, more to the point, how to achieve the same (or better) service for customers and users for lower cost.
On the desktop front, thin-client solutions can lead to considerable savings. Not so much in up-front costs any more, but in terms of power and cost of ownership the thin-client starts to make much more sense. In many ways, though, it's more subtle issues like the lower noise and desktop footprint that ought to make this a no-brainer. We've used SunRays (and the hot desking is really useful) with some success, although we've avoided them for developer desktops in the past because developers tend to want to do things like run netbeans, tomcat, apache, mysql and the like, and you can't really have more than one on a machine. But with zones in Solaris 10 we could consolidate developers onto a SunRay server as well.
Many servers sit pretty idle simply because it's been traditional to allocate one server per service. I know we've done this in the past - simply to keep services separate and manageable. Then server sprawl can become a serious problem. Enter Solaris zones again - it looks like you're running one service per machine, but they're all consolidated. Providing you have some means of handling resource management issues so that you can stop one service monopolizing all the resources on the box, you can consolidate a lot of services onto a single piece of hardware. Not only that, you can afford a better system - more RAS, more power, more memory - so that the services can run faster and more reliably.
Handling cyclical load is another matter. If you have to do something once a month, or once a night, then you normally have a given window in which to do it, and almost by definition the systems used will sit idle the rest of the time. Sure, there's some opportunity to steal CPU and other resource from other machines on your network, but if you want to consolidate then the only opportunity is to find someone else with the same needs but at different times (it's no use if you both want to do the same analysis at the same time!) and share systems with them. (Or, for certain workloads, you have datacenters in different timezones and move the load around the planet as the earth rotates.)
I'm guessing that this is the sort of workload that Sun's recent grid offerings (and grid is one of those words I'll return to in a future blog, no doubt) are designed to address. The business model has to be that if Sun can keep the machines busy then they can make money, and that it's cheaper to buy CPU power when you need it than pay for it and have it sitting idle.
So the grid provision model isn't going to be of any use to customers who have already got high utilization - or, same thing, to customers who have constant workloads. I worked this out for our compute systems and once you get better than 50% (or so - it's only approximate) utilization then it's cheaper to do it yourself. But with utilization much lower than that, it's cheaper to buy the stuff off someone else as you need it.
I wonder who the likely customers are - or what market segment they might be in. In particular, is it going to be large companies or small? If small, there's an opportunity for resellers - brokers, if you like - to act as middlemen, buying large chunks and doing the tasks on behalf of the smaller customers. And while, as I've understood it, Sun are offering capacity in a fairly raw form, smaller end users might be interested in more focused services rather than counting individual cycles.
This could go down to individual consumers once you get into storage. Now, I don't suppose Sun are going to deal with individual consumers, but I know that I would be interested in a gigabyte at a dollar a month for my own critical data. After all, I have a PC and it isn't backed up - and never will be. So I need somewhere to keep this stuff that isn't vulnerable to hardware failure, theft, or user stupidity.
None of this is new, of course. The problem of systems operating inefficiently - at very low utilization levels - has been around for years. It remains to be seen if current initiatives are any more successful than past approaches in getting rid of the horrible inefficiencies we currently put up with.
Friday, March 18, 2005
No such thing as a free lunch
Something I've always wondered about are the enormous predictions made for the value of the Linux market in the future. $35bn per annum, or some such. Where's that IT spend going, if the OS is free?
My assumption has always been that it would be in the consultancy market. But, according to Tech News on ZDNet - Open source--open opportunity for consulting - the consultancy firms aren't really moving in for the kill.
While I'm at it, I liked this bit:
The order-of-magnitude cost savings more than justified the consultancy fees and the stranglehold of proprietary hardware architectures was broken forever.
From what I can see, not only do the cost savings rarely justify the consultancy fees, but you get locked into paying the consultancy fees over and over.
Let's face it, the reason Oracle and IBM want to encourage you to use cheaper solutions is not to save you money, it's so you have more cash left over to give them a bigger slice of the pie.
So why aren't consultancies falling over themselves trying to get customers using open source? They have the opportunity - following the previous argument - to save you some money so that they can increase their fees.
And what consultancies thrive on is change and complexity. The latter being a barrier to the former that can only be overcome by the transfer of large fees in their direction. Many commercial packages are outstanding examples of complexity and opaqueness. The suppliers are clearly in league with the consultancies, as you can't just pick up the thing and make it work. (And in cahoots with book publishers and purveyors of training courses at the same time.) And the idea that you could take a new version and just install it, and everything would just work afterwards, with all your customizations carried forward correctly, while maintaining compatibility with older versions of clients and servers, well that's just a dream isn't it?
While commercial packages seem to embrace change and complexity as a matter of policy, open source isn't immune to this disease. Change is often seen as a desirable attribute, compatibility over time and between releases isn't always a high priority, and so there's clearly an opportunity for consultants to step in and manage the process (and taking their fees along the way). Of course, there are examples of companies or products that want to step into this space and help you out.
What is the barrier, though? Is it that those organizations that are predisposed to open source solutions have an inbuilt aversion to consultancy? Or have consultancies worked out that, because they cannot control the change and complexity of open source, that it would actually cost them more?
My assumption has always been that it would be in the consultancy market. But, according to Tech News on ZDNet - Open source--open opportunity for consulting - the consultancy firms aren't really moving in for the kill.
While I'm at it, I liked this bit:
The order-of-magnitude cost savings more than justified the consultancy fees and the stranglehold of proprietary hardware architectures was broken forever.
From what I can see, not only do the cost savings rarely justify the consultancy fees, but you get locked into paying the consultancy fees over and over.
Let's face it, the reason Oracle and IBM want to encourage you to use cheaper solutions is not to save you money, it's so you have more cash left over to give them a bigger slice of the pie.
So why aren't consultancies falling over themselves trying to get customers using open source? They have the opportunity - following the previous argument - to save you some money so that they can increase their fees.
And what consultancies thrive on is change and complexity. The latter being a barrier to the former that can only be overcome by the transfer of large fees in their direction. Many commercial packages are outstanding examples of complexity and opaqueness. The suppliers are clearly in league with the consultancies, as you can't just pick up the thing and make it work. (And in cahoots with book publishers and purveyors of training courses at the same time.) And the idea that you could take a new version and just install it, and everything would just work afterwards, with all your customizations carried forward correctly, while maintaining compatibility with older versions of clients and servers, well that's just a dream isn't it?
While commercial packages seem to embrace change and complexity as a matter of policy, open source isn't immune to this disease. Change is often seen as a desirable attribute, compatibility over time and between releases isn't always a high priority, and so there's clearly an opportunity for consultants to step in and manage the process (and taking their fees along the way). Of course, there are examples of companies or products that want to step into this space and help you out.
What is the barrier, though? Is it that those organizations that are predisposed to open source solutions have an inbuilt aversion to consultancy? Or have consultancies worked out that, because they cannot control the change and complexity of open source, that it would actually cost them more?
Over the Hill
I've been wanting to blog on more personal stuff, and this didn't seem the right place to do it, so I've set up a separate personal blog to allow me to keep my personal ramblings away from here, which is largely Solaris-centric.
Amongst other things, this means that Planet Solaris won't get saturated with my holiday snaps.
Amongst other things, this means that Planet Solaris won't get saturated with my holiday snaps.
Thursday, March 17, 2005
Minimalist Solaris
I've been looking at minimizing a Solaris installation. This has similarities to the work that Eric Boutilier has been doing, with the difference that while he's trying to find the minimum configuration that will actually boot so that you can install 3rd-party software on top to make a viable system, I'm interested in keeping a usable (and manageable) system that can be integrated into our network without additional utilities needing to be installed.
I'm down to 74 packages so far. This seems a lot, I know, but the core install is about a third of that, with the packages necessary for living on our network being another third, and system admin tools being another third again.
Solaris 10 actually needs more packages than previous releases. One reason is the increasing granularity of the package system, so there simply are more packages. Another is that the functionality of Solaris keeps increasing, and more utilities are making use of features outside the basic core. (For example, using XML for system configuration requires you to have an XML parser.)
While my test system got down to 74 packages, I'm typically installing Solaris 10 on machines and ending up with over 800 packages (for one thing, the Java Desktop System has a few hundred). This is getting plain silly.
I think it's got to the point where a flat list of packages has outlived its usefulness. Trying to do installation management with this many packages is impossible. You just have to hope for the best. (I know that Solaris does have package clusters, but these are really just shorthand ways of referring to lists of packages rather than having meaning in their own right.)
One problem with the present system is that you want to be both very specific and very generic. I want to say "Install JDS on a desktop" and "disable and delete this one daemon" with equal ease, and the current flat system doesn't really allow me to do either very well. (Although there are cases when the install granularity has reached the level of individual services.)
So the question that naturally arises is what sort of package management system can be used that will make life easier? I tend to think that it has to be hierarchical, but haven't got much further than that. Note that the question is really one of "how can we best bundle up files into meaningful and easy to manage chunks" rather that asking what software to use to manage those chunks.
I'm down to 74 packages so far. This seems a lot, I know, but the core install is about a third of that, with the packages necessary for living on our network being another third, and system admin tools being another third again.
Solaris 10 actually needs more packages than previous releases. One reason is the increasing granularity of the package system, so there simply are more packages. Another is that the functionality of Solaris keeps increasing, and more utilities are making use of features outside the basic core. (For example, using XML for system configuration requires you to have an XML parser.)
While my test system got down to 74 packages, I'm typically installing Solaris 10 on machines and ending up with over 800 packages (for one thing, the Java Desktop System has a few hundred). This is getting plain silly.
I think it's got to the point where a flat list of packages has outlived its usefulness. Trying to do installation management with this many packages is impossible. You just have to hope for the best. (I know that Solaris does have package clusters, but these are really just shorthand ways of referring to lists of packages rather than having meaning in their own right.)
One problem with the present system is that you want to be both very specific and very generic. I want to say "Install JDS on a desktop" and "disable and delete this one daemon" with equal ease, and the current flat system doesn't really allow me to do either very well. (Although there are cases when the install granularity has reached the level of individual services.)
So the question that naturally arises is what sort of package management system can be used that will make life easier? I tend to think that it has to be hierarchical, but haven't got much further than that. Note that the question is really one of "how can we best bundle up files into meaningful and easy to manage chunks" rather that asking what software to use to manage those chunks.
Sunday, March 13, 2005
What a week
Man I'm tired.
Just spent the week in Palo Alto, officially meeting up regarding the Solaris 10 beta program, so got to meet up with a lot of the Solaris engineers again and talk Solaris, which was fantastic.
Also managed a bit of OpenSolaris activity while I was there, meeting up with some of the Sun people on the project (thanks for lunch, Jim!), but also having a great evening with Ben Rockwood.
I learnt a lot, thought a lot, and it's going to take time to digest it all. But first I must get some sleep.
[And find some warmer clothes. It's warmer here now than when I left a week ago (so it's above freezing), but as anyone in the Bay area knows it's been sunny and very warm all week, making a nice change.]
Just spent the week in Palo Alto, officially meeting up regarding the Solaris 10 beta program, so got to meet up with a lot of the Solaris engineers again and talk Solaris, which was fantastic.
Also managed a bit of OpenSolaris activity while I was there, meeting up with some of the Sun people on the project (thanks for lunch, Jim!), but also having a great evening with Ben Rockwood.
I learnt a lot, thought a lot, and it's going to take time to digest it all. But first I must get some sleep.
[And find some warmer clothes. It's warmer here now than when I left a week ago (so it's above freezing), but as anyone in the Bay area knows it's been sunny and very warm all week, making a nice change.]
Saturday, March 05, 2005
Getting the next bus
So, according to Microsoft and Intel, The Time For 64-Bit is Now.
Strange. We got our first 64-bit Sun back in 1996. We were running 64-bit Solaris on 64-bit sparc cpus in 1998. I think it's 5 years since we had any 32-bit sparc systems running (they largely got canned in the Y2K work - although we did have one or two Ultra 1s or E150s running in 32-bit mode for the first year or so of this millenium). We've been doing 64-bit for years.
Of course, most of our x86 systems are stuck in 32-bit mode, but not my Sun W2100z, which is 64-bit. And damn quick with it.
They might have missed the bus first time around, but you just have to wait awhile and another one turns up.
Strange. We got our first 64-bit Sun back in 1996. We were running 64-bit Solaris on 64-bit sparc cpus in 1998. I think it's 5 years since we had any 32-bit sparc systems running (they largely got canned in the Y2K work - although we did have one or two Ultra 1s or E150s running in 32-bit mode for the first year or so of this millenium). We've been doing 64-bit for years.
Of course, most of our x86 systems are stuck in 32-bit mode, but not my Sun W2100z, which is 64-bit. And damn quick with it.
They might have missed the bus first time around, but you just have to wait awhile and another one turns up.
Friday, March 04, 2005
Snow, glorious snow
Or maybe not. Woke up this morning and it was just starting to snow. Ok, so it snowed hard for a while and we ended up with about an inch of snow. Which is a good fall by local standards.
Of course, this being England it caused total chaos. Schools closed, roads jammed. It's pretty clear now, an hour or so later, and it'll probably rain by lunchtime and wash it all away.
Of course, this being England it caused total chaos. Schools closed, roads jammed. It's pretty clear now, an hour or so later, and it'll probably rain by lunchtime and wash it all away.
Monday, February 28, 2005
Zones in anger
One of the great features in Solaris 10 is Zones: isolated instances of the Operating system hosted - somewhat like a virtual machine or FreeBSD jails - by a master instance of the Operating System.
We've been using zones for a variety of tasks for the best part of a year now. We had our main webserver running in a zone on my workstation for a few days last summer when the original server got hit by a disk failure. Whipping up a quick zone with the same IP address and name as the ailing hardware was much easier and quicker than finding a spare box and setting it up to suit.
Another major use for zones is for development - particularly for websites. You want to run apache/tomcat/mysql, and these want to use standard ports, so you can only run one instance on a host. But you can run this sort of setup in a zone, and the zones are isolated. It's so much easier (and cheaper) to set up a zone than to build up a separate machine (even though whipping up a machine is pretty trivial using jumpstart). And it's easier than futzing the port numbers to get multiple instances coexisting on one system. My own workstation currently has several zones set up for exactly this purpose.
We have a number of servers that are pretty well open to end users. So we're putting these in zones for isolation - if they're compromised then the underlying systems are less exposed and have an extra layer of protection.
The final use of zones that we're deploying - at present - is as a simple form of redundancy. What we have is a service running in a zone on one machine. Then we have an identically configured zone, with the same name and IP address, on a second machine, but not booted. We can switch the service between machines in seconds - that's all it takes to shut the one zone down and boot the other one.
These scenarios have all been tested for the best part of a year; we're now starting to move to live deployment on the full release of Solaris 10.
We've been using zones for a variety of tasks for the best part of a year now. We had our main webserver running in a zone on my workstation for a few days last summer when the original server got hit by a disk failure. Whipping up a quick zone with the same IP address and name as the ailing hardware was much easier and quicker than finding a spare box and setting it up to suit.
Another major use for zones is for development - particularly for websites. You want to run apache/tomcat/mysql, and these want to use standard ports, so you can only run one instance on a host. But you can run this sort of setup in a zone, and the zones are isolated. It's so much easier (and cheaper) to set up a zone than to build up a separate machine (even though whipping up a machine is pretty trivial using jumpstart). And it's easier than futzing the port numbers to get multiple instances coexisting on one system. My own workstation currently has several zones set up for exactly this purpose.
We have a number of servers that are pretty well open to end users. So we're putting these in zones for isolation - if they're compromised then the underlying systems are less exposed and have an extra layer of protection.
The final use of zones that we're deploying - at present - is as a simple form of redundancy. What we have is a service running in a zone on one machine. Then we have an identically configured zone, with the same name and IP address, on a second machine, but not booted. We can switch the service between machines in seconds - that's all it takes to shut the one zone down and boot the other one.
These scenarios have all been tested for the best part of a year; we're now starting to move to live deployment on the full release of Solaris 10.
Saturday, February 26, 2005
Open source, open binaries, or open distribution?
Just to reinforce the point I was making in my previous blog entry, take a look at IT Manager's Journal | Why distribution -- not low cost -- is real advantage of open source.
(And it's predecessor.)
Sun could learn from this. OK, so they've notched up some pretty impressive statistics for Solaris 10 so far. But they're stil very restrictive and in control of the distribution channel, which hurts them (for all their software - not just Solaris, but Java too).. You can't get Solaris from mirrors, you can't get it from the torrent, you can't get it on Magazine covers. And, because you can't redistribute it, Sun can't use other people to promote its software.
(And it's predecessor.)
Sun could learn from this. OK, so they've notched up some pretty impressive statistics for Solaris 10 so far. But they're stil very restrictive and in control of the distribution channel, which hurts them (for all their software - not just Solaris, but Java too).. You can't get Solaris from mirrors, you can't get it from the torrent, you can't get it on Magazine covers. And, because you can't redistribute it, Sun can't use other people to promote its software.
Wednesday, February 23, 2005
Open Source or Open Binaries?
Why is open source - or specifically Linux - successful?
Is it the ideals behind the license? Is open source better software? Or is it simply that most people are cheapskates and want something for nothing?
I think that it's not really any of those. I think it has a lot to do with ease of access.
And getting hold of a copy of Linux is as easy as falling off a log. There are mirrors of dozens of Linux distributions all over the net. So you can download it, for free, without a nag screen or any application process. Or you can get it on the cover of any of half a dozen magazines in your local bookstore. And you can install it - and there's a good chance it will mostly work, after a fashion - on pretty well anything and have a play with it.
And that's the point. It's not that it's got a license that allows you to see how it's done and change it. Most users couldn't care less. It's not that it's better or worse than commercial software. It's not even that it's free - most people will happily pay for something if they think it's worthwhile - but that includes trying it out for free. The important thing is that the barriers to entry - to trying it out - are essentially zero.
Of course, the more people who try something the more are likely to use it. (I find the same thing with games. I'll happily fork out large sums of cash for a PC game if I know I like it, and I find that out by installing the demo version. No demo - no sale.)
And there are other recent open source success stories. Firefox is being used by millions of people, and I'm willing to bet that only a vanishingly small handful have used the source or built it themselves. It's not access to source that matters here, it's being able to get hold of the binaries with ease.
Increasingly, as well, source access is becoming useless. I build a lot of software from source. Or try to, anyway. And it's hard work. Trawling through prerequisites and resolving the dependency hell is almost impossible. (Haven't open source deveoplers heard of the concept of stable APIs?) Then you have to watch configure make a large bunch of wild and unsubstantiated guesses about the state of your system and then libtool demonstrate how not to build software. And (at a time when the diversity of systems used to be much greater) we used to manage without all this. It used to take a simple make and you were done. No more. Failure is now more common than success.
There are initiatives that aim to address these issues. For Solaris, Sun supply some software with the OS itself, and additional material on the companion CD. Then there's sunfreeware and blastwave. In both cases someone else has had to suffer the pain (and the build time...). Then gentoo and portaris aim to automate the build process. And Eric Boutillier is actively investigating pkgsrc based solutions.
With these last few exceptions, though, it seems that the source part of open source is becoming irrelevant, and what matters is open access to binaries.
Is it the ideals behind the license? Is open source better software? Or is it simply that most people are cheapskates and want something for nothing?
I think that it's not really any of those. I think it has a lot to do with ease of access.
And getting hold of a copy of Linux is as easy as falling off a log. There are mirrors of dozens of Linux distributions all over the net. So you can download it, for free, without a nag screen or any application process. Or you can get it on the cover of any of half a dozen magazines in your local bookstore. And you can install it - and there's a good chance it will mostly work, after a fashion - on pretty well anything and have a play with it.
And that's the point. It's not that it's got a license that allows you to see how it's done and change it. Most users couldn't care less. It's not that it's better or worse than commercial software. It's not even that it's free - most people will happily pay for something if they think it's worthwhile - but that includes trying it out for free. The important thing is that the barriers to entry - to trying it out - are essentially zero.
Of course, the more people who try something the more are likely to use it. (I find the same thing with games. I'll happily fork out large sums of cash for a PC game if I know I like it, and I find that out by installing the demo version. No demo - no sale.)
And there are other recent open source success stories. Firefox is being used by millions of people, and I'm willing to bet that only a vanishingly small handful have used the source or built it themselves. It's not access to source that matters here, it's being able to get hold of the binaries with ease.
Increasingly, as well, source access is becoming useless. I build a lot of software from source. Or try to, anyway. And it's hard work. Trawling through prerequisites and resolving the dependency hell is almost impossible. (Haven't open source deveoplers heard of the concept of stable APIs?) Then you have to watch configure make a large bunch of wild and unsubstantiated guesses about the state of your system and then libtool demonstrate how not to build software. And (at a time when the diversity of systems used to be much greater) we used to manage without all this. It used to take a simple make and you were done. No more. Failure is now more common than success.
There are initiatives that aim to address these issues. For Solaris, Sun supply some software with the OS itself, and additional material on the companion CD. Then there's sunfreeware and blastwave. In both cases someone else has had to suffer the pain (and the build time...). Then gentoo and portaris aim to automate the build process. And Eric Boutillier is actively investigating pkgsrc based solutions.
With these last few exceptions, though, it seems that the source part of open source is becoming irrelevant, and what matters is open access to binaries.
Wednesday, February 16, 2005
Diversity, Choice, Competition
In a LinuxInsider Linux News Commentary, Open-Source Projects Are Not All the Same, Frank Hayes makes the important point that, while both Linux and OpenSolaris are both really Open Source, they differ in important ways. Different models, different communities, different licenses. Diversity is good; competition can only improve both.
The article has a couple of errors though.
The first error is the statement that:
But those patents can only be used with Sun's code. Changing the code means losing the patent protection.
Which is plain wrong. The patent protection stays with the code. That's the whole point of the CDDL.
The second is the statement that both are competing for the attentions of the same developers. They aren't (and it continues the myth that Linux is a volunteer project - interestingly, the OpenSolaris community outside of Sun does have a lot of individuals rather than being largely corporate).
In the same vein, James Governor makes the point that there is no single Open Source Community. There are lots of communities. And, when asked
Don't other open source communities wonder at the vocal minority of Linux fans talking for them?
Yes, we do! But it's not Linux fans, as such - it's just a noisy minority who presume (incorrectly) to speak for the community.
There's not just choice and diversity in code and licenses. There's choice and competition from different products. Like the recently released Solaris 10 and Red Hat's RHEL4. Our friend SJVN builds this up as a great battle with this provocative quote:
"It's the beginning of the end for Solaris in the enterprise,"
The reality is somewhat different - Solaris is wildly popular, while RHEL4 isn't exactly bowling all reviewers over. The reality is that both are going to be around, and have success, for a long while.
Technorati: OpenSolaris - Technorati: Solaris
The article has a couple of errors though.
The first error is the statement that:
But those patents can only be used with Sun's code. Changing the code means losing the patent protection.
Which is plain wrong. The patent protection stays with the code. That's the whole point of the CDDL.
The second is the statement that both are competing for the attentions of the same developers. They aren't (and it continues the myth that Linux is a volunteer project - interestingly, the OpenSolaris community outside of Sun does have a lot of individuals rather than being largely corporate).
In the same vein, James Governor makes the point that there is no single Open Source Community. There are lots of communities. And, when asked
Don't other open source communities wonder at the vocal minority of Linux fans talking for them?
Yes, we do! But it's not Linux fans, as such - it's just a noisy minority who presume (incorrectly) to speak for the community.
There's not just choice and diversity in code and licenses. There's choice and competition from different products. Like the recently released Solaris 10 and Red Hat's RHEL4. Our friend SJVN builds this up as a great battle with this provocative quote:
"It's the beginning of the end for Solaris in the enterprise,"
The reality is somewhat different - Solaris is wildly popular, while RHEL4 isn't exactly bowling all reviewers over. The reality is that both are going to be around, and have success, for a long while.
Technorati: OpenSolaris - Technorati: Solaris
Saturday, February 12, 2005
I bought the book
Today, I bought the book.
Not just any old book, the book.
I've been meaning to get down the shops and buy it since getting some cash over Christmas, but what with a busy life and a bout of the flu, it's taken a lot longer than I planned.
For those of you not paying attention, we're talking about this book.
Technorati: Solaris
Not just any old book, the book.
I've been meaning to get down the shops and buy it since getting some cash over Christmas, but what with a busy life and a bout of the flu, it's taken a lot longer than I planned.
For those of you not paying attention, we're talking about this book.
Technorati: Solaris
Thursday, February 10, 2005
SMF setup for postfix
57 up
So I now have 57 machines running Solaris 10, including most of our compute farm.
The latest machine was our mail server. It's a complicated beast, running postfix, spamassasin, amavis, sophos, sophie, clamav, freshclam, pop, imap, pop-before-smtp, gld, mysql, TLS, SASL...
You get the idea. It's a fairly complex setup. And it's all managed by smf. We're going to do a little writeup of this - stay tuned!
We did have one glitch. Looks like lockd (the nlockmgr service) doesn't always register properly with rpcbind. This caused command line mail clients like mail and mutt running on older machines to hang. (Solaris 10 clients were fine because they're using NFSv4 which handles the locking itself.) Having identified this, a quick
brought everything back to life.
Technorati: Solaris
The latest machine was our mail server. It's a complicated beast, running postfix, spamassasin, amavis, sophos, sophie, clamav, freshclam, pop, imap, pop-before-smtp, gld, mysql, TLS, SASL...
You get the idea. It's a fairly complex setup. And it's all managed by smf. We're going to do a little writeup of this - stay tuned!
We did have one glitch. Looks like lockd (the nlockmgr service) doesn't always register properly with rpcbind. This caused command line mail clients like mail and mutt running on older machines to hang. (Solaris 10 clients were fine because they're using NFSv4 which handles the locking itself.) Having identified this, a quick
svcadm restart svc:/network/nfs/nlockmgr:default
brought everything back to life.
Technorati: Solaris
Monday, February 07, 2005
Solaris mirror resyncs
Most of our servers have mirrored root disks, and so when I install them (which I've been doing a lot of this last week) I need to resync the mirrors (set up during jumpstart). The default settings in Solaris Volume Manager can lead to pretty long resync times, and the way to speed it up [taken straight out of the metasync(1M) manpage] is to add the following
to your /etc/system file (I do this in my jumpstart finish script). This works for Solaris 10 (which is of course what I'm installing eeverything with now!).
This speeds up the resync quite nicely. In fact, the data rate during resync seems to be almost the same in megabytes/s as the disk size in gigabytes (this might just be a coincidence and valid only for the restricted range of hardware I've tested). But this leads to the resync time being pretty well constant.
With the default SVM settings, I almost always saw 8 megabytes/s, which is pathetic for modern disks, and the resync could take hours. Now it's nice and quick.
Technorati: Solaris
*
* speed up mirror resync
*
set md_mirror:md_resync_bufsz = 2048
to your /etc/system file (I do this in my jumpstart finish script). This works for Solaris 10 (which is of course what I'm installing eeverything with now!).
This speeds up the resync quite nicely. In fact, the data rate during resync seems to be almost the same in megabytes/s as the disk size in gigabytes (this might just be a coincidence and valid only for the restricted range of hardware I've tested). But this leads to the resync time being pretty well constant.
With the default SVM settings, I almost always saw 8 megabytes/s, which is pathetic for modern disks, and the resync could take hours. Now it's nice and quick.
Technorati: Solaris
Friday, February 04, 2005
Solaris 10 installs rolling
Having finally managed to haul Solaris 10 across the network, installs are proceeding well. I've now got over 30 machines running Solaris 10. It's gone pretty well without a hitch so far. More machines are being installed in a steady stream.
(The only irritating thing is that JDS now does wireframe window moves rather than opaque window moves. Anyone know how to switch this around?)
Technorati: Solaris
(The only irritating thing is that JDS now does wireframe window moves rather than opaque window moves. Anyone know how to switch this around?)
Technorati: Solaris
Tuesday, February 01, 2005
Way too popular
Solaris 10 is way too popular. I've been fetching it all day and not got halfway yet. I'm getting a measly fraction of my normal download speed. Not good. (For me, that is - obviously it's good for Solaris to see so many downloads.)
Loooks like I'll have to leave it overnight.
Technorati: Solaris
Loooks like I'll have to leave it overnight.
Technorati: Solaris
Subscribe to:
Posts (Atom)