What do you mean your RAID 'went bad'? Surely you had a configuration with hot spares? What RAID level were you using? A properly configured RAID array has always been enough for me.
The author doesn't seem to know an awful lot about GNU/Linux. He categorizes Linux, *BSD and Darwin all as Open Source versions of Unix (he refers to them using the term 'Open Source Unix').
Had a look at the column he writes as well, couldn't find a single non-windows article....
Err...
Thats not really true. Opcode compiled on one platform in Perl will run on any other platform with a Perl virtual machine.
Perl is as cross platform as Java. Perl's virtual machine is the Perl interpreter. A Perl program will run on any machine with a Perl virtual machine on it.
You can generate bytecode using the bytecode backend.
Thats really all I'm worried about.
Will Redhat continue to contribute as it has done in the past? Redhat employs key kernel developers and have been responsible for many major contributions. NPTL and the 0(1) scheduler are amoungst them.
I'd like to see similar comments running the anticipatory scheduler for Linux and a quad processor SMP box vs FreeBSD. Thats where the differences in SMP performance and the threading implementation will show.
I'm amazed to see no mention of the widely used and rock solid GFS, brought to you by the same people who did LVM. GFS was written for Linux and is Posix compliant. It was available under the GPL license once upon a time, unfortunately thats changed. Doesn't cost too much though.
Too many people seem to concentrate on processing power and hardware while neglecting the software side of things. Using a web server which pre-forks (example-- Apache 1.3x), is probably the best way to dramatically reduce performance and scalability in most situations. The sheer number of processes under high load makes most schedulers crap themselves in most situations. Multithreadedness, an example is Apache 2.x, can greatly improve performance and scalability as can single process, single threaded multiplexing non-blocking IO based web servers such as Thttpd, BOA or Zeus. Once one has selected a server which works effeciently for them given their content, fine tuned their OS, then one can move towards actual processing power and system throughput.
Slashdot Mirror
What do you mean your RAID 'went bad'?
Surely you had a configuration with hot spares? What RAID level were you using? A properly configured RAID array has always been enough for me.
The author doesn't seem to know an awful lot about GNU/Linux. He categorizes Linux, *BSD and Darwin all as Open Source versions of Unix (he refers to them using the term 'Open Source Unix').
Had a look at the column he writes as well, couldn't find a single non-windows article....
Err... Thats not really true. Opcode compiled on one platform in Perl will run on any other platform with a Perl virtual machine. Perl is as cross platform as Java. Perl's virtual machine is the Perl interpreter. A Perl program will run on any machine with a Perl virtual machine on it. You can generate bytecode using the bytecode backend.
Freecache is dead too now.
This is because their Akamai web accelerators run Linux. AFAIK, nobody really knows what the boxen behind those acceleratrors run.
Thats really all I'm worried about. Will Redhat continue to contribute as it has done in the past? Redhat employs key kernel developers and have been responsible for many major contributions. NPTL and the 0(1) scheduler are amoungst them.
I'd like to see similar comments running the anticipatory scheduler for Linux and a quad processor SMP box vs FreeBSD. Thats where the differences in SMP performance and the threading implementation will show.
Most of thats not true. GFS is Posix compliant (so you can open() as much as you like) and stable.
I'm amazed to see no mention of the widely used and rock solid GFS, brought to you by the same people who did LVM. GFS was written for Linux and is Posix compliant. It was available under the GPL license once upon a time, unfortunately thats changed. Doesn't cost too much though.
Too many people seem to concentrate on processing power and hardware while neglecting the software side of things.
Using a web server which pre-forks (example-- Apache 1.3x), is probably the best way to dramatically reduce performance and scalability in most situations. The sheer number of processes under high load makes most schedulers crap themselves in most situations.
Multithreadedness, an example is Apache 2.x, can greatly improve performance and scalability as can single process, single threaded multiplexing non-blocking IO based web servers such as Thttpd, BOA or Zeus.
Once one has selected a server which works effeciently for them given their content, fine tuned their OS, then one can move towards actual processing power and system throughput.