This is a chicken/egg problem; Linux won't develop the enterprise userbase without enterprise-level applications, and the enterprise-level applications and other services won't materialize until there's a userbase.
But at this point, Linux definately isn't at the same level as the big iron in the data center, and force-fitting it is a poor decision. Linux isn't data center ready because of a lack of features; NT isn't ready due to lack of maturity of those features. Both have a while to go before they can compete with even big UNIX machines, nevermind large mainframes.
Re:Vapour or not, doesn't matter
on
Microsoft Janus
·
· Score: 1
Oracle needs raw devices to port OPS to Linux; however, for pure HA, you do not need raw devices, you merely need know when your writes are committed to stable storage. However, clustering RDBMSs cluster both for scalability and availability; in that case you need raw devices or some abstraction that provides consistency between multiple writers and multiple readers. We have neither in the stock kernel.
While we do have all components available for failover, this is only genuinely useful for stateless applications like static web service. You need either raw devices (to provide a cluster file system in userland) or a kernel-based cluster file system for file server failover. Application server failover with long-running applications requires specific application support, which we lack. RDBMSs are examples of these long-running applications.
Vapour or not, doesn't matter
on
Microsoft Janus
·
· Score: 4
Whether NT is stable in a single server non-HA configuration or not does not matter; as long as the system as viewed from outside the cluster is up all the time with acceptable performance, there is no loss. Linux can do HA too, but the apps just aren't there. We can't beat this because we don't have control over it. Stability is really the only thing Linux has over NT at the moment in the data center, but this turns the tables. NT with failover clusters is more reliable than any single Linux machine.
Have Oracle port OPS. Oh, wait, that won't be done until raw devices are in the kernel, and Linus doesn't like them. Same for other cluster-enabled RDBMSs. Linux also has a severe filesystem deficiency right now, but as I understand it, this is being worked on, but I don't see much real progress. Other scalability concerns are being addressed in 2.3 right now, which should be out before 2000 as 2.4, if I am to understand Linus's release schedule correctly.
Another real problem with Linux is the lack of availablity of midrange and high-end hardware to key developers. My company (Denarius: http://www.denarius.com) would be more than happy to supply and set up access to high-end hardware for kernel developers as a service to the community. Hardware manufacturers would have an incentive to offer evaluations of their hardware to "sponsor" the project, as well, gaining bonus points with developers and users.
Just because he knows about TCP/IP doesn't mean he knows anything about Linux, and also doesn't mean that he's not just spouting off. So he's a well-read crackpot who is...:P
Doesn't exactly look like responsible reporting to me. Upon a close inspection the system stats look hokey (Especially regarding RAM and HD). And if I understand correctly, ALi and VIA were to be creating the chipset. Additionally, according to AMD the backside L2 cache bus supposedly "scales past 1GHz," so I'd naturally assume that the L2 cache would be core speed, or at least 1/2 of it. And even the size (not to mention the Ultra3 speed) of the IBM hard disk looks fishy. What happened to 4.55, 9.1, 18.2, 36.4... From our favourite news source, even.
It doesn't -prove- anything. It's merely an impressive feat. I have no doubt that another OS could achieve a similar accomplishment, however. Regardless, it is certainly a testament to FreeBSD's performance (not necessarily speed, also includes functionality) under extreme load.
It isn't the change in behaviour caused by the power drill that is the problem. A power drill is a very useful tool for making holes.
A murder spree with a power drill can result in upwards of 15 people killed--without the drill that same individual would probably only be able to kill a couple of people.
Allowing that psychopath to have a power drill is as irresponsible as giving a baby a gun.
Slashdot Mirror
This is a chicken/egg problem; Linux won't develop the enterprise userbase without enterprise-level applications, and the enterprise-level applications and other services won't materialize until there's a userbase.
But at this point, Linux definately isn't at the same level as the big iron in the data center, and force-fitting it is a poor decision. Linux isn't data center ready because of a lack of features; NT isn't ready due to lack of maturity of those features. Both have a while to go before they can compete with even big UNIX machines, nevermind large mainframes.
Oracle needs raw devices to port OPS to Linux; however, for pure HA, you do not need raw devices, you merely need know when your writes are committed to stable storage. However, clustering RDBMSs cluster both for scalability and availability; in that case you need raw devices or some abstraction that provides consistency between multiple writers and multiple readers. We have neither in the stock kernel.
While we do have all components available for failover, this is only genuinely useful for stateless applications like static web service. You need either raw devices (to provide a cluster file system in userland) or a kernel-based cluster file system for file server failover. Application server failover with long-running applications requires specific application support, which we lack. RDBMSs are examples of these long-running applications.
Whether NT is stable in a single server non-HA configuration or not does not matter; as long as the system as viewed from outside the cluster is up all the time with acceptable performance, there is no loss. Linux can do HA too, but the apps just aren't there. We can't beat this because we don't have control over it. Stability is really the only thing Linux has over NT at the moment in the data center, but this turns the tables. NT with failover clusters is more reliable than any single Linux machine.
Have Oracle port OPS. Oh, wait, that won't be done until raw devices are in the kernel, and Linus doesn't like them. Same for other cluster-enabled RDBMSs. Linux also has a severe filesystem deficiency right now, but as I understand it, this is being worked on, but I don't see much real progress. Other scalability concerns are being addressed in 2.3 right now, which should be out before 2000 as 2.4, if I am to understand Linus's release schedule correctly.
Another real problem with Linux is the lack of availablity of midrange and high-end hardware to key developers. My company (Denarius: http://www.denarius.com) would be more than happy to supply and set up access to high-end hardware for kernel developers as a service to the community. Hardware manufacturers would have an incentive to offer evaluations of their hardware to "sponsor" the project, as well, gaining bonus points with developers and users.
Just because he knows about TCP/IP doesn't mean he knows anything about Linux, and also doesn't mean that he's not just spouting off. So he's a well-read crackpot who is... :P
The Breezecom stuff is directional point-to-point, and not shared, so it's perfectly safe to sell the whole bandwidth of a connection.
Linux 2.2 has this in the form of the sendfile() API.
What do you think this is? A poll? :)
Doesn't exactly look like responsible reporting to me. Upon a close inspection the system stats look hokey (Especially regarding RAM and HD). And if I understand correctly, ALi and VIA were to be creating the chipset. Additionally, according to AMD the backside L2 cache bus supposedly "scales past 1GHz," so I'd naturally assume that the L2 cache would be core speed, or at least 1/2 of it. And even the size (not to mention the Ultra3 speed) of the IBM hard disk looks fishy. What happened to 4.55, 9.1, 18.2, 36.4... From our favourite news source, even.
It doesn't -prove- anything. It's merely an impressive feat. I have no doubt that another OS could achieve a similar accomplishment, however. Regardless, it is certainly a testament to FreeBSD's performance (not necessarily speed, also includes functionality) under extreme load.
It isn't the change in behaviour caused by the power drill that is the problem. A power drill is a very useful tool for making holes.
A murder spree with a power drill can result in upwards of 15 people killed--without the drill that same individual would probably only be able to kill a couple of people.
Allowing that psychopath to have a power drill is as irresponsible as giving a baby a gun.
Get my point?