1. Lame product that doesn't work but gets funding...check
I have tried using it for a few days and have never seen so many dead links (results of spider traps), unavailable servers, 404s, etc... it feels just like AltaVista in the days before the end.
2. Lots of money without a real plan... check
25 million for yet another search engine
3. Marketing people advertising how great their work environment is to get attention... check
*this
4. ???
5. Profit
Yep, all in order here, cover your ears, boom coming again.
I can agree to that. When I has in grad school I was applying for a scholarship (because I could not afford the school) and was told I was beat out by a foreign student with much better grades than me. A month later they offered me the scholarship (and instructor in charge told me that the transcript they received was forged and the student did not have perfect grades). So what this Omar guy did was trivialize the grades of the students who actually got good grades and worked hard for them (possibly ruining their chances at getting into a great school). The real victims are other students not the government or the education system.
Well unfortunately the market for good developers is quite thin with a lot of not so good ones leftover from the boom and the upper managements' constant push for offshore development teams to save money. This of course is part of a large problem where good developers are expensive and rightfully so and financial people can't see it as a justified expense allocate pittance of a salary. What we get is either semi-competent developers or off-shored ones and in either case you never know what you are getting.
"It's like a 'surprise ball' sometimes you get a raisin and sometimes you don't, that's the surprise." - Yosh Schmenge
It did happen, and to one of the biggest sites on the web and the only reason it was not a big deal is due to their very high profit margin at the time. They could afford the hardware and data center fees. Smaller companies would have had real impact to their profits.
The problem with java is not just raw performance, it's a combination of many things that I have noticed (ignoring the obvious nature of interpreted code): - Garbage collector instills a false sense of safety, so peaky allocations often deplete resources much quicker without an easy way to release them (in C you delete them when done with java you wait for GC and if load is sudden and high it can get out of hand) - java IDEs allow very easy refactoring which results in lots of classes and lots of 2-5 line methods which create huge call trees and if an exception occurs its not uncommon to see 100 lines deep in the stack trace - there is no real const so objects get passed around as copies where modification may not be desired (final is not a const, the reference is constant while underlying object is not), requires usage of interfaces on objects to limit access - too many huge jars (which not a coding issue) it sucks up deployment time when you have 50 jars that are 3-5mb in size
among other minor issues. While I use java daily at work I find that with C++ I was a lot more productive and build took way less time despite compiled nature of the code.
Another minor annoyance is distribution of code, while it is easy to send your jar file (which is say 100k) and execute the code, it often depends on other jars which are huge by comparisson and have to be shipped as well. For example xalan/xerces are 5MB zipped which in C++ you can just use the static libs and the resulting executable for the same code is 50-60k total, maybe not a big issue but an annoying one.
No language is perfect but I am betting C++ will be making a big resurgence with so many ajax based apps coming to the web with sub-stellar usability and response... just a guess and a hope.
I just won't go down the path of perl personally. I may read that book and do it right, but the code gets supported by many people of varying level of coding skill and you can't force everyone to read book. I have seen some simple and straightforward code become unreadable after 3 months of people adding features to it.
I agree that this is possible with any language but perl's syntax can be deadly if an advanced perl user makes changes and then mid/entry level perl developers work on it also.
Ultimately it comes down to what people are comfortable and what they know well, so I won't preach not using any specific language, whatever makes 'em happy. For my projects I'll stick to java/C++ for coding and python for scripting; just a personal preference.
It may sound that way but it happened (the 300 was a type, 500 was the initial machine count, not that it changes things too much).
In my other post I went into it in my other post to you, but it was mainly j2ee which the architects claimed they profiled but when the code got written it turned out to be slower than expected. Other issue was using java based libraries for some critical rendering (can't go too much into it due to security) and had to be reverted back to old C++ code via JNI which was faster but not native. There were many other issues.
Deep down inside the architects knew that they would need way more hardware but no way CTO/CFO would approve of the whole thing, so I feel there is a lot of "optimism" involved here.
Well last place I worked in that shall remain nameless, went from 500 machine C++ website to almost 5000 machine java website to maintain same response times. Their best engineers and architects planned the move for over a year and initially the machine count was 1000 and the plan was to use j2ee to server common application logic to a cluster of servers. Development took roughly a year for 10% of the site (including the foundation work), over 400 people worked on it.
QA ran perf tests and found that the performance was abysmal (RPC calls, inter-node communication, general j2ee slowness, etc), after much effort this was converted to jsps and servlets to regain some performance but it was nowhere near the 2x that Sun was claiming. There were a lot of factors that affected this but mostly it was the fact that java is slower than C++, java doesn't allow fine grained memory control, java almost requires you to have a lot of objects and small methods (thanks to plugins like codestyle, checklipse, etc).
So here we had a lot of PhDs, top level architects and lots of developers get things working but it was not meant to be within a plan.
While the overall costs did not explode by a factor of 16 it was close to a factor of 10, the decision to make the change mostly comes from above (CTO/chief architect level) and the real problem is not quite as easy.
Unfortunately the problem is always a constraint on budget that has people underestimating (or their project will not be approved) then trying their best only to realize they need more hardware.
Since you do this for a living I am sure you have ran across this at customer sites, it is very hard to accurately estimate the hardware requirement before the site is built but the budget for it has to be approved before the contracts are signed so you have the chicken/egg problem and often just hope for the best. If the site was already built and profiled, then obviously, estimating hardware is trivial.
I feel your pain, we are using ext and while it's a wonderful toolkit the json stuff is quite time consuming on both server and client, time that can be spent doing something more useful like rendering the actual content. In some places I've resorted to sending actual HTML snippets and using innerHTML to "insert" them directly without relying on ext/json. For non-performance critical tasks it's a pretty nice library.
I do agree that C++ is going to get a big resurgence as people are going to start looking for faster ways to execute their applications (and AJAX calls) and while scripting is adequate for low volume, once the volume of users goes up you really want the server to be the least of their concerns and concentrate on speeding up the network, database, etc.
AJAX makes a lot of little calls back to the server and it is critical that they are processed very quickly to give the site a responsive appearance, there is an appreciable difference between an ajax server response of 10ms compared to 50ms (after you factor in the network latency, bandwidth, jitter and other network issues).
I'm hoping C++ comes back faster, I am disliking java more and more every day. I hate the long build times, long deploy to tomcat times and long startup times; I waste more time now waiting to verify/debug/enhance than I ever did with C++. My browsing and slashdot posting skills did go up since I do more of it now while I wait.
However if someone switches from windows and using Visual Studio to mac and xcode, they will definitely notice that VS was a far better product however since they have to code for the mac and xcode is proetty much tops in that arena they just have to adapt since teir decision is driven by the OS issues.
I've seen many kinds of applications: CPU bound, DB bound, network bound, etc. If the app is going to be DB bound or network bound then it does make sense to stick to a script. However if suddenly the DB is no longer the problem (local caching, bigger DB cluster, faster internal network), then the scripted application becomes a bottle neck and often much more difficult of a problem to solve by comparison (unless you find that adding more machine/CPU to be viable). If scaling and hardware costs are not a problem then by all means, scripting is fine.
I worked in a place that went from C++ to java and the machine count went from 300 to over 5000 to maintain the overall performance and handle the growth at the same time. Needless to say supporting 5000 machines is not as easy as 300 and the IT costs really cut into the overall profit.
I find it hard to write good perl, there are so many ways to write something that invariably people will use what they are comfortable with but necessarily what someone else would use, so you get a lot of different coding styles which make it very hard to debug and support.
Personally I don't do perl for that reason, was on a project long ago where I inherited some perl scripts and they were downright painful to work with.
I would not generate HTML using C++, stick to MVC model, let C++ handle the controller stage and build the model then hand it off to any number of technologies setup for cross browser compatibility (XSLT, templated HTML, SOAP, RSS, XML or emit the model as JSON and use ext toolkit). There are a lot of ways and I have used ext with a lot of success, their code is really solid and lets you prototype a site quickly then attach JSON model and ajax calls (which are really nice to have in C++ so that the site feels responsive under load).
Sure PHP and JSP is nice due to ease of getting things running quickly but when the load gets really high you are then faced with difficult problems which in some cases more hardware can solve but more often it requires a rewrite.
Don't forget hardware is not just buying a computer, it also involves power consumption, cooling fees (air conditioning is quite expensive), network costs, storage/hosting costs, etc. I have worked in too many places where executives just state that they will throw more hardware at the problem and then complain when IT bills for infrastructure reduce their precious ROI to rubble:)
I would say that you generalization that script languages are fast enough is a standard misconception. I have been writing web apps since 1993 and have used C/C++, java, perl, python, ruby, and even lisp and honestly I have yet to encounter a script language that can handle high load environments. Perl comes closest but is a nightmare to support if the dev team is more than a few people. Python while a great language for system scripts, not so good for web apps. Ruby is a nice language but doesn't scale so well under load. Java better than interpreted language. C/C++ fastest way to execute web apps but also more difficult (unless you know it well already).
While I agree that interpreted language is great for low-medium server loads, under high loads you have to either start throwing hardware at the problem or rethink your language of choice.
Actually yes and majority of the huge sites on the web use C/C++ (having worked on several where 10 million hits a day is an easy load). Most places have their own but stl + boost is pretty damn nice and will do most of the things you want. You would probably want to look into writing ISAPI extension or apache modules which is not difficult at all and the performance difference between say C and java is significant. One point to note, java garbage collector under severe loads is not pleasant to tune (I have to deal with that currently and it's a pain). Its not uncommon for java process to spike to 1GB+ in a matter of seconds before GC has a chance to kick in and slow things down:) In C you can allocate and release memory in a much more controlled way thus controlling the server's footprint under spikey loads.
Personally I would never run a high volume site on top of a scripting language platform. While RoR is pretty nice on getting a site up and running and integrated with a database, it is still poor in the scalability department.
For a medium to large site they should consider using servlets and java and avoid J2EE.
For a very large site I would recommend C/C++ and maybe java if they have the budget for hardware.
The toughest part is getting developers that can code webapps (not just CGIs) in C/C++ (while easy to do C/C++ developers overall are hard to find and are not as cheap as ruby/perl/python ones and even java ones; this is from experience of trying to hire them). So they should check their developer base and see what is the fastest language they feel very comfortable with and go with it. From experience they may have to settle for java since that will provide them a large pool to pick developers from and the learning curve is slightly less steep than C/C++.
I suspect they fell into the trap of building a demo fast using RoR and then just going with it into production, I have seen this way too many times unfortunately.
Why separate C and C++? I use them both in projects I work on and if you combine them you get 25% which is higher than Java. That study overall is pretty silly with questionable basis. I would argue there is more C/C++ code in the world than any other language; that doesn't mean it is the right language for every job. I use it when I need performance and control over how memory is managed (along with many other reasons). I also use java when performance is probably not an issue. When I need a script I use python. It's all about knowing the right tool to use and foreseeing where the project will go.
Statistics are 63% of the time wrong and 51% of the time partially right...
Managing projects is an issue with developers, culture and diligence. I have been on small java projects that were a mess and on many hige C++ projects that were great to work on. Java allows weak developers to write code without knowing how things work underneath which is unfortuante because it is much harder to find good developers in the java world, I interview too many people who don't even understand basic data structures yet claim to be enterprise level engineers.
Even though I do a lot of java (industry fad?!), I miss the fine grained control over memory and os resources that C++ offers and hope to someday do a lot more C++.
I use a cheap method because I can't afford an extra computer and a raid controller and 2 high end drives. Instead I use Maxtor 500GB network storage ( http://www.maxtorsolutions.com/en/catalog/MSS_II/ )(260$ at local fry's) and attached to it is 500 GB USB drive ( http://www.maxtorsolutions.com/en/catalog/OT4/ ) (160$ at local fry's). I use the main network drive for storage and every week I mirror the content to the second 500GB usb drive. I also only have about 2GB of stuff I really care about and that gets written to DVD every month, so I have lots of backups.
This is a very simple solution but it only cost me 420$ (actually only 160$ since I already had the network drive and was using it to share data between several computers). This has been running for about a year, no problems (network drive has been running for about 2 years); maxtor uses linux as the OS on the network drive and confgurable via web browser. I use a cron/rsync to mirror the drives by the way (you can use windows scheduler and some file sync program like cygwin's rsync or python version of rsync; whatever you like). You can also rsync daily but I personally don't change stuff that often.
You can also look up Western Digital, they have a similar set up (and I assume Seagate and Fujitsu too), but I have had a lot of good exteriences with Maxtor so I chose them.
Counter-counter point, if you have novices writing optimizations then the project is already doomed, else an experienced programmer will be able to write readable optimized code from the start.
Slashdot Mirror
1. Lame product that doesn't work but gets funding...check
I have tried using it for a few days and have never seen so many dead links (results of spider traps), unavailable servers, 404s, etc... it feels just like AltaVista in the days before the end.
2. Lots of money without a real plan... check
25 million for yet another search engine
3. Marketing people advertising how great their work environment is to get attention... check
*this
4. ???
5. Profit
Yep, all in order here, cover your ears, boom coming again.
I can agree to that. When I has in grad school I was applying for a scholarship (because I could not afford the school) and was told I was beat out by a foreign student with much better grades than me. A month later they offered me the scholarship (and instructor in charge told me that the transcript they received was forged and the student did not have perfect grades). So what this Omar guy did was trivialize the grades of the students who actually got good grades and worked hard for them (possibly ruining their chances at getting into a great school). The real victims are other students not the government or the education system.
http://www.fentek-ind.com/kbmrfotb45ub.htm
Built-in trackball and 45ft range may work for you.
Well unfortunately the market for good developers is quite thin with a lot of not so good ones leftover from the boom and the upper managements' constant push for offshore development teams to save money. This of course is part of a large problem where good developers are expensive and rightfully so and financial people can't see it as a justified expense allocate pittance of a salary. What we get is either semi-competent developers or off-shored ones and in either case you never know what you are getting.
"It's like a 'surprise ball' sometimes you get a raisin and sometimes you don't, that's the surprise." - Yosh Schmenge
It did happen, and to one of the biggest sites on the web and the only reason it was not a big deal is due to their very high profit margin at the time. They could afford the hardware and data center fees. Smaller companies would have had real impact to their profits.
The problem with java is not just raw performance, it's a combination of many things that I have noticed (ignoring the obvious nature of interpreted code):
- Garbage collector instills a false sense of safety, so peaky allocations often deplete resources much quicker without an easy way to release them (in C you delete them when done with java you wait for GC and if load is sudden and high it can get out of hand)
- java IDEs allow very easy refactoring which results in lots of classes and lots of 2-5 line methods which create huge call trees and if an exception occurs its not uncommon to see 100 lines deep in the stack trace
- there is no real const so objects get passed around as copies where modification may not be desired (final is not a const, the reference is constant while underlying object is not), requires usage of interfaces on objects to limit access
- too many huge jars (which not a coding issue) it sucks up deployment time when you have 50 jars that are 3-5mb in size
among other minor issues. While I use java daily at work I find that with C++ I was a lot more productive and build took way less time despite compiled nature of the code.
Another minor annoyance is distribution of code, while it is easy to send your jar file (which is say 100k) and execute the code, it often depends on other jars which are huge by comparisson and have to be shipped as well. For example xalan/xerces are 5MB zipped which in C++ you can just use the static libs and the resulting executable for the same code is 50-60k total, maybe not a big issue but an annoying one.
No language is perfect but I am betting C++ will be making a big resurgence with so many ajax based apps coming to the web with sub-stellar usability and response... just a guess and a hope.
It is a very real problem however and one that now spans continents (and language (human kind) barriers).
Not sure there is an easy solution to this but sometimes it is easier to give people rubber mallet than box cutters, the collateral damage is less.
I just won't go down the path of perl personally. I may read that book and do it right, but the code gets supported by many people of varying level of coding skill and you can't force everyone to read book. I have seen some simple and straightforward code become unreadable after 3 months of people adding features to it.
I agree that this is possible with any language but perl's syntax can be deadly if an advanced perl user makes changes and then mid/entry level perl developers work on it also.
Ultimately it comes down to what people are comfortable and what they know well, so I won't preach not using any specific language, whatever makes 'em happy. For my projects I'll stick to java/C++ for coding and python for scripting; just a personal preference.
It may sound that way but it happened (the 300 was a type, 500 was the initial machine count, not that it changes things too much).
In my other post I went into it in my other post to you, but it was mainly j2ee which the architects claimed they profiled but when the code got written it turned out to be slower than expected. Other issue was using java based libraries for some critical rendering (can't go too much into it due to security) and had to be reverted back to old C++ code via JNI which was faster but not native. There were many other issues.
Deep down inside the architects knew that they would need way more hardware but no way CTO/CFO would approve of the whole thing, so I feel there is a lot of "optimism" involved here.
Well last place I worked in that shall remain nameless, went from 500 machine C++ website to almost 5000 machine java website to maintain same response times. Their best engineers and architects planned the move for over a year and initially the machine count was 1000 and the plan was to use j2ee to server common application logic to a cluster of servers. Development took roughly a year for 10% of the site (including the foundation work), over 400 people worked on it.
QA ran perf tests and found that the performance was abysmal (RPC calls, inter-node communication, general j2ee slowness, etc), after much effort this was converted to jsps and servlets to regain some performance but it was nowhere near the 2x that Sun was claiming. There were a lot of factors that affected this but mostly it was the fact that java is slower than C++, java doesn't allow fine grained memory control, java almost requires you to have a lot of objects and small methods (thanks to plugins like codestyle, checklipse, etc).
So here we had a lot of PhDs, top level architects and lots of developers get things working but it was not meant to be within a plan.
While the overall costs did not explode by a factor of 16 it was close to a factor of 10, the decision to make the change mostly comes from above (CTO/chief architect level) and the real problem is not quite as easy.
Unfortunately the problem is always a constraint on budget that has people underestimating (or their project will not be approved) then trying their best only to realize they need more hardware.
Since you do this for a living I am sure you have ran across this at customer sites, it is very hard to accurately estimate the hardware requirement before the site is built but the budget for it has to be approved before the contracts are signed so you have the chicken/egg problem and often just hope for the best. If the site was already built and profiled, then obviously, estimating hardware is trivial.
I feel your pain, we are using ext and while it's a wonderful toolkit the json stuff is quite time consuming on both server and client, time that can be spent doing something more useful like rendering the actual content. In some places I've resorted to sending actual HTML snippets and using innerHTML to "insert" them directly without relying on ext/json. For non-performance critical tasks it's a pretty nice library.
I do agree that C++ is going to get a big resurgence as people are going to start looking for faster ways to execute their applications (and AJAX calls) and while scripting is adequate for low volume, once the volume of users goes up you really want the server to be the least of their concerns and concentrate on speeding up the network, database, etc.
AJAX makes a lot of little calls back to the server and it is critical that they are processed very quickly to give the site a responsive appearance, there is an appreciable difference between an ajax server response of 10ms compared to 50ms (after you factor in the network latency, bandwidth, jitter and other network issues).
I'm hoping C++ comes back faster, I am disliking java more and more every day. I hate the long build times, long deploy to tomcat times and long startup times; I waste more time now waiting to verify/debug/enhance than I ever did with C++. My browsing and slashdot posting skills did go up since I do more of it now while I wait.
However if someone switches from windows and using Visual Studio to mac and xcode, they will definitely notice that VS was a far better product however since they have to code for the mac and xcode is proetty much tops in that arena they just have to adapt since teir decision is driven by the OS issues.
I've seen many kinds of applications: CPU bound, DB bound, network bound, etc. If the app is going to be DB bound or network bound then it does make sense to stick to a script. However if suddenly the DB is no longer the problem (local caching, bigger DB cluster, faster internal network), then the scripted application becomes a bottle neck and often much more difficult of a problem to solve by comparison (unless you find that adding more machine/CPU to be viable). If scaling and hardware costs are not a problem then by all means, scripting is fine.
I worked in a place that went from C++ to java and the machine count went from 300 to over 5000 to maintain the overall performance and handle the growth at the same time. Needless to say supporting 5000 machines is not as easy as 300 and the IT costs really cut into the overall profit.
I find it hard to write good perl, there are so many ways to write something that invariably people will use what they are comfortable with but necessarily what someone else would use, so you get a lot of different coding styles which make it very hard to debug and support.
Personally I don't do perl for that reason, was on a project long ago where I inherited some perl scripts and they were downright painful to work with.
You've never done this have you, but in theory your argument sounds feasible.
I would not generate HTML using C++, stick to MVC model, let C++ handle the controller stage and build the model then hand it off to any number of technologies setup for cross browser compatibility (XSLT, templated HTML, SOAP, RSS, XML or emit the model as JSON and use ext toolkit). There are a lot of ways and I have used ext with a lot of success, their code is really solid and lets you prototype a site quickly then attach JSON model and ajax calls (which are really nice to have in C++ so that the site feels responsive under load).
:)
Sure PHP and JSP is nice due to ease of getting things running quickly but when the load gets really high you are then faced with difficult problems which in some cases more hardware can solve but more often it requires a rewrite.
Don't forget hardware is not just buying a computer, it also involves power consumption, cooling fees (air conditioning is quite expensive), network costs, storage/hosting costs, etc. I have worked in too many places where executives just state that they will throw more hardware at the problem and then complain when IT bills for infrastructure reduce their precious ROI to rubble
I would say that you generalization that script languages are fast enough is a standard misconception. I have been writing web apps since 1993 and have used C/C++, java, perl, python, ruby, and even lisp and honestly I have yet to encounter a script language that can handle high load environments. Perl comes closest but is a nightmare to support if the dev team is more than a few people. Python while a great language for system scripts, not so good for web apps. Ruby is a nice language but doesn't scale so well under load. Java better than interpreted language. C/C++ fastest way to execute web apps but also more difficult (unless you know it well already).
While I agree that interpreted language is great for low-medium server loads, under high loads you have to either start throwing hardware at the problem or rethink your language of choice.
Actually yes and majority of the huge sites on the web use C/C++ (having worked on several where 10 million hits a day is an easy load). Most places have their own but stl + boost is pretty damn nice and will do most of the things you want. You would probably want to look into writing ISAPI extension or apache modules which is not difficult at all and the performance difference between say C and java is significant. One point to note, java garbage collector under severe loads is not pleasant to tune (I have to deal with that currently and it's a pain). Its not uncommon for java process to spike to 1GB+ in a matter of seconds before GC has a chance to kick in and slow things down :) In C you can allocate and release memory in a much more controlled way thus controlling the server's footprint under spikey loads.
Personally I would never run a high volume site on top of a scripting language platform. While RoR is pretty nice on getting a site up and running and integrated with a database, it is still poor in the scalability department.
For a medium to large site they should consider using servlets and java and avoid J2EE.
For a very large site I would recommend C/C++ and maybe java if they have the budget for hardware.
The toughest part is getting developers that can code webapps (not just CGIs) in C/C++ (while easy to do C/C++ developers overall are hard to find and are not as cheap as ruby/perl/python ones and even java ones; this is from experience of trying to hire them). So they should check their developer base and see what is the fastest language they feel very comfortable with and go with it. From experience they may have to settle for java since that will provide them a large pool to pick developers from and the learning curve is slightly less steep than C/C++.
I suspect they fell into the trap of building a demo fast using RoR and then just going with it into production, I have seen this way too many times unfortunately.
Why separate C and C++? I use them both in projects I work on and if you combine them you get 25% which is higher than Java. That study overall is pretty silly with questionable basis. I would argue there is more C/C++ code in the world than any other language; that doesn't mean it is the right language for every job. I use it when I need performance and control over how memory is managed (along with many other reasons). I also use java when performance is probably not an issue. When I need a script I use python. It's all about knowing the right tool to use and foreseeing where the project will go.
Statistics are 63% of the time wrong and 51% of the time partially right...
Managing projects is an issue with developers, culture and diligence. I have been on small java projects that were a mess and on many hige C++ projects that were great to work on. Java allows weak developers to write code without knowing how things work underneath which is unfortuante because it is much harder to find good developers in the java world, I interview too many people who don't even understand basic data structures yet claim to be enterprise level engineers.
Even though I do a lot of java (industry fad?!), I miss the fine grained control over memory and os resources that C++ offers and hope to someday do a lot more C++.
"...bleeding edge programming in F#, to cruel and unusual C++..."
All credibility of the author lost in one absurd statement.
I use a cheap method because I can't afford an extra computer and a raid controller and 2 high end drives. Instead I use Maxtor 500GB network storage ( http://www.maxtorsolutions.com/en/catalog/MSS_II/ )(260$ at local fry's) and attached to it is 500 GB USB drive ( http://www.maxtorsolutions.com/en/catalog/OT4/ ) (160$ at local fry's). I use the main network drive for storage and every week I mirror the content to the second 500GB usb drive. I also only have about 2GB of stuff I really care about and that gets written to DVD every month, so I have lots of backups.
This is a very simple solution but it only cost me 420$ (actually only 160$ since I already had the network drive and was using it to share data between several computers). This has been running for about a year, no problems (network drive has been running for about 2 years); maxtor uses linux as the OS on the network drive and confgurable via web browser. I use a cron/rsync to mirror the drives by the way (you can use windows scheduler and some file sync program like cygwin's rsync or python version of rsync; whatever you like). You can also rsync daily but I personally don't change stuff that often.
You can also look up Western Digital, they have a similar set up (and I assume Seagate and Fujitsu too), but I have had a lot of good exteriences with Maxtor so I chose them.
The QWERTY keyboard is a real example, it was done that way to keep the mechanical typewriters from jamming by effectively slowing you down.
Counter-counter point, if you have novices writing optimizations then the project is already doomed, else an experienced programmer will be able to write readable optimized code from the start.