Not another version already! I only brought 6.3 to upgrade from 6.1 about 3 weeks ago. Why so many versions? What value do we really get between them? I've not seen a list of what's in the new kit, but thinking about it -- 2.2.15 isn't out yet, so they can only have gone up one version of the kernel. Same with XFree86 as 4.0 is too new yet to go mainstream.
Maybe they've made some improvements with the sys admin features in Yast. Yast was good when it first came out, but has fallen way behind the competition in features and ease of use. I hope so anyway. Either that or they should dump it and go with Linuxconf.
This time I think I'll out-psyche myself. I'll buy it as soon as it's out so that the gap between the next version at least *seems* a bit longer.
All you "bash/zsh is best" folks are missing an important point. ksh is the POSIX standard shell. You can virtually guarantee that a ksh script you write on one platform will run on any other platform with ksh (providing you cater for possible path name differences in external commands, but that's not a ksh problem). Add to this the fact that *every* commercial unix platform ships with ksh and its easy to see why ksh is THE standard for writing shell scripts in the commercial world. So I'm extremely happy that I can get a copy of this now for my home Linux systems.
I personally think that the Linux community is aiming too low here. High Availability failover services are just about to become yesterdays technology. Take a look at where Compaq are taking their Tru64 Unix clustering.
... A cluster "system" disk, containing a common/usr for all systems (each cluster member has its own root and swap, also on shared storage).
... Cluster Common Filesystem. All filesystems mounted on any cluster member appear in the mount tables on all systems. Even filesystems on private buses (eg: CD-ROM's)
... Context Dependant Symbolic links, eg:/etc/{memb}/blah/... where {memb} is mapped to the cluster member ID. From a members perspective the filesystem structure adheres to tradition, when in reality system specific parts of the filesystem are held independantly.
... Install the OS once and the Cluster software once. Adding new cluster members (out of the box, with no installed OS) takes only 10 minutes.
... Install an application only once and all members can run it.
... Cluster member numbers factored into PID numbers (init is no longer PID 1) creating unique cluster wide PID's. Helps in cluster process management, but more importantly, paves the way for future advances in "process" failover between cluster members. IMHO this is the holy grail for future cluster technology.
... DLM (distributed lock manager) out of the box. Applications like Oracle Parallel Service should be a lot easier to build, run an maintain in future.
There are a good number of other features, but this is enough to get the point across. There is a big difference between what is "called" clustering in the UNIX world right now (which is not much more than fast hot standby failover) and what clustering was meant to be. VMS has had it for years. Compaq's Tru64 UNIX is on the cusp of getting it (first production quality release is TruCluster v5.0a, due I believe within a month or two).
THIS is what Linux Clustering needs to be aiming for. Not playing catch up with existing failover technology, because that will soon go the way of the dinosaurs.
Ever seen a lot of the KDE/Qt apps? They say, "Don't use such and such a version of Qt because it's not ready yet or the APIs are different" and so on. It's the same thing for Qt, it's just that there are probably a lot of GTK+ apps out there that haven't been updated yet. That's not the toolkits fault.
That's a totally unfair comment and borders on FUD. KDE draws very clear distinctions between development versions and released versions. Development versions are not released to the general public in the same way they are for released versions. Released versions are available in tar/rpm/deb (is that right for Debian?) format, normally from the different Linux vendors. The development versions are also publicly available, but from CVS. The only exception to this was the KRASH pre-release of KDE 2.0, which if you read the announcment states very clearly that this is ONLY for developers to get a taste of what's coming. They even go as far as saying to vendors that they must only include KRASH if they also include a copy of the current production version, KDE 1.1.2. Also, I have yet to come across a KDE app that I've tried out in the last 6 months that hasn't worked with KDE 1.1.2. You need to read up on KDE more before making statements like this. Macka
I think it would be a good idea for the likes of Mandrake and Redhat to take a look at this, find the places where LinuxOne plant their name in distribution and bury some code to force a crash or shutdown if it's found. Doesn't sound to me like these guys have got the brains to track this sort of thing down if the real distros are sneaky about it.
I was in the Ukraine a couple of years ago for a 2 week trip to see a friend and do some touring around. With the sole exception of Kiev (the capital) at 5pm each night, for about 2 hours, the power would be cut. That's a country wide blackout! And the only reason for it was that they couldn't afford to provide electricity 24 hours a day. Bearing in mind that most of the population get round on electically powered Trolly Buses (Trams to you and I) everything just about grinds to a halt. I don't think things have improved much since then, if at all.
Talking of old systems and games, I remember playing VTtrek (I'm sure that's what it was called) oooh, 12 years ago, or there abouts on what was at the time a huge TOPS 10 or TOPS 20 system. That was the first multi-user game I ever came across.
I wonder if anyone ever ported that or did a TOPS emulator.
I hate to take issue with a well-spoken posting, but journalling is not of primary usefulness for helping support High Availability RDBMS systems.
I'm sorry to disagree, but you're very very wrong here. The fact that Reiserfs is fast (if the article is true) as a filesystem for manipulating ordinary files is not what's important (though it's a big plus in many configurations). Nor is how a database manipulates its data relevant. It's how quickly the filesystem is recovered after a failure that's the primary benefit. I've delt with many hundreds of customers over the last 4-5 years that have brought systems for the sole purpose of running databases on Journalling filesystems.
On multi system High Availability configurations of the type that run database application services designed to failover from one system to the next, a journaling filesystem is essential. Unless it's controlled by an administrator, when a service moves from one system to another it's because of some kind of system failure and in this situation the filesystem is not unmounted cleanly. With a journaling FS, recovery is quick, measured in seconds. For a non journaling filesystem recovery could take hours. I've even seen one (very stupidly configured) customer system (100+ GB's) where this took days. If it takes more than a few seconds to recover, then it's not High Availability.
Note that for these, the metadata is very static which means that journalling of metadata is of relatively little importance.
It doesn't matter if the metadata is static or not. If the database sits on filesystem that isn't journalled it will have to be fsck'd regardless and will take almost as long to fsck as a filesystem that isn't as static.
As you rightly pointed out, the only other option is not to have a filesystem at all and drop the database into a RAW partition. In this case all bets are off as the stability and recovery time of a database after a system failure is up to the implementation specific design of the database vendor.
So Digital UNIX (actually called Tru64 UNIX) is dead now huh? Strange that, as they just announced a $100 million marketing campaign to promote its growth.
I guess the folks at Compaq just like throwing good money after bad (NOT).
Actually, the hardest (or most time consuming) part of jumping around commercial unicies is getting to know the proprietary hardware they run on. Oh, that and the different System Admin tools that use.
Even if they gave the TruCluster software and license away, you'd still have to fork out for two Alpha's, shared storage, and memory channel (cards and a hub). Unlike earlier versions of TruCluster, Memory channel is a prerequisite for V5.0 because of the new Cluster Common Filesystem. I don't have figures for these things in front of me, but the bare minimum cost has got to be over $10K for the lot. Not really in the price range of a hobbyist/home enthusiast.
I have a friend, now a mother of two, who was a Police Woman when I first met her. Despite dating anything but Police Men, when she eventualy decided to settle that's exactly what she picked. When I asked her why she replied: Being a Police Man/Woman has its own unique kind of pressures and problems. Who better to understand and support me when I come home after a bad day (had a murder or similar). Someone in another profession just wouldn't be able to relate in the same way.
My present partner isn't a techie, or a geek. She's a sales manager for a software company. But being in the same industry she understands the long hours (puts them in herself) and the type of job I do. I've had previous partners from totally different walks of life that didn't understand my job, or the amount of time I spend on Linux and resented it.
So I think there's something to be said for someone who perhaps shares ones interests or at least can relate to it in some way.
I love reading explanations like that. Leaves no room for doubt.
Re:KDE becomes more and more like closed software
on
KDE Looks Ahead
·
· Score: 2
At it's birth, the goal of the KDE project was to create a desktop where all apps used one common widget set. Making it play friendly with other Open Source desktop projects was never on the radar until IMO it became a political goal.
As far as I'm concerned, the new changes will promote speed, cut code bloat, and made KDE applications easier to write. Those advantages far outweigh any benefits gained by pursuing interoperability with non-KDE software.
The KDE team should not tie themselves to GNOME if the result produces an inferior product.
Whether this is true or not is neither here nor there. But the only way to play safe and avoid being 'shafted' by a commercial offering is to stick with Open Source where possible. Me, I'm waiting for KOffice. Star Office doesn't even appear on my radar.
Forget the legal system for a sec and think about this.
In order for an end user to read a site of mine, their system must establish a link to my system and then data is transfered directly from me to them. If I have a link on the page they've just 'downloaded' that points to an MP3 somewhere, and that user follows that link, then their system connects directly to the new destination. They don't go via my system to get there, and the MP3 doesn't travel via my system to on route back to them. Once the end user has a copy of my page on their system I'm cut out of the loop completely.
A URL is no more than a sign post, something that provides the browser with a route to a destination. How on earth can anyone be sued for that? It's obviously the work of some semi technically literate lawyer who thinks he's onto a nice little earner.
I remember reading some time ago, when the KDE and GNOME flame wars were at their height, the sane and sensible voices were calling for the arguments to stop, and instead to let KDE and GNOME slug it out in the only arena that matters -- `code'.
Which ever product has the best code -- the most functionality -- the most stability, is the one that will dominate the Linux desktop.
I've just done a 2 day intro course on these products and based on what I've learned I'd have to say that chucking out the Tru64 kernel and replacing it with Linux is IMO not yet an option.
This is the biggest leap in technology that Tru64 has made during it's life so far, and the jewel in the crown for V5 has got to be the new filesystem, CFS (Cluster File System).
With CFS, not only can every system in the cluster see all the devices on the shared SCSI bus, but also all the devices on all the private SCSI buses too. When one system mounts a device, this appears in the mount table for all the cluster members.
The thing is that CFS is bound so closely to UNIX V5 and the kernel, that even on a standalone V5 system with no clustering there are tell tale signs that dormant cluster software is waiting with hooks at the ready. You can see this in the file system. For example an ls -l of/etc/binlog.conf shows:
Btw, {memb} is something new too. It's called a CDSL (context dependant symbolic link) and in this case resolves to "member0", changing the number where the cluster member number is different.
While I'm at this I can't resist telling you how clusters are installed, cos this was really neat too.
When installing a cluster you start off with one disk, which can be either local or shared, and install Tru64 UNIX on that. Then install the TruCluster software and select two disks on the shared SCSI, one for the Cluster disk and one for the system (member0) boot disk. When you run "clu_create" Tru64 UNIX is copyied from your current disk to the cluster disk and the boot disk containing the root f/s for member0. You then shutdown and boot of the boot disk. Hey presto, you're a 1 system cluster. The first disk you used can be junked now and reused for something else.
Want to add more members? No problem. You need to assign boot disks for each one, then run clu_add_member for each system. A system specific root is added to each, and member specific directories are setup on the common Cluster Disk. At this point you could take all your new systems out of their boxes, cable them up (though in practice you'd have done this first) power them on and then boot them straight off their new boot disks. No installation needed:-)
The whole process is so quick we reckoned we could install and cluster of 4 x DS20's from scratch in about 1.5 hours.
I could ramble on now about the new System Management Station, that can be driven from a curses front end, a CDE GUI front end, or even a Java version of the CDE GUI from a Web browser. I could wax lyrical about the dynamicly updated pictorial system maps of the systems, their devices, buses, cluster members, etc, the new Event Manager, and lots of other things. But I reckon I've taken up enough of your time.
To wrap up I'd like to say that I think it would be very cool (and cost effective in the long term) if the Linux kernel could replace Tru64's. But I don't see that happening just yet, not for the next couple of years anyway.
Well first off I have to eat my hat, as I'd previously posted that I thought Win64 development was still on track when I replied to the first Slashdot article on this subject. I was quite wrong.
However, the decsion from Compaq and Microsoft to drop NT on Alpha is really a shining example of why Open Source projects like Linux, Apache, KDE, etc, are such a good bet for customers. They aren't owned by one entity, aren't developed on the strength of product sales, and can't be withdrawn from the market without regard for what the users and customers think.
The Linux world would be a better place if all distributions used the same package format, the same system management tools and followed the same filesystem standard. The fact that they don't will not stop Linux growth or acceptance, but it won't help it either.
As for ESR's speculation that Compaq will eventually move from Tru64 UNIX to Linix, well, I'm normally with ESR on most things, but on this one I think he's way off base. For the next few years at least. My reasons for this are:
* The Linux kernel has some way to go yet on the scalability front before it could be considered a potential replacement for Tru64's kernel. Compaqs next generation Wildfire systems will be out soon, with possible configurations of up to 256 CPU's. Tru64 V5.* can scale that high and make good use of it. The Linux kernel will need to be able to match that.
* No one does clustering like Compaq's VMS clusters, and now Tru64 UNIX is getting the same functionality. This puts Compaq's UNIX way out ahead of any other UNIX with the rest of the field (and NT) left behind with failover style clustering. Porting TruCluster V5 functionality to Linux would be a big job. New drivers for the cluster software, new hardware (Memory Channel), the new Cluster common FileSystem, the advanced filesystem (AdvFS), etc. I just can't see Compaq wanting to Open Source any of this, as it's what will set them apart from the competition.
Not so fast folks. Compaq have not made any statements about the end of NT or Alpha, and the reality of the layoffs is quite different from the press spin on it.
The engineers layed off worked on the NT4 port to Alpha. That is done and dusted, there is no more work to be done in that field now. The next Alpha NT move is to Win64, and that port is being developed and driven entirely in-house at Microsoft.
NT is not dead on Alpha. If Windows 2000 scales as well as Microsoft are predicting, and the Win64 Alpha version gets finished as planned, then a lot of companies are going to be very interested in combining this with the horsepower Compaqs imminent Wildfire (Alpha) platform provides. If anything it will put NT Alpha in more direct competition with big UNIX systems, an area of competition it's been denied so far due to NT's lack of scalability.
Alpha also has a very rosey future. A.18 micron shrink is in the works (possibly with copper interconnects) which will have two benefits. 1) a significant leap in MHz, way over the 1GHz milestone. 2) A significant reduction in price (smaller die = more per wafer). When Merced ships Alpha will be significantly faster, smaller and cheeper! Alpha still rules the 64 bit roost, and nothing else in the 64bit market looks like getting anywhere close to it in price/performance.
This story about the end of Alpha NT is just that, a story. Pure press fiction and FUD.
I'm not sure about that. I thought that SCO held the no: 1 slot in terms of licenses or units shipped (though not in revenue). I also remember reading something recently (though I don't remember which eZine it was on) which said that the Monterey triad (IBM + SCO + Sequent) will command over 50% of the commercial UNIX market when it ships. Well, they didn't say commercial in the article, but they didn't mention any of the free *ix's, so that's my spin on it.
Slashdot Mirror
Not another version already! I only brought 6.3 to upgrade from 6.1 about 3 weeks ago. Why so many versions? What value do we really get between them? I've not seen a list of what's in the new kit, but thinking about it -- 2.2.15 isn't out yet, so they can only have gone up one version of the kernel. Same with XFree86 as 4.0 is too new yet to go mainstream.
Maybe they've made some improvements with the sys admin features in Yast. Yast was good when it first came out, but has fallen way behind the competition in features and ease of use. I hope so anyway. Either that or they should dump it and go with Linuxconf.
This time I think I'll out-psyche myself. I'll buy it as soon as it's out so that the gap between the next version at least *seems* a bit longer.
Macka
All you "bash/zsh is best" folks are missing an important point. ksh is the POSIX standard shell. You can virtually guarantee that a ksh script you write on one platform will run on any other platform with ksh (providing you cater for possible path name differences in external commands, but that's not a ksh problem). Add to this the fact that *every* commercial unix platform ships with ksh and its easy to see why ksh is THE standard for writing shell scripts in the commercial world. So I'm extremely happy that I can get a copy of this now for my home Linux systems.
Macka
> Applications like Oracle Parallel Service
Whoops, typo. That should be Oracle Parallel Server.
Macka
I personally think that the Linux community is aiming too low here. High Availability failover services are just about to become yesterdays technology. Take a look at where Compaq are taking their Tru64 Unix clustering.
/usr for all systems (each cluster member has its own root and swap, also on shared storage).
/etc/{memb}/blah/... where {memb} is mapped to the cluster member ID. From a members perspective the filesystem structure adheres to tradition, when in reality system specific parts of the filesystem are held independantly.
... A cluster "system" disk, containing a common
... Cluster Common Filesystem. All filesystems mounted on any cluster member appear in the mount tables on all systems. Even filesystems on private buses (eg: CD-ROM's)
... Context Dependant Symbolic links, eg:
... Install the OS once and the Cluster software once. Adding new cluster members (out of the box, with no installed OS) takes only 10 minutes.
... Install an application only once and all members can run it.
... Cluster member numbers factored into PID numbers (init is no longer PID 1) creating unique cluster wide PID's. Helps in cluster process management, but more importantly, paves the way for future advances in "process" failover between cluster members. IMHO this is the holy grail for future cluster technology.
... DLM (distributed lock manager) out of the box. Applications like Oracle Parallel Service should be a lot easier to build, run an maintain in future.
There are a good number of other features, but this is enough to get the point across. There is a big difference between what is "called" clustering in the UNIX world right now (which is not much more than fast hot standby failover) and what clustering was meant to be. VMS has had it for years. Compaq's Tru64 UNIX is on the cusp of getting it (first production quality release is TruCluster v5.0a, due I believe within a month or two).
THIS is what Linux Clustering needs to be aiming for. Not playing catch up with existing failover technology, because that will soon go the way of the dinosaurs.
Macka
That's a totally unfair comment and borders on FUD. KDE draws very clear distinctions between development versions and released versions. Development versions are not released to the general public in the same way they are for released versions. Released versions are available in tar/rpm/deb (is that right for Debian?) format, normally from the different Linux vendors. The development versions are also publicly available, but from CVS. The only exception to this was the KRASH pre-release of KDE 2.0, which if you read the announcment states very clearly that this is ONLY for developers to get a taste of what's coming. They even go as far as saying to vendors that they must only include KRASH if they also include a copy of the current production version, KDE 1.1.2. Also, I have yet to come across a KDE app that I've tried out in the last 6 months that hasn't worked with KDE 1.1.2. You need to read up on KDE more before making statements like this. Macka
I think it would be a good idea for the likes of Mandrake and Redhat to take a look at this, find the places where LinuxOne plant their name in distribution and bury some code to force a crash or shutdown if it's found. Doesn't sound to me like these guys have got the brains to track this sort of thing down if the real distros are sneaky about it.
Macka
I was in the Ukraine a couple of years ago for a 2 week trip to see a friend and do some touring around. With the sole exception of Kiev (the capital) at 5pm each night, for about 2 hours, the power would be cut. That's a country wide blackout! And the only reason for it was that they couldn't afford to provide electricity 24 hours a day. Bearing in mind that most of the population get round on electically powered Trolly Buses (Trams to you and I) everything just about grinds to a halt. I don't think things have improved much since then, if at all.
Macka
I'd like to throw my weight behind this one, as I'd like
to know what web standards Konqueror is aiming for as
well.
Macka
Talking of old systems and games, I remember playing VTtrek (I'm sure that's what it was called) oooh, 12 years ago, or there abouts on what was at the time a huge TOPS 10 or TOPS 20 system. That was the first multi-user game I ever came across.
I wonder if anyone ever ported that or did a TOPS emulator.
Macka
I'm sorry to disagree, but you're very very wrong here. The fact that Reiserfs is fast (if the article is true) as a filesystem for manipulating ordinary files is not what's important (though it's a big plus in many configurations). Nor is how a database manipulates its data relevant. It's how quickly the filesystem is recovered after a failure that's the primary benefit. I've delt with many hundreds of customers over the last 4-5 years that have brought systems for the sole purpose of running databases on Journalling filesystems.
On multi system High Availability configurations of the type that run database application services designed to failover from one system to the next, a journaling filesystem is essential. Unless it's controlled by an administrator, when a service moves from one system to another it's because of some kind of system failure and in this situation the filesystem is not unmounted cleanly. With a journaling FS, recovery is quick, measured in seconds. For a non journaling filesystem recovery could take hours. I've even seen one (very stupidly configured) customer system (100+ GB's) where this took days. If it takes more than a few seconds to recover, then it's not High Availability.
It doesn't matter if the metadata is static or not. If the database sits on filesystem that isn't journalled it will have to be fsck'd regardless and will take almost as long to fsck as a filesystem that isn't as static.As you rightly pointed out, the only other option is not to have a filesystem at all and drop the database into a RAW partition. In this case all bets are off as the stability and recovery time of a database after a system failure is up to the implementation specific design of the database vendor.
Macka
You can get a full working KDE 1.1.2 build for Tru64 UNIX now. Built for v4.0f, but it should run on V5 without changes.
/ dist
ftp://finwds01.tu-graz.ac.at/pub/kde/tru64_4.0x
Macka
So Digital UNIX (actually called Tru64 UNIX) is dead now huh? Strange that, as they just announced a $100 million marketing campaign to promote its growth.
I guess the folks at Compaq just like throwing good money after bad (NOT).
Macka
Actually, the hardest (or most time consuming) part of jumping around commercial unicies is getting to know the proprietary hardware they run on. Oh, that and the different System Admin tools that use.
Macka
Even if they gave the TruCluster software and license away, you'd still have to fork out for two Alpha's, shared storage, and memory channel (cards and a hub). Unlike earlier versions of TruCluster, Memory channel is a prerequisite for V5.0 because of the new Cluster Common Filesystem. I don't have figures for these things in front of me, but the bare minimum cost has got to be over $10K for the lot. Not really in the price range of a hobbyist/home enthusiast.
Macka
I have a friend, now a mother of two, who was a Police Woman when I first met her. Despite dating anything but Police Men, when she eventualy decided to settle that's exactly what she picked. When I asked her why she replied: Being a Police Man/Woman has its own unique kind of pressures and problems. Who better to understand and support me when I come home after a bad day (had a murder or similar). Someone in another profession just wouldn't be able to relate in the same way.
My present partner isn't a techie, or a geek. She's a sales manager for a software company. But being in the same industry she understands the long hours (puts them in herself) and the type of job I do. I've had previous partners from totally different walks of life that didn't understand my job, or the amount of time I spend on Linux and resented it.
So I think there's something to be said for someone who perhaps shares ones interests or at least can relate to it in some way.
Macka
I love reading explanations like that. Leaves no room for doubt.
At it's birth, the goal of the KDE project was to create a desktop where all apps used one common widget set. Making it play friendly with other Open Source desktop projects was never on the radar until IMO it became a political goal.
As far as I'm concerned, the new changes will promote speed, cut code bloat, and made KDE applications easier to write. Those advantages far outweigh any benefits gained by pursuing interoperability with non-KDE software.
The KDE team should not tie themselves to GNOME if the result produces an inferior product.
Macka
Whether this is true or not is neither here nor there. But the only way to play safe and avoid being 'shafted' by a commercial offering is to stick with Open Source where possible. Me, I'm waiting for KOffice. Star Office doesn't even appear on my radar.
Macka
Forget the legal system for a sec and think about this.
In order for an end user to read a site of mine, their system must establish a link to my system and then data is transfered directly from me to them. If I have a link on the page they've just 'downloaded' that points to an MP3 somewhere, and
that user follows that link, then their system connects directly to the new destination. They don't go via my system to get there, and the MP3 doesn't travel via my system to on route back to them. Once the end user has a copy of my page on their system I'm cut out of the loop completely.
A URL is no more than a sign post, something that provides the browser with a route to a destination. How on earth can anyone be sued for that? It's obviously the work of some semi technically literate lawyer who thinks he's onto a nice little earner.
Macka
I remember reading some time ago, when the KDE and GNOME flame wars were at their height, the sane and sensible voices were calling for the arguments to stop, and instead to let KDE and GNOME slug it out in the only arena that matters -- `code'.
;-)
Which ever product has the best code -- the most functionality -- the most stability, is the one that will dominate the Linux desktop.
I know which one I think is best
Macka
I've just done a 2 day intro course on these products and based on what I've learned I'd have
/etc/binlog.conf shows:
../cluster/members/{memb}/etc/binlog.conf
:-)
to say that chucking out the Tru64 kernel and replacing it with Linux is IMO not yet an option.
This is the biggest leap in technology that Tru64 has made during it's life so far, and the jewel in the crown for V5 has got to be the new filesystem, CFS (Cluster File System).
With CFS, not only can every system in the cluster see all the devices on the shared SCSI bus, but also all the devices on all the private SCSI buses too. When one system mounts a device, this appears in the mount table for all the cluster members.
The thing is that CFS is bound so closely to UNIX V5 and the kernel, that even on a standalone V5 system with no clustering there are tell tale signs that dormant cluster software is waiting with hooks at the ready. You can see this in the file system. For example an ls -l of
binlog.conf ->
Btw, {memb} is something new too. It's called a CDSL (context dependant symbolic link) and in this case resolves to "member0", changing the number where the cluster member number is different.
While I'm at this I can't resist telling you how clusters are installed, cos this was really neat too.
When installing a cluster you start off with one disk, which can be either local or shared, and install Tru64 UNIX on that. Then install the TruCluster software and select two disks on the shared SCSI, one for the Cluster disk and one for the system (member0) boot disk. When you run "clu_create" Tru64 UNIX is copyied from your current disk to the cluster disk and the boot disk containing the root f/s for member0. You then shutdown and boot of the boot disk. Hey presto, you're a 1 system cluster. The first disk you used can be junked now and reused for something else.
Want to add more members? No problem. You need to assign boot disks for each one, then run clu_add_member for each system. A system specific root is added to each, and member specific directories are setup on the common Cluster Disk. At this point you could take all your new systems out of their boxes, cable them up (though in practice you'd have done this first) power them on and then boot them straight off their new boot disks. No installation needed
The whole process is so quick we reckoned we could install and cluster of 4 x DS20's from scratch in about 1.5 hours.
I could ramble on now about the new System Management Station, that can be driven from a curses front end, a CDE GUI front end, or even a Java version of the CDE GUI from a Web browser. I could wax lyrical about the dynamicly updated pictorial system maps of the systems, their devices, buses, cluster members, etc, the new Event Manager, and lots of other things. But I reckon I've taken up enough of your time.
To wrap up I'd like to say that I think it would be very cool (and cost effective in the long term) if the Linux kernel could replace Tru64's. But I don't see that happening just yet, not for the next couple of years anyway.
Macka
Well first off I have to eat my hat, as I'd previously posted that I thought Win64 development was still on track when I replied to the first Slashdot article on this subject. I was quite wrong.
:-)
However, the decsion from Compaq and Microsoft to drop NT on Alpha is really a shining example of why Open Source projects like Linux, Apache, KDE, etc, are such a good bet for customers. They aren't owned by one entity, aren't developed on the strength of product sales, and can't be withdrawn from the market without regard for what the users and customers think.
What an endorsement of the Open Source model
Macka
The Linux world would be a better place if all distributions used the same package format, the same system management tools and followed the same filesystem standard. The fact that they don't will not stop Linux growth or acceptance, but it won't help it either.
As for ESR's speculation that Compaq will eventually move from Tru64 UNIX to Linix, well, I'm normally with ESR on most things, but on this one I think he's way off base. For the next few years at least. My reasons for this are:
* The Linux kernel has some way to go yet on the scalability front before it could be considered a potential replacement for Tru64's kernel. Compaqs next generation Wildfire systems will be out soon, with possible configurations of up to 256 CPU's. Tru64 V5.* can scale that high and make good use of it. The Linux kernel will need to be able to match that.
* No one does clustering like Compaq's VMS clusters, and now Tru64 UNIX is getting the same functionality. This puts Compaq's UNIX way out ahead of any other UNIX with the rest of the field (and NT) left behind with failover style clustering. Porting TruCluster V5 functionality to Linux would be a big job. New drivers for the cluster software, new hardware (Memory Channel), the new Cluster common FileSystem, the advanced filesystem (AdvFS), etc. I just can't see Compaq wanting to Open Source any of this, as it's what will set them apart from the competition.
Macka
Not so fast folks. Compaq have not made any statements about the end of NT or Alpha, and the reality of the layoffs is quite different from the press spin on it.
.18 micron shrink is in the works (possibly with copper interconnects) which will have two benefits. 1) a significant leap in MHz, way over the 1GHz milestone. 2) A significant reduction in price (smaller die = more per wafer). When Merced ships Alpha will be significantly faster, smaller and cheeper! Alpha still rules the 64 bit roost, and nothing else in the 64bit market looks like getting anywhere close to it in price/performance.
The engineers layed off worked on the NT4 port to Alpha. That is done and dusted, there is no more work to be done in that field now. The next Alpha NT move is to Win64, and that port is being developed and driven entirely in-house at Microsoft.
NT is not dead on Alpha. If Windows 2000 scales as well as Microsoft are predicting, and the Win64 Alpha version gets finished as planned, then a lot of companies are going to be very interested in combining this with the horsepower Compaqs imminent Wildfire (Alpha) platform provides. If anything it will put NT Alpha in more direct competition with big UNIX systems, an area of competition it's been denied so far due to NT's lack of scalability.
Alpha also has a very rosey future. A
This story about the end of Alpha NT is just that, a story. Pure press fiction and FUD.
Macka
> Sun is the #1 Unix vendor in the world,
I'm not sure about that. I thought that SCO held the no: 1 slot in terms of licenses or units shipped (though not in revenue). I also remember reading something recently (though I don't remember which eZine it was on) which said that the Monterey triad (IBM + SCO + Sequent) will command over 50% of the commercial UNIX market when it ships. Well, they didn't say commercial in the article, but they didn't mention any of the free *ix's, so that's my spin on it.
Macka