I agree with the console comment. I have my PS2 hooked into the S-Video port of a TV card. Before I bought a Monster Cable, I thought all my games were in 320x240, turns out most of them were actually interlaced 640x480.
That would be more reasonable if you didn't have to have CPU interrupts for every frame as well as the occasional gettimeofday(). These are the things that kill CPU performance when there's a high speed interface involved.
Also, in many cases, all you want to do is forward a packet out another interface and it would be cool if the kernel didn't need to be bothered with such a simple task.
There is a need for accelerated TCP/IP. I suspect this technology is meant for clustering, where the packets can get huge but the frames are relatively tiny and bothersome.
That's a really good idea considering consoles are supposed to last for 5 years. If the memory doubles in transistors every 18 months, after 3 years you'd be able to sell an expansion with 4 times the RAM for the cost of the original memory.
The Dreamcast also had texture compression whereas the PS2 does not, so that 8MB and 16MB were a lot more effective as far as textures were concerned.
Even then, 640x480x16bits is about 1MB. So even with frame buffering and the Z buffer, there's still more video RAM hanging around. I also remember a few Dreamcast games using 320x240 resolution.
On the other hand, while the Dreamcast did have more video RAM, I don't think it was embedded into the GPU like the PS2's (which I assume meant much lower bandwidth for the DC). So I doubt the same level of geometric detail or transparency effects could have been achieved on the Dreamcast since accessing the Z buffer was probably much slower.
This thing seems more comparable to a Mac Mini in terms of price/performance. While the intel video chipset may suck a lot more, it's not like you'd be playing many 3D games on a Mac anyways. You'd probably have to file off the ugly ass contouring as well to make the IWill look decent.
I don't work for any of these companies, I was just browsing for something else and thought this was sort of cool.
The PLUM keyboard's layout looks pretty cool. It's much easier to memorize/hunt and peck than Dvorak while still focusing most of the typing on the home row. It also looks as though its inventors tried to preserve Dvorak's key positions when you compare the two layouts side by side.
I'm guessing the patents on it are probably crazy though as it's fairly new. It's the only alternative keyboard layout I know of that's both more efficient and makes perfect sense to people who normally wouldn't care about such things.
When it was released, the Emotion Engine in the PS2 actually would have been pretty wicked for supercomputing applications if Sony had sold a version with faster interconnects and more RAM. The processors in the PS2 are designed almost entirely to crunch vector operations, which is what most scientific codes rely on. It's really an excellent computer, it just sucks at graphics. The 4MB of uncompressed video memory and lack of hardware texture support are particularly ugly.
I suspect that the main reason there was never an Emotion Engine based cluster product was because the high performance market is tiny, especially compared to the console market, and Sony was already having trouble meeting demand with their exotic chipset when it first came out.
Anyways, I think the guy does go overboard about this new architecture. It probably will be a lot faster than PCs at certain tasks but you can only fit so many transistors in a chip. The cell stuff is cool though, it seems to fit a lot better with what most computers spend their time processing unless you're doing a lot of compiling or database operations.
I think the order that they go in is mostly irrelevant if you twist the plot slightly.
Make the first one on Earth with a main character that has a slightly different back-story and if it's successful, have him go to Deimos and Phobos with a bigger budget and face real monsters. All you need to know on Earth is that a portal from hell opened, they can slowly unravel that it started on Mars and set up what was Doom 1. If a third one gets made, then send him into hell for the final showdown. Then he can get into his homemade interstellar spaceship and defeat the vorticons.
By getting closer to hell each time, they can end them with him going into a portal where the audience can assume he died a tragic death if the money isn't there for a sequel.
Also, there are lots of ways to have a badass main character on Earth without having him go through Hell first, give him some super armour, or genetically enhance him, or have him get broken out of badass marine prison by a demon attack or something. Not only that, but for film, you'd probably want a group of characters anyways so that you can kill off a few and provide potato-head dialogue to explain what's going on. Otherwise, the movie would be pretty confusing.
See what Im getting at here? A DooM movie would be 90 minutes of:
a) Demons from hell b) Zombie headshots c) Ultra-violence d) Satanism/satanic symbolism e) Absolutely no redeeming moral value
That sounds like it could make for a pretty wicked suspense film to me. Something like Alien but with different visuals and imagery.
Doom is all about the atmosphere, most of the levels in the older games focused more on approaching enemies than actually fighting them. For example, you'd always hear enemies in other rooms before facing them, most ambushes were obvious from the layout of the room they were set in, and there was almost always something you could do to avoid or knock out a room that was overcrowded with enemies.
In that vein, I think Doom64, with it's freaky non-musical ambient soundtrack and improved lighting engine, was the best of the sprite-based games. One of the early levels even has a section that mimics the lighting from the carnival scene in Apocalypse Now.
I could understand if this guy was a Steven Spielberg but surely he can't be that deluded?
Ya but if Stephen Spielberg directed, he'd probably keep replacing the guns with a flashlight and distort id's original vision. Oh wait...
Really though, if I remember correctly, a significant part of Doom 2 took place on Earth. Considering that the budget might not allow for a Mars base without looking rediculously cheesy, a movie set on Earth would still be true to the original source even if it's not as cool. I haven't been following this movie though and it's not clear where it's being set, so whatever, I'm probably wrong.
Anyways, I think it's obvious what happened here. Resident Evil: Apocalypse just made a decent amount of money on a tiny budget and now some studio execs are trying to me-too themselves into the same situation. Consequentially, they're trying to reduce their investment risk by making it as close to RE as possible since that property has already shown success. You see it all the time in movies, like when they release a bunch of natural disaster movies within months of eachother. To these people, the Doom property isn't a story or a setting, it's a brand. They're hoping to make a quick buck on name recognition as Doom is a pretty famous gaming franchise. I'm guessing that any interest in actually keeping the Doom universe intact is peripheral at best and only exists to keep from alienating casual gamers.
Similarly, biological weapons and desease are in the news right now whereas demons erupting from Hell are not. If you're funding a movie that seems pretty shitty to begin with, it would probably be in your best interest to choose an antagonist that most represents your audience's fears even if that manifestation is pretty rediculous.
Metroid Prime does something where the game loads areas whenever you open a door. The animation of the door opening is slightly delayed and long enough (about a third of a second) to load the next room while not being intrusive at all.
The only time I ever noticed this enough to realize it was happening was once while a larger environment was causing the drive to spin a lot and the door animation had a delay. Otherwise, the experience was seamless.
Many GameCube games have no loading times or extremely short ones. I'm guessing Nintendo has some wicked tool in their dev kit as the optical drive is slower than most. On the other hand, maybe it's just that they don't have to worry about precaching to the harddrive the way XBox and PC games do.
x86 is probably a ways off being able to provide thousands of cores in a single box with a single memory architecture.
Probably not, but for the same price, I'd be able to have tens or hundreds of x86 Linux or BSD boxes doing the same tasks in most cases. Cheap x86 servers are also replacable like lightbulbs allowing for high redundancy and thus high availability.
I also don't see how the few HPC applications that would benefit from this architecture could pay for the costs of its development unless it blows away the NEC stuff. Maybe there are some database applications that would benefit but the Itanium 1 already tried catering to the large memory machine market.
I think the otherwise idle video card does most of the work anyways (at least it probably will in the future if not).
The reason eye candy is necessary is because the most impressive thing you can do to show off your Mac is to play a movie in Quicktime, minimize it, then watch as the video is still playing in the icon. Blatant eye candy sells computers and will definitely sell something that's already free.
It seems like it would be cheaper for them to just purchase an existing engine and focus solely on the content. Not only would they not have to waste an extra 6 months, but RPGs almost always look dated. They'd probably have a more impressive product if they let someone like id or Epic provide something that's consistently up to date instead of trying to do it in house while simultaneously developing a game as well, especially given their limited staff.
While someone else's engine would create some limitations, I don't think it would cause a drastic decrease in the overall quality if they were properly worked around. For example, not being able to have one huge map didn't make Fallout any worse than Arcanum but it did change the gameplay somewhat.
He had a poor handle on PC components of the day. A Hercules graphics card could display at 720x348x1bit in 1982. PCPaint was using a mouse in 1984.
While there might have been some issues with stuff like memory transfers to fill in parts of the screen quickly enough, I don't buy his argument that a PC couldn't run MacOS. Even if it couldn't have in 1984, I'd guess that it would easily have been doable within 2 years, especially if they developed their own add on card that accelerated the more complicated GUI operations and mouse.
A lot of games, especially ones that are just updates to older engines, are great examples of the good option. The annual sports games from EA have mostly been perfected and are done quick. Most importantly, people buy them.
Some of the most technically brilliant games out there are made at a pretty rapid pace because of the Unreal and Quake engines. All it costs is a million or two for the license and code, so there's good and fast. The engines themselves are evolutions and reimplementations of a slow moving design, so there's good and cheap.
Really, I think the abstraction and scale aspects that the writer is talking about have been perfected in games, they use a lot of abstract tools and scripting for level design and modelling. UnrealEd in particular seems like exactly what he's talking about when he mentions ASIC design.
Game developers even work industrialized 19th century hours. Maybe this guy's on to something after all!
But really, the thing with games is that a lot of the best ones have no release date, even if they're completed in less than a year. The worst ones are usually that way because the publisher forced them out half done, making them unplayable. I think the problem with trying to write something well and quickly comes from the way it's done, project managers only treat the symptoms by setting dates in stone.
I think some of it comes from the perception of programs not being very good. Like how often do your electronics or car blow out compared to your operating system?
Some of this comes from the fact that most people spend all of their time at a computer looking at one of the more unstable programs around, but some of it also comes from programming not being all that mature. A lot of stuff is written in languages like C and C++ that aren't very safe and getting concrete and precise specifications written is often impossible.
In general, programming is just hard to do for humans. Especially in business where time is critical, it's like showing up halfway through a math exam and trying not to make mistakes. The best products seem to come from places that have unlimited time, like BSD and games where the release date is 'When it's done.'
Of course, when you do let developers do their own thing, you get at what this article is talking about where humans write as little error-prone code as possible: easily attainable, commoditized systems, that encourage reuse and reapplication, which you tie together to solve whatever general problem you have, allowing you to focus on the new bits. The STL, Linux kernel, various libraries, and glue languages are powerful abstractions in this sense. It's weird and sad that the closest thing Microsoft has to Perl or Python is VisualBasic.
I have a stats exam tomorrow so this will be "studying".
Let's say you have a drive with a.1% independant chance of failing in any given month. This assumption seems alright since most drives I've seen age well if some defect hasn't killed them within weeks of purchase. We'll ignore these defects. As in real life, drives in the array that fail are immediately replaced with new ones.
You'll have a poisson distribution to count the number of failures for any drive. So for t months, the chance of x failures for a drive is:
f(x)=( ( e^(-.001t) ) * (0.001t)^x)/x!
The expected value, or mean, for this is just 0.001t.
The chance of a single failure taking out your RAID0 array of n drives in a timespan t is a geometric distribution:
g(n) = ( (1-f(1) )^n ) * f(1)
The mean is given by the expected value, which is ( 1 - f(1) ) / f(1).
The probability of k failures in t months taking out your RAID5 array of n drives follows a negative binomial distribution:
nb(n) = ( (n + k + 1)choose(n) ) * (f(1)^k) * ( (1- f(1) )^n)
This is the probability of failing twice in a timespan, t. By setting t to smaller than it takes for you to fix a drive, you can see how reliable a raid5 system can be. The mean is k( 1-f(1) ) / f(1).
This should be right but I just woke up so beware. Doing the actual calculations is left as an exercise to the reader because I really need a beer.
I wonder, can we beowolf custer a beowulf cluster?!;)
You might be interested in grid computing, in which a group of academics with heads too big for their common good decide not to build one fucking huge computer in one place, but instead spend all their grant money on fiber transceivers and other equipment that can transfer at a few dozen GBit between far less powerful clusters. Whenever you see a grid built with modern equipment (rather than one that strings together a few older machines), it means the people involved at some level were playing politics so that they could 'me too' their department into owning a piece of it.
I once watched some of this process in motion, which helped to smack down a far more sensical and quite impressive machine proposal, and found the whole thing to be entirely retarded.
With Java, pretty much anything you'd want to reuse is already included in the massive standard library, simple stuff like ArrayList and TreeMap come up every day. Java's Object hierarchy itself is an excellent demonstration of code reuse. Because of the massive library, the code you do write yourself will probably be customized to whatever you're doing. That's a good thing.
On a less bloated front, I often write objects into a test harness before dropping them into a large project. This allows for easier and more thorough testing. When I do implement them, I'll be certain that they won't conflict with other names and that they work the way they're supposed to.
By properly using interfaces, I can also tear down what I wrote and reimplement it without having to change the rest of the code. So I can write just enough to get things off the ground, then go work on other things. For data structures like priority queues and whatnot where a grossly inefficient solution can be written in minutes, this is essential.
This stuff can be done in C with header files and strict naming policies but it's a lot more painful.
The funny thing about your example is that 64-bit Windows is still in beta while various x86-64 Linux distros are considered stable. So you're not really using all your hardware in Windows either unless you're comfortable with pre-release operating systems, which would seem odd for someone so worried about hosing their disk.
The nForce3 ethernet chipset will be in the next kernel release, it might even be in the most current one, I'm not sure. Within about 6 months, it will probably be supported by whatever distribution you use. Consider that open source developers can't really do anything for hardware until they get their hands on it, so there's usually a time lag in support for bleeding edge stuff like yours.
While you make a good point, I think the ease of use issue is mostly irrelevant.
Regardless of whether or not linux sucks, it will eventually become the defacto operating system because it's cheaper. Without all those monopoly profits flowing into one vendor, there will be more money circulating in the economy to be used for growth.
When you have the choice as a business user between those $300 licenses (BTW how can you possibly charge that much for something that literally sells billions? The R&D has long been paid for, Bill.) or spending that money on something else that will earn more profit in the end, all while putting up with a crappy linux desktop environment, the choice becomes clear. Even if you're just spending that money on extra support staff and the migration, at least it's going back directly into the marketplace instead of Microsoft deciding how best to spend it.
I also think that the quality of the desktop is not that huge of a motivating factor for people to begin with. The eMac and iBook are both only slightly more expensive than your average bargain Wintel box and support MS Office, Photoshop, and Macromedia stuff, which would probably cover most non-financial and non-gamer users, but Apple's market penetration is still extremely weak.
And the Windows desktop isn't the paragon of useability. Log on to any non-technical user's system and you'll see something like 15 icons in the tray all eating up memory, ads that pop-up even when no browser is open, hundreds of icons all over the place for programs they haven't used in years, many of them for readme files and expired shareware, and maybe a few viruses. Quite simply, the average user will put up with whatever shit you put in front of them as long as the price is right. They just don't care as much about the quality of their workspace as we do.
As more people adopt linux and shape it to their needs, its value rises, overcoming migration costs. But it doesn't really matter whether improvements in the OS relate to increasing its value in some unrelated way or reducing migration costs, either is fine. But really, it just doesn't make sense to pay an inflated price on top almost every computer sold when you don't have to. That money can be used to buy more machines, or more people, or whatever else will help make people more productive. Ultimately, things will improve for everyone but Microsoft.
That's just my armchair Micro-econ 101 analysis of the situation anyways.
Slashdot Mirror
I agree with the console comment. I have my PS2 hooked into the S-Video port of a TV card. Before I bought a Monster Cable, I thought all my games were in 320x240, turns out most of them were actually interlaced 640x480.
That would be more reasonable if you didn't have to have CPU interrupts for every frame as well as the occasional gettimeofday(). These are the things that kill CPU performance when there's a high speed interface involved.
Also, in many cases, all you want to do is forward a packet out another interface and it would be cool if the kernel didn't need to be bothered with such a simple task.
There is a need for accelerated TCP/IP. I suspect this technology is meant for clustering, where the packets can get huge but the frames are relatively tiny and bothersome.
That's a really good idea considering consoles are supposed to last for 5 years. If the memory doubles in transistors every 18 months, after 3 years you'd be able to sell an expansion with 4 times the RAM for the cost of the original memory.
The Dreamcast also had texture compression whereas the PS2 does not, so that 8MB and 16MB were a lot more effective as far as textures were concerned.
Even then, 640x480x16bits is about 1MB. So even with frame buffering and the Z buffer, there's still more video RAM hanging around. I also remember a few Dreamcast games using 320x240 resolution.
On the other hand, while the Dreamcast did have more video RAM, I don't think it was embedded into the GPU like the PS2's (which I assume meant much lower bandwidth for the DC). So I doubt the same level of geometric detail or transparency effects could have been achieved on the Dreamcast since accessing the Z buffer was probably much slower.
This thing seems more comparable to a Mac Mini in terms of price/performance. While the intel video chipset may suck a lot more, it's not like you'd be playing many 3D games on a Mac anyways. You'd probably have to file off the ugly ass contouring as well to make the IWill look decent.
I don't work for any of these companies, I was just browsing for something else and thought this was sort of cool.
The PLUM keyboard's layout looks pretty cool. It's much easier to memorize/hunt and peck than Dvorak while still focusing most of the typing on the home row. It also looks as though its inventors tried to preserve Dvorak's key positions when you compare the two layouts side by side.
I'm guessing the patents on it are probably crazy though as it's fairly new. It's the only alternative keyboard layout I know of that's both more efficient and makes perfect sense to people who normally wouldn't care about such things.
When it was released, the Emotion Engine in the PS2 actually would have been pretty wicked for supercomputing applications if Sony had sold a version with faster interconnects and more RAM. The processors in the PS2 are designed almost entirely to crunch vector operations, which is what most scientific codes rely on. It's really an excellent computer, it just sucks at graphics. The 4MB of uncompressed video memory and lack of hardware texture support are particularly ugly.
I suspect that the main reason there was never an Emotion Engine based cluster product was because the high performance market is tiny, especially compared to the console market, and Sony was already having trouble meeting demand with their exotic chipset when it first came out.
Anyways, I think the guy does go overboard about this new architecture. It probably will be a lot faster than PCs at certain tasks but you can only fit so many transistors in a chip. The cell stuff is cool though, it seems to fit a lot better with what most computers spend their time processing unless you're doing a lot of compiling or database operations.
I think the order that they go in is mostly irrelevant if you twist the plot slightly.
Make the first one on Earth with a main character that has a slightly different back-story and if it's successful, have him go to Deimos and Phobos with a bigger budget and face real monsters. All you need to know on Earth is that a portal from hell opened, they can slowly unravel that it started on Mars and set up what was Doom 1. If a third one gets made, then send him into hell for the final showdown. Then he can get into his homemade interstellar spaceship and defeat the vorticons.
By getting closer to hell each time, they can end them with him going into a portal where the audience can assume he died a tragic death if the money isn't there for a sequel.
Also, there are lots of ways to have a badass main character on Earth without having him go through Hell first, give him some super armour, or genetically enhance him, or have him get broken out of badass marine prison by a demon attack or something. Not only that, but for film, you'd probably want a group of characters anyways so that you can kill off a few and provide potato-head dialogue to explain what's going on. Otherwise, the movie would be pretty confusing.
That sounds like it could make for a pretty wicked suspense film to me. Something like Alien but with different visuals and imagery.
Doom is all about the atmosphere, most of the levels in the older games focused more on approaching enemies than actually fighting them. For example, you'd always hear enemies in other rooms before facing them, most ambushes were obvious from the layout of the room they were set in, and there was almost always something you could do to avoid or knock out a room that was overcrowded with enemies.
In that vein, I think Doom64, with it's freaky non-musical ambient soundtrack and improved lighting engine, was the best of the sprite-based games. One of the early levels even has a section that mimics the lighting from the carnival scene in Apocalypse Now.
Ya but if Stephen Spielberg directed, he'd probably keep replacing the guns with a flashlight and distort id's original vision. Oh wait...
Really though, if I remember correctly, a significant part of Doom 2 took place on Earth. Considering that the budget might not allow for a Mars base without looking rediculously cheesy, a movie set on Earth would still be true to the original source even if it's not as cool. I haven't been following this movie though and it's not clear where it's being set, so whatever, I'm probably wrong.
Anyways, I think it's obvious what happened here. Resident Evil: Apocalypse just made a decent amount of money on a tiny budget and now some studio execs are trying to me-too themselves into the same situation. Consequentially, they're trying to reduce their investment risk by making it as close to RE as possible since that property has already shown success. You see it all the time in movies, like when they release a bunch of natural disaster movies within months of eachother. To these people, the Doom property isn't a story or a setting, it's a brand. They're hoping to make a quick buck on name recognition as Doom is a pretty famous gaming franchise. I'm guessing that any interest in actually keeping the Doom universe intact is peripheral at best and only exists to keep from alienating casual gamers.
Similarly, biological weapons and desease are in the news right now whereas demons erupting from Hell are not. If you're funding a movie that seems pretty shitty to begin with, it would probably be in your best interest to choose an antagonist that most represents your audience's fears even if that manifestation is pretty rediculous.
Metroid Prime does something where the game loads areas whenever you open a door. The animation of the door opening is slightly delayed and long enough (about a third of a second) to load the next room while not being intrusive at all.
The only time I ever noticed this enough to realize it was happening was once while a larger environment was causing the drive to spin a lot and the door animation had a delay. Otherwise, the experience was seamless.
Many GameCube games have no loading times or extremely short ones. I'm guessing Nintendo has some wicked tool in their dev kit as the optical drive is slower than most. On the other hand, maybe it's just that they don't have to worry about precaching to the harddrive the way XBox and PC games do.
pffft Install OpenBSD and you'll never have to see your parents again.
Probably not, but for the same price, I'd be able to have tens or hundreds of x86 Linux or BSD boxes doing the same tasks in most cases. Cheap x86 servers are also replacable like lightbulbs allowing for high redundancy and thus high availability.
I also don't see how the few HPC applications that would benefit from this architecture could pay for the costs of its development unless it blows away the NEC stuff. Maybe there are some database applications that would benefit but the Itanium 1 already tried catering to the large memory machine market.
The dual ARM architecture of the iPod would make it awesome for a raycasting engine. iDoom anyone?
I think the otherwise idle video card does most of the work anyways (at least it probably will in the future if not).
The reason eye candy is necessary is because the most impressive thing you can do to show off your Mac is to play a movie in Quicktime, minimize it, then watch as the video is still playing in the icon. Blatant eye candy sells computers and will definitely sell something that's already free.
It seems like it would be cheaper for them to just purchase an existing engine and focus solely on the content. Not only would they not have to waste an extra 6 months, but RPGs almost always look dated. They'd probably have a more impressive product if they let someone like id or Epic provide something that's consistently up to date instead of trying to do it in house while simultaneously developing a game as well, especially given their limited staff.
While someone else's engine would create some limitations, I don't think it would cause a drastic decrease in the overall quality if they were properly worked around. For example, not being able to have one huge map didn't make Fallout any worse than Arcanum but it did change the gameplay somewhat.
He had a poor handle on PC components of the day. A Hercules graphics card could display at 720x348x1bit in 1982. PCPaint was using a mouse in 1984.
While there might have been some issues with stuff like memory transfers to fill in parts of the screen quickly enough, I don't buy his argument that a PC couldn't run MacOS. Even if it couldn't have in 1984, I'd guess that it would easily have been doable within 2 years, especially if they developed their own add on card that accelerated the more complicated GUI operations and mouse.
A lot of games, especially ones that are just updates to older engines, are great examples of the good option. The annual sports games from EA have mostly been perfected and are done quick. Most importantly, people buy them.
Some of the most technically brilliant games out there are made at a pretty rapid pace because of the Unreal and Quake engines. All it costs is a million or two for the license and code, so there's good and fast. The engines themselves are evolutions and reimplementations of a slow moving design, so there's good and cheap.
Really, I think the abstraction and scale aspects that the writer is talking about have been perfected in games, they use a lot of abstract tools and scripting for level design and modelling. UnrealEd in particular seems like exactly what he's talking about when he mentions ASIC design.
Game developers even work industrialized 19th century hours. Maybe this guy's on to something after all!
But really, the thing with games is that a lot of the best ones have no release date, even if they're completed in less than a year. The worst ones are usually that way because the publisher forced them out half done, making them unplayable. I think the problem with trying to write something well and quickly comes from the way it's done, project managers only treat the symptoms by setting dates in stone.
I think some of it comes from the perception of programs not being very good. Like how often do your electronics or car blow out compared to your operating system?
Some of this comes from the fact that most people spend all of their time at a computer looking at one of the more unstable programs around, but some of it also comes from programming not being all that mature. A lot of stuff is written in languages like C and C++ that aren't very safe and getting concrete and precise specifications written is often impossible.
In general, programming is just hard to do for humans. Especially in business where time is critical, it's like showing up halfway through a math exam and trying not to make mistakes. The best products seem to come from places that have unlimited time, like BSD and games where the release date is 'When it's done.'
Of course, when you do let developers do their own thing, you get at what this article is talking about where humans write as little error-prone code as possible: easily attainable, commoditized systems, that encourage reuse and reapplication, which you tie together to solve whatever general problem you have, allowing you to focus on the new bits. The STL, Linux kernel, various libraries, and glue languages are powerful abstractions in this sense. It's weird and sad that the closest thing Microsoft has to Perl or Python is VisualBasic.
I have a stats exam tomorrow so this will be "studying".
.1% independant chance of failing in any given month. This assumption seems alright since most drives I've seen age well if some defect hasn't killed them within weeks of purchase. We'll ignore these defects. As in real life, drives in the array that fail are immediately replaced with new ones.
/x!
Let's say you have a drive with a
You'll have a poisson distribution to count the number of failures for any drive. So for t months, the chance of x failures for a drive is:
f(x)=( ( e^(-.001t) ) * (0.001t)^x)
The expected value, or mean, for this is just 0.001t.
The chance of a single failure taking out your RAID0 array of n drives in a timespan t is a geometric distribution:
g(n) = ( (1-f(1) )^n ) * f(1)
The mean is given by the expected value, which is ( 1 - f(1) ) / f(1).
The probability of k failures in t months taking out your RAID5 array of n drives follows a negative binomial distribution:
nb(n) = ( (n + k + 1)choose(n) ) * (f(1)^k) * ( (1- f(1) )^n)
This is the probability of failing twice in a timespan, t. By setting t to smaller than it takes for you to fix a drive, you can see how reliable a raid5 system can be. The mean is k( 1-f(1) ) / f(1).
This should be right but I just woke up so beware. Doing the actual calculations is left as an exercise to the reader because I really need a beer.
You might be interested in grid computing, in which a group of academics with heads too big for their common good decide not to build one fucking huge computer in one place, but instead spend all their grant money on fiber transceivers and other equipment that can transfer at a few dozen GBit between far less powerful clusters. Whenever you see a grid built with modern equipment (rather than one that strings together a few older machines), it means the people involved at some level were playing politics so that they could 'me too' their department into owning a piece of it.
I once watched some of this process in motion, which helped to smack down a far more sensical and quite impressive machine proposal, and found the whole thing to be entirely retarded.
With Java, pretty much anything you'd want to reuse is already included in the massive standard library, simple stuff like ArrayList and TreeMap come up every day. Java's Object hierarchy itself is an excellent demonstration of code reuse. Because of the massive library, the code you do write yourself will probably be customized to whatever you're doing. That's a good thing.
On a less bloated front, I often write objects into a test harness before dropping them into a large project. This allows for easier and more thorough testing. When I do implement them, I'll be certain that they won't conflict with other names and that they work the way they're supposed to.
By properly using interfaces, I can also tear down what I wrote and reimplement it without having to change the rest of the code. So I can write just enough to get things off the ground, then go work on other things. For data structures like priority queues and whatnot where a grossly inefficient solution can be written in minutes, this is essential.
This stuff can be done in C with header files and strict naming policies but it's a lot more painful.
The funny thing about your example is that 64-bit Windows is still in beta while various x86-64 Linux distros are considered stable. So you're not really using all your hardware in Windows either unless you're comfortable with pre-release operating systems, which would seem odd for someone so worried about hosing their disk.
The nForce3 ethernet chipset will be in the next kernel release, it might even be in the most current one, I'm not sure. Within about 6 months, it will probably be supported by whatever distribution you use. Consider that open source developers can't really do anything for hardware until they get their hands on it, so there's usually a time lag in support for bleeding edge stuff like yours.
Can you tell me where I can find some sailors?
While you make a good point, I think the ease of use issue is mostly irrelevant.
Regardless of whether or not linux sucks, it will eventually become the defacto operating system because it's cheaper. Without all those monopoly profits flowing into one vendor, there will be more money circulating in the economy to be used for growth.
When you have the choice as a business user between those $300 licenses (BTW how can you possibly charge that much for something that literally sells billions? The R&D has long been paid for, Bill.) or spending that money on something else that will earn more profit in the end, all while putting up with a crappy linux desktop environment, the choice becomes clear. Even if you're just spending that money on extra support staff and the migration, at least it's going back directly into the marketplace instead of Microsoft deciding how best to spend it.
I also think that the quality of the desktop is not that huge of a motivating factor for people to begin with. The eMac and iBook are both only slightly more expensive than your average bargain Wintel box and support MS Office, Photoshop, and Macromedia stuff, which would probably cover most non-financial and non-gamer users, but Apple's market penetration is still extremely weak.
And the Windows desktop isn't the paragon of useability. Log on to any non-technical user's system and you'll see something like 15 icons in the tray all eating up memory, ads that pop-up even when no browser is open, hundreds of icons all over the place for programs they haven't used in years, many of them for readme files and expired shareware, and maybe a few viruses. Quite simply, the average user will put up with whatever shit you put in front of them as long as the price is right. They just don't care as much about the quality of their workspace as we do.
As more people adopt linux and shape it to their needs, its value rises, overcoming migration costs. But it doesn't really matter whether improvements in the OS relate to increasing its value in some unrelated way or reducing migration costs, either is fine. But really, it just doesn't make sense to pay an inflated price on top almost every computer sold when you don't have to. That money can be used to buy more machines, or more people, or whatever else will help make people more productive. Ultimately, things will improve for everyone but Microsoft.
That's just my armchair Micro-econ 101 analysis of the situation anyways.