I think you're probably right. But in reality most commercial enterprises want support and accountability for the products they use, and actively want to pay for it. You get both of these with Trolltech's Commercial license (for the first year) along with access to the source code. But you don't get support for the Open Source version.
Given that the cost of the license is only a fraction of what you would pay a developer during the development lifetime of a project, I don't see many companies choosing to pass up on this.
Of cause there will be some... but I suspect that TrollTech will have done their Math, and figure they've got more to gain from expanding their user base and the consequent interest in commercial support than they will loose by keeping such a tight reign on things.
They would not have made this decision if it didn't make financial sense for them at this time.
Not to mention what the console market is going to do to PC games anyway in the next few years. When the next Cell based PlayStation comes out (and I assume the next-gen Xbox too) their game specific performance advantage over PC's are likely to be so great that I can't see much future in PC gaming after that.
By the time Linux developers turn their full attention to Gaming (and that's one huge assumption anyway) they will probably have missed the boat.
Depends on what your criteria is. As a server OS for small systems, its on a par with Linux as it shares most of the same apps and has similar features.
For big tin, definitely not because there is no real big tin for it to run on, so it's not got the features (e.g. Virtualization) to compete in that space.
For Super Computing clusters, again its right up there, though whether its any better than Linux in this regard is debatable.
But for the Desktop, yes, it IS the best OS out there. As someone who over the last 12 years has used mwm and CDE over X on various Unix Risc Workstations; Windows 9*/NT/XP; KDE and Gnome on Linux; and Mac OS X for the last 2.5 years, I can vouch for it. No other Desktop + OS experience I've had in my career is as good is Mac OS X is now. And Tiger, later on this year, will raise the bar even higher.
Wait for Tiger later on this year. It ships with SQLite installed by default. There's bound to be some Apple magic around that either in development, or waiting in the wings to enable you to access SQLite data from the tables in Pages.
Apples use of the code and further development is effectively a fork and has diverged from the original sufficiently enough for it to be hard work to include it into the original.
The khtml developers could include apples code if they wanted, but they'd have to unpick it, mangle it, etc to make it happen and it turns out that's too much work for them to do.
So you're saying that apple should be obliged to write their code twice now, once for the original project (khtml) and once for their fork (webcore) and release both at the same time ??
I call bullshit. If I fork your code to start my own project, I'm not obliged in any way to maintain your code after the fork.
Providing it doesn't cause my VTOL (Vertical Take Off and Landing) 200 mph Zimmer Frame to crash, I don't really think I'm going to care all that much.
I don't understand. So you're saying that through out the whole of America, it's not possible to use Bluetooth to connect to your phone, for anything? And it doesn't matter what carrier you choose or what phone model due to the carriers rigging the market?
That's astonishing! In Europe that would be considered as gross abuse of power. The communications watchdogs have some teeth to tackle this sort of thing, and possibly would get the monopolies commission involved. It would be stopped, which is probably why its never been attempted here.
Maybe it's a US thing that they can do that and expect to get away with it. I don't know of any Carrier in the UK that does that sort of thing. I've got a K700i and regularly use Bluetooth with my Mac to sync up the address book, calendar, offload pictures I take with it and most importantly to connect to the phone's GPRS modem for mobile internet access. If I had to funnel the first three through my carrier (Orange) it would cost me a fortune. And the last feature would be impossible.
I simply would not accept that limitation from a carrier. It's an abuse of their service. Do the sensible thing and change you carrier to someone who doesn't cripple your phone and your computing experience. Then let them know in a letter why you're changing. If enough people do the same, they'll start to get the message.
Still this is all conjecture on your part, and by your own awareness of the issues you place yourself outside the realm of the 'average consumer' (renamed for clarity). So your buying habits are not representative of the majority market.
It would be nice to think that there's some kind of grass roots revolution going on. David rising up in anger to slay the evil Goliath, but outside of the Slashdot bubble world, where are the signs of it? Not one of my non-technical, music buying, 'consumer' friends is even aware of it. I know cos whenever I bring it up in conversation, all I get is blank looks. They react to it in the moment, then forget all about it and go back to buying their music the same old way they've always done.
Do keep beating the drum however. Maybe one day you might actually be heard above the foot falls of the million+ flock of sheep, as they trot off to their nearest MPAA approved music outlet.
Time for the record labels and movie studios to wake up to themselves - they are alienating a large part of their support base.
Are they really? I mean, you'd expect it right... but is this a truism, or just modern legend and wishful thinking on your part? Does anyone have any stats to back up this claim?
I've seen a lot of people state when asked, that if they download tracks and like them then they go and buy the Album. That the justification for free downloads is try-and-buy. Do the actions of the MPAA stop people from following through with their purchase?
I expect that sales of singles are on the wane, but that can be attributed to a combination of legal online sales, and the flood of crappy teen pop the industry is churning out these days.
Personally I think that the number of customers who are aware enough to be put off by these kinds of industry antics are so small they're little more than a rounding error. Certainly no where near enough to dissuade the MPAA from continuing. Your average street punter doesn't know what's going on, and frankly doesn't care. Sad.. but that's life.
For starters, it's Tru64, there's no "e" in the name. Seeing as you don't know how to read, it's no surprise to me that you didn't read up on it's security features. The default install comes configured with "base" security. But if you'd taken any time to learn, you've quickly have discovered the existence of "enhanced"security, which implements "bigcrypt" and moves the password out of/etc/passwd into the tcb database (shadow passords anyone!!!). If you'd take more than a 5 second glance at "sysman", Tru64's management app, you'd have seen the security option staring you right in the face. Plus there's a/very/ extensive Security Administrators Guide included in the doc set.
When the enhanced security mechanism is installed and configured, the system is referred to as a trusted system. Enabling all enhanced security features will result in a system that can be configured to meet the C2 class of trust, as defined by the Trusted Computer System Evaluation Criteria (TCSEC, also called the Orange Book). The system also meets the F-C2 functional class as defined in the Information Technology Security Evaluation Criteria (ITSEC).
Enhanced security extends BSD security by providing:
* Login control enhancements
* Password enhancements
The following lists enhanced security features for login control:
* Recording the last terminal used for a successful and unsuccessful login
* Recording the time of the last successful login
* Recording the time of the last unsuccessful login attempt
* Recording the number of consecutive unsuccessful login attempts
* Automatic account lockout after a specified number of consecutive bad access attempts
* A per-terminal setting for the delay between consecutive login attempts, and the maximum amount of time each attempt is allowed to complete the login before being declared a failed attempt
* A per-terminal setting for the maximum consecutive failed login attempts before locking any new accesses from that terminal
* Display information about last successful and last unsuccessful login attempts at login time.
* Recording login information whenever a login occurs over the terminal.
Enhanced security provides the following features for password control:
* Configurable maximum password length, up to 80 characters
* Configurable password lifetimes
* Variable minimum password length
* System-generated passwords that take the form of a pronounceable password made up of meaningless syllables, an unpronounceable password made up of random characters from the character set, or an unpronounceable password made up of random letters from the alphabet. (All letters are from ASCII.)
* Per-user password generation flags, which include the ability to require a user to have a system-generated password
* Record of who (besides the user) last changed the user's password
* Password usage history
I could go on and on about the auditing capabilities too, which enables you to capture the calling of virtually every system and library call on the system, trackable by an Audit-ID that stays the same even if you change your Real UID to some other user.
And then there SIA, the modular security architecture that enables you to write and plug-in your own security if you so desire.
Yes AdvFS was a bit buggy at V4. It was also funneled and tied to running on the base CPU, which created a real bottle neck.
But it was completely re-written for V5 to be fully multi threaded and could run on any CPU. This was a real turning point for AdvFS, it was incredibly stable a very fast after that.
I've been building TruCluster since the beginning, hundreds of them; and since V5 I've never had a cluster go belly up to the point of being unrecoverable. AdvFS is rock solid now.
In fact, I'm the only person in TruCluster circles I know that's ever had to do a full TruCluster restore from backup. And the one and only time I did, it was a planned move to new systems on a different site with different hardware.
It's the most solid O/S I've ever had the privilege of working with.
What rubbish. I've used both, and H-POX is about 3 years behind Tru64 in development terms. Not to mention very proprietary in its feel. Some simple examples:
-- you can't get a process listing from ps(1) that shows you the run state ( ps -ef doesn't support that) cos it doesn't understand any BSD flags. Tru64 has supported both bsd and sysv flags from inception.
-- Every Unix I've ever come across supports "ifconfig -a" to list all available network devices. Even OSX supports it. But H-POX has to be different, you need to use 'lanscan' to find the device name, and then use ifconfig on each device seperately to see the same info.
I can go on.. but basically it's the clunkiest Unix I've ever come across (perhaps with the exception of SCO Unix).
It's only dirty if the radioactive waste stays here on earth. The cost of launching payloads into space is getting ever cheeper with new technologies and commercial interest. This will only get better over time. What with relatively low cost ion drives available now, it's feasible that radioactive waste shot into space can be put into a slow speed trajectory aimed away from us and into the Sun. Eventually the Sun's gravity will take over and finish the job off.
Sure this will all still cost money, but there's bound to be a break even point between the cost of a space launch and the cost of long term storage and clean up bills. And that can't be very far away.
Thanks for your thoughts. Hopefully then, if whichever outbound SMTP server I'm using signs the mail with a private key, but my hosting company doesn't publish a public key in DNS for my domain, then the default behavior will be to allow email through and not drop it in the bit bucket. I wonder if this behavior will be written into an RFC or left to be implementation specific.
I've tried pinging my hosting company before now about setting up an authenticated SMTP server when I first learned about the possibility of SPF. So far, no joy.
The only problem with this solution is that it's going to make sending email virtually unusable for people like me. I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network. Similarly, when I'm away from my office, I connect to the net using GPRS and use my mobile provider's SMTP server. And sometime if I'm on a clients network I'll use their SMTP server instead.
In all those cases it doesn't matter where I'm sending from, cos the From: and Reply-To: headers point back to my domain, so when people reply to me their email goes to the right place. It's even more important these days with spam filters in front of everyone's Inbox that my From: field correctly identifies who I am. And from a business point of view that has to remain consistent.
The Yahoo site describing this states that for DomainKeys to work, the domain is extracted from the From: field, a DNS lookup fetches the public key, and that is then compared to the email's private key to confirm the email came from the correct place.
For me this is always fail, whether I'm working from home, or I'm out on the road. Basically, it's a complete disaster. Right now I'm not sure how I'd get round that.
I can't be the only person this would screw up. There must be tens of thousands of other people out there who legitimately use email this way and would be badly affected by this.
It's scary. Each passing year seems to move us inexorably closer to an Orwellian society. Soon it won't be possible to have an original idea any more without the system crying foul and demanding you hand over cash for a part of it.
There needs to be a change in the Law. Once you take out a patent, you have 2-3 years to bring a product to market that makes use of the idea, or you loose claim to the patent altogether. Further more, the patent should then be transformed into an Open Patent. Available for anyone, free of charge. This is the only way to prevent further abuse of the system.
The main features are: single root and single init, cluster filesystems and DLM, single process space and process migration, load leveling, single and shared IPC space, device space and networking space, and single management space
1) It's been ported to Itanium, and will ship on that platform very soon.
2) ISV support for VMS on Itanium is strong and its customers are very loyal.
3) You said you wish it would die and allow "better systems" to take over. What better systems? In the context of clustering (cos that's what this discussion is about) VMS Clustering for High Availability systems is still at the top of the food chain. Nothing exists on Linux to match it. Not yet anyway.
Tru64 Unix clustering is about the next best thing, but there won't be any further development there now until HP port TruCluster onto the next-generation of HP-UX. Unfortunately that's taking way too long, and by the time they get there it just might be irrelevant. OpenSSI.org may just eat its lunch.
I bet it doesn't stay that way for long. Eventually someone at Novell is going to take a look at what money they're spending on development, which will include the ongoing costs of integrating, testing and qualifying "tons" of apps for the SuSE portfolio. Then they'll look at what their (paying) customers are asking for (at least the ones who provide 80% of their revenue) and a cut back and rationalization exercise will follow.
SuSE is currently the Swiss Army knife of Linux distros. I'm convinced those days will eventually be numbered. Distros like Ubuntu who limit themselves to a streamlined, specific set of technologies are going to grow very quickly and get a foothold in the market. They can do this cos their development cycles are less burdened, so they're cheaper and faster. Eventually SuSE will have to cut away some of the fat to keep their market lead and stay competitive.
Well done. You have a rock solid argument that may well be the exact reason for lack of this functionality. But that doesn't fix the fact that the functionality isn't there.
Your logic is flawed. Why would they waste money and resources designing functionality into the product that they can't possibly use or sell? Or raise the cost of manufacture & the sale price by bloating it with redundant hardware of no value to the consumer? Why do all that now when they can release another one a year from now with all these things, and tempt customers to dive into their cheque books for a second or third bite at the 'apple'?
It make no business sense at all to do what you suggest.
What's with the off topic URL link? Flat screens for free... yeah fuckin right. You sound like a reasonably intelligent man, you don't really believe you'll get a flat screen out of it do you?
They'll probably harvest your email address and send you requests for all kinds of "handling fees" before mysteriously disappearing and screwing you over.
Don't be a mug! There's no such thing as a free lunch !!!
But at this point the death of Usenet is recursive: I don't go there because nobody else goes there
Not to mention that if you're daft enough to drop anything closely resembling your real email address in a newsgroup, the amount of spam you get will go through the roof. As one of the many people these days who have their own domain and thus control their own email addresses, I jealously guarded my email address for 6 months after activating it for the first time. Using easy to track and delete aliases when ever I had to give out an address. One day I had a brain fart and accidentally posted a Usenet article using my real address. I realised what I'd done shortly after, but it was too late. A few days later I got my first spam, then more, then more and now it's grown to scores a day, despite not publishing it anywhere else in the 4 years that have passed since. Just one lousy stinkin cock-up in one bloody Usenet posting. I don't go near Usenet anymore these days. Like the man said, it's too full of crap.
I think you're probably right. But in reality most commercial enterprises want support and accountability for the products they use, and actively want to pay for it. You get both of these with Trolltech's Commercial license (for the first year) along with access to the source code. But you don't get support for the Open Source version.
Given that the cost of the license is only a fraction of what you would pay a developer during the development lifetime of a project, I don't see many companies choosing to pass up on this.
Of cause there will be some
They would not have made this decision if it didn't make financial sense for them at this time.
Not to mention what the console market is going to do to PC games anyway in the next few years. When the next Cell based PlayStation comes out (and I assume the next-gen Xbox too) their game specific performance advantage over PC's are likely to be so great that I can't see much future in PC gaming after that.
By the time Linux developers turn their full attention to Gaming (and that's one huge assumption anyway) they will probably have missed the boat.
Depends on what your criteria is. As a server OS for small systems, its on a par with Linux as it shares most of the same apps and has similar features.
For big tin, definitely not because there is no real big tin for it to run on, so it's not got the features (e.g. Virtualization) to compete in that space.
For Super Computing clusters, again its right up there, though whether its any better than Linux in this regard is debatable.
But for the Desktop, yes, it IS the best OS out there. As someone who over the last 12 years has used mwm and CDE over X on various Unix Risc Workstations; Windows 9*/NT/XP; KDE and Gnome on Linux; and Mac OS X for the last 2.5 years, I can vouch for it. No other Desktop + OS experience I've had in my career is as good is Mac OS X is now. And Tiger, later on this year, will raise the bar even higher.
Whoever mod'd that down to -1 as Offtopic didn't read it properly
Wait for Tiger later on this year. It ships with SQLite installed by default. There's bound to be some Apple magic around that either in development, or waiting in the wings to enable you to access SQLite data from the tables in Pages.
Apples use of the code and further development is effectively a fork and has diverged from the original sufficiently enough for it to be hard work to include it into the original.
The khtml developers could include apples code if they wanted, but they'd have to unpick it, mangle it, etc to make it happen and it turns out that's too much work for them to do.
So you're saying that apple should be obliged to write their code twice now, once for the original project (khtml) and once for their fork (webcore) and release both at the same time ??
I call bullshit. If I fork your code to start my own project, I'm not obliged in any way to maintain your code after the fork.
Lets see, I'll be 73 about then.
Providing it doesn't cause my VTOL (Vertical Take Off and Landing) 200 mph Zimmer Frame to crash, I don't really think I'm going to care all that much.
I don't understand. So you're saying that through out the whole of America, it's not possible to use Bluetooth to connect to your phone, for anything? And it doesn't matter what carrier you choose or what phone model due to the carriers rigging the market?
That's astonishing! In Europe that would be considered as gross abuse of power. The communications watchdogs have some teeth to tackle this sort of thing, and possibly would get the monopolies commission involved. It would be stopped, which is probably why its never been attempted here.
Maybe it's a US thing that they can do that and expect to get away with it. I don't know of any Carrier in the UK that does that sort of thing. I've got a K700i and regularly use Bluetooth with my Mac to sync up the address book, calendar, offload pictures I take with it and most importantly to connect to the phone's GPRS modem for mobile internet access. If I had to funnel the first three through my carrier (Orange) it would cost me a fortune. And the last feature would be impossible.
I simply would not accept that limitation from a carrier. It's an abuse of their service. Do the sensible thing and change you carrier to someone who doesn't cripple your phone and your computing experience. Then let them know in a letter why you're changing. If enough people do the same, they'll start to get the message.
Still this is all conjecture on your part, and by your own awareness of the issues you place yourself outside the realm of the 'average consumer' (renamed for clarity). So your buying habits are not representative of the majority market.
It would be nice to think that there's some kind of grass roots revolution going on. David rising up in anger to slay the evil Goliath, but outside of the Slashdot bubble world, where are the signs of it? Not one of my non-technical, music buying, 'consumer' friends is even aware of it. I know cos whenever I bring it up in conversation, all I get is blank looks. They react to it in the moment, then forget all about it and go back to buying their music the same old way they've always done.
Do keep beating the drum however. Maybe one day you might actually be heard above the foot falls of the million+ flock of sheep, as they trot off to their nearest MPAA approved music outlet.
Are they really? I mean, you'd expect it right
I've seen a lot of people state when asked, that if they download tracks and like them then they go and buy the Album. That the justification for free downloads is try-and-buy. Do the actions of the MPAA stop people from following through with their purchase?
I expect that sales of singles are on the wane, but that can be attributed to a combination of legal online sales, and the flood of crappy teen pop the industry is churning out these days.
Personally I think that the number of customers who are aware enough to be put off by these kinds of industry antics are so small they're little more than a rounding error. Certainly no where near enough to dissuade the MPAA from continuing. Your average street punter doesn't know what's going on, and frankly doesn't care. Sad
For starters, it's Tru64, there's no "e" in the name. Seeing as you don't know how to read, it's no surprise to me that you didn't read up on it's security features. The default install comes configured with "base" security. But if you'd taken any time to learn, you've quickly have discovered the existence of "enhanced"security, which implements "bigcrypt" and moves the password out of
When the enhanced security mechanism is installed and configured, the system is referred to as a trusted system. Enabling all enhanced security features will result in a system that can be configured to meet the C2 class of trust, as defined by the Trusted Computer System Evaluation Criteria (TCSEC, also called the Orange Book). The system also meets the F-C2 functional class as defined in the Information Technology Security Evaluation Criteria (ITSEC).
Enhanced security extends BSD security by providing:
* Login control enhancements
* Password enhancements
The following lists enhanced security features for login control:
* Recording the last terminal used for a successful and unsuccessful login
* Recording the time of the last successful login
* Recording the time of the last unsuccessful login attempt
* Recording the number of consecutive unsuccessful login attempts
* Automatic account lockout after a specified number of consecutive bad access attempts
* A per-terminal setting for the delay between consecutive login attempts, and the maximum amount of time each attempt is allowed to complete the login before being declared a failed attempt
* A per-terminal setting for the maximum consecutive failed login attempts before locking any new accesses from that terminal
* Display information about last successful and last unsuccessful login attempts at login time.
* Recording login information whenever a login occurs over the terminal.
Enhanced security provides the following features for password control:
* Configurable maximum password length, up to 80 characters
* Configurable password lifetimes
* Variable minimum password length
* System-generated passwords that take the form of a pronounceable password made up of meaningless syllables, an unpronounceable password made up of random characters from the character set, or an unpronounceable password made up of random letters from the alphabet. (All letters are from ASCII.)
* Per-user password generation flags, which include the ability to require a user to have a system-generated password
* Record of who (besides the user) last changed the user's password
* Password usage history
I could go on and on about the auditing capabilities too, which enables you to capture the calling of virtually every system and library call on the system, trackable by an Audit-ID that stays the same even if you change your Real UID to some other user.
And then there SIA, the modular security architecture that enables you to write and plug-in your own security if you so desire.
Yes AdvFS was a bit buggy at V4. It was also funneled and tied to running on the base CPU, which created a real bottle neck.
But it was completely re-written for V5 to be fully multi threaded and could run on any CPU. This was a real turning point for AdvFS, it was incredibly stable a very fast after that.
I've been building TruCluster since the beginning, hundreds of them; and since V5 I've never had a cluster go belly up to the point of being unrecoverable. AdvFS is rock solid now.
In fact, I'm the only person in TruCluster circles I know that's ever had to do a full TruCluster restore from backup. And the one and only time I did, it was a planned move to new systems on a different site with different hardware.
It's the most solid O/S I've ever had the privilege of working with.
What rubbish. I've used both, and H-POX is about 3 years behind Tru64 in development terms. Not to mention very proprietary in its feel. Some simple examples:
-- you can't get a process listing from ps(1) that shows you the run state ( ps -ef doesn't support that) cos it doesn't understand any BSD flags. Tru64 has supported both bsd and sysv flags from inception.
-- Every Unix I've ever come across supports "ifconfig -a" to list all available network devices. Even OSX supports it. But H-POX has to be different, you need to use 'lanscan' to find the device name, and then use ifconfig on each device seperately to see the same info.
I can go on
Which will condense and fall as rain, flowing into rivers and drains, and back out to sea again completing the circle.
Where is your problem again?
It's only dirty if the radioactive waste stays here on earth. The cost of launching payloads into space is getting ever cheeper with new technologies and commercial interest. This will only get better over time. What with relatively low cost ion drives available now, it's feasible that radioactive waste shot into space can be put into a slow speed trajectory aimed away from us and into the Sun. Eventually the Sun's gravity will take over and finish the job off.
Sure this will all still cost money, but there's bound to be a break even point between the cost of a space launch and the cost of long term storage and clean up bills. And that can't be very far away.
Thanks for your thoughts. Hopefully then, if whichever outbound SMTP server I'm using signs the mail with a private key, but my hosting company doesn't publish a public key in DNS for my domain, then the default behavior will be to allow email through and not drop it in the bit bucket. I wonder if this behavior will be written into an RFC or left to be implementation specific.
I've tried pinging my hosting company before now about setting up an authenticated SMTP server when I first learned about the possibility of SPF. So far, no joy.
The only problem with this solution is that it's going to make sending email virtually unusable for people like me. I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network. Similarly, when I'm away from my office, I connect to the net using GPRS and use my mobile provider's SMTP server. And sometime if I'm on a clients network I'll use their SMTP server instead.
In all those cases it doesn't matter where I'm sending from, cos the From: and Reply-To: headers point back to my domain, so when people reply to me their email goes to the right place. It's even more important these days with spam filters in front of everyone's Inbox that my From: field correctly identifies who I am. And from a business point of view that has to remain consistent.
The Yahoo site describing this states that for DomainKeys to work, the domain is extracted from the From: field, a DNS lookup fetches the public key, and that is then compared to the email's private key to confirm the email came from the correct place.
For me this is always fail, whether I'm working from home, or I'm out on the road. Basically, it's a complete disaster. Right now I'm not sure how I'd get round that.
I can't be the only person this would screw up. There must be tens of thousands of other people out there who legitimately use email this way and would be badly affected by this.
It's scary. Each passing year seems to move us inexorably closer to an Orwellian society. Soon it won't be possible to have an original idea any more without the system crying foul and demanding you hand over cash for a part of it.
There needs to be a change in the Law. Once you take out a patent, you have 2-3 years to bring a product to market that makes use of the idea, or you loose claim to the patent altogether. Further more, the patent should then be transformed into an Open Patent. Available for anyone, free of charge. This is the only way to prevent further abuse of the system.
OpenSSI (Single System Image) Clusters for Linux
The main features are: single root and single init, cluster filesystems and DLM, single process space and process migration, load leveling, single and shared IPC space, device space and networking space, and single management space
1) It's been ported to Itanium, and will ship on that platform very soon.
2) ISV support for VMS on Itanium is strong and its customers are very loyal.
3) You said you wish it would die and allow "better systems" to take over. What better systems? In the context of clustering (cos that's what this discussion is about) VMS Clustering for High Availability systems is still at the top of the food chain. Nothing exists on Linux to match it. Not yet anyway.
Tru64 Unix clustering is about the next best thing, but there won't be any further development there now until HP port TruCluster onto the next-generation of HP-UX. Unfortunately that's taking way too long, and by the time they get there it just might be irrelevant. OpenSSI.org may just eat its lunch.
9.1 Pro offers a "ton" of desktop enviornments
I bet it doesn't stay that way for long. Eventually someone at Novell is going to take a look at what money they're spending on development, which will include the ongoing costs of integrating, testing and qualifying "tons" of apps for the SuSE portfolio. Then they'll look at what their (paying) customers are asking for (at least the ones who provide 80% of their revenue) and a cut back and rationalization exercise will follow.
SuSE is currently the Swiss Army knife of Linux distros. I'm convinced those days will eventually be numbered. Distros like Ubuntu who limit themselves to a streamlined, specific set of technologies are going to grow very quickly and get a foothold in the market. They can do this cos their development cycles are less burdened, so they're cheaper and faster. Eventually SuSE will have to cut away some of the fat to keep their market lead and stay competitive.
Well done. You have a rock solid argument that may well be the exact reason for lack of this functionality. But that doesn't fix the fact that the functionality isn't there.
Your logic is flawed. Why would they waste money and resources designing functionality into the product that they can't possibly use or sell? Or raise the cost of manufacture & the sale price by bloating it with redundant hardware of no value to the consumer? Why do all that now when they can release another one a year from now with all these things, and tempt customers to dive into their cheque books for a second or third bite at the 'apple'?
It make no business sense at all to do what you suggest.
What's with the off topic URL link? Flat screens for free
They'll probably harvest your email address and send you requests for all kinds of "handling fees" before mysteriously disappearing and screwing you over.
Don't be a mug! There's no such thing as a free lunch !!!
But at this point the death of Usenet is recursive: I don't go there because nobody else goes there
Not to mention that if you're daft enough to drop anything closely resembling your real email address in a newsgroup, the amount of spam you get will go through the roof. As one of the many people these days who have their own domain and thus control their own email addresses, I jealously guarded my email address for 6 months after activating it for the first time. Using easy to track and delete aliases when ever I had to give out an address. One day I had a brain fart and accidentally posted a Usenet article using my real address. I realised what I'd done shortly after, but it was too late. A few days later I got my first spam, then more, then more and now it's grown to scores a day, despite not publishing it anywhere else in the 4 years that have passed since. Just one lousy stinkin cock-up in one bloody Usenet posting. I don't go near Usenet anymore these days. Like the man said, it's too full of crap.